当前位置：首页 > news >正文

汽车功能安全-软件集成和验证（Software Integration Verification）【目的、验证输入、集成验证要求】9

news 2025/7/11 9:49:14

文章目录

1 目的
2 验证输入
3 软件集成要求
- 3.1 要求和建议
- 3.2 汽车行业示例（混合动力控制器软件）
4 验证要求

1 目的

软件集成和验证阶段的核心目标是证明集成后的软件单元（模块、组件）已经正确地开发出来，满足了所有的功能和（至关重要的）安全要求。
该子阶段的目的是：

a) 定义集成步骤并集成软件元素，直至嵌入式软件完全集成；
b) 验证由软件架构级别的安全分析产生的已定义的安全措施是否得到了适当的实施；
c) 提供证据，证明集成的软件单元和软件组件满足其软件架构设计需求；及
d) 提供充分证据，证明集成软件不包含关于功能安全的非所需功能和特性。

在此子阶段，按照软件架构设计，对软件要素之间特有的集成层次和接口进行验证。软件要素的集成和测试的步骤直接对应着软件的分层架构。
在这里插入图片描述

2 验证输入

软件架构设计规范，按照7.5.1；
- 定义： 描述软件如何被分解为组件、单元以及它们之间如何交互、接口、依赖关系和约束的文档。
- 作用： 为如何进行集成（集成的顺序、接口要求）以及验证测试的结构（如模块测试、组件测试、集成测试）提供蓝图和依据。
- 来源： 软件设计阶段的输出，基于技术安全要求开发。

3 软件集成要求

3.1 要求和建议

定义软件集成方法，并描述将单个软件单元分层集成到软件组件的步骤，直至嵌入式软件完全集成为止。

定义软件集成方法： 你需要明确规定“怎么把小块软件组装成大块软件”。这个方法要详细描述集成策略、使用的工具、环境搭建、执行流程（谁、何时、做什么）、以及如何记录结果。
描述软件集成步骤： 你需要清晰地描绘出软件集成的“阶梯”，从最小的、不可再分的软件单元开始：
- 第一步：把几个单元集成为一个小的软件组件。
- 第二步：把小的组件（或结合更多单元）集成为更大的组件。
- 后续步骤：重复上述分层组合过程…
- 最终步：将所有组件集成，形成完整的嵌入式软件。

在定义步骤时，必须考虑以下依赖关系：
- a) 原文定义：与实现10.4.2提供的验证目标之间的依赖关系
- a)解释：与验证目标（10.4.2）的依赖： 你在软件单元验证阶段（ISO26262 Part 6 Clause 10.4.2）定义了很多测试目标和用例。现在集成过程中，需要考虑：哪些新的集成测试必须在单元测试完成后才能进行？哪些集成步骤的结果（或提供的接口）是执行后续集成测试的前提条件？集成测试如何补充和覆盖单元测试无法发现的（主要是单元交互和集成带来的）问题？
- b) 原文定义：与软件集成相关的功能依赖关系；
- b) 解释：功能依赖关系： 软件各部分之间不是孤立的！一个组件（比如油门控制器）需要另一个组件（比如引擎控制器）提供数据才能工作。在定义集成顺序时，必须识别这些运行时的依赖关系。你需要先集成提供基础服务/数据的组件，再集成依赖这些服务/数据的组件。集成时要测试这些交互是否正确。
- c) 原文定义：软件集成与软硬件集成之间的依赖关系。
- c)解释：软件集成与软硬件集成的依赖： 你的软件最终要跑在目标硬件（ECU）上。这带来了约束：
  - 资源依赖： 某些集成步骤可能必须在目标硬件/模拟器上进行，因为需要验证内存占用、实时性能等（纯软件模拟环境不够）。
  - 执行环境依赖： 某些集成功能（如底层驱动、中断处理）直接依赖硬件，需要尽早与硬件一起验证。
  - 集成策略协调： 软件集成完成到什么程度后，才能开始与硬件集成（VSI）？它们之间可能有部分重叠或并行。需要明确交接点和协同方式。
注：原文定义：对于基于模型的开发，软件集成可以替换为模型级别的集成以及随后来自集成模型的代码自动生成（参见附件B）。
- 解释：基于模型开发（MBD）的备注： 如果使用模型驱动开发（如MATLAB/Simulink），你的“软件单元”可能就是模型块，“软件组件”就是子系统模型。软件集成验证 可以先在模型层面进行（做模型在环MIL测试），验证模型子系统之间的接口、逻辑和功能是否在集成后依然正确。验证通过后，再从集成好的系统模型自动生成代码。这时再通过生成的代码进行类似传统方式的软件集成测试（但前期大部分问题已在模型层面解决）。后续仍需进行目标硬件上的集成验证。

3.2 汽车行业示例（混合动力控制器软件）

软件单元示例：
- Read_Battery_Voltage_Cell()：读取单个电池单体电压。
- Calculate_SOC()：基于电压电流计算电池剩余电量（SOC）。
- Control_Motor_Relay()：控制高压电机接触器的通断。
早期集成步骤：
- 集成电池基础组件： 将多个 Read_Battery_Voltage_Cell() (单元) 集成到一个能同时读取所有单体电压并进行初步一致性校验的组件中。考虑**(b功能依赖)：电压读取组件是计算SOC的基础。考虑(a验证依赖)**：需先保证每个Read_Battery_Voltage_Cell()单元自身验证通过。
- 集成SOC估算组件： 将电压读取组件（已是组件）与Calculate_SOC()（单元）以及其他单元（电流读取、温度读取）集成。执行组件级测试验证SOC计算逻辑。考虑**(b功能依赖)：依赖电压、电流、温度读数。考虑(c软硬件依赖)**：可能需要部分在ECU硬件评估板上运行（或高仿真环境），因为算法计算量可能很大，需验证性能。
中期集成步骤：
- 集成高压控制组件： 将 Control_Motor_Relay()（单元）与接触器状态监控、预充电控制逻辑等单元集成，形成一个能安全管理高压回路通断的组件。测试其安全逻辑（如预充电顺序、短路检测）。考虑**(c软硬件依赖)**: 必须在目标ECU（或精确模拟器）上进行测试，涉及底层驱动、高精度时序控制和硬件直接交互。
后期集成步骤：
- 集成能量管理核心组件： 将电池SOC估算组件、高压控制组件、引擎运行状态组件、发电机控制逻辑等集成。测试其在各种工况下的充放电策略、模式切换逻辑（如纯电->混动）、能量回收等。考虑**(b功能依赖)：依赖几乎所有底层组件提供的数据和状态。考虑(a验证依赖)**：依赖所有底层组件及前期集成步骤的测试结果。
最终集成：
- 集成完整混合动力控制软件： 将能量管理核心组件与其他组件（如热管理、整车通信模块、诊断模块、扭矩分配控制等）集成成一套完整软件。进行系统级软件集成测试。考虑**(c软硬件集成依赖)**：此刻，完整的软件应准备好进行软硬件集成（VSI），即部署到目标ECU上进行与硬件的联合调试和测试。

依赖关系在示例中的体现：
- (a验证目标依赖)：你无法测试能量管理核心组件对SOC的依赖性，除非SOC估算组件已经通过了自身的集成测试。集成测试覆盖了各组件之间接口的逻辑、时序和数据一致性，这是单元测试无法覆盖的。
- (b功能依赖)：SOC估算功能依赖于精确的电压读取和温度读数。没有可靠的底层数据（功能提供），高层策略（功能使用）无法正常工作。集成顺序必须先确保基础功能组件就绪。
- (c软硬件集成依赖)：
  - 像高压接触器控制这样直接操纵关键硬件、涉及高安全性的组件，必须在集成早期就结合硬件（或高保真模拟环境）进行验证（因为纯软件环境无法捕捉关键硬件时序和驱动问题）。
  - 当软件集成到一定程度（如具备基础输入/输出控制、通信、内存管理），就可以提前部署到目标ECU（HW或快速原型板）上，并行开展部分软硬件集成工作（如验证基本输入输出信号、刷写流程等），而不是等所有功能都集成完毕才开始上车调试。

核心目的： 通过这种结构化、分层级并明确定义了依赖关系的集成方法，旨在早期发现和修复软件单元在集成过程中产生的接口错误、时序问题、资源冲突、逻辑交互缺陷等，确保最终生成的嵌入式软件在功能、性能和安全方面满足要求，为后续顺利的软硬件集成和系统验证打下坚实基础。

4 验证要求

按照ISO 26262-8:2018第9章，通过表10所示方法，对软件集成进行验证，证明分层集成的软件单元、软件组件和集成嵌入式软件能够实现：

a) 与软件架构设计的符合性，按照第7章；【软件集成验证重点关注】
- ISO解释： 验证集成后的软件的结构、组织方式（比如模块怎么划分、怎么通信）和预期的“蓝图”（即软件架构设计）一致。
- 通俗解释 (汽车角度)： 就像按照精确的电路图组装电脑主板一样，软件集成也要严格按照事先设计好的“软件结构图”来连接各个程序模块。要检查模块之间的实际连接（谁和谁说话，怎么传数据）和设计图上的连线是否一致。
- 例子：
  - 设计图要求： 发动机控制模块中的“喷油控制软件”必须直接接收“发动机转速传感器软件”的数据。
  - 验证方法： 在集成好的软件里，检查喷油控制模块是否真的调用了转速传感器模块提供的接口函数来获取数据。如果没有（比如它错误地调用了水温传感器的接口），那就是不符合。
  - 测试类型： 接口测试、动态分析（运行中追踪数据流）。
b) 与软硬件接口规范的符合性，按照6.5.2；【可在系统集成测试验证】
- ISO解释： 验证软件如何与它运行其上的硬件（如微控制器、传感器、执行器）打交道的方式，是否符合预先定义好的规则。
- 通俗解释 (汽车角度)： 就好比确保ECU里的软件芯片（芯片）的“管脚”（软件接口）和连接它的传感器、执行器（如发动机喷油器、刹车卡钳的电磁阀）的“接线”（硬件接口）定义匹配无误（电压、信号类型、频率、怎么读怎么写）。软件读取传感器值和发送控制命令的方式必须严格遵守硬件说明书。
- 例子：
  - 规范要求： 刹车压力传感器信号是0-5V模拟信号，对应0-300bar压力值。软件必须通过ADC（模数转换器）通道3读取该值，并按线性比例计算实际压力。
  - 验证方法：
    - 测试： 模拟硬件给ADC通道3输入一个2.5V电压，看软件计算出的压力值是否为150bar（在允许误差范围内）。
    - 代码审查： 检查软件读取该信号的代码确实是指定了对ADC通道3的操作。
  - 潜在错误： 软件错误地配置为读取ADC通道2的信号，或者计算压力的公式错误（比如忘了除以2）。
c) 已定义的功能性**【可在系统合格性测试进行验证】**
- ISO解释： 验证集成后的软件作为一个整体，能正确地执行它被要求完成的所有具体工作任务（功能）。
- 通俗解释 (汽车角度)： 软件集成后，它负责的核心业务能力是否都实现了？比如，自动刹车软件能不能在探测到障碍物时刹停车辆？自动雨刮能不能根据雨量大小自动调整速度？车窗控制软件能不能让四个车窗按按钮要求升降？
- 例子：
  - 功能定义： 自适应巡航控制软件集成后，必须具备的功能包括：自动跟车保持设定距离、在驾驶员踩油门时暂时加速覆盖ACC、自动探测前车消失并加速到设定速度、探测到本车插入慢车道车辆后方时自动降速保持安全距离。
  - 验证方法： 搭建测试台架（或者用仿真软件），模拟各种驾驶场景（如前方车辆减速、加速、变道、切出等），输入相应信号（雷达数据、车辆速度信号、驾驶员操作信号等），检查集成软件输出的控制指令（油门、刹车）是否符合预期（即实现上述每个功能）。
  - 测试类型： 功能测试、黑盒测试（关注输入输出）、场景测试。
d) 指定的特性；【根据ASIL等级确定软件集成验证的实施程度】
示例：可靠性（没有不可访问的软件），鲁棒性（防止错误输入），可信赖性（有效的错误检测和处理）。可靠性（没有不可访问的软件），鲁棒性（防止错误输入），可信赖性（有效的错误检测和处理）。
示例：不存在无法访问的软件；具备有效的错误检测和处理。
- ISO解释： 验证集成后的软件除了能“做事”，还要具备一些非功能性但极其重要的品质，如可靠性、健壮性、可依赖性和易维护性（后面三项特别强调）。
- 通俗解释 (汽车角度)： 软件不能光会干活，还得“靠得住”、“不娇气”、“好养活”。重点关注：
  - 可靠性 (Reliability - No Dead Code)： 集成后的软件里有没有“僵尸代码”？也就是那些永远不会被执行到的代码（死代码），它们可能占据宝贵的内存和计算资源，浪费空间。
  - 鲁棒性 (Robustness)： 当遇到意想不到的坏数据或者不合理输入时（比如传感器突然发疯给了个超出范围的值，或者通信报文被干扰了），软件能不能“稳住”，不崩溃（蓝屏死机），还能做出合理的、安全的响应？
  - 可信赖性 (Trustworthiness - Effective Error Detection & Handling)： 当软件内部或外部真的发生错误时，它能不能及时准确地发现这个错误？发现后能不能采取正确的处理措施？比如切换到安全模式、发出报警、记录错误日志。这是功能安全的基石。
- 例子 (对应每个特性)：
  - 可靠性 (Dead Code)：
    - 检查方法： 进行代码覆盖率分析（如语句覆盖、分支覆盖）。在运行了所有能想到的正常和异常场景的测试用例后，看是否还有未执行到的代码块。
    - 结果： 如果发现有代码段从未被执行，则需要评估这些代码是否是必要的（如果是冗余的则删除），或者是测试用例不充分（需要补充测试）。
  - 鲁棒性 (Bad Input)：
    - 测试方法： 异常值/错误输入测试。 故意给软件接口输入不合理、超出范围、畸形的数据或信号。
    - 例子：
      - 给发动机ECU的油门踏板位置传感器输入一个超过最大允许值（比如>120%）的信号。
      - 给车窗控制信号发送一个同时要求升窗和降窗的矛盾指令。
      - 模拟网络通信丢包或干扰。
    - 期望结果： 软件能检测到这些无效输入，不会执行危险动作（如猛加速到超出安全范围），而是进入故障安全状态（如限制发动机扭矩，或者车窗保持不动），并报告错误（如仪表盘亮起故障灯）。
  - 可信赖性 (Error Detection & Handling)：
    - 测试/分析方法：
      - 故障注入测试 (Fault Injection)： 人为制造硬件或软件错误（比如模拟内存读写错误、CPU寄存器出错、关键任务超时），检查软件的错误检测机制能否捕捉到这个错误（日志记录？错误标志置位？），以及后续的安全处理机制（如重启、降级模式）是否被正确触发并执行。
      - 代码审查： 查看错误处理代码（如try-catch块、返回值检查、看门狗监控）的逻辑是否正确，覆盖了所有可能的错误点。
    - 例子：
    - 刹车控制系统软件内置了软件监控任务（Watchdog）和冗余计算校验。当人为注入错误导致主计算任务卡死，监控任务应能检测到超时，并激活备份计算通道（或触发安全刹车）。验证就是看这个过程是否如设计般工作。
e) 支持功能的足够资源；【软件集成验证重点关注】
- ISO解释： 验证集成后的软件运行所需的计算资源（CPU运算时间）、存储资源（RAM/ROM）和通信带宽在目标ECU上足够用，不会出现“跑不动”或“塞不下”的情况。
- 通俗解释 (汽车角度)： 拼装好的软件在ECU上跑起来后，会不会把“大脑”（CPU）累坏了？内存和闪存够不够装下它自己？跟别的ECU或内部模块“说话”会不会堵车（总线带宽）？必须在真实或模拟的目标硬件上确认这些核心资源是否够用、有余量（通常要求有余量，应对未来变更）。
- 例子：
  - 资源监控工具： 使用实时性能监控工具（如Lauterbach Trace32, iSYSTEM winIDEA，或芯片自带调试模块）：
  - 记录最坏情况下，所有任务（如引擎控制循环、刹车控制循环、通信任务）的执行时间，确保总执行时间小于一个控制周期的设定时间（如2ms）。防止CPU来不及算完，导致控制延迟甚至功能失效。
  - 监控实时运行时的RAM和栈空间峰值使用量，确保不会超过芯片内存大小和安全预留空间。防止堆栈溢出导致崩溃。
  - 测量串行通信或网络通信（如CAN, FlexRay, Ethernet）的实际带宽利用率，确保在最大负载情况下不会堵塞。
  - 结果： 如果发现任务A在最坏情况下用了1.8ms（周期是2ms），余量很小（0.2ms），就需要优化代码或提高硬件性能。如果RAM接近爆满（用了95%），需要削减功能或增加内存。
f) 如适用，根据7.4.10和7.4.11，从面向安全的分析得出的安全措施的有效性。
- ISO解释： 如果在安全分析（如FTA, FMEA）中发现某些故障可能导致危险结果，并为此设计了软件层面的安全措施（比如软件分区/隔离、内部监控诊断逻辑、冗余计算校验、安全库函数），那么需要验证在软件集成后，这些安全措施能够实际地、有效地工作。
- 通俗解释 (汽车角度)： 这是功能安全（Safety）的核心环节。集成时要检验那些为防止严重事故而设计的软件“保险丝”和“保镖”（安全机制）是否安装到位且真能起作用。
注1：安全措施可以包括软件分区。
- 关键安全措施例子 - 软件分区 (注1)：
  - 概念： 将软件划分为不同的、受保护的安全域（例如：ASIL D的高安全关键性功能 - 比如牵引力控制算法，和QM级的低安全关键性功能 - 比如电台UI）。利用芯片硬件（如内存保护单元MPU）或RTOS特性，严格限制它们之间的访问权限。
  - 目的： 防止低安全等级模块（万一出错）破坏或干扰高安全等级模块的运行（比如病毒般的错误数据覆写了关键的控制变量）。
- 验证方法 (f项)：
  - 静态分析：
  - 检查分区规则配置文件（如MPU配置、RTOS安全配置）是否正确实施，各分区的访问权限设定是否符合安全要求。比如高安全域内存能否被低安全域代码写入？不行！
  - 动态测试/故障注入 (结合d项可信赖性)：
  - 破坏性测试： 故意让运行在QM区的软件尝试非法访问ASIL D区控制算法的内存或变量。
  - 期望结果： 硬件MPU（或RTOS保护机制）必须立即检测到访问冲突，并触发错误（如抛出异常、重启低安全域任务、记录错误），保护高安全域不受侵害。
  - 关键路径测试： 在真实干扰环境下，测试内置的软件安全监控器（如程序流监控Plausibility Checks, 数值范围检查, 时间看门狗）是否能正确检测到注入的错误（比如篡改一个关键计算结果），并在规定的时间内触发定义的安全响应（如进入跛行回家模式）。
- 例子：
  - 设计：引擎管理软件使用MPU分区，将喷油控制算法（ASIL D）保护在一个分区，将空调控制算法（QM）放在另一个低权限分区。规定QM区代码绝对不能读写喷油控制分区的数据。
  - 验证：故意在空调控制代码里写一段企图篡改喷油量的指令，然后运行。结果是：硬件MPU检测到非法访问，CPU立即触发一个硬件错误中断，在该中断里软件（或系统）强制将空调控制任务踢出去或重启，同时引擎喷油控制模块毫发无损地继续正常工作。这就证明了分区安全措施的有效性。
注2：对于基于模型的开发，验证对象可以是与软件组件相关联的模型。
- 解释 (汽车角度)： 现在很多汽车软件是用图形化模型（如Simulink模型）来设计的，代码是由这些模型自动生成的。ISO 26262认可，在这种开发流程下，针对软件组件的集成验证不必等到生成了最终代码才进行，而是可以在模型级别就做！把相关的组件模型（比如几个不同团队开发的模块）集成在一起运行测试和检查，同样可以验证上面a-f项的很多要求。
- 优势： 更早发现问题（Shift-Left），降低后期集成风险，节省时间和成本。测试模型通常比测试硬件更容易设置和执行。
- 验证方法（模型级别）：
  - 模型在环测试（MIL - Model-in-the-Loop）： 将集成的组件模型放在仿真环境中运行测试用例（包括功能、鲁棒性测试）。
  - 软件在环测试（SIL - Software-in-the-Loop）： 将组件模型自动生成代码后，在PC上运行该代码进行测试。
  - 检查（通过模型验证工具）：
    - 检查模型集成结构是否与架构设计一致（对应a）。
    - 接口信号的连接在模型级别是否正确（对应a,b）。
    - 在模型中添加的监控和诊断逻辑（安全措施模型）能否检测错误输入或内部模型错误（对应d鲁棒性、可信赖性，f安全措施有效性）。
    - 估算模型（或生成代码）的资源消耗（对应e）。
- 例子： ADAS团队开发了雷达数据处理模型，车辆动力学团队开发了制动控制模型。在正式将代码刷入ECU前，先将这两个模型在仿真环境中连接起来进行集成测试（MIL/SIL）。测试场景：模拟前方车辆突然减速 -> 雷达模型探测到并输出目标信息 -> 制动控制模型接收并计算需要的制动力。验证这个过程是否符合架构设计（a），接口是否匹配（b），制动力计算是否正确（c），资源消耗是否合理（e）。同时可以注入雷达信号丢失错误，检验模型中内置的“信号有效性检查”安全机制是否能检测并触发警告（d, f）。