汽车功能安全-相关项集成和测试（系统集成测试&系统合格性测试）-12

1 目标

在功能安全开发过程中，相关项（即我们要确保安全的关键功能子系统，如刹车控制系统、动力转向系统、高级驾驶辅助系统ADAS等）完成设计后，必须经历的一个关键阶段：集成和测试。这个阶段分三步走，就像搭积木一样层层叠加并验证。

目标：
相关项集成和测试阶段包含三个子阶段和三个主要目标：

• 第一个子阶段是相关项所包含的每一个要素的软硬件集成；
• 第二个子阶段是构成一个完整系统的一个相关项的所有要素的集成；
• 第三个子阶段是相关项与车辆上其它系统的集成以及与整车的集成。

1. 子阶段一：要素级集成与测试 (Element Integration)

   • 做什么： 把组成相关项的最基础的部件（“要素”）组装并测试。要素通常指的是硬件组件（如：ECU板子上的处理器芯片、传感器模组、驱动电路）和运行在其上的基础软件（如：实时操作系统RTOS的驱动、通信栈）。
   • 目标： 确保这些硬件元件焊接连接正确，软件能加载运行，驱动能控制硬件，要素内部能正常工作。这是最底层的集成测试。

2. 子阶段二：相关项（系统）级集成与测试 (Item Integration)

   • 做什么： 把所有经过子阶段一测试好的要素（硬件+软件），按照系统设计图纸（系统架构），组装成一个完整、独立的相关项系统。例如，把ECU板、传感器、执行器等所有硬件，配上完整的应用软件，装在一起成为一个完整的刹车控制器硬件单元。
   • 目标： 确保相关项内部所有要素能协调工作，互相通信（比如传感器信号能正确传给处理软件，软件计算后能驱动执行器）。这个测试是在台架（Bench）或实验室环境完成的，关注整个相关项本身的功能和内部接口。

3. 子阶段三：整车级集成与测试 (Vehicle Integration)

   • 做什么： 把组装好的、独立的相关项系统（如那个刹车控制器），安装到真实的汽车上，连接到它该连的东西：
     • 车上其它系统：比如连到车身控制模块(BCM)获取车速信号，连到动力总成系统获取油门开度，连到仪表盘显示报警灯。
     • 整车环境：接受车辆的电源、振动、电磁干扰等真实环境的影响。
   • 目标： 测试该相关项在真实的车辆运行环境中，与其他系统协同工作时，功能是否正常，特别是安全功能是否按预期工作（比如检测到碰撞风险时是否能正确启动刹车）。

ISO26262定义的第七章的目的是：
a) 确定集成步骤，整合系统要素，直到系统完全集成；
b) 验证根据系统架构层面的安全分析所确定的安全措施是否已经实施；
c) 根据系统架构设计，提供集成的系统要素满足其安全要求的证据。

总之，ISO 26262 中描述的系统集成和测试阶段，就是要求汽车功能安全开发按照 “由小到大、由里到外” 的严谨步骤，把功能安全相关的系统组装和验证出来。核心是：

1. 计划性（a）: 确保有条不紊，步步为营。
2. 抓落实（b）: 确保之前纸上谈兵的“安全主意”真正变成了产品里实打实的“安全功能”，并且真的能救命！
3. 拿证据（c）: 用科学、客观、详实的测试数据和报告来证明这个系统确实“安全可靠”。

在汽车行业，这个过程依赖于严格的测试规范、先进的测试设备（HIL/SIL，试验场），以及一丝不苟的记录和文档管理，最终为车辆上路的安全提供重要的技术保障。

2 输入物

相关项要素的集成按照系统化的方法进行，从软硬件集成开始，经过系统集成，最后完成整车集成。在每个集成阶段要进行特定的集成测试，以证明所集成的要素之间交互的正确性。
在根据ISO 26262-5和ISO 26262-6对硬件和软件进行充分的开发之后，可以根据本章的规定开始系统集成。

1. 根据ISO 26262-3：2018，6.5.1的规定所确定的危害分析和风险评估报告中的安全目标；【整车级测试】
2. 技术安全规范TSR，按照6.5.2；【系统层面测试】
3. 系统架构设计规范，按照6.5.3；【系统层面测试】
4. 软硬件接口（HSI）规范，按照6.5.4, ISO 26262-5:2018, 6.5.2 和ISO 26262-6:2018, 6.5.2。【系统层面测试】

3 要求和建议

为证明系统设计符合功能和技术安全要求，应按照ISO 26262-8:2018第9章执行集成测试活动。

1. 功能安全要求和技术安全要求的正确实施；
2. 安全机制正确的功能表现、准确性和时序；
3. 接口实现的一致性与正确性；及
4. 鲁棒性水平。

集成和测试策略：
集成和测试策略的确定应该综合考虑系统架构设计规范、TSR。它应该解决：

1. 适合为功能安全提供证据的测试目标；及
2. 有助于安全概念的相关项及其要素的集成和测试。
   注：包括有助于安全概念的其他技术要素。

为了实现相关项集成的子阶段，应该在集成和测试策略的基础上进行以下操作：

1. 为硬件-软件集成和测试制定相关项集成和测试策略；
2. 所确定的相关项集成和测试策略应该包括在系统和车辆层面进行集成测试的规范。应该确保硬件-软件验证过程中的未决问题得到解决；
3. 相关项集成和测试策略应该考虑车辆系统（相关项内部和外部）与环境之间的接口；及
4. 相关项集成和测试策略应该考虑是否正在集成作为独立安全要素（SEooC）而开发的系统或要素，以及是否需要对开发过程中所做的假设进行验证。
   注：在硬件-软件集成层面和相关项层面上所进行集成和验证的规范考虑了硬件和软件之间的接口和相互作用。

至少应该在子阶段完全集成的时候对每项功能安全和技术安全需求的实施情况进行一次验证（如适用，可以采用测试)。
注1：通常做法是在指定的下一个更高层面的集成中验证安全要求。
注2：如果将独立安全要素（SEooC）集成到与安全相关的系统中，也就验证了其开发时所用假设的有效性。
注3：对于集成测试期间确定的安全异常，应该按照ISO 26262-2：2018，5.4.3的规定进行报告。

4 测试用例导出方法

为了恰当的定义集成测试的测试用例，应考虑集成的层面，使用表3中所列的恰当的方法组合导出测试用例。

表3 导出集成测试用例的方法：

1. 需求分析

• 专业解释：基于技术安全需求（TSR），导出验证系统是否满足安全目标的测试用例。
• 通俗理解：根据设计文档中的安全要求清单，逐一检查系统是否达标。
• 汽车示例：对自动紧急制动系统（AEB）的测试用例需覆盖 “车速超过30km/h时检测到障碍物必须触发制动” 的需求。

2. 外部和内部接口分析

• 专业解释：分析系统与传感器、执行器等外部组件的通信协议（如CAN/LIN），以及软件/硬件内部数据交换逻辑（比如根据软硬件接口接口规范-HSI）。
• 通俗理解：测试各个模块连接处的数据传递是否正确，避免"信号传丢或传错"。
• 汽车示例：测试雷达传感器发送的障碍物距离信号是否被ECU准确接收，且未在网关转发时被篡改。

3. 软硬件集成等价类生成与分析

• 专业解释：将输入数据划分为有效/无效区间（等价类），选择代表值测试软硬件交互边界。
• 通俗理解：将温度值分为 “正常范围”、“过高”、“过低” 三组，每组选典型值测试。
• 汽车示例：电池管理系统（BMS）测试：
  • 有效类：电池电压在3.0~4.2V
  • 无效类：电压<2.0V（触发故障诊断）
  • 边界值：2.0V、4.2V

4. 边界值分析

• 专业解释：针对输入/输出参数的边界条件（如最小值、最大值）设计用例。
• 通俗理解：测试极端数值下系统是否崩溃（如把车速加到理论最大值）。
• 汽车示例：测试电子助力转向（EPS）在方向盘转角极限值±900度时是否正常复位。

5. 错误猜测法（基于经验）

• 专业解释：依据历史失效数据或专家经验，模拟常见人为错误或环境干扰场景。
• 通俗理解："故意使坏"测试系统容错能力。
• 汽车示例：
  • 模拟驾驶员在倒车雷达工作时突然拔掉传感器插头
  • CAN总线注入错误报文测试ECU异常处理

6. 功能的相关项分析

• 专业解释：识别多功能交互时的冲突（如转向与自动泊车同时请求）。
• 通俗理解：测试多个功能打架时系统如何仲裁。
• 汽车示例：同时开启ACC巡航和车道保持系统时，验证方向盘控制权优先级策略。

7. 相关失效的共因分析（CCA）

• 专业解释：检测多个组件因共同原因（如电压骤降）同时失效的防护措施。
• 通俗理解：防止 “一颗螺丝坏导致整个机器瘫痪”。
• 汽车示例：测试12V蓄电池断电时，备份电源能否维持电子制动系统（EBB）的液压泵运行。

8. 环境与操作用例分析

• 专业解释：模拟温湿度、振动、电磁干扰等物理环境及用户误操作场景。
• 通俗理解：测试 “夏天暴晒+颠簸路段+司机狂按按钮” 的组合影响。
• 汽车示例：
  • 高温（85℃）下测试车载中控屏触控响应
  • 模拟砂石路面振动时测试胎压监测信号稳定性

9. 现场经验分析

• 专业解释：基于售后故障数据或路测记录补充用例，覆盖真实场景漏洞。
• 通俗理解：用真实事故教训指导测试设计。
• 汽车示例：某车型因雨水渗入导致雷达误报后，新增高压水枪喷射雷达模块的防水测试用例。

总结：汽车系统测试用例设计策略

通过上述方法组合，汽车系统集成测试可覆盖：功能正确性（需求分析）、接口可靠性（内外部接口）、鲁棒性（边界值/错误猜测）、系统协同（相关项分析）及真实风险（现场经验）五大安全维度。