On this page
Executive summary
A cargo tank level gauge exports one kind of authority: A2, provide information. It observes and it tells; it opens no valve and stops no pump. And yet that single number rides two propagation paths whose characters are opposites — a commercial path that ends on the Bill of Lading, slow and human-gated and blind to any error inside normal tolerance, and a safety path that ends at an automatic shutdown valve, fast, ungated, and dangerous in both directions.
The independence requirements of IGC Code 13.3.1 and IBC Code 13.1.2 and 15.19.5 are the wall between those paths — written before "cyber" attached to anything, but functionally a common-cause control. Where modern integration quietly dismantles that wall — shared HMI, shared network, shared power, shared service tool — is what this article looks at.
Part I — Engineering
1. Why this system exists
Why you need to know the level in a tank of liquid cargo is obvious. Why it should be radar is not, and the answer is not accuracy. It is closure.
Both codes grade gauging devices by how much cargo they let out. IBC Code 13.1.1 runs open (a tank opening that may expose the gauger to cargo or vapour), restricted (penetrating the tank, releasing a small quantity of cargo vapour or liquid to atmosphere in use and fully closed when not in use), closed (penetrating but part of a closed system — float, electronic probe, magnetic probe, protected sight-glass), and indirect (weighing or pipe flow metering, never breaching the shell). VERIFIED
IGC Code 13.2.2 enumerates the same logic in four categories, and it is worth having all four, because the last of them is where the Code stops describing and starts dimensioning. (1) Indirect — weighing, or pipe flow metering. (2) Closed, not penetrating the cargo tank — the examples the provision names are devices using radioisotopes and ultrasonic devices. (3) Closed, penetrating the cargo tank but forming part of a closed system — float, electronic probe, magnetic probe, bubble tube; where the device is not mounted directly on the tank, an isolating valve is required. (4) Restricted, penetrating the tank and releasing a small quantity in use — fixed tube and slip tube gauges. VERIFIED
Category (4) is the one that carries a number, and its grammar matters. The Code requires the device to be so designed that its maximum opening does not exceed 1.5 mm diameter or equivalent area, unless the device is provided with an excess flow valve. VERIFIED That is a principle with a named exception, not two alternatives of equal standing, and the difference is not pedantry. Read as alternatives, a 3 mm opening is compliant because "one of the two conditions" was satisfied. Read as the Code actually writes it, the small aperture is the rule and an excess flow valve is the single named thing that buys relief from it — a device with a larger opening is admissible only because a specific protective element was fitted, and the burden sits on demonstrating that element, not on choosing a branch.
A radar gauge satisfies category (2): antenna on the tank top, wave reflected off the surface, nothing wetted, nothing pierced. One point must be exact, though, because it bounds how strongly the rest of this article may argue. The only examples the provision names in that category are radioisotope and ultrasonic devices. Radar is not named. VERIFIED A radar gauge meets the definition structurally; the Code does not enumerate it, and this article claims category fitness and nothing more. The conclusion is unchanged: this system exists not in order to be accurate, but in order not to open the tank.
Liquid cargo in a closed tank
|
+-----------+-----------+
| |
"How much is in it?" "Do not open the tank"
| |
Loading limit / Toxicity, flammability,
custody quantity vapour pressure, personnel exposure
| |
+-----------+-----------+
|
Gauging method ladder (IBC 13.1.1)
|
open -> restricted -> closed -> indirect
(exposure decreasing ->)
|
Radar = closed, non-penetrating (IGC 13.2.2(2))
|
Two demands on ONE instrument
|
+-----------+-----------+
| |
Custody quantity Overfill prevention
(commercial) (safety)
Which method must be used is decided by the cargo: IBC Code 13.1.4 points at column j of the chapter 17 table, and the more toxic and flammable the cargo, the further right along the ladder it is pushed. VERIFIED That is the regulatory history in one sentence — the history of gauging methods is not one of improving accuracy but of reducing human exposure.
The same clause family then fixes availability and rules certain devices out, and the way it rules them out is the same structure the aperture rule uses. IGC Code 13.2.1 requires at least one liquid level gauging device per cargo tank, operable at pressures not less than the tank MARVS and within the cargo operating temperature range, and where only one is fitted it must be maintainable without emptying the tank. VERIFIED 13.2.3 allows sighting ports as a secondary means of gauging, but only on tanks with a design vapour pressure not exceeding 0.7 bar. VERIFIED 13.2.4 is the provision most often paraphrased into something stronger than it says: tubular gauge glasses shall not be fitted. VERIFIED It is easy — and wrong — to render that as an absolute prohibition, because the provision carries a narrow exception: a gauge glass of robust construction fitted with an excess flow valve is admissible, subject to approval by the Administration. VERIFIED
That exception is the point, not a footnote to it. Both provisions are built the same way — the default is exclusion, and what reopens the door is a specific protective element plus, in 13.2.4, an approval step by a named authority. It is the drafting logic of the whole chapter: the Code does not forbid leakage paths outright; it forbids unmitigated ones, and it names the mitigation each time rather than leaving it to judgement. An engineer who remembers the rule as "no tubular gauge glasses, ever" will misread a compliant installation as a violation; one who remembers it as "1.5 mm or an excess flow valve, take your pick" will accept a non-compliant one. Both errors come from flattening a principle-and-exception into a list.
So this is equipment mandated by the nature of the cargo, and the mandate starts from safety. Commercial accuracy is a second demand laid on top — but both come out of the same instrument.
2. What the system does
At system level the function decomposes into five steps.
- Range measurement — time of flight, or frequency difference, of a wave reflected off the liquid surface, giving a distance from the antenna reference plane.
- Level derivation — distance converted through tank geometry and datum offsets into ullage or level.
- Volume conversion — level entered into the tank calibration table, corrected for trim and list.
- Mass conversion — temperature and pressure drive the corrections; density gives mass.
- Presentation — to local indicator, CCR workstation, loading computer and alarm system, with a high-level alarm on threshold exceedance.
Radar antenna (tank top)
|
Time-of-flight / frequency sweep
|
Distance to surface
|
Ullage -> Level <- reference plane offsets, tank geometry
|
Tank calibration table <- trim / list correction, shell shrinkage
|
Volume
|
Temperature probes (multi-height) + tank pressure [TYP-B13]
|
Corrected volume -> density -> MASS
|
+----------------> CCR gauging workstation [TYP-B14] -> Cargo officer
|
+----------------> High-level alarm threshold comparison
|
+----------------> Loading computer / custody transfer record
Those five steps are the entire system, and only the first is a physical measurement. Steps two to four are arithmetic.
3. Core functions and operating modes
The instrument plays different roles by mode.
- Loading is the busy mode: level rising fast, loading rate and topping-up judgement hanging on the value, and the only span in which a high-level alarm can fire.
- Discharge informs pump suction-loss judgement and the remaining-on-board figure, and passage monitoring treats change itself as the signal — inter-tank leakage, valve passing, thermal expansion.
- Static custody measurement fixes the quantity after loading, and that output becomes a document with contractual force: highest accuracy demand, most human involvement.
- Tank cleaning, inerting and gas-freeing run with little or no liquid, and the device must survive them.
A second axis splits the system into online and offline. Online is continuous measurement; offline is verification and calibration — building the calibration table, checking zero and span, setting thresholds, functional testing — and the rules demand it explicitly. IGC Code 13.3.5 requires the high-level alarm to be tested at the first full loading after delivery and after every drydocking, 13.3.6 requires every alarm element to be functionally testable before cargo operations under 18.6.2, and IBC Code 15.19.4 requires the same before operations begin. VERIFIED
In cyber terms that regime is easy to name: it is the scheduled, legitimate window in which somebody touches this system. Testing fires alarms, confirms thresholds and frequently reaches parameters — which is where the line between routine maintenance and manipulation gets thin.
4. How the system works
Level is not measured. It is computed. What the gauge physically obtains is a single time or frequency difference; the number on the screen and the number on the Bill of Lading emerge from it through several transformations, each depending on different data with a different owner and a different update route.
MEASURED COMPUTED (chain of stored data + parameters)
-------- --------------------------------------------
Time of flight --> Distance
| antenna reference offset, tank top datum [param]
Ullage
| tank height, datum plate reference [param]
Level
| TANK CALIBRATION TABLE [data set]
Gross volume
| trim / list correction tables [data set]
| shell shrinkage / thermal expansion factor [param]
Corrected volume
| temperature profile (multi-height probes) [live input]
| tank pressure [live input]
| density at reference temperature [param / lab]
MASS --> Bill of Lading
A commercial fact attaches here. OIML R 85-1 & 2 (Edition 2008) sets the metrological and technical requirements, and the metrological controls and tests, for automatic level gauges, and it states its own purpose plainly: level measurement is applied in conjunction with tank calibration tables to determine the volume of liquid received into, delivered out of, or contained in the tank. VERIFIED That sentence makes the point for us: what R 85 attests to is the accuracy of a level, which is to say of a length, while the calibration table is separate data multiplied in outside the scope of that attestation. In the chain above, metrological certification covers the top two or three rungs; everything from the calibration table downward — trim and list tables, shrinkage factor, density — falls outside the certificate. The seam in the commercial path is exactly there.
The scope is worth stating precisely, because it is what makes the attribution honest rather than decorative. R 85 applies to stationary storage tanks, and the shapes it covers are the ones defined in OIML R 71 — vertical cylindrical tanks, and pressure storage tanks of spherical, spheroid and bullet form, including tanks that are refrigerated or heated. VERIFIED That list is close enough to gas-carrier and chemical-tanker containment geometry to explain why the Recommendation reads as though it had been written for this instrument, and far enough from it to matter: a ship's cargo tank is not a stationary storage tank, and shipboard application arrives through type approval and class approval, not through the Recommendation itself. TYPICAL The metrological argument above is therefore attributed to the Recommendation's own text, not asserted as a shipboard requirement.
Part II — Composition
5. What the system is made of
Four component rows, three typologies.
Table 1 — Typology composition
| Typology | Equipment class | Components | Count | Purdue | CBS (UR E26) | Evidence |
|---|---|---|---|---|---|---|
| TYP-B12 | Radar / sonar / sensing device | Radar level gauges | 1 | L1 — sensing | Y — separately listed | TYPICAL |
| TYP-B13 | Process transmitter / sensor | Tank temperature sensors, tank pressure sensors | 2 | L1 — sensing | N | TYPICAL |
| TYP-B14 | HMI / operator console / panel | CCR gauging workstation | 1 | L2 — supervisory | Y — separately listed | TYPICAL |
- TYP-B12, the radar level gauge — the primary instrument, one per tank. Programmable, network-connected, and a separately listed CBS under UR E26, so it must be individually identified in the asset inventory.
- TYP-B13, the temperature and pressure sensors — these produce not level but corrections, and by family doctrine they are not CBSs. The most easily misread row in the system.
- TYP-B14, the CCR gauging workstation — every tank on one screen. Purdue L2, separately listed CBS, and within this system a pure display and supervision console. It opens no valve.
Tank 1..N
|
[TYP-B12] Radar level gauge ---- level ------+
^ |
| analogue / HART inputs |
[TYP-B13] Temperature probes (multi-height) |
[TYP-B13] Tank pressure transmitter |
v
[TYP-B14] CCR gauging workstation
|
+-------------+-------------+
| |
Loading computer / High-level alarm
custody transfer annunciation
That there are only four components is not itself the conclusion.
6. Typology profiles, and re-deriving the instance envelope
Table 2 — Typology attributes
| Attribute | TYP-B12 (radar gauge) | TYP-B13 (temp / pressure) | TYP-B14 (CCR workstation) |
|---|---|---|---|
| Programmable | Y across the family | Most family members are microprocessor-based transmitters | Y |
| Network interface | 'Likely' dominant in the family — instance confirmation needed | Some hardwired into the parent CBS | Y |
| Purdue level | L1 sensing | L1 sensing | L2 supervisory |
| Consequence of loss | Operational for most of the family | Operational for most of the family | Operational for most of the family |
| Supply boundary | Inside parent package (maker package) | Inside parent package | Inside parent package |
| CBS (UR E26) | Y — separately listed | N | Y — separately listed |
| Evidence | TYPICAL | TYPICAL | TYPICAL |
The most important line is the CBS row for TYP-B13. The temperature and pressure sensors are not CBSs — not individual inventory items, not direct objects of security controls — and for good reason, since in many installations they are wired straight into the gauge's analogue inputs, with no account and no network stack.
Now look again at the chain in section 4. Mass is volume times density, and both density and the volume correction come from temperature and pressure: data from a component that is not a CBS determines the output of one that is. "This component is not a cyber asset" and "this component's data is not a cyber concern" are entirely different statements — component count is not the measure of cyber relevance here. Data flow is.
What is not inherited: family ceiling versus instance description
All three typologies carry doctrine written in a bridge / navigation context, because the dominant members of those families are navigation equipment: TYP-B12 contains navigation radar, TYP-B13 rudder feedback units, TYP-B14 INS task stations and local steering positions. The actual components here are cargo tank instruments, and missing that makes the article wrong end to end, so the exclusion list is published rather than merely asserted.
Table 3 — Not inherited from family doctrine
| Present in family doctrine, not applied here | Reason |
|---|---|
| The whole body of navigation radar performance standards (CCRP, CPA/TCPA, target swap, gain and anti-clutter, bidirectional alert interfaces) | These are performance standards for navigation radar. A tank level radar is not within their scope |
| INS performance standard provisions (source selection, track control authority, task station redundancy) | The CCR gauging workstation is not an INS task station |
| Bridge alert management provisions | A bridge alert-management specification. Cargo alarms belong to the CCR and cargo alarm system. Only the structural logic — alarm prioritisation, aggregation, distribution of acknowledge authority — is inherited by analogy; no clause is cited |
| Steering-gear Category III determinations and steering data link provisions | A steering-gear case. Only the provision binding software updates to management of change is cited |
| Anything sourced from rudder feedback units, local steering positions, CPP bridge panels or towing winch emergency release stands | Not components of this system |
That last row is decisive. The system-level envelope carries A4 and A5 outbound and P4 in physical effect, and every one of those codes traces to components on that row — the local steering position, the CPP bridge panel, the towing winch. This system contains none of them, so the instance envelope is re-derived.
SYSTEM-LEVEL ENVELOPE (family ceiling, inherited)
outbound : A1 A2 A4 A5
inbound : A2 A3 A4 A6 A7 UNKNOWN
effect : P1 P2 P3 P4
|
remove codes sourced only from
components absent in SYS-006
|
INSTANCE ENVELOPE (this system)
outbound : A1 A2 <- observe and inform, nothing else
inbound : A2 A3 A6 A7 UNKNOWN <- where the security weight sits
effect : P1 P2 (P3 only under architecture C)
The reasoning carries across; the clauses do not — modelling authority by direction, the rule that sitting inside a closed loop raises physical effect rather than authority, and the shape in which outbound is mild while inbound carries the security weight.
7. Where the supply boundary falls
All three typologies have their supply boundary inside the parent package: gauge, sensors and workstation arrive as one instrumentation vendor package. That skew has three consequences.
First, asset visibility stops at the package. If the owner's inventory carries "tank gauging system, 1 set", the gauges, probes and workstation inside are never individually identified — the hard part when UR E26 requires the systems integrator to submit and maintain a vessel asset inventory and to keep a zones and conduit diagram current. VERIFIED Here B12 and B14 are separately listed; B13 is not.
Second, the update route probably sits outside owner IT control. Firmware, workstation software and the configuration tool all arrive through the vendor service channel. IACS UR E22 Rev.3 §4.2.8 requires software installation and updates to follow a management of change procedure agreed between the system supplier and the systems integrator, meeting §6 — the one software provision that genuinely bites here, though class verification depth varies by system category, with Category I not required to submit it at all and Category II and III subject to information submission on request. VERIFIED
Third — particular to this system — the rules require periodic vendor and surveyor access. Blur that into "remote access risk" and the analysis collapses; stated properly it is the regulated window through which inbound authority arrives.
| Legitimate access window | Basis | Inbound authority obtained |
|---|---|---|
| Type approval and class approval | Approval regime for gauging devices (OIML R 85 sets metrological requirements; shipboard application runs through type approval) | A7 — fixing the approved software version |
| Sensor location verification before commissioning | IGC 13.3.5 | A3 — datum and threshold setting |
| First full loading test after delivery, and after every drydocking | IGC 13.3.5 | A3 — alarm threshold confirmation and adjustment |
| Alarm functional test before cargo operations | IGC 13.3.6, 18.6.2 / IBC 15.19.4 | A3 — alarm state manipulation (test actuation) |
| Metrological verification, calibration and table update | Custody measurement practice | A3 — calibration tables and correction parameters |
That table is the conclusion. Inbound authority here is not an exceptional event; it is a schedule the rules require, so "block the access" is not an available control. The available control is to make the access leave a record of what was approved, what changed, and whether it can be reverted.
8. Architecture patterns A, B and C
Real topology varies by ship, and one explicitly undetermined item lands here: whether installations exist in which the gauge value enters an automatic control loop for cargo valves and pumps. With no settled answer, three patterns are contrasted rather than one asserted.
PATTERN A — Standalone indication
Radar gauge -> Local indicator + CCR workstation -> Cargo officer
(alarm annunciation separate; no upward data path beyond display)
PATTERN B — Online / integrated
Radar gauge -> Gauging bus -> CCR workstation -> Loading computer
|
+-> Custody transfer record
+-> Ship-shore data link (terminal, owner reporting)
PATTERN C — Control-integrated
Radar gauge -> Gauging bus -> Cargo control system -> Automatic loading sequence
| |
| Valve / pump commands
+-> ESD logic input
Table 4 — Pattern comparison
| A. Standalone | B. Online / integrated | C. Control-integrated | |
|---|---|---|---|
| Gauge outbound authority | A2 | A2 | A2 (unchanged) |
| Data consumers | People | People + computation + shore | People + automatic control logic |
| Physical effect ceiling | P1 | P1 – P2 | P3 (conditional) |
| Commercial path exposure | Local | Custody data leaves the ship | As B |
| Coupling to the safety path | None (independence preserved) | Display layer may be shared | Coupled through the ESD input |
| New attack surface | Local access, service tool | Ship–shore conduit, loading computer | Control logic, sequence parameters |
| Difficulty of satisfying independence | Low | Medium | High — common cause becomes real |
Note the first row. In none of the three patterns does the gauge's outbound authority move off A2. What changes is what receives the information, and physical effect rises accordingly: same equipment, same authority, different physical result.
Part III — Authority and physical effect
9. What information and commands flow
Split what moves through this system into information and commands, and an asymmetry appears.
Table 5 — Information versus command
| Class | Item | Direction | Character |
|---|---|---|---|
| Information | Level / ullage | Gauge -> workstation, loading computer | Continuous. Primary input to both paths |
| Information | Tank temperature profile | Probes -> gauge -> upward | Correction input. Makes mass |
| Information | Tank pressure | Transmitter -> gauge -> upward | Correction input plus safety monitoring |
| Information | Computed volume and mass | Gauge, workstation -> loading computer, documents | Derived value. The output of the computation chain |
| Information | High-level alarm state | Gauge, alarm system -> annunciation | Discrete state. Trigger of the safety path |
| Information | Equipment health and fault state | Gauge -> upward | Basis for trusting the rest |
| Command | Calibration parameters (zero, span, datum offset) | Service tool -> gauge | A3. Changes the top of the chain |
| Command | Tank calibration and correction tables | Service tool, workstation -> gauge, loading computer | A3. Changes the whole commercial path |
| Command | Alarm threshold setting | Service tool, engineering access -> alarm system | A3. Moves the firing point of the safety path |
| Command | Alarm acknowledge / silence | Operator interface -> alarm system | A3. Changes what a person perceives |
| Command | Firmware and software replacement | Vendor channel -> gauge, workstation | A7. Persistent authority |
| Command | Account and privilege management | Vendor, ship administrator -> workstation | A6. Not established — carried as UNKNOWN |
In one sentence: everything going out is information, and commands exist only on the way in. Most inbound commands are not real-time control but configuration (A3) and executable replacement (A7) — which is why A3 and A7 can matter more than A4 and A5 here. They outlive the interaction and act on every measurement that follows.
10. What authority each connection carries
Table 6 — Authority matrix (source × destination)
| Source -> Destination | Observe (A1) | Provide info (A2) | Configure (A3) | Command (A4) | Control (A5) | Administer (A6) | Update exec (A7) |
|---|---|---|---|---|---|---|---|
| Radar gauge -> CCR workstation | YES | YES | NO | NO | NO | NO | NO |
| Radar gauge -> loading computer / custody record | YES | YES | NO | NO | NO | NO | NO |
| Radar gauge -> alarm annunciation | NO | YES | NO | NO | NO | NO | NO |
| Temperature / pressure sensors -> radar gauge | NO | YES | NO | NO | NO | NO | NO |
| CCR workstation -> gauge and sensor layer | YES | NO | CONDITIONAL | NO | NO | NO | NO |
| CCR workstation -> cargo officer | NO | YES | NO | NO | NO | NO | NO |
| Service tool -> radar gauge | NO | NO | YES | NO | NO | UNKNOWN | YES |
| Service tool -> CCR workstation | NO | NO | YES | NO | NO | YES | YES |
| Operator interface -> alarm system | NO | NO | YES (ack / silence) | NO | NO | NO | NO |
| Other node on the gauging network -> gauge | NO | YES | UNKNOWN | NO | NO | NO | NO |
| Gauge -> cargo valves and pumps | NO | NO | NO | NO (even under pattern C) | NO | NO | NO |
The last row is bold for a reason. Even under pattern C the gauge does not command the valve — it supplies a value, and the cargo control system that receives it issues the command.
11. Can the system affect the physical process
P1 INDIRECT_DECISION_EFFECT is the baseline: the level governs the cargo officer's judgement, and that judgement becomes valve movement and pump orders, with a whole person standing between the equipment and the physical result. P2 OPERATIONAL_STATE_EFFECT arises where the value governs operational state — loading rate, topping-up timing, whether cargo work continues — and at alarm state transition. P3 holds under architecture C only: the gauge owns no actuator, but where the level feeds an automatic loading sequence or ESD logic, its output determines the output of a controller that moves one. Since it is unresolved whether such installations exist, it is conditional only. P4 is not assigned — there is no actuator here, and the P4 in the system envelope came from the siblings removed in section 6. Nor is P5.
12. Where the human stands
For one instrument, the human gate sits in three different places.
| Path | Human gate | Basis | Implication |
|---|---|---|---|
| Commercial (quantity determination) | EXECUTION | Cargo officer and surveyor read, compute and sign. The whole act is human | The only place an error can be caught. But people do not verify an indication that looks plausible |
| Monitoring (CCR display) | REVIEW | The watchkeeper reviews the picture the workstation builds and intervenes if needed | Room to intervene exists; the duty to intervene only triggers if something is visibly wrong |
| Safety (overfill shutdown) | NONE | IGC 13.3.2 — an independent sensor actuates the shutdown valve automatically | By design there is no person here. That is deliberate: human reaction time is slower than the physical limit |
The third row is the safety philosophy of this system. Removing the human is not a defect; it is the requirement — the time before a tank overflows can be shorter than a person's perceive-decide-act loop.
But the rules also provide the means to undo the removal. IGC Code 13.3.7's override device must preclude inadvertent operation, and while engaged there must be continuous visual indication in the control station and on the bridge. VERIFIED Ask why both locations and the character of the provision appears: an override removes a deliberately designed gate, and that state must not be concealable. It requires, in effect, that bypassing a safety function be possible but never invisible — precisely what modern OT security demands of bypass management, imposed without the vocabulary.
13. Authority escalation and propagation: the two paths
In a system whose entire outbound authority is A2, the risk lies not in the magnitude of the authority but in the shape of the propagation. Set the two paths side by side and they prove to be opposites.
Path 1 — commercial propagation
[A2] Level value
|
Tank calibration table -> Gross volume
|
Trim/list + temperature + pressure + density -> MASS
|
Cargo officer + surveyor read and sign <- HUMAN GATE: EXECUTION
|
Bill of Lading quantity
|
Invoice / cargo claim / demurrage / arbitration
|
CONSEQUENCE: financial, contractual, reputational
timescale = weeks to years
error hides INSIDE normal tolerance
This path is slow and it conceals: human gates and a paper trail make it auditable, and for exactly that reason nobody objects while the error sits inside normal tolerance. If the indication runs low by less than the ordinary spread of measurement, no alarm fires, nothing on the screen looks wrong, and the signatures are given in the normal way.
The one magnitude this article will attach to that structure is a measured one, from a real investigation rather than an illustration. At Buckeye Tank 228 the tank side gauge read approximately eighteen inches below the actual level, and that bias was not recognised as an error by anyone until the failure investigation established it. VERIFIED Eighteen inches of standing, undetected discrepancy in a gauging and alarm system that was reporting no fault is the scale of thing this path is capable of hiding. Beyond that measured case the article deliberately puts no percentage and no monetary figure on it, because no published basis exists for a shipboard bias rate, and inventing one would put a number where the evidence has none. The claim here is about character, not degree. A bias that stays below the alarm threshold is never self-reported by the system; detection comes only from comparison against an independent measurement — shore figures, a draught survey — and that comparison is easily rebutted as a "normal measurement difference".
Path 2 — safety propagation
[A2] Level value
|
Threshold comparison (high-level alarm) -- IGC 13.3.1: independent of other indicators
|
Alarm annunciation -> operator awareness
|
| (parallel, and by rule SEPARATE:)
|
INDEPENDENT sensor -- IGC 13.3.2 -> Automatic shutdown valve <- HUMAN GATE: NONE
| [A0 + P4]
|
+-----+-----------------------------+
| |
SUPPRESSED FALSELY TRIGGERED
| |
Tank overfill Valve closes at full loading rate
| |
Cargo on deck / overboard Surge pressure in loading line
Vapour release, fire risk -> IBC 15.19.8 names exactly this limit
| |
CONSEQUENCE: pollution, CONSEQUENCE: line/manifold rupture,
fire, personnel exposure release at the transfer point
timescale = seconds to minutes timescale = seconds
This path is fast and dangerous in both directions: suppress the safety system and the protection is gone; fire it and the protection itself becomes the weapon. The second is underrated, and the rules acknowledge the physics explicitly. IGC Code 13.3.3 requires alternative means such as loading rate limitation where valve closure would create a surge risk, and IBC Code 15.19.8 requires the loading rate to be set against residual ullage volume, shutdown time, and the design pressure of the pipeline, with 15.19.7 requiring the shutdown to be sequential. VERIFIED The rules already know a shutdown can break a pipe — so a false trip attacks precisely the limit the rulebook has had to calculate.
The two paths contrasted
Table 7 — Authority–effect matrix
| Interaction | Authority | Physical effect | Human gate | Security significance |
|---|---|---|---|---|
| Gauge -> workstation (level display) | out A2 | P1 | REVIEW | Source of situational awareness. Distort it and every downstream judgement is distorted |
| Gauge -> loading computer (volume, mass) | out A2 | P1 | EXECUTION | The commercial path proper. Error hides inside tolerance |
| Temperature / pressure sensors -> gauge | out A2 | P1 | NONE | A non-CBS component determines mass |
| Gauge -> alarm system (threshold exceeded) | out A2 | P2 | REVIEW | The awareness layer of the safety path |
| Independent sensor -> automatic shutdown valve | out A2 | P2 | NONE | IGC 13.3.2. A chain outside this system that shares its consequences |
| Automatic shutdown valve -> cargo flow | A0 | P4 | NONE | No authority, direct physical control. The textbook asymmetry |
| Service tool -> gauge (calibration, tables) | in A3, A7 | P1 (persistent) | AUTHORIZATION (procedural) | The highest real authority. Acts on every subsequent measurement |
| Service tool -> alarm threshold | in A3 | P2 -> P4 (indirect) | AUTHORIZATION (procedural) | Moves the firing point of the safety path |
| Operator -> alarm acknowledge / silence | in A3 | P2 | EXECUTION | Defeats the awareness layer. Indistinguishable from normal operation |
| Gauge -> automatic loading sequence (pattern C) | out A2 | P3 | NONE | Architecture C only. Unresolved |
| Vendor channel -> gauge, workstation (firmware) | in A7 | P1 – P3 (persistent) | AUTHORIZATION (procedural) | Subject to UR E22 §4.2.8 management of change |
Read twice the monotony of the out column against the variety of the in column. Outbound is A2 throughout and effect stays at P1–P2; inbound carries A3, A6 and A7, its effects persist, and its human gate is a procedural AUTHORIZATION that is not technically enforced. A sensor holds no CONTROL authority. Make it lie and physical results still emerge, through people, through contracts and through automatic logic — propagation without escalation.
Part IV — Uncertainty and security
14. Trust boundaries and dependencies
A trust boundary is not where a firewall is; it is where administrative ownership, exposure, privilege, physical access or vendor control changes. Five here.
+--------------------------------------------------------------+
| TANK (physical, hazardous area) |
| Radar antenna -- temperature probes -- pressure tx |
+----------------------------+---------------------------------+
| (1) HAZARDOUS-AREA BOUNDARY
| physical access controlled by
| tank entry permit, not by IT
+----------------------------v---------------------------------+
| VENDOR PACKAGE (maker supply) |
| Gauge electronics -- gauging bus -- CCR workstation |
| |
| (2) SUPPLY BOUNDARY : firmware, parameters, service tool |
| owner IT control ends here |
| (3) METROLOGICAL SEAL : calibration parameters under |
| verification regime, not under IT change control |
+----------------------------+---------------------------------+
|
+----------------------------v---------------------------------+
| SHIP OT (cargo control, loading computer, alarm system) |
| |
| (4) INDEPENDENCE BOUNDARY -- IGC 13.3.1 / IBC 13.1.2 |
| gauging || high-level alarm || overflow control |
| Rule-mandated separation. NOT a network boundary. |
+----------------------------+---------------------------------+
| (5) SHIP-SHORE CONDUIT
| custody transfer data, terminal
| ESD link, owner reporting
+----------------------------v---------------------------------+
| SHORE (terminal, charterer, owner office) |
+--------------------------------------------------------------+
(1) The hazardous-area boundary. Antenna and probes sit on the cargo tank top, and reaching them requires a work permit — a safety management system, not an IT control. The layer is well protected physically and entirely unobserved in IT terms. (2) The supply boundary, covered in section 7, is where firmware, parameters and the service tool live.
(3) The metrological seal boundary is particular to this system. Calibration parameters on a custody-transfer instrument sit under a verification regime, and changing them is a metrological procedure — but that procedure is a different system from IT change control, and the two do not know about each other. Whether the seal is broken is checked by an inspector; whether a parameter changed may be checked by nobody.
(4) The independence boundary — the most important one here. IGC 13.3.1 requires the high-level alarm to operate independently of the other level indicators, IBC 13.1.2 requires the gauging device to be independent of the 15.19 arrangements, and IBC 15.19.5 requires the alarm to be independent of both. VERIFIED This is not a network boundary: the rules require separation of sensor, wiring, logic and in practice power, none of it expressed as a firewall or a segment. Integration erodes it always the same way — share the display, the network, the power, the service tool. Each is a defensible decision; together they are a common cause.
(5) The ship–shore conduit — custody data leaving, a terminal ESD link arriving, an owner reporting path opening. Real from architecture B upward.
15. What happens when the system fails
Before any cyber consideration, this system simply breaks, and knowing those shapes is what lets section 16 rest on evidence.
(a) Antenna fouling, surface turbulence and foam disturb the reflecting surface and the level reads wrong stably — the worst form, because a jumping value invites suspicion and a steadily wrong one does not. (b) Temperature probe drift gives the volume-to-mass conversion an error invisible in the level indication, surfacing later as a custody dispute. (c) Gauging network freeze stops the indication updating while the level keeps rising, and unless the display says so, people read it as normal. (d) Alarm flood buries the alarm that matters. (e) Failure of the high-level alarm itself — sticking, open circuit, mis-set threshold — has no symptom when it occurs and is revealed only when it is needed.
Evidence — what shore incidents show
Three cases show these are not theoretical. All are shore storage or terminal incidents, cited as evidence of physical behaviour and failure structure, never as shipboard requirements.
Buncefield (2005, United Kingdom). The level gauge on Tank 912 stuck — the investigation records it sticking fourteen times in the months before the incident — while the independent high-level switch was also inoperative, so the tank was filled blind and a very large quantity of petrol went over the top. VERIFIED
What matters most is why the second layer was dead. That switch functions only with a padlock retaining its test lever in the working position, and the padlock was absent — not a component failure but a failure to transmit information. The supplier never communicated the padlock's functional significance to the installer, the maintenance contractor or the site operator, and because the manufacturer's documentation called it a 'security' item, many users read it as an anti-tamper accessory and left it off. VERIFIED The effectiveness of a safety layer rested on one piece of knowledge that never crossed the vendor boundary — and the common cause that took both layers down at once was neither wiring nor network but a gap in supplier knowledge.
Buckeye Tank 228 overfill (United States, 17 June 2012, Macungie Station, Emmaus, Pennsylvania). The PHMSA failure investigation attributed the overfill to inaccurate calibration of the level gauging and alarm system, the tank side gauge reading approximately eighteen inches below the actual level. VERIFIED Not a cyber incident, but decisive: a wrong calibration value is never reported as a fault anywhere in the gauging system — it is indistinguishable from correct operation. Eighteen inches is not a subtle number, and it still produced no fault indication anywhere inside the measurement chain, which is why this figure and not an invented percentage is the one this article uses whenever it needs a scale for undetected bias.
Here, though, the independent layer was alive: the control room operator received a "Safe Fill" indication and an "Independent Hi-Hi Alarm", after which flow was diverted. VERIFIED What catches a calibration bias is never the same system's self-diagnosis but an independent second layer — and Buncefield shows what happens when that layer is dead.
MT Marina Aman (chemical tanker). As reported, a fault in the 4S pump's remote control assembly made it run without a command, transferring cargo into 2S unnoticed while the remote gauging on 2S was malfunctioning and an early symptom — abnormal pump noise — went unreported. A single academic case study, attributed and not asserted. TYPICAL
16. Attack surface and credible threat scenarios
Table 8 — Attack surface
| Surface | What it actually is here | Authority obtainable | Evidence |
|---|---|---|---|
| Local (physical access) | Tank-top antenna and probes, CCR workstation console | A3 (console), physical disturbance | TYPICAL |
| Removable media | Workstation software and settings, calibration table files | A3, A7 | TYPICAL |
| Connected OT | Gauging bus, loading computer integration, cargo control system (patterns B and C) | A2 forgery, A3 UNKNOWN | INFERRED |
| Ship–shore | Custody data transmission, terminal ESD link, owner reporting (pattern B upward) | Data integrity | INFERRED |
| Vendor | Service tool, calibration and verification visits, remote diagnostics where present | A3, A6, A7 | TYPICAL |
| Supply chain | Gauge firmware, workstation OS and application, calibration table software | A7 | TYPICAL |
Three scenarios follow, each pushed to the end of its chain along a different path.
Scenario 1 — calibration and table tampering (commercial path)
Entry interaction : vendor service tool session on the radar gauge
(scheduled calibration / verification visit)
Initial authority : A3 CONFIGURE (legitimate, rule-scheduled)
Mechanism : reference-plane offset or tank calibration table
altered by a small constant; well inside plausibility
Authority gained : persistent A3 over every subsequent measurement
Affected interaction: gauge -> loading computer -> custody transfer record
Physical effect : P1 (indirect decision effect) - no alarm, no fault
Consequence : systematic quantity bias on every cargo.
Detected only by independent measurement
(shore figures, draught survey) - and disputed as
"normal measurement difference" when it is
The core of it is that no alarm sounds: the bias sits inside the normal measurement range rather than near a threshold, so nothing anywhere in the gauging system reports a fault. Buckeye Tank 228 is the non-cyber demonstration of exactly that — an inaccurate calibration held a persistent gap of approximately eighteen inches between actual and indicated level, and nothing inside the measurement chain recognised it as an error until the investigation did. VERIFIED An attacker who alters a calibration parameter is producing the same signature by intent that a bad calibration produced by accident. Defending is hard because it is indistinguishable from routine maintenance, and section 7's table shows this access is a schedule the rules require. It cannot be blocked, so the only answer is to record the changes and compare them.
Scenario 2 — alarm threshold and alarm state manipulation (safety path, suppression)
Entry interaction : engineering access to the alarm setting
(service tool, or workstation engineering level)
Initial authority : A3 CONFIGURE
Mechanism : high-level alarm threshold raised, or alarm state
held acknowledged / silenced
Authority gained : A3 over the alarm layer only
Affected interaction: gauge -> alarm annunciation -> operator awareness
Physical effect : P2 (operational state effect) - the ship's alarm
state no longer reflects the tank
---- and here the architecture decides the outcome ----
If independence is INTACT (IGC 13.3.1 / IBC 15.19.5 honoured):
the independent overfill sensor still closes the valve.
Consequence: degraded warning, contained by the last layer.
If independence is ERODED (shared HMI / shared network / shared power
/ shared service tool):
the same access reaches BOTH layers.
Consequence: tank overfill with no warning and no shutdown
= the Buncefield structure, reached by a different route
This is why the independence requirement has to be promoted to a cyber control. Built to block a common cause of mechanical failure, it works unchanged in cyber terms as a control preventing a single access from reaching two layers.
Scenario 3 — false trip (safety path, actuation)
Entry interaction : injection of a false high-high level value, or
forced trip of the overfill logic input
Initial authority : A2 PROVIDE_INFORMATION (falsified) - or A3 on the
threshold, driving the same result
Mechanism : the safety system is not disabled. It is FIRED.
Authority gained : none beyond A2/A3 - the escalation is by design
Affected interaction: overfill logic -> automatic shutdown valve [A0 + P4]
Physical effect : P4, produced by the valve, at full loading rate
Consequence : surge pressure in the loading line.
IBC 15.19.8 requires loading rate to be set against
ullage volume, shutdown time and PIPELINE DESIGN
PRESSURE - i.e. the rule already recognises this
as a physical limit.
Outcome: line or manifold damage, release at the
transfer point, with the safety system's own log
showing a correct trip.
The third is the most counter-intuitive: an attack that does not disable the safety system but fires it, after which any investigation records the safety system as having operated correctly. The evidence is not in the safety system but in its input. Generic threat lists — phishing, ransomware — are absent because they explain nothing here; all three scenarios derive only from the inbound authority this system has (A3, A7) and the information it emits (A2).
17. Security architecture, derived from the threats and only then mapped to standards
Controls come out of the three scenarios, not from a list to which standards are then attached.
(1) Promote independence verification to a cyber control — from scenario 2. The separation required by IGC 13.3.1 and IBC 13.1.2 and 15.19.5 is already a survey item, so add the cyber questions to it. Do the gauging system and the high-level alarm share a display, a network segment, a power supply, a service tool, an account scheme? One "yes" among those five and a common cause remains even where the rule is satisfied. This is the first control here, and the only one that requires buying no equipment.
(2) Put change history and comparison around calibration parameters and tables — from scenario 1. The access cannot be blocked (section 7), so the control must be observability of change: periodic snapshots of parameters, offsets, tables and density; before-and-after comparison across service visits; and simultaneous checking of seal state and parameter state, bridging boundary 3 of section 14.
(3) Name the tank calibration table as an object of version control — from scenario 1. It is not executable code, but it determines the final number. UR E22 Rev.3 §4.2.8 binds software installation and updates to the §6 management of change procedure, and pulling the calibration and correction tables explicitly inside that scope is the practical measure — otherwise they stay outside control on the grounds that they are not software.
(4) Separate the custody data path from the control path — from architectures B and C. Custody data must leave the ship; the control path must not. Where both use one link, a hole opened for commercial convenience becomes exposure of the control path — which is where UR E26's vessel asset inventory and zones and conduit diagram requirements bite.
(5) Put the false trip explicitly in the threat model — from scenario 3. Risk assessments generally cover only "fails to act", but "acts when it must not" produces a distinct physical consequence, limited by the pipeline design pressure IBC 15.19.8 already requires in the calculation. Without that line item scenario 3 is invisible.
(6) Repurpose the testing regime the rules already require as assurance. IGC 13.3.5, 13.3.6 and 18.6.2 and IBC 15.19.4 put these tests already on the schedule, already recorded, already surveyed — so adding "does the threshold match the approved value" and "do the parameters match the last record" is two line items on an existing procedure, not a new one.
(7) Treat IGC 13.3.7 override state as a cyber observable — from section 12. The provision already requires continuous visual indication while an override is engaged; treated as bypass management evidence, rule compliance and OT security collapse into one record.
Standards mapping
| Control | Clause basis |
|---|---|
| Independence verification | IGC 13.3.1 (high-level alarm independent of other indicators), IGC 13.3.2 (automatic shutdown by independent sensor), IBC 13.1.2 (gauging independent of 15.19 arrangements), IBC 15.19.5 (high-level alarm independent of both) |
| Testing and verification regime | IGC 13.3.5, 13.3.6, 18.6.2 / IBC 15.19.4 |
| Override observability | IGC 13.3.7 |
| Loading rate against physical limits | IGC 13.3.3 (rate limitation where surge risk exists), IBC 15.19.7 (sequential shutdown), IBC 15.19.8 (factors in determining loading rate) |
| Software and data change control | IACS UR E22 Rev.3 §4.2.8 (initial installation and updates under a management of change procedure agreed between system supplier and systems integrator, meeting §6) — class verification depth varies by system category |
| Asset inventory and zoning | IACS UR E26 Rev.1 — vessel asset inventory submitted and maintained by the systems integrator, zones and conduit diagram kept current, security zones isolable without affecting primary function |
| Cyber resilience of equipment | IACS UR E27 Rev.1 |
| Gauging accuracy requirements | OIML R 85-1 & 2 (automatic level gauges for stationary storage tanks; shipboard application attributed to type approval and class approval routes) |
| Gauging network security | Where, and only where, the shipboard measurement network is of the IEC 61162 family, the absence of talker authentication in IEC 61162-450 and the IEC 61162-460 extensions apply. Whether this system's gauging bus is of that family is unconfirmed, so this is recorded conditionally only |
The last row is where the honesty sits: naming a network security standard while the gauging bus is unidentified would be an unfounded compliance claim.
18. Open questions, takeaways and references
Twelve questions to ask first on a real project
| # | Question | What it settles |
|---|---|---|
| 1 | Is the vessel architecture A, B or C — does the gauge value enter an automatic loading sequence or ESD logic? | Whether physical effect is P1–P2 or P3 |
| 2 | Do the gauging system and the high-level alarm share a display, on the same workstation? | Independence, erosion route 1 |
| 3 | Do they share a network segment? | Independence, erosion route 2 |
| 4 | Do they share a power supply, and how do the emergency arrangements divide? | Independence, erosion route 3 |
| 5 | Are both reached by the same service tool and the same accounts? | Independence, erosion route 4 — and scenario 2's blast radius |
| 6 | What is the gauging bus actually running — 4–20 mA / HART, Modbus, IEC 61162 family, vendor-proprietary? | Whether any network security standard legitimately applies |
| 7 | Where is the tank calibration table stored and who updates it? Is that update inside the management of change procedure? | Whether control (3) exists or is a gap |
| 8 | Do the calibration parameters have a lock level, and is the delivered default ever changed? | Scenario 1's difficulty |
| 9 | What is the firmware and software update route, and is there signature or hash verification on the media? | The A7 path |
| 10 | Is there a vendor remote diagnostic gateway, and in which zone does it sit? | Whether inbound authority is continuous or episodic |
| 11 | Is the IGC 13.3.7 override state recorded, or only displayed? | Whether bypass evidence exists |
| 12 | Do the temperature and pressure sensors exist as individual inventory items, or are they absorbed into the gauge? | Whether the non-CBS data path is visible at all |
Open questions
- Whether installations exist in which the gauge value enters an automatic control loop for cargo valves and pumps. If they do, that instance is P3 and architecture C is real.
- What the gauging network interface actually is; across the family it is mostly 'Likely', so any statement resting on it cannot exceed INFERRED.
- Whether another node on the bus can genuinely change the gauge's configuration (A3), or only deceive the receiving side.
- Whether workstation account and privilege management (A6) happens outside procedure.
- Whether the sensors land as analogue inputs or on a digital bus, which sets scenario 1's attack path.
Engineering takeaways
FINAL CHAIN
IBC 13.1.1 gauging ladder / IGC 13.2.2 (why the system exists:
| closure before accuracy)
Distance -> Level -> Volume -> Mass (level is COMPUTED, not measured)
|
3 typologies, 4 components, 2 CBS (what it is made of)
|
outbound A2 only . inbound A3 / A6 / A7 (instance envelope, re-derived)
|
ONE number, TWO propagation paths (the shape of the risk)
|
+----------------------+----------------------+
| | |
Commercial: Safety: Safety, inverted:
slow, human-gated, fast, NO human gate, fire the system
error hides inside suppression = overfill instead of stopping it
tolerance (Buncefield structure) -> surge (IBC 15.19.8)
| | |
+----------------------+----------------------+
|
IGC 13.3.1 / IBC 13.1.2 / 15.19.5 independence
= a common-cause control written before "cyber"
|
Verify independence as a CYBER control, not only as a rule check
- Outbound A2 does not mean low risk. The risk is in the shape of the propagation, and this system feeds a contract and an automatic shutdown from the same number.
- The independence requirements of IGC 13.3.1 and IBC 13.1.2 and 15.19.5 are cyber security controls, simply not written in that vocabulary. Integration erodes the wall easily, and the erosion is a rule violation and a cyber exposure at once.
- What needs protecting is the computation chain and its data, not one executable — calibration table, offsets, correction tables, density, thresholds.
- Data from a component that is not a CBS determines the output of one that is. Component count is not a measure of cyber relevance; data flow is.
- Attacks on a safety system run in both directions. Suppress it and the tank overflows; fire it and the pipe breaks.
- A typology envelope is a ceiling for a family, not a description of an instance. Copy one across unexamined and you design controls for actuators that do not exist.
Sources
- IMO, IGC Code — 13.2.1–13.2.4 (gauging device categories; the 1.5 mm aperture principle and its excess flow valve exception; tubular gauge glasses not to be fitted, with the robust-type exception subject to Administration approval), 13.3.1–13.3.7, 18.6.2. Clause text compared against the source. VERIFIED
- IMO, IBC Code — 13.1.1–13.1.4, 15.19.2–15.19.8, chapter 17 column j. Clause numbers and intent confirmed against the source. VERIFIED
- IACS, UR E22 Rev.3 (2023) §4.2.8 — initial installation and subsequent updates under a management of change procedure agreed between system supplier and systems integrator, meeting §6; class verification depth varies by system category. VERIFIED
- IACS, UR E26 Rev.1 (2023) — vessel asset inventory, zones and conduit diagram, security zone isolability. Cited by requirement name; the clause numbers used in an earlier draft could not be confirmed and were removed. VERIFIED (requirements) / clause numbering withdrawn
- IACS, UR E27 Rev.1 (2023) — cyber resilience of onboard systems and equipment. Cited by scope, without clause numbering. VERIFIED
- OIML, R 85-1 & 2, Edition 2008 — metrological and technical requirements, metrological controls and tests for automatic level gauges. Scope is stationary storage tanks of the shapes defined in OIML R 71 (vertical cylindrical; spherical, spheroid and bullet pressure storage tanks; refrigerated and heated included); stated metrological purpose is application in conjunction with tank calibration tables. Shipboard application runs through type approval and class approval, not through the Recommendation itself. VERIFIED (scope and purpose) / TYPICAL (shipboard application)
- IEC 61162-450 / -460 — cited conditionally only; whether this system's gauging bus belongs to that family is unconfirmed. UNKNOWN
- Buncefield investigation reporting (UK, 2005; IChemE / COMAH Competent Authority) — fourteen gauge stickings, the absent padlock retaining the test lever, and the supplier's failure to communicate its significance. A shore incident. VERIFIED
- US PHMSA failure investigation, Buckeye Tank 228 overfill (Macungie Station, Emmaus PA, 17 June 2012) — inaccurate calibration of the level gauging and alarm system; tank side gauge reading approximately eighteen inches low; the independent hi-hi alarm did annunciate and flow was diverted. A shore incident. VERIFIED
- MT Marina Aman overflow case study (Jurnal Bahari dan Teknologi) — single-source, attributed. TYPICAL
Article classification
A typology-based system analysis, not a vendor document and not the documentation of any particular ship. All three typologies carry evidence grade TYPICAL; architectures A, B and C are conceptual models. Because the typology doctrine was written in a bridge / navigation context, no navigation radar, INS, bridge alert management or steering-gear provision is cited anywhere here — what was inherited is the reasoning only (table 3, section 6). Buncefield and Buckeye Tank 228 are shore incidents, never shipboard requirements. No vendor name, product name or accuracy figure appears, because the basis for those exists only in vendor material.