ISO 26262-4(2018)系统层细化:TSC / HSI / 集成 / Safety Validation

Part 4 把 FSC(Part 3 产出)转化为技术产物,形成 V 模型左侧三级:TSC 是高层设计,系统架构是实现约束,集成测试是左侧各级对应的右侧门。Safety Validation 是独立于 development team 的终审——验证的是"整个 item 是否真的实现了 SG",而非"代码是否符合规范"。

Clause 6 一节内同时容纳 TSR 规范、系统架构设计、HSI 规范和硬件架构度量目标值;Clause 7 = system and item integration(含集成进整车);Clause 8 = safety validation(整车级)。

TSC 是 Part 4 的核心 work product。它把 FSC 的"功能层要求"逐条翻译成工程师能直接开始硬件/软件设计的"技术层要求"(TSR),精确到时序、接口、安全机制类型。

Hardware-Software Interface 规范是 Part 5/Part 6 之间的合同,由 Clause 6.4.10 定义,必须由系统/硬件/软件三方联合签字。每次修改需 triple-sign + 影响分析 + Part 5/6 受影响 work products 重验证。

系统架构必须支撑 TSC 的所有要求、满足 ASIL 分配约束、为 Part 5/6 实现提供边界。ASIL 分配是架构的核心决策——每个子系统的 ASIL 等级决定其工程成本。

集成测试自下而上三层,每层都必须覆盖 TSC 要求,fault injection 是关键验证手段。

TSC/HSI/集成/Validation 阶段最常见的 7 类错误:

G1(最高危)TSR 时序不拆分 FDTI/FRTI → FTTI 验证假通过

TSR 只写"SM 反应时间 < FTTI=200ms",不区分检测时间(FDTI)和反应时间(FRTI)。测试只测 FRTI(栅极关断速度),而 FDTI(SW 检测 3 周期=30ms)被遗漏。验收时整合写"1.22μs + 30ms ≈ 31ms < 200ms 通过",但 SG-01 的真正 FDTI=30ms 未被单独验证。实车 fault injection 才暴露 SW 检测路径有漏洞。修复:TSR 必须分别写 FDTI 预算 + FRTI 预算 + 总 ≤ FTTI,三个值分别有验证证据。

G2 HSI 项漏 ASIL 标注 → 审计第一问即暴露

HSI 表只写功能/接口,不写每条 HSI 的 ASIL 等级和"是否 safety-critical"。审计员标准开场白:"请问 HSI-003 PWM 输出是 safety-critical 的吗?依据哪条 TSR?"工程师答不上来 → NC(不符合项)。修复:HSI 表必须含 ASIL + safety-critical 标注 + TSR reference 三列,见 §3.2 表格。

G3 Safe state 定义模糊 → Validation 无法执行

TSC 写"进入 safe state"但不定义 safe state 的可观测技术指标。Validation 团队问"我怎么测试系统进入了 safe state?"答案是"看仪表盘警告灯"——无法量化核查。修复:safe state 定义必须含 ≥3 个可量测指标,例:①PWM 全部低电平(示波器可测)②CAN 发 DTC P-xxxx ③DESAT 引脚电平变化。

G4 TSC 版本未绑定 FSC 版本 → Safety Case 悬空

FSC v2.0 修改了 FTTI=200ms → 250ms,但 TSC 仍引用旧 FSC v1.5,TSR 中 FDTI+FRTI 预算按旧值设计。Safety Case 引用 TSC v1.0+FSC v2.0,内部自洽检查发现约束不匹配。修复:TSC 文档头部强制写"FSC 参考版本:vX.Y";每次 FSC 变更触发 TSC 影响分析 + 版本更新。

G5 ASIL 分解在 TSC 阶段执行但 HSI 独立性要求未更新

系统架构决定"ASIL D 分解为 B(D)+B(D)"——要求两通道硬件路径独立。但 HSI 表中 HSI-006(FS0B)的独立性论证未更新,Part 5 DFA 没有覆盖这条 HW 互锁路径的 CCF。审计 Part 9 DFA 时暴露。修复:ASIL 分解决策 → 立即触发 HSI 表中相关 safety-critical 接口的独立性要求更新 + 通知 Part 9 DFA 团队。

G6 Validation 没有 mid-development 阶段 → release 前发现 SG 违反

项目计划 Validation 只在 J-stage(release 前 2 个月)做实车测试。FSC 中 C3 参数"驾驶员在弯道高速行驶时可控制"的假设从未在中期验证过。J-stage 测试发现在 90km/h 弯道电机突然失扭矩时,驾驶员实际控制率只有 40%(HARA 假设 C3=需外部措施)。整车设计被迫在 2 个月内返工。修复:强制要求 mid-development validation(E-stage,原型车阶段),至少覆盖 HARA 中所有 C 参数的 controllability 假设验证。

G7 Fault injection 只测软件检测,未测 HW 路径独立性

集成测试 FT-002(扭矩不一致)验证了 SW 检测逻辑正确。但 FT-001(DESAT 注入)用的是软件模拟 FAULT 引脚(GPIO 写 0),而非真实 HW 过流注入。实际 HW 注入时发现:1EDI3035AS DESAT 门控电路因 PCB 走线寄生电感导致 tblank 比 spec 多 150ns,总体延迟超出 SCWT 容限。修复:HW 路径 fault injection 必须用真实电气注入(而非 GPIO 仿真),验证每条 HW SM 在真实电气条件下的时序。

C1(-40°C 低温)扭矩估算精度退化 → TSR-01 边界条件

低温(-40°C)下电机磁链 ${\psi }_s$ 温度系数约 +0.14%/°C(永磁铁磁通负温系数;与 NdFeB 剩磁实测约 -0.12%/°C 同量级),但 torque_estimate() 函数使用 nominal ${\psi }_s$=0.32 Wb(25°C)——低温(ΔT=65°C)时实际 ${\psi }_s$≈0.35 Wb,导致扭矩估算偏低约 9%。若 TSR-01 偏差门限设 5%,低温冷车状态可能产生 false alarm(偏差始终 >5% 但电机正常)。工程决策:需标定表按温度补偿 ${\psi }_s$(T),或将 FDTI 阈值在低温段放宽至 8%,并在 Validation 中验证(-40°C 冷车 fault injection)。(注:${\psi }_s$ 温度系数为 OEM 电机标定数据示例,非 ISO 规定。)

C2(OTA 升级)SW 路径 TSR 改变 → 触发 FSC/TSC 重验证

OTA 升级修改了扭矩估算算法(提高精度,控制周期从 10ms → 5ms)。TSR-01 的 FDTI=3×10ms=30ms 变为 3×5ms=15ms(提升检测速度)。此变化看起来是"改善",但TSR 变更必须触发影响分析:① FTTI 路径重算:15ms + FRTI ≤ 200ms(仍满足,但 headroom 增大)。② Part 6 SW 变更:单元测试重跑 MC/DC。③ OTA 软件更新本身的安全走 ISO 24089(Road vehicles — Software update engineering),配置/变更走 ISO 26262-8 Clause 8 变更管理。安全规则:任何影响 TSR 参数的 OTA 必须经过 safety change request 流程,不能绕过 Part 4 TSC 变更程序。

C3(多 ECU 系统)ASIL 边界 → Inverter TSC 与 VCU TSC 接口歧义

100kW EV 系统中 VCU 和 Inverter 各自是独立 item(各有 FSC + TSC)。VCU TSC 写"Torque command 经 CAN 发出,精度 ±0.5%";Inverter TSC 写"CAN 接收扭矩命令,超时 100ms → 扭矩=0"。但两份 TSC 都没有定义"接口处的 ASIL 是什么"——VCU 提供 ASIL B 命令,Inverter 使用 ASIL D 处理?接口本身的 ASIL 如何划定?正确做法:系统级 TSC(OEM 负责)或 DIA(Development Interface Agreement,ISO 26262-8 Clause 5 分布式开发接口)明确规定接口 ASIL,Inverter Tier-1 只能 assume VCU 满足 DIA 约定的接口质量。DIA 签字是必要前提条件。

• standard · standard_iso26262_part4_validation — ISO 26262-4 (2018) 系统层 / Safety Validation