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 legacy software component became unusable for safety qualification following the “ISO 26262:2018-8-14 Proven in use” clause if there is not enough field data to verify safety standards.
• In cases where component field data are available, the operating environment is changing in the modern vehicle architecture due to the introduction of more autonomy and software-driven features.
• The legacy software is not generally developed following a national or international standard (such as ISO/IEC/IEEE 12207). Therefore, it is impossible to qualify following the “ISO 26262:2018-8-12 Qualification of Software Components” clause.
• Similarly, in most cases COTS software components, although developed following the national or international standard, have missed the required quality documentation such as requirement specification, design documents, requirement-based test reports, etc., preventing safety qualification.

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:

• The reusable component can be integrated into any configuration or operational scenario
• Reusable components can be used even by modifying some functionalities as needed for improvement/upgrades
• This approach is more reliable as it does not depend upon any historical data for fault handling, instead identifying the faults and then efficiently containing them inside the supervisor component
• This approach requires qualifying only the functionality of the reusable component which is applicable in the given system context – eliminating the need to verify the complete reusable component and decreasing overall safety qualification time
• The best benefit of this approach is the component’s safety run-time monitoring which is unavailable in other solutions 

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.