Part 1: Functional Safety-Driven Software Development and Virtual ADAS testing for Autonomous Emergency Braking System

Harsh Kumar Singh, Sujith Kudupudi, Ashok Kumar Modalavalasa
04:00 MINS
October 17, 2025

Autonomous Emergency Braking (AEB) is an advanced safety system designed to automatically apply the brakes when it detects an imminent collision, and the driver does not respond quickly enough. Using on-board sensors such as radar and cameras, AEB continuously monitors the road ahead and identifies potential hazards in real time. If the system calculates that a crash is likely, it can warn the driver and, if necessary, take autonomous action to decelerate the vehicle, helping avoid or mitigate the impact. AEB systems are now increasingly standard in modern vehicles, significantly improving road safety and reducing both the number and severity of accidents.

Introduction to Functional safety Compliance with ISO 26262 for AEB

Functional safety software development for Autonomous Emergency Braking (AEB) systems is achieved by rigorously applying ISO 26262, the internationally recognized standard for automotive electrical and electronic systems. This framework ensures the identification, assessment, and mitigation of risks caused by system malfunctions, focusing on the entire vehicle life cycle. By establishing safety goals, analysing hazards, and defining Automotive Safety Integrity Levels (ASIL), ISO 26262 guides manufacturers in building robust AEB systems that reliably prevent or reduce serious collisions. Ultimately, compliance with ISO 26262 is essential for building consumer trust, meeting regulatory requirements, and protecting road users from critical failures in autonomous braking technologies.

Functional Safety Approach in Ansys Medini Analyze

Functional safety approach in Ansys Medini Analyze on integrating HARA, FTA, and FMEA in a model-based environment, fully aligned with ISO 26262 standards. The tool ensures end-to-end traceability between SysML system models, requirements, and all safety analyses. This streamlines compliance, accelerates certification, and delivers consistent, efficient Functional safety software development workflows for complex automotive systems.

Connecting Design and Safety: A Smooth SCADE-to-Medini Integration Approach

SCADE Architecture Model integrating with Ansys Medini Analyze involves using the Embedded System configuration in SCADE Architect to classify system elements such as Functions, Software Components, Hardware Components, Sensors, Actuators, and Processors. During translation, each configured block is mapped to an equivalent SysML-based element in Medini Analyze (e.g., Function → SysML Activity, SW Component → SysML Block with Software Unit category, HW Component → SysML Block with Hardware Part category). The integration is executed through the Import from SCADE Architect feature in Medini, which supports incremental updates via the Diff/Merge tool. In this import process, SCADE packages, block definitions, activities, ports, and connectors are automatically translated into SysML elements such as SysML Container Package, SysML Block, SysML Part, SysML Port, and SysML Connector. This ensures consistent naming and structural alignment, enabling engineers to proceed with safety analyses directly in Medini using the translated architecture model.

Architecture of AEB

The AEB ECU architecture consists of an application layer handling perception and decision logic, a communication layer managing CAN/Ethernet communication, and a Basic software layer ensuring interface control with hardware. Inputs from Radar and Camera feed the perception algorithm, which sends Time-To-Collison (TTC) data to the AEB ECU. The ECU then generates brake commands via the ABS/ESC to the braking system.

Hazard Analysis and Risk Assessment of HARA

The Hazard Analysis and Risk Assessment (HARA) for an AEB system identifies potential hazards such as missed obstacle detection, unintended braking, or delayed brake actuation. Each hazard is assessed for its Severity, Exposure and Controllability to determine the corresponding ASIL level. Based on this, Safety Goals are defined to ensure the AEB operates safely even under fault conditions. This process ensures compliance with ISO 26262 and enhances the overall reliability and safety of the braking system.

Safety Analysis

For AEB, FMEA systematically identifies how individual components like sensors, control units, or actuators might fail and the effects on braking performance and safety. FTA starts with the undesired event (such as failure to brake in an emergency) and maps out possible causes and their logical relationships. Both methods help ensure the AEB system can reliably detect hazards and execute braking, highlighting where redundancy or diagnostics are needed. Their combined use is key to achieving functional safety for life-critical features like AEB.

Requirements Development

Requirements define the necessary functions, performance, safety, and reliability the AEB system must achieve to effectively prevent collisions. They guide system design by establishing criteria for detecting accuracy, timely braking, and fault tolerance. Clear requirements ensure the AEB system operates predictably in real-world conditions, guaranteeing occupant safety. These requirements are validated through rigorous testing, and continuous monitoring throughout the system lifecycle.

The functional safety of the Autonomous Emergency Braking (AEB system ensures the vehicle can detect obstacles and apply brakes safely and reliably. Through HARA, potential hazards like delayed braking or unintended braking are identified and their risk levels are assessed. FTA helps trace the root cause of system-level failures, while FMEA examines each component to find possible failure modes and define preventive measures. Based on these analyses, the control algorithm requirements are developed to ensure accurate decision-making, timely brake activation, and safe fallback actions during faults. Altogether, these activities ensure the AEB system meets safety goals and performs its break effectively under all conditions.

Developing Reliable AEB Control Logic Using Ansys SCADE

An Automatic Emergency Braking (AEB) system works by detecting potential collision risks and initiating braking to prevent accidents. The core software requirements for AEB include:

Perception Inputs: The system needs to receive inputs from sensors (e.g., cameras, radar, LiDAR) to identify objects in the vehicle's path, such as pedestrians, other vehicles, or obstacles. This data is typically used to classify and track these objects in real-time.
Collision Risk Assessment: The software must calculate metrics like Time to Collision (TTC) or Forward Collision Warning (FCW) to assess the likelihood of a crash. If the TTC is too short or the risk is deemed high, the system triggers a warning or initiates emergency braking.
Control Outputs: Based on the calculated risk, the system will issue commands to control the vehicle's braking system or steering (if an evasive maneuver is needed).

These processes need to be done seamlessly and in real-time to ensure safety. Furthermore, since AEB systems are safety-critical, the software must meet stringent standards like ISO 26262, which ensures that the system operates reliably and safely under all conditions.

Conclusion:

Functional safety forms the backbone of reliable Autonomous Emergency Braking systems, ensuring vehicles can respond intelligently and safely in real-world conditions.
Through tools like Ansys Medini Analyze and structured methodologies such as HARA, FTA, and FMEA, engineers can design architectures that identify, evaluate, and mitigate risks at every level of the system.

However, building software that aligns with these safety requirements presents a new challenge — one that demands efficiency, accuracy, and full ISO 26262 compliance. In Part 2, we explore how Ansys SCADE and Ansys AVxcelerate transform this challenge into an opportunity by unifying model-based development and virtual testing for next-generation AEB validation.