ISO 26262-2(2018)管理层细化:Safety Lifecycle / 安全文化 / 确认措施

ISO 26262 列出安全文化 7 条特征,公司要有证据(培训 / 政策 / 案例):

1. Senior management leadership — 管理层亲自抓安全,不只是 Quality 或 Safety 部门孤军奋战
2. Effective communication — 跨职能(EE / SW / Mech / Test)信息流通,不能"each ECU 闭门造车"
3. Openness about safety anomalies — 任何人发现 safety 问题敢报告,不被打压
4. Non-tolerance for shortcuts — 不为赶 deadline 跳过 verification
5. Adequate education and competence — 持续培训
6. Active reward of safety-positive behaviors — 主动奖励严谨工作的人
7. Recognition of personal responsibility — 每个人都要为自己负责的部分担当

工程实务:TÜV 评审会问员工"如果你在调试时发现一个 SG 违反风险,你的处理流程是什么?"——回答"先告诉 FSE 评估"才合格,回答"先看影响 deadline 不"或"自行 fix 不上报"是直接 fail。

ISO 26262 把"独立审视开发结果"分三类,工程实务里经常被混淆:

Part 2 强制要求 Safety Plan 是项目启动 work product:

1. Project scope — item 边界 / 适用 ASIL / 假设
2. Roles and responsibilities — Project Manager / Safety Manager / FSE / Verification Engineer / Confirmation Reviewer 各自职责
3. Schedule — milestone + safety activities 时间表
4. Work products — Part 3-7 全部 work product 的 ID + due date + owner
5. Resources — 工具链 / 测试设备 / 人力
6. Confirmation measures planning — 哪些 review/audit/assessment 在何时做
7. Tailoring decisions — 哪些标准条款不适用,理由

工程实务:Safety Plan 是开发期间的 living document——每个 milestone 更新一次,不是写完就锁;Safety Manager 是 owner。

ISO 26262 强制:任何修改 / 复用都要做 impact analysis,看是否触发 safety lifecycle 重做。

ASIL D 项目 release 必须有以下签字 work product:

任何一份没签字 → 不能 release for production。这就是 OEM 项目延期的常见原因——TÜV 评审找出 1-2 个 issue,要返工 + 重测 + 再评审,几个月延期是常事。

2018 修订版新增内容:FuSa 与 Cybersecurity 的关系:

• Cybersecurity attack 可能触发 SG 违反(例:攻击者通过 CAN bus 发送恶意扭矩命令)
• FuSa 范围限于"malfunctioning behavior",cyberattack 是"intentional",ISO/SAE 21434 是 cybersecurity 母标准
• 实务上两个工作产品要协调——SecOC(Secure Onboard Communication)既是 cybersecurity 控制 又是 FuSa 的 SM(详见 CAN E2E + SecOC)

本节把 §1-§7 的抽象条款落到一个完整 ASIL D 项目时间线上,展示 Safety Plan / Confirmation Measures / Release for Production 如何在 18 个月里咬合。工程不变量:Safety Plan 必须是 living document(每 milestone 更新);Confirmation Measures 的独立性按 ASIL 递增(ASIL D 关键工作产品 → I3);Release for Production 需 6+ 签字工作产品全齐。任何一环滞后 → Release 延期,这是 OEM 量产延期的首要 FuSa 根因。

目标系统:400V/100kW EV 主驱逆变器,TC397(MCU,ASIL D)+ TLF35584(SBC,ASIL D)+ 1EDI3035AS(栅驱,ASIL D)+ SCT3080AL×6(SiC MOSFET);Tier 1 开发;OEM 客户 ASIL D 项目(SG-01「避免非预期扭矩」,FTTI = 200 ms);TÜV Rheinland 担任 I3 独立评估方。此案例与 Safety Assessment / Audit 的同名工程线共用一套器件与时间轴,便于横向对照。

以下 7 条来自 ASIL D 项目实测的返工根因,按危害度排序,每条给出现象 / 物理本质 / 防御。

G1 — Safety Plan 不 living(写完即锁)★ 最高危:Safety Plan v1.0 在 M0 签字后被 CM 系统「归档」→ M8 硬件架构发生重大变更(加了 ASIL 分解)→ Safety Plan 未更新 → M14 评审时 TÜV 发现 Safety Plan 与实际进度不符 → NC。本质:ISO 26262-2 Clause 6.5.3 要求 Safety Plan 是 living document、每 milestone 更新,Safety Manager 是 owner;若 SM 被 PM 压力「固化」计划则违标。影响量级:NC 修复 + TÜV 复审 → 数周延期 + ECR 重评审成本。

G2 — 独立性等级选错(I2 充 I3):团队认为「同公司但完全不同事业部」不够,坚持要找不同法律实体,或反过来用同部门不同 team(I2)交付 ASIL D 的 FSA。要点:I3 = 组织/部门独立即满足(不同部门 / 独立事业部 / 第三方均可),ISO 26262 并不强制不同法律实体;第三方(TÜV/SGS/DEKRA/exida)是惯例而非强制。判据看 org-chart:若审方与被审方最终汇报同一 Safety Director 则仍是 I2,ASIL D 的 HARA/FSC/TSC/Safety Case 会被 TÜV 砍(依据 Clause 6.4.9 + Table 1)。防御:DIA 签约时锁定 I3 来源与档期(至少提前 6 个月),不到 M17 才找。

G3 — Assessment 启动过晚(M17 才第一次 I3):省掉 M14 Interim Assessment → M17 Final 第一次看全套工作产品 → 一次性抓出大量 NC → 全面返工 → Release 延期数月。最佳实践:ASIL D 项目至少 2 轮 I3 接触(Interim + Final),Interim 早暴露早修。

G4 — FMEDA 版本漂移(Assessment 看的不是最新版):M17 Assessment 时 FMEDA 已到 v3.1,但 TÜV 手里是 M14 发的 v2.0 → TÜV 说 SPFM 数字不对(v2.0 = 96.9%,v3.1 = 99.24%)→ 双方花 2 天才搞清是版本问题,浪费 Assessment 时间。注:ASIL D 的 SPFM 目标 ≥ 99%,v2.0 的 96.9% 本就不达标,v3.1 才过线。防御:发给 I3 的每份工作产品必须带文档 ID + 版本号,DIA 里约定「发版本 = SM 确认邮件 + CM 记录」。

G5 — Tailoring 无书面理由:Safety Plan 里 tailoring 只写「Not Applicable」不写理由 → confirmation review 判定 tailoring 论证不充分(ISO 26262-2 要求 tailoring 须有充分 rationale 并经确认)→ NC → 补写论证 + 再走 CR → 数周延期。

G6 — 安全文化违反(openness 缺失)的实际发生路径:硬件工程师发现 FMEDA 里 TLF35584 的失效率 ${\lambda }_D$ 用了供应商未公开核实的内部数据 → 怕延期不敢上报 → 私下改数字 → TÜV Assessment 时发现数据来源不可追溯 → 严重 NC + 数据完整性受质疑 → 更长延期。对策:SM 明确建立「Safety Anomaly 报告不追责」政策(呼应 §2 安全文化第 3 条 openness),Safety Plan 列「任何人发现数据可疑经 Safety Anomaly 系统上报,SM 24 小时内响应」。

G7 — Impact Analysis 未触发(OTA 后):ECU SW 经 OTA 从 v1.2 升到 v1.3(改了 WdgM alive supervision 周期 5ms→8ms)→ 未做 impact analysis → 实际看门狗 DC 从 99% 降至 87% → 量产车队 SPFM 不达标。依据:任何修改(含 OTA)必须先按 ISO 26262-8 Clause 8 变更管理做影响分析,再按 Part 2 Clause 6.4.9 判定是否重触发确认措施(见 §5 Impact Analysis)。

主线覆盖常规项目;以下 3 个边界工况是 Safety Manager 排期时最易踩的「非线性」坑。

C1 — Safety Manager 中途更换(M10 离职):新 SM 对现有工作产品状态不熟 → Safety Plan 不更新 → Confirmation Review 计划漂移 → M14 Interim Assessment 发现 Safety Plan 最后一次更新在 M6,6 个月空窗。对策(Safety Manual / DIA 层实践,ISO 未给专门条款):Safety Plan 写明「SM 变更时新 SM 须在 2 周内完成状态核查并出具 Safety Anomaly 记录确认」;DIA 条款要求变更 SM 时通知 OEM。

C2 — 多 ECU 系统 PMHF 预算分配超标:整车 3 个 ECU 各自 ASIL D,若把总 PMHF 目标平均切分:$\text{PMHF}/3\le 10\text{FIT}/3\approx 3.3\text{FIT}$,而 HV 逆变器 ECU 单算 PMHF = 6.8 FIT(与 Safety Assessment / Audit §10.2 共用案例的 FMEDA v3 一致)→ 超出 3.3 FIT 的平均配额。注:ASIL D 的 PMHF 目标是整链 < 10 FIT,平均切分只是简化假设,真实分配应按各 ECU 复杂度加权。对策:多 ECU 系统在 M0 Safety Plan 就协商好 PMHF 分配矩阵(依据见 ISO 26262-9 ASIL 分析 的分解规则与 Part 5 的 PMHF 目标),不到 M16 才发现。

C3 — L4 自动驾驶场景 Controllability 重评:客户 OEM 把同一 HV 逆变器 ECU 用于 L4 车型 → 驾驶员消失 → 原本依赖「驾驶员可控」的 hazard(有人驾驶时评 C2 正常可控)必须重评:无驾驶员时该维按 C3(不可由驾驶员控制)处理 → 见 HARA 的 C0-C3 定义(C 值越大越不可控、ASIL 越高)。ASIL 本已在 D 封顶不再升,但原先「驾驶员接管」的 FTTI 假设全部失效,TSC/FMEDA/DFA 相关工作产品返工。对策:item scope 在 Safety Plan 中明确含/排 L4 use case;后续扩展 L4 必须触发新的 item 级 impact analysis(见 §5)。

• standard · standard_iso26262_part2 — ISO 26262 Part 2 Management of FS