Subsea Cable Operations Software: Who Pays for the Repair Ship, and Can You Prove It?

Why subsea cable operations outgrow the shared inbox

A subsea cable system is one physical asset owned by parties who compete with each other on land. The consortium signed a construction and maintenance agreement years ago. That document says who owns which fibre pairs, who sits on the management committee, who can authorise a repair and at what threshold, and how the invoice for that repair gets split when it lands. Then a trawler drags an anchor across the cable at two in the morning and every one of those clauses has to be executed inside a week, by email, across nine time zones.

The operations team doing it is small. Often it is three or four people plus a landing party contact in each country. They hold the system in a folder structure: the as laid route position list, the repeater and branching unit inventory, the depot spare stock, the zone maintenance agreement with its standby fee and day rate, permit precedents from the last two repairs, and an ownership percentage table finance maintains separately. None of it is joined to anything else. When the fault happens, somebody starts a new email thread, and that thread quietly becomes the system of record for a repair that will cost more than most software projects.

The cost of that is not abstract. A repair ship on standby bills whether it sails or not, and once mobilised it bills by the day plus fuel plus jointing consumables. Every day lost to a permit application that went to the wrong ministry, or to a depot that shipped the wrong repeater type, is a day nobody gets back. Then the invoice arrives, and the apportionment argument starts, because two owners read the same clause differently and neither can produce a clean record of what was actually done on whose behalf.

The moment the model breaks: a shunt fault at 3,200 metres

Power feeding equipment at one landing station reports a shunt fault. The line monitoring system gives an electrical distance. The optical time domain reflectometer trace from the terminal narrows it further, but the numbers disagree by a few kilometres because nobody has reconciled the as laid slack against the route position list since the last repair changed the cable length.

Now the work starts. Which maintenance zone is that position in, and which agreement covers it. Which ship is on station and what is her current commitment. Is the fault position inside territorial waters, in which case a permit is required, and from which authority, and does the last permit for this system still have an unexpired clause anybody can point to. Which spare cable type and which repeater sit in which depot, and does the depot stock match what the system actually uses after the 2019 upgrade. Does the repair cross a threshold that requires management committee approval, or can the operations manager authorise it alone.

Every one of those questions has an answer somewhere in that folder structure. None of them can be answered in one place, so the answers are assembled by a human under pressure, and mistakes made in that window are expensive for a month.

What generic project and asset tools actually fail at

There is no packaged product for this. That is not a marketing line, it is the reason the category exists on a search results page at all. Operators end up on some combination of Excel, SharePoint, Microsoft Project and email, occasionally with a maintenance management system inherited from the terrestrial side of the business.

Those tools fail on three specific things. The first is that a repair is not a project with a start date, it is a case that has to hold evidence: fault measurements, permit correspondence, ship logs, jointing records, post repair test results, and every authorisation given along the way. Project tools model tasks and dates. They do not model a defensible case file that will be read by a lawyer if a cable ship claim goes wrong.

The second is cost apportionment. Nothing off the shelf can express a clause that says standby fees split by ownership share, repair day rates split by fibre pair ownership on the affected segment, and third party damage recoveries credited back in the same proportion net of legal costs. That is bespoke arithmetic written by lawyers, and it changes per system. Finance ends up rebuilding it in a spreadsheet each time, which is exactly why owners dispute it.

The third is that terrestrial asset systems assume you can send a technician. Your asset is under two miles of water and reachable only by a ship you share with other cable owners under an agreement with its own priority rules. The whole scheduling model is wrong from the first screen.

What a custom subsea cable operations build has to include

Start with the system model, because everything else hangs off it. That means the route position list as a first class object with segments, repeaters, branching units, joints and burial depth, versioned so that a post repair change to cable length updates the geometry rather than being noted in a Word file. Fault positions get plotted against that geometry, and the electrical and optical estimates get stored side by side with their disagreement visible rather than reconciled away.

Then the fault case. One record from first alarm through to final splice and post repair acceptance, holding the measurement history, the zone determination, the ship assignment, permit applications per jurisdiction with their own status and expiry, depot picks with serial numbers, daily ship reports, and each authorisation with who gave it under which clause. The case is append only. Nobody edits history, because the record is the point.

Then the cost engine. Model the construction and maintenance agreement as configurable rules rather than as a fixed schema, because the next system you operate will have a different one. Standby cost accrues continuously and allocates monthly. Repair costs allocate per the clause that applies to the affected segment. Recoveries from a damaging vessel offset in the same proportion. Every allocated line traces back to a source document, so when an owner queries their share you send them a statement with the ship report attached rather than a spreadsheet and an argument.

Then the spare and depot layer, which is duller and equally important. Cable types, repeater and branching unit models with serial numbers, depot locations, minimum holdings under the zone agreement, and consumption when a repair draws stock. Half the emergency purchase orders in this business exist because nobody knew a depot was short until the ship was already loading.

Two integrations earn their place quickly. Pull line monitoring and terminal equipment alarms directly so a fault case opens automatically with its measurements attached instead of being typed. Push a member facing view so owners can see repair status and their accruing cost share without emailing the operations manager, which alone removes a large amount of the coordination load the team currently carries.

What it costs and how long it takes

Across the projects Digital Heroes has delivered, the honest shape for this category is a first release at $90,000 to $180,000 shipping in 14 to 20 weeks. That release is the system model, the fault case with permits and ship coordination, and the cost apportionment engine for one agreement. It is used on the next real fault, not demonstrated in a meeting.

A full platform at $220,000 to $500,000 phased over 9 to 15 months adds multi system support, depot and spare inventory, landing party and landing station coordination, capacity and ownership records including indefinite right of use holdings, the member portal, and integration with line monitoring and finance.

What pushes the number up here specifically: the count of distinct maintenance agreements you operate under, because each one is a separate rule set rather than a configuration. The number of permit jurisdictions, since each authority wants a different pack in a different language. Line monitoring integration, because vendor interfaces on this equipment are not uniform and some of them are old. And how many owners want their own portal view with their own accounting calendar.

What holds it down: starting with one system and one agreement, and accepting that the first release will not touch capacity sales or the network operations centre. Those are separate problems that have working tools already.

When you should not build this

If you buy capacity on systems you do not help manage, do not build. Your exposure is a bill you either pay or contest, and a well run shared drive plus a competent administrator handles that.

If you operate exactly one system with a stable consortium, few repairs and a manager who has run it for a decade without complaint, the honest advice is to spend the money on documentation instead. Write the route position list into a database, get the agreement clauses summarised into a decision table, and see whether that removes the pain before commissioning software.

Build when you operate or manage more than one system, when repair cost disputes routinely run past ninety days, when the person who knows how apportionment works is one person, or when a landing party or cable maintenance authority relationship has already cost you time because nobody could produce a record on demand.

How to choose a developer for subsea cable operations software

Ask them to model the cost apportionment clause on a whiteboard before you sign anything. Hand them one real clause from your agreement and watch what they draw. A developer who understands this will ask which segment the fault sits on, whether ownership is by fibre pair or by capacity, and how recoveries from a third party vessel are treated. A developer who draws an invoice table with a percentage column has not read the clause.

Ask how they will handle the case file being evidence rather than a workflow. The answer you want involves an append only event log, document retention with the original file preserved, and the ability to export a complete pack for a specific fault. If the answer is a status field and a comments box, they are building a ticketing system.

Ask what they have actually integrated at the equipment layer. Line monitoring systems and power feeding equipment interfaces are not web APIs, and someone on the team needs to have worked with industrial and telecom equipment protocols rather than only cloud services.

Ask who owns the code and get it written into the contract before kickoff. You should own the repository, the infrastructure accounts, and the right to hire anyone else to continue the work. At Digital Heroes the client owns the code from the first commit, and we would tell you to walk away from anyone who hedges on that question.