图3 控制器产品开发
本文主要是讲基于V模型的软件开发我们都需要做什么？在ISO26262中都定义了哪些关于基于模型的开发、嵌入式手工方式开发我们需要怎么做才能达到ASIL相应的目标？关于功能安全的内容主要来源于ISO26262-6:2018，如图4。
图4 ISO26262体系总体架构
在ISO 26262-2中我们曾解释过安全生命周期管理流程的各个流程的含义，而软件开发的V模型左边是软件需求、架构设计和实现，右边则是软件的集成与验证。其具体过程如图5/6：
图5 基于V模型的软件开发
图6 基于V模型的软件开发
自上图，我们也可看出，每一步的开发过程都需要回溯验证，而如何保证我们的开发满足既定的需求呢？单纯靠人力是很难进行把握的，因此测试验证就变得尤为重要，因此在开发过程中常需要使用一些工具作为辅助开发。
注：嵌入式软件的测试验证可采用LDRA工具，这是一款自测试需求---动/静态测试---结果输出，的一块测试工具，可以对符合性等方面进行把控，有兴趣的小伙伴可查阅之前的文章（非本公司产品）。
注：其他汇编语言、开源方式的验证可采用我们代理的测试软件，有兴趣的小伙伴可查阅之前的文章。
为了满足ASIL的不同目标要求，ISO26262-6给出了关于模型与编码的一些建议，其中下方诸表中：
“++”表示高度推荐。可以理解为必须执行；
“+”表示推荐。可理解为根据项目情况而定，一般我们在做项目时“+”也是必须实现的；
“o”表示可以不使用。
注：为了与ISO26262标准的相关章节进行对应，这里直接采用原标准的章节编号。
注：下文黑色字体为标准原文，紫色字体为个人添加。
5 软件开发通则
5.4 需求建议
5.4.2在选择设计、建模或编程语言时应考虑的标准是：
a：明确易懂；
b：如果建模用于需求工程和管理，则适合根据ISO 26262-8:2018第6条指定和管理安全要求；
c：支持模块化、抽象化、可封装；
d：支持结构化架构。
为了满足ASIL的不同目标，标准建议软件的建模、设计或编程语言应该满足表1的指导方针与开发环境。
表1 建模与编程准则
主题
SAIL
A
B
C
D
1a
低复杂度执行a
++
++
++
++
1b
使用语言子集b
++
++
++
++
1c
类型的强制执行c
++
++
++
++
1d
使用防守实现技术d
+
+
++
++
1e
使用可靠的设计原则e
+
+
++
++
1f
使用明确的图形表示
+
++
++
++
1g
使用设计指南
+
++
++
++
1h
使用命名约定
++
++
++
++
1i
并发性方面f
+
+
+
+
a:可能需要在这个主题与本文档的其他要求之间做出适当的妥协。
b: 排除定义模糊的语言结构，因为不同的建模者、程序员、代码生成器或编译器可能对这些结构有不同的解释;
排除从经验中容易导致错误的语言构造，例如条件中的赋值或本地变量和全局变量的相同命名;
排除可能导致未处理的运行时错误的语言构造。
c: 在语言中不固有的地方强加强类型的原则.
d: 在除法运算之前验证除数(不同于零或在特定范围内);
检查通过参数传递的标识符，以验证调用函数是否是预期的调用方;
在switch情况下使用“default”来检测错误。
e: 可能需要核查基本假设、边界和适用条件的有效性.
f: 进程或任务的并发性并不局限于在多核或多处理器运行时环境中执行软件。
6 软件安全要求规范
6.4 需求与建议
6.4.1软件安全要求应考虑到软件所需的与安全相关的功能和属性。
6.4.2根据ISO 26262-4:2018、6.4.1和6.4.3的技术安全要求、技术安全概念和系统架构设计派生的软件安全要求规范应考虑：
符合ISO 26262- 8:8 - 2018第6条的安全要求规范和管理；系统和硬件配置；软硬件接口规范；满足硬件设计相关规范；具有时间限制，如执行、反应等时间满足系统需求；外部接口；车辆、系统或硬件的操作模式和模式之间的组合变化对软件产生的影响。6.4.3如果ASIL分解应用于软件安全要求，则应遵守ISO 26262- 9:18 2018第5条。
6.4.4第6条关于软硬件接口规范应足够细化。
6.4.5除6.4.1中规定的安全要求的功能外，其他嵌入式软件执行的功能，应根据所应用的质量管理体系提供这些功能及其特性的规范。
6.4.6细化的软硬件接口规范应由系统、硬件和软件开发负责人共同验证。
6.4.7软件安全要求和软硬件接口规范应按照ISO 26262-8:2018第6和第9条进行验证。
7 软件架构设计
7.4需求建议
7.4.1为了避免软件架构设计和后续开发活动中的系统性错误，软件架构设计的描述应符合表2所列的特征：
a：可理解性；
b：一致性；
c：简易性；
d：可验证性；
e：模块化；
f：抽象化；
注：抽象化可以通过使用层次结构、分组方案或视图来覆盖体系结构设计的静态、动态或部署方面。
g：可封装性；
h：可维护性。
表2 软件架构设计符号
符号
SAIL
A
B
C
D
1a
自然语音a
++
++
++
++
1b
非正式符号
++
++
+
+
1c
半正式符号b
+
+
++
++
1d
正式符号
+
+
+
+
a: 自然语言可以补充符号的使用，例如，一些主题更容易用自然语言表达，或者为符号中捕获的决策提供解释和基本原理。
b: 半正式符号包括伪代码或使用UML、SysML、Simulink或Stateflow建模。
7.4.3为了避免系统故障，软件架构设计具备表3所列的特点：
a：可理解性；
b：一致性；
c：简易性；
d：可验证性；
e：模块化；
f：可封装性；
g：可维护性。
表3 软件架构设计原则
原则
SAIL
A
B
C
D
1a
软件组件的适当层次结构
++
++
++
++
1b
软件组件的大小和复杂性限制a
++
++
++
++
1c
接口大小限制a
+
+
+
++
1d
软件组件之间的强内聚性b
+
++
++
++
1e
软件组件之间的松散耦合性b,c
+
++
++
++
1f
适当的调度特性
++
++
++
++
1g
中断使用限制a,d
+
+
+
++
1h
软件组件的适当空间隔离
+
+
+
++
1i
共享资源的适当管理e
++
++
++
++
a: 在1b、1c和1g原则中，“限制”意味着在与其他设计考虑的平衡中最小化
b: 原则1d和1e可以通过关注点分离来实现，关注点分离指的是识别、封装和操作与特定概念、目标、任务或目的相关的软件部分的能力。
c: 原则1e指处理软件组件之间依赖关系的管理。
d: 原则1g可以包括最小化中断的数量，或者使用具有明确优先级的中断，以实现确定性。
e: 原则1i既适用于共享硬件资源，也适用于共享软件资源。
这种资源管理可以在软件或硬件中实现，包括防止对共享资源的冲突访问的安全机制和/或过程措施，以及检测和处理对共享资源的冲突访问的机制。
7.4.14软件架构设计应根据ISO 26262-8:2018，第9条进行验证，并使用表4所列的验证方法进行：
表4软件架构设计的验证方法
方法
SAIL
A
B
C
D
1a
初步设计a
++
+
o
o
1b
设计检查a
+
++
++
++
1c
设计动态模拟
+
+
+
++
1d
原型验证
o
o
+
++
1e
正式验证
o
o
+
+
1f
控制流分析b
+
+
++
++
1g
数据流分析b
+
+
++
++
1h
调度分析
+
+
++
++
a: 在基于模型的开发中，这些方法也可以应用到模型中。
b: 控制/数据流分析可以局限于与安全相关的组件及其接口。
注：LDRD测试软件便是针对具有功能安全目标的嵌入式软件开发的测试的一款产品。
8 软件单元设计与实现
8.4 需求建议
8.4.3为了避免系统故障并确保软件单元设计实现以下特性，软件单元设计应使用表5所列的符号进行描述。
a：一致性；
b；可理解性；
c：可维护性；
d：可验证性。
表5 软件单元设计符号
符号
SAIL
A
B
C
D
1a
自然语音a
++
++
++
++
1b
非正式符号
++
++
+
+
1c
半正式符号b
+
+
++
++
1d
正式符号
+
+
+
+
a: 自然语言可以补充符号的使用，例如，一些主题更容易用自然语言表达，或者为符号中捕获的决策提供解释和基本原理。
b: 半正式符号包括伪代码或使用UML、SysML、Simulink或Stateflow建模。
8.4.5源代码级软件单元设计和实现的设计原则遵循表6
表6 软件单元设计和实现的设计原则
原则
SAIL
A
B
C
D
1a
在子程序和函数中仅有一个入口点和一个出口点a
++
++
++
++
1b
没有动态对象或变量，除非在创建它们时已进行了在线测试。a
+
++
++
++
1c
初始化变量
++
++
++
++
1d
不能多次使用变量名a
++
++
++
++
1e
避免使用全局变量，除非证明是合理的a
+
+
++
++
1f
指针使用限制a
+
++
++
++
1g
没有隐式类型转换a
+
++
++
++
1h
没有隐藏的数据流或控制流
+
++
++
++
1i
没有无条件的跳跃a
++
++
++
++
1j
没有递归
+
+
++
++
a: 原则1a, 1b, 1d, 1e, 1f, 1g和1i不适用于基于模型的开发中使用的图形符号。
注意：对于C语言，MISRA C的开发方式，涵盖了表6中列出的许多原则。即若想实现ASIL的相应目标，若我们使用的是C预言进行手码代码的开发，则表6的许多原则都会被触发，这样的话就很难达到相应的功能安全目标。
注：下方内容开始，进入V模型的右边
9 软件单元验证
9.4 需求建议
软件单元设计和实现应根据ISO 26262-8:2018第9条进行验证，采用表7的组合方法进行。
表7软件单元验证方法
方法
SAIL
A
B
C
D
1a
初步验证a
++
+
o
o
1b
结对编程a
+
+
+
+
1c
检查a
+
++
++
++
1d
半正式验证
+
+
++
++
1e
正式验证
o
o
+
+
1f
控制流分析b,c
+
+
++
++
1g
数据流分析b,c
+
+
++
++
1h
静态代码分析d
++
++
++
++
1i
基于抽象解释的代码分析e
+
+
+
+
1j
基于需求的测试f
++
++
++
++
1k
接口测试g
++
++
++
++
1l
故障注入测试h
+
+
+
++
1m
资源使用情况评估i
+
+
+
++
1n
若适用，模型和代码之间的背靠背测试j
+
+
++
++
a: 对于基于模型的开发，如果有证据证明对所使用的代码生成器有信心，那么这些方法将应用于模型级别。（有些编译器没有认证）
b: 方法1f和1g可以应用在源代码级别。这些方法既适用于手工代码开发，也适用于基于模型的开发。
c: 方法1f和1g可以作为方法1e、1h或1i的一部分。
d: 静态分析是一个集合术语，它包括搜索源代码文本或模型，以查找匹配已知错误的模式或符合建模或编码指南的模式。（比如我们代理的工具，便可代码静态扫描测试）
e: 基于抽象解释的静态分析是扩展静态分析的统称，它包括通过添加语义信息来扩展编译器解析树，这些语义信息可以检查是否违反定义的规则(例如数据类型的问题，未初始化的变量)，控制流图的生成和数据流分析(例如捕捉与竞争条件和死锁相关的错误，指针错误使用)，甚至元编译和抽象代码或模型解释。
f: 单元级别的软件需求是这个基于需求的测试基础。这包括软件单元设计规范和分配给软件单元的安全需求。
g: 此方法可用于为已使用和交换数据的完整性提供证据。
h: 在软件单元测试的背景下，故障注入测试是指修改被测试的软件单元(例如将故障引入到软件中)，以达到9.4.2所述的目的。这种修改包括任意错误的注入(例如，通过破坏变量的值，通过引入代码突变，或通过破坏CPU寄存器的值)。
i: 只有在目标环境上执行软件单元测试，或者目标处理器的模拟器充分支持资源使用测试时，才能正确执行资源使用评估的某些方面。
j: 这种方法需要一个可以模拟软件单元功能的模型。这里对模型和代码进行了相同的模拟，并对结果进行了比较。
9.4.3生成测试用例应使用表8所列的方法。
表8 软件单元测试的测试用例生成方法
方法
SAIL
A
B
C
D
1a
需求分析
++
++
++
++
1b
等价类生成和分析a
+
++
++
++
1c
边值分析b
+
++
++
++
1d
基于知识或经验的错误预测c
+
+
+
+
a: 根据输入和输出的划分，可以识别等价类，从而为每个类选择具有代表性的测试值。
b: 该方法适用于接口、临界值（接近、范围或超出）。
c: 错误预测可以基于通过“经验教训”和专家判断收集的数据。
9.4.4为了评估验证的完整性，并提供证据证明单元测试的目标已充分实现，应确定软件单元级别的需求覆盖率，并根据表9中列出的度量标准测量结构覆盖率。如果已实现的结构覆盖被认为是不够的，则应指定额外的测试用例或提供基于其他方法的基本原理。
表9 软件单元级别的结构覆盖率度量
方法
SAIL
A
B
C
D
1a
语句覆盖
++
++
+
+
1b
分支覆盖
+
++
++
++
1c
修正条件/判定覆盖
+
+
+
++
注：
结构覆盖可以通过使用适当的软件工具来确定。在基于模型的开发的情况下，结构覆盖的分析可以在模型级使用模型的类似结构覆盖度量执行。如果编译器生成的代码被用来确定结构覆盖的程度，就有必要提供证据证明编译器对测试结果没有影响。注：由于有些开发过程使用的编译器是自主开发的，因此编译过程是否会引入不符合功能安全标准的代码无法确认，因此对于自主开发的编译器是需要进行认证的，认证工具可查阅关于solidsands的文章。
10 软件集成与验证
10.4 需求建议
10.4.2 软件集成应根据ISO 26262-8:2018第9条执行，通过表10所示的适当组合方法对软件集成进行验证。
a：符合第7条规定的软件架构设计；
b：符合6.5.2软硬件接口规范；
c：指定的功能；
d：指定的属性；
注：可靠性源于没有不可访问的软件，对错误输入的鲁棒性，可靠性源于有效的错误检测和处理。
e：足够的资源来支持功能；
f：根据7.4.10和7.4.11的安全导向分析得出的安全措施的有效性（如适用）。
表10 软件集成验证方法
方法
SAIL
A
B
C
D
1a
基于需求的测试a
++
++
++
++
1b
接口测试
++
++
++
++
1c
故障注入测试b
+
+
++
++
1d
资源使用评估c,d
++
++
+
++
1e
若适用，模型和代码之间的背靠背测试e
+
+
++
++
1f
控制流与数据流的验证
+
+
++
++
1g
静态代码分析f
++
++
++
++
1h
基于抽象解释的静态分析g
+
+
+
+
a:软件需求是这个基于需求测试的基础。
b:在软件集成测试的背景下，故障注入测试是指为了10.4.3中描述的目的，在软件中引入故障，特别是测试与安全机制相关的软硬件接口的正确性。这包括为了测试安全机制而注入任意错误(例如通过破坏软件接口)。故障注入也可用于验证不受干扰。
c: 为了确保满足受硬件架构设计影响的要求，并保证有足够的容忍度，必须确定诸如平均和最大处理器性能、最小或最大执行时间、存储使用(例如用于堆栈和堆的RAM、用于程序和数据的ROM)和通信链路的带宽(例如数据总线)等属性。
d: 只有在目标环境上执行软件集成测试，或者目标处理器的模拟器充分支持资源使用测试时，才能正确执行资源使用评估的某些方面。
e: 这种方法需要一个可以模拟软件组件功能的模型。这里对模型和代码进行了相同的模拟，并对结果进行了比较。
f: 静态分析是一个集合术语，它包括诸如体系结构分析、资源消耗分析和搜索源代码文本或模型的模式，以匹配已知的错误或遵从建模或编码指南。
g: 基于抽象解释的静态分析是扩展静态分析的统称，它还包括通过添加语义信息来扩展编译器解析树，这些语义信息可以检查是否违反定义的规则(例如数据类型的问题，未初始化的变量)，控制流图的生成和数据流分析(例如捕捉与竞争条件和死锁相关的错误，指针错误使用)，甚至元编译和抽象代码或模型解释。
10.4.3 为了使根据10.4.2选择的软件集成测试方法测试用例的规范能够实现，测试用例应该使用表11中列出的方法来派生。
表11 软件集成测试的测试用例生成方法
方法
SAIL
A
B
C
D
1a
需求分析
++
++
++
++
1b
等价类生成和分析a
+
++
++
++
1c
边值分析b
+
++
++
++
1d
基于知识或经验的错误预测c
+
+
+
+
a: 根据输入和输出的划分，可以识别等价类，从而为每个类选择具有代表性的测试值。
b: 该方法适用于接口、临界值（接近、范围或超出）。
c: 错误预测可以基于通过“经验教训”和专家判断收集的数据。
10.4.5 适用于ASIL A、B、C和D，根据4.4:为了评估测试用例的完整性，并提供证据证明集成测试的测试目标已充分实现，结构覆盖应根据表12所列方法进行评估。如果已实现的结构覆盖被认为是不够的，则应指定额外的测试用例或提供基于其他方法的基本原理。
表12 软件架构级别的结构覆盖率
方法
SAIL
A
B
C
D
1a
功能覆盖a
+
+
++
++
1b
调用覆盖b
+
+
++
++
a: 方法1a是指软件中执行的软件子程序或函数的百分比(定义见IEC 61508- 7:7 2010, C.5.8)。
b: 方法1b是指执行的软件子程序或函数相对于软件中这些子程序或函数的每次实现调用的百分比。
注：可以通过实现适当的软件集成和测试策略来提供证据。
11 嵌入式软件测试
11.4 需求建议
11.4.1 为了验证嵌入式软件在目标环境中满足软件安全要求，测试应在表13所示的合适的测试环境中进行，并符合ISO 26262-8:2018，第9条。
表13 用于进行软件测试的测试环境
方法
SAIL
A
B
C
D
1a
硬件在环
++
++
++
++
1b
电子控制单元网络环境a
++
++
++
++
1c
整车
+
+
++
++
a: 包括部分或完全集成车辆、“试验车”或“骡”车辆的电气系统的测试台架，以及“车辆的一部分”。
11.4.2嵌入式软件的测试应采用表14所示的方法进行，以提供证据证明嵌入式软件满足各自ASIL要求的软件需求。
表14 嵌入式软件的测试方法
方法
SAIL
A
B
C
D
1a
基于需求的测试
++
++
++
++
1b
故障注入测试a
+
+
+
++
a: 在软件测试中，故障注入测试是指通过破坏校准参数等方法将故障引入到软件中。
11.4.3为了使符合11.4.2的软件测试的测试用例得以实现，测试用例应该使用表15中列出的方法得到。
表15 嵌入式软件测试的测试用例生成方法
方法
SAIL
A
B
C
D
1a
需求分析
++
++
++
++
1b
等价类生成和分析
+
++
++
++
1c
边值分析
+
+
++
++
1d
基于知识或经验的错误预测
+
+
++
++
1e
函数相关性分析
+
+
++
++
1f
操作用例分析a
+
++
++
++
a: 软件的操作用例可以包括现场软件更新，只有在确保软件完整性的情况下，才能通过BootLoader进行引导启动应用程序。嵌入式软件在不同操作模式下的安全相关行为，（如启动、诊断、降级、关机(进入睡眠)、上电(唤醒)、校准）与不同ECU之间同步功能，或用于保护生产人员的终端特定测试台架。
注：ISO26262对于软件开发的要求较多，若采用手工代码的形式开发软件，在实现功能安全相关目标上具有相当大的验证工作，需谨慎评估其合规性。（若有需要，基础软件以及部分应用软件可以合作，当然相关测试工具也可以的。）
公众号文章链接：基于V模型的软件开发如何满足功能安全目标
