From Design to Verification: Best Practices for Automotive Functional Safety Certification

February 05, 2026

Blog

Ever wondered what goes into getting safety certification for electronic devices used in automobiles? In modern vehicles, even a minor design lapse can lead to catastrophic consequences. This is where functional safety becomes critical.

The goal of functional safety is to ensure that best design practices are applied right from the concept phase till the audit phase to adhere to the targeted safety level. The rationale is that the device should be able to recover from the fault and attain safe state. Thus, every device targeted for safety critical application needs to undergo rigorous safety certification process.

In this article, how to stitch the functional safety story into multiple phases of the device execution cycle is explored, beginning from high level system requirements to hardware implementation and verification. The article discusses details of safety work products developed across multiple phases of the design cycle and several strategies that can be adopted by engineers to ensure smooth safety certification journey for any device.

Safety in the concept phase

The definition of a device is derived based on its final application during the concept phase. Hence, during this concept phase, we need to carve out functional safety goals of the device based on the targeted safety level. There are 4 different safety levels ranging from ASIL A to ASIL D based on risk severity, exposure and controllability.

We determine the target safety level of the device based on the risk severity of the application. For example - In the ADAS (Advanced Driver Assistance Systems) applications, during emergency situations wherein a fault can lead to death or severe injuries, ASILD (Automotive Safety Integration Level) safety is required. For moderate risk situation, lower ASIL level safety can be aimed for. For minor risk situation, ASIL A can be targeted.

Safety in the implementation phase

Once the target safety level is determined, we list down the safety diagnostics. Each IP has a set of hardware/software diagnostics to identify faults within its sub-blocks. Each diagnostic has a test for diagnostic to verify if it is working.

All these diagnostics, test for diagnostics, functional description of IP sub-blocks are captured in the IP FMA (Failure Mode Analysis) document. These FMAs can be re-used across multiple projects if the same IP is re-used. Thus, during design phase we can also maintain a reuse document capturing list of IPs whose FMA can be re-used from the previous project to avoid re-work.

All these safety diagnostics can be maintained in jiras as the safety requirements. During design phase, each of this jira can be linked to its respective design implementation jira. A design implementation jira typically consists of design details like document link and design file path.

An automation framework can be deployed to ensure every safety requirement specification jira has an implementation jira linked. Further checks can be subsequently employed to verify correctness of the information captured in the implementation jira. This is to ensure that the document link and the design file path exist. This is the first end to end check to ensure every safety requirement is reviewed and implemented.

Safety in the verification phase

A comprehensive verification plan is developed to ensure the working of safety diagnostics. We identify the fault detection capability for each safety diagnostic during this phase. Thus, it is identified if the collection of safety diagnostics is helpful in achieving the targeted safety level. The FMEDA (Failure Mode Effects and Diagnostic Analysis) document is drafted using this information. This document includes list of all the safety diagnostics, diagnostic coverage, FIT (Failure in Time) and the final LFM (Latent Fault Metric)/SPFM (Single Point Fault Metric) numbers. If the final LFM/SPFM numbers are not as per the targeted ASIL, then update is required in the safety diagnostics to achieve the required fault metric to meet the targeted ASIL. Henceforth, additional safety diagnostics are created, and corresponding hardware/software update is made. Fault metrics are re-calculated. The process of fault metric evaluation continues until the required ASIL is achieved. The FMEDA report generation stage is complete once this objective is achieved.

All the verification details corresponding to each safety diagnostic can be captured in jiras by verification team. The details may include testcase details. The verification jira is linked to the implementation jira of the corresponding safety diagnostic. Thus, traceability flow looks like :-      Safety requirement jira -> design implementation jira -> verification jira.

Hence, JIRA tool can be used to facilitate this end-to-end linking and generating final traceability report. This traceability report is very handy during product’s safety assessment with the third party.

An automation framework can be established to extract all the testcase details from all the linked verification jiras and plug it into the verification environment to start regression of these testcases. The status of these testcases(pass/fail), log paths can then be extracted and attached to the respective jiras during every design release process. During the final design release, the final regression results can be attached to all the verification jiras. This will help immensely during safety audit process as all the relevant details are already captured in the jiras during the device execution phase.

All the useful information in the jiras and several safety work products (like FMA, FMEDA, traceability report etc) can be extracted and plugged into the safety manual in the final stage of the device sign off process.

The journey of functional safety begins right from the device conception stage. Starting with the safety related work products development right from the beginning helps in generating safety work products of excellent quality by the final design release. This reduces the onus on functional safety managers during the safety audit as the unnecessary effort of going over multiple documents to look for implementation/verification details related to any safety diagnostic can be avoided.

Hence, having JIRA based safety requirement to implementation, verification traceability and robust automation framework enables design/DV engineers to capture verified safety work products during the execution phase of any device.