In the automotive industry, ISO 26262 has created a clean definition of how to use proven components called Safety Elements out of Context (SEooC). While SEooCs are more commonly understood as hardware components such as microcontrollers or subsystems, the model provides a way to develop high-quality software elements out of context as well. These elements are designed to provide a specific functionality and meet a required safety level, even when there’s no awareness of how the software will be used (or even what parts of it will be used) in the final target system.
A TCP/IP SEooC
Let’s examine the problems of integrating a TCP/IP stack into an item within a vehicle. TCP/IP is a well-worn and proven protocol for communication; countless stacks are on the market with a vast array of features and variations. It makes little sense to rewrite this for each item, so it’s an ideal candidate for building a SEooC. But there are challenges.
1. This is an example of a basic stack designed for safety applications.
A simplistic TCP/IP stack designed for safety might include IP, ARP, ICMP, TCP, UDP, DHCP, ICMP, Sockets, and some network interface module for adding a target specific network driver (Fig. 1). It can be developed according to ISO 26262-6:2018 with a full V-model software development process as you would expect for safety-critical development. This will come with certain key artifacts:
- The SEooC assumptions that were made in the design of this SEooC. From a high-level viewpoint these might include a microcontroller type and endianness, the presence of an RTOS and a timer, etc.
- The SEooC requirements that define the detailed high-level and functional specification of the SEooC. It will start with the highest-level items, including the protocols and functionality that will be provided, and will drill down such that the complete system is specified.
- A validation test suite that completely checks that the software element behaves identically after integration as it did in the SEooC development process.
All of this needs to be covered by full traceability between requirements and test cases, and between requirements and the design and implementation.
To use this SEooC, the integrator must perform several steps:
- Validate that the assumptions made in the development of the SEooC match to what’s provided by the target system.
- Validate that the requirements (specification) of the SEooC match what’s required by the item.
- Verify that the element runs correctly on the target.
- Perform item-specific integration tests of the SEooC running in the target context.
This is all very straightforward so far—but practical problems must be addressed.
First, for a particular item, it may be that some parts of this stack aren’t required. For example, a simple case would be if the item only uses TCP for communication; thus, the UDP component is redundant. Unneeded components must be removed to avoid any integration tests for them.
Another case would be if the item always has a preconfigured network address because of its fixed role in a vehicle—dynamic reconfiguration isn’t something that happens in road vehicles; at worst it would happen during maintenance. Therefore, DHCP isn’t required.
Aside from the functionality, the configuration may need to be changed. For instance, the number of available network ports or sockets will naturally be changed to fit the target item.
All of these problems mean that the SEooC must be tailored for reuse in a specific item. The tailoring process of a SEooC is described in ISO 2626-10:2018 section 9.2.4 (Fig. 2).
2. The integrator must tailor the SEooC for reuse in a specific item.
For this reason, HCC built its SafeTCPIP SEooC as a set of SEooCs—each module (IP, TCP, UDP etc.) has its own complete V-model as per ISO 26262-6:2018—so that these modules can be put together as required (Fig. 3).
3. HCC Embedded’s SafeTCPIP SEooC is a set of SEooCs, each with its own complete V-model.
Once a module set is defined, the next problem is the tailoring of those modules. This will result in a new set of tests fully mapped to the new requirements and assumptions.
Options for SEooC Development
ISO 26262-10:2018 section 9 describes how to build software SEooCs. The document specifies four options for creating SEooCs:
- Proven in use
- Qualification of a software component
- ISO 26262-6 software element in context of an item
- ISO 26262-6 as software element out of context
Of these, only the last—developing the software element out of context specifically for reuse—meets all of the requirements outlined above, which is the need to develop something clean, to reuse it, and to modify it. The crux is that, unless an element is developed with full traceability and with all of the artifacts, it’s not possible to do a comprehensive impact analysis to initiate a set of changes to the element and guarantee the same level of validation.
How to Choose an ASIL
A fundamental part of developing anything to ISO 26262 is to work out what the potential risks that item might create and assign to it a target Automotive Safety Integrity Level (ASIL). These levels are from ASIL/A, low risk, to ASIL/D, where there’s a serious danger to life. Of course, if you’re developing an element out of context, you have no way to know what ASIL level may be required.
The simple answer to this would be to develop SEooCs to the highest ASIL—ASIL/D—so that they can be used anywhere, but this has some drawbacks. The primary problem is cost. To use an ASIL/D component in an item developed to ASIL/A is likely to be expensive to build as well as to tailor and maintain.
Once you create a target instance of a SEooC, it may be possible to then tailor the specific maintenance processes for that instance. However, analyzing all of the processes and somehow downgrading them isn’t a trival task. It might be easy to drop specific steps, but trying to downgrade traceability (which tends to be one of the more onerous tasks in a safety development) isn’t easy to arrange.
How to Integrate to the Target Safety Development System
Another major consideration is how to integrate this new element into the safety development system of the item—an item most likely developed by a different organization to the SEooC provider, with its own mature and structured safety development system. In principle, there will be very clear similarities between the two development systems, but even small differences, such as the tool used for requirements capture, might not be identical.
There are two possible approaches to resolving this:
- Integrate all of the developed artifacts of the SEooC to the target safety development system.
- Keep responsibilities separated and use the tailoring process and integration test process as the mechanism for controlling integration.
There are pros and cons to both (see table).
HCC takes the approach that for each item being developed, an independent instance of the Master-SEooC is created for that item: SEooC-item-instance-x (Fig. 4).
4. An independent set of SEooC instances is created from the Master SEooC for each target project.
An instance includes everything from the development of the SEooC, including all process documents, so that at any point, the SEooC-item-instance can be modified independently from any other instance. Using a SEooC this way avoids creating interdependency between items.
By adopting this approach, we can use our expertise in the core functionality of the SEooC to maintain independent instances of the SEooC. Therefore, any tailoring or defect management will only occur within that instance of the SEooC.
It creates the additional burden that each time a change needs to be made, it must be independently implemented for each instance. But the upside is that each change can be approved by the item manufacturer.
Summary
Developing software elements out of context is well-defined by ISO 26262:2018 and is a clear step up from the less-rigorously defined COTS or SOUP in other safety standards. Following the methods and techniques recommended, it’s possible to create a model for the development and maintenance of SEooCs as well as manage individual integrations to target items.
The only clear path is to develop the SEooC by the methods defined in ISO 26262-6:2018 and use the process defined in section 9 of ISO 26262-10:2018 to make integrations to target items. An important part of the use of SEooCs is a clear understanding between the SEooC supplier and the manufacturer of the target item. The development and maintenance processes need to be nailed down as part of the early project decision-making. With this approach, HCC Embedded was able to develop a SafeTCPIP stack that allows a range of core TCP/IP components to be safely integrated to automotive systems.
Dave Hughes is the CEO of HCC Embedded.
References:
https://www.hcc-embedded.com/seoocs/ (video)
