SEooC — Safety Element out of Context 工程实战深度

ISO 26262-1:2018 vocabulary(term 3.138)原文定义:"safety-related element which is that is not developed in the context of a specific item"(即一个 safety-related element,不在某一具体 item 上下文中开发)。term 3.138 同条原文补注列举了 SEooC 的形态:a system, a combination of systems, a software component, a software unit, a hardware component or a hardware part——即 SEooC 涵盖 system / 系统组合 / 硬件组件 / 硬件零件 / 软件组件 / 软件单元,不局限于 "an E/E system";"an E/E system ... not developed based on the specific requirements provided by the OEM/suppliers/technology vendors" 那种说法是第三方厂商 paraphrase,不是 ISO 原文。

3 句话理解:

• SEooC 是 hardware 或 software 元件,按 ISO 26262 开发但没有完整的 item-level system definition
• 供方为缺失信息编写"有据可循的假设"(justified assumptions)
• 一句话定位:"Safety element out of context" — 在 item 上下文之外开发,后续在多个 item 中复用,前提是集成时假设能成立

下表是 6 类典型 SEooC 对象 + 主流 vendor:

里程碑:AURIX TC3xx 是"first embedded safety controller worldwide certified ASIL-D under ISO 26262:2018";S32K3 由 NXP 按 BCaM7 process 开发并 TÜV SÜD 认证;TMS570 在 concept phase 已显式按 ISO 26262-10:2012 §9 SEooC 流程分析。

两种开发模式的根本差异:

• SEoC (Safety Element of Context):在已知 item 上下文 + OEM 明确 safety goals + 全部 system requirements 下开发。Top-down 经典 V-model 路径
• SEooC:bottom-up,先决定"这个元件要做到 ASIL-x",再反推应满足哪些上层假设

实操区别:

• SEoC 的 validation 是 item-level + vehicle-level 全闭环
• SEooC 的 validation 只覆盖到 supplier-controllable 边界;vehicle-level validation delegated to OEM/Tier-1

完整理解 SEooC 必须先弄清楚 5 个术语:

• Assumption of Use (AoU) — supplier 在缺 item 上下文情况下对使用方式的假设。Renesas 在 Safety Application Note 里用 AoU-SIR-xx 编号每条
• Assumption of Environment (AoE) — 电气特性、通讯协议、温度/湿度边界、集成约束等环境假设
• Item-Level Integration — Tier-1 把 SEooC 放进 item 上下文做 hazard analysis → safety goals 映射 → AoU 反向验证的全过程,安全论证最后一公里 lifecycle 显式 delegate 给 OEM/integrator
• Validation Argument — SEooC supplier 只能 demonstrate "element fulfils its safety requirements under the assumed context",所以 Safety Manual 变成"safety case 的可移交载体"(critical safety artifact)
• DIA (Development Interface Agreement) — Tier-2/Tier-1/OEM 三方 RACI 文档,划清安全活动归谁

Safety Manual 的典型 10 章结构(汇总 Microchip / Infineon / TI / NXP 模板):

1. Scope + 适用器件版本 / Rev
2. Safety architecture overview
3. Assumptions of Use (AoU) — 编号 list (AoU-001...AoU-NNN)
4. Safety Mechanism (SM) list — 每条带:覆盖的 failure mode + diagnostic coverage % + 触发条件 + 软件配置
5. FMEDA(量化失效率 + SPFM/LFM/PMHF)
6. Failure mode 表(已覆盖 / 未覆盖 / residual)
7. Integration guidelines(pin config / 启动序列 / fault reaction time)
8. Configuration constraints(禁用 pin 组合、寄存器锁定、不允许的运行模式)
9. Application examples(EPS / ABS / Inverter)
10. Document history + ASIL claim

关键 quote(Microchip Sample MCU Safety Manual):"The System Integrator shall fulfill all Assumptions of Use (AoU) listed in the safety manual, and the AoUs were assumed to be fulfilled when analyzing the failure rates and Fault metrics in the provided FMEDA"。

AoU 必须分维度逐条编号,Tier-1 在集成时逐条对照:

Integration Manual 4 阶段套用(基于 Electronic Design 4-step + Renesas 3-stage):

1. 假设核对(AoU validation)
2. 需求映射(SEooC requirements ↔ item requirements)
3. Target 上运行验证(element runs correctly on target)
4. Item-specific integration tests 覆盖 SEooC 在真实 item 中表现

主流 vendor 集成 AN 文档清单:

权威源对 SEooC mismatch 的统一警告:

• "If an OEM violates assumptions, the SEooC's safety argument is no longer valid."(Intertek)
• "Most SEooC integration issues arise not from technical failures but from violated assumptions."(Intertek)
• "If APIs aren't called correctly or features misconfigured, the ASIL OS may get 'downgraded' to non-ASIL."(functionalsafetyfirst.com)

下表是 Tier-2 假设 vs Tier-1 实际不匹配的典型 6 维 + 后果:

标准动作(Intertek + Renesas)4 步:

• 把 Safety Manual 每条 AoU-xxx 提到 requirements 系统(DOORS / Polarion / Codebeamer)
• 对每条做 status:Satisfied / Violated / Not Applicable + 论证
• Violated 的走 ISO 26262-8 change management(Part 8 §8)触发 impact analysis
• 必要时回到 Tier-2 重做 FMEDA(NXP 的 FMEDA 是 customer-configurable 就是这个原因)

完整读取是不可妥协的:

• 不能只看 datasheet 数值,Safety Manual 第 3、4 章 AoU + SM 列表是核心
• Common pitfall(functionalsafetyfirst):"heard about safety manuals but have not read one, or read but found challenging to apply"
• Output:AoU 全清单(已编号)+ SM 全清单 + FMEDA 输入参数 list

把 SEooC 放进 item 上下文做 3 件事:

• 做 item 级 HARA → 推导 safety goals
• 把 safety goal 拆到 SEooC 假设的 ASIL
• 对 AoU 一条一条 check "is the assumption true in this item"
• Output:assumption mapping 表 + gap list

ISO 26262-2:2018 §6.4.9 Table 1 规定 confirmation measure 的最低独立性随 ASIL 升级。注意:独立性级别是 I0/I1/I2/I3,不是 M1/M2/M3 — 后者是 UNECE/EU 车辆类别(M1=乘用车 / M2/M3=客车/商用车;ISO 26262 仅在 scope 中引用,不在 26262 定义)。下表按 Table 1 原文取值,与 Confirmation Measures 深度 同口径(QM→A→B→C→D 五列):

三个最易记错的点(与 sibling 页一致):① impact analysis 与 HARA 的 CR 在任何等级(含 QM)都是 I3——ASIL 定级本身必须被独立确认;② ASIL D 并非全部 I3,integration & test strategy 与 safety validation specification 两行的 CR 只要 I2;③ audit / assessment 在 ASIL B 是 I0(建议做)、不是 I2、也不是"无要求"。I3 的判据是在管理 / 资源 / 发布权限三方面独立于创建部门,公司内部另一部门即可满足;第三方(TÜV / SGS / DEKRA)是 OEM 的商业 / 准入选择,不是 ISO 对 I3 的定义。

关键认知:"perform item-specific integration tests of the SEooC running in the target context"。

必测 4 类:

• AoU 边界(温度 corner / 电压 corner / fsw corner)
• SM 触发路径(fault injection)
• 实际 mission profile 应力(不能只测 datasheet 数值)
• FTTI 端到端时序

最后一步把 Tier-2 work products 整进 item-level safety case:

• 整合内容:DIA + FMEA + FMEDA + Safety Manual + Safety Analysis Report
• Synopsys 论证形式 quote:"Certain assumptions indicated during SEooC development are converted to justifications in the system level Assurance Case"
• 推荐 notation:GSN(Goal Structuring Notation) — Lorit Consultancy Hall sensor 案例展示 GSN 在 SEooC 中的用法

AURIX TC3xx Safety Manual 4-section 结构:

1. Safety concept + platform scalability
2. MCU architecture safety 集成(lockstep CPU / ECC / SMU)
3. Application use cases(EPS / XEV traction inverter)
4. Safety SW enablement

关键架构:SMU (Safety Management Unit) 集中所有 alarm signal,可配置 internal action + external fault signaling protocol。AoU 含 safety goals / FTTI / safe state / severity-exposure-controllability。FMEDA template customer-configurable(ISO 26262 + IEC 61508 双合规)。全套文档 NDA。

S32K3 MCU + FS26 SBC 是 ASIL-D 标准配对:

• MCU 提供算力 + 内部 SM,FS26 提供外部 watchdog / voltage monitor / fail-safe output
• 集成 AN:AN14068 + AN14492 + S32 SAF Quick Start Guide
• 全套文档在 SafeAssure NDA program:safety manuals + standardized FMEDAs + analysis reports + assessment reports + PPAPs
• 安全分析方法:FTA + DFA + FMEDA(quantitative)

TMS570 是早期 SEooC 公开案例:

• Safety Manual(SPNU620 等)显式声明:"devices analyzed during concept phase to support SEooC development per ISO 26262-10:2012"
• 例:EPS FTTI 假设 10 ms,ESC 100 ms — 设计取最严那一个为目标
• 配套 SafeTI Diagnostic Library Software Safety Manual(SPNU592)

Renesas 用 Safety Application Note (SAN) 作为 Safety Manual + Integration Manual 的混合载体:

• AoU 编号 + 解释:每条都说明"integrator 要做什么"
• 提供 ASIL-quality MCAL + Core Self Test 库

Tier-1 偷懒不做 item-level integration analysis 是最致命的反模式:

• 表现:Tier-1 拿到 SEooC 不做 item-level integration analysis,直接套用
• 后果:AoU 没验证 → 安全论证链断 → "SEooC's safety argument is no longer valid"

只读 datasheet 跳过 Safety Manual AoU + SM 章节是常态错误:

• 表现:只看 datasheet,跳过 Safety Manual 第 3、4 章 AoU + SM 列表
• 后果:漏关键 SM 配置 → "ASIL OS may get downgraded to non-ASIL"

Validation 不覆盖 AoU 边界等同于没验证:

• 表现:温度/电压 corner 只测 nominal,没测 AoU 边界
• 后果:实际 mission profile 应力下 SPFM 不达标,量产掉 ASIL

compiler / IDE 也是 SEooC,默认不做 qualification 落 TCL3 → assessment reject:

• 表现:用 GCC/IAR/Keil compiler,没做 ISO 26262-8 §11 tool qualification
• TCL 决定:TI(Tool Impact)× TD(Tool error Detection)→ TCL1/2/3;compiler 默认 TI2,未做 TD → TCL3
• 后果:safety case 在 assessment 时被 reject

把 confirmation reviewer 当形式 + 把 I 级与 M 级搞混是 ASIL-C/D 项目常见 reject 原因:

• 表现:confirmation reviewer 是同组同事(应 I2/I3),functional safety audit 没做或没独立性
• 常见误区:很多团队把 M1/M2/M3 搞混 — 这是车辆类别,不是 confirmation 独立性级别。正确是 I0/I1/I2/I3
• 后果:ASIL-C/D 项目过不了 assessment

用 datasheet 的 typical 值代替 Safety Manual 假设的边界值,是最隐蔽的一类"假通过":

• 表现:Tier-1 核对 AoU 时用 datasheet 的 typical/25 °C 数值(UVLO typ、propagation delay typ、λ typ)去打勾,而不是用 Safety Manual 的 FMEDA 所"假设"的 worst-case / mission-profile 应力值
• 根因:datasheet typical ≠ Safety Manual assumed context——后者带全温度 / 全寿命 mission profile 与保守余量,两套数值体系不同源
• 后果:AoU 表面满足、FMEDA 假设的 corner 不满足 → 量产在温度 / 电压 corner 下 SPFM 掉档(与 §3.2 六维 mismatch 同一物理根因)

把 Tier-2 交付的 FMEDA 数字当系统级指标直接引用,是 assessment 高频 reject 点:

• 表现:直接抄 Tier-2 FMEDA 的 SPFM / LFM / PMHF 当系统指标,不按真实工况重算、不做系统级整合
• 根因:供方 FMEDA 只覆盖元件边界、基于 AoU 假设的 mission profile,且不含跨器件 CCF / DFA(那是 item 上下文才产生的相关失效)
• 后果:系统 SPFM 虚高——真实工况 λ 更大 + 未计入跨芯片共因 → assessment 被 reject(正是 §8.3 A-09 系统级 DFA 与 §10.5 温度降额要闭合的点)

DIA 解决的核心问题是:SEooC 的安全论证链跨越组织边界——Tier-2 只交付元件级 work products,Tier-1 / OEM 用这些 work products 构建 item-level safety case。哪些安全活动由哪一方执行、谁最终负责、谁提供输入、谁需要被告知,如果没有明文约定,量产时必出争议(常见表现:某 FMEDA 参数谁确认?某 SM 的 validation 谁跑?Tool Qualification 报告谁出?)。

DIA 的法律地位:它是项目合同的安全附件,通常在 SOW 签署时同步签,assessment 时作为证据文件提交——缺少 DIA 或 DIA 不覆盖 ISO 26262-8 Clause 5 要求的活动,会被记为 major non-conformance。

通用 DIA 文档遵循如下结构(基于 ISO 26262-8 Clause 5 + Tier-1 行业实践):

以下 RACI 针对 400V/100kW EV 主驱逆变器(TC397 + TLF35584 + UCC21750-Q1),共 12 条关键安全活动;AoU 编号(如 AoU-D01/AoU-T07/AoU-S01)为便于 mapping 的示意编号,真实条款号以各芯片 NDA Safety Manual 为准:

R = Responsible(执行)/ A = Accountable(拍板)/ C = Consulted(输入)/ I = Informed(通知)。

RACI 关键设计原则:

• Tier-2 R/A 只限于元件级文档:安全论证到元件边界为止
• A-09 DFA 的 A 在 OEM:跨芯片 CCF 分析必须在 item 上下文做,Tier-1 执行但需 OEM 拍板(因跨子系统)
• A-11 Confirmation Review A 在 OEM:ASIL-D 要求 I3(不同部门),OEM 需参与最终确认

DIA 不是一次性文档,它随项目进展更新三次:

时序 1 — 项目启动(Concept Phase,典型第 1–2 个月):

• 签署 scope + party + 初始 RACI
• 约定三芯片 Safety Manual 版本锁定方式
• 输出:DIA v0.1(含 referenced documents 章节,Safety Manual 版本号写死)

时序 2 — 架构冻结(System Design Phase,典型第 4–6 个月):

• AoU 逐条核对完成,gap list 定稿
• FMEDA 系统级参数(温度 / FTTI / 工作点)确认
• 输出:DIA v1.0(含已签 AoU mapping 表)

时序 3 — 系统测试阶段(Integration & Testing,典型第 10–14 个月):

• LBIST corner test / fault injection / validation 测试结果整合
• 若有 Safety Manual 版本升级,触发 DIA delta-review
• 输出:DIA v2.0(含完整 validation evidence 引用)

以下是 400V/100kW 主驱逆变器三芯片的公开 FuSa 文档与(NDA)Safety Manual 锚点。要区分两类:公开的 "FuSa in a Nutshell" application notes 是入门/集成指引;真正带完整 AoU + FMEDA 的 Safety Manual 通常在 NDA 下发。

补充集成 AN(在 DIA §3 Referenced Documents 一并锁定):

每次 Tier-2 发布新版 Safety Manual,Tier-1 必须执行 delta-AoU 分析:

触发条件(任一):IC 版本(die revision)升级 / Safety Manual 主版本号变化 / 已知 AoU 条目内容修改。

delta-AoU 分析 3 步:

1. 对比新旧 Safety Manual AoU 清单(diff 工具或人工逐行)
2. 识别增加 / 修改 / 删除的 AoU 条目,评估对 item 上下文的影响
3. 必要时更新 DIA §4 RACI + §6 AoU 验证责任,重新获 FSM 签字

注意:OTA 软件升级若触发 MCU Safety Manual 版本变化,同样需要 delta-AoU — 这是 OTA 场景最易漏掉的安全活动(见 §10.3 案例 M3)。

示意 AoU-D01 假设栅极关断采用足够的负压偏置(VEE2 negative rail,SiC 典型 −2…−5 V),以在关断期间保证抗 Miller 串扰裕度。

失效路径:设计为省 BOM 用 0 V 或过小负压替代规范负压 → 高温重载下 SiC MOSFET(Vth 随结温下降)桥臂对管在互补管开通瞬间承受 dv/dt,经 Cgd 注入 Miller 电流 → 关断偏压不足以把栅极钳在阈值以下 → 意外导通(parasitic turn-on) → 桥臂直通短路(shoot-through),过流数倍额定电流 → 触发 UCC21750 fast DESAT(响应约 200 ns)软关断(400 mA soft turn-off);反复触发或单次能量越 SOA 即器件损伤。

DIA 闭合:DIA A-07 把"SiC 负压偏置 PCB 审核"列为 Tier-1 Responsible;AoU-D01 列入 §6 AoU 验证清单,在架构设计评审(DIA 时序 2)前完成确认。量产防护:AoU-D01 加入 DVT 检查 checklist,SI 仿真必须覆盖负压不足的误选场景。

示意 AoU-T07 假设 LBIST 在 MPFT(Multiple-Point Fault detection Time interval)内完成执行。

失效路径:LBIST 在 nominal(25 °C)下执行耗时约 80 ms(示意),设计中 MPFT 设定 100 ms(余量 25%)。−40 °C 低温下 MCU 主频/振荡器降额 + LBIST 算法耗时增加 → LBIST 超时触发 SMU alarm → 错误判 MCU 失效 → 系统进入 safe state(关断主驱)→ 低温冷启动时频繁 false safe-state → 车辆可用性丧失。

DIA 闭合:DIA A-06 列为 Tier-1 R/A;"LBIST 低温角专项 validation"写入 DIA §5 work products,在 DVT 阶段(−40 °C 冷箱测试)必须完成。修法:在低温环境下实测 LBIST 耗时,若接近 MPFT 则延长 MPFT 或拆分 LBIST 分段执行(TC397 支持)。

示意 AoU-S01 假设 MCU 在 TLF35584 窗口看门狗(WWD)的初始化窗内完成握手/首次喂狗。TLF35584 进入 INIT 状态后默认开一个 "Long Open Window",由 INIT timer(默认约 600 ms,可配)界定;窗内无有效喂狗或 ERR 服务 → 触发 fail-safe:SS1/SS2 拉低进安全态,并进入 QUC 断电重试序列。

失效路径:正常上电时 TC397 Startup SW 在数十 ms 内完成首次喂狗——AoU-S01 满足。OTA 固件下载场景:TC397 需先擦写 flash,再完成 Startup → 总启动时间延长至秒级 → 超出 WWD 初始化窗 → TLF35584 进 fail-safe / 复位 → OTA 固件写入中断 → flash 可能半写(brick 风险)。

DIA 闭合:DIA A-08 把"OTA 场景启动握手边界"列为 Tier-1 R/A,OEM 参与评审(C)。设计措施:OTA 前把 TLF35584 切到合适工作模式 / 在器件允许范围内配置 WWD 窗,或采用 A/B 双分区 OTA 让运行分区持续喂狗;此 gap 必须在 DIA §8 Open Issues 中明文记录直至闭合。

示意 AoU 假设芯片 SM 反应链落在系统 FTTI 预算之内(架构级假设,须在 item 上下文核算)。

失效路径:EV 主驱在 L4 自动驾驶场景下，OEM 安全分析师把 FTTI 从 50 ms 压缩至 10 ms(ASIL D 高速行驶 corner)→ 芯片 SM 反应链时序重新核算:DESAT 检测 + 软关断(UCC21750 约百 ns 级)+ MCU SMU alarm handler 分发(约 1–2 ms)+ FSM 安全状态转换(约 2 ms)→ 若系统层 FTTI = 10 ms,Tier-1 必须分析是否还有余量给通信/CAN 延迟——10 ms 边界几乎没有余量,任何路径延迟增加(高温、低温、负载突变)都可能违反 FTTI。

DIA 闭合:FTTI 的精确值必须写入 DIA §4 RACI 的 A-05(FMEDA 系统级参数),并在 DIA 时序 2(架构冻结)由 Tier-1 R、OEM A 共同签字确认;FTTI = 10 ms 场景需重跑完整 FTTI budget 分解(见 FTTI 预算分解深度)。

三芯片 FMEDA 均基于 IEC 62380 / SN 29500 失效率模型,示意假设 Tamb ≤ 85 °C(控制腔)/ Tj ≤ 125 °C。

失效路径:Tier-1 评估发现实际应用控制腔 Tamb 在高温路况(沙漠 45 °C 环境 + 逆变器满功率)下可达 95–100 °C → Tj 接近 135 °C → 按 Arrhenius 温度加速 $\lambda (T)\propto e^{-Ea/(kBT)}$,Tj 每升约 10–15 °C 失效率约翻倍量级 → TC397 内部 λD 各失效项上升 → SPFM 由 99.x% 逼近/跌破 ISO 26262-5 ASIL D 要求的 ≥ 99%(具体数字须重跑 FMEDA,此处为数量级示意)→ 系统级 SPFM 不达标,量产产线不能放行。

DIA 闭合:DIA A-05 把"FMEDA 系统级温度参数"列为 Tier-1 R/A;工程师必须在 DIA 时序 1(项目启动)就把 mission profile 实际 Tamb 分布提供给 Tier-2,若超出标准 FMEDA 假设则须委托 Tier-2 重出定制 FMEDA——这正是 NXP S32K3 提供"customer-configurable FMEDA"的价值所在。补救措施:热设计降低控制腔温度(散热路径设计)或采用结温更高的器件版本,使 Tj 回到 FMEDA 假设范围。

MCU 本身是 SEooC,但其上运行的 MCAL / AUTOSAR OS / SafeRTOS / Core Self-Test 库各自也是 SEooC,各带自己的 Safety Manual 与 AoU。集成方常只验硬件 MCU 的 AoU,漏掉下层软件 SEooC 的 AoU——例如 MCAL 假设"调用方保证 SPI 事务原子性"、Core Self-Test 库假设"每 FTTI 至少被调度一次"。AoU 是链式传递的:上层 SEooC 的某条 SM,落地时往往正是"下层 SEooC 的某条 AoU 必须成立"。闭合:把每一层 SEooC 的 Safety Manual 都提进 §3.3 的 AoU 追踪系统,逐层核 assumption,别停在硬件层。

SEooC 的 AoU 常写"targets up to ASIL D"——这是保守上界,不代表 item 必须用单一 ASIL D 通道。当 item 用 ASIL B(D) 分解(两条 B(D) 冗余通道合成 D)实现时,SEooC 的"内部两通道"若落在同一 die / 同一电源域 / 同一时钟树,分解所依赖的独立性不成立——共因失效会同时打掉两路,分解无效。闭合:ASIL 分解必须配 DFA(见 ASIL 分解 与 相关失效分析),核 SEooC 内部两通道的 CCF 隔离(物理 / 电气 / 时序);AoU 的"targets ASIL D"不替代 item 侧的分解独立性论证。

SEooC 的价值在复用,但一份 Safety Manual 服务多个 item 时,AoU 满足情况会分叉:item A(EPS,FTTI 10 ms、Tamb 85 °C)满足某条 AoU,item B(engine-bay inverter,FTTI 50 ms、Tamb 125 °C)违反同一条。常见错误是"A 项目已过 assessment,B 项目照抄证据"。闭合:每个 item 独立重跑 AoU 验证 + 独立 safety case——Safety Manual 可共享,safety argument 不可共享;§9.2 的 delta-AoU 规则同样适用于"同版本 Safety Manual 跨 item 复用",不只是"跨版本升级"。

ISO 26262 四个直接相关 part:

• ISO 26262-10:2018 §9 SEooC(标准本体,需购买)
• ISO 26262-2:2018 §6.4.9 Table 1 confirmation measures by ASIL
• ISO 26262-8:2018 Clause 5 Interfaces within distributed developments(DIA 依据条款)
• ISO 26262-8:2018 §11 tool qualification

权威解读 + 工程实战:

• Intertek — Exploring Safety Elements out of Context:https://www.intertek.com/blog/2026/01-15-exploring-safety-elements-out-of-context/
• Embitel — What is SEooC:https://www.embitel.com/blog/embedded-blog/what-is-safety-element-out-of-context-seooc-in-automotive-functional-safety
• Renesas Blog — Applying ISO 26262 to SEooC Software:https://www.renesas.com/en/blogs/renesas-functional-safety-support-automotive-3-applying-iso-26262-standard-seooc-software
• functionalsafetyfirst.com — SEooC for Dummies:https://www.functionalsafetyfirst.com/2020/10/seooc-for-dummies.html
• Electronic Design — Apply the ISO 26262 SEooC Model:https://www.electronicdesign.com/markets/automotive/article/21808428/apply-the-iso-26262-seooc-model-to-automotive-software
• Synopsys SEooC V&V whitepaper:https://www.synopsys.com/dw/doc.php/wp/automotive_verification_validation_seooc_wp.pdf

Tier-2 主流 IC vendor 的 SEooC 文档锚点:

• Infineon AURIX TC3xx — AN1001/AN1002 FuSa in a Nutshell:https://www.infineon.com/dgdl/Infineon-AN1002-FuSa_in_a_Nutshell_Introduction_to_AURIX_TC3xx_functional_safety-ApplicationNotes-v01_00-EN.pdf
• NXP S32K3 SafeAssure:https://www.nxp.com/company/blog/meeting-functional-safety-requirements-with-s32k3-mcus:BL-SAFETY-REQUIREMENTS-WITH-S32K3-MCUS
• NXP AN14068 S32K3 + FS26 hardware/safety guide:https://www.nxp.com/docs/en/application-note/AN14068.pdf
• TI Hercules SPNU620 Safety Manual:https://www.ti.com/lit/fs/spnu620a/spnu620a.pdf
• Microchip Sample MCU Safety Manual DS40002252A:https://ww1.microchip.com/downloads/en/DeviceDoc/Sample-MCU-Safety-Manual-DS40002252A.pdf
• ST AN5691 ASM330LHB safety library:https://www.st.com/resource/en/application_note/an5691-asm330lhbxxasilblibrary-safety-manual-stmicroelectronics.pdf

独立性 I1/I2/I3 + Tool Qual 权威源:

• BRACE Automotive — Confirmation Measures:https://www.brace-automotive.com/en/blog/add-value-your-iso-26262-development-confirmation-measures
• Spyrosoft — ISO 26262 guide:https://spyro-soft.com/iso-26262
• piembsystech — Tool Qualification TCL:https://piembsystech.com/tool-qualification-tcl-iso-26262/
• Siemens Verification Horizons — Clearing the Fog of Tool Qualification:https://blogs.sw.siemens.com/verificationhorizons/2022/04/13/clearing-the-fog-of-iso-26262-tool-qualification/

Safety Case Argument + Mission Profile:

• Lorit Consultancy GSN-SEooC Paper:https://lorit-consultancy.com/wp-content/uploads/2017/02/GSN-SEooC-Paper-8-April-161.pdf
• Power Electronics News — Mission Profile:https://www.powerelectronicsnews.com/ebook-may-21-8-automotive-electronics-reliability-testing-starts-and-ends-with-the-mission-profile/