汽车功能安全核心时间参数解析（FTTI 等）

在汽车功能安全（ISO 26262）中，时间参数是衡量安全机制有效性的核心指标，直接决定系统能否在故障发生后及时避免危害事件。以下是对FTTI、FDTI、FRTI、FHTI、MBMT、HMT等关键时间参数的系统解析，包含标准定义、计算公式、应用场景与汽车行业实例。

一、核心时间参数总览（ISO 26262:2018 定义）

参数缩写	英文全称	中文名称	核心定义	关键作用
FTTI	Fault Tolerant Time Interval	故障容错时间间隔	安全机制未激活时，从相关项故障发生到可能出现危害事件的最短时间	系统安全设计的硬约束，决定故障检测与响应的最大允许时间窗口
FDTI	Fault Detection Time Interval	故障探测时间间隔	从故障发生到被安全机制检测到的时间间隔	衡量诊断系统的响应速度，直接影响安全机制启动及时性
FRTI	Fault Reaction Time Interval	故障响应时间间隔	从故障被检测到系统进入安全状态的时间间隔	评估安全机制的执行效率，如制动系统介入速度、动力切断时间
FHTI	Fault Handling Time Interval	故障处理时间间隔	故障发生到系统完成故障处理（检测 + 响应）的总时间，即FDTI + FRTI	验证安全机制是否满足 FTTI 约束的核心指标，必须FHTI ≤ FTTI
MBMT	Mission-Boundary Miss Time	任务边界错过时间	故障导致系统偏离正常任务边界到触发安全机制的时间	用于 FTTI 分解，描述故障对系统功能的影响延迟
HMT	Hazard Mitigation Time	危害缓解时间	从触发安全机制到完全消除危害的时间	与 MBMT 共同构成 FTTI，决定安全机制的最小有效时间
FHF	Fault Hold-off Time	故障保持时间	故障持续存在且未被检测到的最长允许时间	针对间歇性故障，防止安全机制误触发
FPTI	Fault Propagation Time Interval	故障传播时间间隔	故障从发生位置传播到系统关键路径的时间	评估系统架构的故障隔离能力

---

二、核心参数深度解析

1. FTTI（故障容错时间间隔）— 安全设计的 “红线”

• 标准原文定义：Minimum time-span from the occurrence of a fault in an item to a possible occurrence of a hazardous event, if the safety mechanisms are not activated (or no safety mechanism)
• 通俗理解：如果没有安全机制干预，故障从发生到导致事故的 “倒计时”，是系统必须在此时间内完成故障处理的硬性指标
• 计算公式：
  • 分解公式 1（功能维度）：FTTI = MBMT + HMT
  • 分解公式 2（安全机制维度）：FTTI = FDTI + FRTI = FHTI
• 汽车场景实例（AEB 系统）：
  • 顶事件：AEB 检测到障碍物未触发制动导致碰撞
  • FTTI：假设故障发生到碰撞的最短时间为500ms（车速 80km/h 时，5m 距离的碰撞时间）
  • 约束：安全机制必须在500ms 内完成故障检测（FDTI ≤ 200ms）和制动响应（FRTI ≤ 300ms），即 FHTI ≤ 500ms
• ASIL 等级影响：ASIL 等级越高，FTTI 要求越严格（如 ASIL D 可能要求 FTTI <100ms，ASIL A 可能允许 FTTI> 1s）

2. FDTI + FRTI = FHTI — 安全机制的 “执行效率”

• FDTI（故障探测时间）：
  • 包含信号采集延迟、诊断算法运行时间、ECU 处理延迟等
  • 硬件故障示例：传感器短路→信号异常→诊断模块检测→报警，耗时80ms
  • 软件故障示例：逻辑错误→输出异常→校验码错误→系统检测，耗时150ms
• FRTI（故障响应时间）：
  • 包含安全机制启动时间、执行器响应时间、系统状态切换时间
  • 制动系统示例：ECU 发出制动指令→电磁阀动作→液压建立→制动力输出，耗时250ms
  • 动力系统示例：检测到电机故障→切断高压电路→动力输出为零，耗时100ms
• FHTI（故障处理总时间）：
  • 必须严格满足FHTI ≤ FTTI，否则安全机制失效
  • 验证方法：通过失效注入测试测量实际 FDTI 和 FRTI，与 FTTI 对比

3. MBMT + HMT = FTTI — 危害发生的 “时间分解”

• MBMT（任务边界错过时间）：
  • 描述故障对系统功能的影响延迟，如传感器漂移→数据错误→系统偏离正常工作范围的时间
  • 示例：雷达传感器故障→距离测量误差→AEB 系统未识别障碍物，MBMT = 120ms
• HMT（危害缓解时间）：
  • 描述安全机制消除危害的必要时间，与系统动态特性相关
  • 示例：AEB 系统触发制动→车辆减速→避免碰撞，HMT = 380ms
• 关系：MBMT + HMT = 500ms = FTTI，确保系统在危害发生前完成缓解

三、关键时间参数的应用与验证

1. 安全机制设计的核心流程

plaintext

定义安全目标 → 识别危害场景 → 计算FTTI → 分解FDTI/FRTI → 设计诊断/响应机制 → 验证FHTI ≤ FTTI

• FTTI 确定方法：
  1. 基于危害分析与风险评估（HARA），确定危害事件的触发条件与时间窗口
  2. 结合车辆动力学模型，计算故障到碰撞 / 失控的最短时间（如车速、距离、制动性能）
  3. 参考 ISO 26262-5 附录 D，结合零部件故障率与诊断覆盖率

2. 汽车系统典型 FTTI 数值参考

系统类型	ASIL 等级	FTTI 典型值	FDTI 要求	FRTI 要求	安全机制示例
AEB 自动紧急制动	C/D	300-500ms	≤200ms	≤300ms	双雷达冗余、制动系统快速介入
ESC 电子稳定控制	D	100-200ms	≤50ms	≤150ms	轮速传感器诊断、扭矩矢量分配
EPS 电动助力转向	B/C	500-1000ms	≤200ms	≤800ms	电机故障诊断、机械备份机构
高压电池管理	D	50-100ms	≤20ms	≤80ms	绝缘监测、高压接触器快速断开

3. 验证方法（ISO 26262-4/5 要求）

1. 台架测试：通过失效注入（如断开传感器、注入错误信号）测量 FDTI/FRTI
2. 整车测试：在受控环境下模拟故障场景，验证安全机制响应时间
3. 仿真分析：使用车辆动力学模型（如 CarSim）计算 FTTI，评估安全机制设计合理性
4. 文档化验证：记录 FTTI 计算过程、FDTI/FRTI 测试数据，形成安全分析报告

---

四、常见误区与注意事项

1. FTTI 不是 “越长越好”：过长的 FTTI 可能导致安全机制设计冗余，增加成本；过短则可能超出技术实现能力
2. 区分 “硬件随机故障” 与 “软件系统性故障”：
   • 硬件故障：可通过故障率数据量化 FTTI，如电容失效（λ=100Fit）
   • 软件故障：FTTI 更多依赖场景分析，如逻辑错误的触发条件与影响范围
3. 诊断覆盖率（DC）对时间参数的影响：
   • 诊断覆盖率越高，FDTI 越短（故障被快速检测）
   • 需在故障树（FTA）中体现 “故障 + 诊断失效” 的与门关系，即只有当故障发生且诊断失效时，才会超出 FTTI 导致危害
4. ISO 26262:2018 的更新：第二版明确区分 FDTI/FRTI/FHTI，强调 FHTI 必须≤FTTI，为安全机制设计提供更清晰的时间约束

总结

FTTI 是汽车功能安全的核心时间约束，FDTI 与 FRTI 是实现 FTTI 的两个关键环节，FHTI 则是安全机制执行效率的最终体现。在实际开发中，需通过危害分析确定 FTTI，合理分配 FDTI/FRTI 指标，设计高效的诊断与响应机制，并通过严格测试验证 FHTI ≤ FTTI，确保系统在故障发生时能及时避免危害事件。

FTTI 测试方法及测量时刻判定标准

依据 ISO 26262 标准定义，FTTI（Fault Tolerant Time Interval，故障容错时间间隔）是指 “安全机制未激活时，从相关项故障发生到可能出现危害事件的最短时间间隔”。实车测试的核心目标是精准捕获这一 “最短时间”，需严格界定测量的起始与停止时刻，同时通过规范的测试流程保障结果有效性。本文将详细说明 FTTI 实车测试方法，重点明确时间测量的关键节点。

一、FTTI 实车测试核心原则

1. 安全优先：实车测试需规避真实危害事件（如碰撞、失控）发生，可通过场地 VIL（Vehicle in Loop）虚实结合技术、预设安全防护措施（如缓冲装置、测试场地隔离）降低风险；

2. 严苛工况：需选取 “故障发生至危害事件时间最短” 的最严苛工况（如最高车速、最近障碍物距离、最差路面附着系数），确保测试结果覆盖极限风险场景；

3. 安全机制禁用：测试过程中需临时禁用目标系统的安全机制（如诊断功能、故障响应策略），贴合 FTTI “安全机制未激活” 的定义前提；

4. 高精度同步：采用高精度数据采集设备，确保故障发生、车辆状态、环境参数等数据的时间戳同步，测量精度需≤1ms。

二、FTTI 实车测试完整流程

1. 测试前准备

• 工况定义：基于 HARA（危害分析与风险评估）结果，确定测试工况参数，包括车辆速度、载荷状态、障碍物距离 / 速度（针对 ADAS 系统）、路面附着系数等；

• 环境搭建：选择封闭测试场地（如专业试车场），搭建符合工况要求的测试场景，若需模拟虚拟障碍物可部署 VIL 系统，通过数字孪生技术实现虚实结合场景复现；

• 设备部署：安装高精度惯导组合（定位精度 1-2cm 级）、CAN 总线记录仪、制动压力传感器、车速传感器、高速摄像机等，所有设备统一时间基准；

• 安全配置：部署物理防护装置（如防撞缓冲墙），设置测试紧急终止触发条件（如车辆偏离安全轨迹、距离障碍物过近）；

• 系统预处理：将车辆及目标系统（如 AEB、ESP）置于正常工作状态，预热至正常工作温度，临时禁用系统安全机制并记录状态。

2. 故障注入与数据采集

• 启动测试：车辆进入预设工况并稳定运行（如 AEB 系统测试中，车速稳定至 80km/h，前方 5m 处设置静止障碍物）；

• 故障注入：通过主动故障注入方式触发目标故障，注入方法包括软件注入（如通过 CANape 向 ECU 发送错误信号）、硬件注入（如物理断开传感器线束、短接执行器电路）；

• 数据记录：从故障注入开始，持续采集故障状态信号、车辆运动参数（车速、加速度、位姿）、障碍物距离等数据，直至触发紧急终止条件或判定危害事件临界状态。

3. 数据处理与结果判定

• 提取关键时间点：从采集的数据中识别 “故障发生时刻” 和 “危害事件临界时刻”，计算两者时间差即为 FTTI；

• 重复性验证：同一工况重复测试 3 次以上，取最短时间作为最终 FTTI 结果（符合 “最短时间间隔” 定义）；

• 工况覆盖：依次完成所有预设严苛工况测试，确认不同工况下 FTTI 的最小值，作为系统安全设计的核心约束。

三、实车 FTTI 测量：起止时刻判定标准

FTTI 的核心是 “故障发生→危害事件临界状态” 的时间间隔，实车测试中需通过可量化的物理信号或状态变化来精准界定这两个时刻，避免主观判断误差。

1. 测量起始时刻（T0）：故障实际发生时刻

定义：目标系统出现预设故障的物理起始瞬间，需通过客观信号特征判定，而非故障被诊断或报警的时刻（区别于 FDTI 的起始时刻）。

判定依据及示例：

系统类型	故障类型	起始时刻（T0）判定标准
AEB 系统	毫米波雷达信号丢失	雷达向 ECU 输出的有效数据信号中断的瞬间（通过 CAN 总线记录仪监测，雷达信号帧停止传输或信号值跳变为无效范围的时刻）
ESP 系统	轮速传感器故障	轮速传感器输出信号的频率 / 幅值突变至无效范围的瞬间（通过示波器监测传感器信号波形变化）
主动悬架系统	执行器卡滞	悬架执行器液压压力突然恒定不变，且偏离正常控制目标值 ±10% 以上的时刻（通过压力传感器数据判定）
关键说明：若采用软件注入故障，T0 为 “错误信号被目标系统接收并生效的时刻”，而非注入指令发出时刻（需考虑信号传输延迟）。

2. 测量停止时刻（T1）：危害事件临界时刻

定义：车辆即将发生不可接受危害事件的临界状态瞬间，实车测试中不允许等待真实危害事件（如碰撞、侧翻）发生，需提前定义可量化的临界判定指标。

核心判定原则：基于整车动力学特性，选取 “车辆状态超出安全可控范围” 或 “距离危害事件发生仅存最小安全冗余” 的客观指标。

判定依据及示例：

系统类型	危害事件	停止时刻（T1）判定标准
AEB 系统	车辆与前方障碍物碰撞	车辆与障碍物的距离缩小至 “最小安全制动距离” 的瞬间（如基于当前车速计算，剩余距离仅能满足制动系统最小响应时间需求，约 0.5m；或通过激光测距仪监测距离≤0.5m）
ESP 系统	车辆侧滑失控	车辆质心侧偏角达到 ±8°（乘用车安全临界值），或车轮滑移率超过 30% 的瞬间（通过惯导系统、轮速传感器数据判定）
主动悬架系统	整车姿态失控（侧翻 / 俯仰）	车辆侧倾角达到 15°（侧翻临界阈值），或车身高度偏离正常范围 ±50mm 的瞬间（通过惯导系统、悬架位移传感器数据判定）

3. FTTI 计算：ΔT = T1 - T0

通过高精度数据采集设备提取 T0 和 T1 对应的时间戳，两者差值即为实测 FTTI。例如：AEB 系统测试中，T0=1000ms（雷达信号中断时刻），T1=1225ms（车辆与障碍物距离≤0.5m 时刻），则 FTTI=1225ms-1000ms=225ms。

四、实车测试关键注意事项

1. 临界指标校准：不同车型、系统的危害临界指标（如侧偏角、最小安全距离）需结合整车动力学仿真结果和实车摸底试验校准，确保与真实危害事件的关联性；

2. 数据同步性：所有采集设备需统一时间基准（如通过 PTP 时钟同步），避免因时间偏差导致 FTTI 计算误差；

3. 故障单一性：测试中仅触发目标单一故障，避免多故障叠加导致 FTTI 结果失真；

4. 替代测试补充：对于无法在实车层面安全模拟的极端故障场景，可通过硬件在环（HIL）测试补充验证，确保 FTTI 覆盖所有严苛工况；

5. 合规性记录：完整记录测试工况、故障注入方法、数据采集过程、判定指标等信息，形成可追溯的测试报告，作为功能安全合规性验证的依据。

五、FTTI 时间验证方法（测试层面）

测试中对 FTTI 时间的验证核心是 “确认测量结果准确、符合标准定义、覆盖极限风险”，需从数据有效性、结果重复性、场景覆盖性三个核心维度开展验证，具体方法如下：

1. 数据有效性验证：确保起止时刻识别准确

核心目标：验证 T0（故障发生时刻）和 T1（危害临界时刻）的识别依据客观、无误差，是 FTTI 时间验证的基础。

• 时间同步精度验证：通过设备日志核查所有采集设备（CAN 总线记录仪、惯导系统、示波器）的时间同步偏差，要求同步误差≤1ms；可通过触发同一参考信号（如 ECU 唤醒信号），对比不同设备的时间戳，确认同步有效性；

• 信号特征有效性核查：针对 T0、T1 的判定信号（如雷达数据中断、质心侧偏角阈值），复盘信号波形 / 数据曲线，确认判定时刻为 “信号首次出现有效异常的瞬间”，无提前或滞后判定；例如雷达信号丢失需确认是 “连续 3 个周期无有效数据” 的起始时刻，而非单个周期波动时刻；

• 人工复核与自动化校验结合：采用 “自动化算法提取时间戳 + 人工复核数据曲线” 的方式，避免单一算法识别的偏差；对关键工况（如最高车速、最近障碍物）的 FTTI 数据，需由 2 名以上测试工程师独立复核确认。

2. 结果重复性验证：确保 FTTI 为 “最短时间间隔”

依据 ISO 26262 对 FTTI “最短时间” 的定义，需通过多轮重复测试验证结果的稳定性，排除偶然因素影响：

• 同工况重复测试：同一测试工况（如 AEB 系统 80km/h+5m 障碍物）至少重复测试 3 次，要求 3 次测试的 FTTI 差值≤10ms；若差值过大，需排查故障注入一致性、设备稳定性等问题；

• 最短时间筛选验证：对比同工况多次测试结果，确认最终选取的 FTTI 为 “最小值”；若某一次测试结果明显偏长（如超出其他次数 20ms 以上），需分析是否存在故障注入延迟、车辆状态波动等干扰因素，该次结果不计入有效数据；

• 设备重复性校准：测试前后对数据采集设备进行精度校准（如惯导系统定位精度、示波器采样精度），确保设备自身重复性误差≤0.5ms，避免设备误差导致 FTTI 结果波动。

3. 场景覆盖性验证：确保 FTTI 覆盖所有极端风险

FTTI 是系统安全设计的硬约束，需验证其在所有可能的极端工况下均能满足要求，避免遗漏高风险场景：

• 全工况覆盖验证：依据 HARA 分析结果，逐一验证所有 “故障发生至危害事件时间最短” 的严苛工况，包括不同车速（从设计最高车速到临界工作车速）、载荷（满载 / 空载）、路面附着系数（干燥 / 湿滑 / 冰雪）、环境温度（-40℃~85℃）等；

• 边界工况专项验证：针对系统工作边界的特殊工况（如 AEB 系统最低激活车速、ESP 系统极限转向角），单独开展 FTTI 测试，确认边界工况下 FTTI 仍满足安全约束；

• 跨系统交互验证：若目标系统与其他系统存在交互（如 AEB 与 ESP 协同工作），需验证交互场景下的 FTTI，避免因系统间信号交互延迟导致 FTTI 缩短。

4. 合规性验证：符合 ISO 26262 标准要求

测试过程需形成完整的合规性证据链，验证 FTTI 测试结果可作为功能安全设计的依据：

• 测试流程合规性：确保测试流程符合 ISO 26262-4/5 中关于 “安全机制验证” 的要求，包括测试计划审批、风险评估记录、测试人员资质证明等；

• 数据追溯性验证：所有 FTTI 测试数据需可追溯，包括原始采集数据、时间戳提取记录、人工复核记录、设备校准报告等，确保后续审计时可复现测试过程；

• 与仿真结果对比验证：将实车测试的 FTTI 结果与整车动力学仿真结果对比，要求两者差值≤15%；若差值过大，需排查仿真模型精度或实车测试干扰因素，确保结果的合理性。

5. 专项场景验证：ACC 激活状态下信号丢失

ACC（自适应巡航控制系统）激活状态下，核心传感器（如前向毫米波雷达、摄像头）信号丢失是典型高风险故障，可能导致车辆失控跟车、追尾等危害事件。针对该场景的 FTTI 时间验证需结合 ACC 控制逻辑，明确工况边界与量化判定指标，具体方法如下：

5.1 测试工况定义（ACC 激活专属）

基于 ACC 系统工作特性，选取 “故障发生至危害事件时间最短” 的严苛工况，参数需明确且可复现：

工况参数	严苛工况取值	说明
ACC 激活状态	稳定跟车模式（Set Speed=60km/h，跟车距离等级 L3）	确保 ACC 已完成目标识别、车速闭环控制，处于稳定工作状态
目标车辆状态	前车匀速行驶（40km/h）/ 前车静止（极端工况）	覆盖跟车与静止目标两种核心风险场景
初始车距	跟车距离 = 3m（ACC L3 等级最小跟车距离）	车距越近，故障至追尾的时间越短，符合 “严苛工况” 要求
环境条件	常温（23±5℃）、干燥柏油路面，无雨雪 / 强光干扰	排除环境因素对信号传输的干扰，聚焦核心故障影响
安全机制状态	临时禁用 ACC 故障响应策略（如禁用 “降速提醒”“紧急制动介入”）	贴合 FTTI “安全机制未激活” 的定义前提

5.2 故障类型与起止时刻判定（信号丢失场景专属）

故障类型：ACC 核心传感器信号丢失（优先验证前向毫米波雷达信号丢失，次验证摄像头信号丢失）

时间节点	判定标准（量化信号特征）	数据采集来源
T0（故障发生时刻）	1. 雷达信号：连续 3 个 CAN 通信周期（每个周期 20ms）无有效目标数据输出，或信号值跳变为无效范围（如距离 = 0m、速度 =-99km/h）；2. 信号生效确认：ACC ECU 接收雷达无效信号后，控制指令开始出现异常（如加速指令持续输出）的瞬间	CAN 总线记录仪（监测雷达信号帧 ID：0x230；ACC 控制指令帧 ID：0x320）
T1（危害临界时刻）	1. 距离临界：本车与前车的实际距离≤最小安全跟车距离（根据车速计算：60km/h 时最小安全距离 = 2m）；2. 控制失稳临界：本车加速度偏离 ACC 目标加速度 ±0.5m/s²（如目标减速 0.2m/s²，实际加速 0.3m/s²），且持续 2 个控制周期	#### 5.3 专项测试步骤0. 测试前准备：部署高精度惯导、CAN 总线记录仪、前车定位设备，统一时间基准；将车辆置于封闭测试场地，预热至正常工作温度；0. ACC 激活与稳定：启动车辆，开启 ACC 系统，设置目标车速 60km/h、跟车距离 L3，使车辆进入稳定跟车状态（持续 3s 无控制波动）；0. 故障注入：通过 CANape 软件向 ACC 雷达发送无效信号（模拟信号丢失），记录故障注入触发时刻（需同步确认 ECU 接收状态）；0. 数据采集：持续采集雷达信号、ACC 控制指令、本车速度 / 加速度 / 位置、前车位置等数据，直至触发 “距离临界” 或 “控制失稳临界” 条件，立即终止测试；0. 重复与工况扩展：同一工况重复测试 3 次；依次扩展工况（如目标车速 80km/h、跟车距离 L2、前车减速场景），完成全严苛工况覆盖。#### 5.4 专项验证要点- 信号同步性验证：重点核查 ACC 雷达信号、ECU 控制指令、本车运动参数的时间同步偏差，要求≤1ms（因 ACC 控制周期短，同步误差对 FTTI 计算影响显著）；- 控制逻辑关联性验证：确认信号丢失后 ACC 控制指令的变化规律（如是否持续输出加速指令），避免因控制逻辑误判导致 T1 时刻识别偏差；- 边界工况验证：需覆盖 ACC 最大激活车速（如 130km/h）、最小跟车距离（L1 等级）场景，确保极端边界下 FTTI 仍满足安全约束；- 数据追溯性：完整记录 ACC 激活状态日志、故障注入指令日志、临界状态触发数据，形成专项验证报告，作为功能安全合规依据。## 六、总结FTTI 实车测试的核心是 “精准界定起止时刻 + 复现严苛工况”，而测试层面的验证则是保障 FTTI 结果有效、可靠的关键。通过数据有效性、结果重复性、场景覆盖性及合规性验证，可确保测量的 FTTI 真实反映系统故障到危害事件的最短时间间隔。最终，验证合格的 FTTI 将作为系统安全机制（诊断、响应）设计的核心时间约束，为功能安全合规性提供有力支撑。0. 临界指标校准：不同车型、系统的危害临界指标（如侧偏角、最小安全距离）需结合整车动力学仿真结果和实车摸底试验校准，确保与真实危害事件的关联性；0. 数据同步性：所有采集设备需统一时间基准（如通过 PTP 时钟同步），避免因时间偏差导致 FTTI 计算误差；0. 故障单一性：测试中仅触发目标单一故障，避免多故障叠加导致 FTTI 结果失真；0. 替代测试补充：对于无法在实车层面安全模拟的极端故障场景，可通过硬件在环（HIL）测试补充验证，确保 FTTI 覆盖所有严苛工况；0. 合规性记录：完整记录测试工况、故障注入方法、数据采集过程、判定指标等信息，形成可追溯的测试报告，作为功能安全合规性验证的依据。## 总结FTTI 实车测试的核心是 “精准界定起止时刻 + 复现严苛工况”，其中起始时刻（T0）以 “故障实际发生的客观信号特征” 为准，停止时刻（T1）以 “危害事件临界状态的量化指标” 为准，两者差值即为 FTTI。测试过程中需结合 VIL 等先进技术平衡测试真实性与安全性，同时通过多轮重复测试确保结果的可靠性，最终为系统安全机制设计提供核心时间约束。

六、总结

FTTI 实车测试的核心是 “精准界定起止时刻 + 复现严苛工况”，而测试层面的验证则是保障 FTTI 结果有效、可靠的关键。通过数据有效性、结果重复性、场景覆盖性及合规性验证，可确保测量的 FTTI 真实反映系统故障到危害事件的最短时间间隔。最终，验证合格的 FTTI 将作为系统安全机制（诊断、响应）设计的核心时间约束，为功能安全合规性提供有力支撑。

1. 临界指标校准：不同车型、系统的危害临界指标（如侧偏角、最小安全距离）需结合整车动力学仿真结果和实车摸底试验校准，确保与真实危害事件的关联性；

2. 数据同步性：所有采集设备需统一时间基准（如通过 PTP 时钟同步），避免因时间偏差导致 FTTI 计算误差；

3. 故障单一性：测试中仅触发目标单一故障，避免多故障叠加导致 FTTI 结果失真；

4. 替代测试补充：对于无法在实车层面安全模拟的极端故障场景，可通过硬件在环（HIL）测试补充验证，确保 FTTI 覆盖所有严苛工况；

5. 合规性记录：完整记录测试工况、故障注入方法、数据采集过程、判定指标等信息，形成可追溯的测试报告，作为功能安全合规性验证的依据。

总结

FTTI 实车测试的核心是 “精准界定起止时刻 + 复现严苛工况”，其中起始时刻（T0）以 “故障实际发生的客观信号特征” 为准，停止时刻（T1）以 “危害事件临界状态的量化指标” 为准，两者差值即为 FTTI。测试过程中需结合 VIL 等先进技术平衡测试真实性与安全性，同时通过多轮重复测试确保结果的可靠性，最终为系统安全机制设计提供核心时间约束。

测试中判断故障后处理逻辑是否满足 FTTI 的方法

核心逻辑：功能故障后处理逻辑是否满足 FTTI 要求，本质是验证 “故障处理总耗时（FHTI = 故障探测时间 FDTI + 故障响应时间 FRTI）≤ 预设 FTTI 阈值”。实车测试中需通过 “精准捕获故障处理全流程时间”“与预设 FTTI 阈值对比”“多场景验证稳定性” 三个核心步骤实现判定，全程需结合故障处理逻辑的实际触发机制，确保判定结果贴合功能安全设计目标。

一、判定前提：明确核心定义与预设基准

开展判定前需先明确关键参数定义与基准值，避免判定标准模糊导致结果失真：

参数类型	核心定义	预设基准值来源
FTTI 阈值（判定基准）	故障发生至危害事件的最短时间（安全机制未激活时），是处理逻辑需满足的 “最大容错时间上限”	1. 前期实车 / 仿真测试得出的 FTTI 实测最小值；2. 基于 HARA 分析与整车动力学计算的理论阈值（取两者较小值作为判定基准）
FDTI（故障探测时间）	故障发生时刻（T0）至系统检测到故障并发出诊断信号的时刻（T1）的时间间隔	功能安全需求文档中明确的诊断响应时间要求（如 ACC 系统雷达信号丢失诊断≤80ms）
FRTI（故障响应时间）	故障被检测时刻（T1）至系统完成故障处理、进入安全状态的时刻（T2）的时间间隔	功能安全需求文档中明确的响应执行时间要求（如 ACC 系统故障后降速响应≤120ms）
FHTI（故障处理总耗时）	故障发生时刻（T0）至系统进入安全状态时刻（T2）的总时间（FHTI = FDTI + FRTI）	判定核心指标，需满足 FHTI ≤ 预设 FTTI 阈值
关键提醒：判定基准需提前固化在测试计划中，且 FTTI 阈值需严格小于 “故障发生至真实危害事件的时间”，预留至少 10% 的安全余量（如 FTTI 实测 225ms，判定基准取 200ms）

二、核心判定流程（实车测试实操步骤）

以 “ACC 激活状态下前向雷达信号丢失” 故障为例，完整说明判定流程，其他系统（如 AEB、ESP）可直接复用框架：

步骤 1：测试前准备（明确边界与部署设备）

1. 工况定义：确定严苛测试工况（ACC 激活，目标车速 60km/h，跟车距离 3m，前车匀速 40km/h），确保工况覆盖 “故障处理逻辑最易超时” 的极端场景；

2. 基准值确认：调取前期数据，明确本次判定基准（如 FTTI 阈值 = 200ms，FDTI≤80ms，FRTI≤120ms）；

3. 设备部署：安装高精度数据采集设备（时间同步精度≤1ms），包括：① CAN 总线记录仪（监测雷达信号、ACC 诊断信号、控制指令）；② 高精度惯导（监测车速、加速度）；③ 高速摄像机（辅助验证故障处理动作）；

4. 系统预处理：将车辆与 ACC 系统置于正常工作状态，确认无历史故障；不禁用故障处理逻辑（区别于 FTTI 本身的测试，需完整触发真实处理流程）。

步骤 2：故障注入与关键时间点捕获

核心是精准捕获 T0（故障发生）、T1（故障检测）、T2（处理完成）三个关键时间点，确保时间戳同步：

关键时间点	实车判定标准（量化信号特征）	数据采集来源	ACC 场景示例
T0（故障发生时刻）	目标故障实际发生的瞬间，以客观信号突变 / 中断为判定依据	CAN 总线记录仪、示波器	雷达信号帧（ID：0x230）连续 3 个周期无有效数据，或信号值跳变为无效范围（距离 = 0m）的时刻
T1（故障检测时刻）	系统发出故障诊断信号的瞬间（如故障码上报、诊断报警帧输出）	CAN 总线记录仪（监测诊断信号帧）	ACC ECU 向仪表发送 “雷达故障” 报警帧（ID：0x320）的时刻，或诊断故障码（DTC：P1234）上报的时刻
T2（处理完成时刻）	系统完成故障处理，进入安全状态的瞬间（以控制目标达成、车辆状态稳定为依据）	CAN 总线记录仪、惯导系统	ACC 系统完成降速动作，车速从 60km/h 稳定降至 40km/h（与前车同步），或触发 “驾驶员接管提醒” 且持续输出的时刻
操作要点：故障注入采用 “软件精准注入”（如通过 CANape 触发雷达信号丢失），避免硬件注入（如剪断线束）导致的信号波动，确保 T0 时刻可精准复现。

步骤 3：计算耗时并与 FTTI 阈值对比（核心判定环节）

1. 数据提取：从采集的原始数据中，提取 T0、T1、T2 对应的时间戳（单位：ms）；

2. 耗时计算：① FDTI = T1 - T0；② FRTI = T2 - T1；③ FHTI = T2 - T0 = FDTI + FRTI；

3. 阈值对比：将计算得出的 FHTI 与预设 FTTI 阈值对比，判断是否满足要求；

4. 结果记录：同步记录 FDTI、FRTI 是否分别满足预设子阈值（如 FDTI≤80ms、FRTI≤120ms），便于后续定位超时原因。

ACC 场景示例：若 T0=1000ms、T1=1075ms、T2=1185ms，则 FDTI=75ms（≤80ms）、FRTI=110ms（≤120ms）、FHTI=185ms（≤200ms FTTI 阈值），判定为 “故障处理逻辑满足 FTTI 要求”。

步骤 4：多场景重复验证（确保结果稳定性）

单一工况的测试结果可能存在偶然性，需通过多场景验证确保处理逻辑在全风险范围内均满足要求：

• 同工况重复：同一严苛工况至少重复测试 3 次，要求 3 次 FHTI 均≤FTTI 阈值，且最大值与最小值差值≤10ms；

• 工况扩展验证：覆盖不同风险场景，如：① 不同车速（ACC 最大激活车速 130km/h、最小激活车速 30km/h）；② 不同跟车距离（L1 最小距离、L4 最大距离）；③ 不同环境（低温 - 40℃、高温 85℃、高总线负载 80%）；

• 边界故障验证：验证 “故障叠加场景”（如雷达信号丢失 + 摄像头信号异常），确认处理逻辑仍能在 FTTI 内完成响应（需提前评估叠加故障的 FTTI 阈值）。

三、常见超时问题定位与处理

若测试中出现 FHTI＞FTTI 阈值，需按 “先拆分耗时，再定位环节” 的思路排查问题：

超时类型	可能原因	定位方法	处理建议
FDTI 超时（探测慢）	1. 诊断算法周期过长；2. 总线负载过高导致信号传输延迟；3. 故障判定条件过于严苛（如需连续 5 个周期确认）	查看诊断信号帧的传输时间，对比总线负载率数据，分析故障判定算法的逻辑步骤	优化诊断算法，缩短判定周期；提升总线带宽，优先保障诊断信号传输；合理调整判定条件（如 3 个周期确认）
FRTI 超时（响应慢）	1. 执行器响应延迟（如 ACC 降速时节气门调节滞后）；2. 安全策略调用逻辑复杂；3. 低温环境下执行器性能下降	查看执行器控制指令与实际动作的时间差，分析安全策略的代码执行流程，对比不同环境下的响应时间	优化执行器控制参数；简化安全策略调用逻辑；针对低温环境增加执行器预热策略
FHTI 整体超时	1. FDTI 与 FRTI 均接近阈值，叠加后超时；2. 测试工况超出设计边界（如车速远超 FTTI 计算时的工况）	重新核查工况参数与 FTTI 阈值的匹配性，拆分 FDTI、FRTI 的具体耗时占比	同步优化 FDTI 与 FRTI；重新评估工况的合理性，若为极端边界工况，需调整 FTTI 阈值或优化系统设计

四、判定结果输出与合规性要求

判定完成后需形成完整的测试报告，作为功能安全合规性验证的依据，报告需包含以下核心内容：

1. 判定基准：FTTI 阈值、FDTI/FRTI 子阈值的确定依据与具体数值；

2. 测试工况：所有验证工况的参数、环境条件、故障类型；

3. 关键数据：3 次以上重复测试的 T0、T1、T2 时间戳，FDTI、FRTI、FHTI 计算结果；

4. 判定结论：明确 “故障处理逻辑是否满足 FTTI 要求”，若存在部分工况不满足，需说明具体工况与改进措施；

5. 追溯证据：原始数据采集日志、设备校准报告、故障注入指令记录。

总结

实车测试中判断故障后处理逻辑是否满足 FTTI，核心是 “精准捕获三个关键时间点→计算故障处理总耗时→与预设 FTTI 阈值对比”。关键在于前期明确判定基准、测试中保障数据同步精度、后期通过多场景验证确保结果稳定性。若出现超时，需拆分 FDTI 与 FRTI 定位问题，最终形成可追溯的判定报告，为功能安全合规性提供有力支撑。