[System Study_002] The Loading Computer: Architecture, Interaction & Authority in Ship Loading Systems

A ship's Loading Computer is usually described as "the computer that calculates cargo quantity and stability." As a functional summary that is not wrong. From a systems-engineering and cybersecurity standpoint, it is not enough.

The Loading Computer applies the vessel's cargo, ballast, fuel and other weight state to a ship-specific calculation model in order to assess stability and structural strength. Some installations run as a standalone calculation tool; others are connected to tank gauging or draft measurement; and in certain implementations the system may interact with ballast control.

So the cybersecurity character of a Loading Computer is not settled by the question "is it a PC or an OT device?" The more useful question is:

What does the Loading Computer interact with, what authority can it exercise through those connections, and how far can that authority reach into the vessel's physical state?

This article first analyses the Loading Computer as an engineered system, and only then derives cybersecurity requirements from that analysis.

1. Why the Loading Computer exists

A vessel's loading condition is not fixed. Cargo is loaded and discharged, ballast water is moved, and fuel and fresh water are consumed. Depending on ship type, the position and weight of cargo tanks, containers, bulk cargo or vehicles also change.

These changes do not merely alter the vessel's total weight. When the distribution of weight changes, so can the ship's draft, trim, heel, centre of gravity, intact and damage stability state, shear force and bending moment.

The operator therefore has to be able to judge whether the current or planned loading condition stays within approved stability and strength limits. That is the engineering problem the Loading Computer solves.

Cargo / Ballast / Consumables
             |
      Vessel Loading Model
             |
     Hydrostatic Calculation
             |
   Stability / Strength Analysis
             |
        Limit Verification
             |
       Operator Decision

It is more accurate to see the Loading Computer not as a "cargo PC" but as a calculation system that supports an engineering assessment of the vessel's condition.

2. What the system actually does

The concrete functions vary by ship type and product, but at the system level they decompose into a few core functions.

Loading condition definition. The system first has to represent the vessel's current or planned loading condition. Depending on the implementation, the input can include:

Input Category	Example
Cargo	Cargo weight, tank condition, container loading
Ballast	Ballast tank quantity
Consumables	Fuel, fresh water
Vessel condition	Draft, trim, list
Other deadweight	Stores and other weights

The important point is that these values are not simply database information; they are operational data that represents the vessel's actual physical state inside a calculation model.

Hydrostatic and stability calculation. Using the loading condition and the vessel-specific model, the system computes hydrostatic and stability characteristics. Structural strength assessment. Depending on the vessel and software capability, it can evaluate longitudinal strength and compare shear force and bending moment against permissible limits. Limit verification. Results are compared with approved criteria and limits. Planning. The system does not only evaluate the present state — it can apply a proposed cargo or ballast operation and compute a future condition.

Current Condition
       |
Proposed Cargo / Ballast Change
       |
Predicted Loading Condition
       |
Stability / Strength Assessment
       |
Operational Decision

So the Loading Computer is less a measurement system than, fundamentally, a calculation and engineering decision-support system.

3. The most important asset is not the PC

When analysing a Loading Computer for cybersecurity, it is tempting to start from the PC, Windows and Ethernet. But what determines the trustworthiness of the calculation is much broader. Conceptually, the result is produced by a combination of elements:

Calculation Software
        +
Vessel-Specific Model
        +
Configuration / Limits
        +
Operational Input
        +
External Sensor Data
        |
   Engineering Result

The thing to protect is therefore not a single executable. It includes the calculation software, the vessel-specific model (geometry, compartments, tanks, hydrostatics), the configuration and limits used to judge results, the operational data (current cargo, ballast, fuel), and — where online integration exists — external data such as tank level and draft. If the integrity of any one of these is degraded, the calculated result can be wrong. The most dangerous case is not the system stopping; it is the system appearing to calculate normally while producing a wrong result.

4. The architecture is not singular

The name "Loading Computer" is the same, but the actual system architecture can differ substantially. For cybersecurity analysis, at minimum three forms should be distinguished. These are conceptual patterns; which one a real vessel uses — or which combination — must be confirmed from vendor documentation and vessel-specific network/interface information UNKNOWN.

Architecture A — Standalone calculation. The operator enters the required values and the system provides a result. With no online connection to other OT systems, the primary attack surface is relatively limited — physical access, user accounts, removable media, software installation, configuration modification and maintenance activity become the important paths.

      Officer
         |
   Manual Input
         |
 +-----------------+
 | Loading Computer|
 | Vessel Model    |
 | Calculation     |
 | User Interface  |
 +-----------------+
         |
   Calculation Result

Architecture B — Online monitoring. The Loading Computer is connected to tank gauging or draft measurement. It is no longer only an independent calculation system; it depends on operational information supplied by other systems.

Tank Gauging --------+
                     |
Draft Measurement ---+
                     |
              +--------------+
              |   Loading    |
              |   Computer   |
              +--------------+
                     |
             Engineering Result

Incorrect / Manipulated Sensor Data
               |
        Loading Computer
               |
      Correct Calculation on Incorrect Inputs
               |
          Misleading Result

The key point: the result can be distorted even without the Loading Computer being attacked directly.

Architecture C — Control-integrated. In some implementations, Loading Computer and ballast control functionality are integrated.

Tank / Draft Information
          |
   Loading Computer
          |
 Stability / Loading Logic
          |
 Ballast Control Interface
          |
 Ballast Control System
          |
     Pump / Valve
          |
 Physical Vessel State

Here the character of the system changes. In a standalone Loading Computer the primary result is information. In a control-integrated Loading Computer, a particular interaction may participate in a command path that leads to physical operation. So one of the most important questions when assessing a Loading Computer is: can the system only observe and calculate, or can it also cause the vessel's physical state to change?

5. To understand the system, look at the interaction — not the connection

The mere fact that an Ethernet cable exists between the Loading Computer and another device is not sufficient analysis. What matters more is what actually happens through that connection. Compare two connections:

Tank Gauging          Loading Computer
     |                       |
     v                       v
Loading Computer        Ballast Control
(supplies tank info)    (requests ballast operation)

Both may use Ethernet. But the engineering meaning is entirely different: the first is an interaction that provides tank information; the second is an interaction that requests a ballast operation. The unit of analysis must therefore be the interaction, not the interface:

Source -> Information / Command -> Destination
       -> Authority -> System Effect -> Physical Effect

6. Decomposing the main interactions

Assuming a representative Loading Computer architecture, the interactions can be laid out as below. The column that matters most is Authority.

7. Authority — what a connected system can actually do

Authority is not the same as a user account's permission. Here it means the kind of influence one system can exercise on another through an interaction.

• Observe — can read information but does not change target state.
• Provide Information — supplies information used in another system's judgement.
• Configure — can change parameters, limits or system configuration.
• Command — can request an operational action.
• Control — can directly or indirectly affect a physical process or actuator state.
• Administer — can change accounts, security settings or system-level configuration.
• Update Executable — can change software, firmware or executable logic.

The reason this distinction is needed is simple: connectivity and authority are not the same thing. An interaction can also carry more than one authority — a vendor engineering tool toward a controller may hold Observe + Configure + Administer + Update Executable at once. Do not collapse this into "remote access": remote access describes the connectivity mechanism; authority determines what the remote party can actually do.

8. Physical Effect — how far that authority reaches the vessel

After authority, analyse physical effect. The Loading Computer's interactions can be classified as: no physical effect (e.g. historical report export); indirect decision effect (information influences a human or automated decision); operational state effect (changes system mode, alarm or configuration state without directly actuating equipment); indirect physical control (causes physical action through another control system); and direct physical control (a controller commands an actuator directly).

Indirect decision effect
  Tank Gauging -> Loading Computer -> Officer -> Operational Decision

Indirect physical control
  Loading Computer -> Ballast Controller -> Pump / Valve

A tank gauging system does not directly control a ballast valve. But wrong tank information can produce a wrong Loading Computer result, which can lead to a wrong operator decision. Making this distinction is what lets you state precisely where the Loading Computer sits in the cyber-physical chain.

9. The human gate is part of the architecture

Compare two systems that achieve the same physical outcome:

Human-mediated
 Loading Computer -> Recommended Condition -> Officer -> Ballast Control -> Pump/Valve

Automated
 Loading Computer -> Ballast Control -> Pump/Valve

Although both end in a ballast operation, their security architecture differs considerably. The first can include human review, authorization and execution. In the second, a software interaction itself can lead to physical action. In industrial cybersecurity the human must not be treated as something outside the network — the human gate is also part of the control architecture.

10. Ship–shore transfer of the loading plan

A Loading Computer's operational workflow may add data exchange with a shore-side system — a shore-planned loading plan sent to the ship, or the actual condition/report sent back to shore. But an important qualification: ship–shore file transfer is not a universal, mandatory function of "the Loading Computer" as a system. It is a deployment-specific interaction that a particular vessel or operator may design using Fleet Mail, a file server, a cloud service or another mechanism. So the fact that a Loading Computer is connected to Fleet Mail must not be expressed as a generic Loading Computer architecture. A real assessment must confirm:

In particular, a loading plan and a software update must not be treated as the same file transfer. A loading plan is operational information; a software update can change executable behaviour. The authority itself is different.

11. A trust boundary is not a firewall location

When the Loading Computer connects to other systems, you have to find the points where trust assumptions change.

                  SHORE
                    |
             External Domain
--------------------+--------------------
                    |
          Ship Communication
                    v
             Loading Computer
                    |
--------------------+--------------------
                    |
               Ship OT
                    v
             Ballast Control

A trust boundary exists not because a firewall is present, but because conditions change: administrative ownership, network exposure, privilege, physical accessibility, operational criticality, vendor control and external connectivity. A firewall is just one of several mechanisms that enforce such a boundary.

12. What happens when the Loading Computer fails

Before looking at cyber threats, look at failure. Loss of availability — the Loading Computer cannot be used, limiting the ability to perform loading/stability/strength evaluation. Incorrect operational input — correct calculation on an incorrect vessel-model state yields a misleading result. Corrupted vessel model or limits — the trickier failure: the user enters correct values and the application runs normally, yet the calculation basis itself is wrong. Incorrect external data — in online integration, wrong upstream data affects the result. Loss of interface — required online data disappears or goes stale. Unauthorized command — in a control-integrated implementation, a command from the Loading Computer to a downstream control system could be manipulated.

Incorrect Cargo / Ballast Input
              |
       Correct Calculation
              |
   Incorrect Vessel Model State
              |
        Misleading Result

13. Where a cyber attack can begin — the attack surface

Only now do we look at the attack surface. Local access — operator workstation, physical access, maintenance access, service port. Removable media — USB, portable storage, maintenance media. Connected OT systems — tank gauging, draft measurement, ballast control, other vessel systems. Ship–shore connectivity — business IT, Fleet Mail, external network, cloud service, shore application (implementation-dependent). Vendor maintenance — service laptop, remote access, vendor gateway, software-update infrastructure. Software supply chain — application update, libraries, vendor package, vessel-model/configuration update.

14. Credible threat scenarios

Listing "malware", "hacking" or "DoS" is not sufficient. Scenarios have to be tied to the architecture.

Scenario 1 — Compromised removable media

External Computer -> Compromised USB -> Loading Computer
   -> Software / Configuration -> Engineering Result

The key consequence is not the PC infection itself, but whether the integrity of the calculation software, vessel model or operational data can be affected.

Scenario 2 — Manipulated tank data

Compromised Upstream System -> False Tank Data -> Loading Computer
   -> Valid-Looking Result -> Officer Decision

The attacker distorts the result through an upstream dependency without attacking the Loading Computer directly.

Scenario 3 — Manipulated shore loading plan

Compromised Shore System -> Manipulated Loading Plan
   -> Ship Communication -> Loading Computer -> Operator Decision

Here, more than simple encryption, source authenticity, file integrity, malware inspection, controlled import and operator validation matter.

Scenario 4 — Maintenance authority compromise

If a vendor maintenance interaction holds Observe + Configure + Administer + Update Executable, the meaning of a credential or maintenance-device compromise is far larger than a simple remote-connection compromise.

Vendor Access -> Administrative Authority
   -> Configuration / Software Change -> Loading Computer Behaviour
   -> Engineering Result

So when analysing remote access, confirm what authority the remote party actually gains rather than whether a VPN exists.

Scenario 5 — Control-path compromise

Unauthorized Access -> Loading Computer -> COMMAND Authority
   -> Ballast Control -> Pump / Valve -> Physical Vessel State

In this case Loading Computer cybersecurity expands from information-system protection into a cyber-physical control-integrity problem.

15. Security architecture must be derived from threats

The same security architecture cannot be applied to every system called a Loading Computer. It follows the order Architecture → Interaction → Authority → Failure/Threat → Security Requirement → Control.

16. What to check for IACS UR E26/E27

A Loading Computer's cyber-resilience assessment must not be decided by product name either; the actual shipboard implementation has to be confirmed first. The following are especially important, and the analysis is then mapped to the relevant UR E26/E27 requirements — the standard should not define the system, but connect the engineering analysis to assurance requirements VERIFIED (IACS UR E26/E27).

17. Questions to ask first in a real project

If you have to assess a Loading Computer, you can at least start from these questions. Without answers, the correct cyber architecture cannot be determined either.

1. Is the Loading Computer standalone or network-connected?
2. Which onboard systems is it physically connected to?
3. What is the purpose of each interaction?
4. What information or command crosses?
5. What is the direction?
6. Can the Loading Computer configure another system?
7. Can the Loading Computer send commands?
8. Can it change a physical process directly or indirectly?
9. Is human authorization required?
10. How are tank level and draft information entered?
11. How is the loading plan imported/exported?
12. Is USB used?
13. Is it connected to business IT?
14. Does it exchange data with shore?
15. Is email or Fleet Mail used?
16. Does a cloud service exist?
17. Does vendor remote access exist?
18. How are software and vessel model updated?
19. How is configuration backup managed?
20. How is an approved configuration recovered after failure or compromise?

18. Engineering takeaways

1. A Loading Computer is not just a PC. Software, vessel model, configuration, operational input and external data together produce the engineering result.
2. Same name, different architecture, different cyber criticality. Standalone ≠ online monitoring ≠ control-integrated.
3. Interaction matters more than connection. "It is connected by Ethernet" says less than "what crosses, and why?"
4. Authority can matter more than the interaction. Distinguish Observe / Provide Information / Configure / Command / Control / Administer / Update.
5. Trace the physical effect. Distinguish Information → Human Decision → Physical Action from Command → Controller → Actuator.
6. Cybersecurity is not the starting point. It is the consequence of understanding the engineered system correctly.

Ship Operation -> System Function -> Architecture -> Interaction
  -> Information / Command -> Authority -> Physical Effect
  -> Dependency / Trust -> Failure -> Threat
  -> Security Requirement -> Control

Open questions

The generic system name "Loading Computer" alone cannot settle the following. Analysing a specific vessel or product needs additional vendor documentation, system architecture, interface list and operational procedures UNKNOWN:

• Actual network topology and communication protocol
• Tank gauging integration and read/write capability
• Ballast-control integration
• Business IT / Fleet Mail / ship–shore / cloud connectivity
• Remote access and vendor maintenance authority
• Software update mechanism and onboard cybersecurity functions

---

Sources

• IACS — UR L5, Onboard Computers for Stability Calculations
• IACS — UR E26, Cyber Resilience of Ships
• IACS — UR E27, Cyber Resilience of On-board Systems and Equipment
• Kongsberg Maritime — loading computer with online interface and ballast integration examples
• NAPA — NAPA Loading Computer (loading, stability, strength, ship–shore integration)
• SARC — LOCOPIAS (loading condition, stability, longitudinal strength)

Article Classification. Maritime · Industrial Systems · Loading & Stability · OT Cybersecurity. Evidence profile: primary standards + vendor technical documentation + engineering inference. Scope: generic Loading Computer architecture; vendor- and vessel-specific implementations may differ.