STATERA Library · Series 07 · Volume 17 · Chapter 03 · EN
Source: https://github.com/Statera-Library/07_Vol_17_Outdoor_Autonomous_Vehicle/blob/main/Chapter_03_Safety_Architecture/Chapter_03_Safety_Architecture_EN.md

Volume 17 Outdoor Autonomous Vehicle

Chapter 03. Safety Architecture

03.01. SOTIF (ISO 21448)

Safety of the Intended Functionality (SOTIF), standardized in ISO 21448, addresses hazards that arise even when an autonomous vehicle system is free from conventional hardware or software faults. Unlike functional safety, which primarily manages failures and malfunctions, SOTIF considers whether the intended functionality itself can produce unsafe behavior because of performance limitations, incomplete environmental understanding, ambiguous situations, or foreseeable misuse. This distinction is fundamental for outdoor autonomous vehicles operating in complex and continuously changing environments.

An autonomous vehicle may contain perfectly functioning cameras, LiDARs, radars, GNSS receivers, computers, and drive-by-wire controllers while still making an unsafe decision. A perception algorithm may fail to recognize an unusual object, localization accuracy may degrade near buildings, or a planner may incorrectly interpret an unfamiliar traffic configuration. SOTIF therefore extends safety engineering beyond component reliability toward the limitations of perception, reasoning, prediction, and decision-making functions.

The central SOTIF concept separates operating situations according to whether they are known or unknown and whether they are safe or potentially hazardous. Known safe scenarios represent conditions for which system capability has been sufficiently demonstrated. Known hazardous scenarios contain recognized functional limitations or triggering conditions. Unknown hazardous scenarios are especially important because developers have not yet identified the combination of environmental conditions and system limitations capable of producing unsafe behavior.

Triggering conditions are environmental, operational, or behavioral circumstances that expose limitations in the intended functionality. Examples for an outdoor autonomous vehicle include low sun angles affecting cameras, rain reducing LiDAR quality, GNSS multipath near buildings, partially occluded pedestrians, unusual road markings, reflective surfaces, construction zones, or unexpected interactions with bicycles and other vehicles. Identifying these conditions requires systematic analysis rather than relying only on normal-road testing.

SOTIF analysis begins with a clear definition of the intended functionality and its operating assumptions. Engineers must specify what the autonomous vehicle is expected to perceive, predict, plan, and control, together with the operational design domain in which those capabilities are valid. Road geometry, weather, illumination, speed, infrastructure, communication availability, object types, localization quality, and interaction patterns become explicit engineering parameters rather than implicit assumptions.

The Operational Design Domain (ODD) therefore becomes closely connected to SOTIF engineering. A system designed for controlled industrial roads has fundamentally different exposure from one operating on public urban streets. Safety cannot be evaluated independently of these boundaries. The ODD defines where the intended functionality is expected to remain sufficiently capable, while SOTIF analysis investigates circumstances inside or near those boundaries where performance limitations could create unreasonable risk.

Perception is one of the most significant SOTIF domains because sensors have physical limitations even when functioning correctly. Cameras depend on illumination, contrast, visibility, and optical condition; LiDAR performance can be affected by weather, surface reflectivity, range, and geometry; radar has its own resolution and classification limitations. Sensor fusion reduces individual weaknesses but does not automatically eliminate uncertainty, particularly when multiple sensors encounter correlated environmental degradation.

Localization introduces another class of intended-function limitations. GNSS RTK can provide centimeter-level positioning under favorable conditions, yet satellite obstruction, multipath, correction-service interruption, antenna geometry, or environmental interference can reduce confidence without representing a hardware fault. Safe autonomy therefore requires monitoring not only the estimated position but also integrity, uncertainty, correction status, sensor consistency, and the relationship between localization confidence and permissible vehicle behavior.

Planning and decision systems must similarly be examined for SOTIF limitations. A trajectory planner may operate exactly according to its algorithm while producing behavior that is technically valid but inappropriate for an unusual scene. Prediction models can misunderstand human intent, optimization objectives can inadequately represent safety margins, and learned policies can encounter situations outside their training distribution. Safety engineering must consequently evaluate behavioral competence rather than merely confirming correct software execution.

Machine learning increases the importance of scenario-based SOTIF engineering because model behavior is strongly influenced by training-data coverage. Dataset size alone does not demonstrate safety. Engineers must examine whether relevant combinations of weather, lighting, road users, infrastructure, object appearance, occlusion, speed, and interaction are represented. Rare but safety-critical cases require deliberate collection, simulation, synthetic generation, perturbation, and targeted testing to expose weaknesses hidden by aggregate accuracy metrics.

Scenario engineering provides a practical mechanism for converting SOTIF concerns into measurable validation activities. Functional scenarios describe situations semantically, logical scenarios define parameter ranges, and concrete scenarios instantiate specific test conditions. Parameters such as pedestrian speed, vehicle velocity, visibility, sensor range, obstacle position, braking distance, and localization uncertainty can be systematically varied to discover boundaries where intended functionality transitions from acceptable behavior to potentially unsafe behavior.

Simulation is particularly valuable for exploring hazardous and rare scenarios that would be expensive, dangerous, or statistically inefficient to reproduce through physical testing alone. Large-scale virtual testing can vary environmental and behavioral parameters, inject sensor degradation, create unusual object combinations, and repeatedly examine near-boundary conditions. Simulation does not replace proving-ground or field validation, but it dramatically expands scenario coverage and supports systematic discovery of previously unknown hazardous situations.

Once a functional insufficiency is discovered, mitigation can occur through improved system capability or through restriction of operation. Developers may improve sensing, fusion, localization, prediction, planning, training data, or algorithms. Alternatively, the vehicle can reduce speed, increase safety distance, request remote assistance, exclude particular environmental conditions, or transition toward a Minimal Risk Condition. SOTIF therefore connects perception uncertainty directly with operational behavior rather than treating uncertainty as an isolated diagnostic quantity.

Runtime monitoring is essential because not every relevant limitation can be eliminated before deployment. Confidence measures, sensor-quality indicators, localization integrity, model uncertainty, environmental classification, communication status, and cross-sensor consistency can provide evidence that the system is approaching its validated operating boundary. A supervisory safety architecture can then constrain autonomous functions, reduce vehicle speed, modify the mission, initiate controlled stopping, or transfer responsibility to an appropriate fallback mechanism.

Verification and validation under ISO 21448 should accumulate evidence that residual risk associated with functional insufficiencies has been reduced to an acceptable level. Evidence may combine requirements analysis, scenario coverage, simulation, software-in-the-loop testing, hardware-in-the-loop testing, proving-ground experiments, field operation, fault-independent performance evaluation, and statistical analysis. The objective is not to claim that every possible situation has been tested, but to establish a defensible argument that relevant hazardous scenarios have been systematically explored.

SOTIF must also coexist with functional safety rather than replace it. ISO 26262 addresses hazards associated primarily with malfunctioning behavior, whereas ISO 21448 addresses hazards caused by insufficient intended functionality when components are operating as designed. Outdoor autonomous vehicle safety architecture therefore requires both perspectives: one asks whether the system fails correctly when something breaks, while the other asks whether a correctly operating system can nevertheless misunderstand the world and behave dangerously.

For outdoor autonomous vehicles, SOTIF ultimately becomes a continuous engineering process rather than a one-time certification activity. Field data can reveal previously unknown scenarios, near misses can expose insufficient assumptions, and software updates can change perception or planning behavior. New evidence should therefore feed back into scenario databases, hazard analysis, simulation campaigns, model training, validation criteria, ODD definitions, and runtime safety mechanisms throughout the operational lifecycle.

A mature SOTIF architecture links sensing, perception, localization, prediction, planning, control, supervision, validation, and operational feedback into one safety argument. The essential principle is that autonomy must understand not only what it believes about the environment, but also when that belief may be unreliable. By explicitly managing functional limitations, triggering conditions, uncertainty, scenario coverage, and residual risk, ISO 21448 provides a critical foundation for deploying outdoor autonomous vehicles with defensible safety assurance.

03.02. Autonomous Safety Framework

An Autonomous Safety Framework provides the system-level structure used to ensure that an outdoor autonomous vehicle can perform its mission while maintaining acceptable risk throughout perception, localization, planning, control, and actuation. Within the Safety Architecture chapter, it extends SOTIF principles into an integrated operational framework connecting technical safety mechanisms, autonomous behavior, supervision, fallback strategies, validation, and lifecycle monitoring.

The framework begins by defining the vehicle mission, Operational Design Domain (ODD), operating constraints, safety objectives, and acceptable behavioral boundaries. Outdoor autonomous vehicles may operate on public roads, industrial sites, campuses, ports, agricultural areas, or restricted infrastructure. Each environment introduces different combinations of road users, terrain, weather, visibility, communication conditions, vehicle speeds, and infrastructure interactions that must be explicitly represented in safety requirements.

Safety must be considered as an end-to-end property rather than as an isolated function implemented by a single controller. Cameras, LiDAR, radar, GNSS RTK, IMU, vehicle networks, AI computers, drive-by-wire systems, power systems, and communication links contribute different information and capabilities. The safety framework therefore evaluates whether the complete chain from environmental sensing to physical vehicle motion remains sufficiently trustworthy under both normal and degraded conditions.

A layered architecture is useful for separating safety responsibilities. The sensing layer observes the physical environment and vehicle state, the perception and localization layer constructs an operational representation of the world, and the planning layer determines intended motion. The control and actuation layer converts trajectories into steering, braking, and propulsion commands, while an independent supervisory layer monitors whether these processes remain within defined safety constraints.

Sensor safety begins with continuous evaluation of availability, plausibility, quality, and consistency. A sensor may remain electrically operational while providing degraded information because of contamination, weather, occlusion, glare, vibration, multipath, or environmental interference. The safety framework should therefore distinguish simple device health from information quality and determine whether remaining sensor capability is sufficient for the current operating condition and vehicle behavior.

Localization safety requires similar integrity monitoring. GNSS RTK, IMU, wheel odometry, LiDAR localization, and visual localization can provide complementary estimates, but their uncertainty varies with the environment. The autonomous safety framework should monitor position confidence, correction status, sensor disagreement, map consistency, and temporal stability. When localization integrity decreases, allowable speed, trajectory complexity, or autonomous operating authority should be reduced accordingly.

Perception safety concerns not only object detection accuracy but the reliability of the complete environmental model. The vehicle must identify relevant obstacles, pedestrians, bicycles, vehicles, free space, road boundaries, and other mission-specific objects while maintaining uncertainty estimates. Cross-sensor consistency checking, temporal tracking, confidence monitoring, and detection of out-of-distribution conditions help identify situations where the perception system should no longer be treated as fully reliable.

Planning safety converts environmental understanding into behavior constrained by explicit safety rules. A planner should consider collision margins, stopping distance, dynamic obstacles, vehicle stability, road boundaries, uncertainty, and predicted interactions with other agents. Even when an optimized trajectory is mathematically feasible, supervisory constraints should prevent execution when the trajectory violates predefined safety envelopes or depends on environmental assumptions that cannot be sufficiently verified.

The vehicle control layer must reliably translate safe trajectories into physical motion. Steering-by-wire, brake-by-wire, and throttle-by-wire functions should provide command monitoring, feedback verification, diagnostic information, and appropriate redundancy according to the vehicle risk level. Differences between requested and measured steering angle, braking response, acceleration, wheel speed, or vehicle motion can indicate that the commanded trajectory is no longer being executed as expected.

An independent safety supervisor provides a critical separation between mission autonomy and safety authority. The main autonomous computer may optimize perception, navigation, and mission performance, while the safety supervisor evaluates simplified but highly dependable constraints. It can monitor speed, obstacle distance, localization integrity, trajectory validity, sensor availability, communication state, and actuator response, and can override normal autonomy when defined safety limits are exceeded.

Safety envelopes establish measurable boundaries within which autonomous behavior is permitted. These boundaries may include maximum speed, minimum obstacle clearance, lateral deviation, braking distance, localization uncertainty, steering limits, acceleration limits, or sensor availability requirements. Dynamic safety envelopes can become more conservative when visibility decreases, terrain becomes uncertain, localization quality degrades, or vulnerable road users enter the vehicle\'s operating area.

Degraded operation is preferable to an immediate emergency stop in many situations because stopping itself may create risk. The framework can define progressive responses such as reducing speed, increasing following distance, restricting maneuver complexity, disabling selected autonomous functions, requesting remote assistance, or moving toward a designated safe location. The response should correspond to the severity, persistence, and operational consequences of the detected degradation.

When continued autonomous operation cannot be justified, the system must transition toward a Minimal Risk Condition (MRC). Depending on vehicle type and environment, this may involve controlled deceleration, stopping within a safe corridor, activating warning indicators, securing propulsion, maintaining essential communications, or notifying a control center. The transition must account for surrounding traffic and obstacles so that the fallback action does not introduce a greater hazard than the original problem.

Communication with a fleet or central control system can extend safety supervision beyond the individual vehicle. Operational status, safety events, localization confidence, sensor degradation, mission state, and emergency conditions can be transmitted to remote infrastructure. However, remote communication should normally supplement rather than replace essential onboard safety functions because network latency, congestion, coverage loss, or infrastructure failure may occur during critical situations.

Cybersecurity and safety must also be coordinated because compromised commands, corrupted data, unauthorized access, or manipulated updates can affect physical vehicle behavior. Safety-critical communication paths require authentication, integrity protection, controlled access, secure software deployment, and monitoring of abnormal network behavior. At the same time, cybersecurity mechanisms should be designed so that authentication or communication failures lead to predictable and appropriately constrained vehicle behavior.

Power architecture forms another foundation of autonomous safety. Loss of primary electrical power can simultaneously affect perception, computation, communication, steering, braking, and safety controllers. Critical functions therefore require carefully designed power distribution, protection, monitoring, and where necessary independent or redundant energy paths. The safety framework should define which functions must remain available long enough to execute a controlled transition to a safe state.

Functional safety and SOTIF provide complementary foundations for the framework. Functional safety addresses hazards resulting from faults and malfunctioning behavior, while SOTIF addresses hazards arising from limitations of correctly operating intended functionality. Autonomous vehicle safety requires both because a dangerous event may originate from a failed component, insufficient perception capability, an unexpected environmental condition, an inappropriate decision, or interactions among several individually acceptable subsystems.

Verification must demonstrate safety across component, subsystem, vehicle, and operational levels. Software-in-the-loop, hardware-in-the-loop, simulation, proving-ground testing, fault injection, scenario testing, environmental testing, and field trials can progressively evaluate safety mechanisms. Validation should include nominal operation, degraded states, boundary conditions, rare events, communication loss, localization degradation, sensor limitations, actuator anomalies, and transitions into fallback or minimal-risk behavior.

Safety evidence should be organized into a traceable safety argument connecting hazards, safety goals, requirements, architecture, implementation, verification results, assumptions, and residual risks. Traceability is particularly important for autonomous vehicles because AI models, maps, sensor configurations, software versions, and operating environments can change during development and deployment. A modification in one subsystem may invalidate assumptions previously used elsewhere in the safety case.

The Autonomous Safety Framework therefore continues throughout the vehicle lifecycle. Operational logs, near misses, interventions, sensor degradation events, localization anomalies, emergency stops, remote assistance requests, and newly discovered scenarios provide evidence for continuous improvement. These observations should feed back into hazard analysis, ODD definitions, software updates, simulation libraries, safety requirements, validation campaigns, and fleet operating policies.

A mature framework ultimately establishes a closed safety loop from sensing and autonomous reasoning to physical action, supervision, fallback, validation, and operational learning. The objective is not merely to prevent individual component failures, but to ensure that the complete autonomous vehicle recognizes when its capabilities are insufficient and responds predictably. This capability to detect uncertainty, constrain behavior, degrade gracefully, and reach a safe condition is fundamental to dependable outdoor autonomous operation.

03.03. Sensor Monitoring Safety

Sensor Monitoring Safety is a fundamental part of the safety architecture for outdoor autonomous vehicles because safe operation depends not only on whether sensors are powered and communicating, but also on whether their information remains trustworthy. Cameras, LiDAR, radar, GNSS, IMU, ultrasonic sensors, and wheel-motion sensors may continue operating while their effective performance deteriorates. Monitoring must therefore evaluate both device health and information quality throughout operation.

A sensor monitoring system should distinguish complete failure, partial degradation, intermittent behavior, and environmentally induced performance limitations. Complete failures are relatively straightforward to detect through missing messages, diagnostic flags, or communication timeouts. More difficult conditions include contaminated camera lenses, partially blocked LiDAR fields of view, radar interference, GNSS multipath, IMU drift, or vibration-induced measurement instability, where data continues to arrive but may no longer support safe autonomous operation.

Device-level monitoring provides the first layer of protection. Voltage, current, temperature, internal diagnostic status, communication counters, initialization state, synchronization status, and sensor-specific fault codes can indicate whether hardware is functioning within expected limits. Heartbeat supervision and message timeout monitoring identify disconnected or unresponsive devices, while communication error statistics help detect deteriorating interfaces, connectors, cables, network links, or electronic modules before complete loss occurs.

Information-level monitoring extends beyond conventional diagnostics by examining whether sensor output is physically plausible and operationally useful. A camera can report valid image frames even when glare makes objects difficult to recognize, and a LiDAR can transmit valid point clouds while rain or contamination reduces effective detection range. Safety monitoring should therefore evaluate characteristics such as image quality, point density, signal strength, noise level, measurement stability, field-of-view availability, and confidence.

Plausibility checking compares sensor measurements against physical constraints and expected vehicle behavior. Wheel speed should be consistent with estimated vehicle velocity, IMU acceleration should approximately correspond to changes in motion, and GNSS position should not jump unrealistically between consecutive measurements. Similar checks can detect frozen values, excessive rates of change, impossible ranges, discontinuities, or data patterns inconsistent with vehicle dynamics even when the sensor itself reports no internal fault.

Cross-sensor monitoring provides stronger safety evidence by comparing independent or diverse observations of the same environment or vehicle state. GNSS velocity can be compared with wheel odometry and inertial estimates, while obstacles detected by LiDAR may be compared with radar or camera observations. Agreement increases confidence, whereas persistent disagreement indicates that at least one information source may be unreliable and requires isolation, reduced weighting, or additional diagnostic evaluation.

Sensor fusion should explicitly represent uncertainty rather than assuming that combining multiple measurements automatically produces reliable information. Each sensor contributes measurements with uncertainty determined by its technology, environment, calibration, and current operating condition. When uncertainty increases, the fusion system should reduce confidence accordingly. A safety architecture can use covariance, confidence scores, integrity indicators, or quality states to communicate this uncertainty to localization, perception, planning, and supervisory functions.

Environmental monitoring is particularly important for outdoor vehicles because sensor capability varies strongly with operating conditions. Heavy rain, fog, snow, dust, darkness, direct sunlight, reflective surfaces, vegetation, mud, water spray, electromagnetic interference, and GNSS obstruction can affect different sensor modalities in different ways. Detecting these conditions allows the vehicle to adjust its assumptions about sensor capability before degraded measurements develop into unsafe perception or localization behavior.

Sensor cleanliness and physical visibility should also be treated as safety-relevant states. Dirt, water droplets, ice, condensation, insects, or mechanical obstruction can reduce sensor performance without creating an electrical diagnostic fault. Camera image statistics, LiDAR return distributions, dedicated contamination detection, heater status, washer systems, or comparison with redundant sensors can help identify blocked or degraded sensing surfaces and initiate cleaning, maintenance, or operational restrictions.

Calibration integrity is another essential monitoring dimension. Camera intrinsic parameters, camera-to-vehicle alignment, LiDAR extrinsics, radar alignment, IMU orientation, and relationships among multiple sensors can change because of vibration, impact, mechanical servicing, thermal expansion, or mounting movement. Online consistency checks can identify unexpected alignment errors, while periodic calibration verification ensures that individually healthy sensors continue to represent the environment within a common and geometrically valid reference frame.

Time synchronization must be monitored because autonomous perception depends on measurements representing approximately the same physical moment. GNSS time, PTP, hardware triggers, sensor timestamps, network delays, and computer clocks can all contribute to temporal alignment. Timestamp discontinuities or excessive latency can create apparent object displacement and incorrect fusion results. Monitoring synchronization offset and data age is therefore as important as checking the numerical validity of the measurements themselves.

The monitoring architecture should convert numerous low-level diagnostics into standardized sensor health states that higher-level autonomous functions can understand. Instead of exposing only raw error codes, sensors can be classified as Normal, Degraded, Unavailable, or Invalid, together with confidence and reason information. Such abstraction allows perception, localization, planning, and safety supervisors to respond consistently even when individual sensors use different communication protocols and diagnostic mechanisms.

A degraded sensor does not always require immediate vehicle shutdown. If sufficient independent sensing capability remains available, the vehicle may continue operating under a reduced safety envelope. Maximum speed can be lowered, obstacle clearance increased, complex maneuvers restricted, or the Operational Design Domain narrowed. The permitted response should depend on which sensor is degraded, the environmental condition, available redundancy, vehicle dynamics, mission requirements, and the consequences of losing additional sensing capability.

Redundancy must be evaluated in terms of functional independence rather than sensor quantity alone. Two identical cameras exposed to the same glare or two GNSS receivers affected by the same satellite obstruction may experience common-cause degradation. Diverse sensing technologies such as camera, LiDAR, radar, GNSS, and inertial sensing can provide complementary failure characteristics. Monitoring should therefore consider correlated degradation and determine whether the remaining sensing architecture truly provides independent safety information.

When sensor capability falls below the minimum required for continued autonomy, the safety supervisor should initiate a controlled fallback. Depending on severity, the vehicle may reduce speed, stop accepting new missions, request remote assistance, move toward a safe location, or transition to a Minimal Risk Condition. The decision should consider stopping distance, surrounding objects, localization confidence, remaining perception capability, and whether continued movement would create greater risk than controlled stopping.

Sensor monitoring must remain closely connected to the planning and control layers. A perception confidence reduction should influence allowable trajectory speed and clearance, while localization uncertainty should affect path tracking tolerance and maneuver complexity. This creates a closed safety relationship in which sensing quality directly modifies vehicle behavior. Monitoring becomes meaningful only when detected degradation produces an appropriate operational response rather than merely generating a diagnostic log.

Remote fleet monitoring can supplement onboard safety by collecting sensor health, degradation events, environmental conditions, and intervention history across many vehicles. Fleet-level analysis can reveal recurring contamination locations, GNSS-denied areas, sensor aging patterns, weather-related performance changes, or hardware populations with abnormal failure rates. These observations can support preventive maintenance, map updates, operational restrictions, and improvements to future sensor configurations.

Verification of sensor monitoring requires deliberate introduction of realistic degradation rather than testing only complete disconnection. Validation scenarios should include obscured cameras, reduced LiDAR returns, GNSS multipath or correction loss, IMU bias, radar interference, timestamp errors, calibration shifts, communication latency, temperature excursions, and intermittent data loss. Simulation, hardware-in-the-loop testing, controlled environmental tests, and vehicle trials can demonstrate whether degradation is detected early enough for safe system response.

Monitoring thresholds require careful engineering because excessive sensitivity can produce unnecessary interventions while insufficient sensitivity can permit unsafe operation. Thresholds should consider sensor specifications, environmental variability, vehicle speed, stopping capability, mission context, and uncertainty propagation into downstream functions. Adaptive thresholds may be appropriate where operating conditions change significantly, provided their behavior remains bounded, understandable, testable, and consistent with the overall safety argument.

Diagnostic information should be recorded with sufficient context to support post-event analysis and safety improvement. Relevant records include timestamps, sensor health states, confidence values, environmental conditions, vehicle motion, localization status, perception outputs, supervisor decisions, and fallback actions. Correlating these records helps engineers reconstruct why a safety response occurred and determine whether monitoring thresholds, algorithms, hardware, or operational policies require modification.

Sensor Monitoring Safety ultimately establishes continuous awareness of whether the autonomous vehicle can still trust its perception of itself and the surrounding world. Its purpose is not merely to identify broken sensors, but to detect loss of sensing capability before uncertainty becomes unsafe vehicle behavior. By combining device diagnostics, information-quality assessment, plausibility checking, cross-sensor consistency, uncertainty monitoring, redundancy, degradation management, and fallback control, it forms a critical bridge between sensing and system-level autonomous safety.

03.04. Minimal Risk Condition

A Minimal Risk Condition (MRC) is the controlled operating state reached when an autonomous vehicle can no longer continue its intended driving or mission function with an acceptable level of safety. Within an outdoor autonomous vehicle safety architecture, the MRC represents the final objective of a fallback process rather than simply an emergency stop. Its purpose is to reduce exposure to hazards while preserving sufficient vehicle control, awareness, and communication to manage the abnormal situation safely.

The need for an MRC can arise from many conditions that do not necessarily involve complete system failure. Severe sensor degradation, insufficient perception confidence, localization uncertainty, loss of GNSS corrections, actuator anomalies, compute faults, communication problems, unexpected environmental conditions, or operation outside the validated Operational Design Domain may make continued autonomy unjustifiable. The safety architecture must detect these conditions before they develop into uncontrolled vehicle behavior.

A distinction should be made between a fallback action, a Minimal Risk Maneuver (MRM), and the resulting Minimal Risk Condition. The fallback strategy determines how responsibility for maintaining safety is handled after a critical limitation is detected. The MRM is the sequence of controlled actions used to reduce risk, such as deceleration and movement toward a safe stopping area. The MRC is the stable condition achieved after that maneuver has been successfully completed.

The appropriate MRC depends strongly on the vehicle, environment, mission, and surrounding traffic. For a low-speed outdoor AMR, stopping within a protected area may be sufficient. For a vehicle operating near road traffic, intersections, pedestrians, industrial machinery, or port equipment, an immediate stop may create additional hazards. The system should therefore select a risk-reducing response appropriate to its current operational context rather than applying the same stopping strategy to every event.

MRC initiation begins with continuous safety supervision. Sensor health, localization integrity, perception confidence, trajectory validity, actuator response, electrical power, compute status, communication state, and environmental conditions can be monitored against predefined safety limits. When one or more critical indicators cross these limits, the safety supervisor evaluates whether normal operation can continue, whether degraded operation remains acceptable, or whether an MRC transition must begin.

A progressive degradation strategy can prevent unnecessary transitions directly from normal operation to emergency stopping. The vehicle may initially reduce speed, increase obstacle clearance, limit steering or acceleration, simplify its planned maneuvers, restrict its Operational Design Domain, or suspend nonessential mission functions. If sufficient capability remains, this degraded mode can provide additional time for recovery while maintaining a more conservative dynamic safety envelope.

The decision to initiate an MRC should consider both the severity and persistence of the detected condition. A brief GNSS correction interruption may be tolerable when LiDAR, IMU, and odometry provide sufficient localization continuity, whereas sustained localization disagreement may require a fallback. Similarly, temporary camera degradation may be manageable when independent LiDAR and radar coverage remains adequate, but correlated loss of multiple perception channels may require immediate risk reduction.

Safe stopping requires more than commanding zero velocity. The vehicle must evaluate its current speed, braking capability, road surface, slope, steering state, surrounding objects, available free space, and expected movement of nearby road users. A controlled deceleration profile should maintain vehicle stability and provide sufficient opportunity for surrounding users to recognize the vehicle\'s behavior. Abrupt braking should normally be reserved for situations where collision avoidance requires immediate intervention.

Where the environment permits, moving to a safer location may provide a better MRC than stopping in the current lane or path. The vehicle may identify a shoulder, designated stopping zone, parking position, low-traffic area, or other reachable refuge. Such a maneuver requires sufficient residual perception, localization, planning, steering, braking, and propulsion capability. The system must not attempt a complex relocation maneuver when the functions needed to execute it are themselves unreliable.

Obstacle awareness should remain active throughout the Minimal Risk Maneuver. Even after the normal mission has been abandoned, pedestrians, vehicles, bicycles, equipment, and other dynamic objects may continue moving around the autonomous vehicle. The fallback trajectory should therefore remain subject to collision avoidance and safety-envelope constraints for as long as adequate sensing and control capability exists. Entering fallback mode does not eliminate the requirement for environmental awareness.

Drive-by-wire capability is critical to achieving a controlled MRC. Steering-by-wire, brake-by-wire, and throttle-by-wire systems should provide sufficient diagnostic coverage and residual authority to execute the fallback trajectory. Command and feedback signals should be continuously compared so that loss of actuator response can trigger a more conservative strategy. Safety-critical braking or steering capability may require independent power, communication, or control paths according to the system risk assessment.

Electrical power management is equally important because the transition to an MRC may occur during a power-system fault. Essential sensing, safety computation, braking, steering, warning devices, and communication may need to remain available for a defined period after primary power degradation. Energy reserves and redundant power paths should therefore be designed around the time and energy required to detect the problem, execute the Minimal Risk Maneuver, and stabilize the vehicle in the final condition.

The final MRC should establish a clearly defined physical and logical vehicle state. Propulsion may be inhibited, brakes applied, steering placed in an appropriate state, autonomous mission execution suspended, and hazard indicators activated. Safety controllers should continue monitoring critical conditions, while diagnostic information and the reason for the transition are retained. The vehicle should not automatically resume normal operation merely because the original fault indication temporarily disappears.

Communication can support the MRC by notifying a fleet management system, control center, or remote operator that autonomous operation has been restricted. The message can include vehicle position, MRC reason, sensor and actuator status, remaining energy, mission state, and assistance requirements. Nevertheless, the ability to reach a safe condition should not depend entirely on remote communication because network coverage or infrastructure may be unavailable during the event.

Remote assistance may be useful after the vehicle has stabilized or when limited guidance can safely support the fallback process. An operator may evaluate camera views, system diagnostics, maps, and environmental information before authorizing recovery or providing high-level guidance. Remote intervention should have clearly defined authority and safety constraints so that communication delay, incomplete situational awareness, or operator error cannot bypass onboard safety protections.

Warning and external communication mechanisms help surrounding people understand the vehicle\'s abnormal behavior. Hazard lights, audible alerts, display messages, beacon indicators, or vehicle-to-infrastructure communication may indicate that the vehicle is slowing, stopping, or unavailable. For outdoor AMRs operating near pedestrians or workers, clear and predictable signaling can reduce uncertainty and discourage people from approaching or obstructing a vehicle during a safety transition.

Recovery from an MRC requires stricter criteria than entry into a degraded state. The system should determine whether the initiating condition has been positively resolved, whether required sensors and actuators have returned to validated health states, and whether localization, perception, communication, and power integrity are sufficient for the intended mission. Depending on the severity of the event, remote authorization, maintenance inspection, recalibration, or a controlled restart may be required.

The MRC concept should be integrated with both functional safety and SOTIF. Hardware or software malfunctions may trigger fallback through functional-safety mechanisms, while insufficient perception capability, environmental ambiguity, or operation near the limits of intended functionality may trigger an MRC through SOTIF-related mechanisms. A common supervisory architecture can coordinate these different sources of risk and translate them into consistent vehicle-level responses.

Verification of MRC behavior requires testing the complete transition rather than only checking whether the vehicle eventually stops. Simulation, software-in-the-loop, hardware-in-the-loop, proving-ground tests, and vehicle trials should evaluate detection latency, decision timing, deceleration behavior, fallback trajectory, actuator response, warning activation, communication, and final-state stability. Testing should include combinations of faults and degraded environmental conditions because real events may involve multiple simultaneous limitations.

Scenario-based validation should cover representative operational situations such as sensor loss near pedestrians, localization degradation at an intersection, communication loss during a mission, actuator anomalies on a slope, compute degradation while moving, or power limitations in a constrained area. Each scenario should demonstrate that the selected MRM reduces risk and reaches an appropriate MRC without introducing an unacceptable secondary hazard.

MRC events should be recorded as important lifecycle safety data. Logs should preserve triggering conditions, sensor health, localization confidence, vehicle speed, planned and executed trajectories, actuator feedback, supervisor decisions, warning states, communication events, and recovery actions. Fleet-level analysis of these events can reveal recurring environmental limitations, overly sensitive thresholds, inadequate fallback strategies, or hardware and software weaknesses requiring engineering improvement.

A mature Minimal Risk Condition architecture therefore creates a controlled bridge between normal autonomy and a stable safe state when continued autonomous operation can no longer be justified. It combines early detection, degraded operation, risk-aware maneuver selection, residual sensing and actuation, controlled stopping, communication, recovery management, and validation. The central objective is not merely to stop the vehicle, but to minimize overall risk while preserving predictable behavior throughout the transition.

03.05. Safety Architecture Validation

Safety Architecture Validation establishes evidence that the complete autonomous vehicle safety architecture can maintain acceptable risk across its intended operating conditions, including normal operation, degraded states, faults, functional limitations, and fallback transitions. For an outdoor autonomous vehicle, validation must examine the integrated behavior of sensing, localization, planning, control, drive-by-wire, supervision, communication, power, and Minimal Risk Condition mechanisms rather than evaluating each subsystem independently.

Validation differs from verification in purpose. Verification asks whether a component or system has been implemented according to its specified requirements, while validation asks whether the resulting architecture is sufficiently safe for its intended mission and environment. A function may pass every requirement-based test yet remain inadequate when exposed to complex interactions, unusual road users, environmental uncertainty, simultaneous degradation, or scenarios that were not anticipated during initial development.

The validation process should begin with traceability from hazards to safety goals, requirements, architectural mechanisms, and test evidence. Each identified hazard should be connected to one or more safety requirements and corresponding mitigation mechanisms. Validation activities then determine whether those mechanisms actually reduce vehicle-level risk under representative operating conditions. Traceability prevents safety claims from depending on architectural features that have never been demonstrated through appropriate evidence.

Operational Design Domain (ODD) coverage is fundamental to validation. Road type, terrain, vehicle speed, weather, lighting, temperature, visibility, traffic density, pedestrian interaction, GNSS availability, communication coverage, and infrastructure conditions define the environment in which safety must be demonstrated. Validation should examine not only typical points inside the ODD but also boundary conditions where environmental parameters approach or exceed the limits of validated autonomous capability.

Scenario-based validation provides a structured method for exploring these conditions. Functional scenarios describe important interactions at a semantic level, logical scenarios define ranges for relevant parameters, and concrete scenarios specify exact values for executable tests. Vehicle speed, obstacle distance, pedestrian trajectory, visibility, road friction, localization uncertainty, sensor range, communication latency, and actuator response can be varied systematically to identify unsafe boundaries and unexpected interactions.

Nominal scenarios establish that the safety architecture does not unnecessarily interfere with correct autonomous operation. The vehicle should perceive the environment, localize, plan trajectories, control motion, and complete missions without inappropriate safety interventions when all systems operate within validated conditions. This baseline is important because an excessively conservative safety system can reduce availability, create unpredictable stopping behavior, or introduce operational hazards of its own.

Degraded-state validation examines whether the architecture responds correctly before a complete failure occurs. Tests can progressively reduce camera visibility, LiDAR detection range, GNSS accuracy, communication quality, compute performance, or actuator capability. The system should detect degradation, update confidence or health states, modify its safety envelope, reduce vehicle performance when necessary, and continue operation only while sufficient independent capability remains available.

Fault-injection testing evaluates the architecture under explicit hardware, software, communication, and power faults. Sensor disconnection, frozen data, corrupted messages, delayed packets, processor restart, network interruption, steering feedback errors, brake response degradation, and power-rail loss can be deliberately introduced. The objective is to demonstrate that faults are detected, contained, communicated, and converted into predictable vehicle-level responses before they create unacceptable physical behavior.

Sensor monitoring validation should include realistic information-quality failures rather than only electrical disconnection. Cameras may be obscured or exposed to glare, LiDAR returns reduced by contamination or weather, radar measurements disturbed, GNSS affected by multipath, and IMU signals biased or delayed. Such testing demonstrates whether the safety architecture can distinguish a device that is technically alive from information that is no longer sufficiently trustworthy for autonomous decision-making.

Localization validation must evaluate accuracy together with integrity and uncertainty. GNSS RTK correction loss, satellite obstruction, map inconsistency, wheel slip, IMU drift, and disagreement between localization sources should be reproduced under controlled conditions. The system should recognize when position confidence deteriorates and modify speed, trajectory complexity, operating authority, or fallback behavior before localization uncertainty becomes incompatible with the required safety envelope.

Planning and control validation examines whether unsafe commands are prevented even when upstream information is uncertain or abnormal. Candidate trajectories can be generated near obstacles, road boundaries, pedestrians, or dynamic vehicles while safety margins are deliberately reduced. Supervisory mechanisms should reject trajectories that violate collision, speed, acceleration, steering, stability, or stopping-distance constraints and should prevent mission optimization from overriding higher-priority safety requirements.

Drive-by-wire validation should confirm that steering, braking, and propulsion commands are executed within expected tolerances and that deviations are detected quickly. Command-versus-feedback monitoring, actuator saturation, delayed response, partial loss of authority, communication interruption, and redundant-path switching should be tested. Particular attention is required during fallback because residual actuation capability may determine whether the vehicle can successfully reach a Minimal Risk Condition.

Minimal Risk Maneuver and Minimal Risk Condition validation must test the complete transition rather than merely confirm that the vehicle eventually stops. Detection latency, decision timing, deceleration profile, obstacle avoidance, safe-location selection, warning activation, communication, final brake state, propulsion inhibition, and recovery logic should be evaluated. The resulting condition must reduce overall risk without introducing an unacceptable secondary hazard to nearby people or vehicles.

Common-cause and multiple-failure scenarios are especially important because redundancy can create misleading confidence when supposedly independent channels share environmental or architectural dependencies. Two cameras may fail under common glare, multiple GNSS receivers may suffer the same obstruction, or redundant computers may depend on one power source. Validation should therefore challenge independence assumptions and demonstrate how the architecture behaves when several protections degrade simultaneously.

Simulation enables large-scale exploration of scenario spaces that cannot practically be covered through physical testing alone. Parameter sweeps, Monte Carlo methods, synthetic environments, sensor degradation models, traffic variations, and rare-event generation can expose safety-critical combinations. Simulation results should be connected to physical evidence through model validation so that confidence in virtual testing remains proportional to the demonstrated fidelity of the simulation environment and vehicle models.

Software-in-the-loop (SIL) testing allows autonomous algorithms and safety logic to be evaluated rapidly before target hardware is available. Hardware-in-the-loop (HIL) testing extends this process by connecting real controllers, networks, and interfaces to simulated vehicle and environmental models. These environments are particularly useful for repeatable timing tests, communication faults, actuator anomalies, power-related events, and scenarios that would be dangerous or expensive to reproduce directly with a full vehicle.

Proving-ground validation provides controlled physical confirmation of behaviors identified through analysis and simulation. Test facilities can reproduce obstacle encounters, pedestrian crossings, emergency braking, localization degradation, low-friction surfaces, communication loss, and fallback maneuvers while maintaining appropriate safety controls. Results can then be compared with simulation predictions, allowing engineers to refine models and identify differences between virtual assumptions and real vehicle dynamics.

Field validation complements controlled testing by exposing the vehicle to environmental complexity that is difficult to model completely. Real roads, industrial sites, campuses, ports, agricultural areas, and other intended environments generate combinations of lighting, weather, infrastructure, human behavior, radio conditions, and sensor interference. Field testing should be conducted within controlled safety procedures and should focus on collecting evidence rather than simply accumulating driving distance.

Validation metrics should measure safety-relevant performance instead of relying only on mission success or aggregate perception accuracy. Useful measures include hazard-detection latency, intervention timing, stopping distance, minimum obstacle clearance, localization integrity, false intervention rate, sensor degradation detection time, fallback success rate, safety-envelope violations, communication recovery, and MRC completion. Metrics should be connected directly to safety requirements and acceptance criteria.

Coverage measurement is necessary because autonomous systems operate across extremely large scenario spaces. Validation should track which ODD dimensions, hazard categories, scenario classes, parameter ranges, fault combinations, and safety mechanisms have been exercised. Coverage does not prove the absence of unknown hazards, but it provides structured evidence that relevant operating conditions have been explored systematically rather than through an arbitrary collection of demonstrations.

Pass and fail criteria should be defined before testing whenever practical. Acceptable stopping distance, detection time, localization uncertainty, trajectory clearance, actuator response, communication latency, degradation threshold, and MRC completion conditions should be measurable. Predefined acceptance criteria reduce subjective interpretation and allow repeated tests, software versions, hardware configurations, and vehicle generations to be compared using a consistent safety engineering framework.

All validation evidence should contribute to a structured safety case. Hazard analyses, assumptions, requirements, architectural descriptions, simulation results, SIL/HIL records, proving-ground tests, field evidence, residual risks, and known limitations should form a traceable argument supporting deployment. Functional Safety and SOTIF evidence should remain complementary so that both malfunctioning behavior and limitations of correctly operating autonomous functionality are addressed within the vehicle-level safety justification.

Validation does not end when the vehicle enters service. Operational logs, near misses, emergency interventions, sensor degradation events, MRC transitions, remote assistance requests, and newly encountered scenarios provide additional evidence about real-world safety performance. These observations should update hazard analyses, scenario libraries, simulation models, thresholds, software, ODD definitions, maintenance policies, and subsequent validation campaigns throughout the autonomous vehicle lifecycle.

A mature Safety Architecture Validation process therefore creates a closed evidence loop between safety requirements, architecture, simulation, controlled testing, field operation, and continuous improvement. Its objective is not to prove that an autonomous vehicle can never fail, but to demonstrate systematically that hazards are recognized, safety mechanisms behave predictably, degradation is controlled, fallback remains effective, and residual risk is sufficiently managed throughout the intended operational domain.

Author: Richard Minsoo Go

LinkedIn: Richard Minsoo Go