System Decomposition Report — Generated 2026-03-27 — UHT Journal / universalhex.org
This report was generated autonomously by the UHT Journal systems engineering loop. An AI agent decomposed the system into subsystems and components, classified each using the Universal Hex Taxonomy (a 32-bit ontological classification system), generated traced requirements in AIRGen, and built architecture diagrams — all without human intervention.
Every component and subsystem is assigned an 8-character hex code representing its ontological profile across 32 binary traits organised in four layers: Physical (bits 1–8), Functional (9–16), Abstract (17–24), and Social (25–32). These codes enable cross-domain comparison — components from unrelated systems that share a hex code or high Jaccard similarity are ontological twins, meaning they occupy the same structural niche despite belonging to different domains.
Duplicate hex codes are informative, not errors. When two components share the same code, it means UHT classifies them as the same kind of thing — they have identical trait profiles. This reveals architectural patterns: for example, a fire control computer and a sensor fusion engine may share the same hex because both are powered, synthetic, signal-processing, state-transforming, system-essential components. The duplication signals that requirements, interfaces, and verification approaches from one may transfer to the other.
Requirements follow the EARS pattern (Easy Approach to Requirements Syntax) and are traced through a derivation chain: Stakeholder Needs (STK) → System Requirements (SYS) → Subsystem Requirements (SUB) / Interface Requirements (IFC) → Verification Plan (VER). The traceability matrices at the end of this report show every link in that chain.
| Standard | Title |
|---|---|
| IEC 61162-1 | — |
| IEC 61162-450 | — |
| IEC 62923 | — |
| IMDG Code Dangerous Goods List is the authoritative reference for all DG classification | — |
| IMDG Code Database SHALL contain the complete Dangerous Goods List per the current IMDG Code amendment | — |
| IMDG Code Database SHALL provide batch query capability for segregation group membership and Table 7.2.4 compatibility data | — |
| IMDG Code Database SHALL support synchronous query | — |
| IMDG Code Database SHALL support update ingestion for new IMDG Code amendments within 48 hours of amendment data availability | — |
| IMDG Code Database and return a pass | — |
| IMDG Code Database as central hub enforces a single source of truth for DG classification data. Separating segregation from stowage validation reflects the distinct IMDG Code chapters | — |
| IMDG Code Database as the central reference hub. The Segregation Rules Engine and DG Stowage Position Validator are separated rather than merged because segregation | — |
| IMDG Code Table 7.2.4 | — |
| IMDG Code Table 7.2.4 defines mandatory segregation distances between hazard classes. Automated enforcement prevents human error in stowage planning that could place incompatible dangerous goods adjacent | — |
| IMDG Code Table 7.2.4 for each class pair combination. Calculating separation in three | — |
| IMDG Code Table 7.2.4 rules for the most hazardous pairings. These specific combinations are chosen because they represent the highest | — |
| IMDG Code Table 7.2.4 segregation enforcement is a SOLAS Chapter VII regulatory requirement. Failure to enforce correct segregation of incompatible dangerous goods classes has caused vessel fires and explosions | — |
| IMDG Code Table 7.2.4 segregation requirements during placement | — |
| IMDG Code Table 7.2.4 segregation rules for all 9 hazard classes and 3 segregation groups | — |
| IMDG Code chapters | — |
| IMDG Code compliance checking appear in the IMO FAL Form 7 output. The interface between the Dangerous Goods Management System and the Stowage Planning Engine SHALL transmit stowage constraint data comprising | — |
| IMDG Code compliance is a SOLAS requirement | — |
| IMDG Code is amended on a two | — |
| IMDG Code is required by SOLAS VII and the IMDG Code Chapter 5.4. Processing 500 declarations within 60 seconds matches the rate at which large terminal operating systems submit booking confirmations during peak loading operations. Automated validation replaces manual DG officer review | — |
| IMDG Code reference. Batch query testing at 25 | — |
| IMDG Code section and stowage category code in the rejection reason. Hard rejection of stowage positions violating segregation rules is the safety | — |
| IMDG Code segregation | — |
| IMDG Database directly | — |
| IMDG hazard classes and verify that the Dangerous Goods system returns correct segregation matrices. Intentionally place containers violating segregation distances and confirm the SPE rejects these placements. Pass criteria | — |
| IMDG hazard classes must be represented in the test manifest because segregation rules and stowage categories differ significantly between classes. A test covering only common classes | — |
| IMDG hazard classes placed in known violation configurations | — |
| IMDG segregation | — |
| IMDG stowage category rules | — |
| ISO 1496-1 | — |
| ISO 6346 | — |
| SOLAS | — |
| SOLAS 2009 Chapter II | — |
| SOLAS Chapter II | — |
| SOLAS Chapter VI Regulation 2 | — |
| SOLAS Chapter VI Regulation 2 requires VGM for all packed containers before vessel loading. Non | — |
| SOLAS Chapter VII Regulation 4 and IMDG Code Section 5.4.3 | — |
| SOLAS VGM amendments. The 2000 | — |
| SOLAS VGM compliance evidence. Storing declared VGM | — |
| SOLAS VGM compliance is achievable regardless of terminal infrastructure. Mandatory fields prevent incomplete declarations from entering the system. The Weighbridge Data Interface SHALL acquire gross weight measurements from terminal weighbridge equipment via Modbus TCP | — |
| SOLAS VGM verification requirements. The interface between the Container Weight Database and the Container Tracking and Inventory System SHALL synchronize VGM status and verified gross mass for each container | — |
| SOLAS VI | — |
| SOLAS VII and IMDG Code 5.4.3 | — |
| SOLAS VII. Automated generation from the cargo database eliminates manual transcription errors that could delay port entry clearance. The Communication Link Manager SHALL detect primary VSAT link failure within 5 seconds and complete automatic failover to Inmarsat Fleet Broadband backup within 30 seconds | — |
| SOLAS amendments or flag state circulars change | — |
| SOLAS compliance concern | — |
| SOLAS record retention expectations. The intact stability calculation | — |
| SOLAS requires VGM declarations to identify the weighing method and authorized person. The validator enforces these mandatory fields at the point of entry to prevent incomplete declarations from propagating through the system and causing downstream audit failures. The VGM Compliance Validator SHALL issue a loading authorization status for each container | — |
| SOLAS requires that weighing equipment used for Method 1 VGM be certified and calibrated per national regulations. Maintaining the calibration register enables the system to reject measurements from expired or uncertified equipment | — |
| SOLAS to ensure all containers have valid VGM before departure. The VGM Reporting and Audit Module SHALL generate individual container VGM certificates showing the full chain of custody from declaration receipt through discrepancy check to loading authorization | — |
| SOLAS weighing accuracy standards. The Weighbridge Data Interface SHALL maintain a calibration certificate register for each connected weighing device | — |
| Acronym | Expansion |
|---|---|
| ARC | Architecture Decisions |
| CCCS | Completeness, Consistency, Correctness, Stability |
| EARS | Easy Approach to Requirements Syntax |
| IFC | Interface Requirements |
| STK | Stakeholder Requirements |
| SUB | Subsystem Requirements |
| SYS | System Requirements |
| UHT | Universal Hex Taxonomy |
| VER | Verification Plan |
flowchart TB n0["system<br>Container Ship Cargo Management System"] n1["actor<br>Terminal Operating System"] n2["actor<br>Cargo Officer"] n3["actor<br>Ship Master"] n4["actor<br>Shipping Line Booking System"] n5["actor<br>Port Authority"] n6["actor<br>Ballast and Tank Gauging System"] n7["actor<br>Reefer Container Units"] n8["actor<br>Class Society"] n0 -->|BAPLIE/COPARN/MOVINS EDI| n1 n2 -->|Stowage commands, move confirmations| n0 n0 -->|Stability reports, departure condition| n3 n4 -->|Booking data, container manifests| n0 n0 -->|DG manifest, CUSCAR, cargo declarations| n5 n6 -->|Tank levels, draught readings| n0 n0 -->|Temperature setpoints, status monitoring| n7 n0 -->|Loading instrument data, certificates| n8
Container Ship Cargo Management System — Context
flowchart TB n0["subsystem<br>Stowage Planning Engine"] n1["subsystem<br>Stability and Stress Monitoring"] n2["subsystem<br>Reefer Container Management"] n3["subsystem<br>Dangerous Goods Management"] n4["subsystem<br>Lashing and Securing Calculator"] n5["subsystem<br>Terminal Interface and EDI Gateway"] n6["subsystem<br>Container Tracking and Inventory"] n7["subsystem<br>Cargo Operations Display"] n8["subsystem<br>VGM Compliance and Weight Verification"] n6 -->|Container inventory| n0 n0 -->|Bay plan weights| n1 n0 -->|Stack weights, positions| n4 n3 -->|DG segregation constraints| n0 n2 -->|Reefer plug availability| n0 n5 -->|EDI messages| n6 n8 -->|Verified weights| n0 n8 -->|Weight data| n1 n1 -->|Stability status| n7 n0 -->|Bay plan view| n7
Container Ship Cargo Management System — Decomposition
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| STK-NEEDS-001 | The Container Ship Cargo Management System SHALL enable the cargo officer to plan, execute, and monitor cargo operations such that the vessel's intact stability margins remain above IMO A.749 minimum criteria at all times during loading, discharge, and voyage. Rationale: Core operational need: cargo officers require an integrated system to manage container operations safely and efficiently across port calls, replacing fragmented manual processes that increase turnaround time and error rates. | Analysis | stakeholder, session-277 |
| STK-NEEDS-002 | The Container Ship Cargo Management System SHALL produce stowage plans that minimise the number of restows (shifting moves) at each port of call in the vessel's rotation, targeting less than 5% restow ratio against total discharge moves. Rationale: Each restow costs approximately USD 200-400 in crane time and delays vessel departure. Minimising restows directly reduces port costs and improves schedule reliability for liner services. | Test | stakeholder, session-277 |
| STK-NEEDS-003 | The Container Ship Cargo Management System SHALL enforce IMDG Code segregation, stowage, and documentation requirements for all dangerous goods containers, preventing loading of non-compliant container placements and generating the mandatory dangerous goods manifest for port authority submission. Rationale: IMDG Code compliance is a SOLAS requirement (Chapter VII). Non-compliance risks catastrophic cargo incidents (fires, toxic releases) and exposes the vessel to port state detention. | Test | stakeholder, session-277 |
| STK-NEEDS-004 | The Container Ship Cargo Management System SHALL continuously monitor all connected reefer containers and alert the duty officer within 5 minutes of any temperature deviation exceeding the shipper's tolerance, to prevent spoilage of perishable cargo valued at up to USD 100,000 per container. Rationale: Reefer cargo losses from undetected temperature excursions can exceed USD 100,000 per container. Continuous monitoring with proactive alerting prevents spoilage of perishable and pharmaceutical cargo. | Test | stakeholder, session-277 |
| STK-NEEDS-005 | The Container Ship Cargo Management System SHALL prevent the loading of any container that does not have a valid verified gross mass (VGM) declaration as required by SOLAS Chapter VI Regulation 2, and SHALL flag weight discrepancies exceeding 5% between declared VGM and any independent measurement. Rationale: SOLAS Chapter VI Regulation 2 requires VGM for all packed containers before vessel loading. Non-compliance results in port state detention and potential fines under national maritime legislation. | Test | stakeholder, session-277 |
| STK-NEEDS-006 | The Container Ship Cargo Management System SHALL exchange stowage plans and container data with any SMDG-compliant terminal operating system via UN/EDIFACT maritime messages, supporting the vessel's operation across a global port rotation of 20+ terminals operated by different terminal operators. Rationale: Container shipping relies on standardised EDI messaging between ship and terminal systems. Interoperability with SMDG-compliant terminals is essential for efficient port operations globally. | Demonstration | stakeholder, session-277 |
| STK-NEEDS-007 | The Container Ship Cargo Management System SHALL verify that every on-deck container stack's lashing arrangement meets the forces calculated per the vessel's approved Cargo Securing Manual, and SHALL warn the cargo officer before any stack is loaded that would exceed the lashing capacity for the planned voyage route. Rationale: Parametric rolling and heavy weather can cause catastrophic container stack collapses. CSS Code and vessel-specific cargo securing manual compliance prevents loss of containers overboard and structural damage. | Analysis | stakeholder, session-277 |
| STK-NEEDS-009 | The Container Ship Cargo Management System SHALL be designed to meet the type approval requirements of a recognised classification society for a Class-approved loading instrument as required by SOLAS Chapter II-1 Regulation 22, including independent verification of stability calculations and provision for class surveyor audit access. Rationale: SOLAS Chapter II-1 Regulation 22 mandates that all vessels carry a stability instrument approved by the classification society. Without class type approval, the system cannot be used as the primary loading instrument and the vessel must maintain parallel manual calculations. Class surveyor audit access is required for periodic verification during annual and special surveys. Independent calculation verification prevents single-point software faults from producing undetected erroneous stability results. | Inspection | stakeholder, classification-society, validation, session-288 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SYS-REQS-001 | The Container Ship Cargo Management System SHALL calculate intact stability parameters (GM, GZ curve, trim, heel) and longitudinal strength (bending moment, shear force) within 2 seconds of any change to the loading condition, including individual container load/discharge events and ballast tank level changes. Rationale: SOLAS Chapter II-1 Part B-1 mandates that intact stability and longitudinal strength be verified for every loading condition. Real-time calculation prevents departure in non-compliant conditions that could lead to capsizing or structural failure. | Test | system, stability, session-277 |
| SYS-REQS-002 | The Container Ship Cargo Management System SHALL generate an optimised stowage plan for a full 20,000 TEU load list within 300 seconds, considering port rotation sequence, container weight/type/destination, stack weight limits, tier height limits, hatch cover limits, and dangerous goods segregation constraints. Rationale: A 20,000 TEU vessel may load 5,000+ containers per port call. Plan generation within 2 minutes enables the cargo officer to evaluate alternatives during the compressed pre-departure window; exceeding this threshold delays vessel departure. | Test | system, stowage, session-277 |
| SYS-REQS-003 | The Container Ship Cargo Management System SHALL enforce IMDG Code Table 7.2.4 segregation rules for all 9 hazard classes and 3 segregation groups, preventing the stowage planning engine from placing containers in positions that violate the minimum separation distances (1 container space, 1 container space fore-and-aft, 6m, 12m, 24m, or separate compartment) specified for each incompatible class pair. Rationale: IMDG Code Table 7.2.4 defines mandatory segregation distances between hazard classes. Automated enforcement prevents human error in stowage planning that could place incompatible dangerous goods adjacent, risking fire or toxic release. | Test | system, dangerous-goods, session-277 |
| SYS-REQS-004 | The Container Ship Cargo Management System SHALL poll each connected reefer container's temperature, humidity, and compressor status at intervals not exceeding 5 minutes, and SHALL generate an alarm within 60 seconds when any container's cargo temperature deviates more than 2 degrees Celsius from its set-point for two consecutive readings. Rationale: Reefer containers require continuous power and temperature monitoring. A 5-minute polling interval balances power bus load against the thermal time constant of insulated containers, ensuring excursions are detected before cargo damage occurs. | Test | system, reefer, session-277 |
| SYS-REQS-005 | The Container Ship Cargo Management System SHALL reject any container loading instruction where the container does not have a VGM declaration recorded in the system, and SHALL flag containers where the absolute difference between declared VGM and any independent weight measurement exceeds 5% of the declared VGM or 1,000 kg, whichever is greater. Rationale: SOLAS VI/2 makes VGM a hard gate for loading. Automated rejection prevents containers without valid VGM from being loaded, avoiding potential port state detention and ensuring accurate stability calculations. | Test | system, vgm, session-277 |
| SYS-REQS-006 | The Container Ship Cargo Management System SHALL support transmission and reception of BAPLIE (D.13B or later), COPARN, MOVINS, CUSCAR, IFTDGN, and VERMAS messages conforming to SMDG EDIFACT implementation guidelines, and SHALL process a complete inbound BAPLIE message containing 20,000 container records within 120 seconds. Rationale: BAPLIE, COPARN, and MOVINS are the SMDG-standard EDI message types used by container terminals worldwide. Supporting D.13B or later ensures compatibility with modern terminal operating systems. | Test | system, edi, session-277 |
| SYS-REQS-007 | The Container Ship Cargo Management System SHALL calculate lashing forces for every on-deck container stack using the vessel's Cargo Securing Manual acceleration table, and SHALL generate a warning when any stack's calculated lashing force exceeds 90% of the maximum securing load (MSL) of the fitted lashing arrangement for the planned voyage route's design sea state. Rationale: CSS Code Annex 13 and the vessel-specific cargo securing manual define permissible stack weights and lashing arrangements. Automated lashing force calculation prevents stack collapse in heavy weather conditions. | Analysis | system, lashing, session-277 |
| SYS-REQS-008 | The Container Ship Cargo Management System SHALL maintain a real-time container inventory with sub-second query response time for the full vessel capacity of 20,000+ containers, and SHALL reconcile the shipboard inventory against terminal-reported loading and discharge events within 60 seconds of each EDI move confirmation. Rationale: Sub-second query response is needed because stability recalculation and stowage planning algorithms query the container inventory thousands of times per optimisation cycle. Latency above 1 second would make plan generation unacceptably slow. | Test | system, inventory, session-277 |
| SYS-REQS-009 | The Container Ship Cargo Management System SHALL provide a what-if simulation mode that allows the cargo officer to evaluate the stability, stress, lashing, and DG compliance impact of proposed container moves before committing them, with simulation results displayed within 5 seconds per proposed move set. Rationale: What-if simulation allows the cargo officer to evaluate the stability and strength impact of proposed loading changes before execution. This prevents committing to load sequences that would violate stability criteria mid-operation. | Demonstration | system, simulation, session-277 |
| SYS-REQS-010 | The Container Ship Cargo Management System SHALL achieve a system availability of at least 99.95 percent during cargo operations with a mean time between failures of not less than 2000 hours for the stability calculation function and not less than 1000 hours for the stowage planning function. Rationale: Container vessels operate cargo operations 24/7 in port with typical port stays of 12-36 hours. A system outage during active loading requires halting crane operations at approximately USD 50,000/hour in delay costs. The 99.95% availability target (4.4 hours annual downtime) reflects the operational tempo of ultra-large container vessels calling at 8-12 ports per voyage. The 2000-hour MTBF for stability calculations reflects its safety-critical nature — an undetected stability error during loading could lead to list or capsize. The lower 1000-hour MTBF for stowage planning reflects its operational but non-safety-critical function. | Analysis | performance, availability, validation, session-288 |
| SYS-REQS-011 | The Container Ship Cargo Management System SHALL implement network segmentation between the cargo management network and external-facing communication interfaces (VSAT, terminal EDI links) in accordance with IACS UR E26, and SHALL log all authentication events, configuration changes, and remote access sessions to a tamper-evident audit trail. Rationale: IACS Unified Requirement E26 on cyber resilience mandates network segmentation between operational technology and external-facing interfaces on class-approved vessels. The cargo management system connects to external networks (VSAT for EDI, terminal WiFi for BAPLIE exchange) that are exposed to internet-borne threats. Without segmentation, a compromised EDI link could allow lateral movement to the stability calculation function. The tamper-evident audit trail supports forensic investigation after a security event and satisfies port state control requirements for demonstrating cyber hygiene under IMO MSC-FAL.1/Circ.3. | Test | cybersecurity, compliance, validation, session-288 |
| SYS-REQS-012 | The Container Ship Cargo Management System SHALL retain all loading condition records, VGM declarations, dangerous goods manifests, reefer temperature logs, and stability calculations for a minimum of 3 years from the date of creation, and SHALL support export of retained data in a non-proprietary format for port state control inspection and class society audit. Rationale: Port state control inspections under the Paris MoU and Tokyo MoU may request historical loading condition records, VGM declarations, and DG manifests up to 3 years after a voyage. Classification society annual and special surveys also require historical stability calculation records. Non-proprietary export format ensures data remains accessible independent of the system vendor, preventing vendor lock-in for regulatory compliance data. The 3-year period covers the typical class survey cycle and aligns with SOLAS record retention expectations. | Inspection | data-retention, compliance, validation, session-288 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| SUB-REQS-002 | The Stability and Stress Monitoring System SHALL calculate intact stability parameters including metacentric height (GM), righting lever curve (GZ), and dynamic stability area to IMO Resolution A.749(18) criteria within 5 seconds of any loading change exceeding 10 tonnes displacement delta. Rationale: The Intact Stability Computer is the core safety function of the SSMS. IMO A.749(18) criteria define minimum GM, GZ area, and angle of vanishing stability. The 5-second recalculation threshold ensures the cargo officer sees updated stability before the next crane cycle completes a container move. | Test | |
| SUB-REQS-003 | The Stability and Stress Monitoring System SHALL compute hull girder shear force and bending moment at each of the vessel's defined frame stations (minimum 20 stations) and compare results against IACS UR S11 permissible limits, generating an alarm when any station exceeds 90% of the allowable value. Rationale: IACS UR S11 defines permissible shear force and bending moment envelopes. Exceeding these limits risks hull girder failure. Calculation at each frame station (typically 20-40 stations) provides granular visibility into structural loading along the hull length. | Test | |
| SUB-REQS-004 | The Stability and Stress Monitoring System SHALL evaluate probabilistic damage stability in accordance with SOLAS Chapter II-1, computing the attained subdivision index for at least the three most probable damage scenarios based on the current loading condition, and SHALL alert when the attained index falls below the required subdivision index R. Rationale: SOLAS 2009 Chapter II-1 Part B-1 mandates probabilistic damage stability assessment. The attained subdivision index must meet the required index R for the vessel's length. This requirement ensures the system evaluates damage survivability for every loading condition. | Analysis | |
| SUB-REQS-005 | The Stability and Stress Monitoring System SHALL acquire draught readings from at least four hull-mounted pressure sensors (forward, aft, port midship, starboard midship) at a minimum sampling rate of 1 Hz, with measurement accuracy of plus or minus 2 cm across the full operating draught range. Rationale: Four draught sensors (fore, aft, port midships, starboard midships) provide redundant measurement of actual vessel displacement and trim. A 15-second polling cycle matches the sensor response time of hydrostatic pressure transducers and provides adequate temporal resolution for loading operations. | Test | |
| SUB-REQS-006 | The Stability and Stress Monitoring System SHALL calculate free surface correction for all slack tanks using actual tank sounding data and tank geometry tables, applying the correction to the effective metacentric height (GM) continuously. Rationale: Free surface effect reduces effective GM and can cause negative stability if uncorrected. Using actual tank sounding data rather than assumed fill levels eliminates the conservative approximations that waste cargo capacity by overstating free surface moments. | Test | |
| SUB-REQS-007 | When any stability or strength parameter exceeds its warning threshold, the Stability and Stress Monitoring System SHALL generate a prioritised alarm within 2 seconds, classified as caution (80-90% of limit), warning (90-95% of limit), or critical (above 95% of limit), and SHALL display the specific parameter, current value, limit value, and recommended corrective action. Rationale: Multi-tier alerting (warning at 90%, alarm at 95%, critical at 100% of limits) gives the cargo officer graduated response time. The 2-second alert latency ensures the alarm sounds before the next container in a loading sequence is committed. | Test | |
| SUB-REQS-008 | The Stability and Stress Monitoring System SHALL store at least 100 loading conditions including departure, arrival, and intermediate states, retaining hydrostatic tables, tank calibration data, and hull form coefficients for the specific vessel, and SHALL permit recall of any stored condition within 3 seconds. Rationale: Loading condition storage enables regulatory compliance (classification societies require departure/arrival conditions on record) and provides reference data for voyage planning. 100 conditions covers a typical 6-month trading pattern with multiple port rotations. | Test | |
| SUB-REQS-009 | When fewer than three of the four draught sensors are operational, the Stability and Stress Monitoring System SHALL maintain stability calculations using the remaining sensors with increased uncertainty bounds displayed to the operator, achieving draught accuracy of plus or minus 5 cm, stability calculation update rate of not less than once per 30 seconds, and GM accuracy within plus or minus 0.05 metres. While in degraded draught sensor mode, the system SHALL flag the degraded state on all displayed outputs and SHALL maintain shear force and bending moment calculations at not less than 90 percent of nominal accuracy. Rationale: Draught sensor redundancy means the system must continue operating with reduced sensor count. The plus or minus 5 cm accuracy threshold in degraded mode exceeds the IMO minimum draught measurement accuracy of plus or minus 10 cm, maintaining classification society approval while clearly indicating reduced confidence. | Test | |
| SUB-REQS-010 | The Stability and Stress Monitoring System SHALL evaluate the IMO weather criterion (Resolution A.749(18) Regulation 3.2) for the current loading condition, computing the ratio of area b to area a on the GZ curve, and SHALL alert when the ratio falls below 1.0. Rationale: The IMO weather criterion assesses the vessel ability to withstand beam wind combined with rolling. This is the most common stability failure mode for container ships due to their high windage area. Continuous evaluation during loading prevents departure in weather-vulnerable conditions. | Test | |
| SUB-REQS-011 | The Stowage Optimization Engine SHALL generate a feasible container placement plan for a full 20,000 TEU load list within 120 seconds on a single compute node, producing solutions where no constraint (stack weight, tier height, segregation, reefer plug, lashing) is violated. Rationale: A 10-minute solve time for 20,000 TEU is the operational threshold beyond which planners revert to manual placement, negating the optimization benefit. The 98 percent feasibility rate ensures the engine rarely produces plans requiring manual intervention, which on ultra-large container vessels can delay port operations by 2-4 hours per infeasible plan. | Test | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-012 | The Port Rotation Planner SHALL produce a bay affinity map for a voyage of up to 15 port calls within 60 seconds, achieving a predicted restow ratio of less than 5 percent of total discharge moves across the voyage. Rationale: Bay affinity maps reduce restow moves at intermediate ports by grouping containers discharged at the same port into adjacent bays. For a 12-port rotation, affinity planning can reduce total restow moves by 15-30 percent, directly translating to reduced port stay time and crane hours. | Test | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-013 | The Crane Split Calculator SHALL distribute cargo operations across up to 6 quay cranes achieving at least 90 percent workload balance (ratio of lightest to heaviest crane load), while ensuring no two cranes are assigned simultaneous operations on adjacent bays. Rationale: Unbalanced crane splits cause one crane to finish significantly before others, wasting expensive quay crane hours. A 15 percent maximum deviation across 6 cranes ensures near-uniform completion times, maximizing port throughput. Six cranes is the maximum simultaneously deployable on the largest container vessels (23,000+ TEU). | Test | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-014 | The Vessel Stowage Model SHALL represent all container slots with bay, row, tier coordinates and associated physical constraints including stack weight limits, tier height limits, reefer plug availability, and hatch cover groupings, accurate to the vessel General Arrangement Plan. Rationale: The vessel stowage model must represent every physical slot including 20/40/45-foot variations, high-cube compatibility, and weight stack limits because planning against an incomplete model produces infeasible plans that are only discovered during physical loading. Slot-level fidelity prevents overstow situations and hatch cover conflicts. | Inspection | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-015 | The Stowage Rules Database SHALL provide constraint lookup responses within 1 millisecond per query for stack weight limits, segregation rules, and reefer plug availability, supporting at least 500,000 queries per optimization run without cache invalidation. Rationale: A 1-millisecond constraint lookup response time is required because the optimization engine evaluates millions of candidate placements per solve iteration. At 10ms per lookup, a 20,000 TEU solve would spend over 3 minutes on constraint queries alone, exceeding the 10-minute total solve budget. | Test | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-016 | The Stowage Optimization Engine SHALL enforce IMDG Code Table 7.2.4 segregation requirements during placement, ensuring no container placement violates horizontal or vertical separation distances for any of the 9 hazard classes and 3 segregation groups, including closed-versus-open deck differentiation. Rationale: IMDG Code Table 7.2.4 segregation enforcement is a SOLAS Chapter VII regulatory requirement. Failure to enforce correct segregation of incompatible dangerous goods classes has caused vessel fires and explosions (e.g., MSC Flaminia 2012). Automated enforcement eliminates human error in manual segregation checking for vessel loads exceeding 1,000 DG containers. | Test | subsystem, stowage-planning-engine, safety, session-280 |
| SUB-REQS-017 | The Hatch Cover Sequence Planner SHALL generate a valid hatch cover removal and replacement sequence that minimizes total crane idle time attributable to hatch operations, ensuring that no hold cargo operation is scheduled before the corresponding hatch covers and all on-deck containers above them are removed. Rationale: Hatch cover removal/replacement sequence must be planned with cargo operations because an incorrect sequence blocks crane access to holds. On a 20,000 TEU vessel with 20+ hatch covers, an invalid sequence causes 30-60 minute crane idle time per error. The planner must account for deck cargo that must be moved before hatch covers can be lifted. | Demonstration | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-018 | The Restow Minimization Module SHALL identify all overstow situations in the current bay plan against the discharge list for the next 3 ports and propose pre-emptive shift moves that reduce the predicted restow ratio below 5 percent without violating any stability or structural constraint. Rationale: Restow (moving a container to access one beneath it) costs USD 150-300 per move in crane time and stevedore labour. On a 14-port rotation of a large container vessel, unoptimized stowage can generate 500-1,000 unnecessary restow moves per voyage. Identifying and minimizing overstow situations during planning prevents these costs at the point where they are cheapest to resolve. | Test | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-019 | The Stowage Optimization Engine SHALL support a what-if simulation mode where the cargo officer can modify up to 50 container placements manually and receive updated stability, stress, and constraint violation assessments within 10 seconds per modification. Rationale: What-if simulation allows planners to evaluate the impact of late booking changes, weather rerouting, or port skips without committing to a new plan. This is operationally critical because container vessels frequently receive booking changes within 24 hours of port arrival, and the planner needs to assess feasibility before accepting or rejecting the change. | Demonstration | subsystem, stowage-planning-engine, session-280 |
| SUB-REQS-020 | The IMDG Code Database SHALL contain the complete Dangerous Goods List per the current IMDG Code amendment, including all UN numbers (minimum 3,500 entries), proper shipping names, hazard classes and divisions, packing groups, stowage categories (A through E), segregation groups (SGG1 through SGG18), EmS fire and spillage schedule references, and special provisions. Rationale: The IMDG Code Dangerous Goods List is the authoritative reference for all DG classification, stowage, and segregation decisions. The minimum 3,500 UN number entries covers the complete DGL as of Amendment 41-22. Inclusion of stowage categories, segregation groups, and EmS references enables automated end-to-end DG compliance checking without external lookups. | Inspection | subsystem, dg-management, imdg-database, session-281 |
| SUB-REQS-022 | The DG Declaration Validator SHALL validate an incoming Dangerous Goods Declaration against the IMDG Code Database and return a pass/fail result with specific non-compliance codes within 2 seconds per declaration. Rationale: DG declaration validation against the IMDG Code is required by SOLAS VII and the IMDG Code Chapter 5.4. Processing 500 declarations within 60 seconds matches the rate at which large terminal operating systems submit booking confirmations during peak loading operations. Automated validation replaces manual DG officer review, which is error-prone at high volumes. | Test | subsystem, dg-management, declaration-validator, session-281 |
| SUB-REQS-023 | The Segregation Rules Engine SHALL evaluate segregation compatibility for all pairwise combinations defined in IMDG Code Table 7.2.4, covering all 9 hazard classes, their divisions, and all 18 segregation groups SGG1 through SGG18, returning the required separation category 1 through 4 or X for each pair. Rationale: Segregation compatibility evaluation for all container pairs within a bay is the computationally critical path for DG stowage safety. On a 24,000 TEU vessel carrying 2,000+ DG containers, the segregation engine must evaluate millions of pair combinations. A 5-second evaluation time per bay keeps total vessel-wide segregation checking under 10 minutes. | Test | subsystem, dg-management, segregation-engine, session-281 |
| SUB-REQS-024 | The Segregation Rules Engine SHALL calculate minimum physical separation distances in three dimensions using vessel geometry data, applying: 3m horizontal for away-from, 6m or one bulkhead for separated-from, 12m or two bulkheads for separated-by-complete-compartment, and 24m minimum for separated-longitudinally-by-intervening-complete-compartment. Rationale: Minimum physical separation distances (horizontal, vertical, and fore-aft) are specified in IMDG Code Table 7.2.4 for each class pair combination. Calculating separation in three-dimensional coordinates is necessary because container vessel stowage is three-dimensional, and two containers may satisfy horizontal segregation while violating vertical adjacency rules. | Test | subsystem, dg-management, segregation-engine, session-281 |
| SUB-REQS-025 | The DG Stowage Position Validator SHALL reject any proposed stowage position that violates the container's IMDG stowage category rules, including on-deck versus under-deck restrictions, minimum distance from crew accommodation, and proximity to heat sources or machinery spaces, providing the specific IMDG Code section and stowage category code in the rejection reason. Rationale: Hard rejection of stowage positions violating segregation rules is the safety-critical gate in the DG management chain. Advisory-only mode is insufficient because planners under time pressure have historically overridden warnings, leading to incompatible DG stowage (contributing factor in the Maersk Honam fire, 2018). Automated rejection with reason codes eliminates this failure mode. | Test | subsystem, dg-management, stowage-validator, session-281 |
| SUB-REQS-026 | When the main Dangerous Goods Management System is unavailable, the Emergency Response Information System SHALL continue to provide EmS fire and spillage schedules and MFAG treatment data for all DG containers currently aboard, with lookup response time not exceeding 5 seconds, via an independent backup display. Rationale: Emergency response procedures must remain accessible during system outages because DG incidents (spills, fires, toxic releases) can occur at any time. The offline reference retains the 50 most recent DG container records because emergency responders need to identify nearby hazards, and the most recent containers represent the current deck and hold cargo arrangement. | Demonstration | subsystem, dg-management, emergency-response, safety-critical, session-281 |
| SUB-REQS-027 | The DG Manifest Generator SHALL produce a dangerous goods manifest compliant with SOLAS Chapter VII Regulation 4 and IMDG Code Section 5.4.3, listing every DG container aboard with its stowage position, UN number, proper shipping name, hazard class and division, packing group, net quantity, number of packages, and EmS reference, and SHALL regenerate the complete manifest within 5 minutes of any stowage change. Rationale: The DG manifest is a mandatory document under SOLAS VII and IMDG Code 5.4.3, required before vessel departure. IMO FAL Form 7 is the internationally recognised format accepted by all port state control authorities. Automated generation eliminates transcription errors that have historically caused vessel detention during port state control inspections. | Test | subsystem, dg-management, manifest-generator, session-281 |
| SUB-REQS-028 | The IMDG Code Database SHALL support update ingestion for new IMDG Code amendments within 48 hours of amendment data availability, without requiring system downtime, and SHALL maintain the previous amendment data for containers loaded under the prior edition until they are discharged. Rationale: The IMDG Code is amended on a two-year cycle (with a one-year transitional period). The database must ingest new amendments without system downtime because vessels operate continuously, and an outdated DG database would cause incorrect segregation decisions during the transitional period when both the current and previous amendments are valid. | Demonstration | subsystem, dg-management, imdg-database, session-281 |
| SUB-REQS-029 | The Reefer Monitoring Unit SHALL poll all connected reefer containers and acquire supply air temperature, return air temperature, cargo setpoint, compressor status, and fault codes within a polling cycle of 15 minutes or less for a fleet of up to 1200 connected containers. Rationale: A 15-minute polling cycle for 1200 containers balances RS-485/Ethernet bus bandwidth against the thermal time constant of reefer cargo (typical spoilage onset >2 hours). Supply/return air temperatures and compressor status are the minimum telemetry set required by carrier standard operating procedures and P&I Club cargo claim investigations. | Test | subsystem, reefer, reefer-monitoring-unit, session-282 |
| SUB-REQS-030 | The Reefer Monitoring Unit SHALL acquire temperature readings with a resolution of 0.1 degrees Celsius and an end-to-end accuracy of plus or minus 0.5 degrees Celsius across the operating range of minus 35 to plus 30 degrees Celsius. Rationale: Temperature resolution of 0.1 degrees Celsius and accuracy of plus or minus 0.5 degrees Celsius match USDA 7 CFR 96 and ATP agreement requirements for perishable cargo transport. The operating range of minus 35 to plus 30 degrees Celsius covers frozen cargo (deep-frozen fish at minus 30 degrees Celsius) through tropical fruit (bananas at plus 13 degrees Celsius). | Test | subsystem, reefer, reefer-monitoring-unit, session-282 |
| SUB-REQS-033 | The Reefer Power Distribution Controller SHALL monitor individual circuit current draw for each reefer outlet and automatically disconnect any outlet drawing more than 32 amperes at 440 volts within 200 milliseconds of overload detection. Rationale: Individual circuit monitoring with 1-second response enables selective load-shedding before breaker trip, preventing cascading power loss across reefer banks. Circuit-level granularity is required because reefer containers draw variable current during compressor start (up to 3x running current), and a single tripped circuit can take 12-16 containers offline. | Test | subsystem, reefer, power-distribution, session-282 |
| SUB-REQS-034 | When total reefer power demand exceeds 80 percent of available generator capacity allocated to reefer services, the Reefer Power Distribution Controller SHALL implement priority-based load shedding, maintaining power to pharmaceutical and deep-frozen cargo (below minus 18 degrees Celsius setpoint) while shedding chilled cargo loads in reverse priority order. Rationale: The 80 percent demand threshold triggers proactive load-shedding before generator overload protection trips the entire reefer bus. Priority-based shedding ensures perishable high-value cargo (pharmaceuticals, fresh produce) retains power while less time-sensitive frozen cargo with greater thermal inertia is shed first. This prevents total reefer power loss incidents that have historically resulted in multi-million dollar cargo claims. | Test | subsystem, reefer, power-distribution, session-282 |
| SUB-REQS-035 | The Temperature Alarm Processor SHALL evaluate each reefer container temperature reading against its cargo-specific setpoint and generate advisory alarms when deviation exceeds 2 degrees Celsius for 15 minutes, warning alarms when deviation exceeds 3 degrees Celsius for 30 minutes, and critical alarms when deviation exceeds 5 degrees Celsius for any duration or 3 degrees Celsius for 2 hours. Rationale: Tiered alarm classification (deviation, warning, critical) prevents alarm fatigue among watch officers. Cargo-specific thresholds are essential because frozen cargo at minus 18 degrees Celsius has different deviation tolerances than chilled pharmaceuticals at plus 5 degrees Celsius. False alarm rates in reefer monitoring systems are a known industry problem — threshold specificity directly reduces nuisance alarms while maintaining detection of genuine temperature excursions. | Test | subsystem, reefer, alarm-processor, session-282 |
| SUB-REQS-036 | When a critical temperature alarm remains unacknowledged for 30 minutes, the Temperature Alarm Processor SHALL escalate the alarm to the bridge watch alarm system and generate an audible alert at the cargo control room. Rationale: A 30-minute unacknowledged critical alarm indicates the watch officer may be incapacitated or unaware. Escalation to the bridge and chief engineer ensures response before cargo damage progresses past recovery. The 30-minute threshold is derived from typical thermal runaway onset times for pharmaceutical cold chain cargo, which can become unsalvageable within 1-2 hours of setpoint exceedance. | Demonstration | subsystem, reefer, alarm-processor, session-282 |
| SUB-REQS-037 | The Pre-Trip Inspection Module SHALL record compressor run test results, cooling pull-down performance (ambient to setpoint within 4 hours for a 40-foot container), defrost cycle completion, and controller firmware version, and SHALL issue a pass verdict only when all criteria are met. Rationale: Pre-trip inspection (PTI) is mandated by carrier SOPs and terminal operating procedures before loading reefer containers. Recording compressor run test, cooling down rate, and defrost cycle results provides the evidentiary chain required for P&I Club cargo claims and demonstrates due diligence under the Hague-Visby Rules for carrier liability. | Test | subsystem, reefer, pre-trip-inspection, session-282 |
| SUB-REQS-038 | The Reefer Data Logger SHALL store timestamped temperature readings at intervals of 15 minutes or less for every connected reefer container, retaining at least 90 days of continuous data per container with tamper-evident integrity verification compliant with FDA 21 CFR Part 11 for pharmaceutical cold chain cargo. Rationale: Continuous temperature logging at configurable intervals (typically 5-15 minutes) produces the tamper-evident audit trail required by USDA, EU Regulation 37/2005, and ATP agreement for perishable cargo transport. Tamper-evidence is critical because temperature records are primary evidence in cargo damage claims and may be subpoenaed in litigation. | Inspection | subsystem, reefer, data-logger, session-282 |
| SUB-REQS-039 | The Controlled Atmosphere Monitor SHALL monitor oxygen concentration with a resolution of 0.1 percent and carbon dioxide concentration with a resolution of 0.1 percent for all connected CA reefer containers, and SHALL generate an alarm when either parameter deviates more than 1 percentage point from the cargo-specific atmosphere recipe for more than 30 minutes. Rationale: Controlled atmosphere (CA) reefer containers maintain reduced oxygen levels (typically 2-5 percent O2) to slow produce respiration and extend shelf life. Monitoring oxygen with 0.1 percent resolution and CO2 is essential because CA deviations can cause anaerobic respiration, ethanol accumulation, and cargo loss within hours for sensitive products like avocados and stone fruit. | Test | subsystem, reefer, controlled-atmosphere, session-282 |
| SUB-REQS-040 | When the central Reefer Monitoring Unit processor fails, the Temperature Alarm Processor SHALL continue evaluating the most recent valid temperature readings cached locally and SHALL generate alarms based on the last known setpoints for at least 2 hours, polling at a degraded cycle of 30 minutes using its backup data acquisition path. While operating in degraded mode, the Temperature Alarm Processor SHALL detect temperature excursions exceeding 5 degrees Celsius above setpoint within one polling cycle and SHALL maintain alarm notification delivery to the bridge alarm panel with a latency of no more than 10 seconds after detection. Rationale: The 2-hour minimum degraded operation on cached readings provides the watch officer time to diagnose and restore the central processor or transition to manual monitoring. The degraded polling cycle of 30 minutes (vs 15 minutes nominal) reduces load on the backup data acquisition path while maintaining detection capability for critical temperature excursions that typically develop over 1-2 hour timescales. | Test | subsystem, reefer, alarm-processor, degraded-mode, session-282 |
| SUB-REQS-041 | The VGM Declaration Receiver SHALL parse and validate incoming VERMAS EDI messages conforming to SMDG D.13B or later format, accepting both Method 1 (whole-container weighing) and Method 2 (sum of package weights plus tare) declarations, and SHALL process a batch of 500 declarations within 60 seconds. Rationale: SOLAS VI/2 mandates VGM submission before loading. The receiver must handle both Method 1 (whole-container weighing) and Method 2 (sum of contents) declarations since shippers choose their method. VERMAS D.13B is the IMO-endorsed EDI format for VGM exchange. | Test | subsystem, vgm, session-284 |
| SUB-REQS-042 | The VGM Declaration Receiver SHALL provide a manual entry interface for VGM declarations where EDI submission is unavailable, requiring the operator to enter container number, gross mass, weighing method, authorized weigher identity, and weighing date, and SHALL validate all mandatory fields before acceptance. Rationale: Not all terminals have EDI connectivity, particularly in smaller ports. A manual entry fallback ensures SOLAS VGM compliance is achievable regardless of terminal infrastructure. Mandatory fields prevent incomplete declarations from entering the system. | Demonstration | subsystem, vgm, session-284 |
| SUB-REQS-043 | The Weighbridge Data Interface SHALL acquire gross weight measurements from terminal weighbridge equipment via Modbus TCP, OPC-UA, or RS-232 serial protocols with a measurement resolution of 10 kg for containers up to 45,000 kg gross mass. Rationale: Terminal weighbridge equipment spans decades of technology — Modbus TCP for industrial scales, OPC-UA for modern installations, RS-232 for legacy equipment. Multi-protocol support ensures the system can operate at any terminal worldwide without pre-configuration. The measurement resolution requirement reflects SOLAS weighing accuracy standards. | Test | subsystem, vgm, session-284 |
| SUB-REQS-044 | The Weighbridge Data Interface SHALL maintain a calibration certificate register for each connected weighing device, recording certificate number, issuing authority, calibration date, and expiry date, and SHALL reject weight measurements from any device whose calibration certificate has expired. Rationale: SOLAS requires that weighing equipment used for Method 1 VGM be certified and calibrated per national regulations. Maintaining the calibration register enables the system to reject measurements from expired or uncertified equipment, which protects the vessel from regulatory non-compliance. | Test | subsystem, vgm, session-284 |
| SUB-REQS-045 | The Weight Discrepancy Detector SHALL compare each declared VGM against the corresponding weighbridge measurement and SHALL flag any container where the absolute difference exceeds 5% of the declared VGM or 1,000 kg, whichever is greater, classifying discrepancies as minor (5-10% or 1,000-2,000 kg), major (10-20% or 2,000-5,000 kg), or critical (above 20% or above 5,000 kg). Rationale: Weight discrepancies between declared VGM and measured weight are the primary indicator of misdeclaration or weighing error. The 5% threshold aligns with MSC.1/Circ.1475 industry guidance on acceptable VGM tolerances. Flagging discrepancies prevents loading containers whose actual weight may compromise stability calculations. | Test | subsystem, vgm, session-284 |
| SUB-REQS-046 | The Weight Discrepancy Detector SHALL perform statistical analysis across all VGM declarations for a given load list and SHALL identify shippers whose declarations show a systematic bias exceeding 3% mean deviation from measured weights across 10 or more containers. Rationale: Systematic shipper bias (consistently under- or over-declaring weight) is a leading indicator of intentional misdeclaration. Statistical analysis across a load list enables proactive identification of problematic shippers before the pattern results in a safety incident from cumulative weight errors. | Test | subsystem, vgm, session-284 |
| SUB-REQS-047 | The VGM Compliance Validator SHALL verify that each VGM declaration identifies the weighing method (Method 1 or Method 2), includes the identity of the authorized weigher, and confirms that the weigher is registered in the approved weigher database, and SHALL reject any declaration missing these mandatory fields. Rationale: SOLAS requires VGM declarations to identify the weighing method and authorized person. The validator enforces these mandatory fields at the point of entry to prevent incomplete declarations from propagating through the system and causing downstream audit failures. | Test | subsystem, vgm, session-284 |
| SUB-REQS-048 | The VGM Compliance Validator SHALL issue a loading authorization status for each container, with status values of AUTHORIZED (valid VGM, no discrepancy), CONDITIONAL (minor discrepancy, reweigh requested), HOLD (major discrepancy, pending resolution), or REJECTED (no VGM, critical discrepancy, or invalid declaration), and SHALL transmit this status to the Stowage Planning Engine within 2 seconds of determination. Rationale: A binary accept/reject model is insufficient — some containers may have minor administrative deficiencies (e.g., missing weigher signature) that can be resolved while the container is staged. The four-state authorization model allows cargo operations to continue for compliant containers while holding non-compliant ones without blocking the entire operation. | Test | subsystem, vgm, session-284 |
| SUB-REQS-049 | The Container Weight Database SHALL store VGM records for each container including container number, declared VGM, measured weight, tare weight, discrepancy status, weighing method, authorized weigher identity, equipment identifier, and timestamps, and SHALL retain these records for a minimum of 3 years from the date of the voyage. Rationale: A persistent container weight record with full audit trail is required for SOLAS VGM compliance evidence. Storing declared VGM, measured weight, tare weight, and discrepancy status together enables post-incident forensic analysis if a weight-related safety event occurs. | Inspection | subsystem, vgm, session-284 |
| SUB-REQS-050 | The Container Weight Database SHALL support individual container weight lookups with a response time not exceeding 100 milliseconds for a database containing up to 500,000 historical container records. Rationale: The stability system and stowage optimizer query individual container weights frequently during planning cycles. A 100ms response time across 500,000 historical records ensures that weight lookups do not become a bottleneck in the 60-second planning cycle, even when the database includes multi-voyage history for trend analysis. | Test | subsystem, vgm, session-284 |
| SUB-REQS-051 | The VGM Reporting and Audit Module SHALL generate a per-voyage VGM compliance summary report showing total containers processed, VGM coverage percentage, discrepancy rate by severity tier, and list of containers loaded without VGM (which SHALL be zero for a compliant voyage), in PDF and structured XML formats. Rationale: Port State Control inspections and terminal operators require per-voyage VGM compliance summaries. The report must quantify coverage and discrepancy rates to demonstrate systematic compliance, not just individual container verification. This supports the master's obligation under SOLAS to ensure all containers have valid VGM before departure. | Demonstration | subsystem, vgm, session-284 |
| SUB-REQS-052 | The VGM Reporting and Audit Module SHALL generate individual container VGM certificates showing the full chain of custody from declaration receipt through discrepancy check to loading authorization, with all timestamps, and SHALL make these available within 5 seconds of request. Rationale: Individual container VGM certificates with full chain of custody provide the documentary evidence required if a container is selected for spot-check by Port State Control or if a weight-related incident occurs. The certificate links declaration receipt through discrepancy check to loading authorization for complete traceability. | Test | subsystem, vgm, session-284 |
| SUB-REQS-053 | The Stack Weight Calculator SHALL compute vertical compressive loads for each container stack by summing individual container gross weights and applying dynamic amplification factors derived from the vessel's metacentric height and natural roll period per CSS Code Annex 13. Rationale: CSS Code Annex 13 requires vertical compressive load assessment for each stack to determine whether stacking weight limits are exceeded. Dynamic amplification factors account for vessel motions at sea that increase effective weight beyond static gravity loading. This is the primary check preventing container stack collapse. | Test | subsystem, lashing, stack-weight, session-285 |
| SUB-REQS-054 | The Stack Weight Calculator SHALL recalculate all bay stack weights within 3 seconds of a container weight or position change, covering all bays (up to 400 bays on a 24,000 TEU vessel) in a single calculation cycle. Rationale: During active cargo operations, container weights and positions change continuously. A 3-second recalculation window across all 400 bays ensures the lashing assessment reflects the current vessel state before the next container move is authorized. Delayed recalculation risks permitting a move that creates an overloaded stack. | Test | subsystem, lashing, stack-weight, performance, session-285 |
| SUB-REQS-055 | The Lashing Rod Load Analyzer SHALL compute the balance of external forces (gravity, wind, sea inertia) against securing capacity (lashing rod tension, twist-lock shear, stacking cone compression, friction) for every above-deck container, reporting each lashing element load as a percentage of its safe working load. Rationale: The lashing rod load analysis is the core safety calculation — it determines whether the securing arrangement can withstand the combined dynamic forces experienced at sea. Balancing gravity, wind, and inertial forces against lashing rod capacity, twist-lock shear, and stack cone friction is the method prescribed by CSS Code Annex 13. | Test | subsystem, lashing, lashing-analyzer, session-285 |
| SUB-REQS-056 | The Racking Force Calculator SHALL compute transverse racking forces at each tier of every above-deck container stack using parametric and synchronous roll models, and SHALL flag any tier where the calculated racking force exceeds 75% of the ISO 1496-1 racking test load (150 kN for a 20ft unit, 300 kN for a 40ft unit). Rationale: Racking forces cause transverse deformation of container frames, a primary failure mode during heavy rolling. Parametric and synchronous roll models capture both steady-state and resonant roll conditions. Flagging violations before loading enables restowage while the vessel is still alongside, avoiding dangerous at-sea conditions. | Test | subsystem, lashing, racking, safety-critical, session-285 |
| SUB-REQS-057 | The Wind Force Estimator SHALL calculate windage forces on each exposed container face using wind speed profiles up to Beaufort 12 and container geometry from the bay plan, accounting for shielding factors from adjacent stacks and superstructure per CSS Code Annex 13 methodology. Rationale: Wind forces on above-deck container stacks are a significant component of the total lateral force at high Beaufort numbers. Accounting for shielding effects prevents overly conservative calculations that would unnecessarily reduce deck stowage capacity, while the Beaufort 12 upper bound covers the maximum operational sea state. | Test | subsystem, lashing, wind-force, session-285 |
| SUB-REQS-058 | The CSS Code Compliance Engine SHALL validate all securing arrangements against both the CSS Code Annex 13 simplified method and the vessel's approved Cargo Securing Manual, and SHALL reject any bay where any lashing element exceeds 100% SWL or any stack exceeds the bay stack weight limit. Rationale: Dual validation against both CSS Code Annex 13 and the vessel-specific Cargo Securing Manual is required because the CSM may impose additional vessel-specific constraints (e.g., reduced stacking weights for specific bays). The compliance engine is the final regulatory gate before loading authorization. | Test | subsystem, lashing, compliance, safety-critical, session-285 |
| SUB-REQS-059 | The Securing Equipment Database SHALL maintain a complete inventory of all vessel securing equipment including lashing rod types, turnbuckle models, twist-lock specifications, stacking cone ratings, and bridge fitting positions, with safe working load (SWL) values traceable to the equipment manufacturer's certification. Rationale: Lashing force calculations require precise securing equipment specifications — rod rated capacity, turnbuckle pre-tension, twist-lock shear strength. Maintaining a live inventory enables the calculator to account for damaged or missing equipment and to alert when replacement stock falls below minimum spares levels. | Inspection | subsystem, lashing, securing-database, session-285 |
| SUB-REQS-060 | When vessel motion sensor data is unavailable, the Lashing and Securing Calculator SHALL default to the CSS Code Annex 13 worst-case acceleration parameters for the vessel's deadweight class, and SHALL annotate all outputs with a reduced-confidence flag indicating that default rather than measured motion parameters were used. Rationale: Motion sensor data may be unavailable due to sensor failure or during dry-dock commissioning. Defaulting to CSS Code worst-case acceleration parameters ensures a conservative but regulatory-compliant calculation when measured motion data is not available, preventing a situation where lashing cannot be calculated at all. | Test | subsystem, lashing, degraded-mode, session-285 |
| SUB-REQS-061 | The Container Registry SHALL maintain the authoritative record for every container on board and planned for loading, including ISO container ID per ISO 6346, type/size code, tare weight, maximum gross weight, owner/operator code, booking reference, and seal numbers, supporting a minimum of 24,000 concurrent container records. Rationale: The Container Registry is the single source of truth for container attributes. ISO 6346 identification ensures globally unique container references. Maintaining both on-board and planned-for-loading containers enables pre-arrival stowage planning before the vessel reaches port. | Test | subsystem, container-tracking, registry, session-285 |
| SUB-REQS-062 | The Bay Plan Manager SHALL maintain real-time container-to-position mapping for all bays, rows, and tiers, and SHALL update slot occupancy within 5 seconds of receiving a confirmed crane move from the Crane Position Interface. Rationale: Real-time container-to-position mapping is the spatial complement to the Container Registry. The 5-second update window ensures the bay plan reflects crane operations in near-real-time, preventing double-allocation of slots during simultaneous multi-crane operations. | Test | subsystem, container-tracking, bay-plan, performance, session-285 |
| SUB-REQS-063 | The Container Event Logger SHALL record every container movement event (load, discharge, shift, restow) with UTC timestamp, operator ID, crane ID, source position, and destination position, and SHALL retain event records for the duration of the voyage plus 90 days. Rationale: A complete, immutable event log of every container movement provides the audit trail required by port authorities and the vessel's ISM safety management system. Including crane ID and operator ID enables accountability and performance analysis of cargo operations. | Test | subsystem, container-tracking, event-logger, session-285 |
| SUB-REQS-064 | The Container Status Engine SHALL manage container lifecycle states (booked, planned-load, loaded, in-transit, planned-discharge, discharged) with enforced valid state transitions, and SHALL trigger downstream recalculation notifications to stability, stowage, and reefer monitoring subsystems within 2 seconds of any state change. Rationale: Enforced state transitions prevent logically impossible container moves (e.g., discharging a container that was never loaded). The state machine model ensures data integrity across the registry and bay plan, and invalid transition attempts trigger alerts for investigation. | Test | subsystem, container-tracking, status-engine, session-285 |
| SUB-REQS-065 | The Crane Position Interface SHALL accept container identification and position confirmation from crane PLC systems via OPC-UA protocol, and SHALL validate that the confirmed position matches a planned stowage slot before updating the Bay Plan Manager. Rationale: Crane PLC confirmation provides ground truth for container positions. OPC-UA is the standard industrial protocol for crane automation systems. Validating confirmed positions against planned positions detects misloads in real time, before subsequent containers are stacked on top of an incorrectly placed unit. | Test | subsystem, container-tracking, crane-interface, session-285 |
| SUB-REQS-066 | The Booking and Manifest Linker SHALL reconcile pre-arrival booking lists against loaded containers and SHALL generate a discrepancy report identifying shorts, overs, and mis-shipped containers within 60 seconds of completing a port call loading sequence. Rationale: Booking-to-loaded reconciliation is a core commercial requirement — shorts, overs, and mis-shipments have financial and liability consequences. Generating discrepancy reports within 30 minutes of completing cargo operations allows resolution while the vessel is still alongside. | Test | subsystem, container-tracking, booking-linker, session-285 |
| SUB-REQS-067 | The EDI Message Parser and Translator SHALL parse and validate inbound EDIFACT messages conforming to UN/EDIFACT D.13B syntax rules at a sustained rate of no fewer than 200 messages per second, rejecting messages with syntax errors within 50ms and generating a structured error report per rejected message. Rationale: EDIFACT is the maritime industry standard for vessel-terminal data exchange. D.13B syntax rules are the minimum version supporting VGM-related message extensions. 200 messages/second sustained throughput covers peak arrival periods at major hub ports where multiple vessels submit plans simultaneously. | Test | subsystem, terminal-interface, session-286 |
| SUB-REQS-068 | The Terminal Operating System Connector SHALL maintain concurrent authenticated sessions with at least 20 distinct terminal operating systems simultaneously, supporting both REST API polling at configurable intervals (minimum 30-second resolution) and webhook-based push notifications, with per-connection TLS 1.3 mutual authentication. Rationale: Modern container vessels call at 8-12 ports per rotation, each with different TOS vendors. Supporting 20 concurrent sessions covers the pre-arrival connection setup for the next port while maintaining active sessions at the current port. REST API and SFTP support covers both modern and legacy TOS integration patterns. | Test | subsystem, terminal-interface, session-286 |
| SUB-REQS-069 | The Message Queue and Delivery Manager SHALL persist all queued messages to non-volatile storage and guarantee zero message loss during communication link outages lasting up to 48 hours, with automatic retransmission upon link restoration achieving full queue drain within 30 minutes of reconnection at available bandwidth. Rationale: Communication link outages are routine at sea (VSAT rain fade, high-latitude coverage gaps). The 48-hour store-and-forward requirement covers extended outages during ocean transits. Non-volatile persistence prevents message loss from power cycling, which is critical for SOLAS-mandated pre-arrival notifications. | Test | subsystem, terminal-interface, session-286 |
| SUB-REQS-070 | The Port Authority and Customs Interface SHALL generate and transmit pre-arrival notifications conforming to IMO FAL Convention Form 7 format at least 24 hours before port arrival, CUSCAR customs manifests at least 24 hours before arrival for non-EU and 4 hours for EU ports, and IFTDGN dangerous goods notifications at least 24 hours before arrival, with transmission confirmation receipt logging. Rationale: IMO FAL Convention requires pre-arrival notifications to port authorities at least 24 hours before arrival. Form 7 (Dangerous Goods Manifest) is mandatory under SOLAS VII. Automated generation from the cargo database eliminates manual transcription errors that could delay port entry clearance. | Demonstration | subsystem, terminal-interface, session-286 |
| SUB-REQS-071 | The Communication Link Manager SHALL detect primary VSAT link failure within 5 seconds and complete automatic failover to Inmarsat Fleet Broadband backup within 30 seconds, maintaining all active message queue sessions without requiring re-authentication, and SHALL fail back to the primary link within 60 seconds of primary link restoration. Rationale: VSAT is the primary shipboard communication link but has known failure modes (antenna tracking loss, transponder failure). The 5-second detection and 30-second failover window prevents message queue overflow and ensures time-critical messages (safety alerts, VGM rejections) reach shore within the operational response window. | Test | subsystem, terminal-interface, session-286 |
| SUB-REQS-072 | While operating on the backup Inmarsat link with bandwidth below 256 kbps, the Message Queue and Delivery Manager SHALL prioritise outbound messages in the order: (1) safety-critical notifications including IFTDGN and stability alerts, (2) regulatory submissions including CUSCAR and FAL forms, (3) operational messages including BAPLIE, COPARN, and MOVINS, (4) administrative traffic, with lower-priority messages queued but not discarded. Rationale: Inmarsat Fleet Broadband backup links have severely limited bandwidth (typically 150-256 kbps). Priority-based message queuing ensures safety-critical messages (distress, hazard alerts) are transmitted first, followed by regulatory obligations (pre-arrival notifications), before routine commercial traffic consumes the limited bandwidth. | Test | subsystem, terminal-interface, session-286 |
| SUB-REQS-073 | The Bay Plan Visualization Engine SHALL render a complete vessel bay plan for a 24,000 TEU vessel within 2 seconds of initial load and update the display within 500ms of any stowage plan change, supporting simultaneous display of container status, dangerous goods class, reefer status, weight, and lashing compliance as selectable overlay layers. Rationale: The bay plan is the primary operational display used by the cargo officer during loading/discharging. A 2-second initial render and 500ms update latency for a 24,000 TEU vessel ensure the display remains responsive during active operations where decisions must be made between crane cycles (typically 90-120 seconds per container move). | Test | subsystem, cargo-display, session-286 |
| SUB-REQS-074 | The Alarm and Notification Manager SHALL aggregate alarms from all cargo subsystems (stability, reefer, dangerous goods, VGM, lashing, stowage) and present them in a unified priority queue with three severity levels (critical, major, minor), requiring operator acknowledgment for critical alarms within 60 seconds before escalating to an audible alarm, and SHALL maintain a tamper-proof alarm log for the preceding 12 months. Rationale: Cross-subsystem alarm aggregation prevents the operator from needing to monitor multiple independent alarm panels. During correlated events (e.g., heavy weather triggering stability warnings, reefer power fluctuations, and lashing alerts simultaneously), a unified prioritized view enables triage by criticality rather than by subsystem. | Demonstration | subsystem, cargo-display, session-286 |
| SUB-REQS-075 | The What-If Simulation Engine SHALL evaluate the stability, longitudinal strength, dangerous goods compliance, and lashing adequacy impact of a proposed container move or set of up to 50 moves within 10 seconds for a 20,000 TEU load case, presenting results alongside current values with clear pass/fail indicators against classification society limits. Rationale: What-if simulation allows the cargo officer to evaluate proposed moves before execution, which is critical for avoiding stability violations that cannot be easily reversed once a container is placed. Multi-domain impact assessment (stability, strength, DG compliance, lashing) in a single simulation prevents piecemeal decision-making. | Test | subsystem, cargo-display, session-286 |
| SUB-REQS-076 | The Loading Sequence Display SHALL show the real-time status of up to 6 simultaneous gantry crane operations, updating crane positions and container moves within 5 seconds of each terminal-reported event, and SHALL highlight any out-of-sequence move, hatch cover conflict, or crane working area overlap with a visual and audible warning. Rationale: Modern ultra-large container vessels use 5-6 simultaneous gantry cranes during port calls. Showing real-time crane status and container moves within 5 seconds enables the cargo officer to coordinate operations across cranes and detect sequence deviations before they cascade into stowage conflicts. | Test | subsystem, cargo-display, session-286 |
| SUB-REQS-077 | The Reporting and Analytics Module SHALL generate port call summary reports within 30 minutes of departure including total containers handled (loaded, discharged, shifted), crane productivity (moves per hour per crane), cargo utilisation (TEU and weight as percentage of capacity), and SHALL maintain voyage-level statistics for a minimum of 5 years for fleet performance analysis and class society survey evidence. Rationale: Port call summary reports are required by both the ship operator (for operational KPI tracking) and the charterer (for demurrage/dispatch calculations). Generating within 30 minutes of departure enables transmission to shore operations while the communication link is still at port bandwidth before the vessel transitions to VSAT-only connectivity. | Demonstration | subsystem, cargo-display, session-286 |
| SUB-REQS-078 | The Stability and Stress Monitoring System SHALL perform a built-in test sequence at system startup and at intervals not exceeding 24 hours, verifying the integrity of hydrostatic data tables, vessel structural model parameters, and calculation algorithms against stored checksums, and SHALL display a clear test status indication to the operator. Rationale: Classification society type approval (DNV GL, Lloyd's Register, Bureau Veritas) requires loading instruments to perform self-diagnostics verifying data integrity before operational use. Hydrostatic table corruption or structural model parameter drift would produce silently incorrect stability calculations. Checksum verification at startup catches corruption from power events or storage degradation, while the 24-hour periodic check detects slow-onset faults. Clear operator indication ensures the watch officer does not rely on unverified calculation results. | Demonstration | self-test, stability, safety, validation, session-288 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| IFC-DEFS-001 | The Stability and Stress Monitoring System SHALL receive proposed loading sequences from the Stowage Planning Engine as structured container placement messages containing bay-row-tier position, gross weight, and container type (standard/high-cube/reefer/tank), and SHALL return a stability assessment result (approved, conditional, or rejected) with current GM, maximum permissible KG, and shear force utilisation percentage within 3 seconds per sequence. Rationale: The Stowage Planning Engine must send proposed load sequences to the SSMS for pre-move stability verification. JSON over IEC 61162-450 maritime Ethernet provides structured data exchange with sub-second latency required for real-time stability checking during cargo operations. | Test | |
| IFC-DEFS-002 | The Stability and Stress Monitoring System SHALL accept verified gross mass (VGM) data from the VGM Compliance and Weight Verification System for each container, using the VGM value as the authoritative weight input for all stability and strength calculations, and SHALL reject any container without a valid VGM certificate from weight calculations by substituting the declared maximum gross weight. Rationale: VGM data feeds directly into stability calculations via accurate container weights. Using the VGM value as the authoritative weight input eliminates the discrepancy between declared and actual weights that historically caused stability miscalculations. | Test | |
| IFC-DEFS-003 | The Stability and Stress Monitoring System SHALL publish real-time stability status to the Cargo Operations Display and Decision Support system at a minimum update rate of 0.5 Hz, providing current GM, trim, heel, shear force distribution profile, bending moment distribution profile, weather criterion ratio, and alarm state for each monitored parameter. Rationale: The Cargo Operations Display requires real-time stability data to present the cargo officer with current vessel state. A 2-second maximum update latency ensures the display reflects the most recent calculation and any active alarms. | Test | |
| IFC-DEFS-004 | The Stability and Stress Monitoring System SHALL interface with hull-mounted hydrostatic pressure draught sensors via a NMEA 0183 or NMEA 2000 serial data bus, receiving draught readings in metres referenced to keel baseline, and SHALL detect sensor failure within 5 seconds by monitoring message heartbeat and value range (0.5m to 25m for ULCV operating range). Rationale: Hull-mounted hydrostatic pressure sensors are the primary measurement input for actual vessel displacement and trim. NMEA 0183 or NMEA 2000 serial data bus is the maritime standard for sensor interfacing, ensuring compatibility with classification-approved transducers. | Test | |
| IFC-DEFS-005 | When a critical stability or strength alarm is generated, the Stability and Stress Monitoring System SHALL transmit the alarm to the bridge alarm management system via IEC 61162-450 (maritime Ethernet) within 1 second, including alarm category, parameter name, current value, and limit value, formatted as an ALR sentence. Rationale: Critical stability or strength alarms must reach the ship safety system for inclusion in the integrated alarm management per SOLAS Chapter II-1 Regulation 30. IEC 61162-450 maritime Ethernet provides the bandwidth and determinism needed for alarm transmission within 1 second. | Test | |
| IFC-DEFS-006 | The interface between the Stowage Planning Engine and the Container Tracking and Inventory System SHALL provide the load list (container ID, size, type, weight, POD, hazard class, reefer flag) in BAPLIE-compatible format with a maximum transfer latency of 5 seconds for a full 20,000 TEU manifest. Rationale: The Stowage Planning Engine cannot produce valid plans without real-time container inventory and booking data. The Container Tracking System is the authoritative source for container dimensions, weights, and port of discharge, which are mandatory inputs for every stowage optimization calculation. | Test | interface, stowage-planning-engine, session-280 |
| IFC-DEFS-007 | The interface between the Stowage Planning Engine and the Stability and Stress Monitoring System SHALL transmit proposed loading sequences as structured container placement messages containing bay, row, tier, container weight, and VGM, receiving stability verification responses (GM, trim, shear force, bending moment status) within 3 seconds per loading step evaluation. Rationale: Every proposed loading sequence must be verified against stability and structural limits before execution. This interface enables closed-loop validation where the SSMS returns pass/fail with margin data, preventing the planner from generating sequences that would put the vessel outside class-approved loading conditions. | Test | interface, stowage-planning-engine, session-280 |
| IFC-DEFS-008 | The interface between the Stowage Planning Engine and the Lashing and Securing Calculator SHALL transmit stack configurations (container weights, heights, and positions within each on-deck stack) and receive lashing force compliance results (pass/fail with force margins) within 2 seconds per stack evaluation. Rationale: Stack weight and tier height data determines lashing rod and turnbuckle requirements per CSS Code. The Lashing Calculator needs exact stack configurations to compute forces, because on-deck container stacks experience wind, roll, and pitch accelerations that vary by bay position and stack height. | Test | interface, stowage-planning-engine, session-280 |
| IFC-DEFS-009 | The interface between the Stowage Planning Engine and the Dangerous Goods Management System SHALL provide hazard class, UN number, and packing group for each dangerous goods container, and receive validated segregation distance matrices and stowage category restrictions, with full manifest validation completing within 10 seconds. Rationale: DG segregation constraints must be enforced during stowage optimization, not after. Providing hazard class and UN number data to the DG Management System at planning time enables pre-placement segregation checking, avoiding the costly cycle of plan-check-reject-replan. | Test | interface, stowage-planning-engine, session-280 |
| IFC-DEFS-010 | The interface between the Stowage Planning Engine and the Reefer Container Management System SHALL query available reefer plug locations by bay and tier, receiving current allocation status and power capacity per bay, and the Stowage Planning Engine SHALL not assign a reefer container to a slot without a confirmed available reefer plug. Rationale: Reefer containers require powered outlet slots. The stowage engine must query available reefer plug counts by bay to avoid placing reefer containers in unpowered positions. Over-allocation of reefer plugs is a common cause of cargo claims on vessels carrying 1,000+ reefer units. | Test | interface, stowage-planning-engine, session-280 |
| IFC-DEFS-011 | The interface between the DG Declaration Validator and the IMDG Code Database SHALL support synchronous query-response lookup by UN number, returning the complete DG entry (hazard class, division, packing group, stowage category, segregation groups, EmS references, and special provisions) within 10 milliseconds per query. Rationale: Synchronous query-response is required because declaration validation is a blocking operation — the DG officer cannot approve a booking until the UN number lookup and classification check completes. Asynchronous processing would create a backlog during peak booking periods when hundreds of DG declarations arrive within minutes. | Test | interface, dg-management, session-281 |
| IFC-DEFS-012 | The interface between the Segregation Rules Engine and the IMDG Code Database SHALL provide batch query capability for segregation group membership and Table 7.2.4 compatibility data, accepting a list of UN numbers and returning the complete segregation profile (primary class, subsidiary risks, SGG memberships) for each within 50 milliseconds for batches of up to 100 entries. Rationale: Batch query capability allows the Segregation Rules Engine to request segregation data for all DG containers in a bay or hold in a single call, reducing the number of database round-trips from O(n squared) pair lookups to O(n) batch fetches. This is critical for meeting the 5-second per-bay evaluation time target. | Test | interface, dg-management, session-281 |
| IFC-DEFS-013 | The interface between the DG Stowage Position Validator and the Segregation Rules Engine SHALL accept a proposed container placement (UN number, bay, row, tier) and a list of all other DG containers currently stowed, and SHALL return a segregation compliance result (pass with minimum margins, or fail with each violated pair and required separation distance) within 500 milliseconds. Rationale: The DG Stowage Position Validator must receive segregation rule results in context of a specific proposed position (bay, row, tier) to evaluate three-dimensional separation compliance. This interface decouples rule lookup from position validation, allowing the segregation engine to be updated independently of the stowage validation logic. | Test | interface, dg-management, session-281 |
| IFC-DEFS-014 | The interface between the DG Manifest Generator and the DG Declaration Validator SHALL provide access to all validated DG declaration records for containers currently aboard, including UN number, proper shipping name, hazard class and division, packing group, net quantity, number of packages, EmS reference, and shipper certification status, with data freshness no greater than 60 seconds from the last validation update. Rationale: The DG Manifest Generator needs validated declaration records as its input because it must not include unvalidated or rejected declarations in the statutory manifest. This interface ensures only declarations that have passed IMDG Code compliance checking appear in the IMO FAL Form 7 output. | Test | interface, dg-management, session-281 |
| IFC-DEFS-015 | The interface between the Dangerous Goods Management System and the Stowage Planning Engine SHALL transmit stowage constraint data comprising: for each DG container, the list of prohibited bay-row-tier positions, required minimum separation distances from each other DG container aboard, and stowage category restrictions, formatted as constraint sets consumable by the Stowage Optimization Engine within 2 seconds for a full vessel DG load of up to 500 containers. Rationale: Stowage constraint transmission from the DG system to the planning engine closes the loop between DG compliance and stowage optimization. Without this interface, the planner would have to run DG checks as a post-processing step, resulting in iterative reject-replan cycles that can double solve times. | Test | interface, dg-management, cross-subsystem, session-281 |
| IFC-DEFS-016 | The interface between the Reefer Monitoring Unit and the Temperature Alarm Processor SHALL transmit container identification, bay-row-tier location, supply air temperature, return air temperature, cargo setpoint, and timestamp for each polled container via an internal message bus with delivery latency not exceeding 5 seconds. Rationale: The Temperature Alarm Processor requires container identification, supply air temperature, return air temperature, and setpoint from each polling cycle to perform per-container threshold evaluation. Without container-level identification, alarms cannot be routed to the correct reefer bay for crew response. | Test | interface, reefer, session-282 |
| IFC-DEFS-017 | The interface between the Reefer Monitoring Unit and the Reefer Data Logger SHALL transmit the complete polling record (all acquired parameters including supply air temperature, return air temperature, setpoint, compressor status, power draw, and fault codes) for each container at each polling interval, with guaranteed delivery and sequence ordering. Rationale: The Reefer Data Logger must receive complete polling records including all sensor channels to produce tamper-evident logs that satisfy USDA and ATP regulatory requirements. Incomplete records would create gaps in the continuous temperature chain-of-custody documentation. | Test | interface, reefer, session-282 |
| IFC-DEFS-018 | The interface between the Reefer Monitoring Unit and the Reefer Power Distribution Controller SHALL exchange outlet power status (energised, tripped, load-shed) and container-to-outlet mapping, updated within 10 seconds of any state change. Rationale: Bidirectional power status exchange between the Reefer Monitoring Unit and Power Distribution Controller is required for coordinated load-shedding. The monitoring unit must know which outlets are energised to avoid polling disconnected containers, and the power controller must receive monitoring data to inform load-shedding priority decisions. | Test | interface, reefer, session-282 |
| IFC-DEFS-019 | The interface between the Pre-Trip Inspection Module and the Reefer Monitoring Unit SHALL transmit PTI results including pass/fail verdict, measured pull-down performance, and confirmed setpoint for each inspected container, enabling the RMU to initialise monitoring with validated baseline parameters. Rationale: PTI results must be transmitted to the Reefer Monitoring Unit so that containers failing pre-trip inspection are flagged before the vessel sails. This prevents scenarios where a failed-PTI container is loaded, connected, and only discovered as non-functional mid-voyage when replacement is impossible. | Test | interface, reefer, session-282 |
| IFC-DEFS-020 | The interface between the Controlled Atmosphere Monitor and the Temperature Alarm Processor SHALL transmit O2 concentration, CO2 concentration, and atmosphere recipe deviation status for each CA reefer container, enabling the alarm processor to generate consolidated temperature-plus-atmosphere alarms. Rationale: Controlled atmosphere deviations (O2 or CO2 outside setpoint) require the same alarm processing pipeline as temperature deviations because they pose equivalent cargo damage risk. Routing CA data through the Temperature Alarm Processor avoids duplicating alarm prioritisation and escalation logic. | Test | interface, reefer, session-282 |
| IFC-DEFS-021 | The interface between the Reefer Power Distribution Controller and the Temperature Alarm Processor SHALL transmit power fault events (overload trip, ground fault, phase loss, load-shed activation) with affected outlet identification within 2 seconds of fault detection. Rationale: Power fault events (overload trips, ground faults, phase loss) directly affect reefer container temperature maintenance. The Temperature Alarm Processor must correlate power fault notifications with temperature trends to distinguish power-related temperature excursions from mechanical compressor failures, enabling correct crew response actions. | Test | interface, reefer, session-282 |
| IFC-DEFS-022 | The interface between the VGM Declaration Receiver and the Terminal Interface and EDI Gateway SHALL receive VERMAS EDI messages in UN/EDIFACT D.13B or later format via TCP/IP, supporting message sizes up to 500 KB per transmission and batch files containing up to 2,000 individual declarations. Rationale: SOLAS VI/2 requires verified gross mass (VGM) before loading. VERMAS is the standard EDI message type for VGM exchange between terminals and vessels. The 500 KB limit and 1000-container batch support cover the maximum throughput during simultaneous multi-berth operations at major hub ports. | Test | interface, vgm, session-284 |
| IFC-DEFS-023 | The interface between the Weighbridge Data Interface and terminal weighing equipment SHALL support Modbus TCP (function codes 03 and 04), OPC-UA (DA profile), and RS-232 serial at 9600-115200 baud, with automatic protocol detection and a maximum measurement acquisition latency of 500 milliseconds from trigger to recorded value. Rationale: Terminal weighing equipment varies widely — older installations use serial/Modbus, newer systems use OPC-UA. Multi-protocol support with auto-detection is necessary to interface with the diverse installed base across global port calls without requiring per-port configuration. The 200ms measurement latency supports continuous truck-scale weighing during gate operations. | Test | interface, vgm, session-284 |
| IFC-DEFS-024 | The interface between the VGM Compliance Validator and the Stowage Planning Engine SHALL transmit container loading authorization status (AUTHORIZED, CONDITIONAL, HOLD, REJECTED) with container number, verified gross mass, and authorization timestamp, using a publish-subscribe message pattern with delivery latency not exceeding 500 milliseconds. Rationale: The Stowage Planning Engine must know container loading authorization status in real time to prevent stowing containers with unverified or disputed gross mass. The four-state model (AUTHORIZED/CONDITIONAL/HOLD/REJECTED) captures the regulatory nuances where some containers may load conditionally pending shipper Method 2 recertification. | Test | interface, vgm, session-284 |
| IFC-DEFS-025 | The interface between the Container Weight Database and the Stability and Stress Monitoring System SHALL provide verified gross mass values for individual containers with a query response time not exceeding 50 milliseconds, using the container number as the lookup key, and SHALL include a confidence indicator distinguishing weighbridge-verified weights from declaration-only weights. Rationale: Stability calculations use individual container weights as primary inputs. The 50ms query response ensures that recalculating stability for a full vessel loading sequence (up to 24,000 TEU) completes within the 60-second planning cycle required by the stowage optimizer. Container number plus booking reference form the composite key per SOLAS VGM verification requirements. | Test | interface, vgm, session-284 |
| IFC-DEFS-026 | The interface between the Container Weight Database and the Container Tracking and Inventory System SHALL synchronize VGM status and verified gross mass for each container, updating the inventory record within 1 second of any VGM status change, using the container number as the common identifier. Rationale: The Container Tracking inventory must reflect current VGM status so that the cargo officer sees a unified view of container readiness. The 1-second synchronization window prevents race conditions where a container appears loadable in the bay plan before its VGM has been validated. | Test | interface, vgm, session-284 |
| IFC-DEFS-027 | The interface between the VGM Reporting and Audit Module and the Cargo Operations Display and Decision Support system SHALL provide real-time VGM compliance dashboard data including total declarations received, coverage percentage, discrepancy counts by severity, and pending authorizations, refreshed at intervals not exceeding 10 seconds. Rationale: The cargo officer needs a consolidated VGM compliance view to make loading go/no-go decisions. Real-time dashboard data (coverage percentage, discrepancy counts) provides situational awareness during cargo operations where a single non-compliant container can delay vessel departure. | Demonstration | interface, vgm, session-284 |
| IFC-DEFS-028 | The interface between the Lashing and Securing Calculator and the Stowage Planning Engine SHALL provide container weight, position, and tier data at bay granularity via a synchronous request-response API, with the Stowage Planning Engine requesting lashing compliance verification for each proposed stowage plan before acceptance. Rationale: Lashing validation depends on precise container weight and position data. Bay-granularity synchronous queries ensure the lashing force calculations reflect the exact current or proposed stowage arrangement. Asynchronous updates would risk calculating lashing forces against stale positions during active cargo operations. | Test | interface, lashing, cross-subsystem, session-285 |
| IFC-DEFS-029 | The interface between the Stability and Stress Monitoring System and the Lashing and Securing Calculator SHALL transmit current metacentric height (GM), natural roll period, and significant wave height parameters at 10-second intervals, formatted as a structured message containing vessel motion state for securing force calculations. Rationale: Lashing force calculations per CSS Code require current metacentric height (GM) and roll period to determine dynamic acceleration components. The 10-second update interval matches the stability system's calculation cycle and ensures lashing assessments reflect the vessel's current loading condition rather than a stale stability state. | Test | interface, lashing, stability, session-285 |
| IFC-DEFS-030 | The interface between the Container Tracking and Inventory System and the Terminal Interface and EDI Gateway SHALL exchange BAPLIE (bay plan), COPARN (booking confirmation), and CODECO (gate movement) messages in UN/EDIFACT D.95B or later format, with message acknowledgement within 30 seconds of receipt. Rationale: BAPLIE, COPARN, and CODECO are the industry-standard EDIFACT message types for bay plan exchange, booking confirmation, and gate movements respectively. UN/EDIFACT D.95B is the minimum version supporting container weight fields required by SOLAS VGM amendments. The 2000-container batch supports full vessel plan exchange at ultra-large container ship scale. | Test | interface, container-tracking, terminal-edi, session-285 |
| IFC-DEFS-031 | The interface between the Container Tracking and Inventory System and the Stowage Planning Engine SHALL provide real-time slot occupancy and container attribute data, with the Bay Plan Manager responding to slot availability queries within 500 milliseconds for any single bay and within 2 seconds for the full vessel. Rationale: The Stowage Planning Engine needs real-time slot occupancy to avoid double-booking positions. The 500ms query response time supports the iterative optimization loop where the planner evaluates hundreds of candidate slot placements per planning cycle. | Test | interface, container-tracking, stowage, session-285 |
| IFC-DEFS-032 | The interface between the Container Tracking and Inventory System and the VGM Compliance and Weight Verification System SHALL synchronize verified gross mass values to the Container Registry within 5 seconds of VGM validation, and SHALL flag any container whose VGM differs from the booking-declared weight by more than 5%. Rationale: Synchronizing VGM values into the Container Registry within 5 seconds ensures the bay plan and stowage optimizer always have current weight data. Flagging containers with VGM discrepancies exceeding 5% directly in the registry prevents loading operations from proceeding with suspect weight data, which could compromise stability calculations. | Test | interface, container-tracking, vgm, session-285 |
| IFC-DEFS-033 | The interface between the EDI Message Parser and Translator and the Message Queue and Delivery Manager SHALL exchange parsed message objects via an internal message bus using a structured JSON envelope containing message type, priority level, source terminal ID, timestamp, and parsed payload, with the queue acknowledging receipt within 10ms. Rationale: Decoupling EDI parsing from message delivery via a message bus allows independent scaling and failure isolation. The structured JSON envelope with priority levels ensures time-critical messages (e.g., VGM rejections, loading holds) are processed ahead of routine status updates during peak cargo operations. | Test | interface, terminal-interface, session-286 |
| IFC-DEFS-034 | The interface between the Communication Link Manager and the Message Queue and Delivery Manager SHALL provide link status notifications (up/down/degraded, available bandwidth in kbps, measured latency in ms) within 2 seconds of any link state change, and the Message Queue SHALL adjust its transmission scheduling and compression settings based on the reported available bandwidth. Rationale: The Message Queue must know link state to prioritize and batch messages appropriately. The 2-second notification window ensures the queue can switch to store-and-forward mode before message loss occurs during VSAT outages, which are common during high-latitude transits. | Test | interface, terminal-interface, session-286 |
| IFC-DEFS-035 | The interface between the Terminal Operating System Connector and the EDI Message Parser and Translator SHALL pass raw inbound messages with metadata (source TOS identifier, connection ID, received timestamp, message encoding) and accept formatted outbound messages with destination routing information, supporting message sizes up to 10 MB for complete BAPLIE load plans. Rationale: Each terminal operates a different TOS with proprietary message wrappers. Passing raw messages with metadata (source TOS ID, encoding, timestamp) to the parser allows protocol-specific decoding without the TOS Connector needing to understand message semantics, enabling support for new TOS integrations through parser configuration rather than connector changes. | Test | interface, terminal-interface, session-286 |
| IFC-DEFS-036 | The interface between the Alarm and Notification Manager and the subsystem alarm sources (Stability Alarm and Advisory Generator, Temperature Alarm Processor, Weight Discrepancy Detector, CSS Code Compliance Engine, Segregation Rules Engine) SHALL receive alarm events via a publish-subscribe pattern with each event containing: source subsystem, severity (critical/major/minor), alarm code, timestamp, affected component identifiers, and human-readable description, with maximum propagation delay of 500ms from source to display. Rationale: Centralizing alarm aggregation prevents alarm flooding where multiple subsystems generate correlated alarms (e.g., stability warning plus lashing overload plus reefer power loss during heavy weather). A unified alarm format with severity, source, and timestamp enables the operator to triage by criticality rather than by subsystem. | Test | interface, cargo-display, session-286 |
| IFC-DEFS-037 | The interface between the What-If Simulation Engine and the calculation services (Intact Stability Computer, Stowage Optimization Engine, CSS Code Compliance Engine) SHALL support synchronous request-response calls where the simulation engine submits a proposed load case modification and receives complete recalculated results (stability parameters, strength values, compliance status) within 8 seconds, with the calculation services operating in read-only mode without modifying the current operational load case. Rationale: What-if simulations must invoke the same calculation engines used in operational mode to ensure simulation results match real outcomes. Synchronous request-response ensures the simulation completes a full stability-lashing-compliance check before presenting results, preventing the cargo officer from acting on partial assessments. | Test | interface, cargo-display, session-286 |
| IFC-DEFS-038 | The interface between the Loading Sequence Display and the Container Tracking and Inventory System (Container Status Engine and Bay Plan Manager) SHALL receive container move events (load, discharge, shift, restow) with crane identifier, bay-row-tier position, container ID, and timestamp, updating the loading progress view within 5 seconds of each event, and SHALL query the Bay Plan Manager for planned versus actual sequence comparison. Rationale: The loading sequence display must reflect real-time crane movements to guide the cargo officer. Container move events with crane identifier and bay-row-tier position allow the display to show per-crane progress and flag any deviation from the planned loading sequence, which is critical for maintaining interim stability during cargo operations. | Test | interface, cargo-display, session-286 |
| IFC-DEFS-039 | The Container Ship Cargo Management System SHALL interface with the vessel ballast control system via a serial data link conforming to IEC 61162-450 to receive real-time tank sounding data including fill level, temperature, and density for all ballast tanks, and SHALL transmit recommended ballast operations to the ballast control system for operator confirmation. Rationale: Ballast operations directly affect vessel stability, trim, and stress. Real-time tank sounding data via IEC 61162-450 enables the stability calculation to reflect actual ballast conditions rather than planned values, preventing dangerous discrepancies during simultaneous cargo and ballast operations. Bidirectional communication with operator confirmation prevents automated ballast changes without human oversight, meeting SOLAS Chapter II-1 Regulation 22 requirements for safe loading condition management. | Test | interface, ballast, stability, validation, session-288 |
| IFC-DEFS-040 | The Container Ship Cargo Management System SHALL receive meteorological data including wind speed, wind direction, significant wave height, and wave period from the vessel weather routing system or onboard weather station via NMEA 0183 or IEC 61162-1, and SHALL use actual wind speed data as input to the Wind Force Estimator for lashing force calculations when available. Rationale: Actual wind speed is the dominant variable in above-deck container lashing force calculations per CSS Code Annex 13. Design values assume worst-case conditions and produce conservative lashing assessments that may unnecessarily restrict container weights or stack heights. Using measured wind data from the onboard weather station allows the Wind Force Estimator to compute forces based on actual conditions, improving stowage utilisation while maintaining safety margins. The 60-second fallback ensures lashing calculations never use stale wind data. | Test | interface, weather, lashing, validation, session-288 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| ARC-DECISIONS-001 | The Stability and Stress Monitoring System SHALL be decomposed into six components: Intact Stability Computer, Longitudinal Strength Monitor, Damage Stability Assessor, Draught Sensor Interface, Stability Alarm and Advisory Generator, and Loading Condition Database. The Intact Stability Computer and Longitudinal Strength Monitor operate as parallel computation pipelines fed by a common Draught Sensor Interface, with both feeding the Alarm Generator. The Damage Stability Assessor is driven by intact stability results rather than raw sensor data, reflecting its dependency on the current equilibrium condition. The Loading Condition Database is shared storage accessed by all computational components. Rationale: Decomposing the SSMS into six functional components separates independent computational domains (intact stability, damage stability, longitudinal strength, free surface, draught sensing, alarming) enabling parallel development, independent verification, and clear interface definition between calculation engines. | Inspection | |
| ARC-DECISIONS-002 | ARC: Stowage Planning Engine — Decomposed into seven components separating the vessel physical model (Vessel Stowage Model) from the optimization logic (Stowage Optimization Engine) and operational sequencing (Crane Split Calculator, Hatch Cover Sequence Planner). The Port Rotation Planner and Restow Minimization Module are separated from the core optimizer because voyage-level planning operates on a different time horizon (days) than per-port stowage optimization (minutes), and their outputs serve as constraints to rather than integral parts of the placement algorithm. The Stowage Rules Database is isolated to allow vessel-class-specific and regulatory constraint updates without modifying optimization code. This separation supports independent verification of safety-critical constraint enforcement (IMDG segregation, structural limits) from optimization heuristics. Rationale: Separating the vessel physical model from optimization logic enables independent validation of the ship model against classification society data, while optimization algorithms can be updated without re-certifying the vessel model. Operational services (crane split, hatch cover sequencing, restow minimization) are separated because they serve different planning phases and user roles. | Analysis | architecture, stowage-planning-engine, session-280 |
| ARC-DECISIONS-004 | ARC: Dangerous Goods Management System — Decomposed into six components with the IMDG Code Database as the central reference hub. The Segregation Rules Engine and DG Stowage Position Validator are separated rather than merged because segregation (inter-container compatibility) and stowage (position-to-rule compliance) are governed by different IMDG Code chapters (7.2 vs 7.1) and require different evaluation geometries: segregation operates on pairwise container distances in 3D hold space, while stowage validates individual positions against categorical rules. The Emergency Response Information System is architecturally independent to ensure availability during main system degradation — a critical safety requirement for incident response at sea. The DG Manifest Generator aggregates from the Declaration Validator and Stowage Position Validator rather than reading the IMDG Database directly, enforcing data flow through validated pathways. Rationale: The IMDG Code Database as central hub enforces a single source of truth for DG classification data. Separating segregation from stowage validation reflects the distinct IMDG Code chapters (7.2 vs 7.1) and evaluation geometries. The Emergency Response System is independent to maintain availability during main system outages — critical for incident response at sea where shore support may be delayed. | Inspection | architecture, dg-management, session-281 |
| ARC-DECISIONS-006 | ARC: Reefer Container Management System — Separated monitoring, power distribution, and alarm processing into independent components rather than a monolithic reefer management controller. The Reefer Monitoring Unit handles data acquisition via RS-485/Ethernet polling, while the Temperature Alarm Processor evaluates readings against cargo-specific thresholds independently. This separation ensures alarm processing continues even if the monitoring polling cycle is delayed, and allows the Power Distribution Controller to operate autonomously during monitoring software updates. The Controlled Atmosphere Monitor is isolated because CA technology applies to only 5-15 percent of the reefer fleet but requires specialised gas composition analysis distinct from temperature monitoring. Pre-Trip Inspection is separated because it operates only in port and interfaces with terminal systems, unlike the at-sea monitoring components. Rationale: Separating monitoring from alarm processing ensures alarm evaluation continues even during polling delays or software updates. The Power Distribution Controller operates autonomously because power fault response must not depend on monitoring software availability. CA monitoring is isolated because it applies to a small fraction of the reefer fleet and uses fundamentally different sensor technology. | Inspection | architecture, reefer, session-282 |
| ARC-DECISIONS-008 | ARC: VGM Compliance and Weight Verification System — Separated discrepancy detection from compliance validation as distinct components rather than combining them into a single validation engine. The Weight Discrepancy Detector performs numerical comparison of declared versus measured weights and applies tolerance thresholds, while the VGM Compliance Validator handles regulatory checks (authorized weigher status, weighing method identification, declaration completeness). This separation ensures that regulatory compliance logic can be updated independently when SOLAS amendments or flag state circulars change, without affecting the measurement comparison algorithms. Alternative considered: a single monolithic VGM validator. Rejected because regulatory requirements change on different cycles than measurement tolerance standards, and because the discrepancy detection function serves the stability system independently of compliance status. Rationale: Separating discrepancy detection from compliance validation allows independent tuning of weight tolerance thresholds (operational concern) versus regulatory reporting rules (SOLAS compliance concern). The weighbridge interface is isolated because terminal weighing equipment protocols vary widely across ports. | Inspection | architecture, vgm, session-284 |
| ARC-DECISIONS-009 | ARC: Lashing and Securing Calculator — Decomposed into separate force calculators (stack weight, racking, wind) feeding a central Lashing Rod Load Analyzer, with a CSS Code Compliance Engine as the final validation gate. This topology separates physical force domains (gravity, inertia, aerodynamic) for independent validation and allows the compliance engine to apply both CSS Code Annex 13 simplified and advanced methods without coupling to force calculation internals. Alternative of a monolithic calculator rejected because CSS Code updates (e.g., MSC.1/Circ.1352 amendments) would require regression across all force models simultaneously. Rationale: Separating force calculators by physical phenomenon (stack weight, racking, wind) mirrors the independent engineering models in the CSS Code Annex 13, enabling each calculator to be validated and certified independently. The CSS Code Compliance Engine acts as the final gate to ensure the combined result meets regulatory thresholds. | Analysis | architecture, lashing, session-285 |
| ARC-DECISIONS-010 | ARC: Container Tracking and Inventory System — Organised around a Container Registry (master data) and Bay Plan Manager (spatial data) as twin data authorities, with a Container Status Engine implementing a state machine for container lifecycle transitions. Crane Position Interface decoupled from Bay Plan Manager via event-driven updates rather than direct writes, ensuring the audit trail (Container Event Logger) captures every state change. Booking and Manifest Linker separated from Container Registry to isolate commercial data volatility from physical container records. Alternative of a unified container database rejected because booking data changes at port-pair granularity while physical attributes are static per voyage. Rationale: Separating Container Registry (master data) from Bay Plan Manager (spatial data) reflects the two fundamental data models: container attributes (weight, type, DG class) are independent of position, while slot occupancy depends on the vessel's physical geometry. This separation prevents data coupling where a registry update could corrupt spatial state. | Analysis | architecture, container-tracking, session-285 |
| ARC-DECISIONS-013 | ARC: Terminal Interface and EDI Gateway — Decomposed into five components: EDI Message Parser and Translator for EDIFACT/XML protocol handling, Terminal Operating System Connector for multi-TOS integration, Message Queue and Delivery Manager for reliable store-and-forward over satellite links, Port Authority and Customs Interface for regulatory reporting (FAL Convention, CUSCAR), and Communication Link Manager for VSAT/Inmarsat/4G failover. The message queue is the architectural spine — all inbound and outbound traffic flows through it to guarantee delivery despite maritime link unreliability. Direct point-to-point connections between external systems and internal subsystems were rejected in favour of this hub pattern to provide a single point of message audit, compression, and prioritisation. Rationale: Separating EDI parsing from TOS connectivity allows supporting multiple terminal operating systems without modifying the protocol handler. The Communication Link Manager is isolated because VSAT/4G link management (bandwidth monitoring, failover) is independent of message semantics and requires dedicated watchdog logic. | Analysis | architecture, terminal-interface, session-286 |
| ARC-DECISIONS-015 | ARC: Cargo Operations Display and Decision Support — Decomposed into five components: Bay Plan Visualization Engine for graphical vessel representation, Loading Sequence Display for real-time crane operations tracking, Alarm and Notification Manager for cross-subsystem alert aggregation, What-If Simulation Engine for decision support scenario analysis, and Reporting and Analytics Module for operational and regulatory reporting. The alarm manager is the safety-critical integration point — it aggregates from all other subsystems (stability, reefer, DG, VGM, lashing) into a single prioritised stream for the cargo officer, following ISM Code alarm management principles. The what-if engine reuses the stability and stowage calculation engines rather than duplicating them, calling them as services for scenario evaluation. Rationale: Separating visualization (Bay Plan Visualization Engine, Loading Sequence Display) from computation (What-If Simulation Engine) follows the model-view separation principle. The Alarm and Notification Manager aggregates cross-subsystem alarms into a single operator view, preventing alarm flooding during correlated failure scenarios. | Analysis | architecture, cargo-display, session-286 |
| Ref | Requirement | V&V | Tags |
|---|---|---|---|
| VER-METHODS-001 | The intact stability calculation (SUB-SSMS-002) SHALL be verified by loading 50 pre-computed test conditions from the vessel's approved stability booklet and comparing system-calculated GM, GZ curve values, and weather criterion ratios against the booklet values, with maximum permissible deviation of 1% for GM and 2% for GZ ordinates. Rationale: Comparing system output against class-approved hydrostatic data for 50 conditions validates both the calculation algorithms and the hydrostatic data tables. The 0.01m GM tolerance matches classification society acceptance criteria for stability instrument type approval. | Test | |
| VER-METHODS-002 | The longitudinal strength computation (SUB-SSMS-003) SHALL be verified by comparing system-calculated shear force and bending moment values at all frame stations against an independent FEA-validated reference model for 20 loading conditions, with maximum deviation of 3% at any station. Rationale: Classification society approval of loading instruments requires demonstration that shear force and bending moment calculations match approved finite element analysis within defined tolerances. The 2 percent tolerance aligns with IACS UR S11 acceptance criteria. | Test | |
| VER-METHODS-003 | The alarm generation system (SUB-SSMS-007) SHALL be verified by injecting simulated stability and strength values at each alarm threshold boundary (80%, 90%, 95% of limits) and measuring alarm latency, correctness of alarm category, and completeness of displayed information, across all monitored parameters. Rationale: Alarm system verification requires controlled injection of values at each threshold boundary to confirm correct alarm state transitions and timing. This is a standard type-approval test procedure for maritime safety systems per IEC 62923. | Test | |
| VER-METHODS-004 | The draught sensor interface (IFC-SSMS-IFC-004) SHALL be verified by connecting a NMEA signal simulator generating known draught values across the 0.5-25m range at 1 Hz, and validating that the system acquires, validates, and resolves readings into mean draught, trim, and heel within the specified accuracy, and detects simulated sensor failure within 5 seconds. Rationale: NMEA signal simulation is the standard method for verifying maritime sensor interfaces without requiring physical sensors. Testing against known draught values validates the entire signal acquisition chain from connector to displayed value. | Test | |
| VER-METHODS-005 | The probabilistic damage stability assessment (SUB-SSMS-004) SHALL be verified by comparing system-calculated attained subdivision index against classification society approved calculations for at least 10 representative loading conditions, with the attained index agreeing within 0.005. Rationale: Classification societies require independent verification of damage stability calculations against approved methods. The 0.005 tolerance on the subdivision index matches DNV GL and Lloyd Register type-approval criteria for stability instruments. | Test | |
| VER-METHODS-006 | The degraded mode operation (SUB-SSMS-009) SHALL be verified by systematically disabling one and then two draught sensors and confirming that the system continues to calculate stability parameters with draught accuracy within plus or minus 5 cm compared to a calibrated reference, and that the degraded state indication appears on all display outputs within 2 seconds of sensor loss. Rationale: Degraded mode testing validates that the system correctly detects sensor loss, adjusts its calculation methodology, and alerts operators. The 5 cm accuracy and 2-second indication thresholds must be verified under controlled conditions before operational approval. | Test | |
| VER-METHODS-007 | The IMO weather criterion evaluation (SUB-SSMS-010) SHALL be verified by loading at least 5 test conditions with known weather criterion results from approved stability booklet calculations and confirming that the system-calculated beam wind heeling lever, roll-back angle, and area ratios agree within 2 percent of the approved values. Rationale: The weather criterion is the most common stability failure mode for container ships due to high windage area. Verification against approved booklet values ensures the system correctly implements the complex multi-step A.749(18) Regulation 3.2 calculation. | Test | |
| VER-METHODS-009 | The stowage planning interface (IFC-SSMS-IFC-001) SHALL be verified by transmitting 100 representative loading sequences from the Stowage Planning Engine test harness and confirming that the SSMS receives, parses, and initiates stability calculation for each sequence within 500 milliseconds, with zero message loss over IEC 61162-450 maritime Ethernet. Rationale: The stowage planning interface is the most frequently exercised data path during cargo operations. Verification must demonstrate both throughput and reliability because a dropped or delayed stability check could allow an unsafe loading move to proceed. | Test | |
| VER-METHODS-010 | Verify IFC-DEFS-006: Inject a synthetic 20,000 TEU manifest from the Container Tracking system to the Stowage Planning Engine. Measure end-to-end transfer time from request to full manifest availability in SPE memory. Pass criteria: transfer completes within 5 seconds with zero container record loss. Repeat with manifests containing malformed records to verify error handling. Rationale: Tests the full data pipeline from Container Tracking to Stowage Planning at maximum vessel capacity (20,000 TEU). Synthetic manifest injection is chosen over live data to ensure reproducible test conditions and cover edge cases (overweight containers, special cargo types) that may not appear in operational data. | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-011 | Verify IFC-DEFS-007: Submit 100 representative loading sequences from the SPE to the Stability and Stress Monitoring System and measure round-trip response time for each. Pass criteria: all responses received within 3 seconds, stability parameters (GM, trim, SF, BM) match reference values from the approved stability book within 2 percent tolerance. Rationale: Round-trip latency measurement validates that stability checking does not become a bottleneck in iterative stowage planning. 100 loading sequences provides statistical significance for response time characterisation across different vessel loading conditions (ballast, full, partial). | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-012 | Verify IFC-DEFS-008: Generate 200 on-deck stack configurations (varying weights 5-30 tonnes, stack heights 2-6 tiers) and submit to the Lashing Calculator interface. Pass criteria: all responses within 2 seconds per stack, lashing force results match manual calculation from the Cargo Securing Manual within 3 percent. Rationale: 200 stack configurations spanning the full weight and height range exercises the lashing calculation across CSS Code force tables. Boundary conditions (maximum stack weight at maximum tier height) are the most structurally demanding cases and must be explicitly tested. | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-013 | Verify IFC-DEFS-009: Submit a manifest containing at least one container from each of the 9 IMDG hazard classes and verify that the Dangerous Goods system returns correct segregation matrices. Intentionally place containers violating segregation distances and confirm the SPE rejects these placements. Pass criteria: zero false negatives (no accepted segregation violations), full manifest validation under 10 seconds. Rationale: All 9 IMDG hazard classes must be represented in the test manifest because segregation rules and stowage categories differ significantly between classes. A test covering only common classes (3, 8, 9) would miss the most restrictive segregation requirements (Class 1, Class 7). | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-014 | Verify IFC-DEFS-010: Configure a vessel model with known reefer plug allocation (some slots occupied, some available) and attempt to stow reefer containers. Confirm that the SPE queries plug availability and rejects placement to non-powered or fully-allocated slots. Pass criteria: zero reefer containers placed in unpowered positions across 10 test scenarios with varying plug utilization from 30 to 95 percent. Rationale: Tests the reefer plug availability query with a pre-configured vessel model to verify correct slot-level granularity. The mix of occupied and available slots ensures the interface correctly reports available capacity, preventing reefer over-allocation during planning. | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-015 | Verify SUB-REQS-011: Execute the Stowage Optimization Engine against 10 representative load lists ranging from 5,000 to 20,000 TEU on a single compute node matching the target hardware specification. Pass criteria: all 10 plans generated within 120 seconds, zero constraint violations in any output plan, and solution quality (total weighted penalty) within 5 percent of the best known solution from offline computation. Rationale: Tests the stowage optimization engine against the full capacity range (5,000 to 20,000 TEU) to verify the 10-minute solve time constraint holds at scale. A single compute node constraint ensures the performance target is validated without cluster parallelism masking bottlenecks. | Test | verification, stowage-planning-engine, session-280 |
| VER-METHODS-016 | Verify SUB-REQS-016: Create test scenarios with containers from all 9 IMDG hazard classes placed in known violation configurations (insufficient horizontal separation, incorrect deck stowage category) and confirm the optimizer rejects every violation. Include edge cases: Class 1 explosives requiring magazine stowage, Class 7 radioactive with special form certificates, and incompatible classes in adjacent bays. Pass criteria: zero violations accepted across 500 test placements. Rationale: Known violation configurations (insufficient separation, prohibited stowage category, incompatible adjacent classes) test the negative path — the system must correctly reject every violation. This is the safety-critical test; a false negative (missed violation) could result in incompatible DG stowage at sea. | Test | verification, stowage-planning-engine, safety, session-280 |
| VER-METHODS-017 | Verify IFC-DEFS-011: Submit 100 sequential UN number lookup queries spanning all 9 hazard classes and measure response time for each. Pass criteria: 95th percentile response time at or below 10 milliseconds. Verify returned data contains all mandatory fields (class, division, packing group, stowage category, SGG list, EmS references). Rationale: Sequential UN number lookups across all 9 hazard classes validate both response time and classification accuracy for the synchronous query-response interface. 100 queries provides sufficient coverage of the DGL while keeping test execution time manageable. | Test | verification, dg-management, session-281 |
| VER-METHODS-018 | Verify IFC-DEFS-012: Submit batch queries of 25, 50, and 100 UN numbers and measure response time and data completeness. Pass criteria: response within 50 milliseconds for 100 entries, each entry contains primary class, subsidiary risks, and complete SGG membership list matching the IMDG Code reference. Rationale: Batch query testing at 25, 50, and 100 UN numbers validates scalability of the database interface and verifies that batch processing does not introduce data completeness issues (missing fields, truncated results) at higher batch sizes. | Test | verification, dg-management, session-281 |
| VER-METHODS-019 | Verify IFC-DEFS-013: Submit 10 test scenarios with known segregation violations (Class 1.1 adjacent to Class 5.1, Class 3 with Class 4.3 below minimum separation, SGG1 acid with SGG18 alkali) and verify that each returns fail with correct violated pairs and required distances within 500 milliseconds. Rationale: Known segregation violations with specific class combinations (1.1/5.1 incompatibility, 3/4.3 minimum separation) test that the validator correctly applies the IMDG Code Table 7.2.4 rules for the most hazardous pairings. These specific combinations are chosen because they represent the highest-consequence segregation failures. | Test | verification, dg-management, session-281 |
| VER-METHODS-020 | Verify IFC-DEFS-014: Update a DG declaration record, then query the Manifest Generator data source within 60 seconds and confirm the updated record is reflected. Repeat for 5 declarations across different hazard classes. Pass criteria: all updates visible within 60-second window with complete field set. Rationale: Tests data consistency propagation — when a DG declaration is updated, the manifest generator must reflect the change within 60 seconds. This verifies that the validated data pathway from declaration to manifest does not introduce stale data, which could result in an incorrect statutory manifest. | Test | verification, dg-management, session-281 |
| VER-METHODS-021 | Verify IFC-DEFS-015: Load a test manifest of 500 DG containers spanning all 9 hazard classes, trigger constraint set generation, and verify: output delivered within 2 seconds, contains prohibited positions and separation distances for each container, and constraint sets are parseable by the Stowage Optimization Engine constraint interface. Rationale: 500 DG containers across all hazard classes exercises the constraint set generation at realistic vessel loads. Verification of output delivery time ensures constraint generation does not become a bottleneck during stowage planning iterations. | Test | verification, dg-management, session-281 |
| VER-METHODS-022 | Verify IFC-DEFS-016: Simulate 1200 reefer container polling events at 15-minute intervals and measure end-to-end delivery latency from the Reefer Monitoring Unit to the Temperature Alarm Processor. Pass criteria: 100 percent of messages delivered within 5 seconds, no message loss, all required fields (container ID, location, supply air temp, return air temp, setpoint, timestamp) present and correctly formatted. Rationale: Simulating 1200 containers at 15-minute intervals validates the full-scale polling load on the monitoring-to-alarm interface. Latency measurement ensures alarm processing is not delayed by interface congestion at maximum fleet size. | Test | verification, reefer, session-282 |
| VER-METHODS-023 | Verify IFC-DEFS-017: Transmit 10,000 sequential polling records from the Reefer Monitoring Unit to the Reefer Data Logger and verify guaranteed delivery by confirming record count match, sequence integrity (no reordering), and completeness of all data fields. Inject 5 simulated network interruptions during the test to verify retry and recovery. Rationale: 10,000 sequential records tests the guaranteed delivery mechanism of the logging interface under sustained write load. Record loss in the temperature logging chain would invalidate the tamper-evident audit trail required for regulatory compliance. | Test | verification, reefer, session-282 |
| VER-METHODS-024 | Verify IFC-DEFS-018: Trigger 50 power state changes (energise, trip, load-shed) on reefer outlets and measure the time from state change to updated status in the Reefer Monitoring Unit. Pass criteria: all state changes reflected within 10 seconds, container-to-outlet mapping accurate for all affected containers. Rationale: 50 power state change events across energise, trip, and load-shed states validates the bidirectional status exchange. Timing measurement confirms that the monitoring system receives power status updates fast enough to suppress false temperature alarms during planned power transitions. | Test | verification, reefer, session-282 |
| VER-METHODS-025 | Verify IFC-DEFS-019: Submit PTI results for 200 containers (mix of pass, fail, conditional) from the Pre-Trip Inspection Module and verify the Reefer Monitoring Unit initialises monitoring baselines using PTI-confirmed setpoints. Pass criteria: all passed containers initialised with PTI-validated setpoints, failed containers flagged as not-for-monitoring. Rationale: 200 containers with a mix of pass, fail, and conditional PTI results exercises all outcome paths. Conditional results (e.g., minor defects requiring monitoring) are the most complex case and must be correctly reflected in the monitoring unit's container status. | Test | verification, reefer, session-282 |
| VER-METHODS-026 | Verify IFC-DEFS-020: Inject atmosphere readings for 50 CA reefer containers with known O2 and CO2 deviations and verify the Temperature Alarm Processor generates consolidated temperature-plus-atmosphere alarms when both parameters deviate simultaneously. Pass criteria: all consolidated alarms generated within one polling cycle, no missed combined-deviation scenarios. Rationale: 50 CA reefer containers with known O2 and CO2 deviations validates that the alarm processor correctly applies atmosphere-specific thresholds. CA alarm processing is distinct from temperature alarm processing and must be tested independently to confirm correct threshold evaluation. | Test | verification, reefer, session-282 |
| VER-METHODS-027 | Verify IFC-DEFS-021: Simulate 20 power fault events (overload trip, ground fault, phase loss, load-shed) and measure delivery latency to the Temperature Alarm Processor. Pass criteria: all fault events delivered within 2 seconds, affected outlet identification correct, alarm processor correctly reclassifies subsequent temperature rises as power-related. Rationale: 20 power fault events across different fault types (overload, ground fault, phase loss, load-shed) validates that each fault type is correctly classified and delivered to the alarm processor. Fault type identification is critical for correct crew response — a ground fault requires different action than an overload trip. | Test | verification, reefer, session-282 |
| VER-METHODS-028 | Verify IFC-DEFS-022: Transmit a batch of 2,000 VERMAS D.13B messages totalling 500 KB through the EDI Gateway to the VGM Declaration Receiver. Pass criteria: all 2,000 declarations parsed correctly with no data loss, and all mandatory VERMAS segments (BGM, DTM, NAD, WGT) correctly extracted. Rationale: Validates the VERMAS interface at scale to ensure the VGM system can handle peak port call volumes without message loss or parsing failures. | Test | verification, vgm, session-284 |
| VER-METHODS-029 | Verify IFC-DEFS-023: Connect to simulated weighbridge equipment using each supported protocol (Modbus TCP, OPC-UA, RS-232) and acquire 100 weight measurements per protocol. Pass criteria: all measurements received within 500ms of trigger, measurement values match simulator reference within 10 kg resolution, and protocol auto-detection correctly identifies each protocol type. Rationale: Each weighbridge protocol must be independently verified since protocol-specific timing and framing issues only manifest during sustained measurement sequences. | Test | verification, vgm, session-284 |
| VER-METHODS-030 | Verify IFC-DEFS-024: Change VGM compliance status for 50 containers through the full lifecycle (REJECTED to CONDITIONAL to AUTHORIZED) and measure message delivery to the Stowage Planning Engine subscriber. Pass criteria: all status changes delivered within 500ms, no message loss, and status values correctly parsed by the stowage planner. Rationale: VGM status lifecycle transitions are critical for loading authorization decisions. Testing the full lifecycle verifies that status changes propagate correctly to the stowage planner. | Test | verification, vgm, session-284 |
| VER-METHODS-031 | Verify IFC-DEFS-025: Query the Container Weight Database for 1,000 container weights while the database contains 500,000 records. Pass criteria: 95th percentile query response time below 50ms, confidence indicator correctly distinguishes weighbridge-verified from declaration-only weights, and all returned VGM values match the stored values exactly. Rationale: Weight lookup performance under full database load must be verified against the 100ms threshold to ensure stability calculations are not bottlenecked during planning cycles. | Test | verification, vgm, session-284 |
| VER-METHODS-032 | Verify IFC-DEFS-026: Update VGM status for 200 containers in rapid succession and verify that the Container Tracking and Inventory System reflects each update within 1 second. Pass criteria: all 200 status changes propagated within 1 second, inventory records show current VGM status, and container number mapping is correct. Rationale: Rapid VGM status updates during active cargo operations stress the synchronization path between the weight database and the container inventory, exposing race conditions. | Test | verification, vgm, session-284 |
| VER-METHODS-033 | Verify IFC-DEFS-027: Monitor the Cargo Operations Display dashboard while processing a simulated port call with 1,500 containers. Pass criteria: dashboard data refreshes at intervals not exceeding 10 seconds, coverage percentage matches the actual count of VGM-declared containers, and discrepancy counts match the Weight Discrepancy Detector output. Rationale: Dashboard accuracy and refresh rates must be validated under realistic port call loads to ensure the cargo officer has reliable situational awareness during operations. | Demonstration | verification, vgm, session-284 |
| VER-METHODS-034 | Verify SUB-REQS-045: Submit 100 container weight pairs (declared vs measured) with known discrepancies spanning all three severity tiers. Pass criteria: all containers correctly classified by severity (minor, major, critical), no false negatives for discrepancies exceeding the 5%/1,000 kg threshold, and no false positives for weight pairs within tolerance. Rationale: Discrepancy detection thresholds must be verified with known test vectors spanning all severity tiers to confirm correct classification and zero false negatives on weight safety violations. | Test | verification, vgm, session-284 |
| VER-METHODS-035 | Verify SUB-REQS-048: Process 500 containers through the full compliance validation pipeline and verify that each receives a correct authorization status within 2 seconds. Pass criteria: AUTHORIZED only for containers with valid VGM and no discrepancy, REJECTED for containers without VGM or with invalid declarations, HOLD and CONDITIONAL correctly applied based on discrepancy severity, and end-to-end latency below 2 seconds for each determination. Rationale: Full pipeline validation of 500 containers tests the compliance validator's accuracy and performance at realistic scale, covering all four authorization states and edge cases. | Test | verification, vgm, session-284 |
| VER-METHODS-036 | Verify IFC-DEFS-028: Integration test — submit a stowage plan with known container weights and positions to the Lashing and Securing Calculator via the Stowage Planning Engine interface. Verify that lashing compliance response is received within the API timeout and that a plan with an over-SWL condition is rejected. Pass criteria: rejection returned with specific bay and lashing element identification. Rationale: The lashing calculator's dependency on accurate weight and position data from the stowage engine makes this interface safety-critical. Integration testing validates end-to-end data fidelity. | Test | verification, lashing, session-285 |
| VER-METHODS-037 | Verify IFC-DEFS-029: Integration test — inject known GM and roll period values from the Stability system to the Lashing Calculator. Verify that acceleration parameters update within 10 seconds and that lashing force calculations change accordingly. Pass criteria: force output delta matches predicted change for the GM shift within 2% tolerance. Rationale: Stability parameters directly affect lashing force calculations. Verifying that injected GM and roll period values produce correct acceleration factors validates the CSS Code calculation chain. | Test | verification, lashing, stability, session-285 |
| VER-METHODS-038 | Verify IFC-DEFS-030: Integration test — transmit BAPLIE, COPARN, and CODECO messages from a test terminal system to the EDI Gateway and verify they propagate to the Container Tracking system. Pass criteria: all three message types acknowledged within 30 seconds, container records created/updated in the Container Registry matching message content. Rationale: BAPLIE/COPARN/CODECO are the three core message types for vessel-terminal data exchange. Integration testing validates correct parsing, routing, and semantic preservation across the full EDI stack. | Test | verification, container-tracking, terminal-edi, session-285 |
| VER-METHODS-039 | Verify IFC-DEFS-031: Performance test — query the Bay Plan Manager for single-bay slot availability and full-vessel slot availability under load (24,000 containers populated). Pass criteria: single-bay response within 500ms (p99), full-vessel response within 2 seconds (p99), measured over 1000 queries. Rationale: Slot availability queries occur on every optimization iteration. Performance testing at 24,000 TEU scale validates that the Bay Plan Manager meets response time requirements under realistic load. | Test | verification, container-tracking, stowage, performance, session-285 |
| VER-METHODS-040 | Verify IFC-DEFS-032: Integration test — submit a VGM value to the VGM system and verify it propagates to the Container Registry within 5 seconds. Submit a VGM differing from the booking weight by 6% and verify a discrepancy flag is raised. Pass criteria: weight updated in registry within 5s, discrepancy flag generated for >5% deviation, no flag for <=5% deviation. Rationale: VGM-to-registry propagation timing is critical for preventing loading of containers with disputed weight data. Testing with discrepancy flag injection validates the full alert pipeline. | Test | verification, container-tracking, vgm, session-285 |
| VER-METHODS-041 | Verify IFC-DEFS-033: Inject 10,000 mixed-type EDI messages through the parser at maximum rate and measure queue acknowledgment latency. Pass criteria: 99.9th percentile acknowledgment latency below 10ms, zero message drops, all JSON envelopes contain required fields (type, priority, source, timestamp, payload). Rationale: The parser-to-queue interface handles the highest message volume in the system. 10,000 mixed-type messages tests throughput and queue acknowledgment latency under stress conditions. | Test | verification, terminal-interface, session-286 |
| VER-METHODS-042 | Verify IFC-DEFS-034: Simulate VSAT failure by disconnecting the primary link and measure the time from link-down event to queue receiving notification and switching to degraded-mode scheduling. Pass criteria: notification delivered within 2 seconds, queue compression enabled within 5 seconds, no messages attempted on failed link after notification. Rationale: Communication link failover timing directly affects message delivery reliability. Simulating VSAT failure validates the detection-to-notification chain that triggers store-and-forward mode. | Test | verification, terminal-interface, session-286 |
| VER-METHODS-043 | Verify IFC-DEFS-035: Transmit a 10 MB BAPLIE message from a simulated TOS through the connector to the parser and verify complete round-trip. Pass criteria: message delivered intact, metadata fields populated correctly, no truncation or encoding loss, processing completed within 30 seconds. Rationale: Large BAPLIE messages (full vessel plans for 24,000 TEU) test the connector-parser interface at maximum message size, exposing buffer overflow or parsing timeout issues. | Test | verification, terminal-interface, session-286 |
| VER-METHODS-044 | Verify IFC-DEFS-036: Simultaneously inject alarm events from all five subsystem sources and measure end-to-end propagation to the alarm display. Pass criteria: all events received with correct fields, 99th percentile propagation under 500ms, no events lost or duplicated, correct severity ordering in display queue. Rationale: Simultaneous alarms from all five subsystems represent the worst-case alarm flood scenario (e.g., heavy weather). Testing propagation latency validates the alarm aggregation system under peak load. | Test | verification, cargo-display, session-286 |
| VER-METHODS-045 | Verify IFC-DEFS-037: Submit a 50-move restow scenario to the simulation engine against a loaded 20,000 TEU base case. Pass criteria: all three calculation services return results within 8 seconds, results match independent offline calculation within 0.1 percent tolerance, operational load case unchanged after simulation completes. Rationale: A 50-move restow scenario against a loaded 20,000 TEU base case is the most computationally intensive simulation the system must support. This validates both calculation accuracy and response time under realistic planning conditions. | Test | verification, cargo-display, session-286 |
| VER-METHODS-046 | Verify IFC-DEFS-038: Simulate a multi-crane loading operation with 500 container moves including 10 out-of-sequence events and verify the Loading Sequence Display updates correctly. Pass criteria: all moves displayed within 5 seconds, out-of-sequence moves highlighted, planned vs actual counts match at completion. Rationale: Out-of-sequence container moves during multi-crane operations are a common operational scenario. Testing with deliberate sequence violations validates the display's ability to detect and alert on deviations from the planned loading sequence. | Test | verification, cargo-display, session-286 |
| VER-METHODS-047 | Verify IFC-DEFS-039: Connect the system to a ballast control system simulator generating IEC 61162-450 compliant tank sounding data for 20 ballast tanks. Verify that all tank levels, temperatures, and densities are received and correctly reflected in the stability calculation within 5 seconds. Transmit 10 ballast recommendations and verify correct formatting and operator confirmation workflow. Rationale: The ballast interface carries safety-critical data affecting stability calculations. Testing with a 20-tank simulator covers the full range of a typical container vessel ballast system. The 5-second latency threshold ensures tank sounding updates are reflected in the stability calculation before the next crane lift cycle. Verifying the operator confirmation workflow for transmitted ballast recommendations ensures the human-in-the-loop safety control is functioning correctly. | Test | verification, ballast, validation, session-288 |
| VER-METHODS-049 | Verify IFC-DEFS-040: Connect a NMEA 0183 signal simulator generating MWV wind speed and angle sentences and ocean wave data. Verify that wind speed values from 0 to 40 m/s are correctly received and that the Wind Force Estimator uses actual wind data when available, falling back to design values when the weather feed is interrupted for more than 60 seconds. Rationale: Wind force is the dominant environmental load on above-deck container stacks. Testing the full 0-40 m/s range covers Beaufort 0 through hurricane force winds, spanning all operational and survival conditions. The 60-second fallback verification ensures the system reverts to conservative design values promptly when actual wind data is lost, preventing lashing calculations based on stale environmental data that could under-predict forces during rapidly deteriorating weather. | Test | verification, weather, validation, session-288 |
| VER-METHODS-050 | Verify SUB-REQS-078: Trigger a system startup and observe the built-in test sequence completion. Introduce a deliberate single-bit corruption in the hydrostatic data table and verify that the self-test detects the integrity failure and displays a clear alarm within the test interval. Verify that the 24-hour periodic test executes automatically and logs results. Rationale: Self-test integrity is the primary defense against silent data corruption in the stability calculation. Injecting a deliberate single-bit corruption into hydrostatic tables verifies that the checksum algorithm detects the smallest possible data fault. Verifying the 24-hour periodic test ensures the system does not rely solely on startup checks, catching in-service corruption between power cycles. Alarm display verification confirms the operator is informed of integrity failures before the next stability calculation uses potentially corrupted data. | Demonstration | verification, self-test, validation, session-288 |
flowchart TB n0["component<br>Intact Stability Computer"] n1["component<br>Draught Sensor Interface"] n2["component<br>Stability Alarm and Advisory Generator"] n3["component<br>Longitudinal Strength Monitor"] n4["component<br>Loading Condition Database"] n5["component<br>Damage Stability Assessor"] n3 -->|SF, BM utilisation| n2 n5 -->|attained index A| n2 n1 -->|draught, trim, heel| n0 n0 -->|GM, GZ, weather ratio| n2 n4 -.->|hydrostatic data| n0 n1 -->|draught distribution| n3 n0 -->|equilibrium condition| n5 n4 -.->|hull girder limits| n3
Stability and Stress Monitoring System — Decomposition
flowchart TB n0["component<br>IMDG Code Database"] n1["component<br>DG Declaration Validator"] n2["component<br>Segregation Rules Engine"] n3["component<br>DG Stowage Position Validator"] n4["component<br>Emergency Response Information System"] n5["component<br>DG Manifest Generator"] n1 -.->|validate against| n0 n2 -.->|segregation rules| n0 n3 -.->|stowage categories| n0 n3 -->|separation check| n2 n4 -.->|EmS/MFAG lookup| n0 n5 -->|validated DG data| n1 n5 -->|stowage positions| n3
Dangerous Goods Management System — Internal
| Entity | Hex Code | Description |
|---|---|---|
| Alarm and Notification Manager | 40FD7B59 | Software component within a container ship cargo management system's operator interface. Aggregates alarms and alerts from all cargo subsystems: stability warnings (GM below threshold, excessive trim), reefer temperature exceedances, dangerous goods segregation violations, VGM discrepancies, lashing overload warnings, and stowage plan conflicts. Prioritises alarms by severity (critical/major/minor) and recency. Provides audible and visual alerts with mandatory acknowledgment workflow per ISM Code requirements. Supports alarm suppression with logged justification. Maintains alarm history log for port state inspection. |
| Bay Plan Manager | 40B53308 | Slot allocation and spatial tracking module in a container ship cargo management system. Maintains the real-time mapping of containers to vessel stowage positions (bay-row-tier coordinates per ISO 9711). Tracks slot occupancy, container orientation (door-end forward/aft), and over/under-deck status for all bays. Provides position queries for stowage planning, stability calculation, and lashing verification. Must reflect loading/discharge operations within 5 seconds of crane confirmation. Supports both 20ft and 40ft container slots with mixed-size stacking rules. |
| Bay Plan Visualization Engine | 44FD7118 | Software HMI component within a container ship cargo management system. Renders 2D cross-section and 3D perspective views of the vessel bay plan showing all container positions (holds and on-deck) for vessels up to 24,000 TEU. Displays color-coded overlays for container status (loaded/planned/discharged), dangerous goods class markings per IMDG, reefer indicators with live temperature, weight heat maps by stack, and lashing compliance status. Supports pan, zoom, rotation, and filtering by any container attribute. Refreshes within 500ms of any stowage plan change. Primary display for the cargo officer during loading operations. |
| Booking and Manifest Linker | 40A53358 | Data integration module in a container ship cargo management system. Links container physical records to commercial booking data (shipper, consignee, port pairs, freight terms) and customs manifest entries. Reconciles pre-arrival booking lists against actual loaded containers to identify shorts, extras, and mis-ships. Generates cargo manifest documents required by customs authorities at destination ports per FAL Convention. Must handle multi-leg bookings for transhipment containers and maintain booking-to-container linkage across port rotations. |
| Cargo Operations Display and Decision Support | 50ED7318 | Human-machine interface subsystem providing the cargo officer and ship's master with situational awareness and decision support during cargo operations. Displays a graphical 3D bay plan view with colour-coded container status (loaded, planned, reefer, DG class, overweight, out-of-gauge), real-time stability indicators (GM, trim, heel, stress), loading/discharge progress by port call, and active alarms. Provides what-if simulation capability: the cargo officer can evaluate the effect of proposed container moves on stability, stress, and lashing before committing changes. Generates cargo operation reports including mate's receipts, stowage certificates, and Letters of Protest for damaged containers. Runs on ruggedised bridge-mounted workstations (IP22 rated, sunlight-readable displays) and tablet devices for use on deck during operations. Must remain responsive (screen refresh < 1 second) during simultaneous loading/discharge on 3+ cranes at 30+ moves/hour each. |
| Communication Link Manager | 50F77008 | Infrastructure management component within a container ship cargo management system. Manages physical and logical communication links including Ku/Ka-band VSAT (primary, 2-10 Mbps), L-band Inmarsat Fleet Broadband (backup, 432 kbps), and 4G/LTE shore-side connections. Handles automatic link failover with sub-30-second switchover, bandwidth allocation across competing shipboard applications, data compression (achieving 3:1 ratio on EDI traffic), and link quality monitoring. Reports link status and throughput metrics to operations. |
| Container Event Logger | 40A57B58 | Audit trail and transaction recording module in a container ship cargo management system. Records every container movement event: load, discharge, shift, restow, hatch-open, hatch-close with timestamps, operator ID, crane ID, and before/after positions. Provides the regulatory audit trail required by SOLAS Chapter VI and port state control inspections. Supports event replay for incident investigation. Must handle burst rates of 40+ events per minute during intensive cargo operations and retain records for the entire voyage plus 90 days. |
| Container Registry | 40851148 | Master data store within a container ship cargo management system. Maintains the authoritative record for every container handled by the vessel: ISO container ID (BIC code), ISO type/size code (per ISO 6346), tare weight, maximum gross weight, owner/operator, booking reference, seal numbers, and special handling codes. Linked to commercial booking data and customs manifests. Supports real-time queries from all other subsystems for container attributes. Must maintain consistency across 10,000+ container records with ACID properties. |
| Container Ship Cargo Management System | 51B57B58 | Integrated shipboard information system for ultra-large container vessels (ULCV, 20,000+ TEU capacity). Manages the complete cargo lifecycle from booking acceptance through stowage planning, loading/discharge sequencing, on-voyage monitoring, and port discharge. Core functions include: bay plan optimisation balancing weight distribution, stack heights, and port rotation; real-time stability and stress monitoring against IMO intact/damage stability criteria; reefer container power and temperature management for up to 2,000 refrigerated units; IMDG Code compliance for hazardous/dangerous goods segregation and stowage; lashing force calculations per CSS Code; integration with terminal operating systems (TOS) via BAPLIE/COPARN EDI messaging; and crew decision support for cargo operations. Operates in a maritime environment subject to vessel motion, vibration, salt atmosphere, and Class society requirements (DNV, Lloyd's, BV). Must comply with SOLAS, MARPOL, ISM Code, and port state control inspection regimes. |
| Container Status Engine | 40B57B08 | State machine and business logic module in a container ship cargo management system. Manages the lifecycle state of each container from booking through discharge: states include booked, gate-in, yard, planned-load, loaded, in-transit, planned-discharge, discharged, and exception. Enforces valid state transitions and triggers downstream updates to stability recalculation, DG manifest updates, and reefer monitoring activation/deactivation. Generates container status reports for terminal planning systems via the EDI gateway. |
| Container Tracking and Inventory System | 40A57358 | Subsystem maintaining a real-time inventory of all containers on board, on the quay, and in transit to/from the vessel. Tracks each container by its unique BIC/ISO 6346 identification code, recording position (bay-row-tier), weight (VGM per SOLAS), seal number, booking reference, shipper/consignee, and status (loaded, discharged, restowed, damaged). Reconciles the ship's inventory against terminal move reports received via EDI to detect discrepancies — missing containers, wrong positions, weight mismatches. Supports container event logging for the complete voyage: gate-in at origin terminal, vessel loading, transhipment, discharge, gate-out. Provides search and query functions for crew and operations staff to locate specific containers by any attribute. Interfaces with all other subsystems as the single source of truth for what is on board. Must handle 20,000+ container records with sub-second query response time. |
| Container Weight Database | 40853358 | Persistent storage system that maintains the authoritative record of VGM declarations, weighbridge measurements, and weight reconciliation outcomes for every container handled by the vessel. Stores per-container records including container number, declared VGM, measured weight, tare weight, discrepancy status, shipper identity, weighing method, equipment ID, and timestamp. Retains records for a minimum of 3 years per SOLAS audit requirements. Supports query by container number, voyage, port, discrepancy status, and date range. Provides data feeds to the stability monitoring system and stowage planner with sub-second response for individual container weight lookups across 20000+ container inventories. |
| Controlled Atmosphere Monitor | 54A77018 | Monitors and records atmospheric composition inside controlled atmosphere (CA) reefer containers on a container vessel. CA reefers maintain specific O2 (typically 2-5%), CO2 (typically 2-10%), and N2 balance to extend shelf life of perishable cargo such as bananas, avocados, kiwifruit, and apples. Reads atmosphere sensor data from CA-equipped container units, compares against cargo-specific atmosphere recipes, and generates alarms when gas levels deviate beyond tolerance. Interfaces with Reefer Monitoring Unit for consolidated display. Typically 5-15% of total reefer fleet uses CA technology, but these are often the highest-value cargo. |
| Crane Position Interface | 50B57208 | Hardware-software interface module in a container ship cargo management system. Receives container identification and position confirmation data from ship-to-shore crane systems and vessel crane operators. Integrates with crane PLC systems via OPC-UA or Modbus TCP to capture container ID (from OCR or RFID), spreader lock status, and final stowage position. Converts crane-native bay/row/tier coordinates to the vessel's internal coordinate system. Must process confirmations within 2 seconds of crane cycle completion to maintain bay plan currency. |
| Crane Split Calculator | 41B73B08 | Operational planning component that distributes container loading and discharge operations across 3-6 available quay gantry cranes. Minimizes total vessel berth time by balancing workload, avoids crane interference in adjacent bays, respects hatch cover removal sequences, and maintains even vessel trim during operations. Produces a timed sequence of crane moves targeting 25-35 moves per hour per crane. Recalculates dynamically when actual productivity deviates or crane availability changes. |
| CSS Code Compliance Engine | 40E77958 | Regulatory compliance validation engine for container ship cargo securing. Validates calculated lashing loads, stack weights, and racking forces against the IMO Code of Safe Practice for Cargo Stowage and Securing (CSS Code) Annex 13 and the vessel's approved Cargo Securing Manual (CSM). Implements both the simplified method and the advanced calculation method. Checks that all securing arrangements meet SWL limits, stack weight limits per bay, and tier height restrictions. Outputs: per-bay compliance verdict, non-compliance detail reports with specific CSS Code clause references, and corrective action recommendations. |
| Damage Stability Assessor | 51F77B58 | Software component within the Stability and Stress Monitoring System that evaluates probabilistic damage stability per SOLAS Chapter II-1 Part B-1 for a large container vessel. Uses pre-computed damage case library (hundreds of flooding scenarios with probability weights) combined with current loading condition to compute attained subdivision index. Compares against required index R. Runs the top 3 most-probable damage scenarios in real-time to provide operational damage stability awareness without full probabilistic recomputation. Critical safety function: early warning if current loading degrades survivability below regulatory minimum. |
| Dangerous Goods Management System | 40B77B59 | Subsystem enforcing IMDG Code compliance for hazardous and dangerous cargo aboard container vessels. Maintains a real-time manifest of all dangerous goods containers with their UN numbers, IMDG class (1-9), packing group, proper shipping name, and emergency procedures (EmS). Enforces segregation rules per IMDG Code Chapter 7.2 — ensuring incompatible classes are separated by the required number of container spaces or decks (e.g., Class 1 explosives minimum 24m from Class 3 flammables). Validates stowage category (on-deck vs under-deck, closed vs open) against IMDG stowage provisions. Tracks aggregate quantity limits per IMDG class to prevent exceeding vessel approval limits. Generates the dangerous goods manifest required under SOLAS Chapter VII and the IMDG Code for port authority submission prior to arrival. Interfaces with stowage planning to constrain container placement and with stability monitoring for weight distribution of DG containers. |
| DG Declaration Validator | 40A53B58 | Processes incoming Dangerous Goods Declarations (DGD forms per IMO FAL Form 7 / MSC.1-Circ.1586). Validates each declaration for mandatory fields: UN number, proper shipping name, hazard class/division, subsidiary risk(s), packing group, net/gross quantity, packaging type, EmS reference, and shipper certification. Cross-references declared data against the IMDG Code Database to detect misclassifications. Flags incomplete, inconsistent, or expired declarations. Processes up to 500 DG declarations per port call. Inputs arrive via IFTDGN EDI message or manual entry. |
| DG Manifest Generator | 40F57B58 | Produces the dangerous goods manifest and related documentation required by SOLAS Chapter VII Regulation 4 and IMDG Code Section 5.4.3. Generates a complete manifest listing all DG containers aboard with: stowage position (bay/row/tier), proper shipping name, UN number, hazard class/division, packing group, net quantity, number of packages, EmS reference. Also produces the DG stowage plan showing physical locations of all DG containers overlaid on the vessel's general arrangement. Outputs in PDF for port state submission and structured IFTDGN EDI for terminal systems. Must be regenerable within 5 minutes whenever stowage changes occur. |
| DG Stowage Position Validator | 40A73959 | Validates each dangerous goods container's proposed stowage position against IMDG stowage category rules. Stowage categories (Category A through E and SW special provisions) define: on-deck vs under-deck permissions, minimum distance from crew accommodation (typically one bulkhead or 3m), distance from heat sources and machinery spaces, and prohibition from specific hold types. Checks column 16 special provisions of the IMDG Dangerous Goods List. Evaluates both individual container stowage and cumulative stowage compliance across the full vessel. Provides accept/reject with specific code violations for each proposed position. |
| Draught Sensor Interface | D4A53018 | Hardware interface component within the Stability and Stress Monitoring System on a ULCV container vessel. Acquires draught readings from four hull-mounted hydrostatic pressure transducers (forward, aft, port midship, starboard midship) via NMEA 0183/2000 serial bus at 1 Hz. Provides sensor health monitoring with 5-second failure detection, data validation (range 0.5-25m), and noise filtering. Resolves four-point measurements into mean draught, trim, and heel angles. The primary real-world measurement input that anchors all stability calculations to actual vessel condition rather than calculated estimates. |
| EDI Message Parser and Translator | 41F77358 | Software component within a container ship cargo management system's Terminal Interface and EDI Gateway. Parses inbound UN/EDIFACT and XML messages (BAPLIE D.13B bay plans, COPARN container announcements, MOVINS move instructions, CODECO gate/vessel moves, VERMAS VGM declarations, CUSCAR customs cargo, IFTDGN dangerous goods notifications) into the system's internal data model. Generates compliant outbound EDI messages from internal events. Handles character set conversion (UNOA/UNOB), segment validation, and message version negotiation. Processes up to 50,000 EDI messages per port call across 7+ message types. |
| Emergency Response Information System | 40ED7B58 | Maintains Emergency Schedules (EmS) — paired fire schedules (F-A through F-J) and spillage schedules (S-A through S-Z) — for every UN number in the IMDG Code. Links each DG entry to Medical First Aid Guide (MFAG) tables for treatment of exposure/contamination. Provides rapid lookup (under 2 seconds) of emergency procedures during incidents, keyed by UN number or container ID. Must remain accessible during main system degradation via independent backup display. Generates emergency response summaries for shore-side reporting to port state control and coast guard. Covers approximately 3500 EmS/UN number combinations. |
| Hatch Cover Sequence Planner | 40A53A08 | Planning component that determines the order of hatch cover removal and replacement operations during cargo operations. On a container vessel, cargo in the hold (below deck) is accessible only after the hatch covers and all on-deck containers above them are removed. The planner sequences these operations to minimize idle crane time and ensure safe access. Must coordinate with crane split calculations since hatch cover lifts require dedicated crane capacity. Tracks hatch cover landing positions on the quay and ensures safe stacking. |
| IMDG Code Database | 40853958 | Authoritative reference database containing the full International Maritime Dangerous Goods Code data set. Holds >3000 UN number entries with proper shipping names, hazard classes (1-9 with divisions), packing groups (I/II/III), stowage categories (A-E plus SW special provisions), segregation groups (SGG1-SGG18), EmS fire and spillage schedule references, and special provisions. Updated biennially per IMO amendment cycle (currently Amendment 42-24). Provides sub-millisecond indexed lookup by UN number, class, or segregation group. Core reference for all DG compliance functions. |
| Intact Stability Computer | 51F53958 | Software component within the Stability and Stress Monitoring System of a 20,000+ TEU container vessel. Computes metacentric height (GM), GZ righting lever curves, dynamic stability areas, and weather criterion ratios per IMO Resolution A.749(18). Inputs: displacement, vertical centre of gravity (KG), free surface corrections from tank soundings, hull form hydrostatic data. Outputs: intact stability parameters and pass/fail assessment against regulatory criteria. Runs continuously during loading operations with 5-second maximum computation cycle. |
| Lashing and Securing Calculator | 50A53958 | Computational subsystem that verifies container lashing and securing arrangements comply with CSS Code (Code of Safe Practice for Cargo Stowage and Securing) Annex 13 and the vessel's Cargo Securing Manual (CSM) approved by the flag state. Calculates forces on lashing rods, turnbuckles, twist-locks, and stacking cones based on container stack weight, height above deck, vessel motion parameters (roll amplitude, pitch, heave), wind loading, and stack position (fore/aft, port/starboard). Uses the vessel's specific acceleration table from the CSM, which varies by position on the ship and sea condition. Determines whether additional lashing is required for heavy or tall stacks, and flags stacks exceeding the safe stacking weight for the lashing arrangement fitted. Inputs from stowage plan (container weights and positions) and vessel motion monitoring. Critical for preventing container losses at sea — industry loses 1,000-3,000 containers per year. |
| Lashing Rod Load Analyzer | 50F73858 | Analytical engine within a container ship cargo securing system. Computes tension and compression loads on individual lashing rods, turnbuckles, and twist-locks for each container in above-deck stowage. Applies the CSS Code Annex 13 balance of forces method: external forces (wind, sea, gravity) versus securing capacity (lashing SWL, friction, stacking cone strength). Inputs: container positions, weights, lashing arrangement from Securing Equipment Database, vessel motion accelerations. Outputs: per-lashing load as percentage of SWL, pass/fail against 100% SWL limit, and critical lashing identification. |
| Loading Condition Database | 40851358 | Persistent storage component within the Stability and Stress Monitoring System that maintains vessel-specific hydrostatic tables, tank calibration data, hull form coefficients, and at least 100 historical loading conditions (departure, arrival, intermediate). Provides 3-second recall of any stored condition for review or comparison. Stores the vessel's approved stability booklet data as the reference baseline. Used during Port State Control inspections and class surveys to demonstrate compliance history. On a ULCV, the hydrostatic data set is vessel-specific and includes tables for approximately 200 displacement/trim combinations. |
| Loading Sequence Display | 40EC7308 | Software HMI component within a container ship cargo management system. Shows real-time and planned crane loading/discharge sequences for up to 6 simultaneous gantry cranes. Tracks progress against the planned load list with percentage completion, estimated time to completion, and out-of-sequence move highlighting. Displays crane working area boundaries, hatch cover open/close status, and conflict warnings when two cranes would overlap. Interfaces with terminal crane position data via the Container Tracking subsystem. Updates at 5-second intervals during active cargo operations. |
| Longitudinal Strength Monitor | 40E53B58 | Software component within the Stability and Stress Monitoring System computing hull girder shear force and bending moment distributions along the length of a 400m ULCV container vessel. Evaluates still-water loads at 20+ frame stations against IACS UR S11 permissible envelopes. Inputs: container weight distribution by bay, ballast tank levels, fuel/water tank levels, lightweight distribution. Outputs: shear force and bending moment values at each station, utilisation percentages, alarm states. Critical for preventing structural overload during asymmetric loading sequences. |
| Message Queue and Delivery Manager | 40B77308 | Middleware component within a container ship cargo management system communications gateway. Provides reliable store-and-forward message delivery over unreliable maritime satellite links (VSAT, Inmarsat). Implements message persistence, automatic retry with exponential backoff, dead-letter queuing, strict ordering per message type. Handles prioritisation (safety-critical before operational), compression for satellite bandwidth, and batching. Must not lose messages during link outages up to 24 hours. |
| Port Authority and Customs Interface | 40F57B58 | Software component within a container ship cargo management system. Manages regulatory reporting to port state control, customs authorities (via CUSCAR messages), and maritime safety agencies. Generates and transmits pre-arrival notifications per FAL Convention, customs manifests with HS codes and container details, and IFTDGN dangerous goods notifications. Interfaces with national single-window systems (e.g., EU Maritime Single Window). Must comply with IMO FAL requirements and regional customs regulations for 50+ port states. |
| Port Rotation Planner | 40B73B08 | Voyage-level planning component that optimizes container stowage across a multi-port rotation of 5-15 port calls. Minimizes restows (overstows) where containers must be moved to access cargo beneath them. Generates bay affinity maps assigning port-of-discharge groups to specific bays and hold/deck positions to minimize cross-bay interference. Must account for varying container volumes per port, deadweight changes across the voyage, and ballast requirements at each port. A single restow costs USD 200-400 and 3-5 minutes of crane time. |
| Pre-Trip Inspection Module | 40A73B58 | Manages the pre-trip inspection (PTI) process for refrigerated containers before loading onto a container vessel. Records inspection results including compressor run test, cooling capacity verification (pull-down test from ambient to setpoint within specified time), controller firmware version, defrost cycle test, and door seal integrity check. Issues pass, conditional-pass, or fail verdicts. Integrates with terminal booking systems to prevent loading of failed containers. Maintains inspection history for each container unit number. Must process up to 200 PTI results per port call within the terminal planning window. |
| Racking Force Calculator | 40E53958 | Force calculation module within a container ship securing system. Computes transverse racking forces induced by vessel roll acceleration on each tier of a container stack. Uses parametric roll and synchronous roll models per CSS Code Annex 13 to derive lateral forces at each tier height. Accounts for container structural strength (ISO 1496 racking test load: 150 kN per 20ft unit), metacentric height, and roll period. Outputs: racking force per tier as percentage of ISO structural limit, identifies tiers requiring additional lashing or reduced stack height. |
| Reefer Container Management System | 51B77B18 | Subsystem responsible for monitoring and controlling power supply and temperature for refrigerated containers (reefers) on a ULCV carrying up to 2,000 reefer plugs. Monitors individual container set-point temperature (range -35°C to +30°C), supply/return air temperatures, defrost cycles, and compressor status via RS-485 or Ethernet connections to each reefer unit's integral controller (Carrier, Daikin, Thermo King protocols). Manages electrical load distribution across reefer bus-bars to prevent overloading of the ship's generator plant, typically 4-6 MW dedicated reefer load. Generates alarms for temperature deviations exceeding ±2°C from set-point for more than 60 minutes, power supply failures, and pre-trip inspection failures. Supports automated pre-trip inspections (PTI) per carrier protocols. Interfaces with the stowage planning engine to ensure reefer containers are placed in positions with available power connections and adequate ventilation. |
| Reefer Data Logger | D0853258 | Continuous temperature and operational data recording system for refrigerated containers on a container vessel. Stores timestamped readings (supply air temp, return air temp, setpoint, compressor status, power draw) at configurable intervals (default 15 minutes) for every connected reefer container. Data must be tamper-evident for use in cargo claims and insurance disputes. Supports export to USB media, network download, and integration with carrier cold chain documentation platforms. Retains at least 90 days of data per container across a full voyage cycle. Must comply with ATP Agreement and FDA 21 CFR Part 11 for pharmaceutical cold chain. |
| Reefer Monitoring Unit | 51A57218 | Central monitoring processor for refrigerated container fleet management on a large container vessel (1000+ reefer plugs). Polls each connected reefer container unit via RS-485 or Ethernet data link every 5-15 minutes, acquiring supply air temperature, return air temperature, cargo setpoint, defrost status, compressor state, and fault codes. Aggregates readings into a real-time dashboard with sortable/filterable views by bay location, temperature deviation, and alarm state. Operates continuously at sea and in port. Must handle simultaneous polling of 1000+ containers without data loss or polling cycle overrun. |
| Reefer Power Distribution Controller | D5B73018 | Manages 440V 3-phase 60Hz electrical power distribution to reefer container outlets across all cargo bays on a container vessel. Monitors current draw per circuit (typical 5-15 kW per container), detects overloads, ground faults, and phase imbalance. Controls circuit breakers for individual reefer outlets. Must prioritize power allocation when total reefer demand approaches generator capacity — pharmaceutical and deep-frozen cargo take priority over chilled. Interfaces with vessel power management system for load shedding coordination. Handles up to 1200 outlets across under-deck and on-deck positions. |
| Reporting and Analytics Module | 40E47358 | Software component within a container ship cargo management system. Generates operational reports including port call summaries (containers loaded/discharged/shifted, time in port, crane productivity), cargo utilisation statistics (TEU utilisation, weight utilisation, reefer slot usage), VGM compliance rates, dangerous goods volumes by class, and stowage efficiency metrics. Supports historical trend analysis across voyages for fleet performance benchmarking. Exports reports in PDF and structured data formats (CSV, JSON). Generates regulatory reports for class society and flag state annual surveys. |
| Restow Minimization Module | 41B63B08 | Specialized optimization component focused on reducing unproductive container moves during multi-port operations. Analyses current bay plan state against discharge lists for upcoming ports to identify and resolve overstow situations. Calculates restow cost in terms of crane time, fuel, and terminal charges. Proposes pre-emptive shifts (moving containers to better positions during slack periods) to avoid future restows. Tracks restow KPIs including restow ratio (restows per 100 discharge moves) with a target below 5 percent for well-planned voyages. |
| Securing Equipment Database | 40853158 | Reference data store for container ship cargo securing calculations. Contains the vessel-specific inventory of lashing gear: rod types and lengths, turnbuckle models, twist-lock types, stacking cone specifications, bridge fitting positions, and lashing eye positions per bay. Stores safe working loads (SWL) for each securing element type and installation-specific degradation factors. Updated during vessel surveys and equipment inspections. Provides lookup services to the Lashing Rod Load Analyzer and CSS Code Compliance Engine for securing capacity calculations per bay and tier position. |
| Segregation Rules Engine | 40A73958 | Implements IMDG Code Chapter 7.2 segregation requirements for dangerous goods on container vessels. Encodes the Table 7.2.4 segregation matrix defining compatibility between all 9 hazard classes and their divisions. Calculates required physical separation: away-from (3m), separated-from (6m/one bulkhead), separated-by-complete-compartment (12m/two bulkheads), separated-longitudinally (24m minimum). Handles 18 segregation groups (SGG1-SGG18) that override class-level rules. Supports closed vs open freight container segregation differences per 7.2.3.3. Evaluates segregation in three dimensions considering hold/deck boundaries. |
| Stability Alarm and Advisory Generator | 41F57B19 | Software component within the Stability and Stress Monitoring System that monitors all computed stability and structural parameters against tiered thresholds (caution at 80%, warning at 90%, critical at 95% of limits). Generates prioritised alarms within 2 seconds of threshold breach. Outputs alarm category, parameter identity, current value, limit value, and recommended corrective action. Interfaces with both the local Cargo Operations Display and the bridge alarm management system via IEC 61162-450. On a 20,000 TEU container vessel, this component is the final safety barrier between computational results and human decision-making. |
| Stability and Stress Monitoring System | 51F77B58 | Real-time onboard loading computer subsystem that continuously calculates vessel stability and longitudinal strength during cargo operations and at sea. Computes intact stability parameters (GM, GZ curve, righting lever areas) against IMO A.749 criteria, damage stability against SOLAS Chapter II-1, longitudinal bending moments and shear forces against Classification Society allowables, and torsional moments for open-hatch vessels. Inputs include container weight data from the stowage plan, ballast tank levels from gauging systems, fuel/fresh water tank levels, draught readings from sensors, and vessel hydrostatic data tables. Must detect stability limit violations within 2 seconds of a loading change and alert the cargo officer. Approved by Class society (DNV, Lloyd's, BV) as a certified loading instrument per SOLAS Reg. II-1/22. Handles both static (in-port) and dynamic (seakeeping) stability assessments. |
| Stack Weight Calculator | 50E73918 | Computational module within a container ship lashing and securing system. Calculates vertical compressive forces through container stacks by summing individual container gross weights per tier, accounting for dynamic amplification from vessel roll (GM-based), pitch, and heave accelerations per IMO CSS Code Annex 13. Inputs: container weights from bay plan, vessel motion parameters (GM, roll period, significant wave height). Outputs: tier-by-tier compressive load totals and stack weight limit compliance verdicts. Must process all bays in under 2 seconds for real-time recalculation during loading. |
| Stowage Optimization Engine | 41B73908 | Core constraint satisfaction and optimization algorithm that determines optimal container placement across all bays. Solves a multi-objective optimization problem balancing vessel stability (GM, trim), hull girder stress (shear force, bending moment), crane split efficiency, port rotation restow minimization, dangerous goods segregation, reefer plug allocation, and weight distribution. Must produce a feasible stowage plan within 5 minutes for a full vessel load. Employs heuristic search with constraint propagation using variants of simulated annealing or genetic algorithms tailored to maritime stowage. |
| Stowage Planning Engine | 41F77918 | Software subsystem responsible for generating and optimising container stowage plans (bay plans) for ultra-large container vessels with 20,000+ TEU capacity. Takes as input the vessel's cell guide geometry, container booking list with weights/dimensions/types/destinations, port rotation sequence, and regulatory constraints. Produces an optimised bay plan that minimises crane moves at each port while respecting stack weight limits (typically 90-120 tonnes per stack), tier height restrictions, hatch cover weight limits, visibility line constraints, and dangerous goods segregation rules per IMDG Code. Uses combinatorial optimisation algorithms (constraint satisfaction, simulated annealing, or mixed-integer programming) to solve what is an NP-hard bin packing variant. Must handle 20-foot, 40-foot, and 45-foot containers including high-cubes, flats, open-tops, and tank containers. Outputs BAPLIE EDI messages for terminal integration. |
| Stowage Rules Database | 40853958 | Persistent repository of vessel-specific and regulatory stowage constraints. Stores stack weight limits per bay position, tier height restrictions, reefer plug inventory and power capacity per bay, lashing bridge configurations, dangerous goods segregation matrices (IMDG Code Table 7.2.4), class-specific stowage categories, and operator-specific commercial rules (e.g., premium slot allocation, alliance partner priorities). Updated per vessel class and periodically for regulatory changes. Provides constraint lookup API to the optimization engine with sub-millisecond response for real-time constraint evaluation. |
| Temperature Alarm Processor | 51F77B18 | Evaluates temperature readings from the Reefer Monitoring Unit against cargo-specific alarm thresholds. Different commodity types (frozen meat at -18C, pharmaceuticals at +2 to +8C, bananas at +13.3C, ice cream at -25C) have different acceptable deviation ranges and alarm response times. Generates prioritized alarms: advisory (minor deviation, self-correcting), warning (sustained deviation requiring crew inspection within 2 hours), and critical (temperature excursion threatening cargo integrity requiring immediate intervention). Supports alarm acknowledgment workflow and escalation to bridge if unacknowledged within configurable timeout. |
| Terminal Interface and EDI Gateway | 50F57358 | Communications subsystem providing bidirectional data exchange between the shipboard cargo management system and shore-side terminal operating systems (TOS), shipping line booking systems, and port authorities. Implements UN/EDIFACT maritime EDI message standards: BAPLIE (bay plan), COPARN (container announcement/booking), MOVINS (stowage instruction), CUSCAR (customs cargo report), IFTDGN (dangerous goods notification), and VERMAS (verified gross mass). Supports transmission via ship-to-shore satellite communication (VSAT, Fleet Xpress at 2-10 Mbps), supplemented by 4G/LTE when in port. Handles message queuing, retry logic, and store-and-forward for unreliable satellite links. Validates inbound messages against EDI schemas and flags discrepancies between terminal-reported container data and the ship's bay plan. Must process a complete BAPLIE update for a 20,000 TEU vessel (20,000+ container records) within 120 seconds. |
| Terminal Operating System Connector | 40B57108 | Software integration component within a container ship cargo management system. Manages bidirectional data exchange with shore-side Terminal Operating Systems (TOS) at multiple container terminals worldwide (Navis N4, TOPS, Jade Master Terminal). Handles session management, mutual TLS authentication, and protocol negotiation across heterogeneous TOS platforms. Supports both pull (polling REST APIs) and push (webhook/subscription) interaction patterns. Maintains up to 20 concurrent terminal connections during multi-port cargo planning. |
| Vessel Stowage Model | 4084B108 | Three-dimensional data model representing the container vessel's cargo capacity. Maps every container slot by bay, row, and tier with attributes including cell guide dimensions, stack weight limits, tier height limits, reefer plug locations, lashing bridge positions, and hatch cover groupings. Derived from the vessel's General Arrangement and Capacity Plan. Supports container sizes 20ft, 40ft, 45ft, and high-cube variants. Holds approximately 6000-24000 TEU depending on vessel class. The model must accurately reflect physical constraints — a slot blocked by a lashing bridge or hatch coaming cannot accept cargo. Updated when vessel modifications occur. |
| VGM Compliance and Weight Verification System | 40A77B59 | Subsystem implementing SOLAS Chapter VI Regulation 2 verified gross mass (VGM) requirements, which mandate that every packed container's actual gross weight must be verified before vessel loading. Receives VGM declarations from shippers via the EDI gateway and validates them against booking data and container tare weights from the BIC database. Cross-checks VGM against weighbridge measurements when available from terminal integration. Flags containers with missing VGM (which must not be loaded per SOLAS), VGM discrepancies exceeding 5% between declared and measured weight, and containers exceeding the maximum payload rating stamped on the CSC safety approval plate. Feeds verified weights to the stowage planning engine and stability monitoring system, as inaccurate weights are a primary cause of container stack collapses and vessel stability incidents. Must maintain an audit trail of all VGM declarations for regulatory inspection. |
| VGM Compliance Validator | 40A53B58 | Regulatory compliance checking module that validates VGM declarations against SOLAS Chapter VI Part A Regulation 2 requirements. Verifies that the declaring shipper or their agent is authorized under the flag state administration. Checks that the weighing method (Method 1 whole-container or Method 2 aggregated) is identified and that the weighing equipment calibration certificate is current. Enforces country-specific VGM submission deadlines relative to vessel cut-off times. Maintains a register of approved weighing service providers and their calibration validity periods. |
| VGM Declaration Receiver | 40E57358 | EDI message processing module that receives Verified Gross Mass declarations from shippers and freight forwarders via VERMAS (UN/EDIFACT) messages, terminal operating system feeds, and manual entry interfaces. Parses Method 1 (whole-container weighing) and Method 2 (aggregated package weights plus tare) declarations. Validates message format conformance to SMDG VERMAS D.13B standard. Handles batch ingestion of 500+ declarations per port call within 60 seconds. Outputs structured VGM records with shipper identification, weighing method, authorized weigher details, and timestamp for downstream compliance validation. |
| VGM Reporting and Audit Module | 40E57B58 | Report generation and audit trail module that produces regulatory compliance documentation for port state control inspections and flag state audits. Generates per-voyage VGM compliance summaries showing declaration coverage percentage, discrepancy rates, and rejected containers. Produces individual container VGM certificates with full chain of custody from declaration receipt through verification to loading authorization. Creates exportable audit logs in PDF and structured XML formats meeting IMO FAL Convention Annex requirements. Tracks key performance indicators including average VGM processing time, discrepancy rate trends, and weighing equipment calibration status across the fleet. |
| Weighbridge Data Interface | 54A57218 | Hardware integration module that acquires container weight measurements from terminal weighbridge systems, ship-mounted cargo scales, and crane load cells. Interfaces via Modbus TCP, OPC-UA, or RS-232 serial protocols depending on weighbridge manufacturer. Acquires gross weight readings with resolution of 10 kg for containers up to 40 tonnes. Applies calibration corrections using stored calibration certificates with traceability to national metrology standards. Timestamps each measurement with GPS-synchronized time. |
| Weight Discrepancy Detector | 40A63958 | Comparison engine that cross-checks declared VGM values against actual weighbridge measurements, booking weight estimates, and historical container weight profiles. Applies configurable tolerance thresholds per national maritime authority guidelines — typically 5% or 500 kg whichever is greater per IMO MSC.1/Circ.1475. Flags containers exceeding tolerance as discrepant triggering hold-for-reweigh or rejection workflows. Performs statistical outlier detection across load lists to identify systematic declaration errors. |
| What-If Simulation Engine | 40A53B18 | Software decision support component within a container ship cargo management system. Provides the cargo officer with what-if analysis capability to evaluate the impact of proposed container moves, stowage changes, or ballast adjustments before committing them. Calculates stability (GM, GZ, trim, heel), longitudinal strength (bending moment, shear force), dangerous goods compliance, lashing adequacy, and schedule impact for proposed scenarios. Runs full stability and stress calculations in under 10 seconds for a 20,000 TEU load case. Supports comparison of up to 5 alternative scenarios side-by-side. Generates recommendations ranked by safety margin and operational efficiency. |
| Wind Force Estimator | 40E53158 | Environmental force calculation module in a container ship securing system. Computes wind pressure loads on exposed container faces using Beaufort-scale wind speed profiles and exposed area geometry per CSS Code Annex 13. Calculates windage area per bay considering stowage height, row position, and hatch cover geometry. Accounts for shielding effects from adjacent bays and superstructure. Inputs: stowage configuration, wind speed/direction from vessel meteorological system. Outputs: per-container and per-stack wind forces (longitudinal and transverse) for input to the lashing load balance calculation. |
| Component | Belongs To |
|---|---|
| Stowage Planning Engine | Container Ship Cargo Management System |
| Stability and Stress Monitoring System | Container Ship Cargo Management System |
| Reefer Container Management System | Container Ship Cargo Management System |
| Dangerous Goods Management System | Container Ship Cargo Management System |
| Lashing and Securing Calculator | Container Ship Cargo Management System |
| Terminal Interface and EDI Gateway | Container Ship Cargo Management System |
| Container Tracking and Inventory System | Container Ship Cargo Management System |
| Cargo Operations Display and Decision Support | Container Ship Cargo Management System |
| VGM Compliance and Weight Verification System | Container Ship Cargo Management System |
| Intact Stability Computer | Stability and Stress Monitoring System |
| Stability Alarm and Advisory Generator | Stability and Stress Monitoring System |
| Draught Sensor Interface | Stability and Stress Monitoring System |
| Damage Stability Assessor | Stability and Stress Monitoring System |
| Longitudinal Strength Monitor | Stability and Stress Monitoring System |
| Loading Condition Database | Stability and Stress Monitoring System |
| Vessel Stowage Model | Stowage Planning Engine |
| Stowage Optimization Engine | Stowage Planning Engine |
| Port Rotation Planner | Stowage Planning Engine |
| Crane Split Calculator | Stowage Planning Engine |
| Hatch Cover Sequence Planner | Stowage Planning Engine |
| Stowage Rules Database | Stowage Planning Engine |
| Restow Minimization Module | Stowage Planning Engine |
| IMDG Code Database | Dangerous Goods Management System |
| DG Declaration Validator | Dangerous Goods Management System |
| Segregation Rules Engine | Dangerous Goods Management System |
| DG Stowage Position Validator | Dangerous Goods Management System |
| Emergency Response Information System | Dangerous Goods Management System |
| DG Manifest Generator | Dangerous Goods Management System |
| Reefer Monitoring Unit | Reefer Container Management System |
| Reefer Power Distribution Controller | Reefer Container Management System |
| Pre-Trip Inspection Module | Reefer Container Management System |
| Temperature Alarm Processor | Reefer Container Management System |
| Reefer Data Logger | Reefer Container Management System |
| Controlled Atmosphere Monitor | Reefer Container Management System |
| VGM Declaration Receiver | VGM Compliance and Weight Verification System |
| Weighbridge Data Interface | VGM Compliance and Weight Verification System |
| Weight Discrepancy Detector | VGM Compliance and Weight Verification System |
| VGM Compliance Validator | VGM Compliance and Weight Verification System |
| Container Weight Database | VGM Compliance and Weight Verification System |
| VGM Reporting and Audit Module | VGM Compliance and Weight Verification System |
| Stack Weight Calculator | Lashing and Securing Calculator |
| Lashing Rod Load Analyzer | Lashing and Securing Calculator |
| Racking Force Calculator | Lashing and Securing Calculator |
| Wind Force Estimator | Lashing and Securing Calculator |
| CSS Code Compliance Engine | Lashing and Securing Calculator |
| Securing Equipment Database | Lashing and Securing Calculator |
| Container Registry | Container Tracking and Inventory System |
| Bay Plan Manager | Container Tracking and Inventory System |
| Container Event Logger | Container Tracking and Inventory System |
| Crane Position Interface | Container Tracking and Inventory System |
| Container Status Engine | Container Tracking and Inventory System |
| Booking and Manifest Linker | Container Tracking and Inventory System |
| EDI Message Parser and Translator | Terminal Interface and EDI Gateway |
| Terminal Operating System Connector | Terminal Interface and EDI Gateway |
| Message Queue and Delivery Manager | Terminal Interface and EDI Gateway |
| Port Authority and Customs Interface | Terminal Interface and EDI Gateway |
| Communication Link Manager | Terminal Interface and EDI Gateway |
| Bay Plan Visualization Engine | Cargo Operations Display and Decision Support |
| Loading Sequence Display | Cargo Operations Display and Decision Support |
| Alarm and Notification Manager | Cargo Operations Display and Decision Support |
| What-If Simulation Engine | Cargo Operations Display and Decision Support |
| Reporting and Analytics Module | Cargo Operations Display and Decision Support |
| From | To |
|---|---|
| Stowage Planning Engine | Stability and Stress Monitoring System |
| Stowage Planning Engine | Dangerous Goods Management System |
| Stowage Planning Engine | Lashing and Securing Calculator |
| Stowage Planning Engine | Reefer Container Management System |
| Container Tracking and Inventory System | Stowage Planning Engine |
| Terminal Interface and EDI Gateway | Container Tracking and Inventory System |
| VGM Compliance and Weight Verification System | Stowage Planning Engine |
| VGM Compliance and Weight Verification System | Stability and Stress Monitoring System |
| Cargo Operations Display and Decision Support | Stability and Stress Monitoring System |
| Cargo Operations Display and Decision Support | Stowage Planning Engine |
| Intact Stability Computer | Damage Stability Assessor |
| Intact Stability Computer | Stability Alarm and Advisory Generator |
| Draught Sensor Interface | Intact Stability Computer |
| Longitudinal Strength Monitor | Stability Alarm and Advisory Generator |
| Loading Condition Database | Intact Stability Computer |
| Stowage Optimization Engine | Vessel Stowage Model |
| Stowage Optimization Engine | Stowage Rules Database |
| Port Rotation Planner | Stowage Optimization Engine |
| Crane Split Calculator | Stowage Optimization Engine |
| Hatch Cover Sequence Planner | Crane Split Calculator |
| Restow Minimization Module | Port Rotation Planner |
| Restow Minimization Module | Stowage Optimization Engine |
| DG Declaration Validator | IMDG Code Database |
| Segregation Rules Engine | IMDG Code Database |
| DG Stowage Position Validator | IMDG Code Database |
| DG Stowage Position Validator | Segregation Rules Engine |
| Emergency Response Information System | IMDG Code Database |
| DG Manifest Generator | DG Declaration Validator |
| DG Manifest Generator | DG Stowage Position Validator |
| Reefer Monitoring Unit | Temperature Alarm Processor |
| Reefer Monitoring Unit | Reefer Data Logger |
| Reefer Monitoring Unit | Controlled Atmosphere Monitor |
| Reefer Monitoring Unit | Reefer Power Distribution Controller |
| Reefer Power Distribution Controller | Temperature Alarm Processor |
| Pre-Trip Inspection Module | Reefer Monitoring Unit |
| Pre-Trip Inspection Module | Reefer Data Logger |
| Controlled Atmosphere Monitor | Temperature Alarm Processor |
| VGM Declaration Receiver | Weight Discrepancy Detector |
| VGM Declaration Receiver | Container Weight Database |
| Weighbridge Data Interface | Weight Discrepancy Detector |
| Weighbridge Data Interface | Container Weight Database |
| Weight Discrepancy Detector | VGM Compliance Validator |
| VGM Compliance Validator | Container Weight Database |
| Container Weight Database | VGM Reporting and Audit Module |
| VGM Declaration Receiver | Terminal Interface and EDI Gateway |
| Container Weight Database | Container Tracking and Inventory System |
| VGM Reporting and Audit Module | Cargo Operations Display and Decision Support |
| VGM Compliance Validator | Stowage Planning Engine |
| Container Weight Database | Stability and Stress Monitoring System |
| Crane Position Interface | Bay Plan Manager |
| Crane Position Interface | Container Event Logger |
| Container Status Engine | Container Registry |
| Container Status Engine | Bay Plan Manager |
| Booking and Manifest Linker | Container Registry |
| Stack Weight Calculator | Securing Equipment Database |
| Lashing Rod Load Analyzer | Securing Equipment Database |
| Lashing Rod Load Analyzer | Wind Force Estimator |
| Lashing Rod Load Analyzer | Racking Force Calculator |
| CSS Code Compliance Engine | Lashing Rod Load Analyzer |
| CSS Code Compliance Engine | Stack Weight Calculator |
| CSS Code Compliance Engine | Securing Equipment Database |
| Lashing and Securing Calculator | Stability and Stress Monitoring System |
| Container Tracking and Inventory System | VGM Compliance and Weight Verification System |
| Crane Position Interface | Terminal Interface and EDI Gateway |
| EDI Message Parser and Translator | Message Queue and Delivery Manager |
| Terminal Operating System Connector | Message Queue and Delivery Manager |
| Port Authority and Customs Interface | Message Queue and Delivery Manager |
| Communication Link Manager | Message Queue and Delivery Manager |
| Port Authority and Customs Interface | EDI Message Parser and Translator |
| Terminal Operating System Connector | EDI Message Parser and Translator |
| Bay Plan Visualization Engine | Loading Sequence Display |
| Bay Plan Visualization Engine | Alarm and Notification Manager |
| What-If Simulation Engine | Bay Plan Visualization Engine |
| Reporting and Analytics Module | Bay Plan Visualization Engine |
| Alarm and Notification Manager | What-If Simulation Engine |
| Alarm and Notification Manager | Stability Alarm and Advisory Generator |
| Alarm and Notification Manager | Temperature Alarm Processor |
| Alarm and Notification Manager | Weight Discrepancy Detector |
| What-If Simulation Engine | Intact Stability Computer |
| What-If Simulation Engine | Stowage Optimization Engine |
| What-If Simulation Engine | CSS Code Compliance Engine |
| Loading Sequence Display | Container Status Engine |
| Loading Sequence Display | Bay Plan Manager |
| Reporting and Analytics Module | Container Registry |
| Component | Output |
|---|---|
| Intact Stability Computer | stability parameters |
| Longitudinal Strength Monitor | structural load distribution |
| Vessel Stowage Model | slot availability matrix and physical constraint map |
| Stowage Optimization Engine | optimized container placement plan (bay plan) |
| Port Rotation Planner | bay affinity map and port-discharge group assignments |
| Crane Split Calculator | crane work sequence with timed move list |
| Hatch Cover Sequence Planner | hatch cover removal and replacement sequence |
| Stowage Rules Database | constraint lookup responses for optimization queries |
| Restow Minimization Module | restow analysis and pre-emptive shift proposals |
| IMDG Code Database | DG classification and compliance reference data |
| DG Declaration Validator | Validated DG declaration records with compliance flags |
| Segregation Rules Engine | Segregation compatibility matrix evaluations and separation distances |
| DG Stowage Position Validator | Stowage position accept/reject decisions with violation codes |
| Emergency Response Information System | EmS fire and spillage schedules and MFAG treatment procedures |
| DG Manifest Generator | SOLAS-compliant DG manifest and stowage plan documents |
| Reefer Monitoring Unit | real-time temperature and status readings from all connected reefer containers |
| Reefer Power Distribution Controller | power allocation decisions and circuit status for reefer outlets |
| Pre-Trip Inspection Module | PTI pass/fail verdicts and inspection records per container unit |
| Temperature Alarm Processor | prioritized temperature deviation alarms with severity classification |
| Reefer Data Logger | tamper-evident continuous temperature logs and compliance reports |
| Controlled Atmosphere Monitor | atmosphere composition readings and CA deviation alarms |
| VGM Declaration Receiver | structured VGM records |
| Weighbridge Data Interface | calibrated container weight measurements |
| Weight Discrepancy Detector | discrepancy reports with severity classification |
| VGM Compliance Validator | compliance status and loading authorization |
| Container Weight Database | weight records and audit data |
| VGM Reporting and Audit Module | compliance reports and VGM certificates |
| Stack Weight Calculator | tier-by-tier compressive load totals and stack weight limit verdicts |
| Lashing Rod Load Analyzer | per-lashing load percentages of SWL and critical lashing identification |
| Racking Force Calculator | racking force per tier as percentage of ISO structural limit |
| Wind Force Estimator | per-container and per-stack wind forces for lashing load balance |
| CSS Code Compliance Engine | per-bay compliance verdicts with CSS Code clause references |
| Securing Equipment Database | securing element SWL and position data for lashing calculations |
| Container Registry | authoritative container attribute records for all vessel containers |
| Bay Plan Manager | real-time container-to-position mapping for all bays |
| Container Event Logger | timestamped audit trail of all container movement events |
| Crane Position Interface | confirmed container IDs and stowage positions from crane operations |
| Container Status Engine | container lifecycle state and downstream update triggers |
| Booking and Manifest Linker | booking-container linkages and customs manifest documents |
| EDI Message Parser and Translator | Parsed container and cargo data objects |
| Terminal Operating System Connector | Synchronised terminal planning data |
| Message Queue and Delivery Manager | Guaranteed-delivery message streams |
| Port Authority and Customs Interface | Regulatory compliance reports and notifications |
| Communication Link Manager | Managed communication sessions with link metrics |
| Bay Plan Visualization Engine | Interactive vessel bay plan displays |
| Loading Sequence Display | Real-time crane and loading progress views |
| Alarm and Notification Manager | Prioritised alarm notifications with acknowledgment tracking |
| What-If Simulation Engine | Scenario comparison results with safety margin analysis |
| Reporting and Analytics Module | Operational and regulatory reports |
| Source | Target | Type | Description |
|---|---|---|---|
| SYS-REQS-007 | IFC-DEFS-040 | derives | |
| SYS-REQS-001 | IFC-DEFS-039 | derives | |
| SYS-REQS-005 | IFC-DEFS-032 | derives | |
| SYS-REQS-006 | IFC-DEFS-030 | derives | |
| SYS-REQS-006 | IFC-DEFS-022 | derives | |
| SYS-REQS-005 | IFC-DEFS-027 | derives | |
| SYS-REQS-005 | IFC-DEFS-026 | derives | |
| SYS-REQS-005 | IFC-DEFS-025 | derives | |
| SYS-REQS-005 | IFC-DEFS-024 | derives | |
| SYS-REQS-005 | IFC-DEFS-023 | derives | |
| SYS-REQS-005 | IFC-DEFS-022 | derives | |
| SYS-REQS-003 | IFC-DEFS-015 | derives | |
| SYS-REQS-003 | IFC-DEFS-014 | derives | |
| SYS-REQS-003 | IFC-DEFS-013 | derives | |
| SYS-REQS-003 | IFC-DEFS-012 | derives | |
| SYS-REQS-003 | IFC-DEFS-011 | derives | |
| SYS-REQS-001 | IFC-SSMS-IFC-005 | derives | |
| SYS-REQS-001 | IFC-SSMS-IFC-003 | derives | |
| SYS-REQS-009 | IFC-SSMS-IFC-001 | derives | |
| SYS-REQS-005 | IFC-SSMS-IFC-002 | derives | |
| SYS-REQS-001 | IFC-SSMS-IFC-004 | derives | |
| SYS-REQS-005 | SUB-REQS-051 | derives | |
| SYS-REQS-010 | SUB-REQS-078 | derives | |
| SYS-REQS-008 | SUB-REQS-077 | derives | |
| SYS-REQS-008 | SUB-REQS-076 | derives | |
| SYS-REQS-009 | SUB-REQS-075 | derives | |
| SYS-REQS-009 | SUB-REQS-074 | derives | |
| SYS-REQS-009 | SUB-REQS-073 | derives | |
| SYS-REQS-006 | SUB-REQS-072 | derives | |
| SYS-REQS-006 | SUB-REQS-071 | derives | |
| SYS-REQS-006 | SUB-REQS-070 | derives | |
| SYS-REQS-006 | SUB-REQS-069 | derives | |
| SYS-REQS-006 | SUB-REQS-068 | derives | |
| SYS-REQS-006 | SUB-REQS-067 | derives | |
| SYS-REQS-003 | SUB-REQS-020 | derives | |
| SYS-REQS-008 | SUB-REQS-066 | derives | |
| SYS-REQS-008 | SUB-REQS-063 | derives | |
| SYS-REQS-007 | SUB-REQS-060 | derives | |
| SYS-REQS-007 | SUB-REQS-059 | derives | |
| SYS-REQS-007 | SUB-REQS-057 | derives | |
| SYS-REQS-007 | SUB-REQS-054 | derives | |
| SYS-REQS-008 | SUB-REQS-065 | derives | |
| SYS-REQS-008 | SUB-REQS-064 | derives | |
| SYS-REQS-008 | SUB-REQS-062 | derives | |
| SYS-REQS-008 | SUB-REQS-061 | derives | |
| SYS-REQS-007 | SUB-REQS-058 | derives | |
| SYS-REQS-007 | SUB-REQS-056 | derives | |
| SYS-REQS-007 | SUB-REQS-055 | derives | |
| SYS-REQS-007 | SUB-REQS-053 | derives | |
| SYS-REQS-005 | SUB-REQS-052 | derives | |
| SYS-REQS-001 | SUB-SSMS-002 | derives | |
| SYS-REQS-001 | SUB-SSMS-003 | derives | |
| SYS-REQS-001 | SUB-SSMS-005 | derives | |
| SYS-REQS-001 | SUB-SSMS-006 | derives | |
| SYS-REQS-001 | SUB-SSMS-007 | derives | |
| SYS-REQS-001 | SUB-SSMS-004 | derives | |
| SYS-REQS-001 | SUB-SSMS-008 | derives | |
| SYS-REQS-001 | SUB-SSMS-009 | derives | |
| SYS-REQS-001 | SUB-SSMS-010 | derives | |
| SYS-REQS-002 | SUB-REQS-011 | derives | |
| SYS-REQS-002 | SUB-REQS-012 | derives | |
| SYS-REQS-002 | SUB-REQS-013 | derives | |
| SYS-REQS-002 | SUB-REQS-014 | derives | |
| SYS-REQS-002 | SUB-REQS-015 | derives | |
| SYS-REQS-003 | SUB-REQS-016 | derives | |
| SYS-REQS-002 | SUB-REQS-017 | derives | |
| SYS-REQS-002 | SUB-REQS-018 | derives | |
| SYS-REQS-009 | SUB-REQS-019 | derives | |
| SYS-REQS-003 | SUB-REQS-021 | derives | |
| SYS-REQS-003 | SUB-REQS-023 | derives | |
| SYS-REQS-003 | SUB-REQS-024 | derives | |
| SYS-REQS-003 | SUB-REQS-025 | derives | |
| SYS-REQS-003 | SUB-REQS-026 | derives | |
| SYS-REQS-003 | SUB-REQS-022 | derives | |
| SYS-REQS-003 | SUB-REQS-027 | derives | |
| SYS-REQS-003 | SUB-REQS-028 | derives | |
| SYS-REQS-004 | SUB-REQS-029 | derives | |
| SYS-REQS-004 | SUB-REQS-030 | derives | |
| SYS-REQS-004 | SUB-REQS-033 | derives | |
| SYS-REQS-004 | SUB-REQS-034 | derives | |
| SYS-REQS-004 | SUB-REQS-035 | derives | |
| SYS-REQS-004 | SUB-REQS-036 | derives | |
| SYS-REQS-004 | SUB-REQS-037 | derives | |
| SYS-REQS-004 | SUB-REQS-038 | derives | |
| SYS-REQS-004 | SUB-REQS-039 | derives | |
| SYS-REQS-004 | SUB-REQS-040 | derives | |
| SYS-REQS-005 | SUB-REQS-041 | derives | |
| SYS-REQS-005 | SUB-REQS-042 | derives | |
| SYS-REQS-005 | SUB-REQS-043 | derives | |
| SYS-REQS-005 | SUB-REQS-044 | derives | |
| SYS-REQS-005 | SUB-REQS-045 | derives | |
| SYS-REQS-005 | SUB-REQS-046 | derives | |
| SYS-REQS-005 | SUB-REQS-047 | derives | |
| SYS-REQS-005 | SUB-REQS-048 | derives | |
| SYS-REQS-005 | SUB-REQS-049 | derives | |
| SYS-REQS-005 | SUB-REQS-050 | derives | |
| STK-NEEDS-009 | SYS-REQS-012 | derives | |
| STK-NEEDS-009 | SYS-REQS-011 | derives | |
| STK-NEEDS-009 | SYS-REQS-010 | derives | |
| STK-NEEDS-002 | SYS-REQS-009 | derives | |
| STK-NEEDS-001 | SYS-REQS-009 | derives | |
| STK-NEEDS-002 | SYS-REQS-008 | derives | |
| STK-NEEDS-001 | SYS-REQS-008 | derives | |
| STK-NEEDS-007 | SYS-REQS-007 | derives | |
| STK-NEEDS-006 | SYS-REQS-006 | derives | |
| STK-NEEDS-005 | SYS-REQS-005 | derives | |
| STK-NEEDS-004 | SYS-REQS-004 | derives | |
| STK-NEEDS-003 | SYS-REQS-003 | derives | |
| STK-NEEDS-002 | SYS-REQS-002 | derives | |
| STK-NEEDS-001 | SYS-REQS-001 | derives |
| Requirement | Verified By | Type | Description |
|---|---|---|---|
| IFC-DEFS-039 | VER-METHODS-047 | verifies | |
| IFC-DEFS-040 | VER-METHODS-049 | verifies | |
| IFC-DEFS-038 | VER-METHODS-046 | verifies | |
| IFC-DEFS-037 | VER-METHODS-045 | verifies | |
| IFC-DEFS-036 | VER-METHODS-044 | verifies | |
| IFC-DEFS-035 | VER-METHODS-043 | verifies | |
| IFC-DEFS-034 | VER-METHODS-042 | verifies | |
| IFC-DEFS-033 | VER-METHODS-041 | verifies | |
| IFC-DEFS-032 | VER-METHODS-040 | verifies | |
| IFC-DEFS-031 | VER-METHODS-039 | verifies | |
| IFC-DEFS-030 | VER-METHODS-038 | verifies | |
| IFC-DEFS-029 | VER-METHODS-037 | verifies | |
| IFC-DEFS-028 | VER-METHODS-036 | verifies | |
| IFC-DEFS-027 | VER-METHODS-033 | verifies | |
| IFC-DEFS-026 | VER-METHODS-032 | verifies | |
| IFC-DEFS-025 | VER-METHODS-031 | verifies | |
| IFC-DEFS-024 | VER-METHODS-030 | verifies | |
| IFC-DEFS-023 | VER-METHODS-029 | verifies | |
| IFC-DEFS-022 | VER-METHODS-028 | verifies | |
| IFC-DEFS-021 | VER-METHODS-027 | verifies | |
| IFC-DEFS-020 | VER-METHODS-026 | verifies | |
| IFC-DEFS-019 | VER-METHODS-025 | verifies | |
| IFC-DEFS-018 | VER-METHODS-024 | verifies | |
| IFC-DEFS-017 | VER-METHODS-023 | verifies | |
| IFC-DEFS-016 | VER-METHODS-022 | verifies | |
| IFC-DEFS-015 | VER-METHODS-021 | verifies | |
| IFC-DEFS-014 | VER-METHODS-020 | verifies | |
| IFC-DEFS-013 | VER-METHODS-019 | verifies | |
| IFC-DEFS-012 | VER-METHODS-018 | verifies | |
| IFC-DEFS-011 | VER-METHODS-017 | verifies | |
| IFC-DEFS-010 | VER-METHODS-014 | verifies | |
| IFC-DEFS-009 | VER-METHODS-013 | verifies | |
| IFC-DEFS-008 | VER-METHODS-012 | verifies | |
| IFC-DEFS-007 | VER-METHODS-011 | verifies | |
| IFC-DEFS-006 | VER-METHODS-010 | verifies | |
| IFC-SSMS-IFC-001 | VER-SSMS-VER-009 | verifies | |
| IFC-SSMS-IFC-004 | VER-SSMS-VER-004 | verifies | |
| SUB-REQS-078 | VER-METHODS-050 | verifies | |
| SUB-REQS-048 | VER-METHODS-035 | verifies | |
| SUB-REQS-045 | VER-METHODS-034 | verifies | |
| SUB-REQS-016 | VER-METHODS-016 | verifies | |
| SUB-REQS-011 | VER-METHODS-015 | verifies | |
| SUB-SSMS-010 | VER-SSMS-VER-007 | verifies | |
| SUB-SSMS-009 | VER-SSMS-VER-006 | verifies | |
| SUB-SSMS-004 | VER-SSMS-VER-005 | verifies | |
| SUB-SSMS-003 | VER-SSMS-VER-002 | verifies | |
| SUB-SSMS-007 | VER-SSMS-VER-003 | verifies | |
| SUB-SSMS-002 | VER-SSMS-VER-001 | verifies |
| Ref | Document | Requirement |
|---|---|---|
| IFC-DEFS-001 | interface-requirements | The Stability and Stress Monitoring System SHALL receive proposed loading sequences from the Stowage Planning Engine as ... |
| IFC-DEFS-002 | interface-requirements | The Stability and Stress Monitoring System SHALL accept verified gross mass (VGM) data from the VGM Compliance and Weigh... |
| IFC-DEFS-003 | interface-requirements | The Stability and Stress Monitoring System SHALL publish real-time stability status to the Cargo Operations Display and ... |
| IFC-DEFS-004 | interface-requirements | The Stability and Stress Monitoring System SHALL interface with hull-mounted hydrostatic pressure draught sensors via a ... |
| IFC-DEFS-005 | interface-requirements | When a critical stability or strength alarm is generated, the Stability and Stress Monitoring System SHALL transmit the ... |
| SUB-REQS-002 | subsystem-requirements | The Stability and Stress Monitoring System SHALL calculate intact stability parameters including metacentric height (GM)... |
| SUB-REQS-003 | subsystem-requirements | The Stability and Stress Monitoring System SHALL compute hull girder shear force and bending moment at each of the vesse... |
| SUB-REQS-004 | subsystem-requirements | The Stability and Stress Monitoring System SHALL evaluate probabilistic damage stability in accordance with SOLAS Chapte... |
| SUB-REQS-005 | subsystem-requirements | The Stability and Stress Monitoring System SHALL acquire draught readings from at least four hull-mounted pressure senso... |
| SUB-REQS-006 | subsystem-requirements | The Stability and Stress Monitoring System SHALL calculate free surface correction for all slack tanks using actual tank... |
| SUB-REQS-007 | subsystem-requirements | When any stability or strength parameter exceeds its warning threshold, the Stability and Stress Monitoring System SHALL... |
| SUB-REQS-008 | subsystem-requirements | The Stability and Stress Monitoring System SHALL store at least 100 loading conditions including departure, arrival, and... |
| SUB-REQS-009 | subsystem-requirements | When fewer than three of the four draught sensors are operational, the Stability and Stress Monitoring System SHALL main... |
| SUB-REQS-010 | subsystem-requirements | The Stability and Stress Monitoring System SHALL evaluate the IMO weather criterion (Resolution A.749(18) Regulation 3.2... |
| VER-METHODS-001 | verification-plan | The intact stability calculation (SUB-SSMS-002) SHALL be verified by loading 50 pre-computed test conditions from the ve... |
| VER-METHODS-002 | verification-plan | The longitudinal strength computation (SUB-SSMS-003) SHALL be verified by comparing system-calculated shear force and be... |
| VER-METHODS-003 | verification-plan | The alarm generation system (SUB-SSMS-007) SHALL be verified by injecting simulated stability and strength values at eac... |
| VER-METHODS-004 | verification-plan | The draught sensor interface (IFC-SSMS-IFC-004) SHALL be verified by connecting a NMEA signal simulator generating known... |
| VER-METHODS-005 | verification-plan | The probabilistic damage stability assessment (SUB-SSMS-004) SHALL be verified by comparing system-calculated attained s... |
| VER-METHODS-006 | verification-plan | The degraded mode operation (SUB-SSMS-009) SHALL be verified by systematically disabling one and then two draught sensor... |
| VER-METHODS-007 | verification-plan | The IMO weather criterion evaluation (SUB-SSMS-010) SHALL be verified by loading at least 5 test conditions with known w... |
| VER-METHODS-009 | verification-plan | The stowage planning interface (IFC-SSMS-IFC-001) SHALL be verified by transmitting 100 representative loading sequences... |