TSC 技术安全概念 + DIA 开发接口协议

功能安全L1别名 TSC · Technical Safety Concept · DIA · Development Interface Agreement · 技术安全概念 · 安全开发接口协议

本质与导读

本质 TSC 把 FSC 的功能级要求("过流切扭矩")翻成具体硬件/软件实现("电流传感器 + 双 ADC + 主从对比 + 5 ms 内 STO"),是技术文档;DIA 把 OEM-Tier1-Tier2 之间谁交付、谁审查、谁背锅写成安全责任合同。一个落实现,一个分责任,缺一对 DIA 在 PPAP 直接退回。

主线坐标:横轨 · 功能安全(跨站) · ↑ 全景主线

1. ISO 26262 概念链:Item → SG → FSC → TSC

ISO 26262 V 模型的"概念阶段"产出 4 层文档——一层比一层具体,前一层是后一层的输入。

ISO 26262 概念链 — Item → SG → FSC → TSC → 硬件/软件需求

层文档颗粒度ISO 引用产出方
1Item Definition系统边界 + 功能 + 接口Part 3 §5OEM 主导
2Safety Goal (SG)"不应发生的危害" + ASILPart 3 §6OEM (HARA 结果)
3FSC (Functional Safety Concept)"功能上要怎么避免危害" + FTTIPart 3 §7OEM 主导 + Tier-1 协商
4TSC (Technical Safety Concept)"具体用什么器件 + 算法实现"Part 4 §6Tier-1 主导

关键差异:

  • FSC:不允许指硬件,只能说"功能层防护" (如"过流时切扭矩")
  • TSC:必须指硬件 + 算法 (如"使用 LEM HASS-50S 双 ADC,主从 100Hz 对比,差 > 5% 触发 STO,5 ms 内进 safe state")

为什么这个差异重要:FSC 由 OEM 写,Tier-1 不能改 (那是 OEM 的"安全目标合同");TSC 由 Tier-1 写,内容是供应商的"技术秘密",OEM 看的是 FSC 而不是 TSC 实现细节。

2. TSC 6 项必含内容

TSC (ISO 26262 Part 4 §6) 必须覆盖 6 个维度——任何一项缺失都不能进入 Part 5 (硬件) / Part 6 (软件) 阶段:

#项内容
1技术安全需求 (TSR)把 FSC 的功能需求翻译为可测试的技术语言
2架构分配哪些 TSR 由硬件实现,哪些由软件,哪些由系统接口
3HSI (Hardware-Software Interface)硬件提供给软件的服务清单 (如"ADC 提供 10 kHz 采样 + over-range flag")
4安全机制 (SM)检测/容错机制清单,每个 SM 有 DC (Diagnostic Coverage) 估值
5FTTI (Fault Tolerant Time Interval)故障发生到进入 safe state 的最大允许时间
6Safe State 定义进入哪种降级模式 (STO / 3PO / passive state)

典型 TSR 示例 (主驱 PEU,源自 FSC "扭矩异常时切到 0"):

  • TSR-001: 控制器测量三相电流的实际值与命令值偏差 > 5 A 时,触发故障
  • TSR-002: 故障检测后 5 ms 内,所有 IGBT 栅极进入 STO 状态
  • TSR-003: STO 状态由独立硬件 enable 通道控制,不依赖 MCU 软件
  • TSR-004: STO 状态下,残余扭矩 < 5 Nm

3. HSI (Hardware-Software Interface)

HSI 是 TSC 里最容易被忽视但最关键的一节——很多项目失败是因为 HSI 写得不清,硬件团队和软件团队各做各的。

HSI 应规定:

  • 硬件提供的输入/输出端口:类型、范围、单位
  • 采样率 / 时序保证:ADC 10 kHz、CAN 1 ms 帧间隔
  • 错误信号:over-range、stuck-at、CRC fail 怎么传给软件
  • 共享资源约束:MCU 多核共享 ADC,SafetyOS 调度规则
  • 诊断接口:BIST 启动条件、结果回报方式

典型 HSI 表:

信号方向类型范围时序错误处理
Iu_measHW → SWint16-500~+500 A100 μs samplingover-range 置 status bit
STO_enableSW → HWbool0/1立即生效HW 内 watchdog,SW 30 ms 不刷新自动 disable
Vdc_measHW → SWuint160~1000 V1 ms samplingADC fail 报 DTC + 状态 -1

4. DIA — 跨组织安全责任合同

DIA (Development Interface Agreement) 是 ISO 26262 Part 8 §5 强制要求的合同文档——跨组织开发时,每对接口必签 DIA。

怎么写 DIA

怎么写 DIA? → DIA 写作工程化深度 讲 5 阶段 SOP / 8 章模板 / §3 RACI 50 格 / §4 Confirmation 3 review / §6 AoU 接受三选一 / §8 Tool 互信 / SEooC virtual DIA / 5 反模式 / ASIL D Review 6 项。 DIA 沿供应链每对接口必签 — OEM ↔ Tier-1 (DIA #1),Tier-1 ↔ Tier-2 (DIA #2)

典型供应链结构:

TSC/DIA 安全责任链竖向图:OEM(整车厂)经 DIA #1 向下连到 Tier-1(PEU 供应商);Tier-1 再分三支,分别经 DIA #2(MCU)、DIA #3(功率模块)、DIA #4(软件)向下连到三个 Tier-2——NXP/Infineon、英飞凌/Wolfspeed、Vector/Elektrobit。

关键认知:任何一对没签 DIA 的接口都是"安全空洞"——出了事所有人都甩锅。OEM 在 PPAP 审计时会逐对检查 DIA。

5. DIA 8 类必含条款

DIA 不是模板化合同,内容必须项目化定制。8 类必含:

#条款内容
1Item 边界 + 接口双方分别交付什么,接口在哪
2Safety Plan 同步双方各自的 Safety Plan 节点对齐
3职责分配 (RACI)HARA / FSC / TSC / HW / SW / 验证 各方谁负责
4Confirmation Measures哪些审查由 OEM 做、哪些由 Tier-1、独立性要求
5变更管控任何变更需双方书面同意,变更 PCN 流程
6Safety ManualTier-2 提供给 Tier-1 的 SM,Tier-1 接受的 assumption
7验证证据共享FMEDA / V&V / 测试报告如何相互访问
8Tool Qualification 共享哪个工具谁 qualify,工具结果是否互信

关键条款细节:

  • Safety Manual (item #6) 是 Tier-2 → Tier-1 的"使用说明书",列出器件的安全前提 (如"MCU 假设外部 watchdog 每 100ms 刷新")——Tier-1 不满足这些 assumption 就用错了器件
  • Confirmation Reviews (item #4) 的独立性要求由 ASIL 等级决定 (topic-confirmation-measures)
  • Tool Qualification (item #8):大型 OEM 通常已经把主流工具 (CANalyzer/Simulink) qualify 了,Tier-1 可以引用,免去自己重做

6. DIA 在 SEooC 场景下的特殊性

topic-seooc (Safety Element out of Context) 是没有具体 OEM 项目就开发的安全相关器件 (如通用 MCU、SBC)——这种情况下 Tier-2 不知道具体 OEM 是谁,DIA 怎么办?

SEooC 解决方式:

  • Tier-2 假设一组 "虚拟 DIA" (assumption set),列在 Safety Manual 里
  • Tier-1 采用 SEooC 时,验证"我的实际使用是否满足 SM 里的所有 assumption"
  • Tier-1 与 OEM 签的 DIA:声明"使用了 SEooC,SM 已审核,assumption 全部覆盖"

典型 assumption:

  • "MCU 假设温度 -40~+150 ℃,超温外部冷却保证"
  • "栅极驱动假设供电 15V ± 1V 稳定,超出范围 Tier-1 加监测"
  • "SBC 假设软件每 100ms 喂狗,否则触发 reset"

7. TSC 与 ASPICE / Safety Case 的关系

TSC 是 ISO 26262 文档,但与 ASPICE 和 topic-safety-case 强耦合:

文档框架与 TSC 关系
TSCISO 26262 Part 4本页主题
ASPICE SYS.2 (System Requirements)ASPICETSR 直接进 SYS.2,双向 traceability
ASPICE SYS.3 (System Architecture)ASPICETSC 架构分配进 SYS.3
Safety CaseISO 26262 Part 4 §9TSC 是 Safety Case 的核心证据章节
HSIASPICE 4.0 HWEHWE.1 Requirements 输出 HSI
DIAISO 26262 Part 8 §5引用 Safety Plan + Safety Case 节点

实操:TSC 写完,TSR 必须在 ASPICE 工具 (DOORS / Polarion / Jama) 里有对应的需求 ID + 双向 trace 链——否则 ASPICE 评估 PA1 (Process Attribute) 直接 N (Not Achieved)。

8. TSC 在 PEU 主驱中的典型实例

PEU 主驱常见 SG "防止非预期扭矩输出" → FSC → TSC 落地:

层内容
SG系统不应输出超过驾驶员命令 ± 10% 的扭矩 (ASIL D)
FSC检测扭矩异常 → 5 ms 内进 safe state (STO 或 3PO)
TSR-001三相电流偏差 > 5 A 触发故障
TSR-002故障后 STO enable 拉低,栅极驱动 5 ms 内关断
TSR-003STO 路径独立硬件 (不经过 MCU 软件)
HSI-001电流采样 100 μs / 通道,over-range 触发 status flag
HSI-002STO_enable 信号由 SBC 直接控制,MCU 软件设置 + 硬件 watchdog
SM-001电流双 ADC 主从对比 (DC ≥ 95%)
SM-002STO 路径 BIST 在每次上电时自检
FTTI5 ms (扭矩动态响应外推)
Safe StateSTO (栅极关断,电机自由旋转) → 车速 > 5 km/h 时改 3PO (三相短路,主动制动)

这套 TSC 落到 PEU 上,硬件需要:双 ADC、STO 路径专用 SBC、栅极驱动独立 enable + fault 报告;软件需要:电流偏差检测算法、STO 触发逻辑、ASIL D 软件分区隔离。

9. 5 个常见陷阱

TSC + DIA 失败模式集中在 5 个反复出现的坑:

陷阱描述预防
FSC 与 TSC 混淆OEM 给的 FSC 里指明用某 ICOEM 改回 FSC 不指硬件,Tier-1 自己选
HSI 写得太粗"ADC 提供电流采样"——没有时序HSI 表精确到 μs / 单位 / 错误处理
TSR 不可测试TSR-001 "系统要稳定"——无法验证每条 TSR 必须有定量验收准则
DIA 漏对OEM-Tier1 签了,Tier1-Tier2 漏了任何跨组织接口都补 DIA
SM Manual 假设不读Tier-2 Safety Manual 里 assumption Tier-1 没看强制做 SM 读后 review + 签字

核心要点
  • TSC = FSC 的"硬件/软件实现版" → ISO 26262 Part 4 §6 强制产出。
  • TSC 6 项必含:TSR / 架构分配 / HSI / 安全机制 / FTTI / Safe State。
  • HSI 是 TSC 灵魂——硬件和软件团队的"翻译表",写得粗就项目翻车。
  • DIA = ISO 26262 Part 8 §5 强制 → 跨组织开发每对接口必签。
  • DIA 8 类必含:Item 边界 / Safety Plan / 职责分配 / Confirmation Reviews / 变更 / SM / 验证证据 / Tool Qualification。
  • SEooC 场景下,Tier-2 用 Safety Manual 作"虚拟 DIA"——Tier-1 接受 assumption 时再补正式 DIA。
  • TSC 与 ASPICE 强耦合:TSR 必须进 SYS.2 双向 trace,否则 PA1 = N。
  • 少一对 DIA = PPAP 阶段直接退回 —— OEM 审计逐对检查。

Engineering Objects
引用此页的结构化 Engineeri…

引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。

  • standard · standard_iso26262_part2 — ISO 26262 Part 2 Management of FS
  • standard · standard_iso26262_part8 — ISO 26262 Part 8 Supporting Processes

Cross-references