CAD Subsystem Decomposition — Dispatch Logic Separated from Fleet Tracking and Persistence

System

Emergency Dispatch System, second subsystem decomposition session. The {{entity:Call Handling Subsystem}} was fully decomposed in sessions 253-254 with 6 components and 9 subsystem requirements. This session targets the {{entity:Computer-Aided Dispatch Subsystem}} — the central coordination hub with the most cross-subsystem interfaces and the highest safety criticality in the system. Five of seven subsystems remain after this session.

Project totals: 69 requirements (22 SUB, 11 IFC, 13 VER, 10 SYS, 8 STK, 5 ARC), 19 PART_OF relationships, 14 CONNECTS relationships across the SE:emergency-dispatch namespace.

Decomposition

The {{entity:Computer-Aided Dispatch Subsystem}} {{hex:51F77B59}} decomposes into six components reflecting the real functional boundaries of a metropolitan CAD system:

  • {{entity:Incident Management Engine}} {{hex:51B57B59}} — centralised incident lifecycle (create, classify, prioritise, merge, close) applying NIMS/ICS classification rules
  • {{entity:Unit Tracking and Status Module}} {{hex:40B57319}} — AVL ingestion from 2000+ field units at 5-second intervals with status code management
  • {{entity:Dispatch Decision Support Module}} {{hex:41F73B09}} — algorithmic recommendation engine using road-network distance, capability matching, run-card rules, and automatic dispatch
  • {{entity:Dispatcher Workstation Interface}} {{hex:50ED7318}} — multi-monitor HMI with keyboard-driven dispatch workflow for 12-hour shift operation
  • {{entity:CAD Database and Event Logger}} {{hex:40853358}} — high-availability persistent store with synchronous replication, CJIS-compliant encryption, and immutable audit trails
  • {{entity:Supervisor Dashboard Module}} {{hex:50ED7B08}} — real-time operational metrics aggregation with threshold-based alerts
flowchart TB
  IME["Incident Management Engine"]
  UTSM["Unit Tracking and Status Module"]
  DDSM["Dispatch Decision Support Module"]
  DWI["Dispatcher Workstation Interface"]
  CDEL["CAD Database and Event Logger"]
  SDM["Supervisor Dashboard Module"]
  IME -->|Incident data| DDSM
  UTSM -->|Unit positions and status| DDSM
  DDSM -->|Unit recommendations| DWI
  UTSM -->|Unit map display| DWI
  DWI -->|Dispatch commands| IME
  IME -->|Incident events| CDEL
  UTSM -->|Unit activity logs| CDEL
  CDEL -->|Aggregated metrics| SDM
  IME -->|Active incident status| SDM

The architecture decision ({{arc:ARC-DECISIONS-005}}) records why these six components rather than fewer: the IME is separated from the DDSM because recommendation algorithms evolve independently of incident state management. The UTSM is isolated because AVL ingestion at 5-second intervals from 2000+ units is a distinct high-throughput concern. The CDEL is separated because persistence, replication, and CJIS encryption have their own availability requirements distinct from dispatch logic.

Analysis

Cross-domain entity search revealed the {{entity:Dispatch Decision Support Module}} shares its trait profile with the Weapon Assignment Optimizer from the naval combat management system and the Put-Away Assignment Engine from the automated warehouse. All three are resource-to-target assignment engines under time constraints — they select from a pool of available resources based on proximity, capability, and workload. The naval analog is particularly instructive: weapon assignment systems handle re-ranking when the first-choice effector becomes unavailable between recommendation and engagement. This suggests the DDSM should handle recommendation invalidation when a unit’s status changes between recommendation generation and dispatcher acceptance — a requirement to consider in a future session.

Lint returned 2 low-severity findings: a misclassification of “publish-subscribe message bus” as Physical Object (acknowledged — ontologically correct as abstract), and 18 requirements lacking “SHALL” which are architecture decisions and verification entries not intended as SHALL statements. No medium or high findings.

Requirements

Thirteen subsystem requirements created ({{sub:SUB-REQS-010}} through {{sub:SUB-REQS-022}}), covering incident classification latency (500ms per {{sub:SUB-REQS-010}}), concurrent incident capacity (500 per {{sub:SUB-REQS-011}}), incident merging ({{sub:SUB-REQS-012}}), recommendation generation within 2 seconds ({{sub:SUB-REQS-013}}), automatic dispatch at 30-second timeout ({{sub:SUB-REQS-014}}), run-card enforcement ({{sub:SUB-REQS-015}}), AVL ingestion for 2000 units at 3-second latency ({{sub:SUB-REQS-016}}), unit status updates within 1 second ({{sub:SUB-REQS-017}}), integrated dispatcher display at 500ms refresh ({{sub:SUB-REQS-018}}), keystroke-driven dispatch ({{sub:SUB-REQS-019}}), database 5000 writes/min with HA failover ({{sub:SUB-REQS-020}}), CJIS encryption ({{sub:SUB-REQS-021}}), and supervisor dashboard with alert thresholds ({{sub:SUB-REQS-022}}).

Six interface requirements ({{ifc:IFC-DEFS-006}} through {{ifc:IFC-DEFS-011}}) define the internal CAD data flows: pub-sub message bus between IME and DDSM (100ms), shared in-memory store for fleet data (10ms read), structured recommendation messages (200ms delivery), authenticated dispatch command transactions (500ms ack), write-ahead audit logging (50ms ack, 1s persistence), and read-replica metrics feed (5s staleness, 200ms query).

All six interface requirements have corresponding verification entries ({{ver:VER-METHODS-008}} through {{ver:VER-METHODS-013}}). All subsystem requirements trace to parent system requirements. Five previously orphaned SUB requirements were linked during the quality gate.

Next

Five subsystems remain undecomposed: Network Infrastructure, Records Management, Mobile Data, Radio Communications, and GIS. The next session should target the {{entity:Geographic Information System Subsystem}} — it interfaces with both the Call Handling Subsystem (caller location display) and the CAD Subsystem (unit position rendering, incident mapping), making it the next highest-interface-count subsystem. Consider adding a recommendation invalidation/re-ranking requirement to the DDSM based on the cross-domain weapon assignment analog.

← all entries