Defining Automotive Functional Safety through Hardware to AI
This includes pedestrian detection, lane keeping, over-the-air updates, cloud integration, and decision-making on the go. These capabilities are provided thanks to software, connectivity, and AI.
The evolution of vehicles into smart machines increases the complexity of their safe operation, which makes automotive functional safety an essential consideration when developing any modern car architecture. A vehicle fault cannot be limited to just a hardware malfunction anymore; it can also come as a software error, an unintended system interaction, and even an incorrect prediction from an AI model. That is why there is ISO 26262.
It ensures that safety is considered and complied with throughout all stages of development, providing the framework for creating a system that would be able to detect faults, handle failures, and work safely anyway.
Traditionally, the concept of automotive functional safety in automobiles has been limited to hardware components. If the hardware components were trustworthy and failures could be managed, then the automobile was safe. But that alone is not sufficient in today’s world, where Software Defined Vehicles depend on software to control critical functionalities, connected to cloud computing platforms to stay online, and where artificial intelligence is playing an increasingly significant role in determining driving decisions.
The task of developing a functionally safe vehicle involves ensuring safety in the very process of engineering each component of the automobile, from the hardware all the way through software, and even connected and intelligent features.
Building Automotive-Grade Hardware for FuSa Compliance
Each critical safety function within a car needs hardware. This can be anything from brakes to steering to battery control to an ADAS controller. In all cases, there is just one task for the hardware besides doing what it’s supposed to do. That is to behave predictably if something fails.
This is the reason why automotive functional safety in vehicles begins with hardware. The engineers start building a platform that can sense failures, isolate them, and put the whole system in a safe state before writing any software or training any AI algorithms.
Defining Safety Goals Before Designing the Hardware
Hardware design does not start with deciding on processors or developing circuit boards. It starts with considering possible scenarios that can go wrong.
The process begins with Hazard Analysis and Risk Assessment, popularly called HARA. The process involves identifying any scenario that poses a safety threat and analyzing its severity level, probability of occurrence, and likelihood of avoidance by the driver. Based on these findings, a function is assigned a certain Automotive Safety Integrity Level (ASIL).
These safety objectives form the Technical Safety Requirements, which will determine all key decisions related to the hardware, including choice of processors, redundancy, diagnostics, fault tolerance, and safety features to be incorporated right at the initial stage.
Here are the ISO 26262-level safety standards designed for hardware components as follows:
| Hardware Component | Safety Relevant Function | Typical ASIL Level |
|---|---|---|
|
Braking Controller (AEB) |
Automatic Emergency Braking |
ASIL D |
|
Electronic Steering Controller |
Steering command execution and monitoring |
ASIL D |
|
ADAS Domain Controller |
Perception, lane keeping, adaptive cruise control |
ASIL B to ASIL D |
|
Battery Management System |
Overcharge, overcurrent, and thermal protection |
ASIL B to ASIL C |
|
Powertrain Controller |
Torque control and drivetrain management |
ASIL C to ASIL D |
|
Airbag Control Unit |
Collision detection and airbag deployment |
ASIL D |
|
Gateway ECU |
Secure communication between vehicle networks |
ASIL B |
|
Body Control Module |
Lighting, wipers, and door lock systems |
ASIL A to ASIL B |
|
TPMS Controller |
Tyre pressure monitoring and driver alerts |
ASIL A to ASIL B |
The level of ASILs that is demonstrated above varies with respect to the design of the system and its operational environment and the results of HARA analysis.
Implementation of Safety Mechanisms within the Hardware
After defining the safety specifications, the hardware can be designed to detect abnormal situations and act properly when any faults occur.
It may include the following components according to applications:
- Lockstep processors performing parallel calculations
- Error Correcting Code (ECC) protected memory that detects and corrects memory faults
- Safety MCUs (microcontrollers)
- Watchdog timer that detects software faults
- Clock and voltage monitors
- Built-in self-test (BIST)
- Hardware Security Modules
All the listed mechanisms perform different functions; however, they make sure that any single fault will not lead to the dangerous failure of the whole system.
Proving the Hardware Meets Functional Safety Requirements
Hardware Safety Verification
Simply adding safety measures will not suffice. Engineers must verify that the hardware satisfies the Functional Safety criteria determined in the HARA process.
Such hardware safety verification will normally consist of:
- Deriving Hardware Safety Requirements
- Developing the Hardware Safety Architecture
- Performing Failure Modes, Effects, and Diagnostic Analysis (FMEDA)
- Evaluating diagnostic coverage
- Validating SPFM, LFM, and PMHF metrics
- Verifying safety mechanisms before production
These activities provide proof that the hardware has the capability to detect failures, manage failures, and satisfy the Functional Safety requirements as per ISO 26262.
Automotive Example: Automatic Emergency Braking Controller
Think about the Automatic Emergency Braking controller.
An unexpected braking or a failure of a brake command can have disastrous effects. Such situations are classified as high-risk cases during HARA, which leads to ASIL D requirements.
To fulfil this requirement, the following components are incorporated into the controller: redundant CPUs, lockstep operation, memory with ECC protection, watchdogs, the independent Safety MCU, as well as constant diagnostics. All these components continuously analyze the controller while it is operating. If any failure occurs, the dangerous braking commands will be denied, and the controller will transition into a safe state before the error affects the safety of the car.
This is the idea behind Functional Safety. The hardware is not only supposed to operate properly but should also recognize and react to failures in a proper manner.
Given such an approach to the hardware design, we can proceed with the software part. After all, nowadays, hardware forms the basis for operation, and software gives the actual behavior of the vehicle.
Building Safe Software and Digital Vehicle Platforms
The hardware provides basic foundations, but software enables what modern automobiles are demanded in current life. The software controls the acceleration, braking, steering, battery performance, and reaction to the environment.
As vehicles continue to evolve into software-based platforms, there is a need for the automotive functional safety of the automobile to be dependent not only on the hardware but also on the software.
Turning Safety Goals into Safe Software
The safety objectives formulated during the HARA exercise do not end there; these safety objectives are then converted into Software Safety Requirements (SSRs). The SSRs specify how the software should operate under normal circumstances and, more significantly, how it will behave when a fault occurs.
These requirements normally include:
- The ability of the software to detect an abnormal operating condition
- The predictable response of the software to any faults
- Deterministic operation of the software
- Safeguarding of safety-critical functions
- The transition of the software into a safe state whenever necessary
As opposed to just fulfilling the necessary functional requirements, the software will be reliable even in case of faults.
Developing Software for Safety Critical Systems
To meet such criteria, a structured software architecture is required. Automotive platforms such as AUTOSAR and Real-Time Operating Systems (RTOS) form the basis for the architecture, while safety principles, such as Freedom from Interference (FFI), software partitioning, resource isolation, deterministic execution, and fault detection, guarantee that the malfunctioning of one application does not interfere with the functioning of the other critical safety functions.
The principle is simple: if one software system fails, it must be transparent to the other systems.
Verifying Software Functional Safety
Ensuring software safety is just part of achieving the end goal. In addition, engineers must demonstrate that every Software Safety Requirement has been applied correctly and verified.
This normally means:
- MISRA C and MISRA C++ compliance checks
- Static code analysis
- Tests such as unit, integration and regression testing
- Configuration management
- End-to-end requirements traceability
Requirement traceability is particularly useful throughout the development stages of the program. Any changes made can be traced back to what was originally required in terms of safety.
Automotive Example: Electronic Steering Control
Electronic Steering Control is an example of this procedure in practice. Being responsible for steering commands that affect vehicle orientation, unexpected actions may result in severe danger. In accordance with HARA, the ASIL level will be assigned, and Software Safety Requirements will be derived from the Technical Safety Concept.
The software will continuously check the validity of steering angles, detect signal timeouts, provide memory protection, deal with diagnostic faults, and make transitions into the safe state in case of detected faults. Invalid data will be ignored, and the system will enter the safe state. The software should not only perform a function but also validate its ability to do so.
Up to this point, all procedures relate to the preparation of software before production. But modern cars keep developing even after being manufactured.
Maintaining Functional Safety After Production
The software development process is not finished when just a vehicle rolls off the assembly line. Modern cars have their capabilities upgraded, bugs fixed, and performance improved even after they have been sold to consumers. This means that every single change made in software can potentially influence critical functions.
This is the reason why Functional Safety does not only include development but also encompasses updates and validation of software.
Digital Engineering: Maintaining Safety in Connected Vehicles
Modern vehicles don’t stay the same after manufacturing. Features, improvements in performance, and bug fixes are regularly delivered through Over-the-Air (OTA) updates. While these updates increase the capabilities of the car, they might impact safety-related operations.
This is why functional safety should regulate not only the development process but also deployment of the software in the entire vehicle life cycle.
Managing Safe OTA Updates
Nowadays, over-the-air (OTA) updates are an inherent component of modern vehicle architectures. Before any update is released to the vehicle, it is evaluated for its influence on the safety-critical features and ensured compliance with the initial Functional Safety criteria.
The usual process involves such steps as:
- OTA Campaign planning
- Safety impact evaluation
- Checking software compatibility
- Validation of Functional Safety criteria
- Deployment with security measures
- Post-deployment validation
As for the installation itself, the use of authentication and integrity checks allows the safe transition to the new software or roll back to the previous one.
Functional Safety and Automotive Cybersecurity
With the growing connectivity of vehicles, Functional Safety has become interlinked with Automotive Cybersecurity. An unauthorized software upgrade or a compromised communication channel is not merely a matter of concern from a security perspective; it significantly impacts vehicle safety.
To mitigate these threats, modern vehicle platforms have worked hard to implement technologies that include Secure Boot, Secure Flashing, Secure Diagnostics, Hardware Security Modules, Secure Key Management, encrypted communication, and Intrusion Detection Systems.
Managing the Connected Vehicle Lifecycle
Connected platforms also allow manufacturers to track vehicle operation. Engineers monitor how vehicle systems operate to overcome issues in the early stage and apply software iterations safely.
Standards such as ISO 24089 and UNECE R156 for software update engineering, and ISO/SAE 21434 and UNECE R155 for connected vehicles’ automotive cybersecurity.
Automotive Example: Updating an ADAS Domain Controller
Take for example when we have an ADAS Domain Controller that controls Adaptive Cruise Control, Lane Keeping Assist and Automatic Emergency Braking. Suppose the OEM has come up with a better perception algorithm and wishes to implement it via an OTA update. Before this step is done, the engineers must check if these changes affect any already set safety requirements leading to carry out regression, integration and system testing. The update package is thoroughly checked and authenticated before being passed for installation.
This means that the update can only be installed on the vehicle once certain safety conditions have been met i.e., it is parked, there is enough charge in the battery, and stable connection to the network. After the installation is complete and all diagnostics have been completed successfully. In the case when verification fails, the controller brings back the previously approved software, which proves that with every vehicle transaction, the vehicle remains in safety mode.
With software getting more intelligent, another sort of issue has emerged. The decisions of the vehicle are not solely made by the rules but by learning-based models.
Building Safe AI Systems for Automotive Applications
As we have seen, as vehicles become smart, new challenges to safety have arisen. The latest ADAS and autonomous driving functions depend on AI algorithms that detect lanes, pedestrians, the environment, and make decisions on how to drive. But unlike conventional software that operates based on fixed instructions, AI can learn from data and act differently based on different scenarios.
For this reason, automotive functional safety needs to go beyond protection against hardware or software failure.
Defining Safety Before Training AI
From conventional software where algorithms can be trusted to follow predictable paths of code, because AI-enabled solutions rely on their data, AI behavior is dependent on learning and knowledge acquired. This means that safety cannot just start with the development of the model but should be initiated through appropriate safety targets.
By following standards like ISO 26262, ISO 21448 (SOTIF), and ISO/PAS 8800, the engineers formulate AI safety goals and requirements.
They also define operational design domains (ODD), which indicate the places and conditions under which AI systems can safely operate.
The Operational Design Domain consists of:
- Operating environment and constraints
- Expected system performance
- Allowed uncertainties
- Fallback and safe-state strategy
- Runtime monitoring demands
These constraints allow creating safe AI systems.
Developing Reliable and Compliant AI Models
When the safety criteria have been established, engineers shift their attention to creating AI models that would work effectively in real-life circumstances. As opposed to conventional software, whose performance relies on the program code, the performance of the artificial intelligence largely relies on the quality and variety of training data.
Thus, safety-oriented AI design calls for:
- Diverse and representative datasets
- Correct data labelling
- Bias reduction
- Explainable model
- Confidence estimation
- Out-of-Distribution (OOD) detection
- Massive model validation
Besides reaching high performance in the test phase, the aim of the process is the predictability of the performance in a variety of different situations.
Ensuring Safe AI Operation Beyond Testing
An adequately trained AI model will be able to encounter situations that it has not encountered during training. For this reason, Functional Safety considers factors other than accuracy. Engineers put the AI model through its paces in varied driving conditions, edge cases, environmental conditions, uncertainty factors, and failure modes.
But, testing is not enough to handle all real-world scenarios. The next generation vehicles implement various safety features such as confidence monitoring, safety supervisor, runtime checks, ODD monitoring, and graceful degradation approaches.
All of these serve as a protective layer for the AI model. Whenever there is any uncertainty in the AI model, unreliable sensor readings, or any out-of-bounds operating conditions, the car may limit functionality, warn the driver, or even go into safe mode.
Automotive Example: AI-Based Lane Keeping Assist
The application of an artificial intelligence-based lane keeping assist system provides a good example of the working of AI safety. Initially, engineers define the conditions where the system can work safely, like roads with lane markings. Subsequently, the AI system is trained and tested in various scenarios, for example, rainy weather, deteriorated lane markings, shadows, construction sites, and darkness.
In operation, the AI system constantly assesses lane placement and confidence levels along with an independent safety monitor, which evaluates decisions made by the system. In case of decreased confidence or changing conditions outside of the acceptable range of operating conditions, the AI system will be able to disable automatic steering and hand over vehicle control back to a human driver.
Thus, it becomes clear that vehicle safety is not solely provided by the intelligence of an AI system but by a fully developed safety framework.
With the expertise and experience in automotive engineering, MosChip draws from its comprehensive Functional Safety engineering services to deliver ISO 26262-conformant automotive systems starting from HARA and ASIL determination, Safety Concepts, FMEA, FTA, SEooC development, safety assessments, tool qualification, all the way through processes of verification and validation. Used together with the competences in AUTOSAR, embedded software, ADAS, EVs, SDV platforms, MosChip can achieve quick delivery of safe and compliant automotive systems.
To know more about MosChip’s capabilities, drop us a line, and our team will get back to you.
FAQs
Automotive Functional Safety is essential in Software Defined Vehicles (SDVs) because vehicle functionality increasingly depends on complex software, electronic control units (ECUs), sensors, and AI–driven systems. As software takes on greater responsibility for functions such as steering, braking, powertrain control, and advanced driver assistance systems (ADAS), even a single malfunction can create significant safety risks. Standards such as ISO 26262 provide a structured framework to identify potential hazards, assess risks, and implement appropriate safety measures throughout the vehicle lifecycle.
ISO 26262 focuses on preventing hazards caused by faults in electrical and electronic systems, while ISO 21448 (SOTIF) addresses risks that can arise even when no system fault exists. This is especially important for AI-based functions such as perception, object detection, and driver assistance, where limitations in sensing, data, or operating conditions can affect system performance. Together, these standards help manufacturers address both system failures and performance limitations to improve the overall safety of intelligent automotive systems.
MosChip provides comprehensive Functional Safety engineering services to help OEMs, Tier 1 suppliers, and semiconductor companies develop safe, compliant, and reliable automotive systems. Our expertise spans hardware, embedded software, semiconductor IPs and SoCs, AUTOSAR platforms, ADAS, EVs, Software Defined Vehicles (SDVs), and AI-enabled automotive applications. From HARA, ASIL determination, and Safety Concepts to FMEA, FTA, SEooC development, verification, validation, safety assessments, and compliance documentation.
