个人主页：云纳星辰怀自在

座右铭：“所谓坚持，就是觉得还有希望！”

---

本文为基于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:

1. Verify that the defined software requirements are fulfilled.
2. 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):

1. Inspection
2. Review
3. Walk through
4. Static code analysis
5. Dynamic code analysis
6. 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:

1. SRS, incl. SSR(Function Safety)
2. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
3. <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:

1. The software requirements are traceable and consistent with the system requirements
2. The software requirements are unambiguous, atomic, internally and externally consistent.

The verification review shall be performed using:

1. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
2. <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:

1. System Requirements Specification (Incl. Technical Safety Requirements) has been baselined in System Requirements Process.
2. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process.
3. System Design Specification (Incl. Technical Safety Concept) has been baselined in System Design Process.
4. Hardware Software Interface Specification has been baselined in System Design Process.
5. Software Requirements Specification Verification Review Checklist should be available.

3.1.7.2 Exit Criteria

Following are exit criteria for software (safety) requirements:

1. Software Requirements Specification has been approved and baselined.
2. Software Requirements Specification Verification Review Report has been approved.
3. 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:

1. SRS, incl. SSR(Function Safety)
2. <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:

1. The software architectural design shall comply with the software requirements
2. The software architectural design shall be developed as a guideline for software unit detailed design.

The verification review shall be performed using:

1. <XXX-SW-E1T001_XXX Software Requirement Analysis Strategy>
2. <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. b        Control and data flow analysis can be limited to safety-related components and their interfaces.

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:

1. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
2. Configuration Data Specification and Calibration Data Specification have been baselined in Software Requirements Process.
3. Hardware Software Interface Specification has been baselined in System Design Process.
4. Software Architectural Design Specification Verification Review Checklist should be available.

3.2.7.2 Exit Criteria

Following are exit criteria for software architecture design:

1. Software Architectural Design Specification has been approved and baselined.
2. Software Architectural Design Specification Verification Review Report has been approved.
3. 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:

1. SRS, incl. SSR(Function Safety)
2. <XXX-SW-E2T002_XXX-Software Architecture Design Specification>
3. <XXX-SW-G1T001_Guideline for Modelling with Matlab>
4. <XXX-SW-R1T001_Naming Convention for C-coding>
5. <XXX-SW-R1T002_Naming Convention for Matlab>
6. <XXX-SW-E3T002_XXX-SwUnit Detailed Design and Implementation Specification>
7. <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>
8. <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:

1. The software requirements shall be traceable to the allocated software units.
2. The compliance of implemented model and the source code with the software unit design specification.
3. The Software Unit Design Specification is developed per <XXX-SW-E3T001_XXX-SwUnit Detailed Design and Implementation Strategy>.
4. The implemented model and source code comply with <XXX-SW-G1T001_Guideline for Modelling with Matlab>.
5. 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:

1. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
2. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
3. 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:

1. Software Unit Design Specification has been approved and baselined.
2. Software Unit Design Specification Verification Review Report has been approved.
3. 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:

1. <XXX-SW-E4T001_XXX-SW Unit Verification Strategy>
2. <XXX-MAN-M3T010_Checklist-XXX Software Unit Verification>
3. Software Unit Test Case
4. 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

1. There exists at least one test case for each software unit deign requirement.
2. The tests are traceable to the software unit design requirements.
3. The tests have been performed in accordance with the methods identified in Project Plan (Safety Plan).
4. The tests produce the same results and the coverage as reported.
5. 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:

1. Configuration Data Specification and Calibration Data Specification have been baselined in System Requirements Process
2. Software Requirements Specification (Incl. Software Safety Requirements) has been baselined in Software Requirements Process.
3. 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:

1. Software Unit Design Specification has been approved and baselined.
2. Software Unit Design Specification Verification Review Report has been approved.
3. 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