Functional Safety before ISO 26262
While car technology has been developing for over one hundred years, ISO 26262 is a safety standard that was introduced only in the last decade. Safety features existed even before the publication of ISO 26262. However, there was no unified standard to address the complex interactions between software, electronics, and vehicle control systems.
Automotive systems have consistently included safety mechanisms, even long before formal safety standards were introduced. Multiple safety features existed, like braking systems, Electronic Stability Control, Traction control systems, airbags, seat belts, etc.
Here are a few safety standards that were used before ISO 26262 was introduced:
• IEC 61508: This was the general functional safety standard previously used, but not automotive-specific.
• Federal Motor Vehicle Safety and Regulatory Standards (FMVSS): This standard aimed to minimize traffic-related accidents and improve overall vehicle safety for all road users, including drivers, passengers, and pedestrians.
• IIHS (Insurance Institute for Highway Safety): This was an independent nonprofit organization, and the standard was supported by auto insurers. It aimed to reduce vehicle crashes, injuries, and fatalities by performing comprehensive safety research and testing.
Let us consider a few examples of safety mechanisms which existed in the past.
The dual brake systems, are an example of hardware redundancy—a safety mechanism designed to ensure that if one brake failed, the backup system would still function. Another example is the use of dual wheel speed sensors in ABS systems, which provided sensor redundancy to maintain functionality even if one sensor failed.
Multiple OEMs used self-check mechanisms, such as a test in the instrument cluster that turned on all tell-tale signs at ignition startups to ensure their correct operation. Memory self-tests were designed to identify random hardware errors, guaranteeing that the stored data remained intact over the product’s lifetime.
The ECC (Error-Correcting Code) mechanism was used in RAM to detect and correct memory faults, ensuring data integrity.
Vehicle communication utilized timeout monitoring, where CAN messages were observed to verify the accuracy of data transfer between ECUs.
Internal or external watchdogs were used as mechanisms to detect and recover from software-hangs, hardware peripheral faults, or CPU errors. There is no shortage of many similar examples.
The impact of ISO 26262
The standard has become the universal translator for everyone in the automotive electronics world. Now, everyone from OEMs to chip vendors, is finally speaking the same language, thanks to this standard.
In the earlier automotive systems, safety features were typically integrated in a straightforward, ad-hoc manner. With the introduction of ISO 26262, these aspects are now formalized using a structured framework. Safety is broken down into clearly defined elements such as safety goals, Functional Safety Requirements (FSR), safety measures, and other related concepts. This standardization ensures a systematic approach to managing the complexity of modern automotive systems.
ISO 26262 enables engineers to identify safety goals that may not have been previously classified as safety relevant. It supports the evaluation of whether the applied safety measures are appropriate, lacking, or excessive for the given risk level. The standard guides, which methods are mandatory, optional, or not needed for each ASIL level. It also helps determine the percentage of diagnostic coverage offered by different safety mechanisms.
Thus, it helps engineers select appropriate fault detection and mitigation strategies during system development.
Functional Safety-Mere Paperwork or More?
A common mindset is to finish the implementation first, then contact a certification agency to manage the paperwork and get certified.
However, Functional Safety is not just a checkbox at the end, it is a discipline. It ensures that safety is systematically planned, implemented, and maintained throughout the entire product life cycle.
The 2018 version of ISO 26262 reflects this approach. It consists of twelve parts, each outlining specific processes and requirements, resulting in several distinct work products necessary for compliance.
Let us take a closer look.
The ISO 26262 official website:
<credits: https://www.iso.org/standard/68383.html
ISO26262 FUSA Work Products
PART 1 Vocabulary
Work product details can be found in the official ISO PDFs; however, these are licensed documents that must be purchased.
PART 2 Management of Functional Safety
PART 3 Concept Phase
PART 4 Product Development at the System Level
PART 5 Product Development at the Hardware Level
PART 6 Product Development at the Software Level
PART 7 Production and Operation Service and Decommissioning
PART 8 Supporting Processes
PART 9 Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analysis
PART 10 Guidelines on ISO 26262
PART 11 Guidelines on application of ISO 26262 to semiconductors
PART 12 Adaptation of ISO 26262 for motorcycles
The Need for Multiple Work Products
• Modern cars are packed with electronics: automatic braking, lane keeping, parking assistance, cruise control, anti-lock braking systems (ABS), Advanced Driver Assistance Systems (ADAS), and even self-driving features. These systems rely heavily on electronics and software, making functional safety and system reliability more critical than ever.
• ISO 26262 provides methodologies on how to design safety. Thoroughly described and documented work products provide the necessary evidence to demonstrate that the system is adequately safe and compliant with the OEM’s ASIL requirements.
• These work products establish a standardized approach to safety. Without this structured framework, safety practices would be inconsistent, unreliable, and harder to validate.
• It introduced risk-based development through Automotive Safety Integrity Levels (ASIL), covering failure prevention, system design, hardware, and software development, verification, and validation, as well as production and maintenance.
• These work products serve as evidence that the OEM and supplier expectations are met. Moreover, ISO 26262 provides documentation of due diligence, helping to protect against liability.
Deadlines! For Every Project, Time is Always Tight!
It is a prevalent opinion that Functional Safety slows down development yet avoiding it leads to non-compliance. Trying to cut corners on required processes just to meet deadlines might help one ship faster, but it can compromise safety seriously.
Let us look at how tight deadlines can impact safety.
Skipping things like hazard analysis, dependent failure analysis, or safety reviews might save time in the present, but they can cause costly fixes later. Getting safety involved too late and discovering issues at the end is painful. People often jump to quick fixes without enough analysis or proper brainstorming. Superficially fixing safety issues may leave other violations hidden and unresolved. If tool qualification is ignored, verification results might not even count.
Best Practices for Tight Deadlines
• Start the functional safety activities right at the project kickoff. The earlier you catch risks, the less the rework later.
• Employ specialists who know ISO 26262 inside-out. A specialist who knows thoroughly how to keep safety-critical systems simpler and free from interference by non-safety functions is an asset to the process.
• Use pre-certified hardware and software modules, safety libraries, and proven safety architectures whenever possible.
• One of the biggest challenges for safety engineers is to design systems that are simple yet technically independent. Focus on designing simpler systems.
• Invest in automated tools for static analysis, model checking, and test coverage to enhance reliability and efficiency.
• Team-up safety engineers with developers from day one. Cross-functional collaboration helps prevent late-stage surprises.
• Avoid making individual decisions under pressure. Instead, hold a brainstorming session with the team to generate multiple solutions and then select the best one.
• Develop your safety case progressively throughout the development process.
• Qualify your development and verification tools early; otherwise, use pre-qualified tools.
• Keep documentation clear, concise, and traceable.
A Synopsis
Consider a scenario where your car radio stops working, it is not a big deal, it would just be a quiet drive. However, if your brakes stop responding because of a software bug, that is quite a different story—a dangerous one!
Remember! Safety is not an option, it is essential.
Every team should have a proactive approach towards Functional Safety. It is important to understand that the standard only expects compliance with the specified requirements, never asking for more than is necessary. It offers straightforward guidance about which methods or processes must, may, or need not be applied depending on the ASIL level.
It also guides one on how to identify potential failures, to design systems to reduce those risks, to test everything and what to do if a system does fail despite all this. Hence, proper analysis and diligent documentation ensure the required compliance with the ASIL.
You can find Functional Safety (FuSa) expertise and simplified explanations of key concepts on the website below.
https://www.functionalsafetyfirst.com/p/about.html
Author Bio & Picture:
Suneja Walavalkar is a Technical Lead at Einfochips, specializing in Functional Safety. She holds a TÜV SÜD Functional Safety Certification (Level 1) and a B.Tech in Electronics and Telecommunication Engineering. Prior to joining Einfochips, she has worked with Lear Automotive India. Leveraging her technology domain and experience, she is now focusing on Functional Safety projects in terms of system, software, and hardware domains.
Top comments (0)