In the previous articles of the Renesas Functional Safety Blog Series1, Renesas introduced the Renesas Functional Safety Support Program and the CAR tool. The blogs also gave a short background of the ISO 26262 standard, which is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles2. In part 6 of the ISO 26262 standard, the guidance and requirements on developing safety-related software are given3. At Renesas, we aim to provide software products that enable customers to realize a faster and easier path to build safe automotive ECUs, systems, and vehicles.
This is the third blog in the Renesas functional safety series. As mentioned in the previous blogs, the majority of Renesas safety products are developed as Safety Element out of Context (SEooC). The SEooC software is targeted for Renesas automotive MCUs and SoCs and is developed for a wide range of applications. This blog will discuss some critical aspects when developing SEooC software, the challenges, and the Renesas SEooC software solutions.
SEooC, as defined in ISO 26262, stands for “Safety Element out of Context”, which means it is not developed in the context of a specific item. An SEooC is developed based on assumptions. It is intended to be used in various items when the validity of its assumptions can be established during integration of the SEooC. Although the focus of this blog is software, an SEooC can be a system, a combination of systems, a subsystem, a software component, a hardware component or a part3. Some typical examples of SEooC software are: Autosar MCAL (Microcontroller Abstraction Layer), embedded system OS (Operating System), and middleware software.
ISO 26262 provides guidance on developing a software component as SEooC in three steps4:
- Step 1. Conclude assumptions on the scope and the safety requirements of the software component as an SEooC.
- Step 2. Develop the software component based on the assumptions and in accordance with the requirement of ISO 26262-6 corresponding to its ASIL (Automotive Safety Integrity Level) capability. All applicable work products are made available for further integration in different contexts. Examples of work products are:
- DIA/DIR5 (Development Interface Agreement/Report)
- S-SRS (Software Safety Requirement Specification)
- SAN/SM (Safety Application Note/Safety Manual) - describes the assumptions, safety feature implementations, as well as other safety-related information
- Source code
- Configuration manual - assists users to understand and apply the configuration properly
- FSA report (Functional Safety Assessment report), etc.
- Step 3. Integrate the software component in a specific context. In this step, the validity of all the assumptions made on this SEooC are checked regarding this context. In the case where some assumptions do not fit with this new context, an impact analysis is initiated.
In step 1, one of the challenges is to compile assumptions properly. The perspective of assumptions can be broad. Here are some typical examples of assumptions:
- Use case assumptions: describes the assumed use case.
- System level protection assumptions: some safety mechanisms are implemented on the system level to protect the hardware IP (Intellectual Property), for example, end-to-end protection for communication messages.
- Assumptions on requirements of partially covered safety mechanisms: If some safety mechanisms are not fully covered by the SEooC software, the integrator is required to complete the implementation. Renesas documents these requirements as AoU (Assumption of Use) in the SAN (Safety Application Note) and assumes that the integrator will fulfill these requirements.
- Assumptions on integration requirements: the SEooC software will be integrated into an application. To deem that integrated software reaches the target ASIL level, it is necessary to define the integration requirements and assume they can be fulfilled by the integrators.
The software engineers and safety engineers at Renesas have years of experience in developing functional safety software. The assumptions are concluded and documented with careful analyses of the software and assumed system. Renesas' development process ensures the safety requirements based on these assumptions are reviewed and assessed.
In step 2, a major challenge is presented due to the configurability of the software. Many SEooC software products are configurable because of the “out of context” nature. The software needs to be adjustable for different contexts. Therefore, configuration shall be considered. The configuration that is implemented in the end product shall be verified and validated. As the number of configuration parameters increases, the number of possible configurations increases exponentially. How can SEooC software suppliers gain enough confidence that all of the configurations are sufficiently covered by the tests? Two lifecycle options are described in ISO 26262:
- Option 1 is to apply “Simplified Lifecycle I”: verify the configured software. This involves after-release verification activities either at customer site, or, with configuration shared by the customers, the supplier can provide aftermarket verification service. As the number of customers and projects increase, how can the supplier still provide the service with good confidence and efficiency? These solutions bring tremendous value when dealing with the challenge:
- Automated test systems. Renesas has established automated test systems, which can execute a significant amount of testing in a short period of time. These test systems are available for pre-release software verification, as well as post-release software verification for customer configuration.
- Well-defined requirements. Renesas teams aim to define the requirements thoroughly and accurately. Renesas has established a sophisticated process, defining guidelines, templates, responsibility between departments, and so forth. Using modern requirement engineering tools, the requirements are reliably captured, and traceability is easily maintained. When testing the customer configuration, better test coverage can be achieved with well-defined requirements.
- Option 2 is to apply “Simplified Lifecycle II”: verify the configurable software with a range of admissible configuration data, and show the customer configuration is compliant with the verified configuration data range. The target of the verification is to cover as many possible configurations as possible. Renesas has incorporated many state-of-the-art testing methods. These methods include N-wise Testing6, Feature Combination Testing, Random Testing, etc. These methods aim to optimize the testing configuration sets, to cover more configurations with fewer number of tests. With support from these testing methods, there is a higher chance to ensure the customer configuration is covered in the verified configuration range. In this way, further verification can be avoided, which is not desirable as it results in additional cost and effort.
In step 3, when the SEooC software finally reaches the customer, the customer will face the challenge to validate the assumptions and integrate it into their system. It can be time consuming for customers to validate all assumptions. It may also require adequate knowledge of the software to understand and confirm all the assumptions. When the assumptions are not valid, it may require changes to the SEooC component or a change to the system safety requirements. This may result in extra effort and cost on the supplier or customer, or both. Renesas discloses all the assumptions of use for Renesas functional safety software products in the SAN (Safety Application Note). This document is carefully written and reviewed, to assist the users to understand and verify the assumptions with minimum effort. As part of the Safety Support Program for Automotive, software support is provided to customers in case there are any questions.
Acknowledging the difficulties in developing and providing SEooC software, Renesas continues to accept the challenges. Renesas’ target is to provide software products that meet all relevant ISO 26262 requirements, as well as to provide necessary information for the users to also meet the ISO requirements when integrating the SEooC software into their system. Renesas has established a three-pillar structure for compliant product development: development team, quality assurance, and internal independent technical assessment team. The development team at Renesas has a long history in developing functional safety software, following the ISO 26262 standard. The quality assurance team is responsible for assessing and auditing the functional safety process during the software development. The internal independent technical assessment team performs the technical assessment on the Renesas functional safety software products to ensure that it is functionally safe from a technical perspective. Renesas also works with external assessors on software functional safety assessment. With these well-established teams and a strong safety culture, Renesas is keen to provide ASIL software that is:
- Well-developed by an experienced development team
- Thoroughly assessed by I3 level quality assurance team and internal independent technical assessment team
- eEasy to integrate into a safety system by customers
In conclusion, in this blog we first introduced the ISO guideline on developing software SEooC. Then three challenges were discussed. Renesas provides solutions to these challenges by:
- Developing and assessing the software products with experienced engineers and well-defined processes
- Incorporating state-of-the-art testing methods and utilizing automated testing systems
- Providing customer support to facilitate the SEooC integration process
Renesas has a broad profile of SEooC ASIL software products. For RH850 MCUs (Microcontroller Units), Renesas provides MCALs and CST (Core Self Test) software libraries in ASIL quality. For R-CAR SoCs (System on Chips), Renesas provides ASIL quality software such as CPU runtime test, computer vision software, security software, etc. Renesas also works with 3rd party partners such as OS vendors and compiler providers to complete system solutions. Please contact your Renesas sales representative if you have any interest in Renesas software solutions.
1: Renesas Automotive Functional Safety Page
2: ISO 26262-1:2018 Road vehicles — Functional safety Part 1 Vocabulary
3: ISO 26262-6:2018 Road vehicles — Functional safety Part 6 Product development at the software level
4: ISO 26262-10:2018 Road vehicles — Functional safety Part 10 Guidelines on ISO 26262 Clause 9 Safety Element out of Context
5: DIR (Design Interface Report) is a Renesas-specific document equivalent to DIA (Design Interface Agreement)
6: All-pairs testing - Wikipedia
See also:
Renesas Functional Safety Support for Automotive (1) – An overview
Renesas Functional Safety Support for Automotive (2) – A Customizable Option for Precise Safety Analysis