By Dave Higham and Maricel Ventura
Reliance on electronics and software is big business in the automotive industry and has driven significant focus on quality and reliability of vehicles and their components. Alongside this, the aim of safe, secure and accident-free driving has been given significant attention, with the publication of ISO 26262 for functional safety and ISO/SAE 21434 for cybersecurity for electronic and electrical systems (E/E Systems) of road vehicles.
In this blog our focus will be primarily on aspects of functional safety, but have no doubts, without addressing security, safety has no foundation. As an aside, the scope of road safety is much broader than vehicle E/E systems, and only with the collaboration of all stakeholders can all aspects of road safety be addressed successfully.
Back in the day, E/E systems were introduced to replace mechanical control systems to increase accuracy and precision of control but also to increase reliability and reduce costs. Today however, the complexity of E/E systems, and our reliance on them continues to increase, with control being taken out of the hands of humans in the form Advanced Driver Assist Systems (ADAS) to fully Autonomous Vehicles (AV). This is resulting in an increase of the vehicle boundary that is being extended into collaborative vehicle systems and the ‘Intelligent Transport System.’ Even prior to the AV systems, a typical high-end motor car would include more than 100 electronic control units (ECUs) executing over 100 million lines of code. Even low-end cars would contain up to 50 systems distributed throughout the vehicle.
To cater for the surge of E/E systems in road vehicles there was a need to address and align on a common framework to address safety challenges in complex software intensive systems. This was ratified in 2011 with the first edition of ISO 26262 with a second edition published in 2018, and activities for the third edition underway.
The scope of ISO 26262 is specifically focused on addressing possible harm caused by the malfunctioning of E/E systems, installed in ‘series production road vehicles’. It provides a framework for functional safety, based on automotive practices with additional activities to cover such things as safety analysis, hardware metrics and independent confirmation measures.
ISO 26262 is objective based and specifies requirements covering the entire lifecycle from concept to end of life. Like its parent standard, IEC 61508, it addresses safety via risk identification and reduction. All identified intolerable risks are addressed by the implementation of safety measures to avoid or control systematic failures, to detect or control random hardware failures, and to mitigate their effects.
ISO 26262 uses a qualitative risk classification called ASIL, ‘Automotive Safety Integrity Level’, where risks are classified from ASIL A to ASIL D, with ASIL D being highest.
Without going into the detail of ASIL classification the figure below shows the two aspects of ASIL i.e. the risk and rigour (via safety measures).
The “balance” of ISO 26262 implied above, is to enable the identification and classification of the hazardous events at the vehicle (Item) level via ASILs and to define the rigour, via safety measures to address the unacceptable ASIL risks to provide confidence that all risks have been addressed. Critical to achieving functional safety is the identification of safety related failures in the causal chain that lead to hazardous event, hence the need to perform safety analysis throughout the architectural hierarchy of the E/E system to identify safety requirements and safety mechanisms to address these failures.
The emphasis in the brief overview above is that functional safety is an attribute at the vehicle level, but as we all know, vehicle E/E systems are a set of complex hardware and software systems, that interact with one another where components are provided from a broad range of suppliers. This is where ISO 26262 has a significant focus to ensure traceability of safety requirements, development rigour, integration, and deployment. So not only are there technical interfaces to be addressed, but there are commercial, organisational interfaces to be managed too. One aspect, and possible contradiction to ISO 26262, is that rather than the “top down” approach of ISO 26262, in many instances the lower tiers of the supply chain (i.e. ECU, SoC, CPU, etc) are developing product prior to customer engagement and are therefore developing Safety Elements out- of-context (SEooC).
As an IP vendor like Codasip, why should we pay attention to all these safety considerations? It is crucial because our processors often form the core of E/E systems. Whether our CPU is running safety-critical application code or dedicated safety functions, ensuring the integrity of these processors is essential for achieving functional safety. However, operating at the bottom of the supply chain necessitates a keen focus on Systematic Elements of the Safety Case and SEooC requirements. This requires us to have a practical understanding of the vehicle domain to the greatest extent possible.
In this case as a supplier of processor IP core – designs based on a set of assumptions. The key assumptions are the use cases where the element will be deployed, the safety related failure modes and the resultant safety requirements that the IP core needs to achieve.
Examples of safety assumptions are:
- Required fault diagnostic time interval (FDTI)
- Fault reaction (resulting to safe state) and/or degraded mode
- Target ASIL
- External safety mechanisms implemented by SOC integrators
Note that with SEooC the supplier defines the target ASIL rather than deriving it from a vehicle level HARA and associated safety goals so it imperative the SoC integrator of the IP take ownership and validates these SEooC assumption.
When the IP element is designed it will be subject to a rigorous safety analysis using methods such as:
- Failure Modes Effects Analysis (FMEA) to identify systematic design failures
- Dependent failure analysis (DFA) to identify common cascading faults
- Hardware architectural metrics (FMEDA) to identify permanent and transient faults.
To enable the SoC integrator to assess using the element developed out-of-context (ooC), the CPU supplier provides a “safety pack” including a safety case report, a safety manual and safety integration manual alongside other technical documents.
These documents enable the integrator to assess whether the SEooC can meet their safety requirements of the ECU and to provide practical help for the integration and their assurance activities.
IP vendors like Codasip face a crucial decision regarding the sale of their intellectual property (IP) cores: whether to offer them with ASIL (Automotive Safety Integrity Level) assurance only or to pursue additional third-party ASIL certification. Opting to sell IP developed without ASIL certification provides flexibility and speed in the development process, allowing for quicker market entry. However, this approach places the responsibility of ensuring ASIL certification squarely on the shoulders of the SoC integrator. On the other hand, undergoing third-party ASIL certification demonstrates a commitment to meeting rigorous safety standards and provides customers with added assurance of the IP core’s reliability in safety-critical automotive applications. While this route may involve additional time and investment upfront, it can ultimately lead to enhanced trust, expanded market opportunities, and strengthened relationships with customers who prioritize safety and compliance. Therefore, the decision between selling IP cores with or without external ASIL assurance requires careful consideration of factors such as market demand, competitive landscape, and long-term strategic objectives.
