Over the decades, the car has evolved from a mechanically controlled machine to an electronically controlled system. Modern vehicles include hundreds of electronic control units (ECUs) managed by software. Advanced features like (Remote Parking Assistance, Adaptive Cruise Control, Automated Lane Keeping System, Driver Status Monitoring & Attention Assist, Blind Spot Detection & collision warning, etc.) are part of almost all modern cars. And now, with more software-driven features, like autonomous driving and driver assistance features in vehicles, a paradigm shift is underway in the automotive industry.
According to a McKinsey & Company study, the global automotive software and electronics market will grow to $469 billion by 2030 from the current market size of $238 billion. The study also highlights four factors fueling this growth – autonomous driving (AD), connectivity, electrification, and shared mobility (ACES). These ACES megatrends will completely transform vehicle electronics and software-architecture requirements over the next ten years. ECUs manage the safety-critical functionality of a car through software. With the expected explosion in growth for automotive software, focusing on safety qualification is imperative.
ISO Standards Address Most Quality Standard Scenarios
With the introduction of ISO26262 - Functional Safety for Road Vehicle standard in 2011 and further refinement in 2018, product development for automotive following the safety recommendations became convenient. However, there are scenarios where car manufacturers prefer to use legacy software components instead of building everything from scratch. Or it is necessary to use a commercial-off-the-shelf (COTS) solution as part of the product. But these components/solutions are not functional safety certified. Safety qualification is needed to address these scenarios.
New Challenges for Vehicle Software Standards
ISO 26262 specifies several approaches to qualify the legacy or COTS software components not developed following IS026262 standards. However, these approaches require documentation or field data which are not available in most cases. For these scenarios, there are a few specific challenges to address:
The challenges above are faced by different automotive organizations while qualifying reusable software components. Some organizations have found a route to address the challenges, but each has taken a different approach. For example, Red Hat’s Linux-based in-vehicle OS attempts to qualify each software package. In case of any gap, they opt for a complete re-development following the safety standard. On the other hand, Altia is making its existing HMI technology ASIL compliant by introducing a safety monitor, as is the QT Company. Similarly, SafeTTy Systems has developed ASIL B Linux by defining a run-time monitoring technique.
Solution Recommendation to Address Quality
While some market players have identified different routes to make their reusable software components safety compliant, the solution developed using the ASIL decomposition techniques (specified by ISO 26262:2018-9) seems to hold the most promise. Adding a ‘Wrapper’ or ‘Supervisor’ component, responsible for detecting irregular behavior and taking recovery steps, would provide a more comprehensive solution. The suggested architectural changes are below:
Note: X represents the different ASIL levels (i.e., A, B, C, or D)
This architecture can be explained through the ISO 26262: 2018-9-5.4.7 clause – ASIL decomposition between an intended functionality and its safety mechanism. In this improved architecture, all communication between the system software and the reusable software component would go through the Supervisor module to ensure any failures in the reusable software component do not cascade to other parts of the software.
Revised Strategy Provides Additional Business Benefits
The solution described above gives the system integrator the flexibility to use any legacy software component or COTS solution without the time-consuming task of looking into the development history, i.e., configuration management record, change management record, field data, test log, etc. But this architecture provides other valuable benefits:
A New Standard for the Software-Driven Architecture
All car manufacturers invest heavily in new features and technologies in modern vehicles but ensuring driving safety is a central focus. With the introduction of software-driven vehicle architecture, many COTS or legacy software components from the IT world (e.g., container ecosystem, middleware protocol such as data distribution service, service discovery protocol, etc.) will be in modern cars. To safety-certify those components, the revised ASIL strategy with the ‘Supervisor,’ having run-time monitoring capability, will be the most effective technique for the automotive software developer to achieve the overall safety requirements of the products when utilizing reusable components.
Senior Architect – Automotive Functional Safety
Arnik has been with Wipro for 15+ years, with work experience spanning across different domains of Automotive. He has contributed to several in-house competency building initiatives, the creation of intellectual property and more over Functional Safety Certification for Wipro. Currently Arnik is leading the Automotive Functional safety COE of Wipro.
Architect - Automotive Functional Safety
Sayanshree has more than 11 years of experience in software development. While working on different Automotive domains according to ISO26262 – she has acquired considerable experience in Safety Architecture and Safety compliance. She is an active member of Automotive Functional safety COE of Wipro.