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: