ISO26262是一个开发流程吗

尽管很多人认为ISO26262讲的确实是一个流程,但它并不是一个开发流程。

ISO26262假设您已经在定义好的流程中进行开发,该标准将附加的约束应用到流程中,重点关注的是系统安全。

ISO26262使用经典的“V模型”框架来管理需求。“V模型”是描述开发产品(包括开发过程中的所有文档)之间关系的标准方法。

V模型开发流程

V模型

每个开发过程都应该以某种形式包含“V模型”中要素,但可能并不完全符合ISO26262的要求。符合ISO26262通常意味着将现有的设计产品映射到ISO26262工作产品上。

软件设计产品与ISO26262工作产品的映射

ISO26262在开发流程的基础上增加了额外的约束

产生这种混淆是因为许多工程师错误地认为“V模型”描述的是一个包含工作流和活动的开发流程,事实上,有许多开发方法可以满足V模型,例如瀑布开发,敏捷开发,等等。

ISO26262附加了哪些约束

ISO26262侧重于正在开发的系统安全方面,因此ISO26262附加的约束侧重于确保系统满足其安全要求。无论哪种开发流程,ISO26262(一般)要求考虑以下几个方面:

ISO26262增加的额外约束

ISO26262增加的额外约束

Tool Aspects

Tool Aspects,指的是开发工具方面的约束,开发人员必须考虑在每个阶段使用什么工具,工具的适用性,以及如何使用它们。

Techniques

Techniques,指的是开发技术方面的约束,对于每个过程阶段(ISO26262称为子阶段),ISO26262指定了一系列推荐的开发技术(例如,代码检查)。ASIL等级越高,推荐的要做的开发技术越多,技术也从建议变为需要。

Methodologies

Methodologies,指的是开发方法的约束,虽然ISO26262规定了一套全面的技术,但它没有对如何应用这些技术提供任何指导。也就是说,ISO26262没有指定任何方法——例如,使用OO设计(面向对象设计开发方法)。然而,开发组织必须为开发的每个子阶段指定和文档化具体的开发方法/最佳实践/指南。

Artefacts

Artefacts,指的是在开发设计过程的输出产物。ISO26262称之为Work Product(工作产出),并且在每个阶段必须有哪些工作产出有一定的规定。

Safety Aspects

Safety Aspects,指的是安全方面的约束。安全方面是那些直接与系统安全相关的输入或方法。这是相对于系统内在质量而言的。

下一节