A camera manufacturer can develop cameras for different industries viz. mobile, security or automotive. Let’s say, one of the potential applications of this camera is an infotainment system.
What if this infotainment system is ASIL C compliant? The camera will now also come under the purview of ISO 26262 standard. However, not as a regular E/E item, but as a safety element out of context (SEooC).
Did we get you puzzled? Let’s bring in some clarity!
The software or hardware components that are developed without considering the context of their application in a particular vehicle; meaning components that are developed without any idea of where they will be fitted, fall under the purview of SEooC.
Another way to define SEooC is, “E/E systems that are not developed based on the specific requirements provided by the OEM, suppliers or technology vendors, but are developed rather on assumptions”.
In other words, such systems, hardware or software, are developed for an assumed context and not for a specific vehicle, OEM or industry.
Part-10 of the ISO 26262 standard has the recommendations for development of safety elements out of context.
SEooC in the Context of Automotive Industry: Understanding the Hardware & Software SEooC
In the context of automotive industry, the most common hardware SEooC is the microcontroller.
Mostly, microcontroller platform designs provide the building blocks, based on which a specific system (that caters to a particular business use-case) is developed.
Hence, these building blocks (microcontroller platform and the various pins/ports) are not developed based on the requirements provided by any stakeholder in the automotive industry.
Talking of a software SEooC, the classic example is an RTOS (Real time operating system). An RTOS is equipped with a scheduler, that is designed to meet the real-time requirements of an embedded system.
There are several RTOSes available in the market that are not necessarily designed for an ISO 26262 compliant automotive control unit or any specific applications.
These RTOSes are required to be configured and customized for a specific application.
A note of caution:
We have provided some very basic examples of SEooC, however, in certain projects, determining an SEooC gets a little complicated. What might seem as an SEooC, may not be one. A wrong assumption of such an element may impact the entire functional safety lifecycle and hence, cause serious implication.
As a matter of fact, assumptions hold the most importance place in SEooC development. Let’s learn more about these assumptions as we explore the approach to SEooC development as per ISO 26262.
SEooC Development as per the ISO 26262 Standard: Understanding the Process
Development of a safety element out of context starts with assumptions. The developers make assumptions of the target environment and develop the product accordingly.
General Assumptions Made for SEooC Development include:
- The area of application and the intended function of the component
- An overview of the technical architecture of the system
- Functional and Technical Safety Requirement
- Automotive Safety and Integrity Level (ASIL) value assigned to the system
Based on these assumptions, the detailed safety requirements are derived, safety goals are set, and the product development begins.
A sharp contrast can be observed here, between the actual concept phase in safety lifecycle (HARA) and SEooC.
In the development of SEooC, the safety goals and ASIL value are not determined by HARA but are based on assumptions described above.
Before, integrating the SEooC into the system, these assumptions are also validated on 3 grounds:
- Requirement Level: This ensures that the SEooC meets the requirements of a system.
- Architecture Level: The SEooC fits right with the target system architecture
- ASIL Level: The SEooC meets the ASIL requirement, i.e. ASIL A/ ASIL B/ ASIL C/ ASIL D
Understanding SEooC With Example
As we have already stated that a SEooC can be a software, hardware or a complete system. In order to have clarity, let’s understand development of a system as a safety element out of context.
Let’s say that the system under consideration is a lane departure warning system, designed to warn the driver in case of lane departures.
This functionality is supposed to be automatically activated at certain conditions. And can also be deactivated by the driver.
Assumptions made by the Developer
- The system interfaces with other automotive ECUs via CAN BUS, in order to get the required vehicle info
- It is designed for a front-wheel driven automotive
- The system activates automatically as well as on driver’s request- Functional requirement
- The system deactivates if requested by the driver- Functional Requirement
ISO 26262 Related Assumptions about:
- Item Definition to assume the components which with the system will interact
- Safety Goals and ASIL Value
- Functional Safety Requirements (FSR) and Technical Safety Requirement (TSR)
Safety Goals and ASIL Assumption:
- System does not get activated at high-speed.
- System does not get deactivated unless the driver requests for it
- The system will fetch information from external sources about the vehicle speed and the driver’s request (ASIL C or ASIL D)
These assumptions and more (in a real world system) help in derivation of the complete technical safety requirements (TSR).
Once, the TSR is finalized, the SEooC is ready for the development as per the ISO 26262 standard. The product development process is similar to the functional safety lifecycle (Part 4,5 and 6)
Once, the SEooC is developed, the development team needs to provide all the work products (DIA, FMEA report, FMEDA report, FTA etc).
These work products include- Safety Requirements as well as the assumptions that they are based on. Such information helps the OEM or the tier-1 supplier to integrate the SEooC in the target system with utmost accuracy.
What if the SEooC does not match the requirements of the target system?
At the SEooC integration phase, the safety requirements of the Item (directly under scope of ISO 26262) is matched with safety requirements assumed for the SEooC.
If some discrepancies are identified, a change management activity is initiated as per Part-8 of ISO 26262 standard. Impact analysis is performed and following possibilities are worked out.
- If the differences are found to be acceptable w.r.t to the safety goals, no action is taken.
- If found unacceptable, a change is made to either the item definition or the functional safety concept.
- Or the change is made to the SEooC component.
The assumptions made by the product developers varies depending on the component under consideration.
Let’s see some of the assumptions of software and hardware SEooC to understand the difference.
Assumptions in Development of a Microcontroller Unit as Safety Element Out of Context
- Contribution of the MCU in violation of a safety goal
- Probability of failure of CPU instruction memory (derived using FMEDA)
- Safe State implementation by the MCU in case of a reset.
- Safety mechanisms implemented within the stipulated time
- ASIL value based on the assumed functionalities of the MCU
Assumptions in Development of a Software as SEooC
- The software architecture of which the software will be a part of
- Interference caused by the software component is handled by the system
- Assumption of ASIL value of the software based on the data it handles
- List of error conditions
- Handling of instances of Data corruption
Advantages of SEooC
- The concept of SEooC reduces the ISO 26262 certification cost through re-use of components
- It allows the suppliers to develop the software and hardware components according to the safe practices prescribed by ISO 26262
- Re-certifying additional components can be easily avoided by making them SEooC
- Components can be developed without the actual requirements and ASIL value, thus, making the process less restricted.
AUTOSAR and SEooC: How do they Get Along?
Although SEooC and AUTOSAR are not directly related to each other, it’s important to talk about AUTOSAR here. Partly because, the blog is written keeping the automotive landscape in mind and because SEooC and AUTOSAR have a lot in common.
Let’s elaborate a little.
AUTOSAR aims to achieve standardization in software architecture, by making the different layers independent of each other (abstraction).
Each module viz, MCAL, BSW, RTE and the application layer can be developed independently without any dependence to the OEM specific applications.
The different software layers are almost like ‘plug and play’, where only certain configurations are required before implementation.
At the concept level, SEooC is quite similar. The ‘safety elements out of context’ components are developed, without any dependence on the system of which they may become a part of.
In that way, they are also developed as ‘plug and play’ components, ready to be integrated into a range of systems (depending on the assumptions made during the development).
If the AUTOSAR layers such as application or MCAL are developed based on certain assumptions, these components also qualify to be ‘safety elements out of context’ components.
Even from the technology vendor’s perspective, AUTOSAR and SeOOC are on a common ground.
If AUTOSAR standard is followed, solutions from different vendors can be integrated to build a complete system.
Similarly, multiple SEooCs developed by tier-1 suppliers or product engineering services companies can be part of a common system.
However, what makes SeOOC different is the functional safety (ISO 26262) aspect, which is not directly covered by AUTOSAR.
There is another dimension to it too!
During the development of an SEooC, the AUTOSAR compliance can also come into picture.
However, this will happen only when the SEooC developers are sure about its implementation in an automotive solution. In such a scenario, the safety element can be called an AUTOSAR compliant SEooC.
Conclusion
Automotive industry has several stakeholders that come together to build a vehicle. An ECU may be from a different company and sensors from the other.
Now that the ISO 26262 has become almost a de facto standard for automotive safety, the concept of SEooC is acting as a bridge. SEooC is an attempt to eventually and gradually develop an environment which is conducive for all the stakeholders.
It allows time and scope for different stakeholders to participate in this common and larger goal of achieving Functional Safety in Automotive.
