Functional Safety

本专栏共有10 篇文章

ISO26262标准之软件安全需求测试

软件安全需求测试阶段重点是验证软件满足其安全要求。 软件测试在很大程度上可以在模拟环境中进行。但这样的测试并不能保证软件已经能够完全满足需求。 为提高软件正确率,ISO26262标准为测试环境提出了额外的要求: 软件安全验证测试环境 Technique A B C D Hardware-in-the-loop + + ++ ++ Electronic control unit network enviroments ++ ++ ++ ++ Vehicles ++ ++ ++ ++

ISO26262标准之软件集成和测试

这个子阶段关注的是如何通过架构设计中的组件(component)集成到一起构建成一个完整的软件,并确保系统按预期结果运行。 一般来说,软件集成是通过持续迭代来完成的。这个阶段是与硬件和系统团队一起制定计划,不断推进实现的。 与前面一样,ISO26262没有提供关于软件集成方法的指导,也没有任何特定的策略。但是标准定义了应该执行哪种类型的集成测试的技术。 集成测试方法 Technique A B C D Requirement-base test ++ ++ ++ ++ Interface test ++ ++ ++ ++ Fault injection test + + ++ ++ Resource usage test + + + ++ Back-to-back comparison tests between code

ISO26262标准之软件单元测试

软件单元测试关注的是软件单元模块是否满足需求规范(不一定都是系统需求)。 在这里的测试,是指动态测试——即在模拟环境中执行软件进行测试。 ISO26262规定了下列动态测试类型 软件动态测试方法 Technique A B C D Requirement-base test ++ ++ ++ ++ Interface test ++ ++ ++ ++ Fault injection test + + + ++ Resource usage test + + + ++ Back-to-back comparison tests between code and model(if applicable) + + ++ ++ 测试用例设计的方法 测试用例的设计是指定使用以下方法

ISO26262标准之软件单元设计与实现

软件单元设计与实现 软件单元设计关注的是代码层级的设计,实现和验证。在设计软件单元时,ISO26262推荐以下技术: 软件单元设计表述方法 Technique A B C D Natural language ++ ++ ++ ++ Information notations ++ ++ ++ + Semi-formal notations + ++ ++ ++ Formal notations + + + + 以上提到Semi-formal notation,即半正式的表示法,通常情况下半正式表示法比自然语言要好,至少需要用MS Office画的流程图,但是这种方式配置管理和版本管理很难搞,最好还是使用标准的UML工具。 与架构设计一样,ISO26262给出了必须遵守的设计准则,这些准则在MISRA-C中大多数都能够覆盖到。 软件单元设计的准则和实现 Technique A

ISO26262标准之软件架构设计和验证

下面是ASIL A ~ ASIL D 各个ASIL级别在软件需求和架构设计开发阶段,ISO26262要求在开发过程中需要应用的技术。如果一项技术被列为"Highly Recommended"(强烈推荐)的,那就必须应用它。"Recommended"(推荐)的技术最好要被采用。"No Recommended"不推荐的技术作为可选项,可以省略。 需要记住的是,ISO26262标准不包含实现所需ASIL等级的任何方法。在指定了技术的地方,标准并没有提供任何关于该技术必须在何时、何地如何应用的指导。 软件安全需求规范 这个子阶段的重点是确保所采取的方法能够保证软件安全,与系统安全概念相一致。

ISO26262标准之软件编码和建模规范

下面是ASIL A ~ ASIL D 各个ASIL级别在开发启动阶段,ISO26262要求在开发过程中需要应用的技术。如果一项技术被列为"Highly Recommended"(强烈推荐)的,那就必须应用它。"Recommended"(推荐)的技术最好要被采用。"No Recommended"不推荐的技术作为可选项,可以省略。 需要记住的是,ISO26262标准不包含实现所需ASIL等级的任何方法。在指定了技术的地方,标准并没有提供任何关于该技术必须在何时、何地如何应用的指导。 软件开发启动阶段 这个子阶段的重点是软件开发活动的规划,特别强调确保适当的工具、

ASIL等级对开发有什么影响

ASIL等级对开发技术的影响 ASIL等级用于配置ISO26262的需求,一般来说,ASIL等级越高,开发要求越严格。 为了符合ISO26262的要求,负责开发的团队必须执行所有的活动,并输出标准规定的所有工作产出(即设计文档、软件、硬件等)。区别在于每个阶段必须完成的工作量(根据严格程度而定)。 ASIL等级用于在每个开发阶段选择哪些开发技术,这些开发是标准指定的。根据是否要求实现,分为以下三种: Highly Recommended(++) Highly Recommended,即强烈推荐使用的技术,使用两个加号"++"作为标识,为了达到对应的ASIL等级,这些技术是必须的要使用的。如果没有使用强烈推荐的技术,必须有一个非常令人信服的理由来解释为什么要省略它 Recommended(+) Recommended,即推荐使用的技术,

ISO26262是一个开发流程吗

尽管很多人认为ISO26262讲的确实是一个流程,但它并不是一个开发流程。 ISO26262假设您已经在定义好的流程中进行开发,该标准将附加的约束应用到流程中,重点关注的是系统安全。 ISO26262使用经典的“V模型”框架来管理需求。“V模型”是描述开发产品(包括开发过程中的所有文档)之间关系的标准方法。 V模型 每个开发过程都应该以某种形式包含“V模型”中要素,但可能并不完全符合ISO26262的要求。符合ISO26262通常意味着将现有的设计产品映射到ISO26262工作产品上。 ISO26262在开发流程的基础上增加了额外的约束 产生这种混淆是因为许多工程师错误地认为“V模型”描述的是一个包含工作流和活动的开发流程,事实上,有许多开发方法可以满足V模型,例如瀑布开发,敏捷开发,等等。 ISO26262附加了哪些约束 ISO26262侧重于正在开发的系统安全方面,因此ISO26262附加的约束侧重于确保系统满足其安全要求。无论哪种开发流程,ISO26262(一般)