ISO26262 & Model Based Design: A Match Made in Heaven?

ISO26262 & Model Based Design: A Match Made in Heaven?

A majority of components in an automobile are gradually coming under the purview of safety-relevant systems. Some of these include the Body Control Module, Powertrain, Power Steering, Battery Management System and so on..

Safety brings with it, higher degree of complexity and in turn, heavier and complicated source code. Manual coding of such complex system is not feasible, given the time and cost constraints. And the fact that competitors are racing against time to be the first to introduce a cutting-edge functionality, makes it even more important for development activities to move at an accelerated pace.

Model Based Design, that has revolutionized system development approach in several engineering domains, plays a significant role on this front.

Developing an ISO 26262 compliant software entails compliance demonstration through evidences (work-products, Test Reports from ISO 26262 Qualified tools and more). When you deploy the MBD approach of development, many of these issues are managed viz a viz verification and validation at earlier stages, back-to-back tests between code and model, tool qualification, etc.

So, does this qualify ISO 26262 and Model Based Design paradigm to be a match ‘’made in heaven’’? Let’s find out!

Finding Model Based Development Approach in ISO 26262 Standard Document

As one would imagine, MBD finds a mention in Part-6 of the ISO 26262 standard. Part-6 deals with Product Development at the software level and it is natural that MBD is dealt with in detail here.

Right from the Software Safety Requirements to verification of software architectural design and beyond, Model Based Development is included as a special case.

Sample this: In the software architecture design verification part, it is specifically mentioned that the testing methods mentioned in Table-6 are to be applied to the model in case of MBD approach.

While we go through the document, we find that MBD is deeply rooted in ISO 26262. Moreover, the extensive V&V (verification and validation) that ISO 26262 mandates, appears easier when we follow the MBD paradigm of software development.

Part-6 also has a separate annexure that talks specifically about Model Based Design and highlights its difference with the manual coding technique. The mere presence of a section dedicated to MBD is a testament to the fact that MBD and ISO 26262 get along very well together. And as the complexity of the automotive system grows, the collaboration will be at a more granular level.

Following notes from Part-6 will help in making the MBD-ISO 26262 relations clear:

1. In the case of model-based development, modelling the structure is an inherent part of the overall modelling activities
2. If model-based development with automatic code generation is used, the implementation related properties apply to the model and need not apply to the source code.
3. In the case of model-based development with automatic code generation, the methods for representing the software unit design are applied to the model which serves as the basis for the code generation.
4. In the case of model-based software development the software unit specification design and implementation can be verified at the model level.
5. For model-based software development, the corresponding parts of the implementation model also represent objects for the test planning.
6. In the case of model-based development, the analysis of structural coverage can be performed at the model level using analogous structural coverage metrics for models.
7. For model-based development, software unit testing can be carried out at the model level followed by back-to back comparison tests between the model and the object code.
8. For model-based development, the software integration can be replaced with integration at the model level and subsequent automatic code generation from the integrated model.
9. For model-based development, the test objects can be the models associated with the software components
10. In the case of model-based development, software architecture testing can be performed at the model level using analogous structural coverage metrics for models.

Source: ISO 26262 Standard Document: 2011

Looking closely at these notes, it can be easily deduced that models have been considered as the reference for unit and integration testing. The testing process is strengthened by performing back-to-back tests between the model and the generated code.

Now, that we have a fair understanding of how ISO 26262 and MBD get along, let’s shift our focus on the MBD based Reference workflow.

What is MBD Based Reference Workflow for ISO 26262 Compliant Development?

MBD based safety related software development requires additional V&V requirements to be fulfilled when compared to non-MBD software development. Therefore, a reference workflow that considers the MBD specific notes (mentioned earlier) as well as the best practices, has been created.

Such a workflow can aid in meeting the safety requirements as prescribed in ISO 26262 standard. It does so by addressing the design and implementation together with the required tests and verifications.

The models are created based on the requirements as per the ISO 26262 modelling guidelines. Models are verified against the requirements (Model-in-Loop Testing). Next, the code is generated as per the coding guidelines. Once the code is generated, it is verified against the model (Processor-in-Loop Testing). Both MIL and PIL gives the measurement of structural coverage (code coverage).

How Does the MBD Based Reference Workflow Help?

• It describes MBD approach including model based testing and auto-code generation from the models.
• The workflow highlights the stages at which the ISO 26262 guidelines need to be applied for testing.
• Verification of the auto-generated C code is demonstrated by back-to-back testing.
• The workflow also has a document list that comprises tables with methods and measures recommended by ISO 26262 and the simulations and code coverages at code and model level.

 

Traditional Development of ISO 26262 Compliant Software	MBD approach of ISO 26262 compliant software
For an ASIL D compliant development, all Test methods are difficult to be covered.	Methods like I/O range checks, prototype generation, etc. can be covered using MBD approach
Simulation of dynamic parts is highly recommended in Table 6.	Simulation is at the core of MBD
Despite traditional tools providing automation, manual effort is still required	MBD tools support several of the methods mandated by standard; thus, the reduce manual effort

A V-Cycle Perspective of the MBD Based Reference Workflow for ASIL Compliance

Implementation of ISO26262 using Model Based Development can be ensured by aligning MBD workflow with existing software development workflow.

On the right-hand side of the V cycle following checks can be performed for ISO62626 based MBD.

• Requirement Traceability:
  • Requirement Traceability is being able to track the life of a requirement from its conception to realization.
  • The developer must ensure Bi-directional Traceability (both forward and backward) of the requirements implemented as a model and link them to designs, code, and tests.
  • This will help the user to assess project completeness & support for industry standards.
  • Any unintended behavior of the system can be prevented if Requirement Traceability is followed.

 

• Model Compliance Check
  • Executable model needs to be verified against multiple checks.
  • Once the model is implemented, one should check model’s architecture and compliance to different standards like DO-178, ISO 26262, IEC 61508, IEC 62304, MAAB Style Guidelines, MISRA C, etc.
  • These compliance checks enable you to replace duplicate design elements, reduce design complexity and identify reusable content.

   

  Errors in Design

  • Hidden design errors must be identified in your models that might get missed during simulation testing. This includes errors like detecting blocks in the model that result in integer overflow, dead logic, array access violations, division by zero, etc.
  • The developer should generate appropriate number of test cases for such errors to identify & fix the issue in design phase.

   

  Coverage Check

  • Additional test cases need to be generated which will be useful to run the model to satisfy CC (condition), DC (decision), & MCDC (modified condition/decision) and relational boundary coverage.
  • This will help to assess the effectiveness of simulation testing in models, software-in-loop (SIL) and processor-in-loop (PIL). You can use missing coverage data to find gaps in testing, missing requirements or unintended functionality.

   

  Fixed Point Data Errors

  • If the model is using fixed point data, it should be ensured that all fixed-point and floating-point data types and target-specific numeric setting meet numerical accuracy requirements and target hardware constraints.
  • Test and debug quantization effects such as overflows and precision loss before implementing the design on hardware.

  Once the model is ready with all possible checks done, one can move towards the left-hand side of the V cycle.

  Following checks can be performed on the left-hand side of V cycle on the generated code.

   

  Traceability

  • Code can be checked against requirement traceability using traceability report generated by code generation tool.

   

  Static Code Analysis

  • Identify run-time errors, concurrency issues, security vulnerabilities, overflow, divide-by-zero, out-of-bounds array access in the C code generated form model.
  • This is possible by performing static analysis and semantic analysis. One should also perform analyses of software control, data flow and inter-procedural behavior. Find the bugs and fix them.
  • These code verification results can be used to track quality metrics and check conformance with software quality objectives.

   

  Code testing

  Generated code must be tested in both standalone and integrated environment to ensure that there are no errors or differences in the obtained results and coverages compared to the results/coverages obtained in virtual testing.

Value-Add of Integrating MBD Methodology in ISO 26262 Compliance Development

• Most of the processes and steps to check safety standard compliance can be automated using standard tools available in the market.
• Due to this possibility of automation, overall process becomes efficient and quite accurate.
• This also offers an edge over competition when it comes to making your presence felt in the market.

Final Remarks

The future of Automotive Technology belongs to Automated Driving, Electric Vehicles and Telematics. Safety compliance as well as complexity aspects of these systems point towards a closer collaboration of model-based design approach and ISO 26262. And when you consider the value-adds of this integration, you have a winner!

Watch this space for more such insights on ISO 26262 as well as model based development of automotive applications.

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