個人主頁：云納星辰懷自在
座右銘：“所謂堅持，就是覺得還有希望！”
本文為基于ISO26262軟件驗證計劃模板，僅供參考。
軟件驗證計劃，包括：
1. 軟件需求驗證計劃
2. 軟件架構設計驗證計劃
3. 軟件單元設計驗證計劃
4. 軟件單元驗證計劃
1. General
This document is linked to the Project plan (safety plan) of <PrjName>. The verification is carried out in the following different forms:
In the design phases, verification implies the evaluation of the work products of each phase to ensure that they comply with the requirement set out in the previous phase for correctness, completeness and consistency.
In the test phases, verification implies the evaluation of work products of a particular phase within a test environment to ensure that they comply with the requirements set out at that particular phase.
1.1 Purpose
This document outlines the verification activities and the processes used to demonstrate that <PrjName> fulfils ISO26262.
The Software verification plan aims to:
- Verify that the defined software requirements are fulfilled.
- Clarify the test strategy and test planning for software test.
1.2 Scope
The scope of this document is limited to specification of software verification activities for <PrjName>.
The specification considers the software test objectives, how to make software test plan considering test strategy to carry out software test performance and finally document within test report.
The specification considers the software test strategy and test method.
1.3 Audience
This document is only for used by the staffs and managed within XX. Anyone shall be forbidden to distribute it outside without the written permission from XX.
Copyright ? XXX Co., Ltd. 2021.
1.4 Reference Document
Table 1 Associated Regulations
| ID | Associated Regulations |
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 |
Table 2 Associated Standards
| ID | Associated Standards |
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 |
Table 3 Associated Documentations
| ID | Document ID | Ver. | Author |
| 1 | <XX-SUP-P1T001_XXX-Quality Assurance Plan> | ||
| 2 | <XX-SW-R0T001-SOR_Basic Software Requirement> | ||
| 3 | <XXX-SW-R1T002_Naming Convention for Matlab> | ||
| 4 | <XXX-SW-R1T001_Naming Convention for C-coding> | ||
| 5 | <XXX-SW-G1T001_Guideline for Modelling with Matlab> | ||
| 6 | <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy> | ||
| 7 | <XXX-SW-E2T002_XXX-Software Architecture Design Specification> | ||
| 8 | <XXX-SW-E2T003_XXX-SW Safety Analysis Report> | ||
| 9 | <XXX-SW-E2T001_XXX-Software Architecture Design Strategy> | ||
| 10 | <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy> | ||
| 11 | <XXX-SW-E3T002_XXX-SwUnit Detailed Design and Implementation Specification> | ||
| 12 | <XXX-SW-E4T001_XXX-SW Unit Verification Strategy> | ||
| 13 | <XXX-MAN-M3T011_Review Report-XXX-Software Architectural Design> | ||
| 14 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | ||
| 15 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Verification> | ||
| 16 | <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis> | ||
| 17 | <XXX-MAN-M3T010_Checklist-XXX Software Architectural Design> | ||
| 18 | <XXX-MAN-M3T010_Checklist-XXX Software Unit Design and Implementation> | ||
| 19 | <XXX-MAN-M3T010_Checklist-XXX Software Unit Verification> |
1.5 Definitions, Acronyms and Abbreviations
All terms, acronyms and abbreviations which are required to correctly interpret this document are listed in Table 4 Definitions, Table 5 Acronyms and Table 6 Abbreviations respectively.
Table 4 Definitions
| ID | Definition | Explanation |
| 1 | ||
| 2 |
Table 5 Acronyms
| ID | Acronym | Explanation |
| 1 | BMS | Battery Management System |
| 2 | MIL | Model in the loop |
| 3 | SIL | Software in the loop |
| 4 | HIL | Hardware in the loop |
| 5 | SFMEA | Software Failure Mode and Effect Analysis |
| 6 | TSR | Technical Software Requirement |
| 7 | SSR | Software Safety Requirement |
Table 6 Abbreviations
| ID | Abbreviation | Explanation |
| 1 | ||
| 2 |
2. Management of Software Verification Activities
This section describes the team organization, schedule, resources, responsibilities, tools, and methodologies to be applied in order to perform the software verification activities for <<PrjName>>.
2.1 Organization
The team organization and individual responsibilities are as defined in Project Plan (Safety Plan).
Table 7 Authorized User
| ID | Name | Department | Title | Read | Write | Copy |
| 1 | Engineer 1 | ? | ? | ? | ||
| 2 | Engineer 2 | ? | ? | ? | ||
| 3 | Engineer 3 | ? | ? | ? | ||
| 4 | Engineer 4 | ? | ? | ? | ||
| 5 | ... | ? | ? | ? | ||
| 6 | ... | ? | ? | ? |
2.2 Schedule
The project schedule is as defined in Project Plan (Safety Plan).
2.3 Tools and Methodology
This project will adopt the method of developing Software fusing ASPICE, the following is the list of the software tools adopted for successful completion of the project based on model-based development.
Table 8 Software unit test environment
| No. | Tool | Comment | Version | QTY |
| 1 | MATLAB | ... | ||
| 2 | Source Insight | IDE | ||
| 3 | Eclipse | IDE | ||
| 4 | ParaSoft | Do static test and unit dynamic test for hand-coding codes | ||
| 5 | MTest | Do unit dynamic test for Simulink models | ||
| 6 | WindRiver | ... | ||
| 7 | Lauterbach | ... | ||
| 8 | … | |||
| 9 | ||||
| 10 |
2.4 Evaluation Method
The <<PrjName>> software shall be subjected to different evaluation methods, in accordance with the verification review guidelines. The methods are (example):
- Inspection
- Review
- Walk through
- Static code analysis
- Dynamic code analysis
- SFMEA
3 Software Verification
This section of software verification plan for <<PrjName>> provides the detailed plan for the verification activities throughout the project lifecycle.
3.1 Verification of Software Requirement Phase?
3.1.1 Objective
The objective of this phase is to plan for verification of software requirements derived from the system requirements specification.
3.1.2 Inputs
The following documentations shall be provided to execute the verification of Software Requirement:
- SRS, incl. SSR(Function Safety)
- <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
- <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>
3.1.3 Responsible person
The following person will be in charge of this phase.
| ID | Name | Department | Title |
| 1 |
3.1.4 Work Products
The following are the deliverables from this sub-phase.
Table 9 Verification Work products of Software (Safety) Requirement Phase
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Requirement Specification> | |
| 2 | ||
| 3 |
3.1.5 Verification Review Methods
The software requirements shall be verified to ensure that:
- The software requirements are traceable and consistent with the system requirements
- The software requirements are unambiguous, atomic, internally and externally consistent.
The verification review shall be performed using:
- <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
- <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>
The following evaluation methods shall be applied for the verification.
Table 10 Methods for the verification of safety requirements
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Verification by walk-through | ++ | + | o | o |
| 1b | Verification by inspection | + | ++ | ++ | ++ |
| 1c | Semi-formal verificationa | + | + | ++ | ++ |
| 1d | Formal verificationa | o | + | + | + |
| a???????? Verification can be supported by executable models. | |||||
3.1.6 Environment
All work products of this phase should pass the verification review, all the tools used in verification as below:
Table 11 SSR Verification Environment
| No. | Tool | Comment | Version | QTY |
| 1 | OFFICE | |||
| 2 | Doors | |||
| 3 | ||||
| 4 | ||||
| 5 |
3.1.7 Entry/Exit Criteria
All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.
3.1.7.1 Entry Criteria
Following are entry criteria for software (safety) requirements:
- System Requirements Specification (Incl. Technical Safety Requirements) has been baselined in System Requirements Process.
- Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process.
- System Design Specification (Incl. Technical Safety Concept) has been baselined in System Design Process.
- Hardware Software Interface Specification has been baselined in System Design Process.
- Software Requirements Specification Verification Review Checklist should be available.
3.1.7.2 Exit Criteria
Following are exit criteria for software (safety) requirements:
- Software Requirements Specification has been approved and baselined.
- Software Requirements Specification Verification Review Report has been approved.
- Address all issues reported during verification.
3.2 Verification of Software Architecture Design
3.2.1 Objective
The objective of this phase is to plan for verification of software architectural design which is derived from software requirements specification。
3.2.2 Inputs
The following documentations shall be provided to carry out the verification of Software Architectural Design:
- SRS, incl. SSR(Function Safety)
- <XXX-MAN-M3T010_Checklist-XXX Software Architectural Design Checklist>
3.2.3 Responsible person
The following person will be in charge of this phase.
| ID | Name | Department | Title |
| 1 |
3.2.4 Work Products
The following are the deliverables from this sub-phase.
Table 12 Verification Work products of Software Architecture Design phase
| No. | Work Product | |
| 1 | <XXX-SW-E2T003_XXX-SW Safety Analysis Report> | |
| 2 | <XXX-MAN-M3T011_Review Report-XXX-Software Architectural Design> | |
| 3 | <XXX-SW-E2T002_XXX-Software Architecture Design Specification> |
3.2.5 Verification Review Methods
The software architectural design verification shall ensure that:
- The software architectural design shall comply with the software requirements
- The software architectural design shall be developed as a guideline for software unit detailed design.
The verification review shall be performed using:
- <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
- <XXX-MAN-M3T010_Checklist-XXX Software Requirements Analysis>
The following evaluation methods shall be applied for the verification.
Table 13 Methods for the verification of safety architectural design
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Walk-through of the designa | ++ | + | o | o |
| 1b | Inspection of the designa | + | ++ | ++ | ++ |
| 1c | Simulation of dynamic behaviour of the design | + | + | + | ++ |
| 1d | Prototype generation | o | o | + | ++ |
| 1e | Formal verification | o | o | + | + |
| 1f | Control flow analysisb | + | + | ++ | ++ |
| 1g | Data flow analysisb | + | + | ++ | ++ |
| 1h | Scheduling analysis | + | + | ++ | ++ |
| a???????? In the case of model-based development, these methods can also be applied to the model. | |||||
3.2.6 Environment
All work products of this phase should pass the verification review, all the tools used in verification as below:
Table 14 Software Architectural Design Verification Environment
| No. | Tool | Comment | Version | QTY |
| 1 | OFFICE | |||
| 2 | Doors | |||
| 3 | ||||
| 4 | ||||
| 5 |
3.2.7 Entry/Exit Criteria
All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.
3.2.7.1 Entry Criteria
Following are entry criteria for software (safety) requirements:
- Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
- Configuration Data Specification and Calibration Data Specification have been baselined in Software Requirements Process.
- Hardware Software Interface Specification has been baselined in System Design Process.
- Software Architectural Design Specification Verification Review Checklist should be available.
3.2.7.2 Exit Criteria
Following are exit criteria for software architecture design:
- Software Architectural Design Specification has been approved and baselined.
- Software Architectural Design Specification Verification Review Report has been approved.
- Address all issues reported during verification.
3.3 Verification of Software Unit Design and Implementation
3.3.1 Objective
The objective of this phase is to plan for verification of software unit design and implementation which is derived from software architectural design.
3.3.2 Inputs
The following documentations shall be provided to carry out the verification of Software Unit Design:
- SRS, incl. SSR(Function Safety)
- <XXX-SW-E2T002_XXX-Software Architecture Design Specification>
- <XXX-SW-G1T001_Guideline for Modelling with Matlab>
- <XXX-SW-R1T001_Naming Convention for C-coding>
- <XXX-SW-R1T002_Naming Convention for Matlab>
- <XXX-SW-E3T002_XXX-SwUnit Detailed Design and Implementation Specification>
- <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>
- <XXX-MAN-M3T010_Checklist-XXX Software Unit Design and Implementation>
3.3.3 Responsible person
The following person will be in charge of this phase.
| ID | Name | Department | Title |
| 1 |
3.3.4 Work Products
The following are the deliverables from this sub-phase.
Table 15 Verification Work products of Software Unit Design and Implementation
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | |
| 2 | ||
| 3 |
3.3.5 Verification Review Methods
The verification shall comply with the following:
- The software requirements shall be traceable to the allocated software units.
- The compliance of implemented model and the source code with the software unit design specification.
- The Software Unit Design Specification is developed per <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>.
- The implemented model and source code comply with <XXX-SW-G1T001_Guideline for Modelling with Matlab>.
- Static code analysis and semantic analysis is executed on the auto generated source code.
The following evaluation methods shall be applied for the verification review. The verification review shall be performed using Software Design Guidelines and Software Unit Design Specification Checklist.
Table 16 Methods for the Verification of Software Design and Implementation
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Walk-through of the design | ++ | + | o | o |
| 1b | Inspection of the design | + | ++ | ++ | ++ |
| 1c | Semi-formal verification | + | + | + | ++ |
| 1e | Formal verification | o | + | + | + |
3.3.6 Environment
All work products of this phase should pass the verification review, all the tools used in verification as below:
Table 17 Software Unit Design Verification Environment
| No. | Tool | Comment | Version | QTY |
| 1 | IDE | Source Insight, Eclipse, etc. | ||
| 2 | MATLAB | |||
| 3 | ||||
| 4 | ||||
| 5 |
3.3.7 Entry/Exit Criteria
All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.
3.3.7.1 Entry Criteria
Following are entry criteria for software (safety) requirements:
- Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
- Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
- Software Architectural Design Specification has been baselined in Software Architectural Design Process
3.3.7.2 Exit Criteria
Following are exit criteria for Software Unit Design and Implementation:
- Software Unit Design Specification has been approved and baselined.
- Software Unit Design Specification Verification Review Report has been approved.
- Address all issues reported during verification.
3.4 Verification of Software Unit Verification
3.4.1 Objective
The objective of this phase is to plan for software unit verification in order to demonstrate that the software units fulfill the software unit requirements and do not contain undesired functionality.
3.4.2 Test Strategy
Software unit verification strategy is in order to reduce software development risks, time, and cost. In this phase, interfaces tested for proper information flow and all error handling paths should be tested. Software unit tests are expected to against state machines in the software unit design.
3.4.3 Regression Test Strategy
Software unit verification phase shall be executed for the impacted units based on the updated Software Unit Test Specification. Check for defects propagated to other modules by changes made to existing program. Additional test cases focus on software functions likely to be affected by the change. Regression Tests cases focus on the changed software units.
3.4.4 Inputs
The following documentations shall be provided to carry out the verification of Software Unit Verification:
- <XXX-SW-E4T001_XXX-SW Unit Verification Strategy>
- <XXX-MAN-M3T010_Checklist-XXX Software Unit Verification>
- Software Unit Test Case
- Software Unit Test Report
3.4.5 Responsible person
The following person will be in charge of this phase.
| ID | Name | Department | Title |
| 1 |
3.4.6 Work Products
The following are the deliverables from this sub-phase.
Table 18 Verification Work products of Software Unit Verification
| No. | Work Product | |
| 1 | <XXX-MAN-M3T011_Review Report-XXX-Software Unit Verification> <XXX-MAN-M3T011_Review Report-XXX-Software Unit Design and Implementation > | |
| 2 | Software Unit Test Report | |
| 3 |
3.4.7 Verification Review Methods
The verification review shall be performed to ensure that
- There exists at least one test case for each software unit deign requirement.
- The tests are traceable to the software unit design requirements.
- The tests have been performed in accordance with the methods identified in Project Plan (Safety Plan).
- The tests produce the same results and the coverage as reported.
- In case of acceptable test failures or incomplete coverage, there exists valid justification recorded.
The following evaluation methods shall be applied for the verification review. The verification review shall be performed using Software Design Guidelines and Software Unit Design Specification Checklist.
Table 19 Methods for the Verification of Software Unit Verification
| No. | Inputs for Verification Review | Walk-through | Inspection |
| 1 | Software Unit Test Case | No | Yes |
| 2 | |||
| 3 |
3.4.8 Test Methods
The methods specified in the following table shall be applied for verification. The verification shall be performed using Software Unit Test Guideline and Software Unit Test Specification Checklist. The detailed requirements refer to <XXX-SW-E4T001_XXX-SW Unit Verification Strategy>.
Table 20 Methods for Software Unit Verification
| Method | ASIL | ||||
| A | B | C | D | ||
| 1a | Walk-through | ++ | + | o | o |
| 1b | Pair-programming | + | + | + | + |
| 1c | Inspection | + | ++ | ++ | ++ |
| 1d | Semi-formal verification | + | + | ++ | ++ |
| 1e | Formal verification | o | o | + | + |
| 1f | Control flow analysis | + | + | ++ | ++ |
| 1g | Data flow analysis | + | + | ++ | ++ |
| 1h | Static code analysis | ++ | ++ | ++ | ++ |
| 1i | Static analyses based on abstract interpretation | + | + | + | + |
| 1j | Requirements-based test | ++ | ++ | ++ | ++ |
| 1k | Interface test | ++ | ++ | ++ | ++ |
| 1l | Fault injection test | + | + | + | ++ |
| 1m | Resource usage evaluation | + | + | + | ++ |
| 1n | Back-to-back comparison test between model and code, if applicable | + | + | ++ | ++ |
Table 21 Methods for deriving test cases for software unit testing
| Method | ASIL | ||||
| A | B | C | D | ||
| 1a | Analysis of requirements | ++ | ++ | ++ | ++ |
| 1b | Generation and analysis of equivalence classes | + | ++ | ++ | ++ |
| 1c | Analysis of boundary values | + | ++ | ++ | ++ |
| 1d | Error guessing based on knowledge or experience | + | + | + | + |
Table 22 Structural coverage metrZD at the software unit level
| Method | ASIL | ||||
| A | B | C | D | ||
| 1a | Statement coverage | ++ | ++ | + | + |
| 1b | Branch coverage | + | ++ | ++ | ++ |
| 1c | MC/DC (Modified Condition/Decision Coverage) | + | + | + | ++ |
3.4.9 Environment
All work products of this phase should pass the verification review, all the tools used in verification as below:
Table 23 Software Unit Verification Environment
| No. | Tool | Comment | Version | QTY |
| 1 | ||||
| 2 | ||||
| 3 | ||||
| 4 | ||||
| 5 |
3.4.10 Entry/Exit Criteria
All deviations observed in verification should be addressed based on checkpoint questions provided in the checklist. All work products of this phase must be complete and approved.
3.4.10.1 Entry Criteria
Following are entry criteria for software (safety) requirements:
- Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
- Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
- Software Architectural Design Specification has been baselined in Software Architectural Design Process
3.4.10.2 Exit Criteria
Following are exit criteria for Software Unit Design and Implementation:
- Software Unit Design Specification has been approved and baselined.
- Software Unit Design Specification Verification Review Report has been approved.
- Address all issues reported during verification.
3.4.11 Software Unit Verification Method
XXX will demand to do the software unit test according to the software unit verification strategy.
The methods for SwUnit verification could be seen as below. XXX will adopt these methods marked with orange.
Table 24 Methods for Software Unit Verification
| No. | Methods | Comment | Select | |||
| A | B | C | D | |||
| 1a | Walk-through | ++ | + | O | O | R |
| 1b | Pair-programming | + | + | + | + | R |
| 1c | Inspection | + | ++ | ++ | ++ | R |
| 1d | Semi-formal verification | + | + | ++ | ++ | ￡ |
| 1e | Formal verification | O | O | + | + | ￡ |
| 1f | Control flow analysis | + | + | ++ | ++ | ￡ |
| 1g | Data flow analysis | + | + | ++ | ++ | ￡ |
| 1h | Static code analysis | ++ | ++ | ++ | ++ | R |
| 1i | Static analyses based on abstract interpretation | + | + | + | + | R |
| 1j | Requirements-based test | ++ | ++ | ++ | ++ | R |
| 1k | Interface test | ++ | ++ | ++ | ++ | R |
| 1l | Fault injection test | + | + | + | ++ | R |
| 1m | Resource usage evaluation | + | + | + | ++ | ￡ |
| 1n | Back-to-back comparison test between model and code, if applicable | + | + | ++ | ++ | ￡ |
| Refer to ISO 26262-6 § 9.4.2 Table 7, the “check symbol” means will adopt this method. | ||||||
未完待續。。。
參考文章
LINK
資源下載：TBD
