作者|booksoser
来源|汽车电子硬件设计
E.1目标
本附件解释了安全分析和相关故障分析在软件架构层面的可能应用。本附件提供的例子旨在支持对这些分析的理解,并就其应用提供指导。
E.2.概述
E.2.1分析的范围和目的
通过在软件架构层面上应用安全分析或相关故障分析,检查或确认嵌入式软件提供指定功能、行为和属性的能力,使其具有指定ASIL所要求的完整性。
嵌入式软件是否适合提供指定的功能和属性,并具有指定的ASIL所要求的完整性,由:
Ø 确定可能导致违反安全要求的因果链的设计弱点、条件、故障或故障(例如。使用归纳或演绎方法);和
Ø 分析可能的故障、故障或因果链对软件架构元素所需的功能和属性的后果。
通过分析软件架构设计中的相关故障(即相关故障),来检查相关软件架构元素之间实现的独立性或免受干扰的程度。例如:
Ø 可能导致多个需要相互独立的软件元素的故障行为的单个事件、故障或故障(例如。级联和/或公共原因故障,包括公共模式故障);和
Ø 可能从一个软件元素传播到另一个导致违反安全要求的因果链的单个事件、故障或故障(例如。级联故障)。
实现软件架构元素之间的独立或不受干扰可能是必需的,因为:
Ø 在软件级别上应用ASIL分解(见6.4.3);
Ø 例如,实施软件安全要求(见7.4.11(软件安全要求的实施)),以提供软件安全机制有效性的证据,例如被监视元素与监视器之间的独立性;或
Ø 需要软件架构元素的共存(见7.4.6、7.4.8和7.4.9和(Criteria for coexistence of elements))。
在软件架构级别上,安全分析和相关故障分析的角色支持设计规范和设计验证活动。
这种分析也可能表明,在特定的安全要求方面,不完整或不一致。
并对软件架构层面的相关故障进行了安全分析和分析的基础:
Ø 产品中有效安全机制的规范和实施;或
Ø 确定适当的开发时间安全措施,这些措施适合于防止或检测和控制在这些分析过程中发现的相关故障或故障。
图E.1说明了软件开发过程中软件架构层面的安全分析的作用,以及软件安全需求、软件架构设计和安全计划之间的基本关系或相互作用。
图E.1-说明安全软件分析在开发过程中的作用
示例图E.2说明了共享资源的相互冲突使用造成的干扰(例如。共享处理元素)。如图E.2所示,QM软件元素干扰并阻止ASIL软件元素的及时执行。这种干扰也可能发生在具有不同ASIL值的软件组件之间。该图说明了在没有和实现免受干扰机制的情况下对软件执行的影响。通过在软件中引入“检查点”并对检查点实施超时监视,可以检测到定时干扰,并启动适当的反应。
Ø 执行软件组件
Ø 阻塞软件组件
Ø 干扰
Ø “通过”程序流监测检查点
Ø “失败”程序流监测检查点
图E.2-导致级联故障的定时干扰示例
安全分析和相关故障分析将应用于软件架构层面。代码级安全分析(例如。关于运行时错误,如除以零,超出数组索引边界的访问),由于以下原因,既不需要也不被认为是必要的:
Ø 关于这些类型的故障的剩余风险可以被认为是足够低的,只要本文件中描述的软件开发方法,包括选择和应用适当的方法、方法和开发原则,如建模和编程准则、设计和实现规则、模型和/或代码评审、语义或静态分析、单元和集成测试得到仔细应用;和
Ø 在实现各自的架构元素时,这些类型的故障通常会导致元素在其界面上的相同故障行为,就像在架构级别上分析的那样。因此,更高一级的分析已经提供了证据,证明所选择的技术安全机制是有效的,或者开发时间安全措施足以确保充分的论证。
系统、硬件和软件层面的安全分析和相关故障分析之间的
E.2.2安全分析与系统、硬件和软件层面的相关故障分析之间的关系
在开发生命周期的多个阶段应用安全分析和相关失效分析。这些分析可以相互关联。
在系统一级启动的关注分离方法中,通常由硬件开发负责确保处理单元在硬件故障方面有足够低的剩余风险。因此,在不考虑硬件故障的情况下,可以在软件架构层面进行软件安全分析和软件相关故障分析。
然而,在某些硬件条件下(例如。对处理元件的随机硬件故障(包括瞬态故障)的诊断覆盖率不足,可以考虑硬件故障的负面影响。在这种情况下,对具体的硬件/软件交互进行了具体的分析,例如:
Ø 特定的软件映射到多核系统的不同处理单元;
Ø 关于软件架构设计的静态或动态方面执行软件的处理元素的详细设计;或
Ø 选定的软件安全机制对软件的可实现诊断覆盖
Ø 相关的硬件故障。
注:分析特定的硬件/软件交互可以支持故障注入技术。
E.2.3分布式软件开发中的安全分析(包括软件元素的SEooC开发)
嵌入式软件及其软件元素通常是由多个组织(包括OEM、一级、二级、硅供应商或软件供应商)开发的分布式开发,甚至超出上下文(例如。基本软件,硬件相关软件,COTS软件或操作系统开发为SEooC)。
分布式软件开发中有意义的安全分析的重要方面是:
Ø 关于分析范围的定义和协议,以及单独或共同进行分析所使用的程序或方法(包括交换信息/文件或确认假设);
Ø 关于参与组织软件安全分析过程和共同规则的总体责任的定义和协议(例如。高级组件,它们之间的访问规则);
Ø 在使用模块化方法进行分析时,对接口的定义和一致(例如。在不同范围、所使用的方法或交换的信息/文档之间的接口上商定的软件故障模型);
Ø 以及关于分析验证的定义和协议。
已完成
数据加载中