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

汽车功能安全-在系统层面验证TSR实例

news 2025/7/18 7:17:25

文章目录

1 TSR 需求分析
2 测试用例导出方法 (基于四个维度)
- 2.1 测试用例导出方法
- 2.2 测试方法
3 系统层面测试用例设计 (示例):
- 3.1 通用设置
- 3.2 测试用例列表
4 测试方法总结

1 TSR 需求分析

需求 ID: TSR-CCU-TSR-001 (示例)
需求描述： CCU接收【IDCU_LowBeamOnOff_Set】信号时应采用CAN E2E机制，用于检测CAN通信故障。具体实现详见profile1 E2E通信保护规范，应用的E2E机制包括超时检测/CRC校验/滚动计数器。当E2E机制检测到故障时，ECU应开启近光灯。FHTI < 500ms；包含 Effectiveness有效性、Accuracy精确度、Timing时序、Fault recover故障恢复的验证；
需求内容解析:
1. 触发条件: CCU 需要接收 IDCU_LowBeamOnOff_Set 信号。
2. 安全机制: 必须应用符合 Profile 1 E2E 通信保护规范的 CAN E2E 机制。
  - 包含要素：超时检测、CRC 校验、滚动计数器。
3. 故障检测要求: E2E 机制需有效检测 CAN 通信故障（包括物理层故障、协议层故障导致的报文丢失、损坏、延迟、乱序、伪装）。
4. 故障响应要求: 当 E2E 机制检测到IDCU_LowBeamOnOff_Set信号的通信故障时：
  - 操作：开启近光灯。
  - 性能：故障处理时间间隔 FHTI =超时时间）。
安全目标层面: 系统层面
- 安全状态: 近光灯开启 (这里开启近光灯是作为检测到IDCU_LowBeamOnOff_Set信号通信故障后的安全状态 或降级状态，以确保照明功能的基本可用性)。
- 核心要求:
  有效性: E2E 机制能否可靠检测各种类型的 CAN 通信故障？
  精确度: E2E 机制能否避免误报（将有效数据误判为故障）？能否精确识别是哪个具体报文的故障？
  时序: 从真实故障发生到近光灯开启，是否能稳定保证 <500ms？
  故障恢复: 故障被清除后，系统是否能恢复正常工作？
  测试关键: 注入或模拟特定类型的通信故障，并验证检测机制、响应动作及时序。

2 测试用例导出方法 (基于四个维度)

2.1 测试用例导出方法

需求分析： （ASIL A-D）
这是最核心的方法。将 TSR 需求拆解为不同的子项（E2E 各要素的检测能力、响应动作、时序要求），并针对每个子项设计正向和反向测试用例。
边界值分析： （ASIL C-D）
主要应用到超时机制（比如N倍报文周期超时）N=5。
- 报文N-1倍周期超时的情况。——>4
- 报文N倍周期超时的情况。——>5
- 报文N+1倍周期超时的情况。——>6
等价类生成与分析： （ASIL B-D）
适用于故障类型：
- 报文完全丢失（超时）: 连续抑制多个报文周期。
- 报文数据破坏: CRC 错误（随机错误/特定位错误）、数据场非法值。
- 报文序列错误: 滚动计数器错误（重复、跳变异常、超出允许窗口）。
- 报文延迟: 轻微延迟（<超时时间）、严重延迟（>=超时时间）。
基于知识或经验的错误猜测：（ASIL C-D）
- 在 CAN 总线负载极高时注入故障（资源争用）。
- 在 CCU 或 IDCU 刚启动的初始化阶段注入故障。
- 故障注入后快速清除，观察恢复过程是否正常。
- 模拟短暂的电磁干扰脉冲。
- 测试当多个 CAN 报文的 E2E 同时出现问题时，是否只影响了 IDCU_LowBeamOnOff_Set 的处理。

2.2 测试方法

基于需求的测试：（ASIL A-D）
这是最核心的方法。将 TSR 需求拆解为不同的子项（E2E 各要素的检测能力、响应动作、时序要求），并针对每个子项设计正向和反向测试用例，最后按照设计的用例完成测试。
故障注入： （ASIL B-D）
系统层面测试的关键方法。使用 HIL 平台注入特定的、可重复的故障到 CAN 总线（针对IDCU_LowBeamOnOff_Set 信号），例如：
- 注入 CRC 错误。
- 注入滚动计数器错误 (跳变异常、重复、超范围)。
- 抑制/删除 IDCU_LowBeamOnOff_Set 信号 (模拟超时)。
- 延迟发送 IDCU_LowBeamOnOff_Set 信号 (模拟延迟或导致超时)。
- 发送损坏的数据场（模拟通信噪声）。
- 发送更高优先级伪造报文抢占总线（模拟延迟或丢失）。

3 系统层面测试用例设计 (示例):

3.1 通用设置

系统处于正常工作状态（点火开启、车辆状态允许灯光工作）。
初始灯光状态：远光灯开启（或关闭），非近光灯开启状态 (以便清晰观察到状态变化)。
通过 HIL/SIL 平台监控：
- IDCU_LowBeamOnOff_Set 信号的发送 (IDCU 模拟)。
- IDCU_LowBeamOnOff_Set 信号的接收 (CCU 侧)。
- 注入的故障类型和注入时间点。
- 从注入时间点或故障真实发生点到 CCU 控制近光灯开启信号 (CCU_LowBeam_Control) 的时间差 (FHTI)。
- 实际的近光灯状态（如果有反馈信号）。

3.2 测试用例列表

1. 维度：有效性 (Effectiveness) & 精确度 (Accuracy) - 检测机制验证

用例名称1: TSR-CCU-E2E-001 - E2E超时故障检测与响应有效性验证
- 用例导出方法: 基于需求的测试+基于知识或经验的错误猜测+等价划分
- 测试方法： 基于需求的测试 + 故障注入测试
- 测试步骤:
  1. 配置 HIL 工具模拟 IDCU，周期性发送有效的 IDCU_LowBeamOnOff_Set 信号 (e.g., set=0 关闭近光)。
  2. 使用 HIL 工具注入故障：抑制连续 N （如：6）个周期的 IDCU_LowBeamOnOff_Set 信号的报文发送。N 需大于 E2E Profile1 超时检测的配置参数。例如：超时检测的配置参数=5
  3. 精确记录连续抑制 5 个报文周期后的时间点 T_inject (故障发生时间)。
  4. 监控 CCU 的输出信号 CCU_LowBeam_Control。
  5. 测量 T_inject 到 CCU_LowBeam_Control 变为开启状态 (或者对应状态变化) 的时间差 T_response。
  6. 重复步骤 2-5 多次（不同抑制周期数如：7、10、15）。
- 预期结果:
  - E2E 机制成功检测到超时故障（CCU 内部应有相关故障诊断代码置位）。
  - CCU 控制开启近光灯 (CCU_LowBeam_Control 输出对应开启状态)。
  - T_response < 500ms (验证有效性同时考虑了时序)。
用例名称2: TSR-CCU-E2E-002 - E2E CRC校验故障检测与响应有效性验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测 + 等价类 (坏CRC)
- 测试方法: 基于需求的测试 + 故障注入测试+错误猜测法
- 测试步骤:
  1. 配置 HIL 工具模拟 IDCU，周期性发送有效的IDCU_LowBeamOnOff_Set 信号。
  2. 使用 HIL 工具注入故障：篡改报文信号数据域并重新计算一个无效的 CRC 值，发送带有非法 CRC 的 IDCU_LowBeamOnOff_Set 信号的报文（可以是随机无效 CRC 或针对特定数据篡改）。
  3. 精确记录发送带有非法 CRC 信号的时间点 T_inject 。
  4. 监控 CCU_LowBeam_Control。
  5. 测量 T_inject到 CCU_LowBeam_Control 变为开启状态的时间差 T_response。
  6. 尝试不同数据篡改方式和 CRC 值（保证 ECC/CRC 校验必定失败）。
- 预期结果:
  - E2E 机制成功检测到 CRC 故障。
  - CCU 控制开启近光灯。
  - T_response < 500ms。

用例名称3: TSR-CCU-E2E-003 - E2E滚动计数器故障检测与响应有效性验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测 + 边界值 + 等价类 (计数器错误)
- 测试方法： 基于需求的测试+故障注入+错误猜测法
- 测试步骤:
  1. 配置 HIL 工具模拟 IDCU，周期性发送有效的IDCU_LowBeamOnOff_Set信号，滚动计数器正常递增。
  2. 使用 HIL 工具注入故障：
    - 场景 A (Counter Repeat): 发送连续多个相同滚动计数器的报文。
    - 场景 B (Counter Jump): 发送一个滚动计数器值突然跳变超过允许接收窗口的报文 (e.g., 从 5 跳到 10，假设窗口为 3)。
    - 场景 C (Counter Out-of-Range): 发送滚动计数器值为非法值的报文 (e.g., 大于协议允许的最大值，如最大15，实际发送16)。
  3. 精确记录发送第一个非法滚动计数器报文的时间点 T_inject。
  4. 监控 CCU_LowBeam_Control。
  5. 测量T_inject 到 CCU_LowBeam_Control 变为开启状态的时间差 T_response。
  6. 对每种场景重复测试。
- 预期结果:
  - 对发送的非法滚动计数器报文，E2E 机制成功检测到计数器故障。
  - CCU 控制开启近光灯。
  - T_response < 500ms。
用例名称4: TSR-CCU-E2E-004 - E2E机制精确度验证 - 有效报文处理无响应
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测
- 测试方法： 基于需求的测试 + 故障注入 -> 验证无误报 (False Positive)
- 测试步骤:
  1. 配置 HIL 工具模拟 IDCU，持续发送带有合法数据、有效 CRC、正确滚动计数器的 IDCU_LowBeamOnOff_Set 信号。
  2. 让系统长时间运行（远超过 E2E 检测周期）。
  3. 监控 CCU_LowBeam_Control。
  4. 监控 CCU 是否有与 IDCU_LowBeamOnOff_Set E2E 相关的故障诊断代码。
- 预期结果:
  - CCU 不会错误地开启近光灯（除非 IDCU_LowBeamOnOff_Set 内容本身指示开启）。
  - 没有与 IDCU_LowBeamOnOff_Set E2E 检测相关的故障诊断代码置位。
  - CCU 处理报文的行为与有效内容一致。验证了检测的精确度 - 无故障时不触发安全机制。
用例名称5： TSR-CCU-E2E-004 - E2E机制精确度验证 - 有效报文处理无响应-报文丢失未超时
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测
- 测试方法： 基于需求的测试 + 故障注入 -> 验证无误报 (False Positive)
- 测试步骤:
  1. 配置 HIL 工具模拟 IDCU，持续发送带有合法数据、有效 CRC、正确滚动计数器的 IDCU_LowBeamOnOff_Set 信号信号 (e.g., set=0 关闭近光)。
  2. 监控 CCU 的输出信号 CCU_LowBeam_Control且监控 CCU 是否有与 IDCU_LowBeamOnOff_Set E2E 相关的故障诊断代码。
  3. 使用 HIL 工具注入故障：抑制连续 N （如：2）个周期的 IDCU_LowBeamOnOff_Set 信号的报文发送。N 需小于 E2E Profile1 超时检测的配置参数。例如：超时检测的配置参数=5
  4. 恢复故障。
  5. 重复步骤 2-5 多次（不同抑制周期数如：3、4）。
- 预期结果:
  - CCU 不会错误地开启近光灯（除非 IDCU_LowBeamOnOff_Set 内容本身指示开启）。
  - 没有与 IDCU_LowBeamOnOff_Set E2E 检测相关的故障诊断代码置位。
  - CCU 处理报文的行为与有效内容一致。验证了检测的精确度 - 无故障时不触发安全机制。

2. 维度：时序 (Timing) - FHTI 严格要求

用例名称6: TSR-CCU-Timing-006 - E2E超时故障响应FHTI验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测 + 边界值分析
- 测试方法： 基于需求的测试+故障注入+错误猜测法
- 测试步骤:
  1. 同 TSR-CCU-E2E-001 步骤 1。
  2. 注入故障：抑制报文，确保触发超时（抑制时间略大于 E2E 配置的超时阈值）。
  3. 使用 高精度计时器/示波器 精确测量：
    - T0: 最后一个有效的 IDCU_LowBeamOnOff_Set 信号预期到达时间 + E2E 超时时间阈值 (模拟实际判定为故障的时间点)。
    - T1: CCU_LowBeam_Control 输出变为开启状态的精确时间点。
  4. 计算 FHTI = T1 - T0。
  5. 重复多次测试 (不同负载条件 - 如总线负载 30%， 80%)。
- 预期结果:
  - 在所有测试中，实测 FHTI < 500ms (严格满足)。
  - FHTI 的分布应相对稳定。
用例名称7: TSR-CCU-Timing-007 - E2E CRC错误响应FHTI最坏情况验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测 + 边界值分析
- 测试方法： 基于需求的测试+故障注入+错误猜测法
- 测试步骤:
  1. 同 TSR-CCU-E2E-002 步骤 1。
  2. 注入故障：发送一个带有非法 CRC 的报文。
  3. 使用 高精度计时器/示波器 精确测量：
    - T0: 非法 CRC 报文实际到达 CCU 节点的 CAN 控制器接收引脚的时间点 (故障发生时间点)。
    - T1: CCU_LowBeam_Control 输出变为开启状态的精确时间点。
  4. 计算 FHTI = T1 - T0。
  5. 在 高总线负载 (接近 100%) 条件下重复多次此测试（此时CPU调度、总线延迟可能最差）。
- 预期结果:
  - 在所有测试中，实测 FHTI < 500ms (即使在最坏情况负载下)。

3. 维度：故障恢复 (Fault Recover)

用例名称8: TSR-CCU-Recovery-008 - E2E超时故障恢复后正常行为验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测
- 测试方法： 基于需求的测试+故障注入+错误猜测法
- 测试步骤:
  1. 执行 TSR-CCU-E2E-001 (或类似)，触发超时故障导致近光灯开启。
  2. 在确认近光灯已开启并稳定后 (T_inject + FHTI + margin)。
  3. 停止故障注入，恢复 IDCU 正常发送有效的 IDCU_LowBeamOnOff_Set 报文。
  4. 监控：
    - E2E 相关故障诊断代码的状态。
    - CCU_LowBeam_Control 输出信号。
    - 实际的近光灯状态。
  5. 让系统运行一段时间，包含正常切换 IDCU_LowBeamOnOff_Set (e.g., set=0 关闭近光， set=1 开启近光)。
- 预期结果:
  1. 恢复通信后，E2E 相关故障诊断代码应在合理时间内清除。
  2. CCU 应能正常接收并解析 IDCU_LowBeamOnOff_Set。
  3. CCU_LowBeam_Control 输出（以及近光灯状态）不再强制保持开启，而是跟随 IDCU_LowBeamOnOff_Set 信号的有效内容变化 (如果内容是 set=0，应能关闭近光；如果是 set=1，保持开，但响应的是正常指令而非故障响应)。
用例名称9: TSR-CCU-Recovery-009 - 瞬态E2E错误检测与自动恢复验证
- 用例导出方法: 需求分析 + 基于知识或经验的错误猜测
- 测试方法： 基于需求的测试+故障注入+错误猜测法
- 测试步骤:
  1. 配置 IDCU 持续发送有效报文。
  2. 注入一个非常短暂的故障：
    - 场景 A: 注入单个无效 CRC 报文（仅一帧）。
    - 场景 B: 连续注入 1-2 个无效计数器报文（未达到 E2E 触发阈值的瞬时抖动）。
  3. 监控：
    - E2E 相关故障诊断代码的状态 (应瞬时置位又清除？或被过滤？这取决于内部计数策略）。
    - CCU_LowBeam_Control 输出信号。
  4. 观察系统在短暂的 E2E 检测失败后，是否自动恢复，并且 未触发 开启近光灯的错误响应 (因为瞬时错误可能被过滤或未达到安全机制触发条件——实际项目根据需求决定)。
- 预期结果:
  - CCU 可能在内部记录瞬态故障 (DTC)，但不应触发开启近光灯的安全响应。（实际项目需求为准）
  - CCU_LowBeam_Control 不应因该短暂错误而开启（除非 IDCU_LowBeamOnOff_Set 内容要求开启）。
  - 系统在处理完该瞬时故障报文后，立即恢复正常接收和处理后续有效报文。验证了安全机制避免因瞬时错误进入降级模式的能力。

4 测试方法总结

硬件在环测试 (HIL - Hardware-in-the-Loop): 这是进行系统层面 E2E 测试的最常用、最有效方法。HIL 台架可以：
- 精确模拟 IDCU 的 CAN 消报文发送。
- 精确注入各种类型的 CAN 通信故障 (超时模拟、错误数据/CRC/计数器注入、总线负载控制)。
- 实时监控 CCU 的输出 (如 CCU_LowBeam_Control)。
- 通过示波器、高精度记录设备或 HIL 板卡自身 IO 直接测量 FHTI。
- 模拟真实的 ECU 电气环境和部分车辆网络。
软件在环测试 (SIL - Software-in-the-Loop):【软件集成阶段】在早期或在缺乏 HIL 资源时，可以使用 SIL 来验证 CCU 应用逻辑（故障标志处理、灯光控制决策）以及时序估算。但 SIL 很难精确模拟 CAN 协议栈延迟、硬件中断响应等影响 FHTI 的关键因素，也无法验证物理通信故障。对通信和时序要求严格的系统层面测试，SIL 只能作为辅助。
系统级集成台架 (带真实 CANoe/CANalyzer): 如果包含真实 CCU、IDCU、网关和灯光的台架可用，CANoe/CANalyzer 可用于监控总线、注入一些故障（如节点模拟、报文修改）、记录数据。但其对时序测量的精度通常不如专用 HIL，且注入硬性物理层故障比较困难。
测量工具: 必须使用高精度工具（如示波器、HIL 板卡内部时间戳）测量 FHTI。