Вы находитесь на странице: 1из 31

IEC Certification Kit Model-Based Design for ISO 26262

R2013a

How to Contact MathWorks www.mathworks.com comp.soft-sys.matlab www.mathworks.com/contact_TS.html suggest@mathworks.com bugs@mathworks.com doc@mathworks.com service@mathworks.com info@mathworks.com Web Newsgroup Technical Support Product enhancement suggestions Bug reports Documentation error reports Order status, license renewals, passcodes Sales, pricing, and general information

508-647-7000 (Phone) 508-647-7001 (Fax) The MathWorks, Inc. 3 Apple Hill Drive Natick, MA 01760-2098
For contact information about worldwide offices, see the MathWorks Web site.

IEC Certification Kit: Model-Based Design for ISO 26262

COPYRIGHT 20112013 by The MathWorks, Inc.


The software described in this document is furnished under a license agreement. The software may be used or copied only under the terms of the license agreement. No part of this manual may be photocopied or reproduced in any form without prior written consent from The MathWorks, Inc. FEDERAL ACQUISITION: This provision applies to all acquisitions of the Program and Documentation by, for, or through the federal government of the United States. By accepting delivery of the Program or Documentation, the government hereby agrees that this software or documentation qualifies as commercial computer software or commercial computer software documentation as such terms are used or defined in FAR 12.212, DFARS Part 227.72, and DFARS 252.227-7014. Accordingly, the terms and conditions of this Agreement and only those rights specified in this Agreement, shall pertain to and govern the use, modification, reproduction, release, performance, display, and disclosure of the Program and Documentation by the federal government (or other entity acquiring for or through the federal government)and shall supersede any conflicting contractual terms or conditions. If this License fails to meet the governments needs or is inconsistent in any respect with federal procurement law, the government agrees to return the Program and Documentation, unused, to The MathWorks, Inc. Trademarks MATLAB and Simulink are registered trademarks of The MathWorks, Inc. See www.mathworks.com/trademarks for a list of additional trademarks. Other product or brand names may be trademarks or registered trademarks of their respective holders. Patents MathWorks products are protected by one or more U.S. patents. Please see www.mathworks.com/patents for more information.

Revision History March 2012 September 2012 March 2013 New for Version 2.1 (Applies to Release 2012a) Revised for Version 3.0 (Applies to Release 2012b) Revised for Version 3.1 (Applies to Release 2013a)

Contents
1 Introduction ...................................................................................................................................... 1-1 1.1 Model-Based Design for ISO 26262 ....................................................................................... 1-2 2 ISO 262626: Applicable Model-Based Design Tools and Processes ............................................. 2-1 2.1 Initiation of Product Development at the Software Level ....................................................... 2-2 Table 1 Topics To Be Covered By Modeling and Coding Guidelines ................................. 2-2 2.2 Software Architectural Design ................................................................................................ 2-3 Table 2 Notations for Software Architectural Design .......................................................... 2-3 Table 3 Principles for Software Architectural Design .......................................................... 2-3 Table 4 Mechanisms for Error Detection at the Software Architectural Level .................... 2-5 Table 5 Mechanisms for Error Handling at the Software Architectural Level ..................... 2-5 Table 6 Methods for Verification of Software Architectural Design ................................... 2-6 2.3 Software Unit Design and Implementation ............................................................................. 2-8 Table 7 Notations for Software Unit Design ........................................................................ 2-8 Table 8 Design Principles for Software Unit Design and Implementation........................... 2-9 Table 9 Methods for Verification of Software Unit Design and Implementation .............. 2-11 2.4 Software Unit Testing ........................................................................................................... 2-14 Table 10 Methods for Software Unit Testing ..................................................................... 2-14 Table 11 Methods for Deriving Test Cases for Software Unit Testing .............................. 2-15 Table 12 Structural Coverage Metrics at the Software Unit Level ..................................... 2-16 2.5 Software Integration and Testing .......................................................................................... 2-17 Table 13 Methods for Software Integration Testing ........................................................... 2-17 Table 14 Methods for Deriving Test Cases for Software Integration Testing .................... 2-19 Table 15 Structural Coverage Metrics at the Software Architectural Level ....................... 2-19 3 ISO 262628: Applicable Model-Based Design Tools and Processes ............................................. 3-1 3.1 Confidence in the Use of Software Tools ................................................................................ 3-2 Table 4 Qualification of Software Tools Classified TCL3 ................................................... 3-2 Table 5 Qualification of Software Tools Classified TCL2 ................................................... 3-3

vi

1 Introduction

1.1 Model-Based Design for ISO 26262


This documentation provides annotated versions of method tables that appear in the ISO 26262 6 and ISO 262628 standards. The annotated tables provide suggestions on how to use ModelBased Design products from MathWorks to apply the methods listed in the standard for different Automotive Safety Integrity Levels (ASILs). The IEC Certification Kit provides additional support when using Model-Based Design for ISO 26262 applications, including reference workflows for verifying and validating models and generated code.

1-2

2 ISO 262626: Applicable ModelBased Design Tools and Processes

2.1 Initiation of Product Development at the Software Level


Table 1 Topics To Be Covered By Modeling and Coding Guidelines
Topics ASIL A 1a 1b 1c 1d Enforcement of low complexity Use of language subsets Enforcement of strong typing Use of defensive implementation techniques Use of established design principles Use of unambiguous graphical representation Use of style guides Use of naming conventions ++ ++ ++ o B ++ ++ ++ + C ++ ++ ++ ++ D ++ ++ ++ ++ Applicable Model-Based Design Tools and Processes Simulink Modeling Guidelines

Comments

1e 1f 1g 1h

+ + + ++

+ ++ ++ ++

+ ++ ++ ++

++ ++ ++ ++

The High Integrity System Modeling Guidelines and the MathWorks Automotive Advisory Board Control Algorithm Modeling Guidelines can be used to address topics listed in this table. The guideline subset used for a project should address a combination of topics applicable for the ASIL under consideration.

2-2

2.2 Software Architectural Design


Table 2 Notations for Software Architectural Design
Methods ASIL A 1a Informal notations ++ B ++ C + D + Applicable Model-Based Design Tools and Processes Simulink Model Info and DocBlock blocks Simulink Verification and Validation System Requirements block Simulink Verification and Validation Requirements Management Interface (RMI) Comments

The blocks can be used to integrate architectural descriptions into a model.

1b

Semiformal notations

++

++

++

Simulink Stateflow

The RMI can be used to link Simulink and Stateflow architectural designs to informal descriptions in Microsoft Word, Microsoft Excel, ASCII text, and PDF files. Simulink and Stateflow support software architectural design using semiformal notations.

1c

Formal notations

Table 3 Principles for Software Architectural Design


Methods ASIL A 1a Hierarchical structure of software components ++ B ++ C ++ D ++ Simulink Model block, Ports & Subsystems block library Stateflow Simulink Model Dependency Viewer Embedded Coder Applicable Model-Based Design Tools and Processes Comments

Model blocks (model referencing), subsystems, libraries, and Stateflow charts support hierarchical decomposition of models. When using Model blocks or libraries to structure a model, the Model Dependency Viewer can display a graph of models and libraries referenced by the top model. Embedded Coder supports modularization of code at the file level.

2-3

Methods

ASIL A B ++ C ++ D ++

Applicable Model-Based Design Tools and Processes Simulink Stateflow Embedded Coder Simulink Verification and Validation ISO 26262 checks Polyspace - Metrics

Comments

1b

Restricted size of software components

++

Software components can be structured hierarchically to limit component size.

1c

Restricted size of interfaces

++

++

++

++

Simulink Verification and Validation ISO 26262 checks

Polyspace - Metrics

ISO 26262 Model Advisor check Display model metrics and complexity report provides information on the size and complexity of models and subsystems. Polyspace Metrics supports the generation of size and complexity metrics for source code. ISO 26262 Model Advisor check Display model metrics and complexity report provides information on the number of inports and outports of models and subsystems. Polyspace Metrics supports the generation of size and complexity metrics for source code.

1d 1e

1f

High cohesion with software components Restricted coupling between software components Appropriate scheduling properties

+ +

+ ++

+ ++

+ ++

++

++

Simulink

Stateflow Scheduler patterns Embedded Coder Configuration

1g

Restricted use of interrupts

++

Simulink provides a way to control the rate of block execution and allows specification of block-based or port based sample times. Models can display color coding and annotations to represent specific sample times. Stateflow provides multiple scheduler patterns for controlling execution of subsystems. Embedded Coder can be configured to not insert interrupts into step function code.

2-4

Table 4 Mechanisms for Error Detection at the Software Architectural Level


Methods ASIL A 1a Range checks of input and output data ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Stateflow Simulink Design Verifier Polyspace Code verification Simulink Stateflow Simulink Stateflow 1d 1e 1f External monitoring facility Control flow monitoring Diverse software design o o o + + o + ++ + ++ ++ ++ Simulink Stateflow Fixed-Point Designer Software diversity for algorithmic parts can be supported by executing floating-point and fixed-point versions of an algorithm in parallel and comparing the results. Comments

Simulink and Stateflow can be used to design range checks for input and output data. During simulation, the Simulation range checking diagnostic detects when signals exceed specified ranges. Simulink Design Verifier and Polyspace can calculate and verify signal ranges. Simulink and Stateflow can be used to design plausibility checks. Simulink and Stateflow can be used to detect data errors.

1b

Plausibility

++

1c

Detection of data errors

++

++

++

++

Table 5 Mechanisms for Error Handling at the Software Architectural Level


Methods ASIL A 1a Static recovery mechanism Graceful degradation Independent parallel redundancy Correcting codes for data + B + C + D + Applicable Model-Based Design Tools and Processes Simulink Stateflow Stateflow Comments

1b 1c 1d

+ o +

+ o +

++ + +

++ ++ +

Simulink and Stateflow can be used to design fault detection, isolation, and recovery (FDIR) algorithms. Stateflow can be used to design graceful degradation behaviour.

2-5

Table 6 Methods for Verification of Software Architectural Design


Methods ASIL A 1a Walkthrough of the design ++ B + C o D o Applicable Model-Based Design Tools and Processes Simulink Simulink Report Generator Web View, System Design Description (SDD) report Simulink Comments

Architectural design walkthroughs can be based on the model, a generated Web View, or an SDD report.

1b

Inspection of the design

++

++

++

Simulink Verification and Validation Model Advisor checks

1c 1d

Simulation of dynamic parts of the design Prototype generation

+ o

+ o

+ +

++ ++

Simulink Simulink Coder Embedded Coder

Simulink 3D Animation Gauges Blockset 1e Formal verification o o + + Simulink Model Verification block library Simulink Design Verifier Property proving, design error detection

Design inspections can be based on the model, a generated Web View, or an SDD report. Design inspections can be supported by ISO 26262, MAAB, Requirements Consistency, and custom Model Advisor checks. A Model Advisor check configuration can define a set of checks required to pass as a prerequisite for entering a design inspection. Simulink supports simulation of algorithm and environment models. Simulink Coder can be used to generate code for rapid prototyping. Embedded Coder can be used to generate code for on-target rapid prototyping. Software-in-the-loop (SIL) and processorin-the-loop (PIL) simulation can be used to execute generated code in the context of a model. Simulink 3D Animation can be used to animate 3-dimensional scenes driven by signals in a model. Gauges Blockset can be used to add graphical instrumentation to models. Model Verification blocks can be used to formalize software safety requirements and other model properties. Property proving can be used to verify model properties. Design error detection can analyze a model to detect design errors that might occur at run time.

2-6

Methods

ASIL A B C D

Applicable Model-Based Design Tools and Processes Polyspace Code verification

Comments

1f

Control flow analysis

++

++

Simulink Verification and Validation Model coverage analysis Simulink Design Verifier Test case generation Polyspace Call tree, unreachable code analysis Simulink Diagnostics Stateflow Diagnostics Polyspace Variable access pane, generated Excel report, code verification

Polyspace - can analyze C code to identify software errors that might occur during run time. Model coverage analysis can help identify unreachable portions of a model. Automatic test case generation can be used to detect unreachable model constructs, which could result in unreachable code. Polyspace can extract control flow information at the function level from C code and create an application call tree. Gray checks detect unreachable code. Data Store Memory block diagnostics and Stateflow diagnostics can be configured to identify data flow issues. Polyspace supports static verification of dynamic properties of generated code. This verification technique is based on data flow analysis. The variable access pane displays the following information about each global variable: number of read and write access operations, location of read and write operations, detailed type value ranges for individual read and write access operations, whether or not it shared, whether shared access is protected (critical section). This information is also accessible in the generated Excel report.

1g

Data flow analysis

++

++

2-7

2.3 Software Unit Design and Implementation


Table 7 Notations for Software Unit Design
Methods ASIL A 1a Natural language ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Model Info block, DocBlock block Simulink Verification and Validation System Requirements block Simulink Verification and Validation Requirements Management Interface (RMI) Simulink Model Info block, DocBlock block Simulink Verification and Validation System Requirements block Simulink Verification and Validation Requirements Management Interface (RMI) 1c Semiformal notations + ++ ++ ++ Simulink Stateflow 1d Formal notations + + + + Comments

The blocks can be used to add natural language or descriptions of a unit design to a model.

1b

Informal notations

++

++

++

Models representing unit designs can be linked to descriptions in Microsoft Word, Microsoft Excel, ASCII text, or PDF files. The blocks can be used to add informal descriptions of a unit design to a model.

The RMI can be used to link models representing unit designs to external informal descriptions in Microsoft Word, Microsoft Excel, ASCII text, or PDF files. Simulink and Stateflow support software unit design, using semiformal notations.

2-8

Table 8 Design Principles for Software Unit Design and Implementation


Methods ASIL A 1a One entry and one exit point in subprograms and functions ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Modeling guidelines Comments

Polyspace MISRAC checker 1b No dynamic objects or variables, or else online test during their creation + ++ ++ ++ Embedded Coder Configuration Polyspace MISRAC checker Simulink IC block, diagnostics

Adherence can be facilitated by applying modeling guidelines in combination with analyzing generated code. MAAB guideline jc_0511 provides corresponding modeling recommendations. Polyspace can assess compliance with MISRAC:2004 rule 14.7. Embedded Coder can be configured to generate C code that does not include dynamic objects. Polyspace can assess compliance with MISRAC:2004 rule 20.4. An IC block can specify the initial condition for a signal. Setting the Underspecified initialization detection diagnostic to Simplified improves consistency of simulation results for models that do not specify initial conditions for conditional subsystem output ports or have conditionally executed subsystem output ports connected to S-functions. Parameters in the Optimization > Data initialization section of the Configuration Parameters dialog box can be used to control initialization of variables in generated code. Polyspace can check the initialization of variables in generated code. Uninitialized variables are reported as NIV checks. Setting the Duplicate data store names diagnostic to error detects conditions where a lower-level data store unexpectedly shadows a higher-level data store with the same name.

1c

Initialization of variables

++

++

++

++

Embedded Coder Configuration

Polyspace Code verification

1d

No multiple use of variable names

++

++

++

Simulink Diagnostics

2-9

Methods

ASIL A B + C ++ D ++

Applicable Model-Based Design Tools and Processes Simulink Embedded Coder Configuration Polyspace Variable access pane, generated Excel report, MISRA C checker

Comments

1e

Avoid global variables or else justify their usage

Usage of Data Store Memory blocks needs to be reviewed and justified. Selecting the Enable local block outputs optimization reduces use of global variables in generated code. The variable access pane displays the following information about each global variable: number of read and write access operations, location of read and write operations, detailed type value ranges for individual read and write access operations, whether or not it shared, whether shared access is protected (critical section). This information is also accessible in the generated Polyspace can assess compliance with MISRA-C:2004 rules 8.11 and 8.7 to help detect variables with scopes that should not be global. Embedded Coder may generate pointer arithmetic for certain language features for example, lookup tables or matrix multiplication. Embedded Coder checks the data type and range of values to avoid corruption of address spaces. Polyspace can assess compliance with MISRAC:2004 rules 11.1 to 11.5 and 17.3 to 17.5, which restrict use of pointers. Polyspace can check whether pointers refer to valid objects. Violations are reported as IDP checks. MISRA-C:2004 contains rules that facilitate the use of established design principles. Polyspace can assess compliance with MISRA-C:2004 rules 11.1, 11.2, 11.3, and 11.5. Polyspace can assess compliance with MISRA-C:2004 rule 5.2. Polyspace can assess compliance with MISRAC:2004 rules 14.4 and 14.5.

1f

Limited use of pointers

++

++

Embedded Coder Configuration

Polyspace MISRAC checker, code verification

1g

No implicit data type conversions

++

++

++

Polyspace MISRA C checker

1h 1i

No hidden data flow or control flow No unconditional jumps

+ ++

++ ++

++ ++

++ ++

Polyspace MISRA C checker Polyspace MISRAC checker

2-10

Methods

ASIL A B + C ++ D ++

Applicable Model-Based Design Tools and Processes Simulink Modeling guidelines

Comments

1j

No recursions

Polyspace Call tree

Adherence can be facilitated by applying modeling guidelines. High-integrity guideline hisf_0004 Provides corresponding modeling recommendations. Avoid using n-D Lookup Table and Interpolation blocks and Prelookup blocks with dimensions > 5. Generated call trees can be reviewed to identify recursive function calls.

Table 9 Methods for Verification of Software Unit Design and Implementation


Methods ASIL A 1a Walkthrough ++ B + C o D o Applicable Model-Based Design Tools and Processes Simulink Simulink Report Generator Web View, System Design Description (SDD) report Embedded Coder Code generation report Comments

Unit design walkthroughs can be based on a model, a generated Web View, or an SDD report.

1b

Inspection

++

++

++

Simulink Simulink Report Generator Web View, System Design Description (SDD) report Simulink Verification and Validation Model Advisor checks

Code walkthroughs can be based on HTML code generation reports or code Generation reports with an integrated Web View of the model. Unit design inspections can be based on a model, a generated Web View, or an SDD report.

Embedded Coder Code generation report IEC Certification Kit Traceability matrix

Unit design inspections can be supported by ISO 26262, MAAB, Requirements Consistency, and custom checks in Model Advisor. A Model Advisor check configuration can define a set of checks to pass as a prerequisite for entering model inspection. Code walkthroughs can be based on HTML code generation reports, code Generation reports with an integrated Web View of the model, or model-to-code and code-to-model traceability matrices.

2-11

Methods

ASIL A B + o C ++ + D ++ +

Applicable Model-Based Design Tools and Processes Simulink Simulink Model Verification blocks Simulink Design Verifier Property proving, design error detection, test case generation Polyspace Code verification

Comments

1c 1d

Semiformal verification Formal verification

+ o

Simulink supports simulation of algorithm and environment models. Model Verification blocks can be used to formalize software safety requirements and other model properties. Property proving can be used to verify model properties using formal verification techniques. Design error detection can analyze a model to detect design errors that might occur at run time. Runtime error detection can analyze C code to identify software errors that might occur during run time. Model coverage analysis can help to identify unreachable portions of a model. Automatic test case generation can be used to detect unreachable model constructs that could result in unreachable code. Polyspace can extract control flow information at the function level from C code and create an application call tree. Gray checks detect unreachable code. Data Store Memory block diagnostics and Stateflow diagnostics can be configured to identify data flow issues. Polyspace supports static verification of dynamic properties of generated code. This verification technique is based on data flow analysis. Polyspace can facilitate static analysis of C code.

1e

Control flow analysis

++

++

Simulink Verification and Validation Model coverage analysis Simulink Design Verifier Test case generation Polyspace Call tree, unreachable code analysis Simulink Diagnostics Stateflow Diagnostics Polyspace Code verification

1f

Data flow analysis

++

++

1g

Static code analysis

++

++

++

Polyspace MISRAC checker, metrics

2-12

Methods

ASIL A B + C + D +

Applicable Model-Based Design Tools and Processes Polyspace Code verification, variable access pane, generated Excel report

Comments

1h

Semantic code analysis

Polyspace uses abstract interpretation to analyze C code. The variable access pane displays the following information about each global variable: number of read and write access operations, location of read and write operations, detailed type value ranges for individual read and write access operations, whether or not it shared, whether shared access is protected (critical section). This information is also accessible in the generated Excel report.

Clause 8.4.5 The software unit design and implementation shall be verified in accordance with ISO 262628:2011 Clause 9, and by applying the verification methods listed in Table 9 to demonstrate: ... the fulfillment of the software safety requirements as allocated to the software units (in accordance with 7.4.9) through traceability ...

Model-Based Design Tools and Processes

Comments

b)

IEC Certification Kit Traceability matrix

Generated traceability matrices can be used to document and review existing links between textual requirements, models, and generated code.

2-13

2.4 Software Unit Testing


Table 10 Methods for Software Unit Testing
Methods ASIL A 1a Requirements-based test ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Verification and Validation Requirements Management Interface (RMI) IEC Certification Kit Traceability matrix Simulink Signal Builder block Stateflow Dynamic test vector charts Simulink Verification and Validation Component testing capabilities Simulink Design Verifier Test case generation Simulink Stateflow Comments

RMI can be used to establish bidirectional links between textual requirements and models. Generated traceability matrices can be used to document and review existing links between textual requirements, models, and code. Signal Builder blocks can be used to create open-loop model tests. Dynamic test vector charts can be used to create closed-loop, reactive model tests. Component testing capabilities can be used to create model test harnesses. They also enable a requirements pane in the Signal Builder that can be used to link tests with textual requirements. Automatic test case generation in combination with Test Objective blocks can be used to generate interface tests. Simulink and Stateflow can be used to carry out fault injection tests. The tools can also be used to simulate failure propagation at the model level. For this purpose, the system model and a separate failure model can be used. Automatic test case generation in combination with Test Objective blocks can be used to generate fault injection tests. PIL testing analyzes resource utilization on a target processor. The code metrics report provides the amount of memory used by the generated code.

1b

Interface test

++

++

++

++

1c

Fault injection test

++

Simulink Design Verifier Test case generation Embedded Coder Processorin-the-loop (PIL) testing, code metrics report

1d

Resource usage test

++

2-14

Methods

ASIL A B + C ++ D ++

Applicable Model-Based Design Tools and Processes Simulink Stateflow Simulink Verification and Validation Component testing capabilities, model coverage Simulink Design Verifier Test case generation Embedded Coder Softwarein-the-loop (SIL) testing, processor-in-the-loop testing, code generation verification (CGV) Simulink Simulation Data Inspector (SDI)

Comments

1e

Back-to-back test between model and code, if applicable

Simulation capabilities of Simulink and Stateflow and the component test capabilities of Simulink Verification and Validation facilitate dynamic testing of models. Model coverage can be used to assess the completeness of the model tests. Simulink Design Verifier can generate missing test cases. SIL and PIL testing provide a way to execute model tests on generated code. CGV automates selected back-to-back testing workflows. SDI supports the comparison of test results created during back-to-back testing.

Table 11 Methods for Deriving Test Cases for Software Unit Testing
Methods ASIL A 1a Analysis of requirements ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Verification and Validation Component testing capabilities Simulink Design Verifier Test case generation Comments

1b

Generation and analysis of equivalence classes

++

++

++

1c

Analysis of boundary values

++

++

++

Simulink Design Verifier Test case generation

Component testing capabilities can be used to create model test harnesses. They also enable a requirements pane in the Signal Builder that can be used to link tests with textual requirements. The analysis of equivalence classes can be based on the interfaces of the model. Automatic test case generation in combination with Test Objective blocks can be used to generate test cases and test sequences for given equivalence classes. The analysis of boundary values can be based on the interfaces of the model. Automatic test case generation in combination with Test Objective blocks can be used to generate test cases and test sequences for given boundary values.

1d

Error guessing

2-15

Table 12 Structural Coverage Metrics at the Software Unit Level


Methods ASIL A 1a Statement coverage ++ B ++ C + D + Applicable Model-Based Design Tools and Processes Embedded Coder Code coverage collection Comments

1b

Branch coverage

++

++

++

Simulink Verification and Validation Model coverage analysis Simulink Design Verifier Test case generation Embedded Coder Code coverage collection

1c

MC/DC (Modified Condition/Decision Coverage)

++

Simulink Verification and Validation Model coverage analysis Simulink Design Verifier Test case generation Embedded Coder Code coverage collection

During software-in-the-loop (SIL) simulation, Embedded Coder can collect statement coverage by using the third-party tool LDRA Testbed. During SIL simulation, Embedded Coder can collect condition/decision coverage information, which usually subsumes statement coverage, by using the thirdparty tool BullseyeCoverage. During model testing, Simulink Verification and Validation can collect decision coverage (also known as branch coverage) at the model level. Simulink Design Verifier can generate test cases that satisfy decision coverage at the model level. During software-in-the-loop (SIL) simulation, Embedded Coder can collect statement coverage by using the third-party tool LDRA Testbed. During SIL simulation, Embedded Coder can collect condition and decision coverage, which usually subsumes statement coverage, by using the thirdparty tool BullseyeCoverage. During model testing, Simulink Verification and Validation verification can collect MC/DC coverage at the model level. Simulink Design Verifier can be used to generate test cases that satisfy MC/DC coverage at the model level. During SIL simulation, Embedded Coder can collect MC/DC coverage by using the third-party tool LDRA Testbed.

2-16

2.5 Software Integration and Testing


Table 13 Methods for Software Integration Testing
Methods ASIL A 1a Requirements-based test + B + C + D + Applicable Model-Based Design Tools and Processes Simulink Verification and Validation Requirements Management Interface (RMI) IEC Certification Kit Traceability matrix Comments

RMI can be used to establish bidirectional links between textual requirements and models. Generated traceability matrices can be used to document and review existing links between textual requirements, models, and code. The Signal Builder block can be used to create open-loop model tests. Dynamic test vector charts can be used to create closed-loop, reactive model tests. Component testing capabilities can be used to create model test harnesses. They also enable a requirements pane in the Signal Builder, which can be used to link tests with textual requirements. Automatic test case generation in combination with Test Objective blocks can generate fault injection tests. Simulink and Stateflow can be used to execute fault injection tests. Can also simulate failure propagation at the model level. For this purpose, a system model and/or a separate failure model can be used. Automatic test case generation in combination with Test Objective blocks can generate fault injection tests. PIL testing analyzes resource utilization on a target processor. The code metrics report provides information about memory usage of generated code.

Simulink Signal Builder block Stateflow Dynamic test vector charts Simulink Verification and Validation Component testing capabilities Simulink Design Verifier Test case generation Simulink Stateflow Simulink Design Verifier Test case generation 1d Resource usage test + + + ++ Embedded Coder Processorin-the-loop (PIL) testing, code metrics report

1b

Interface test

++

++

++

++

1c

Fault infection test

++

++

2-17

Methods

ASIL A B + C ++ D ++

Applicable Model-Based Design Tools and Processes Simulink Stateflow

Comments

1e

Back-to-back test between model and code, if applicable

Simulation capabilities of Simulink and Stateflow and the component test capabilities of Simulink Verification and Validation facilitate dynamic model testing. Model coverage can assess the completeness of model tests. Simulink Design Verifier can generate missing test cases.

Simulink Verification and Validation Component testing capabilities, model coverage Simulink Design Verifier Test case generation Embedded Coder Softwarein-the-loop (SIL) testing, processor-in-the-loop (PIL) testing, code generation verification (CGV) Simulink Simulation Data Inspector (SDI)

SIL and PIL testing capabilities execute model tests on generated code. CGV can automate selected back-to-back testing workflows. SDI supports comparison of test results created during back-to-back testing.

2-18

Table 14 Methods for Deriving Test Cases for Software Integration Testing
Methods ASIL A 1a Analysis of requirements ++ B ++ C ++ D ++ Applicable Model-Based Design Tools and Processes Simulink Verification and Validation Component testing capabilities Simulink Design Verifier Test case generation Comments

1b

Generation and analysis of equivalence classes

++

++

++

1c

Analysis of boundary values

++

++

++

Simulink Design Verifier Test case generation

Component testing capabilities can be used to create model test harnesses. They also enable a requirements pane in the Signal Builder that can be used to link tests with textual requirements. The analysis of equivalence classes can be based on the interfaces of the model. Automatic test case generation in combination with Test Objective blocks can be used to generate test cases and test sequences for given equivalence classes. The analysis of boundary values can be based on the interfaces of the model. Automatic test case generation in combination with Test Objective blocks can be used to generate test cases and test sequences for given boundary values.

1d

Error guessing

Table 15 Structural Coverage Metrics at the Software Architectural Level


Methods ASIL A 1a Function coverage + B + C ++ D ++ Applicable Model-Based Design Tools and Processes Embedded Coder Code coverage collection Embedded Coder Code coverage collection Comments

1b

Call coverage

++

++

During SIL simulation, Embedded Coder can collect function coverage information by using the third-party tool BullseyeCoverage. During SIL simulation, Embedded Coder can collect procedure/function call coverage information by using the thirdparty tool LDRA Testbed.

2-19

2-20

3 ISO 262628: Applicable ModelBased Design Tools and Processes

3.1 Confidence in the Use of Software Tools


Table 4 Qualification of Software Tools Classified TCL3
Methods ASIL A 1a Increased confidence from use in accordance with 11.4.7 Evaluation of the tool development process in accordance with 11.4.8 Validation of the software tool in accordance with 11.4.9 ++ B ++ C + D + Applicable Model-Based Design Tools and Processes Comments

1b

++

++

IEC Certification Kit - ISO 26262 Tool Qualification Kits

1c

++

Embedded Coder, Simulink Verification and Validation, Simulink Design Verifier, and Polyspace products for C/C++ have been prequalified, using a combination of methods 1b and 1c. TV SD carried out an independent tool qualification assessment. The IEC Certification Kit provides Software Tool Criteria Evaluation reports, Software Tool Qualification reports, and evidence for the independent assessment. The IEC Certification Kit provides exemplary test cases and test procedures for Embedded Coder, Simulink Verification and Validation, and Polyspace products for C/C++ that can be used to facilitate tool validation tests for these products.

1d

Development in accordance with a safety standard

++

3-2

Table 5 Qualification of Software Tools Classified TCL2


Methods ASIL A 1a Increased confidence from use in accordance with 11.4.7 Evaluation of the tool development process in accordance with 11.4.8 Validation of the software tool in accordance with 11.4.9 ++ B ++ C ++ D + Applicable Model-Based Design Tools and Processes Comments

1b

++

++

++

IEC Certification Kit- ISO 26262 Tool Qualification Kits

1c

++

Embedded, Simulink Verification and Validation, Simulink Design Verifier, and Polyspace products for C/C++ have been prequalified, using a combination of methods 1b and 1c. TV SD carried out an independent tool qualification assessment. The IEC Certification Kit provides Software Tool Criteria Evaluation reports, Software Tool Qualification reports, and evidence for the independent assessment. The IEC Certification Kit provides exemplary test cases and test procedures for Embedded Coder, Simulink Verification and Validation, and Polyspace products for C/C++ that can be used to facilitate tool validation tests for these products.

1d

Development in accordance with a safety standard

++

3-3

Вам также может понравиться