Home Embedded Blog How is Software Verification Performed As Per the ISO 26262 Standard

How is Software Verification Performed As Per the ISO 26262 Standard

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 complaint 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 value.

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 values 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.
  •  
    Table 1

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.

Table 6

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.

Part 8

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.

Learn more about ISO 26262 compliant unit Testing here- ISO 26262 Compliant Unit Testing Strategies: A Step Towards Achieving Functional Safety in Automotive Product Development

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.

  1. The test is carried out according to the software verification plan.
  2. It follows the guidelines described in Part-8 of ISO 26262 standard
  3. 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.

Unit test
  • 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:

  1. Functional Coverage: Shows the completeness of the Function that is being tested.
  2. 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:

  1. Software Verification Plan
  2. Software Architectural Design
  3. Software Verification Report
  4. 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.

This entry was posted in Embedded Blog, Blog by Embitel. Bookmark the permalink

Sep 27 2019
Related Posts

ASK OUR EXPERTS

captcha

FEATURED WHITEPAPER

12 design strategies to develop an "In-Vehicle Infotainment " system

RELATED SERVICES
 

Car HUD (Heads-up Display)

Go-to-market in 6 months with our automotive grade hardware and software design


Automotive Control Units

Electronic Control Units (ECU) development services for Body Control Modules (BCM), Powertrain, Chassis and Infotainment


AUTOSAR Software Services

AUTOSAR MCAL development, RTE and BSW integration, Application Layer development, Tools configuration and code generation


CUSTOMER SUCCESS STORIES
 
J1939-stack

J1939 Stack for advanced EPS system

Find out how J1939 stack resolved on-chip memory issue for an Automotive Tier-I supplier


connected-car

Software re-engineering | Telematics applications

Modular architecture re-design across fleet management product lines - GPS fleet security, vehicle and trailer tracking


IoT

IoT based Home Automation system

Design and development – Sensor Networks, Custom IoT gateway, Cloud and Mobile App