Modern-day vehicles have evolved from predominantly mechanical machine into an electronically-controlled system.Today, a car consists of hundreds of automotive Electronic Control Units (ECU) and millions of lines of software code.
As comfort and safety features in cars expand, the number of ECUs needed to support them is also growing. This rise in ECUs adds complexity to car designs, driven by the need for better driving experiences, improved safety, and stricter pollution controls.
Implementation of ISO 26262 standard to ensure functional safety becomes critical in this context.
Automotive ECUs power many of the safety-critical functions and features available in modern cars, including advanced driver assistance (ADAS), telematics, passive safety systems, engine management—to name a few.
Functional Safety in Automotive:
With the widespread adoption of modern automobiles, run and regulated by automotive ECUs, the need for advanced safety features has also become inevitable. Functional safety as a process has become an essential component of the ECU software development cycle.
Automotive functional safety practices help identify malfunctions (electronic and electrical) and specify actions and techniques to mitigate risks and damage during instances of software or hardware failures. This aligns closely with the guidelines outlined in the ISO 26262 standard.
Inability or delay in identifying or mitigating instances of ECU (hardware/software) failure can impact all stakeholders throughout the value chain—including ECU suppliers, car manufacturers, and end users. The consequences may involve loss of life or property, financial loss, legal liability, regulatory actions, or even the loss of goodwill for all involved.
This is why modern vehicles are required to adhere to the safety standards listed within the Automotive Safety Integrity Level (ASIL), a risk classification scheme defined in the ISO 26262 standard.
Image Credit: dcvizcayno.wordpress.com
Ensuring Functional Safety of Automotive Software with ISO 26262 standard
ISO 26262 standard addresses the need for a unified and automotive-specific international functional safety standard for electrical and electronic ECUs and other embedded systems in a vehicle.
As an adaptation of the IEC 61508 standard, the ISO 26262 standard specifies recommendations to ensure functional safety throughout the product development cycle—at the system, hardware, and software levels. The ASIL classification is a key component of the ISO 26262 standard compliance.
Most functions within an automotive ECU are implemented and controlled through automotive ECU software, which may consist of over 10 million lines of code. Typically, these programmable ECUs contain highly modular embedded software. The software may include both safety-related and non-safety-related components performing functions with different ASIL ratings.
The ISO 26262 standard specifies two approaches to be followed if embedded software includes components with varying ASIL ratings:
- Develop the entire software according to the highest ASIL.
- Take necessary actions to ensure that software components with a lower ASIL rating do not interfere with software components with a higher ASIL rating.
Design and development of ISO 26262 compliant ECU Software
The need for developing safety-critical automotive components and the increasing demands for complex and innovative automobile applications are ongoing challenges for automotive manufacturers and design engineers. They must cater to increased application complexity while reducing time-to-market, all while ensuring adherence to automotive functional safety guidelines.
The expertise lies in designing automotive ECU applications by accounting for every aspect of safety failures that can occur during the product development cycle. These failures mostly fall under the following categories:
- Random/systematic hardware defects
- Systematic software defects
Identifying Sources of Errors during ECU Software development Lifecycle
Systematic software failures often arise due to human errors during various product development lifecycle phases. These failures can be traced back to root causes and addressed effectively. Common instances of such errors include:
- Requirement Specification and Communication Errors: This phase results in one of the largest sources of errors. It occurs when:
- Software executes “correctly” according to the understanding of the requirement, but the requirement itself is inaccurately defined within the system scope.
- Requirements are misunderstood by automotive software developers.
- Software Design and Coding Errors– Considered as the second most common source of errors, this type of error usually occurs due to:
- A poorly structured embedded software code
- Timing errors, incorrect queries, syntax errors, algorithm errors, error in displaying results, lack of self-tests, failed error-handling – to name a few.
- Errors due to software changes – Such errors is said to have occurred when
- Changes to the developed software may introduce unanticipated errors
- Failure of the configuration control process
These errors can usually be traced back to requirements and programming errors.
- 4. Errors Due to Inadequate Testing: During the testing phases, sometimes the software seems to have passed the testing criteria, but during the actual execution it may fail to perform the required task. Such a failure is termed as a testing failure. This happens if:
- Software functions properly in unit testing
- Software passes system and integration testing, but ideally it shouldn’t have. This happens when safety-critical test coverage is inadequate.
Such errors can also be traced back to requirements and programming errors.
- Errors in Timings: Software performs the right function, but at the wrong time or under inappropriate conditions. Such instances of errors during the application development can be reduced or eliminated by introducing failure-safe processes and by taking extra care at each of the phases including: requirement analysis, design, manufacturing process, documentation etc.By adhering to the ISO 26262 standard, many of these errors can be mitigated through rigorous processes and validation techniques.
General Best Practices Recommended by Automotive Functional Safety Experts
Every FuSa project has unique requirements, however there are certain best practices that remain common. We talked to our FuSa experts to know what their go-to ISO 26262 standard best practices are.
Model-based Design
The Model-Based Design paradigm complements the ISO 26262 standard exceptionally well. Certain aspects of the standard, like requirement traceability, early validation, and error detection, are best adhered to when MBD is implemented. For instance:
- Traceability: MBD allows direct mapping of safety requirements to system models and simulations, ensuring seamless traceability.
- Early Validation: Engineers can simulate real-world scenarios during the design phase, catching issues before physical prototypes are built.
- Error Reduction: Auto-generating production code from validated models minimizes manual coding errors.
How It Works:
- Use Specialized Tools: Platforms like MATLAB, Simulink, or dSPACE enable teams to build executable models of systems such as electric power steering or battery management system.
- Test Before You Build: Simulate scenarios like sensor failures or unexpected environmental conditions to validate system responses.
- Generate Code from Models: Once the model is verified, generate production code directly, ensuring consistency between design and implementation.
Enhanced Verification and Validation Techniques
When it comes to meeting the stringent requirements of the ISO 26262 standard, verification and validation (V&V) techniques are vital. These processes ensure that every safety-critical element behaves as intended and adheres to automotive functional safety norms. Certain techniques, like fault injection and automated regression testing, fit perfectly within the ISO 26262 standard framework.
Techniques to Consider:
- Static Code Analysis: This is your first line of defence. Tools like Polyspace scan the source code to find hidden issues like null pointer dereferences or unsafe type conversions.
- Dynamic Testing: Dynamic testing validates how software performs in real-world conditions. Tools like VectorCAST help simulate and monitor runtime behavior, ensuring robust safety mechanisms.
- Fault Injection: Introduce faults deliberately—like dropping voltage or corrupting sensor data—to evaluate the system’s response. Fault-injection testing is a critical step for validating fail-safe mechanisms.
- Automated Regression Testing: Set up CI/CD pipelines to automate testing whenever code is updated. This ensures that new features or fixes don’t compromise existing functionality.
Safety-oriented Coding Practices
Code—whether written manually or auto-generated from a model—holds the key to the quality and reliability of software. And when it comes to developing safety-critical solutions, the code must adhere to the ISO 26262 standard to ensure compliance with automotive functional safety requirements.
So, how do engineers ensure that? By following a set of rigorous safety-oriented coding practices tailored for safety-critical systems.
- Follow Industry StandardsTo maintain consistency, predictability, and reliability, engineers adhere to industry-accepted coding standards like MISRA C or AUTOSAR C++.
- Defensive Programming to Anticipate FailuresSafety-critical systems must assume that things can—and will—go wrong. Defensive programming ensures the software can handle unexpected inputs or behaviours without any glitch. It involves validating inputs at every stage and adding fallback mechanisms to handle errors.
- Use Pre-Certified LibrariesPre-certified libraries provide validated functions for tasks like cryptography or mathematical operations, reducing the need for custom development and validation efforts. They save time and ensure compliance with the ISO 26262 standard, as they have already been tested for safety-critical environments.
Comprehensive Traceability
Think of traceability in automotive functional safety like a detailed map for a road trip. Just as you need a clear route to get from Point A to Point B, traceability ensures that every requirement, design, implementation, and test connects seamlessly.
It is vital for demonstrating compliance with the ISO 26262 standard, linking every requirement to its corresponding implementation and validation.
How to achieve traceability?
- Establish a Traceability Matrix: Link safety requirements to design elements, code, and test cases.
- Use Advanced Tools: Tools like IBM DOORS, Jama Connect, and Polarion can automate and maintain traceability, reducing manual effort and improving accuracy.
- Maintain Version History: Use version control systems like Git to document changes and track their impact on safety-related artifacts.
- Audit-Ready Documentation: Maintain clear and concise records that link every requirement to its corresponding safety assessment and test results.
Recommended Approach
The best practice for developing functionally safe automotive software also varies with the end application and its specific requirements. For example, the development and design of software for ADAS may differ significantly from that for Anti-Lock Brake Systems (ABS).
To ensure adherence to the ISO 26262 standard, developers should:
- Optimize software and hardware design according to domain-specific requirements.
- Treat components (hardware and software) as part of an integrated system, rather than as isolated units.
- Implement error mitigation techniques across all stages of development.
By adopting these measures, automotive manufacturers can achieve robust compliance with the ISO 26262 standard and ensure that their designs meet the highest standards of automotive functional safety.
