ISO 26262-6(2018)软件层细化:HSI / 架构 / 单元 / 集成 / 测试

软件安全需求不是从 TSC 直接复制,而是基于:

• TSC 分配给软件的部分(从 ISO 26262-4)
• 软件需要支持的安全行为(safety mechanism 的软件实现)
• 安全相关属性(robustness / 独立性 / fault tolerance)

例 1:TSC 要求"扭矩偏差超 10% 时进入 safe state"——拆成两个软件需求:(a) 比较扭矩参考与实测每 10ms 一次 + (b) 偏差 > 10% 时通过 SPI 拉低 SBC 的 FCCU 输入。

例 2:robustness 属性——software 要在传感器输入超出物理范围时不崩(NaN / overflow / out-of-range 都要处理)。这不直接来自 TSC,但软件规范里要列出来作为隐式安全要求。

HSI 是 Part 5 和 Part 6 之间的合同,必须包含:

1. Operational mode and configuration:寄存器 / 配置 bit / 工作模式
2. Hardware features used by software:用了 timer 1 / DMA channel 5 / ADC channel 0-7 等
3. Shared resources:中断号、内存映射、总线
4. Diagnostic interface:诊断 SM 怎么读硬件状态
5. Configuration parameters:增益控制、带通频率、时钟分频

工程关键:HSI 必须由系统 / 硬件 / 软件三方联合签字(6.4.6),任意一方更改要全部 review。这是为什么 OEM 要求所有 HSI 改动都进版本控制 + Tier 1 / 半导体厂同步。

这一节先把“8 个架构特性(7.4.1)”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

ASIL D 要求8 个特性都要有明确证据;ASIL A 比较松。

这一节先把“表示方法(Table 2)”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。

ASIL D 强烈推荐 semi-formal——大部分工程用 SysML / UML state diagram;formal 是可选。

关键概念:当混合 ASIL 模块同存于一个 ECU 时,低 ASIL 模块不能影响高 ASIL 模块。要论证 3 类机制:

1. 时间隔离:低 ASIL 模块不能因死循环 / 长执行时间影响高 ASIL 模块的实时性。机制:OSEK / AUTOSAR OS 的时间预算 + execution monitor + watchdog
2. 空间隔离:低 ASIL 模块不能写到高 ASIL 模块的内存。机制:MMU / MPU + 内存分区
3. 信息交换隔离:低 ASIL 数据流不能污染高 ASIL 数据。机制:消息端口检查 + sequence number + checksum

工程实操:没有 MMU/MPU 的小 MCU(STM32 G4 / TI C2000)做混合 ASIL 必须靠"代码合并 + 全部按高 ASIL 开发"——成本暴涨。所以选 MCU 时如果可能有混合 ASIL,优先选有 MPU 的。

Unit 不是"一个文件"——是最小可单测验证的代码单元(典型一个状态机 / 一个算法函数)。每个 unit 都要:

• 单元设计文档(行为 / 接口 / 边界条件)
• 实现(可能是 C 代码或 Simulink 模型)
• 单元测试用例

每个安全相关 unit 的设计要符合 Table 7 设计原则(命名清晰 / 限制参数数量 / 单出口 / 限制 goto / 避免动态对象创建)。

测试覆盖度按 ASIL 推荐:

ASIL D 项目典型要求:100% statement + 100% branch + ≥ 95% MC/DC(完全 MC/DC 不切实际但要求很高)。这通常用 LDRA / VectorCAST 等工具自动算覆盖率。

集成测试不只是"功能验证"——重点验证架构层面的安全要求:

• 单元间接口的时序 / 数据完整性
• HSI 的实际行为符合规范
• Freedom from interference 实测验证(故障注入)
• Resource usage(stack / heap / CPU 使用率)

最后一关是"在目标硬件上跑全功能":

• HIL(Hardware-in-the-Loop)环境
• Fault injection(注故障验证 SM 反应)
• Worst-case execution time(WCET)分析
• 长时间稳定性测试

TSC 到 SW-SR 的推导不是"复制粘贴",而是把系统级要求映射到软件可验证的接口与时序。以下三条 SW-SR 来自 TSC 对 SG-01(防意外扭矩)的分配。

FTTI 推导:SW-SR-01 检测 3 ms + SW 发命令 5 ms + TLF35584 safe-state 响应约 1 ms(数量级)= SW 路径约 9 ms ≪ FTTI 200 ms;SW 路径作冗余,ASIL D 主路径为 HW DESAT(约 1.3 µs)。

HSI 是 Part 5/6 法律合同,但工程上最常见的漏洞是只列信号名称、不写时序与公差——Clause 6.4.5 明确要求 operational modes, hardware features used, shared resources, diagnostic interface, configuration parameters 全部涵盖。下面按 5 类逐项展开示例参数。

Class 1 — Operational Mode & Configuration(示例值,落地以 TC397 DS / TLF35584 SM 锁定版核定):

Class 2 — Hardware Features Used by Software:

• ADC Module 0 CH0–5:三相电流(分流 0.5 mΩ ISA-PLAN),量程 ±250 A,12-bit,ADC trigger 由 GTM-ATOM PWM 中点触发,触发抖动 ≤ 100 ns
• GTM-ATOM0 CH0–5:6 路 PWM,10 kHz,死区 300 ns(25°C),跨接 CDTM 禁止信号用于 FAULT 硬件直接封锁 PWM
• QSPI2:WdgM 使用,TLF35584 WDT 刷新;WDT 刷新必须在 WD_WIN2 − 1 ms(约 7 ms)内完成,不可被其他任务抢占

Class 3 — Shared Resources:

• QSPI2 被 WdgM 和 CAN-SPI bridge 共用 → OSEK OS 需为 WdgM 任务分配 IRQ level 高于 CAN task,防止 WDT 刷新饥饿
• 中断向量 INT_GTM_ATOM0_CH0:优先级 0(最高),不可屏蔽;任何 BSW 任务不得关闭此中断超过 50 µs

Class 4 — Diagnostic Interface:

• TC397 Lockstep 比较错误:WdgM 每 5 ms 轮询一次 SMU alarm 状态(具体寄存器偏移以 TC397 Safety Manual 为准)
• TLF35584 safe-state pin:active-low,断言后约 100 ns 内有效;SSM 读取时序要求在断言后 500 µs 内响应(SW 路径 FDTI 中分配)

Class 5 — Configuration Parameters:

架构合规的证据分两层:ASIL 分解论证(说明哪块软件跑在哪个 ASIL、靠什么独立性机制)与 Freedom from Interference 的具体隔离配置(MPU + OS partition)。先给分解论证。

ASIL 分解论证(semi-formal):

Freedom from Interference MPU 配置(Clause 7.4.11 + Annex D,地址为示例):

验证:集成测试 ITC-FFI-001 执行 CPU2 向 R0 非法写 → 触发 MPU trap → CPU2 ShutdownOS → CPU0/CPU1 继续运行 250 ms 不受影响(HIL 环境实测记录时间戳作为验收证据)。

工具链:PC-lint Plus + LDRA Testbed MISRA C:2012 checker。违例记录在 SARD(Software Analysis and Review Document),每条需:Rule ID + 违例位置 + 偏差类型 + 工程师 + 审查者签字。示例统计如下。

最高危未偏差项:Rule 14.4(控制表达式必须为 essential Boolean)—— TC397 SMU/Lockstep 状态寄存器返回 uint32,若直接写 if (CCMERR_FLAG) 违反此规则但逻辑无误;必须显式转换 if (CCMERR_FLAG != 0u) 才合规。

工具:LDRA Testbed,Tasking VX-toolset instrumented build。方法:object-code instrumentation(非源码),以排除编译器优化导致的源码到机器码不一致。覆盖率关键在于 MC/DC 的独立对(independence pair)数——N 个条件的判定,MC/DC 最少需 N+1 个测试向量,每个条件贡献 1 个独立对(共 N 对,coupled 条件会更少)。下表为示例测量结果。

未覆盖对说明:TorqueFSM 独立对 "C11-C12"(通道 A 与通道 B 电流传感器互相校验)——只有真实传感器单路故障才能到达此分支,软件仿真无法构造;由 Clause 11 HIL 故障注入测试(FI-TorqueFSM-001)覆盖,并在测试规范中记录为"覆盖方式转移",审核员须接受此论证(需事前与审核员就转移接受度达成一致)。

按 ISO 26262-8 Clause 11,所有用于 ASIL D 安全工作产物的工具需确定 TCL(Tool Confidence Level)并执行对应资质活动。示例资质链如下。

TCL3 何时需要:仅在工具输出无法被任何方式独立核查时才需 TCL3(如形式化证明工具、模型检测器输出)。本项目所有工具均有可比对的输出(binary / 覆盖报告 / 静态分析结果),无需 TCL3——误标 TCL3 会引入不可完成的验证义务。

FFI 证明需要在目标硬件上执行故障注入,不能只靠 MPU 配置文档声明。以下为集成阶段的 FFI 故障注入验收用例(HIL 实测填入时间戳)。

测试工程师以"Branch Coverage 100%"报告满足条件覆盖——实为混淆 Branch 和 MC/DC。单个多条件决策 if (A && B && C) 有 3 个条件,MC/DC 最少需 N+1 = 4 个测试向量(每个条件贡献 1 个独立对,共 N = 3 对);而 Branch Coverage 只需两组(全真/全假)即报 100%。识别:LDRA / LCOV 报告里 "Branch Coverage" 和 "MC/DC Coverage" 是两个不同指标,必须明确指定 MC/DC 模式并由项目经理在测试计划中写明。后果:Functional Safety Manager 在 Part 6 工作产物评审时发现覆盖率报告写的是 Branch,需重跑 MC/DC 并重新获取审查签字。

HSI 文档列出信号名称和电气参数,遗漏时序要求:如 SPI WDT refresh 必须在 WD_WIN2 − 1 ms 内完成、ADC trigger jitter ≤ 100 ns、safe-state pin 响应时间 ≤ 100 ns。没有时序的 HSI 在 Clause 10 集成测试中无法生成时序测试用例,审核员会以 "HSI 不完整" 拒绝 Part 5/6 接口闭合。修复:HSI 表格增加 "Timing" 列,每个信号填 trigger source、max latency、jitter tolerance。

项目团队声称编译器为 TCL3,但无法提供 TCL3 所要求的独立验证测试集——实际上 Tasking 作为 established tool 仅需 TCL1(output comparison 即可)。识别:ISO 26262-8 对 TCL 有清晰映射;compiler 和 lint 工具通常 TCL1/2 足够,只有无可比对输出的工具(如模型检测器)才用 TCL3。后果:声明 TCL3 但未执行对应资质活动 → 工具资质记录缺失 → Part 6 工具 WP 评审不通过。

WdgM_CheckpointReached 被正确调用但任务陷入无限循环反复 checkpoint——alive supervision 无法检出,因为它只检测"是否定期调用"。Deadline supervision 检测任务从起点到终点的最大时间;Logical supervision 检测 checkpoint 调用顺序(A→B→C 的 DAG 图)。ASIL D 需三种 supervision 全配;项目如仅配 alive,审核员发现后需补设计文档 + 重新 FMEDA 验证 WdgM DC。

MPU region 表配置正确,但 linker script 中 CPU0 Safety stack 的 VMA 与 CPU2 的 DSPR 段没有明确 NOLOAD 保护——链接器在极端优化或段重排时可能允许地址重叠。MPU 是运行时机制,linker script 是编译时约束,二者都要配。识别:在 map 文件中搜索 CPU0 Safety stack 地址范围,确认无其他 section 交叉;集成测试 ITC-FFI-001 是端到端验证。

HSI 三方(系统 / 硬件 / 软件)签字通常只在 OEM ↔ Tier-1 层。若 HSI 包含 SEooC 芯片(TC397 / TLF35584)的 AoU 引用,芯片供应商 SM(Safety Manual)版本必须锁定在 HSI 附录,且芯片供应商需确认 AoU 成立。不锁定版本 → 芯片升版后 AoU 变化 → HSI 悄然失效。缓解:HSI 附录增加 "SEooC 版本锁定表"(器件名 / SM 版本 / 锁定日期 / 变更触发条件)。

标定工程师认为"只改标定数据不改代码"不需要 SW 变更流程——但 ISO 26262-6 Annex C 明确:配置数据是软件的一部分,需经 Part 6 全流程(impact analysis + re-test + sign-off)。高风险:扭矩极限标定值、过流阈值被修改后,安全案例里 FMEDA 中的 "safety threshold = 300 A" 失效,但 Safety Case 中无记录。缓解:在 CM 工具(DOORS / Polarion)中为 A2L / CDF 文件建立 safety baseline,任何标定更改触发 "safety relevant change?" 问答,yes → 走 Part 6 变更流程。

TC397 LBIST(Logic Built-In Self-Test)在 −40°C 冷启动时间比 25°C 明显延长(倍增因子以 TC397 Safety Manual 低温特性表为准)。示例序列:Power-on 50 ms + LBIST 80 ms + SW init 30 ms = 160 ms,FTTI 200 ms 余量 40 ms(20%)。若低温 LBIST 延至 110 ms → 190 ms,余量仅 10 ms(5%)——仍过门但在 ASIL D 工作产物中须量化记录;若系统架构在 L4 场景将 FTTI 压缩到 150 ms,则低温启动直接超标。缓解选项:TC397 提供 Fast Startup Mode(缩短 LBIST),但 DC 降额 → 需 Safety Manager 批准并在 FMEDA 中更新 DC_SPF。

L4 无驾驶员接管场景下 SG-01 FTTI 可能被系统安全架构压缩到 50 ms 乃至 10 ms。SW 扭矩监督路径(SW-SR-01)检测时间 3 ms + 发命令 5 ms + TLF35584 safe-state 响应 1 ms = 9 ms,FTTI 10 ms 余量仅 1 ms(10%)——已进入不可靠区域(任何 OS 调度抖动都可能超限)。此时 Part 6 设计必须将主 ASIL D 路径从 SW FSM 切换为 HW DESAT(约 1.3 µs 响应),SW 路径降为 ASIL B 冗余/诊断。系统含义:Part 4 TSC 需在 ASIL 路径分配中显式写明"若 FTTI < 50 ms,SW 路径不作主路径",否则 Part 6 审核员会拒绝 SW 路径的 ASIL D 主路径声明。

OTA 升级软件后,以下 Part 6 工作产物需重评估:(1) MISRA C 基线——新代码模块若引入新的 required violations,需更新 SARD 并重审;(2) MC/DC 覆盖集——新单元未被测试用例覆盖,需补充;(3) 工具 TCL 记录——若工具链版本升级,需重执行 TCL 资质确认(TCL1 output comparison / TCL2 TVS);(4) HSI 版本——若新 SW 版本改变信号时序需求,三方需重新签字。若 OTA 声称"只改标定数据",需通过 Annex C 分离性论证证明标定数据与 SW 逻辑完全独立(独立存储 / 独立 CM / 独立安全基线)——否则整个 Part 6 流程重跑。