道路车辆功能安全 ISO 26262标准（6-1）—软件级产品开发
写在前面
本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识，希望能帮助更多的同学认识和了解功能安全标准。
若有相关问题，欢迎评论沟通，共同进步。(*^▽^*)
1. 道路车辆功能安全ISO 26262标准
6. ISO 26262-6 软件级产品开发
一、软件级产品开发启动
这个子阶段的目标是计划和启动软件开发的功能安全活动。软件开发的启动是计划活动，其中软件开发子阶段及其支持过程（见 ISO26262-8 和 ISO26262-9）是根据项目发展的程度和复杂性决定和计划。软件开发子阶段和支持流程是通过确定适当的方法启动，以符合有关规定和各自的 ASIL。方法是指通过指南和工具， 对于每个子阶段支持。
要求和建议
1. 应当规划确定产品开发在软件级别的活动和适当的方法。
2. 产品开发的生命周期在软件层面的制定应当按照 ISO26262-2:2011，6.4.3.4 进行，并根据图 2 中给出的参考模型。
3. 对于一个项目软件的软件开发过程，包括生命周期，方法，语言和工具，应当是与整个软件生命周期的所有子阶段一致的，并与系统和硬件开发阶段兼容，使得所需的数据可以被正确地转换。
4. 对于软件开发的每个子阶段，下面的选择，包括为他们的指南，应进行：
- 方法
- 工具
5. 选择一个合适的模型或编程语言时必须考虑的标准是：
- 一个明确的定义
- 对嵌入式实时软件和运行时错误处理的支持
- 对模块化，抽象化和结构化结构的支持
6. 为了支持设计和执行的正确性，设计和建模语言，或编程语言，应符合下表中所列的主题。
| Topic | ASIL | ||||
| A | B | C | D | ||
| 1a | Enforcement of low complexity | ++ | ++ | ++ | ++ |
| 1b | Use of language subsets | ++ | ++ | ++ | ++ |
| 1c | Enforcement of strong typing | ++ | ++ | ++ | ++ |
| 1d | Use of defensive implementation techniques | o | + | ++ | ++ |
| 1e | Use of established design principles | + | + | + | ++ |
| 1f | Use of unambiguous graphical representation | + | ++ | ++ | ++ |
| 1g | Use of style guides | + | ++ | ++ | ++ |
| 1h | Use of naming conventions | ++ | ++ | ++ | ++ |
二、软件安全需求规范拟定
这个子阶段的第一个目标是拟定软件安全需求，他们是来自技术安全概念和系统设计规范。第二个目标是细化软硬件接口要求，依据 ISO26262-4:2011，第 7 条。第三个目的是验证该软件的安全要求和硬件的软件接口要求与技术安全概念和系统设计规范一致。
要求和建议
1. 该软件的安全要求应满足每个基于软件的功能，其故障可能违反相应的软件技术安全要求。
例如，功能故障可能导致违反安全规定可以是：
- 使系统达到或保持安全状态的功能
- 相关的检测，显示和处理的安全相关的硬件元件故障的功能
- 相关的检测，通知和缓解在软件本身的故障功能
- 与车载和非车载测试相关的功能
- 软件生产和服务过程中进行修改的功能
- 有关性能或时间要求严格的操作功能
2. 软件安全要求规范应来源于技术安全概念和系统设计，符合ISO26262-4:2011，7.4.1 和 7.4.5，应考虑以下因素：
- 安全要求符合 ISO 26262-8:2011，第 6 条的规定和管理
- 指定的系统和硬件配置，配置参数可以包括增益控制，带通频率和时钟分频器
- 有关软硬件接口规范
- 硬件设计规范的有关要求
- 时序约束
- 外部接口
- 车辆、系统或硬件的运行模式对软件有影响
3. 如果 ASIL 分解到软件安全技术需求，应遵守 ISO26262-9:2011，第 5 章。
4. 在 ISO26262-4:2011，第 7 条发起的软硬件接口规范，详细说明会降至允许正确的控制和硬件的情况，并应说明硬件和软件之间的每一个与安全有关的依赖关系。
5. 如果其它的安全性的要求，除了在 6.4.1 中指定的通过嵌入式软件实施的那些功能，这些功能将被指定，否则引用他们的规范。
6. 软件安全要求的验证，硬件软件接口的规范细化，应按照 ISO26262-8:2011，第 9 条计划。
7. 细化的软硬件接口规范应由负责本系统的硬件和软件开发人员共同进行验证。
8. 软件安全要求和细化的软硬件接口要求应按照 ISO26262-8:2011 第 6 和第 9章，进行验证。
- 与技术安全要求的合规和一致性
- 符合系统设计
- 与软硬件接口一致
三、软件体系设计
这个阶段的第一个目标是设计软件体系结构以实现软件安全需求，第二个目标是校验软件体系结构。
要求和建议
1. 为了确保软件体系设计获取正确和有效地必需的信息来进行后续的开发活动，软件体系结构设计使用的符号应具有适当的抽象水平，如下表所列的软件体系结构设计说明。
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Informal notations | ++ | ++ | + | + |
| 1b | Semi-formal notations | + | ++ | ++ | ++ |
| 1c | Formal notations | + | + | + | + |
2. 在软件体系开发的过程中，应该考虑下列因素：
- 软件架构设计的可验证性
- 配置软件的适用性
- 软件单元的设计和实施的可行性
- 软件集成测试中的软件体系结构的可测试性
- 软件体系结构设计的可维护性
3. 为了避免高复杂性造成的故障，软件体系结构设计应使用下表列出的原则具有以下性质：
- 模块化
- 封装性
- 简单化
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Hierarchical structure of software components | ++ | ++ | ++ | ++ |
| 1b | Restricted size of software components | ++ | ++ | ++ | ++ |
| 1c | Restricted size of interfaces | + | + | + | + |
| 1d | High cohesion within each software component | + | ++ | ++ | ++ |
| 1e | Restricted coupling between software components | + | ++ | ++ | ++ |
| 1f | Appropriate scheduling properties | ++ | ++ | ++ | ++ |
| 1g | Restricted use of interrupts | + | + | + | ++ |
4. 软件体系结构设计应开发到所有软件单元都被识别的水平。
5. 软件体系结构设计应说明：
- 软件组件的静态设计方面
——软件结构，包括它的等级层次
——数据处理的逻辑顺序
——数据类型及其特点
——软件组件的外部接口
——软件的外部接口
——约束条件包括架构的范围和外部依赖
- 软件组件的动态设计方面
——功能和行为
——控制流和流程并发
——软件组件之间的数据流
——在外部接口的数据流
——时间限制
6. 每一个与安全相关的软件组件应被归类为以下之一：
- 新开发的
- 修改重复利用
- 无修改重复利用
7. 新开发的，或经过修改重复使用的安全相关的软件组件，应该符合 ISO26262。
8. 那些没有修改重复使用的安全相关的软件组件，则应该符合 ISO26262-8:2011，第 12 条。
9. 该软件的安全要求应分配给软件组件。因此，每个软件组件，应当制定符合任何分配给它的最高 ASIL 要求。
10. 如果嵌入式软件必须实现不同的 ASILs，或安全相关和非安全相关的软件组件，那么所有的嵌入式软件的应按照最高 ASIL，除非软件组件符合的标准与 ISO26262-9:2011，第 6 条共存。
11. 如果软件分区用于软件组件之间交流，它应确保以下几点：
- 共享资源被使用时避免软件分区干扰
- 软件分区是由专用的硬件特性或等效方法来支持
- 实现软件分区的一部分软件开发符合相同或更高的 ASIL 比分配到的软件分区的要求最高 ASIL 更高
- 在软件集成和测试过程中执行软件分区的验证
12. 按照 ISO26262-9:2011 第 7 条，相关故障的分析应进行，如果软件安全要求的实现依赖于免受干扰或软件组件之间有足够的独立性。
13. 依据 ISO26262-9:2011，第 8 条，在软件架构层面安全分析应进行，以便：
——识别或确认软件的安全相关部分
——支持规范和验证的安全机制的效率
14. 为了详细说明软件体系结构层次的安全机制，按照13条安全分析的结果，如下表中所列的错误检测机制应应用。
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Range checks of input and output data | ++ | ++ | ++ | ++ |
| 1b | Plausibility check | + | + | + | ++ |
| 1c | Detection of data errors | + | + | + | + |
| 1d | External monitoring facility | o | + | + | ++ |
| 1e | Control flow monitoring | o | + | ++ | ++ |
| 1f | Diverse software design | o | o | + | ++ |
15. 本节适用于 ASIL（A）,（B），C 和 D，在安全分析的基础上根据13条，如下表所列的错误处理机制也应适用。
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Static recovery mechanism | + | + | + | + |
| 1b | Graceful degradation | + | + | ++ | ++ |
| 1c | Independent parallel redundancy | o | o | + | ++ |
| 1d | Correcting codes for data | + | + | + | + |
16. 在安全目标下，软件体系设计未覆盖的新识别的危险，应写入危险分析和风险评估报告，按照 ISO26262-8:2011，第 8 条的变更管理要求来进行。
17. 嵌入式软件的所需的资源，其中包括：
- 执行时间
- 存储空间;例如，RAM，栈堆，ROM，非易失性数据
- 通讯资源
18. 依据 ISO 26262-8:2011，第 9 章，软件体系架构应该被校验，使用下表列出的方法，应具有以下属性：
- 遵守软件安全需求
- 兼容目标硬件
- 遵守设计指南
| Methods | ASIL | ||||
| A | B | C | D | ||
| 1a | Walk-through of the design | ++ | + | o | o |
| 1b | Inspection of the design | + | ++ | ++ | ++ |
| 1c | Simulation of dynamic parts of the design | + | + | + | ++ |
| 1d | Prototype generation | o | o | + | ++ |
| 1e | Formal verification | o | o | + | ++ |
| 1f | Control flow analysis | + | + | ++ | ++ |
| 1g | Data flow analysis | + | + | ++ | ++ |
本文章是博主花费大量的时间精力进行梳理和总结而成，希望能帮助更多的小伙伴~ 🙏🙏🙏
后续内容将持续更新，敬请期待(*^▽^*)
欢迎大家评论，点赞，收藏→→→