> ## Content Index > Fetch the complete content index at: https://julius-shin.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # [System Study_001] Anti-Heeling: When One Sensor Moves Hundreds of Tonnes - URL: https://julius-shin.ghost.io/anti-heeling-system-authority-analysis/ - Published: 2026-09-08T14:19:44.000Z - Updated: 2026-09-10T17:38:34.000Z - Description: A system no regulation requires holds one of the shortest physical authority paths on a ship. A typology-level analysis of anti-heeling under the Interaction-Authority-Physical Effect model. - Author: Julius Shin - Tags: Engineering Intelligence, Maritime OT, IACS UR E26, Systems Engineering, Ballast Systems, SYS-055 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. ![Diagram of a ship alongside a quay heeling to port as a gantry crane lands a container off-centre, with the anti-heeling pump transferring ballast from the port low tank to the starboard high tank, and the control chain from inclinometer through controller and starter to valve and pump.](https://storage.ghost.io/c/a6/dc/a6dc20de-3f8c-43b2-8b47-7a4a15e40dfe/content/images/2026/09/anti-heeling-system-authority-analysis-context.jpg) The work itself creates the heel. Anti-heeling offsets the moment while cargo operations continue — it does not remove the cause. Transfer runs from the low side to the high side. ### 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 | Mode | Who decides | Where the human stands | | --------------------------------- | ------------------------------------- | ---------------------------------------------- | | **Manual** | Operator | Commands direction, timing and volume directly | | **Automatic** | Controller | Monitors only. No per-event approval | | **Semi-auto** (product-dependent) | Controller proposes, operator accepts | An approval gate exists | 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. Engineering note — the thing you protect is not one executable The program can be intact and a changed setpoint will change behaviour. Program and setpoint can both be intact and a wrong inclinometer reading will make the system act precisely, in precisely the wrong direction. And if valve position feedback disagrees with reality, the console displays normal while the water goes somewhere else. What must be protected is not the executable but the entire set of inputs that manufacture the decision. ## 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. | Purdue | Typology | Equipment family | Authority (out) | Physical effect | CBS (E26) | | ---------------- | -------- | ------------------------------- | --------------- | ------------------ | ----------------------- | | L2 — supervisory | TYP-B04 | HMI / operator console / panel | A4 · A3 · A1 | P3 P2 P1 | **Y — list separately** | | L1 — control | TYP-B07 | PLC / controller / control unit | A4 · A5 · A2 | P4 P3 P2 | **Y — list separately** | | L1 — sensing | TYP-B01 | Process transmitter / sensor | A1 · A2 | P1 P2 P3 | N | | L0 — process | TYP-A04 | Shutoff / isolation valve | **A0** | **P4** (P5 subset) | N | | L0 — process | TYP-C01 | Centrifugal pump | **A0** | **P4** | N | 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. Key distinction — component count is not a measure of cyber relevance Of this system's five components, only two are E26 CBS candidates. The other three — transmitter, valve, pump — are not. Yet the physical work of moving water is done entirely by those three, and the two CBS candidates move no water at all. Inventory size and physical contact are different axes, and overlaying them misreads both. ### 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 inventory trap What actually holds physical authority is not the pump but the starter panel that energises it, and the logic lives in the control cabinet. Both are absorbed into the parent package and appear on no component row. Build an E26 asset inventory mechanically from component rows and a CBS that should have been listed separately disappears entirely. The signal to watch for is explicit in the data: a CBS candidacy of "list separately" combined with a supply boundary of "within parent package". 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. Typical architecture — disclaimer These three patterns are conceptual models, not the implementation of any particular ship or product. Actual arrangement is established only by vendor documentation, P&IDs and the vessel's own wiring diagrams. Statements below of the form "this system holds A5 CONTROL" are used only where they hold across patterns A through C. ## 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. | What flows | Kind | Direction | | ------------------------------ | ------------- | ----------------------------------- | | Heel angle | Information | Transmitter → controller | | Port/stbd tank levels | Information | Transmitter → controller | | Pump run / trip status | Information | Starter → controller → console | | Valve position feedback | Information | Limit switch → controller → console | | Mode change | **Command** | Console → controller | | Initiation setpoint and limits | **Parameter** | Console / service tool → controller | | Pump start / stop | **Command** | Controller → starter | | Valve open / close | **Command** | Controller → solenoid | 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 | Source → Destination | Observe | Provide info | Configure | Command | Control | Admin | Update exec | | -------------------------------- | ------- | ------------ | --------- | ------- | ------- | ----- | ----------- | | Transmitter → controller | · | **Y** | · | · | · | · | · | | Controller → transmitter | **Y** | · | ? | · | · | · | ? | | Controller → valve & pump | · | · | · | **Y** | **Y** | · | · | | Controller → IAS | · | **Y** | · | · | · | · | · | | Console → controller | **Y** | · | **Y** | **Y** | · | · | · | | Vendor service tool → controller | **Y** | · | **Y** | · | · | **Y** | **Y** | | Vendor service tool → console | **Y** | · | **Y** | · | · | **Y** | **Y** | | Valve & pump → controller | · | **Y** | · | · | · | · | · | Key distinction — connectivity is not authority The inclinometer is wired to the controller. But the authority the inclinometer exercises over the controller stops at A2 PROVIDE\_INFORMATION. It commands nothing. In the other direction the controller holds A1 OBSERVE, and on a HART-class transmitter that may extend to A3 CONFIGURE through remote re-ranging — except that the source data records the network interface only as "likely", so whether that path exists here is not established. We do not write that it exists, and we do not write that it does not. 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 | Interaction | Authority | Physical effect | Human gate | Security significance | | ------------------------- | ---------- | ------------------- | ------------------ | -------------------------------------------------- | | Transmitter → controller | A2 | **P1** | SUPERVISION | False value contaminates the decision | | Console → controller | A3, A4 | **P2** | EXECUTION | No physical quantity changes; operating state does | | Controller → valve & pump | A4, A5 | **P3 / P4** | SUPERVISION (auto) | Physical contact of the automatic loop | | Valve operation | A0 | **P4** (subset P5) | — | Directly opens and closes fluid flow | | Pump operation | A0 | **P4** | — | Actually transfers the water | | Vendor tool → controller | A3, A6, A7 | **P3** (persistent) | AUTHORIZATION | Behaviour change that outlives the session | Key distinction — A0 outbound and P4 hold at the same time The valve's and the pump's outbound authority is A0 NONE. They order nothing; they hold no logic, no setpoint, no state machine. And yet their physical effect is P4 DIRECT\_PHYSICAL\_CONTROL. When the valve opens, fluid flows. When the pump turns, water actually moves. There is no interpreting layer in between. This asymmetry is not an anomaly — it is the normal case. Which is why using "this component's highest authority value" as a risk score gets it wrong twice: the valve and pump are underrated at zero authority and maximum physical contact, while the console is overrated because it holds A4 and A3 but is not wired to any actuator and therefore stops at P3. 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. Honesty note — this was not an anti-heeling failure Golden Ray was a stability calculation input error, not an anti-heeling system failure. It appears here for one precise reason: it is a public investigation record of the chain "wrong number → wrong judgement → physical outcome" running to completion in the ballast and stability domain, and the structure of that chain is Route 2 above. Attributing this casualty to anti-heeling would be a distortion of fact. 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 | Cause | Observation | Operational consequence | | ------------------------------------------- | ------------------------------------------------- | --------------------------------------------------------------------------- | | Inclinometer drift / zero offset | Heel indicated non-zero while stationary | Automatic mode initiates an unnecessary transfer and manufactures real heel | | Signal lag / excessive filter time constant | Pump overshoots and reverses repeatedly | **Hunting** — heel oscillation amplified, cargo work stability eroded | | Valve seat wear or debris | Indicated closed while passing | Unintended inter-tank transfer, discovered late | | Limit switch misalignment | Console indication disagrees with actual position | Pump started against a wrong valve line-up | | Controller power dip, watchdog failure | CPU halted, outputs holding last value | **Final elements frozen at the last order** | 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. An honest statement of regulatory status The anti-heeling system itself is not equipment mandated by SOLAS or class rules. But what it handles and what it produces are both under mandatory regulation — ballast water under the BWM Convention and MARPOL, heel and stability under SOLAS II-1, and its controller and console under IACS UR E26/E27 if they are CBS. The system is discretionary, its consequences are regulated. Inverting that into "SOLAS requires anti-heeling" is simply wrong. ### 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”](https://iacs.org.uk/resolutions/unified-requirements/ur-e/?ref=julius-shin.ghost.io) — §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”](https://iacs.org.uk/resolutions/unified-requirements/ur-e/?ref=julius-shin.ghost.io) — §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”](https://www.imorules.com/GUID-8CC22231-DC68-4383-9D0A-61D67F77FEE5.html?ref=julius-shin.ghost.io) — 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,”](https://www.ntsb.gov/news/press-releases/Pages/NR20210914b.aspx?ref=julius-shin.ghost.io) 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.