写在前面
本系列文章主要讲解道路车辆功能安全ISO26262标准的相关知识,希望能帮助更多的同学认识和了解功能安全标准。
若有相关问题,欢迎评论沟通,共同进步。(*^▽^*)
1. 道路车辆功能安全ISO 26262标准
6. ISO 26262-6 软件级产品开发
四、软件单元设计和实现
这个子阶段的第一个目标是规定软件单元按照软件体系设计及相关的软件安全要求。第二个目的是实现所指定的软件单元。第三个目标是静态验证软件单元设计和实现。
根据软件体系结构设计,开发软件单元的详细设计,详细设计将被实现为一个模型或直接为源代码,根据建模或编码准则。在进行软件单元测试阶段之前,详细设计和开发是静态验证。如果代码是手工开发,在源代码级别实施相关的属性是可以实现。如果基于模型的开发与自动代码生成时,这些属性应用到模型,无需应用到源代码。
为了开发一个软件单元设计,实现软件的安全要求,以及所有非安全的要求。因此,在安全相关和非安全相关的要求都在这个子阶段的过程中处理。
软件单元的实现包括源代码的生成和编译成目标代码。
要求和建议
1. 本阶段应符合软件单元安全相关的要求。
2. 为确保该软件单元设计允许后续的开发活动获取正确和有效地进行所必需的信息,该软件单元的设计应采用下表 所列的符号说明。
Methods | ASIL | ||||
A | B | C | D | ||
1a | Natural language | ++ | ++ | ++ | ++ |
1b | Informal notations | ++ | ++ | + | + |
1c | Semi-formal notations | + | ++ | ++ | ++ |
1d | Formal notations | + | + | + | + |
在基于模型的开发与自动生成代码的情况下,该方法为代表的软件单元设计作为基础的代码生成的模型。
3. 软件单元的规范应描述功能行为和内部设计,以达到必要的细节实施水平。例如,内部的设计可以包括使用寄存器和数据存储的限制。
4. 软件单元源代码级的设计与实现应采用如下表所列的的设计原理,达到以下属性:
- 软件单元的子程序和函数的正确执行顺序基于软件架构设计
- 软件单元之间的接口的一致性
- 软件单元内部的数据流和控制流的正确性
- 简约化
- 可读性和可理解性
- 鲁棒性
- 软件修改的适用性
- 可测试性
Methods | ASIL | ||||
A | B | C | D | ||
1a | One entry and one exit point in subprograms and functions | ++ | ++ | ++ | ++ |
1b | No dynamic objects or variables, or else online test during their creation | + | ++ | ++ | ++ |
1c | Initialization of variables | ++ | ++ | ++ | ++ |
1d | No multiple use of variable names | + | ++ | ++ | ++ |
1e | Avoid global variables or else justify their usage | + | + | ++ | ++ |
1f | Limited use of pointers | o | + | + | ++ |
1g | No implicit type conversions | + | ++ | ++ | ++ |
1h | No hidden data flow or control flow | + | ++ | ++ | ++ |
1i | No unconditional jumps | ++ | ++ | ++ | ++ |
1j | No recursions | + | + | ++ | ++ |
5. 软件单元的设计与实施应按照 ISO26262-8:2011 第 9 条进行验证,并通过使用下表列出的验证方法来证明:
- 遵守软硬件接口规范(根据 ISO26262-5:2011,6.4.10)
- 软件安全要求分配给软件单元的实施的可追溯性
- 源代码和设计规范的一致性
- 源代码与编码指南一致性
- 软件单元实现与目标硬件的兼容性
Methods | ASIL | ||||
A | B | C | D | ||
1a | Walk-through | ++ | + | o | o |
1b | Inspection | + | ++ | ++ | ++ |
1c | Semi-formal verification | + | + | ++ | ++ |
1d | Formal verification | o | o | + | + |
1e | Control flow analysis | + | + | ++ | ++ |
1f | Data flow analysis | + | + | ++ | ++ |
1g | Static code analysis | + | ++ | ++ | ++ |
1h | Semantic code analysis | + | + | + | + |
五、软件单元测试
这个子阶段的目标是证明软件单元实现软件单元的设计规范和不含有不需要的功能。依据软件设计规范建立软件单元设计的测试流程,并依照流程来执行。
1. 该条款要求应符合如果软件单元是与安全相关的。
2. 软件单元测试必须按照 ISO26262-8:2011 第 9 条计划,规定和执行。
3. 在下表中列出的软件单元测试方法应适用于验证软件单元的实现:
- 遵守软件单元设计规范
- 遵守软硬件接口规范
- 指定的功能
- 不存在非计划的功能
- 鲁棒性
- 足够的资源支持功能
Methods | ASIL | ||||
A | B | C | D | ||
1a | Requirements-based test | ++ | ++ | ++ | ++ |
1b | Interface test | ++ | ++ | ++ | ++ |
1c | Fault injection test | + | + | + | ++ |
1d | Resource usage test | + | + | + | ++ |
1e | Back-to-back comparison test between model and code, if applicable | + | + | ++ | ++ |
4. 为了使适当的测试用例按照第3条软件单元测试规范,测试用例应采用下表中列出的方法得出。
Methods | ASIL | ||||
A | B | C | D | ||
1a | Analysis of requirements | ++ | ++ | ++ | ++ |
1b | Generation and analysis of equivalence classes | + | ++ | ++ | ++ |
1c | Analysis of boundary values | + | ++ | ++ | ++ |
1d | Error guessing | + | + | + | + |
5. 为了评估测试用例的完整性,并证明没有额外功能,在软件单元级别要求的覆盖范围应确定,结构范围应按照下表中列出的指标进行测定。如果实现的结构范围被视为是不够的,那么额外的测试用例应指定或提供理由。
Methods | ASIL | ||||
A | B | C | D | ||
1a | Statement coverage | ++ | ++ | + | + |
1b | Branch coverage | + | ++ | ++ | ++ |
1c | MC/DC(Modified Condition/Decision Coverage) | + | + | + | ++ |
6. 软件单元测试的测试环境应尽可能与目标环境密切对应。如果软件单元测试不在目标环境中进行,源代码和目标代码中的差异,以及测试环境和目标环境之间的差异,应在指定目标环境中额外的随后的测试阶段加以分析。
- 在测试环境和目标环境之间的差异可以发生在源代码或目标代码,例如,由于不同的位宽度的数据字与该处理器的地址字。
- 根据测试的范围内,应使用适当的软件执行单元的测试环境(如目标处理器,处理器仿真器或开发系统)。
- 软件单元测试可在不同的环境中被执行,例如:
——模型在环测试
——软件在环测试
——处理器在环测试
——硬件在环测试
- 对于基于模型的开发,软件单元测试,可以在模型级进行,在模型和对象代码之间的背对背比较测试之后。背对背的对比测试用于确保该模型的行为对于测试目标等同于自动生成的代码。
本文章是博主花费大量的时间精力进行梳理和总结而成,希望能帮助更多的小伙伴~ 🙏🙏🙏
后续内容将持续更新,敬请期待(*^▽^*)
欢迎大家评论,点赞,收藏→→→