The Pre-lude:
The Part-6 of ISO 26262 standard enlists the guidelines for product development at the software level. It also has a clear and specific take on software verification and validation process.
In addition to the part-6, the Part-8 of the ISO 26262 Standard also has a separate clause that talks about the software verification in general.
When a verification strategy is planned for the ISO 26262 compliant software, recommendations from both the parts are considered.
After completing the process of HARA (Hardware and Risk Analysis), your Functional Safety (FuSa) Consultants are armed with the following necessary information:
- The safety goals,
- Functional Safety (FuSa) concept document
- ASIL grade.
With all this information under the sleeves, the stage gets set to kick-start the ISO 26262 compliant software development process!
Shifting Gears: Understanding the Omnipresence of Software Verification in the V-Cycle
In the V-Cycle model for software development, software verification is performed at every stage of development.
If you look at the V-model, you can find that the arrows connecting the two hands of V-model are bi-directional.
Unit testing corresponds to the software implementation, Integration test is done against the High Level Design and so on.
This is done to achieve bi-directional traceability, which is of utmost importance in the context of ISO 26262 compliant software development. We will talk about traceability later in the blog.
Talking of ISO 26262 compliant software verification, it is quite like traditional software verification processes. However, there are certain guidelines that need to be followed depending on the ASIL grades assigned to the software.
These guidelines not only consist of the recommendation for the methods to be deployed for verification, but also the verification strategy.
Let’s understand this process in detail!
Designing the Software Verification Plan
The test phase of software development lifecycle is defined in Part 6.9- Unit Testing, 6.10- Integration Testing and 6.11- Verification of Software Safety Requirements.
Before this test phase is kick-started, the software verification plan has to be in place. This plan is one of the work-products of the activities that are listed in the phase called the Initiation of Product Development at Software Level
The following considerations are necessary for designing the verification plan:
- Activities involved in software development and the methods chosen to perform them. For instance, a software module development can be an activity and Model Based Development can be the chosen method to perform it.
- The product development lifecycle- that may also be altered according to Part-2 of the standard- Management of Functional Safety
- Whether the software is configurable; if yes, other considerations may come into picture
- Methods, programming language, development tools etc. should be consistent across the different phases and sub-phases of the product development lifecycle.
Following these considerations, a software verification plan is created as a work-product.
The next step is to fine-tune this software verification plan.
After the initiation of the software development lifecycle, the software safety requirements are specified. During this phase, a refined version of software verification plan is generated as a work product.
This refined software verification plan is used as an input(among other inputs) to the software architectural design. This is important because, this design is also to be verified as per the software verification plan.
The following methods can be used for the purpose.
After the verification of the software architectural design, a verification report is generated as a work product. This report is one of the evidences presented to prove the ISO 26262 compliance.
Verification of Software Units: An Important Objective of Software Unit Design and Implementation
As per the product development lifecycle, post the design of the software architecture, the Software Unit Design and Implementation process is started. And verification of the software modules (that have been developed), is one of the three objectives of this phase.
As you have been noticing, the work products of the preceding step serve as the input for the next steps. Likewise, during the verification of software units, the inputs are as follows:
- Software Verification Plan (Fine-tuned during specifying software safety requirement)
- Software Verification Report (Work Product of Software Architectural Design)
The following table lists the Methods of Verification. The process of verification is as per Part-8 of ISO 26262 standard.
At this stage of Product Development Lifecycle, the software unit design is ready to be implemented.
But wait! The software unit now has to go through the rigorous testing processes that comprise Unit Testing, Integration Testing and finally, the verification of software safety Requirement.
The V-Model ensures that each of these tests are performed against their left-hand side counterparts. For instance, Unit Test can be traced to Software Unit Design, Integration to Software Architectural Design and so on.
Understanding Unit, Integration Test and SSR verification Recommended by ISO 26262
The ISO 26262 compliant unit test is quite similar to the regular unit testing. The key difference is that it takes into consideration the software verification plan and report.
Let’s now move on to the Software Integration Test. The main goal of this phase of testing is to ensure that the software architectural design is fully realized by the developed software.
Details of ISO 26262 Compliant Software Integration Testing
We will not go into the detail of integration testing as it is similar for all software. However, we will try to identify to certain guidelines that ISO 26262 compliant integration testing process is mandated to follow.
- The test is carried out according to the software verification plan.
- It follows the guidelines described in Part-8 of ISO 26262 standard
- The test objects in Integration testing are the software components
In addition to these recommendations, the methods for integration testing is also specified in the standard. These methods are similar for both Unit test as well.
- Requirement-based Test: It that the software requirements specified at the architectural level is met by the software.
- Interface Test: Interface of one software unit with others is very important and this test ensures that the interfaces are devoid of any errors
- Fault Injection Test: Arbitrary faults are injected to the software, for instance, corrupting the values of CPU registers, introducing code mutations etc. The software must exhibit intended behavior at such instances.
- Resource Usage Test: Ensures that the software being tested does not eat up CPU resources which is more than accepted value. Some aspects of this test are performed during system testing (HIL).
- Back to back Comparison Test: This test comes into picture, when software is being developed using Model Based Development method. The model and code are simulated in a similar way and result is compared.
Are we finally done with the tests here? Apparently No!
Performing all these tests is not enough when it comes to ISO 26262 compliance. In order to evaluate whether these tests have been performed appropriately, some metrics are used.
We call them, Structural Coverage Metrics! Let’s understand them in brief.
There are 2 types of structural coverage metrics:
- Functional Coverage: Shows the completeness of the Function that is being tested.
- Call Coverage: Shows the percentage of software function calls that are executed. Each function call is executed at least once.
These coverages come under dynamic code analysis and can be performed by tools like CANTATA and RTRT.
And now, we finally, come to the last phase of verification, the Verification of Software Safety Requirement.
Details of the ISO 26262 Compliant Verification of Software Safety Requirement.
The objective of this step is to ensure that the software is able to fulfill the software safety requirements as specified during Software Architectural Design.
The Inputs to this sub-phase of verification are:
- Software Verification Plan
- Software Architectural Design
- Software Verification Report
- Safety Plan
And a few supporting information.
The process of verification also involves Hardware-in-Loop Testing, in-vehicle network environment and vehicle environment.
In essence, the test bench that is created for verification needs to include fully or partially integrated vehicle electric system or simulation vehicles.
Conclusion
The stringent verification guidelines recommended in ISO 26262 standard may seem exhaustive, but it is extremely important when it comes to the safety of vehicle and passengers.
Partnering with an expert Functional Safety Consulting team can prove to be a great value-add in achieving the Software Verification objectives in an efficient and cost-effective manner.
