SEooC — Safety Element out of Context
本质与导读
本质 SEooC 是 ISO 26262 给通用器件(MCU / 栅极驱动 IC / SBC)开的口子:芯片厂脱离 system context、基于假设场景按某 ASIL 开发,把全部 assumption 写进 Safety Manual 交 Tier1 验证。关键:芯片标 ASIL D 不等于系统 ASIL D——Tier1 必须逐条核对 assumption 在自己 system context 中是否真成立,不匹配则"看起来合规"实则漏保护。
1. 为什么需要 SEooC
ISO 26262 标准预设的开发对象是"完整 item"——比如 EPS、主驱、BMS 这种"知道完整 system context"的产品。开发流程必须从 HARA 起,有具体 ASIL、有 FTTI、有 Safe State。
但通用器件(MCU、栅极驱动 IC、SBC、ADC、磁编码器)根本没有这些 system context:
| 维度 | EPS | 主驱 | BMS |
|---|---|---|---|
| 典型 ASIL | D | D | C/D |
| 典型 FTTI | 100 ms | 50 ms | 100 ms |
| Safe State | 机械备份 / no assist | ASC / 自由轮 | 切断接触器 |
芯片厂发同一颗 MCU 给所有这些场景,不可能把每个 system context 都覆盖一遍 ASIL D 流程。SEooC 是 ISO 26262 给的合规口子:芯片厂做"假设性"HARA + ASIL 开发,把 assumption 全文档化到 Safety Manual,Tier1 system integrator 用之前逐条验证 assumption 在自己系统里是否成立。
2. SEooC 与完整 item 开发的差异
ISO 26262 Part 2 / Part 3 / Part 4 开发 item 的流程与 Part 10 Clause 9 开发 SEooC 的流程有 6 处关键差异——核心在 system context 是 actual 还是 assumed。
| 步 | 完整 Item | SEooC |
|---|---|---|
| Item Definition | 真实(车 / 子系统) | 假设的典型使用场景 |
| HARA | 真实驾驶场景 | 假设的 S/E/C 取覆盖性高的 |
| Safety Goal | 真实 hazard 推导 | 假设的 覆盖典型应用 |
| FSC / TSR | 真实分配 | 假设的 接口需求 |
| 实施 | 按 ASIL 流程 | 同 |
| 交付物 | 完整 item | 实物 + Safety Manual(列全部 assumption) |
3. Safety Manual 必含 4 类 assumption
SEooC 的核心交付物是 Safety Manual——一份详细列出所有 assumption 的文档,Tier1 用之前必须逐条核对。assumption 分 4 类:
3.1 Use Case Assumptions
芯片假设它会被用在什么场景——决定它针对什么 hazard 设计了 SM。
例(AURIX TC397 Safety Manual 节选):
"TC397 is intended…
"TC397 is intended for use in safety-related applications up to ASIL D. The intended applications include but are not limited to: powertrain control, chassis control, ADAS sensor processing, body domain controller. Use cases assume:
Tier1 检查点:你的应用是否落在这些假设范围内?如果你的 FTTI < 10 ms,芯片的"safety case"就不一定 cover 你的场景。
3.2 Safety Requirements(芯片自己提供的 SM)
Safety Manual 列出芯片内部实现的 SM 清单 + 每个 SM 的覆盖率。
例:
| SM | 覆盖什么失效 | 假设的 DC |
|---|---|---|
| Lockstep dual core | CPU 永久 / 瞬时故障 | ≥ 99% |
| ECC on RAM | RAM 单 / 双 bit 错 | ≥ 99% |
| CMU(Clock Monitor) | 主时钟漂移 | ≥ 95% |
| LBIST(启动 + 周期) | 数字逻辑 latent fault | ≥ 90% |
Tier1 检查点:这些 SM 的覆盖率与你 FMEDA 用的数字一致吗?有些 DC 是"在某些假设条件下"达成的(比如 LBIST 必须每 100 ms 跑一次,你的设计跑 200 ms 就会拉低 DC)。
3.3 Safe State 假设
芯片假设系统的 safe state 是什么——通常是"reset 到 known state"或"输出 disable / tri-state"。
例:
"Upon detection of…
"Upon detection of a critical fault by SMU, TC397 enters Safe State by:
- Asserting hardware Error Pin (ERR_OUT)
- Halting CPU execution
- The system is responsible for transitioning the application to a Safe State within FTTI."
Tier1 检查点:芯片的 safe state(ERR_OUT 拉高 + CPU halt)能否触发你系统的 safe state(STO / ASC / 切接触器)?如果你的栅极驱动 IC 不响应 ERR_OUT,芯片再 ASIL D 也没用。
3.4 External Safety Mechanisms 假设
芯片假设外部存在哪些 SM——这些 SM 不在芯片内部,但 safety case 依赖它们。
例:
"TC397 assumes the…
"TC397 assumes the presence of the following EXTERNAL safety mechanisms:
- External Q&A WatchDog with independent power and clock
- External voltage monitor with independent reference
- Bulk capacitor providing ride-through during short power dips
- System-level signal integrity protection (CRC, parity)"
Tier1 检查点:这些外部 SM 你都做了吗?这是 SEooC 最容易踩坑的地方——芯片假设你有 Q&A WD,你只用 Window WD,芯片的 ASIL D 立刻退化。
4. Tier1 接收 SEooC 的验收清单
收到 SEooC 芯片 + Safety Manual 后,Tier1 必须走 5 步验收流程——任何一步跳过,集成后的系统 ASIL 都不可信。
4.1 5 步验收
5 步验收是串行依赖——读 Manual 是基础,比对 assumption 是判断,后 3 步是闭环;任一步省略都让验收"看似过了实际没过"。
| 步 | 动作 |
|---|---|
| 1 通读 Safety Manual | 不要跳节,4 类 assumption 全读 |
| 2 比对假设 vs 实际 | 你的 ASIL / FTTI / 工作范围是否在芯片假设内 |
| 3 验证外部 SM | 芯片假设的外部 SM 你是否实施了(WD / V monitor / 等) |
| 4 更新 FMEDA | 把芯片提供的 SM DC 数据填入你的 FMEDA |
| 5 记录 gap + DFA | 不匹配的 assumption 要么补 SM 要么记 risk,DFA 重做 |
4.2 不匹配 assumption 的处理
如果 system context 与 SEooC assumption 不匹配,有 3 种合规处理方式:
| 处理 | 适用情况 |
|---|---|
| 加额外 SM 补齐 | 假设需要 Q&A WD,你原来用 Window WD → 加一个外部 Q&A WD |
| 降低 system ASIL 期望 | 芯片假设 FTTI ≥ 10 ms,你的项目是 5 ms → 这颗芯片不能用,或 system ASIL 必须降 |
| 联系芯片厂获取 specific safety analysis | 大客户可能要求厂商出 system-specific safety case extension |
5. 主流车规芯片的 SEooC 文档
下面是几个典型 SEooC 器件的 Safety Manual 概览,作为参考:
| 厂商 | 芯片 | 标记 ASIL | Safety Manual 重点 assumption |
|---|---|---|---|
| Infineon | AURIX TC397 / TC4x | D | FTTI ≥ 10 ms;外部 Q&A WD;recommended SBC TLF35584 |
| NXP | S32K344 | D | FTTI ≥ 5 ms;外部 V monitor;系统 CRC |
| STM | SPC58E | D | 类似 AURIX,SBC L9396 配套 |
| TI | UCC21750(栅极驱动) | D | 假设有 LV 端 STO 信号;DESAT 阈值由系统设 |
| Infineon | 1EDI3035AS(栅极驱动) | D | 假设隔离 / ASC 信号外部独立 |
实务经验:OEM 提供的 system safety case 必须明确每颗 SEooC 的 assumption-vs-reality 对比表,审计时这是第一个被翻的文档。
6. SEooC 与 ASIL 分解的关系
SEooC 与 ASIL 分解经常被混淆——它们解决不同问题,但常常组合使用。
| 维度 | SEooC | ASIL 分解 |
|---|---|---|
| 解决的问题 | 通用芯片如何 ISO 26262 合规开发 | 系统如何降低开发成本 |
| 谁用 | 芯片厂(开发) + Tier1(验收) | Tier1(系统架构师) |
| 典型场景 | MCU / 栅极驱动 / SBC | EPS 主+监控 MCU |
| 结合 | Tier1 用两颗 SEooC ASIL B(D) MCU 实施 ASIL D 分解 | 是 |
典型组合:Tier1 在 EPS 项目里用 Infineon TC275(SEooC ASIL D)做主 MCU、ST SPC58(SEooC ASIL D)做监控 MCU,然后做 ASIL D → B(D) + B(D) 分解——两颗芯片本身按 ASIL D SEooC 开发,但 Tier1 实际只用到 B(D) 等级。
7. 5 个 SEooC 反模式
SEooC 失效集中在 5 个反模式——这 5 个让"用了 ASIL D 标记的芯片但系统不安全"成为常见情况。
| 反模式 | 表现 | 修法 |
|---|---|---|
| 只看 ASIL 标签不看 Safety Manual | "这颗 MCU 是 ASIL D" → 直接进 BOM | 必读 Safety Manual,核对 4 类 assumption |
| 不实施外部 SM | Safety Manual 假设有 Q&A WD,你用 Window WD | 检查清单逐条核对外部 SM |
| 假设的 FTTI 超你的应用 | 芯片假设 FTTI ≥ 10 ms,你的项目 5 ms | 选 FTTI 更短的芯片 / 改架构 |
| 共因没补 | 芯片内部独立但你接同电源 / 同时钟 | DFA 重做,把外部接线纳入 |
| 不做集成验证 | 假设 OK 就发布,没做 chip-system fault injection | 故障注入测试 + DFA 报告 |
7.1 只看 ASIL 标签的隐蔽危险
最常见也最危险的反模式:工程师看见"ASIL D"标签就 BOM 选定。ASIL D 标签只是声明"芯片按 ASIL D 流程开发了",不代表"放进任意系统都自动 ASIL D"。修法:把 Safety Manual review 列入 BOM evaluation checklist,review 不通过的芯片不能进 BOM。
7.2 不实施外部 SM 的隐蔽危险
Safety Manual 通常会说"assumes external Q&A watchdog"。如果你只用 Window WD 凑合,芯片的所有 SM 都假设 Q&A WD 存在,Window 监督不到的故障类型会被漏过。修法:Safety Manual 里的"external SMs"是硬约束,不能省。
核心要点
- SEooC 是 ISO 26262 给芯片厂的合规口子 —— 假设性 HARA + 假设性 ASIL 开发,assumption 全文档化到 Safety Manual
- 与完整 item 开发的核心差异:system context 是 assumed 不是 actual
- Safety Manual 必含 4 类 assumption:Use Case / Safety Req / Safe State / External SM
- Tier1 接收时走 5 步验收:读 Manual → 比对 assumption → 验证外部 SM → 更新 FMEDA → 记录 gap
- ASIL 标签只是"开发等级",不等于"放进系统就 ASIL D" —— 必须 assumption 全部成立
- 主流芯片 SEooC:AURIX TC4x / S32K344 / TI UCC21750 / Infineon 1EDI3035 都是 ASIL D SEooC
- 与 ASIL 分解组合使用:两颗 ASIL D SEooC 芯片 + 系统级 D→B(D)+B(D) 分解 = EPS 标准架构
- 5 反模式戒除:只看标签 / 不实施外部 SM / FTTI 不匹配 / 共因没补 / 不做集成验证
Engineering Objects
引用此页的结构化 Engineeri…
引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。
- standard ·
standard_iso26262_part8— ISO 26262 Part 8 Supporting Processes
Cross-references
- ← 索引
- 功能安全
- HARA 危害分析与风险评估 — SEooC 的 HARA 是假设性的
- ASIL 分解(Decomposition) — 常与 SEooC 组合使用
- 安全机制目录 — Safety Manual 列的 SM 与本页 catalog 对照
- ISO 26262 硬件要素三类分类 — III 类元件几乎都是 SEooC
- DFA / FMEDA / FTA 三种核心分析方法 — Tier1 接收 SEooC 后必重跑 DFA
- 汽车 MCU — AURIX / S32K3 都是 SEooC 实例
- SBC 系统基础芯片 — TLF35584 / FS8500 都是 SEooC
- 栅极驱动 — UCC21750 / 1EDI3035AS 都是 SEooC
- PEU 开发流程 — Tier1 视角的 SEooC 验收落地