功能安全软件验证方法

软件级产品开发作为功能安全V流程中的一个重要组成部分，在产品功能安全开发的过程中具有举足轻重的地位。它以技术安全概念（TSC）为直接输入，软件开发V模型的左侧是软件的设计（①软件安全需求规范；②软件架构设计；③软件软件单元设计和实现），V模型的右侧是测试和验证（①软件单元验证；②软件集成和验证；③嵌入式软件测试）。

在软件集成和验证部分，道路车辆功能安全标准ISO26262-2018 Part 6推荐ASIL_C和ASIL_D应采用背靠背测试的方法；在嵌入式软件测试部分，道路车辆功能安全标准ISO26262-2018 Part 6推荐所有ASIL等级均应在硬件在环的环境下进行。

今天，我们主要讨论：

①模型在环测试（MIL）；

②软件在环测试（SIL）；

③硬件在环测试（HIL）；

④处理器在环测试（PIL）。

四种测试方法之间有什么区别和联系？分别要做哪些事情？各自的使用场景是什么样的？

01模型在环测试

模型在环测试（Model In the Loop, MIL）是指：通过Simulink搭建控制器模型和被控对象模型后，将控制器模型和被控对象模型连接起来形成闭环，通过控制器去实现被控对象的控制。模型在环测试的示意图如图一所示。

通常情况下，模型在环测试主要用于以下两种场合：
①软件工程师进行模型级别的测试与验证；
②系统工程师通过控制算法模型控制被控对象模型来实现算法的验证。
那么问题来了，在进行模型在环测试时是否必须要有被控对象模型呢？答案显然是否定的。在实际的测试中，是否一定需要被控对象模型要依具体情况而定。举个例子：对TCU的扭矩输出功能进行模型在环测试，这种情况显然是需要被控对象模型的；但如果被控对象的输出是开关量（如车灯的控制），只需要知道输出是ON或OFF即可，没必要再去进行车灯的Simulink建模。

02软件在环测试

软件在环测试（Software In the Loop, SIL）是指：将控制器的Simulink模型通过自动代码生成器编译生成C代码并对其进行测试，软件在环测试的示意图如图二所示。

那么软件在环测试是否必须要有被控对象模型呢？答案依然是否定的，原因是因为软件在环测试的目的只是为了验证模型和代码的一致性（在使用相同的测试用例的情况下）。
注：背靠背测试包括模型在环测试和软件在环测试，目的是通过输入相同的测试用例来验证模型与代码的一致性。

03 处理器在环测试

处理器在环测试（Processor In the Loop, PIL）是指：将控制器的Simulink模型通过自动代码生成器编译生成C代码后在目标处理器是运行，处理器在环测试的示意图如图三所示。

模型在生成代码的过程中可能会出现错误，同样在编译的过程中也有可能出现错误。软件在环测试的目的是为了验证代码与模型的一致性，而处理器在环测试的目的是为了验证代码在目标处理器上的运行结果与模型的一致性。

此外，通过处理器在环测试还可以获得算法在实际控制器上的最长运行时间，这对于嵌入式软件工程师的价值是不言而喻的。

04 硬件在环测试

硬件在环测试（Hardware In the Loop, SIL）是指：将被控对象的Simulink模型通过自动代码生成器编译生成C代码后生成可执行文件并将其放到工控机上运行，用工控机来替代被控对象，目的是为了验证控制器的功能。硬件在环测试的示意图如图三所示。

通常情况下，硬件在环测试主要用于以下几种场合：
①被控对象价格比较昂贵，损坏后会给企业带来较大的经济损失；
②被控对象发生失效后会危及测试人员的人身安全；
③在开发过程中，被控对象的开发严重滞后于控制器的开发。
注：虽然硬件在环测试比实物测试成本低，但并不是说HIL测试能够完全替代实物测试。