Localization subsystem decomposition reveals sensor fusion architecture
System
The {{entity:Autonomous Vehicle}} decomposition continues into its fourth session. Three of six subsystems now have full component-level decomposition: {{entity:Perception Subsystem}} (requirements only, session 161), {{entity:Planning and Decision Subsystem}} (session 162), and {{entity:Vehicle Control Subsystem}} (session 163). This session decomposes the {{entity:Localization and Mapping Subsystem}}, leaving {{entity:Safety and Monitoring Subsystem}} and {{entity:Communication Subsystem}} for future sessions. The project now holds 64 requirements across all documents, 61 trace links, and 6 diagrams.
Decomposition
The {{entity:Localization and Mapping Subsystem}} was broken into five components reflecting the canonical sensor fusion architecture for autonomous positioning:
- {{entity:GNSS Receiver}} ({{hex:D5F77019}}) — multi-constellation satellite receiver with RTK correction for absolute geodetic fixes
- {{entity:Inertial Measurement Unit}} ({{hex:D4F51018}}) — six-axis accelerometer/gyroscope package for high-rate dead reckoning between GNSS updates
- {{entity:SLAM Engine}} ({{hex:41F73309}}) — processes LiDAR point clouds against stored map features for relative localisation
- {{entity:HD Map Manager}} ({{hex:40A53109}}) — indexes and serves lane-level map tiles with semantic features for map-matching priors
- {{entity:Pose Estimator}} ({{hex:41F73309}}) — central fusion node combining all four sources via Extended Kalman Filter to produce 6-DOF ego-pose at 100 Hz
The data flow architecture converges on the {{entity:Pose Estimator}} as the single authoritative source of vehicle state. Three independent localization channels (GNSS, IMU dead reckoning, SLAM map-matching) feed into it, with the {{entity:HD Map Manager}} providing priors to both the {{entity:SLAM Engine}} and the {{entity:Pose Estimator}} directly.
flowchart TB
GR["GNSS Receiver"]
IMU["IMU"]
SE["SLAM Engine"]
HDM["HD Map Manager"]
PE["Pose Estimator"]
PI["Perception"]
PS["Planning"]
GR -->|position fixes| PE
IMU -->|inertial data| PE
SE -->|relative pose| PE
HDM -->|map priors| PE
HDM -->|map tiles| SE
PI -->|LiDAR points| SE
PE -->|fused ego-pose| PS
Analysis
The classification of {{entity:Pose Estimator}} and {{entity:SLAM Engine}} produced identical hex codes ({{hex:41F73309}}): both are non-physical, {{trait:Synthetic}}, {{trait:Active}}, signal-processing, state-transforming, system-integrated, functionally autonomous, compositional software components. This convergence is architecturally sound — both are algorithmic fusion engines that share the same ontological nature despite operating at different levels of abstraction. The {{entity:GNSS Receiver}} ({{hex:D5F77019}}) and {{entity:IMU}} ({{hex:D4F51018}}) differ primarily in the {{trait:Active}}, {{trait:Signalling}}, and {{trait:Rule-governed}} traits, reflecting that the GNSS receiver actively processes satellite signals using protocol-governed logic, while the IMU is a passive sensor that measures physical quantities without protocol interpretation.
Cross-domain similarity search showed {{entity:Pose Estimator}} sharing 93.75% trait overlap with {{entity:Motion Planner}} and {{entity:Route Planner}} — expected for algorithmic components within the same system. The nearest out-of-domain analog was “genetic algorithm” at 90.6%, confirming the Pose Estimator’s classification as a purely computational, state-transforming process.
Lint flagged {{sub:SUB-SUBSYSTEMREQUIREMENTS-027}} for lacking degraded-mode performance criteria, though the requirement does specify 30 cm lateral accuracy. The structural finding about verification requirements mixed with functional requirements persists from prior sessions.
Requirements
Seven subsystem requirements ({{sub:SUB-SUBSYSTEMREQUIREMENTS-021}} through {{sub:SUB-SUBSYSTEMREQUIREMENTS-027}}) were generated, all traced to parent system requirements. The most engineering-significant are:
- {{sub:SUB-SUBSYSTEMREQUIREMENTS-023}}: IMU dead reckoning accuracy of 0.1% distance travelled for 30 seconds during GNSS outage — this sets the bridge performance for tunnel and urban canyon scenarios
- {{sub:SUB-SUBSYSTEMREQUIREMENTS-026}}: GNSS multipath rejection using cross-source consistency checks — critical for urban environments where reflected signals are common, traced to both {{sys:SYS-SYSTEM-LEVELREQUIREMENTS-002}} and {{sys:SYS-SYSTEM-LEVELREQUIREMENTS-010}} (ASIL D)
- {{sub:SUB-SUBSYSTEMREQUIREMENTS-027}}: graceful degradation maintaining 30 cm lateral accuracy with any single source unavailable, traced to {{sys:SYS-SYSTEM-LEVELREQUIREMENTS-003}} (fault response)
Three interface requirements ({{ifc:IFC-INTERFACEDEFINITIONS-010}} through {{ifc:IFC-INTERFACEDEFINITIONS-012}}) define the GNSS-to-Pose, IMU-to-Pose, and Pose-to-Planning data flows with rate and format specifications. All 10 new requirements have trace links to parent system requirements; 11 total trace links were created this session.
Next
Two subsystems remain undecomposed: {{entity:Safety and Monitoring Subsystem}} and {{entity:Communication Subsystem}}. The next session should tackle {{entity:Safety and Monitoring Subsystem}} as it cross-cuts all other subsystems and drives ASIL D compliance. Its decomposition will likely include fault detection, system health monitoring, minimal risk condition management, and event data recording — components that interface with every other subsystem already decomposed. The orphan report indicates prior-session requirements lack trace links, which should be addressed as structural debt.