Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
ISO 26262-6:2018 — 汽车嵌入式系统软件级功能安全
软件安全需求、架构设计、单元实现与验证方法全面解析
ISO 26262-6:2018 软件开发概述
ISO 26262-6:2018定义了汽车功能安全生命周期中软件级产品开发的要求。现代车辆包含超过1亿行代码，分布在100多个电子控制单元（ECU）上，软件已成为车辆功能和安全风险的主要贡献者。本标准为开发满足每个ASIL级别严格要求的安全相关软件提供了全面的框架。
该标准遵循软件开发的V模型方法，涵盖从安全需求规格说明、架构设计、单元设计与实现、单元验证、软件集成与验证，直至最终嵌入式软件测试的完整软件生命周期。
ISO 26262-6中最重要的概念之一是不同ASIL软件元素之间的无干扰（FFI）。如果ASIL D和QM（质量管理）软件元素运行在同一ECU上，您必须证明QM软件不能在时序、内存或信息交换方面干扰ASIL D软件。
软件安全需求与架构设计
第6章涉及软件安全需求的规格说明，这些需求源自技术安全概念和硬件-软件接口规格说明。这些需求必须：
- 无歧义——每个需求只有一种解释
- 可验证——必须能够通过评审、分析或测试确认需求得到满足
- 分配ASIL——每个需求携带其ASIL分类
- 可追溯——双向追溯至技术安全概念中的源需求
第7章规定了软件架构设计要求，定义了软件的静态和动态方面。架构必须处理：
- 软件组件及其接口的层次结构
- 组件之间的数据流和控制流
- 资源分配（CPU时间、内存、通信带宽）
- 错误检测和错误处理机制
- 不同ASIL软件元素之间的无干扰
标准根据ASIL要求使用特定的设计表示法。对于ASIL C和D，强烈建议使用半形式化或形式化表示法（例如Simulink/Stateflow、带形式化约束的UML或AADL），如下表所示：
| 设计方法 | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| 自然语言配合非正式图表 | ++ | + | o | o |
| 半形式化表示法（如Simulink、UML） | + | ++ | ++ | ++ |
| 形式化表示法（如VDM、SCADE） | o | o | + | + |
安全关键软件中一个常见的架构错误是过度耦合的组件。当一个组件的变更迫使许多其他组件也进行变更时，安全分析变得极其困难。使用定义良好的接口和数据封装来最小化耦合。
软件单元设计、实现与验证
第8章涵盖软件单元设计与实现，其中架构组件被分解为单个软件单元（函数、模块或类）。关键要求包括：
- 使用适当的建模、设计和编程语言，并配备风格指南
- 遵守MISRA C/C++等编码标准（标准表中明确引用）
- 实现防御性编程技术（范围检查、合理性检查）
- 遵守软件单元设计原则（低复杂度、高内聚、低耦合）
第9章规定软件单元验证方法。标准提供了一个详细的方法表及其ASIL相关推荐：
| 验证方法 | ASIL A | ASIL B | ASIL C | ASIL D |
|---|---|---|---|---|
| 语句覆盖 | ++ | ++ | ++ | ++ |
| 分支覆盖 | + | ++ | ++ | ++ |
| MC/DC（修改条件/判定覆盖） | o | o | + | ++ |
| 基于需求的测试 | ++ | ++ | ++ | ++ |
| 背对背测试（模型与代码） | + | + | ++ | ++ |
对于ASIL D项目，在开发周期早期实施MC/DC覆盖分析。对现有代码回溯添加MC/DC覆盖极其困难，通常需要重大重新设计条件逻辑。
软件集成、验证与嵌入式软件测试
第10章涉及软件集成与验证，其中单个软件单元被集成到更大的软件组件中，然后集成到完整的软件中。集成测试必须验证集成软件的功能行为、资源消耗和时序行为。测试环境可以从SIL（软件在环）仿真到HIL（硬件在环）测试。
第11章规定嵌入式软件测试——系统集成前的最终软件验证步骤。嵌入式软件测试必须在目标硬件（或代表性硬件环境）上执行，并且必须验证：
- 嵌入式软件的功能正确性
- 最坏情况下的时序行为
- 对硬件故障的鲁棒性（与ISO 26262-5故障注入测试协调）
- 与通信网络（CAN、LIN、FlexRay、以太网）的正确交互
切勿仅依赖仿真进行ASIL C或D的软件测试。目标硬件引入的时序效应、内存约束和外设行为无法在仿真中完全建模。始终在目标ECU或等效硬件平台上执行嵌入式软件测试。
常见问题解答
问：软件单元验证（第9章）和软件集成验证（第10章）有何区别？
答：单元验证在隔离环境中测试单个软件单元（函数、模块），通常在开发主机上使用桩和驱动。集成验证测试单元之间的交互及其正确组装到软件组件和完整软件中，包括跨单元边界的数据流、控制流和时序。
答：单元验证在隔离环境中测试单个软件单元（函数、模块），通常在开发主机上使用桩和驱动。集成验证测试单元之间的交互及其正确组装到软件组件和完整软件中，包括跨单元边界的数据流、控制流和时序。
问：ISO 26262-6是否要求使用MISRA C？
答：标准并未明确强制要求MISRA C，但要求使用编码指南。标准中的参考表格将MISRA C列为成熟的编码标准。实践中，大多数汽车安全项目使用MISRA C（或C++项目的MISRA C++）作为编码指南，因为它是业界最广泛认可和接受的标准。
答：标准并未明确强制要求MISRA C，但要求使用编码指南。标准中的参考表格将MISRA C列为成熟的编码标准。实践中，大多数汽车安全项目使用MISRA C（或C++项目的MISRA C++）作为编码指南，因为它是业界最广泛认可和接受的标准。
问：基于模型的开发（MBD）是否有助于符合ISO 26262-6？
答：是的。使用Simulink/Stateflow、SCADE或ASCET等工具进行基于模型的开发可以显著简化ISO 26262-6的符合性工作。模型作为可执行规格说明，可早期验证，自动生成具有可追溯性的生产代码，并支持模型与代码之间的背对背测试。但是，建模工具本身必须按照ISO 26262-8第11章（工具鉴定）进行鉴定。
答：是的。使用Simulink/Stateflow、SCADE或ASCET等工具进行基于模型的开发可以显著简化ISO 26262-6的符合性工作。模型作为可执行规格说明，可早期验证，自动生成具有可追溯性的生产代码，并支持模型与代码之间的背对背测试。但是，建模工具本身必须按照ISO 26262-8第11章（工具鉴定）进行鉴定。
问：什么是无干扰（FFI），如何证明它？
答：FFI意味着具有较低ASIL（或QM）的软件元素不能导致较高ASIL的软件元素违背其安全要求。FFI必须在三个维度上证明：时序（低ASIL元素不能剥夺高ASIL元素的CPU时间）、内存（低ASIL元素不能破坏高ASIL元素的内存）和信息交换（低ASIL元素不能向高ASIL元素传递无效数据）。这通常通过内存分区（MPU/MMU）、时间触发调度和接口验证来实现。
答：FFI意味着具有较低ASIL（或QM）的软件元素不能导致较高ASIL的软件元素违背其安全要求。FFI必须在三个维度上证明：时序（低ASIL元素不能剥夺高ASIL元素的CPU时间）、内存（低ASIL元素不能破坏高ASIL元素的内存）和信息交换（低ASIL元素不能向高ASIL元素传递无效数据）。这通常通过内存分区（MPU/MMU）、时间触发调度和接口验证来实现。
