[System Study_001] Anti-Heeling: When One Sensor Moves Hundreds of Tonnes

An anti-heeling system is not required by any regulation. It exists because cargo work demands it. And yet it holds one of the shortest paths on a ship between a single sensor reading and hundreds of tonnes of water in motion — with no human approving each step.

This is a typology-level anatomy of that system under the Interaction–Authority–Physical Effect model. The analysis unit is not the interface but the interaction, and the classification is drawn from the equipment families the system is built from rather than from any one vendor's implementation.

Authority sits upstream. Physical contact sits downstream. Treating the highest authority value as a risk score gets both ends wrong.

Part I — Engineering

1. Why this system exists

When forty-foot containers land in sequence on one side of a bay, when vehicles file up a PCTC ramp, when a crane slews a heavy lift outboard, all of these operations produce the same side effect. The work itself heels the ship.

The problem is not that the ship heels. The problem is that when it heels, the work stops. Gantry cranes have rail gradient limits. Ramps stop accepting vehicles when the contact angle goes out of range. Slewing cranes lose rated capacity the moment a list develops. Cargo work is priced by the hour, and halting operations for every list correction puts that cost straight onto the schedule.

Single-side loading / crane slewing / ramp work
        |
        v
   Heel develops
        |
        +--> Cargo equipment operating limits exceeded --> work stops
        |
        +--> Stability margin eroded ------------------> safety reserve reduced
        |
        v
   Without correction, the operation does not work

An anti-heeling system solves this by actively transferring ballast water between port and starboard heeling tanks. Water moves from the low side to the high side, the moment is offset, and the hull stays upright without pausing the operation.

This is where the character of the system is set. Anti-heeling exists not because a rule demands it, but because the work requires it. That is exactly why the source workbook records its requirement origin as design-dependent VERIFIED. No SOLAS provision requiring anti-heeling on general merchant ships was identified in this research INFERRED; the basis for fitting one comes from what the ship carries and how it handles it.

And yet this unmandated system holds one of the shortest physical authority paths on the vessel — because a single inclinometer reading is translated into pump start without any per-event human approval.

2. What the system does

At system level, anti-heeling runs a five-step closed loop.

[MEASURE]  heel angle + port/stbd tank levels
   |
[DECIDE]   compare against setpoint -> correction needed? direction? target volume?
   |
[SELECT]   choose transfer path (from which tank to which tank)
   |
[ACTUATE]  align valves -> start pump (or blower, on air-driven designs)
   |
[RE-MEASURE] confirm heel change -> stop on target
   |
   +------------------- loop -------------------+

One distinction must be made immediately. Anti-heeling is not a static stability device. It does not increase GM and it does not improve the righting arm curve. If anything it works the other way, introducing free surface effect that reduces stability.

Working practice carries the same distinction in its vocabulary. Heel is a temporary inclination caused by an external force, and the vessel returns upright when that force is removed. List is a permanent inclination arising from weight distribution TYPICAL. Anti-heeling is designed, as its name says, to correct heel — but in service it also pushes back the list created by uneven loading. When that distinction blurs, operation slides into continuously offsetting a symptom while leaving the cause in place. A ship whose anti-heeling never stops running usually has a cargo plan problem, not an equipment problem.

3. Core functions and operating modes

Automatic mode is governed by its setpoint. Vendor documentation across several suppliers repeats the same figures: correction begins around ±1.5° of heel, and the initiation setpoint itself is adjustable across roughly 0.04°–5° depending on the product TYPICAL.

Read that as a specification and move on, and you miss the point of this article. A setpoint is a parameter, parameters can be changed, and the act of changing one has a name — A3 CONFIGURE.

4. How the system works

The answer to "how does anti-heeling work" is not a single program. The result is produced by a combination of four things: the inclinometer reading, the tank levels, the setpoints and control parameters, and the actual state of valves and pumps.

Part II — Composition

5. What the system is made of

In the workbook's component breakdown this system decomposes into five components, and those five belong to five different typologies — one clean layer each, with no overlap.

All five carry an evidence grade of TYPICAL — these are typology-level determinations inherited from equipment-family research, not measurements taken from a specific vessel.

Read as one line each: the console receives human intent, the controller manufactures the decision, the transmitter supplies the raw material for that decision, the valve sets the path, and the pump moves the water. Supervisory, control, sensing and actuation — exactly one layer apiece.

Two things in that table are worth pausing on before we unpack the layers. The bottom two rows carry zero outbound authority and the maximum physical effect, and neither of them is a CBS candidate. Section 11 returns to why that combination is the normal case rather than an anomaly.

6. Typology profiles

L2 — HMI / operator console (TYP-B04). Programmable, networked, and in the workbook all instances are CBS candidates to be listed separately. These are workstation-class devices running application software on a general-purpose or embedded OS. The family's principal authority is A4 COMMAND and A3 CONFIGURE toward its controller — and A3 is quieter than A4 but outlives it.

L1 — PLC / controller (TYP-B07). All workbook instances sit at Purdue L1-control. This is not the sensing layer; it is the layer that drives final elements directly. Closing a continuous regulation loop is A5 CONTROL; discrete orders such as pump start/stop are A4 COMMAND. Both codes coexist inside one controller.

L1 — Process transmitter (TYP-B01). An important split lives here. A passive sensing element and a microprocessor-based transmitter are different devices. The latter can be re-ranged and diagnosed remotely over HART. Because the workbook records the network interface only as "likely", whether this system's instrument link is plain 4-20 mA or carries HART is not established INFERRED.

L0 — Valve (TYP-A04) and pump (TYP-C01). Neither is programmable, neither is networked, and neither is an E26 CBS candidate. A valve body opens when pilot hydraulics arrive and closes when they are cut. A pump turns when power arrives and stops when it is removed. Neither interprets any information.

7. Where the supply boundary falls

In the workbook, all five components of this system sit within the parent package. On the component list, no independent control cubicle exists.

Vendor product documentation describes a different typical composition: main control cabinet, remote operator panels, tank level sensors, motor starters for pumps and valves, PLC, and inclinometer TYPICAL. Two of those do not appear as independent items in the workbook's five rows — the main control cabinet and the motor starter.

The supply boundary is a trust boundary for reasons that have nothing to do with where a firewall sits. It is a trust boundary because administrative ownership, privilege and update path all change at that line. If the package vendor commissions, tunes and updates its own cubicle, that access should not be labelled with the name of a connection method — "remote access" — but modelled as the acts it makes possible: A3 CONFIGURE, A6 ADMINISTER, A7 UPDATE_EXECUTABLE.

8. Architecture patterns

Real topology varies by ship, and the available data does not settle it. Three conceptual patterns are offered; none is asserted as the answer.

[A] Standalone
    dedicated inclinometer -> dedicated PLC -> dedicated valves & pumps
                     |
                     +--(status display only)--> IAS
    Character: control authority is closed inside the package. Local attack surface.

[B] IAS-Integrated
    dedicated inclinometer -> dedicated PLC -> valves & pumps
                     |<-->  IAS (display, alarms, history, mode change)
    Character: display and alarms leave for the IAS, and mode-change authority
               now also exists at the IAS console.

[C] Ballast-Integrated
    inclinometer -> PLC -> shared ballast valves & pumps
                     |<-->  IAS / ballast control
    Character: anti-heeling and ballast operation divide authority over the same
               physical resources. Misbehaviour on one side can directly obstruct
               work on the other.

Part III — Authority and Physical Effect

9. What information and commands flow through it

Writing "data is exchanged" ends the analysis before it starts. Separate them.

Without the third column this table is useless — because information and commands travel the same links, and authority differs by direction.

10. What authority does each connection carry

The columns worth staring at are the right-hand three. The only rows carrying Admin and Update Executable are the vendor service paths, not the operating paths. And those persist after the interaction ends — logic and firmware do not disappear on the next scan cycle.

The controller typology's doctrine puts it in one sentence: changing an interlock limit can be more consequential than a runtime command. Without sending a single order, quietly widening the initiation setpoint and the transfer volume limit leaves the machine to run itself into the dangerous region.

11. Can the system affect the physical process

The P5 attaching to valves is confined to the subset serving as the final element of a designated safety function, never the family as a whole. Ordinary anti-heeling line isolation valves stop at P4.

12. Human gate

Here the character of the system becomes sharpest. The same ballast transfer places the human in completely different positions depending on mode.

[MANUAL MODE]
Inclinometer -> Controller -> Console display -> *HUMAN DECISION* -> order -> valve & pump -> water moves
                                                     ^
                                         Human Gate = EXECUTION
                                     (nothing happens unless a person acts)

[AUTOMATIC MODE]
Inclinometer -> Controller -> valve & pump -> water moves
                     ^
             Human Gate ~ NONE (per event)
             The human steps back to SUPERVISION - watching, not approving

An anti-heeling controller is by definition a device that acts without operator intervention, which is why its human gate is SUPERVISION. Two modes producing the same physical result do not share a security architecture. Forging an order in manual mode requires imitating a human action. In automatic mode it is enough to contaminate a measurement. There is not even a person to deceive.

There is an important exception. Even where automatic mode leaves no per-event gate, the configuration and firmware paths carry a gate of their own. IACS UR E26 Rev.1 §4.2.6.3.1 requires that remote access be impossible until an accountable role onboard explicitly accepts it. So this system's human gate is not one gate but two layers — an operating gate that moves with the mode, and a change gate of AUTHORIZATION character.

13. Authority escalation and propagation

The inclinometer holds no CONTROL authority. A2 PROVIDE_INFORMATION is all it has. And yet a false heel reading reaches the physical world by two distinct routes.

[ROUTE 1 - automatic propagation, no human]
false heel value -> controller decision distorted -> valve line-up + pump start -> water moves
      A2                    (decision)                    A4/A5                      P4

[ROUTE 2 - human-mediated propagation, human present but input contaminated]
false heel value -> console display -> operator judgement -> manual order -> water moves
      A2                  P1              *GATE*               A4              P4
                                    but the gate is not a defence

Route 2 is the point of this section. A human standing at the gate does not constitute a defence. Given no means of verifying the value in front of them, a person will make a precisely wrong decision on contaminated input.

That chain has run to completion, on the public record, in the ballast and stability domain. On 8 September 2019 the vehicle carrier Golden Ray heeled sharply to port during a starboard turn within forty minutes of departing St. Simons Sound, Georgia, reaching 60° in under a minute before grounding and capsizing. The NTSB determined the probable cause to be the chief officer's error in entering ballast quantities into the stability calculation program. Post-accident analysis put actual GM between 0.8 m and 1.8 m against the 2.45 m that had been reported VERIFIED.

Console physical access or account compromise
   -> A4 COMMAND obtained (operating orders)
   -> shift to A3 CONFIGURE (setpoints, limits)        <-- the character changes here
   -> automatic decision logic left distorted, resident
   -> every subsequent automatic action executes on the attacker's parameters
   -> P3/P4 (persists without sending another order)

The move from A4 to A3 is the decisive one. A runtime order disappears on the next cycle; a setpoint stays.

Part IV — Uncertainty and Security

14. Trust boundaries and dependencies

A trust boundary is not where a firewall is. It is where a trust assumption changes. This system has three.

+---------------------------------------------------+
|  VENDOR PACKAGE DOMAIN                            |
|  (owner: package supplier / privilege: A3, A6, A7)|
|   [inclinometer] -> [controller] -> [valve & pump]|
+--------------------------|------------------------+
                           |  <== BOUNDARY 1: supply boundary
                           |      ownership, privilege, update path all change
                           v
+---------------------------------------------------+
|  SHIP INTEGRATION DOMAIN                          |
|   [IAS / engine control room console]             |
+--------------------------|------------------------+
                           |  <== BOUNDARY 2: IAS interface (E26 §1.3.2 b)
                           v
+---------------------------------------------------+
|  SHARED BALLAST DOMAIN (pattern C only)           |
|   physical resources shared -> authority contention|
+---------------------------------------------------+

This system depends on power, inclinometer integrity, tank level accuracy, and the ballast water actually available to move. The last is regularly forgotten — if one side's tank is already empty, the controller can judge perfectly and still have no means of correcting.

15. What happens when the system fails

The last row is the dangerous one. The deterministic-output requirement at IACS UR E27 Rev.1 §4.1 item 20 targets exactly this failure form.

[THE WORST FAILURE IS NOT STOPPING]

Stopped:       pump halts -> no heel correction -> cargo work suspended -> cost
                                                            (recoverable)

Running wrong: transfer continues in the wrong direction -> heel grows by itself
               -> cargo equipment limits exceeded -> stability margin eroded
                                                            (recovery takes time)

The failure mode of an active control system is worse when it does the wrong thing than when it does nothing. Which surfaces an uncomfortable fact: an anti-heeling system is also a device capable of creating heel.

16. Attack surface and credible threat scenarios

The exposure points are local access to the console and the panel's programming ports; removable media carrying PLC logic and project files; the IAS interface link in patterns B and C; the vendor service laptop and remote diagnostic link; and the supply chain of package firmware and project files resident at yard and vendor. Unauthenticated fieldbus belongs on this list too — Modbus RTU/TCP and CANopen carry neither sender authentication nor message integrity.

SCENARIO 1 - parameter change via the vendor path

Entry interaction    : vendor service laptop -> controller
Initial authority    : A3 CONFIGURE, A6 ADMINISTER, A7 UPDATE_EXECUTABLE
Mechanism            : widen the initiation setpoint, relax transfer volume and time
                       limits (not a single operating order is sent)
Authority gained     : distortion resident in the automatic decision logic
Affected interaction : controller -> valve & pump (A4/A5)
Physical effect      : P3 -> P4
Consequence          : heel during cargo work develops beyond design intent, or
                       correction lags. The operator screen reads "normal automatic".

The point of Scenario 1 is that no command was ever issued. There is no anomalous order in the log.

SCENARIO 2 - contamination of the heel signal path

Entry interaction    : inclinometer signal path (wiring access, or remote I/O segment)
Initial authority    : A2 PROVIDE_INFORMATION - all the inclinometer has
Mechanism            : inject a constant offset into the measurement
Authority gained     : none - no escalation occurs at all
Affected interaction : (a) the automatic loop  (b) console display -> operator
Physical effect      : (a) P3/P4 immediately   (b) P1 -> human-mediated P4
Consequence          : in automatic mode, immediate mis-transfer. In manual mode the
                       operator issues a precisely wrong order on contaminated input.

The design lesson of Scenario 2 is that escalation is not a precondition for attack. Contaminating A2 alone reaches P4. Grade assets by authority alone and this path is invisible.

17. Security architecture and standards

Controls are derived from threats, and standards are mapped afterwards.

1. Log and authenticate setpoint and limit changes — who changed what, when, to what value, recorded at a different grade from runtime orders.
2. Time-bound vendor access with explicit acceptance — IACS UR E26 Rev.1 §4.2.6.3.1 requires remote access to be possible only after an accountable role onboard explicitly accepts it.
3. Verify software authenticity — IACS UR E27 Rev.1 §5.2, §5.4 and §6.3.4.4 require documentation and delivery of updates and verification of authenticity by the user.
4. Redundant heel measurement with cross-checking — hanging an automatic loop off a single inclinometer creates a path from one A2 contamination to P4.
5. Rate-limit automatic mode — bound transfer volume and duration so a wrong decision has a bounded physical result.
6. Validate inputs — IACS UR E27 Rev.1 §4.2 item 39 requires validation of the syntax, length and content of process control inputs.
7. Register the control cabinet and starter panel explicitly in the asset inventory — IACS UR E26 Rev.1 §4.1.1.3.2 names application programs, operating systems and firmware as inventory objects.

On the manual return path, SOLAS II-1 Reg. 31.4 provides that "automatic starting, operational and control systems shall include provisions for manually overriding the automatic controls" and that "failure of any part of such systems shall not prevent the use of the manual override" VERIFIED. Note carefully that Regulation 31 addresses machinery essential for the propulsion, control and safety of the ship; whether anti-heeling falls into that category on a given vessel is a separate determination, and writing that this clause automatically applies would be wrong. It is cited here as the design principle SOLAS establishes for automatic control systems. IACS UR E26 Rev.1 §4.4.2.1 adds the cyber dimension, requiring that CBS for local backup control be independent of the main control system.

18. Open questions

These are what must be asked of the vendor and the owner. They are not rhetorical — each one changes an answer above.

1. What is the actual link between inclinometer and controller — plain 4-20 mA, or HART on top? If HART is present, an inbound A3 remote re-range path genuinely exists.
2. Which component rows correspond to the main control cabinet and the motor starter panel? Are they missing from the E26 inventory?
3. Does the pump run/trip contact physically originate at the pump or at the starter contactor?
4. Is this installation pattern A, B or C? Does it share piping and pumps with the ballast system?
5. What are the present initiation setpoint and transfer limits, and who is able to change them?
6. Is the inclinometer single or redundant? If redundant, how does the automatic loop behave on disagreement?
7. Does a vendor remote diagnostic link exist, and is the explicit-acceptance requirement of §4.2.6.3.1 actually implemented?
8. Where are the controller project file backups held, and how is their integrity assured?
9. Does any valve in the anti-heeling line serve as the final element of a designated safety function?
10. Is anti-heeling classified on this vessel as machinery essential for propulsion, control and safety?
11. Do any ship types or class notations require anti-heeling? No such requirement was identified in this research.

What this changes

• Stop grading assets by authority alone — a path exists from A2 contamination straight to P4 with no escalation anywhere along it.
• Treat parameter changes as a separate class from commands — A3 is quieter than A4 and lasts longer, and Scenario 1 leaves no anomalous order in any log.
• Audit the inventory for the "list separately" and "within parent package" combination — that is where a CBS that must be listed separately gets buried in parent package documentation.
• Ask which mode the system runs in — mode moves the human gate, and in automatic mode there is no person to deceive.

Closing thought

Anti-heeling is a small system by any inventory measure. Five components, of which two are computer based. It appears in no mandatory equipment list. And it will move hundreds of tonnes of water across a ship on the strength of one angle measurement, while the officer responsible watches a screen that says everything is normal.

The interesting question is not whether this system is dangerous. It is why a component list — the artefact most cyber programmes start from — tells you so little about which parts of it matter. The answer is that inventories count things, and authority is not a property of things. It is a property of the interactions between them, and it runs in one direction at a time.

---

Article classification. Engineering Intelligence — system anatomy, typology-anchored. Evidence profile: primary standards (IACS UR E26/E27, SOLAS II-1) plus workbook typology data, vendor product documentation and a public accident investigation. Scope: generic architecture; real implementations vary by vendor and vessel, and architecture patterns A/B/C are conceptual models. The authority and physical effect classifications are typology-level determinations and have not been verified against any specific vessel's wiring diagrams or P&IDs. Typology coverage: 5 of 5 confirmed.

Sources

• IACS, UR E26 Rev.1, “Cyber resilience of ships” — §1.3 scope, §1.3.2 b) communication interfaces, §2 CBS definition, §4.1.1.3.2 asset inventory, §4.2.4.3.1 physical access, §4.2.6.3 and §4.2.6.3.1 remote access, §4.4.2.1 local backup control
• IACS, UR E27 Rev.1, “Cyber resilience of on-board systems and equipment” — §4.1 item 20 deterministic output, §4.2 item 39 input validation, §5.2 / §5.4 / §6.3.4.4 software update and authenticity
• IMO, SOLAS Chapter II-1 Regulation 31, “Machinery controls” — Reg. 31.4 manual override. Regulation 31 addresses machinery essential for propulsion, control and safety; Reg. 31.2.5 on control-location exclusivity applies specifically to propulsion machinery and is noted here only as a design principle.
• NTSB, “NTSB Determines Inaccurate Stability Calculations Caused Capsizing of Vehicle Carrier Golden Ray,” news release NR20210914b, 14 September 2021
• Anti-heeling product documentation consulted for typical composition and setpoint ranges (Wärtsilä Intering, Hoppe Marine, Weser Flow Control, VEGA, CIRCOR). Cited vendor-neutrally; no product is recommended and no implementation is asserted from these sources.