Stowage Planning Engine decomposed — seven components driving the vessel's cargo optimization pipeline

System

Container Ship Cargo Management System, second subsystem decomposition session. The {{entity:Stability and Stress Monitoring System}} was fully decomposed in the prior session with 6 components, 9 subsystem requirements, 5 interface requirements, and 8 verification entries. This session decomposes the {{entity:Stowage Planning Engine}} — the architectural hub of the cargo management system, connecting to 6 of the 8 other subsystems and responsible for the core container placement optimization problem.

Decomposition

The {{entity:Stowage Planning Engine}} {{hex:41F77918}} was decomposed into 7 components reflecting the real computational pipeline of a modern container stowage planning system:

  • {{entity:Vessel Stowage Model}} {{hex:4084B108}} — 3D slot representation with physical constraints (cell guides, stack weights, tier heights, lashing bridges, hatch cover groupings)
  • {{entity:Stowage Rules Database}} {{hex:40853958}} — persistent constraint repository holding IMDG segregation matrices, vessel-specific limits, and commercial rules with sub-millisecond lookup
  • {{entity:Port Rotation Planner}} {{hex:40B73B08}} — voyage-level optimizer producing bay affinity maps across 5-15 port calls, targeting restow ratios below 5%
  • {{entity:Stowage Optimization Engine}} {{hex:41B73908}} — core constraint satisfaction algorithm balancing stability, stress, segregation, crane efficiency, and restow minimization within a 120-second budget
  • {{entity:Restow Minimization Module}} {{hex:41B63B08}} — overstow analysis with 3-port lookahead and pre-emptive shift proposals
  • {{entity:Crane Split Calculator}} {{hex:41B73B08}} — distributes cargo operations across 3-6 quay cranes targeting 90% workload balance with adjacent-bay interference avoidance
  • {{entity:Hatch Cover Sequence Planner}} {{hex:40A53A08}} — sequences hatch cover lifts to minimize crane idle time while ensuring hold access safety

The decomposition separates three time horizons: voyage planning (days), per-port optimization (minutes), and operational sequencing (real-time). The {{entity:Stowage Rules Database}} is isolated from the optimizer to allow regulatory updates (IMDG Code amendments, CSM revisions) without modifying optimization code.

flowchart TB
  VSM["Vessel Stowage Model"]
  SRD["Stowage Rules Database"]
  PRP["Port Rotation Planner"]
  SOE["Stowage Optimization Engine"]
  RMM["Restow Minimization Module"]
  CSC["Crane Split Calculator"]
  HCS["Hatch Cover Sequence Planner"]
  VSM -->|Slot availability| SOE
  SRD -->|Constraint rules| SOE
  PRP -->|Bay affinity map| SOE
  SOE -->|Bay plan| CSC
  CSC -->|Crane schedule| HCS
  RMM -->|Restow analysis| PRP
  RMM -->|Shift proposals| SOE

Analysis

Cross-domain similarity analysis revealed the {{entity:Stowage Optimization Engine}} shares 93.75% trait similarity with the {{entity:Pick Planning and Optimization Module}} from the automated warehouse domain and the {{entity:Sensor Resource Scheduler}} from defence systems. All three solve constrained resource allocation problems — placing items into slots under physical, safety, and temporal constraints. The {{entity:Crane Split Calculator}} is a near-perfect structural match at 96.9% similarity, differing only in the {{trait:Powered}} trait, confirming that crane workload balancing is ontologically a scheduling/allocation problem rather than a physical control problem.

Lint reported 5 findings (1 high, 3 medium, 1 low), all from prior sessions. No new findings introduced. The high-severity finding (system entity lacking Physical Object trait) and the medium-severity degraded mode gap ({{sub:SUB-SSMS-009}}) should be addressed in a future QC session.

Requirements

9 subsystem requirements created ({{sub:SUB-REQS-011}} through {{sub:SUB-REQS-019}}) covering optimization performance (120s/20,000 TEU), port rotation planning (<5% restow ratio), crane split balance (90% workload ratio), vessel model accuracy, rules database query performance (1ms/500K queries), IMDG segregation enforcement, hatch cover sequencing, restow minimization, and what-if simulation mode (10s response for manual modifications).

5 interface requirements ({{ifc:IFC-DEFS-006}} through {{ifc:IFC-DEFS-010}}) define the SPE’s external interfaces with Container Tracking (BAPLIE manifest, 5s transfer), Stability and Stress Monitoring (3s round-trip verification), Lashing Calculator (2s per stack), Dangerous Goods Management (10s full validation), and Reefer Management (plug availability confirmation).

7 verification entries ({{sub:VER-METHODS-010}} through {{sub:VER-METHODS-016}}) trace to all 5 interface requirements and 2 key subsystem requirements (optimizer performance, IMDG enforcement). Verification coverage stands at 15/28 (54%) for combined SUB+IFC requirements across the project.

All subsystem requirements trace to parent system requirements via derives linksets. Architecture decision {{stk:ARC-DECISIONS-002}} records the rationale for the 7-component decomposition.

Next

7 of 9 subsystems remain without component decomposition. Next session should tackle the {{entity:Dangerous Goods Management System}} — the highest safety-criticality among remaining subsystems, responsible for IMDG Code compliance and segregation enforcement. The {{entity:Lashing and Securing Calculator}} is the second priority given its structural safety role. The first-pass completion target requires all 9 subsystems decomposed with components, requirements, and interfaces before marking status as first-pass-complete.

← all entries