The 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.
With passage of time and the lightening pace of technical advancement, the number of ECUs within automobiles is also increasing. This increase in complexity and functionalities of ECU-based car design is driven by a need for a comfortable driving experience along with safety and pollution control.
The automotive ECUs power many of the advanced function 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 of the 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. Functional safety schemes for automobiles helps in identifying malfunctions (electric and electronic), and specifies actions and techniques to be adopted to mitigate risks and damage during instances of software or hardware failures.
Inability or a delay in identifying or mitigating instances of ECU (hardware/software) failure can impact all the stakeholders throughout the value chain – including the ECU Supplier, Car manufacturers and the end user.
The consequences may involve loss of life or property, financial loss, legal liability, regulatory actions or even the loss of goodwill for all of those involved.
And this is why today modern vehicles are required to adhere to the safety standards listed within the Automotive Safety Integrity Level (ASIL). ASIL is a risk classification scheme specified within the ISO 26262 – a Functional Safety standard for Road Vehicles.
Image Credit: dcvizcayno.wordpress.com
Ensuring Functional Safety of Automotive Software with ISO 26262 standard
The ISO 26262 standard addresses the need for a unified and automotive-specific international Functional Safety Standard for electrical and electronic ECU and other embedded systems in a vehicle.
The ISO 26262 standard is an adaptation of IEC 61508 standard. It specifies recommendations to ensure the functional safety throughout the product development cycle- at the system, hardware, and software levels. The ASIL standard is a key component for the ISO 26262 compliance.
Most functions within an automotive ECU are implemented and controlled through automotive ECU software and the complexity of this software can reach more than 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 code and software components that perform functions with different ASIL ratings.
The ISO 26262 standard specifies two approaches to be followed if embedded software includes software components with varying ASIL ratings.
- Either develop the entire software according to the highest ASIL, or
- Take necessary actions to ensure that the software components with a with a lower ASIL rating are not interfering with software with 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 the automotive manufacturers and design engineers.
They have to play the balancing act of catering to increased application complexity while reducing the time-to-market with utmost care. And this while ensuring that no comprise is made on ensuring safety of the automotive application and software component.
The expertise then lies in designing the automotive ECU application by taking into account every aspect of safety failures that can occur during the product development cycle. These failures mostly fall under following groups:
- Random/systematic hardware defects
- Systematic software defects.
Identifying Sources of Errors during ECU Software development Lifecycle
The systematic software failures occur mostly due to human errors during different product development life cycle phases. These can mostly be traced back to a certain root cause and fixed.
Let us look at some instances of errors that usually occur during the software development cycle and which could have a lasting impact on the performance of the final automotive application:
- Requirement specification and communication– 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 eventually appears to be inaccurately defined within the scope of the system
- The requirement was simply misunderstood by the automotive software developer
- 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 errors, 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.
- 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 systems 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.
Designing a robust and well –optimized software, keeping into account these instances of errors; can reduce systematic failures to a large extent.
Recommended Approach
The best practice for developing functionally safe automotive software can vary with the end- application and requirement it is being developed for.
The development and design of a software specific to ADAS may not be same as the one for Anti-Lock Brake System (ABS). The need of the hour then is to optimize the software and hardware design according to the specific domain and application.
The ISO 26262, a functional safety standard for automotive, specifies definite techniques and measures to address various types of failures and issues related to the automotive software development lifecycle.
It is also necessary to ensure that while designing the ECU software and ensuring compliance with the ISO 26262 standard, the components (hardware and software) are not seen just as individual systems but as a whole .The best approach is to have a holistic view of the ECU application so that all the applications work in perfect coordination.
