System

{{entity:Container Ship Cargo Management System}} — completing first-pass decomposition. Prior sessions decomposed 7 of 9 subsystems to component level. This session tackled the remaining two: {{entity:Terminal Interface and EDI Gateway}} and {{entity:Cargo Operations Display and Decision Support}}. With both now decomposed, the system reaches first-pass-complete status with 184 requirements across 6 documents, 62 PART_OF relationships, and 60 entities in the SE:container-ship-cargo namespace.

Decomposition

Terminal Interface and EDI Gateway was decomposed into five components reflecting the real communications architecture of a modern container vessel: {{entity:EDI Message Parser and Translator}} {{hex:41F77358}} handles EDIFACT/XML protocol conversion for all seven standard message types (BAPLIE, COPARN, MOVINS, CODECO, VERMAS, CUSCAR, IFTDGN). {{entity:Terminal Operating System Connector}} {{hex:40B57108}} manages sessions with heterogeneous shore-side TOS platforms. {{entity:Message Queue and Delivery Manager}} {{hex:40B77308}} provides reliable store-and-forward over unreliable maritime satellite links — the architectural spine of the subsystem. {{entity:Port Authority and Customs Interface}} {{hex:40F57B58}} generates regulatory submissions per IMO FAL Convention and EU Maritime Single Window. {{entity:Communication Link Manager}} {{hex:50F77008}} handles VSAT/Inmarsat failover with sub-30-second switchover.

Cargo Operations Display and Decision Support was decomposed into five components: {{entity:Bay Plan Visualization Engine}} {{hex:44FD7118}} renders the vessel bay plan with multi-layer overlays for DG, reefer, weight, and lashing. {{entity:Loading Sequence Display}} {{hex:40EC7308}} tracks multi-crane operations in real time. {{entity:Alarm and Notification Manager}} {{hex:40FD7B59}} aggregates safety-critical alarms from all cargo subsystems into a unified priority queue following ISM Code principles. {{entity:What-If Simulation Engine}} {{hex:40A53B18}} provides scenario analysis by calling the existing stability, stowage, and lashing calculation engines in read-only mode. {{entity:Reporting and Analytics Module}} {{hex:40E47358}} generates operational and regulatory reports.

flowchart TB
  n0["Stowage Planning Engine"]
  n1["Stability and Stress Monitoring"]
  n2["Reefer Container Management"]
  n3["Dangerous Goods Management"]
  n4["Lashing and Securing Calculator"]
  n5["Terminal Interface and EDI Gateway"]
  n6["Container Tracking and Inventory"]
  n7["Cargo Operations Display"]
  n8["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

Analysis

Cross-domain analog search revealed the {{entity:Alarm and Notification Manager}} shares 29 traits with the {{entity:Centralised Radiation Monitoring Display and Alarm System}} from the radiochemistry laboratory decomposition ({{hex:54ED7B59}}). Both aggregate safety-critical alarms from distributed sensor networks into a unified operator display with mandatory acknowledgment. The radiation monitoring system adds the {{trait:Observable}} and {{trait:Powered}} physical traits because its display hardware operates in a controlled environment, whereas the cargo alarm manager is a pure software component running on the vessel’s computing infrastructure. This pattern — centralised alarm aggregation with severity prioritisation and audit logging — appears to be a universal safety-system archetype.

The {{entity:Message Queue and Delivery Manager}} matches at 31 traits with the generic asynchronous message queue entity, confirming its classification is ontologically sound. Its closest non-cargo analog is the {{entity:Network Management and Monitoring System}} from the cybersecurity operations centre — both manage unreliable communication channels with guaranteed delivery semantics.

Lint reported 8 findings (3 high, 4 medium, 1 low). The three high-severity findings are ontological mismatches where the system, reefer monitoring unit, and temperature alarm processor lack the Physical Object trait despite having physical constraints in requirements. These reflect the system’s hybrid nature — software-defined components deployed on physical shipboard hardware — and should be addressed in QC by adding physical embodiment requirements.

Requirements

This session created 11 subsystem requirements ({{sub:SUB-REQS-067}} through {{sub:SUB-REQS-077}}), 6 interface requirements ({{ifc:IFC-DEFS-033}} through {{ifc:IFC-DEFS-038}}), 6 verification entries (VER-METHODS-041 through VER-METHODS-046), and 2 architecture decisions ({{stk:ARC-DECISIONS-014}}, {{stk:ARC-DECISIONS-015}}). All subsystem requirements trace to parent system requirements via derives links. All interface requirements have corresponding verification entries with verifies links. Key requirement areas: EDI throughput (200 msg/s), satellite link failover (30s), message queue persistence (48h outage tolerance), alarm propagation (500ms), what-if simulation (10s for 20,000 TEU), and regulatory compliance timing (IMO FAL, EU Maritime Single Window).

Next

First-pass decomposition is complete. The next session should be a QC pass (Flow C/E) addressing: the 3 high-severity lint findings on physical embodiment, duplicate architecture decisions (ARC-DECISIONS-013/014 for Terminal Interface, ARC-DECISIONS-011/012 for prior subsystems), and the 2 degraded-mode requirements (SUB-REQS-040, SUB-SSMS-009) lacking quantified performance thresholds. Orphan analysis shows 12 architecture decisions without trace links, which is expected but should be reviewed. VER coverage stands at 45/38 for interface requirements (exceeds 100%) but subsystem requirement verification coverage should be assessed.