Driving smarter ECU consolidation
There is a shift emerging in industry, particularly the automotive sector that will have a profound impact on developing software that must comply with functional safety standards. Currently, even a small car is likely to have around 70 electronic control units (ECUs) controlling everything from the braking system and lights, to the windows and entertainment center. On a luxury car, the number of ECUs can easily be 120.
The financial benefits involve significant risks
Developing all those separate ECUs is expensive. The shift (and it is already happening) is from having one ECU for each function to having multiple software components coexisting in the same ECU. This has technological and economical advantages, such as hardware sharing, reduced communication overheads and fewer wires and connectors; but it comes with considerable risks.
The first risk is that any failure of the shared hardware can affect multiple software components and the associated functions. The second risk is when software components running on the same ECU can interfere with one another. That means a fault in one software component (such as the entertainment system) might cause a failure on another software component (such as the engine management system).
The latter risk is significantly aggravated if software components with different criticalities coexist in the same ECU. In this scenario, extra care has to be taken to avoid less critical components, which will have been developed in compliance to less stringent processes, sabotaging more critical components.
De-coding the functional safety standards (ISO 26262)
There are valid economic reasons for the co-existence of software components with different criticalities. Indeed, the functional safety standards for the automotive sector (ISO 26262) allows for this. However, the ISO 26262 requirements imply that, in this situation, developers have two choices. They can either:
Develop all the software to the same standard as the safety critical software. This is an expensive option as manufacturers will incur the cost of developing non critical software, such as the in-car entertainment system, to the same safety compliance as critical software such as the braking system.
Provide proof that it is not possible for low critical software components to interfere with safety critical components. Clearly, a much more cost effective option.
How ECLAIR can help
Providing the software-level part of that proof is exactly what we have designed the new functions in the latest version of our ECLAIR tool to do. ECLAIR provides a general service that detects and checks all the interactions between user-defined software components. In addition to verifying that the planned hierarchical structure of each software component is respected by the implementation (another requirement of ISO 26262), it provides orders-of-magnitude savings in the verification that:
(i) they are sufficiently independent from each other;
(ii) there is no interference between them (which is a crucial requirement for ECU consolidation).
Users can configure the tool to specify the allowed interactions, and ECLAIR produces a violation message for each unwanted interaction. ECLAIR will enforce whatever constraints on access the user configures, not just safety issues. This is a dramatically more cost effective option than the alternative, which is to test at a later stage of the project.
Dependent Failure Analysis is required in case of: (1) ASIL decomposition, (2) implementation of software safety requirements, or (3) required coexistence of the software architectural elements
In this blog, we have just scratched the surface of some complex concepts. You’ll find a more comprehensive coverage of ECLAIR support for ISO 26262 in this whitepaper. This also gives an in-depth explanation of exactly how ECLAIR provides crucial support to development, QA and safety teams who need to provide evidence of how their software ensures freedom of interference, independence, and absence of interference.
In addition, you can also watch a very interesting webinar precisely on this subject, "Verifying the Hierarchical Structure and Freedom from Interference of Software Components":
Of course, if you have any questions don't hesitate to get in touch.
Upskill your technical knowledge: join us for our new webinars or at Menlopark’s Embedded TESTCON conference
By the way, we have more webinars scheduled. You can check out all the details here.
We would also like to take this opportunity to invite you to register to join us at Embedded TESTCON. This conference will run online from November 3rd to 6th. Our CTO is giving a technical presentation, a training workshop and a case study presentation and he will also take part in a panel discussion. More details will be revealed over the next few weeks.
You can also connect with us on LinkedIn to make sure you never miss our updates!