Ensuring Functional Safety
Last updated
Last updated
he next big question is: Is it actually safe to open the vehicle door via an API? The answer is no, unless critical safety measures are in place. In a service-oriented SDV architecture, safety depends on implementing proper checks within the API for door control.
To make the door control API safe, several precautions must be built into its implementation:
Check Vehicle Motion Status: Before initiating the door-opening sequence, the API must verify that the vehicle is completely stationary. Opening the door while the vehicle is moving could lead to hazardous situations.
Rear Camera Verification: The API must also check the rear camera feed to detect approaching vehicles or obstacles in the vehicle’s path. If any danger is detected, the door-opening process must be blocked.
Side Camera Obstacle Detection: Using the side camera, the system must ensure that the vehicle door can open without hitting an obstacle like a wall, post, or another vehicle parked nearby.
Regulatory Compliance: All these checks must comply with relevant automotive safety standards, such as ISO 26262 and applicable UNECE regulations, ensuring that the door-opening process follows industry best practices.
The following diagram shows how this is implemented in our SOA architecture.
Finally, we return to the critical topic of testing in the context of Software-Defined Vehicles (SDVs). Recall our earlier discussion about testing loosely coupled systems and the Simeon Army with Chaos Monkeys. In the case of the open-door API with multiple use cases, testing needs to balance structured, deterministic methods from ISO 26262 with more chaotic, resilience-focused methods inspired by the Chaos Monkeys.
ISO 26262 mandates highly structured and deterministic testing aimed at ensuring functional safety, reliability, and regulatory compliance. This approach involves thorough documentation, rigorous reproducibility, and a time-consuming certification process. Essential testing techniques include:
Fault Injection Testing: Simulating hardware faults such as sensor failures or intermittent ECU connections.
Software Fault Injection: Introducing issues like memory overflows or corrupt data in communication protocols (e.g., CAN bus).
Power Fault Simulation: Testing power stability by simulating voltage fluctuations or power interruptions.
To evaluate how the system performs under unexpected conditions, resilience testing follows a more chaotic, exploratory path:
Fault Injection at Scale: Injecting large-scale, unexpected failures, including network outages or system misconfigurations.
Boundary Testing: Pushing the system to its operational limits. For the open-door API, this could mean simulating 10,000 rapid open-close requests per minute.
Signal Range Testing: Verifying the system’s response when input values exceed design specifications, such as extreme brake pressure or abnormal steering inputs.
Finally, system validation ensures that all interconnected components—hardware, software, and external environments—work seamlessly. This includes end-to-end testing of:
Functional Correctness: Ensuring the system works as intended under expected conditions.
Integration Testing: Confirming that subsystems interact correctly.
Environmental Simulation: Testing system responses to external factors like weather, road conditions, and driver behavior.
By combining these diverse testing approaches, SDV developers can build robust, safe, and resilient systems that comply with automotive standards while being prepared for real-world challenges.
Ensuring functional safety for every API introduced in a Software-Defined Vehicle (SDV) is critical. This requirement ties directly into the process of homologation, where APIs must comply with relevant technical regulations before deployment.
Homologation ensures that the open-door API meets legal and safety standards defined by international and regional authorities. Compliance is mandatory to certify that the vehicle is safe, secure, and road-legal across different markets.
To achieve homologation for the open-door API, developers can query a regulatory database like Certivity, which provides detailed technical regulations relevant to vehicle systems. For door-related APIs, several key standards apply, including:
UNR 11: Governs door latches and hinges, ensuring mechanical integrity and secure closure.
UNR 97: Focuses on vehicle alarm systems, ensuring anti-theft capabilities and safe vehicle access.
By referencing these standards, the development team can align the open-door API’s implementation with industry regulations, ensuring that technical compliance is met early in the development process. This approach reduces regulatory risk, supports continuous homologation, and accelerates product certification for global markets.
The following shows an example for a prototype combining COVESA VSS in the digital.auto VSS browser with the Certivity RegDB.
By integrating these safety mechanisms into the API, we ensure that the door-opening process becomes secure, compliant, and failsafe. This highlights how functional safety in SDV architectures is not just a technical feature but a critical system requirement that supports safety, reliability, and regulatory compliance.
