Академический Документы
Профессиональный Документы
Культура Документы
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.
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-2
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
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
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
++
1c
++
++
++
++
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
1g
++
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
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
++
++
++
++
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
Architectural design walkthroughs can be based on the model, a generated Web View, or an SDD report.
1b
++
++
++
1c 1d
+ o
+ o
+ +
++ ++
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
Comments
1f
++
++
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
++
++
2-7
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
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
++
++
++
++
1d
++
++
++
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
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
++
++
1g
++
++
++
1h 1i
+ ++
++ ++
++ ++
++ ++
2-10
Methods
ASIL A B + C ++ D ++
Comments
1j
No recursions
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.
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
+ 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
++
++
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
++
++
1g
++
++
++
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
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 ...
Comments
b)
Generated traceability matrices can be used to document and review existing links between textual requirements, models, and generated code.
2-13
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
++
Simulink Design Verifier Test case generation Embedded Coder Processorin-the-loop (PIL) testing, code metrics report
1d
++
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
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
++
++
++
1c
++
++
++
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
1b
Branch coverage
++
++
++
Simulink Verification and Validation Model coverage analysis Simulink Design Verifier Test case generation Embedded Coder Code coverage collection
1c
++
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
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
++
++
2-17
Methods
ASIL A B + C ++ D ++
Comments
1e
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
++
++
++
1c
++
++
++
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
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
1b
++
++
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
++
3-2
1b
++
++
++
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
++
3-3