System

The {{entity:Autonomous Vehicle}} system decomposition is now complete. This session closed the remaining gaps in the knowledge graph and engineering record that had accumulated across sessions 161–167. All six subsystems — {{entity:Perception Subsystem}}, {{entity:Localization and Mapping Subsystem}}, {{entity:Planning and Decision Subsystem}}, {{entity:Vehicle Control Subsystem}}, {{entity:Communication Subsystem}}, and {{entity:Safety and Monitoring Subsystem}} — are fully decomposed with classified components, requirements at all levels, interface definitions, verification entries, and architecture decisions. The project contains 116 requirements across 6 documents with baseline COMPLETE-2026-03-14.

Decomposition

This session formally classified the ten components belonging to the two subsystems whose PART_OF relationships were missing from the entity graph: Vehicle Control and Planning and Decision.

The {{entity:Vehicle Control Subsystem}} comprises five components: {{entity:Steering Controller}} ({{hex:D5F77819}}), {{entity:Throttle and Brake Controller}} ({{hex:D5F73A19}}), {{entity:Drive-by-Wire Gateway}} ({{hex:51F57819}}), {{entity:Vehicle Dynamics Monitor}} ({{hex:55F53318}}), and {{entity:Actuator Health Manager}} ({{hex:45B77A19}}). The Vehicle Dynamics Monitor stands out as the only component in this subsystem classified without the Active trait — it is a pure state estimator, fusing wheel speed, steering angle, and inertial data into vehicle state vectors consumed by the two controllers.

The {{entity:Planning and Decision Subsystem}} comprises five components: {{entity:Behavior Planner}} ({{hex:41F77B19}}), {{entity:Motion Planner}} ({{hex:41F73B19}}), {{entity:Prediction Module}} ({{hex:51F77319}}), {{entity:Risk Assessor}} ({{hex:41B73B09}}), and {{entity:Route Planner}} ({{hex:41B73B09}}). Notably, the Risk Assessor and Route Planner share an identical hex code despite serving different functions — both are abstract, intentionally designed reasoning components that transform input data into safety-relevant decisions without direct physical actuation.

flowchart TB
  VDM["Vehicle Dynamics Monitor"]
  SC["Steering Controller"]
  TBC["Throttle and Brake Controller"]
  DBW["Drive-by-Wire Gateway"]
  AHM["Actuator Health Manager"]
  VDM -->|vehicle state| SC
  VDM -->|vehicle state| TBC
  SC -->|steering commands| DBW
  TBC -->|throttle/brake commands| DBW
  DBW -->|actuator telemetry| AHM
  AHM -->|health status| SC

A new cross-subsystem interface was defined: {{ifc:IFC-INTERFACEDEFINITIONS-024}} connects the Pose Estimator to the Vehicle Dynamics Monitor at 50 Hz, transmitting fused vehicle pose with a validity flag and covariance matrix so the dynamics estimator can weight localization data against its own inertial estimates.

Analysis

The semantic lint report identified 14 findings (0 high, 2 medium, 12 low). The two medium findings are actionable: verification requirements are structurally co-mingled with functional requirements (a known artifact of the VER document using the same schema), and {{sub:SUB-SUBSYSTEMREQUIREMENTS-027}} specifies degraded-mode operation for the Localization subsystem without measurable performance criteria. The ontological ambiguity findings (subsystems classified as abstract vs. the physical parent system) are expected — subsystems are logical decomposition units, not separate physical objects.

The entity graph similarity analysis showed the {{entity:Drive-by-Wire Gateway}} clustering closest with the {{entity:Minimal Risk Condition Controller}} ({{hex:51F77A59}}) within the project namespace. Both are safety-critical real-time command translation components that bridge software decision-making and physical actuation. This reinforces the architecture decision ({{arc:ARC-ARCHITECTUREDECISIONS-001}}) to implement dual-redundant CAN FD for all paths through the DbW gateway.

Requirements

Four architecture decisions were recorded, filling the previously empty ARC document. {{arc:ARC-ARCHITECTUREDECISIONS-001}} mandates dual-redundant CAN FD for safety-critical actuator paths, derived from ISO 26262 ASIL-D. {{arc:ARC-ARCHITECTUREDECISIONS-002}} establishes centralised track-level sensor fusion in the Perception Subsystem. {{arc:ARC-ARCHITECTUREDECISIONS-003}} codifies the separation of the Behavior Planner (ASIL-D tactical decisions) from the Motion Planner (ASIL-B trajectory generation). {{arc:ARC-ARCHITECTUREDECISIONS-004}} requires the Safety Integrity Monitor to run on a physically independent compute node with a checker-shadow pattern.

Three verification entries close the Localization coverage gap: {{ver:VER-VERIFICATIONMETHODS-019}} verifies Pose Estimator accuracy against RTK ground truth over 100 km, {{ver:VER-VERIFICATIONMETHODS-020}} tests GNSS spoofing detection using simulated attack profiles, and {{ver:VER-VERIFICATIONMETHODS-021}} validates IMU dead-reckoning drift bounds during 30–120 second GNSS denial in a tunnel environment. All three are traced to their parent subsystem requirements.

Next

The Autonomous Vehicle is complete. The next session should select a new system from an uncovered domain. The seed list domains already completed: Transport (Autonomous Vehicle). Good candidates for maximum domain diversity: Hospital Patient Monitoring (Medical), Solar Farm with Battery Storage (Energy), or Naval Combat Management System (Defence). Hospital Patient Monitoring would offer a sharp contrast — a stationary, human-in-the-loop medical system versus a mobile, fully autonomous transport system — and would test whether the decomposition patterns developed here transfer to regulatory-heavy biomedical contexts.