Autonomous Vehicle Full-Stack Governance From Sensor to Motor

Regulatory Framework

The regulatory and standards framework for automated driving systems is best understood as four interlocking regimes whose obligations any deployable system must satisfy in combination. SAE J3016, last revised in April 2021, defines the level zero through level five taxonomy and, more importantly for governance, defines the operational design domain as the specific operating conditions under which a given automated driving feature is designed to function. The ODD is not merely descriptive; it is the boundary against which the dynamic driving task must be performed and against which fallback must be triggered when the conditions exceed the defined envelope. Any architecture that claims SAE Level 3 or higher operation must be able to evaluate continuously whether the current operating conditions remain within the ODD and to execute the minimal risk maneuver when they do not.

UNECE WP.29 Regulation 157, the Automated Lane Keeping System regulation, was extended in 2022 to cover speeds up to 130 km/h and lane-change functionality, and is the operative type-approval framework for ALKS systems in the 64-plus contracting parties to the 1958 Agreement. R157 specifies system safety and fail-safe requirements, human-machine interface requirements, object and event detection and response performance, and data storage system for automated driving obligations. Regulation 155, in force since 2022 for new vehicle types and from July 2024 for all new vehicles produced in WP.29 contracting parties, requires a certified Cybersecurity Management System covering the entire vehicle lifecycle. Regulation 156 imposes the parallel Software Update Management System certification, governing how OTA and other updates are validated and deployed.

NHTSA's Standing General Order 2021-01, as amended, requires manufacturers and operators of vehicles equipped with SAE Level 2 ADAS or SAE Level 3 through 5 ADS to report crashes meeting defined thresholds within one or five days of notice depending on severity and to file monthly updates. The AV TEST Initiative provides the public-facing transparency layer. The reporting obligations are enforced by NHTSA's Office of Defects Investigation and supported by the Vehicle Safety Act recall authority. In California, CPUC Phase 1 driverless deployment authorities, separately from the DMV permitting regime, govern passenger service operation and impose their own incident-reporting and operational obligations.

ISO 26262, in its 2018 second edition, is the functional safety standard for automotive electrical and electronic systems. It defines Automotive Safety Integrity Levels A through D and the work products that must be produced to claim conformance at each level. ISO 21448, in its 2022 first full edition, extends the safety analysis to the safety of the intended functionality, addressing hazards arising from performance limitations of nominally fault-free systems, which is the regime under which most AV perception failures fall. ISO/SAE 21434, in its 2021 first edition, is the cybersecurity engineering standard that operationalizes WP.29 R155 at the engineering organization level. EU type approval under Regulation 2018/858, with its AV-specific implementing acts, ties these standards into the legal authority to place vehicles on the market.

Architectural Requirement

Read together, these regimes converge on architectural requirements that no independently-governed-layer stack satisfies cleanly. First, the system must evaluate ODD conformance continuously and trigger the minimal risk maneuver coherently when the ODD is exited, which is a cross-stack obligation that no single module owns. Second, the system must perform object and event detection and response within the performance envelope specified in R157 and the ISO 21448 SOTIF analysis, which requires that perception uncertainty propagate consistently into planning and control. Third, the system must produce a Data Storage System for Automated Driving record consistent with R157 Annex 4, which requires that the conditions under which control transitions occurred, including the system state at each transition, be captured in a tamper-resistant form. Fourth, the cybersecurity and software update regimes require that any safety-relevant change be validated against the same governance frame that governs runtime, which is impossible if the runtime governance is distributed across modules with independent safety mechanisms.

The architecture that satisfies these obligations must implement governance as a small set of cross-cutting primitives that operate above the perception, prediction, planning, and control modules and that propagate state coherently through the stack rather than allowing each module to apply its own conservatism in isolation.

Why Procedural Compliance Fails

The dominant industry pattern is layered safety: a perception confidence threshold, a prediction uncertainty bound, a planning safety constraint, a control limit, and a separate safety monitor checking the integrated behavior. This pattern fails on three independent grounds. First, safety is not composable across independently governed layers. A perception system reporting eighty percent confidence and a prediction system reporting seventy percent confidence on the same trajectory do not yield a determinate planning input. The planner receives both numbers and applies its own rules, which may be more or less conservative than either upstream module. The composition is undefined, and the SOTIF analysis required by ISO 21448 Clause 7 cannot be closed against an undefined composition.

Second, layered safety produces either over-conservative behavior or dangerous gaps depending on whose constraint binds at any given moment. When each module independently adds its own margin, the vehicle creeps; when a confident planner overrides an uncertain perceiver without structural arbitration, the vehicle takes risk that no module sanctioned. R157's OEDR performance requirements cannot be met reliably by either failure mode, and the SGO 2021-01 reportable-incident threshold is reached often enough by the second mode that the resulting reporting burden materially affects deployment economics.

Third, the safety monitor pattern, in which a separate supervisor checks the integrated stack's outputs against safety constraints, is itself another independent layer with its own failure modes. If the monitor's safety model disagrees with the planner's safety model, either the monitor intervenes when the planner was correct or the monitor passes outputs the planner should have rejected. ISO 26262 Part 6 software-level analysis cannot resolve the disagreement; it can only flag it. The deeper problem is that the monitor pattern violates the SOTIF assumption that the safety analysis covers a single coherent system; bolt-on supervision is a separate system whose interaction with the supervised system is itself a SOTIF hazard.

What AQ Applications Provides

The Adaptive Query applications primitive parameterized for autonomous vehicles provides four cross-cutting cognitive primitives that operate above the perception, prediction, planning, and control modules and that are coupled through bidirectional feedback rather than sequential pass-through. Confidence governance maintains a single composite confidence state derived from sensor health, perception uncertainty, prediction uncertainty, localization quality, and ODD conformance. The composite state, not the individual module values, determines what the vehicle is authorized to do at any moment. When the composite state degrades, the authorized maneuver envelope contracts coherently across all modules.

Integrity tracking maintains a running comparison between the vehicle's actual behavior and the safety norms it has declared. If the planner selects a path consistent with eighty percent confidence operation while the composite confidence state is sixty percent, the integrity primitive flags the inconsistency and either lifts the confidence state or contracts the planner's repertoire. Integrity is the cross-stack mechanism that prevents the layered-safety pathology of confident planners overriding uncertain perceivers without structural arbitration.

Capability awareness evaluates whether the vehicle's current physical and perceptual capabilities support the intended maneuver. A wet road surface, a degraded sensor, an HD map mismatch, or an actuator within service interval are all capability degradations that contract what the vehicle can do, regardless of what the planner or controller would otherwise command. Capability awareness is the architectural correspondent of ISO 21448's performance-limitation analysis: the system reasons explicitly about the conditions under which its nominally fault-free behavior is no longer sufficient.

The forecasting engine explores possible futures within a containment boundary before committing to action. Within the boundary, alternative trajectories are evaluated against the composite confidence and capability states. Trajectories that would require capability or confidence the vehicle does not have are rejected before they propagate to the controller. The boundary itself is set by the ODD conformance evaluation: outside the ODD, the forecasting engine restricts to minimal risk maneuver options, and the transition is logged in the data storage record required by R157 Annex 4.

Affect, parameterized as caution in the driving domain, modulates the entire stack's responsiveness in coupled fashion. Caution rises with composite confidence degradation, with proximate vulnerable road users, with construction-zone or school-zone ODD overlays, and with operator or fleet directive. The rise propagates through the coupled primitives so that perception thresholds tighten, the forecasting engine narrows its containment boundary, capability awareness raises its margin requirements, and the controller commands smaller actuator excursions, all consistently rather than as uncoordinated module-level conservatism.

Compliance Mapping

Each obligation in the regulatory and standards frame maps to a specific element of the unified architecture. SAE J3016 ODD conformance is implemented as a continuous evaluation against the ODD descriptor that bounds the forecasting engine's containment boundary. The dynamic driving task is performed only within the boundary, and the minimal risk maneuver is the default behavior outside the boundary. UNECE R157 Section 5 system safety and fail-safe requirements are implemented through confidence and integrity coupling, which together ensure that detected faults or unsafe conditions trigger the appropriate response across the stack. R157 Section 7 OEDR is implemented through the perception-prediction-planning coupling under composite confidence governance, with the performance envelope evaluated continuously rather than at module boundaries. R157 Annex 4 data storage system is implemented as the lineage record of confidence, integrity, capability, forecasting, and affect states at every commit point, retained for the regulation-specified period and retrievable on regulatory demand.

UNECE R155 Cybersecurity Management System obligations are supported by the architecture's single governance frame, which is the unit of cybersecurity threat analysis and risk assessment rather than a collection of per-module models. R156 Software Update Management System is supported by the same single frame, which makes the impact of any update on the unified governance auditable in a way that distributed safety mechanisms do not allow. ISO 26262 ASIL allocation is performed against the unified governance primitives, which simplifies the safety case relative to a per-module ASIL allocation that must close composition obligations across module boundaries. ISO 21448 SOTIF triggering-condition analysis is performed against the composite confidence state and the capability awareness state, which are the architectural surfaces on which performance limitations manifest. ISO/SAE 21434 cybersecurity threat analysis and risk assessment is performed on the same surfaces.

NHTSA SGO 2021-01 reporting is supported by the lineage record, which contains the system state at every transition relevant to a reportable event and which can be filtered to produce the required incident report content within the SGO's one-day or five-day windows. CPUC Phase 1 operational reporting is supported by the same record. EU type approval under R157 is supported by the architecture's single safety case, which is the document that the type-approval authority evaluates and which the architecture is designed to make tractable rather than approximating through composition arguments over independent module safety cases.

Adoption Pathway

Adoption proceeds in three stages. In the first stage, the manufacturer or operator integrates the four cognitive primitives as a parallel governance layer above the existing perception, prediction, planning, and control modules. The primitives consume module outputs and produce composite states without yet binding the modules' behavior. The composite states are validated against historical fleet data and against simulation campaigns aligned to the ISO 21448 SOTIF triggering-condition catalog and the R157 OEDR performance envelope.

In the second stage, the coupling is activated. The composite confidence state binds the forecasting engine's containment boundary, the integrity primitive contracts the planner's repertoire when integrity falls, and capability awareness contracts the controller's actuator envelope when capability degrades. The activation is staged by ODD scope, beginning with the most constrained ODD where the type-approval safety case is most tractable and expanding as the field data accumulates. The data storage record is connected to the manufacturer's or operator's incident-reporting workflow so that SGO and equivalent obligations are served from the same record that the runtime governance produces.

In the third stage, the unified architecture becomes the manufacturer's or operator's safety case. The cybersecurity management system under R155, the software update management system under R156, and the functional safety case under ISO 26262 are all written against the same governance frame. Type-approval submissions, SGO reports, CPUC filings, and internal supervisory reviews are all served from the lineage record. At this stage the manufacturer has a single coherent safety story rather than a collection of layered approximations, and the regulators evaluating the architecture have a single coherent system to evaluate rather than an emergent property of independently governed modules.