ISO 26262-6(2018)软件层细化:HSI / 架构 / 单元 / 集成 / 测试
本质与导读
本质 Part 6 真正的要求不是怎么写代码,而是把软件做成可逐段独立证明"符合 ASIL × 工程方法"的可追溯产物——从 TSC 一路推到单元测试与集成;MISRA C / 静态分析只是手段。其杀手锏是 Table 1-15:对每个 ASIL 等级规定哪种方法必须用 / 推荐 / 可选,工程评审拿它当 checklist。
1. Part 6 五段开发流程
Reference Phase Model(Figure 2):
| 阶段 | Clause | 输入 | 输出 |
|---|---|---|---|
| 1. 软件安全需求规范 | 6 | TSC + HSI 初稿 | 软件安全需求 + HSI 细化 |
| 2. 软件架构设计 | 7 | 软件需求 | 架构 + 安全分析 |
| 3. 软件单元设计与实现 | 8 | 架构 | 代码 + 单元规范 |
| 4. 软件单元验证(单元测试) | 9 | 单元代码 | 单元测试报告 |
| 5. 软件集成与验证 | 10 | 所有单元 | 集成测试报告 |
| 6. 嵌入式软件测试 | 11 | 集成软件 | 软件验证报告 |
每个阶段都有专属 work products(WP),WP 串成完整的可追溯链——从 SG 一路追到代码每一行单元测试。
2. 软件安全需求与 HSI(Clause 6)
2.1 软件安全需求的来源
软件安全需求不是从 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,但软件规范里要列出来作为隐式安全要求。
2.2 HSI(Hardware-Software Interface)5 类信息
HSI 是 Part 5 和 Part 6 之间的合同,必须包含:
- Operational mode and configuration:寄存器 / 配置 bit / 工作模式
- Hardware features used by software:用了 timer 1 / DMA channel 5 / ADC channel 0-7 等
- Shared resources:中断号、内存映射、总线
- Diagnostic interface:诊断 SM 怎么读硬件状态
- Configuration parameters:增益控制、带通频率、时钟分频
工程关键:HSI 必须由系统 / 硬件 / 软件三方联合签字(6.4.6),任意一方更改要全部 review。这是为什么 OEM 要求所有 HSI 改动都进版本控制 + Tier 1 / 半导体厂同步。
3. 软件架构设计(Clause 7)
3.1 8 个架构特性(7.4.1)
这一节先把“8 个架构特性(7.4.1)”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。
| 特性 | 含义 |
|---|---|
| Comprehensibility | 易理解,新工程师能短时间上手 |
| Consistency | 各模块设计原则一致 |
| Simplicity | 简单优先,避免过度抽象 |
| Verifiability | 可形式化或单测验证 |
| Modularity | 高内聚低耦合 |
| Abstraction | 复杂度藏到接口下 |
| Encapsulation | 数据 + 行为绑死,封装边界清晰 |
| Maintainability | 后续可改不破坏 |
ASIL D 要求8 个特性都要有明确证据;ASIL A 比较松。
3.2 表示方法(Table 2)
这一节先把“表示方法(Table 2)”的判断维度收拢到同一视图里，后面的表格用于横向比较各选项的边界。
| ASIL | A | B | C | D |
|---|---|---|---|---|
| Natural language(自然语言) | ++ | ++ | ++ | ++ |
| Informal notations(框图 / 流程图) | ++ | ++ | + | + |
| Semi-formal notations(UML 类图 / 状态图) | + | ++ | ++ | ++ |
| Formal notations(Z / VDM / B 方法) | + | + | + | + |
ASIL D 强烈推荐 semi-formal——大部分工程用 SysML / UML state diagram;formal 是可选。
3.3 Freedom from Interference(免干扰,Annex D)
关键概念:当混合 ASIL 模块同存于一个 ECU 时,低 ASIL 模块不能影响高 ASIL 模块。要论证 3 类机制:
- 时间隔离:低 ASIL 模块不能因死循环 / 长执行时间影响高 ASIL 模块的实时性。机制:OSEK / AUTOSAR OS 的时间预算 + execution monitor + watchdog
- 空间隔离:低 ASIL 模块不能写到高 ASIL 模块的内存。机制:MMU / MPU + 内存分区
- 信息交换隔离:低 ASIL 数据流不能污染高 ASIL 数据。机制:消息端口检查 + sequence number + checksum
工程实操:没有 MMU/MPU 的小 MCU(STM32 G4 / TI C2000)做混合 ASIL 必须靠"代码合并 + 全部按高 ASIL 开发"——成本暴涨。所以选 MCU 时如果可能有混合 ASIL,优先选有 MPU 的。
4. ASIL × 工程方法表(Table 1 编程语言准则)
Part 6 的灵魂是"按 ASIL 推荐工程方法"的诸多表。以编程语言准则(Table 1)为例:
| 准则 | A | B | C | D |
|---|---|---|---|---|
| Enforcement of low complexity(强制低复杂度) | ++ | ++ | ++ | ++ |
| Use of language subsets(语言子集,如 MISRA-C) | + | ++ | ++ | ++ |
| Enforcement of strong typing(强类型) | ++ | ++ | ++ | ++ |
| Use of defensive implementation(防御式编程) | + | + | ++ | ++ |
| Use of well-trusted design principles(可信设计原则) | + | + | ++ | ++ |
| Use of unambiguous graphical representation | + | + | + | |
| Use of style guides(风格指南) | + | ++ | ++ | ++ |
| Use of naming conventions(命名规范) | ++ | ++ | ++ | ++ |
工程实务:MISRA C 是 ISO 26262 ASIL D 的事实标配语言子集——把 C 的 unsafe 部分(union / pointer arithmetic / switch fall-through 等)禁了。模型驱动开发(MBD)用 Simulink + Embedded Coder 也要应用 MISRA AC 系列模型规范。
5. 软件实现与测试(Clause 8-9-10-11)
5.1 单元设计与实现(Clause 8)
Unit 不是"一个文件"——是最小可单测验证的代码单元(典型一个状态机 / 一个算法函数)。每个 unit 都要:
- 单元设计文档(行为 / 接口 / 边界条件)
- 实现(可能是 C 代码或 Simulink 模型)
- 单元测试用例
每个安全相关 unit 的设计要符合 Table 7 设计原则(命名清晰 / 限制参数数量 / 单出口 / 限制 goto / 避免动态对象创建)。
5.2 单元测试覆盖(Clause 9 + Table 12)
测试覆盖度按 ASIL 推荐:
| 覆盖度 | A | B | C | D |
|---|---|---|---|---|
| Statement coverage(语句覆盖) | ++ | ++ | + | + |
| Branch coverage(分支覆盖) | + | ++ | ++ | ++ |
| MC/DC(条件 / 决策修正覆盖) | + | + | ++ |
ASIL D 项目典型要求:100% statement + 100% branch + ≥ 95% MC/DC(完全 MC/DC 不切实际但要求很高)。这通常用 LDRA / VectorCAST 等工具自动算覆盖率。
5.3 集成测试(Clause 10)
集成测试不只是"功能验证"——重点验证架构层面的安全要求:
- 单元间接口的时序 / 数据完整性
- HSI 的实际行为符合规范
- Freedom from interference 实测验证(故障注入)
- Resource usage(stack / heap / CPU 使用率)
5.4 嵌入式软件测试(Clause 11 + Table 14)
最后一关是"在目标硬件上跑全功能":
- HIL(Hardware-in-the-Loop)环境
- Fault injection(注故障验证 SM 反应)
- Worst-case execution time(WCET)分析
- 长时间稳定性测试
6. Annex C 软件配置(Configurable Software)
Part 6 Annex C 处理一类特殊软件:配置数据(Calibration / Variant)是产品——同一份代码烧不同标定数据生成不同的 ECU 变种。每个标定数据要按 ASIL 走 Part 6 全流程,这是为什么:
- 标定工程师属于安全团队
- ASAM CDF / A2L 文件是 controlled work product
- 标定改动也要经过 change control 流程
7. Annex E 软件层 DFA / FMEA
软件级 DFA 要识别:
- 共因失效:多个 software 模块共用 RTOS / 共用驱动 / 共用 ISR → 一个 RTOS bug 同时打挂多模块
- 级联失效:模块 A 输出错误 → 模块 B 接受错误输入 → 链式崩
软件级 FMEA(Annex E)用 software FMEA 表识别每个模块的失效模式 + 影响 + 检测 + 严重度。比硬件 FMEA 更难——软件 failure mode 不像电阻短路那样可枚举。
核心要点
- Part 6 五段:软件安全需求 → 架构 → 单元设计实现 → 单元测试 → 集成与测试
- HSI 是 Part 5/6 之间合同,5 类必含信息,系统 / 硬件 / 软件三方联合签字
- 8 个软件架构特性要求显式证据,ASIL D 推荐 semi-formal notation(UML/SysML)
- Freedom from interference 三机制:时间 / 空间 / 信息交换;无 MPU 的 MCU 混合 ASIL 成本暴涨
- ASIL × 编程语言准则表是 PART 6 的灵魂,MISRA C 是 ASIL D 事实标配语言子集
- 单元测试 ASIL D 典型要求 100% statement + 100% branch + ≥ 95% MC/DC,需 LDRA / VectorCAST 等工具自动算
- 标定数据(calibration)按 Annex C 也走 Part 6 全流程,标定工程师属安全团队
Engineering Objects
引用此页的结构化 Engineeri…
引用此页的结构化 Engineering Object(v2.0 Copilot 自动生成,不要手动编辑此段)。
- standard ·
standard_iso26262_part6— ISO 26262 Part 6 Software
Cross-references
- ← 索引
- 软件 ASIL D:软件 ASIL D 实现细节
- ISO 26262-5 硬件层细化:Part 5 硬件 metrics
- ISO 26262-11 半导体细化:Part 11 IC supplier
- HV 主驱逆变器 ISO 26262 安全概念:FSC/TSC 上层
- DFA / FMEDA / FTA:分析方法
- ASPICE:软件过程能力(与 Part 6 互补)
- ASIL 分解(ASIL Decomposition):软件级 ASIL decomposition
- 汽车 MCU:MPU / 混合 ASIL 硬件支持
- Safety Case:软件安全 case 编写
- 功能安全(Functional Safety):FuSa 总框架
- IEC 61508 概览:IEC 61508-3 软件母标准