避免重新发明轮子是高效产品开发的关键部分。在嵌入式编程中,这个概念始于可信库,并已通过面向对象编程和Java等概念得到增强,这使我们能够创建当今的复杂系统。
安全标准还促进了经过验证的软件元素的重用,尽管这带来了复杂的挑战。在项目中引入没有同样严格程度的元素将不可避免地导致弱点。因此,安全标准规定了验证这些组件以用于安全项目的方法。
但是,对效率的追求可能会导致在安全关键系统中不起作用的概念。定制现货 (COTS) 软件是许多行业以多种方式使用的术语,尽管它在工业安全中具有非常具体的含义,但它可能成为走捷径的借口,这在安全项目中是不可接受的。一个系统的强度取决于它最薄弱的地方。医疗标准IEC 62304中使用了未知血统/出处(SOUP)的软件,但是有充分的理由在安全项目中没有“未知”的东西。你可以测试它到死,但最终,当它的起源未知时,你如何在未来几年内维护它?
断章取义地定义安全元素
在汽车领域,ISO 26262-10中定义的安全元件脱离环境(SEooC)是在车辆中使用最初不是为该特定项目设计的组件的方法。
术语SEooC有点笨拙,但它清楚地定义了问题。您集成到系统中的所有软件库都是“脱离上下文”有效地开发的:它们旨在提供特定的功能,而不了解它将如何在目标系统中使用。“元素”表示这是一个具有特定功能范围的单元或模块;“安全”表示该模块是在一组安全要求的背景下专门开发的。
有两种基本类型的软件 SEooC(源自 ISO 26262-10-9):
经验证的使用方法。这种类型的软件使用“已使用中证明”参数(和其他措施)来验证 COTS 组件是否符合指定的安全级别。ISO 26262-8-14规定了如何实现这一目标,但在软件环境中有很多争论。可观察错误的概念是关键 - 记录产品的使用情况,以便可靠地记录和汇总所有错误,从而准确了解软件的可靠性。这需要考虑在特定配置中。这些结果与目标项目的相关性是复杂的,因为安全项目几乎可以肯定在用于建立软件可靠性的现场测试用例中具有不同的配置和工作环境。您能相信一款未按照安全标准开发的软件能够可靠地报告所有错误吗?
ISO 26262-6方法。在汽车安全系统中开发软件元件的标准方法在ISO 26262标准的第6节中定义,用于开发道路车辆的功能安全。它源自标准前面部分中定义的目标系统的完整 V 模型开发,并且本身就是一个 V 模型。由于该要素是在上下文之外开发的(即,不是从目标项目的安全计划中得出的),因此必须采取其他措施。主要的附加措施是创建一组假设,SEooC 旨在在其中工作。在集成期间,必须在目标平台上验证这些假设。
完整的软件生命周期维护
这是任何安全项目开发的关键部分:响应开发期间或发布后提出的问题的能力。一旦项目成熟,就需要有一种方法在提出问题时可靠地修改项目。ISO 26262-6方法的一个关键优势是可以进行全面而准确的影响分析,并正确实施由此产生的更改,因为所有标准工件都是在设计,实施和测试之间具有可追溯性的。
在时间和人员方面,您离项目发布越远,就越需要提供工件及其相关流程,以便安全地进行更改。此方法可确保将来的可维护性。
跨行业重用
在多个行业中使用许多嵌入式组件具有实际意义。例如,用于存储数据的文件系统或用于通信数据的网络堆栈不是特定于行业的,理想情况下,从一个新项目中获得的好处应该在新项目中利用,而不管它们适用于哪个行业。从软件的角度来看,跨不同行业开发软件的安全要求大致相似,但根据所需的安全级别具有不同程度的严格性。采用根据 ISO 26262-6 开发的 SEooC 方法为跨标准映射伪影提供了坚实的基础(例如,符合工业功能安全的 IEC 61508 或医疗设备的 IEC 62304)。
为 SEooC 定义 ASIL 级别
在所有安全标准中,都规定了安全级别。目标系统中故障的影响越严重,用于实施和验证软件的定义措施就越严格。
为 SEooC 选择汽车安全完整性等级 (ASIL) 可能会有问题。简单的答案是始终开发到最高ASIL级别(ASIL D),以便无需重大返工即可与任何项目集成,并且跨行业标准的映射也更容易。缺点是,它使这些 SEooC 比开发到较低 ASIL 的 SEooC 贵得多。
如何获取 SEooC
SEooC可以提供嵌入式组件作为安全系统的核心部分,并降低成本。然而,设计嵌入式组件以便在安全环境中重复使用不可避免地很复杂,因此采购这些组件必须经过深思熟虑。为了获得最佳结果,它们需要在能够处理安全产品生命周期需求的环境中进行开发。
最佳实践是开发完整的ISO 26262第6节安全元件,其中包含准备重复使用的假设和测试用例。这需要由项目管理系统支持,该系统允许每个客户使用在半独立项目中维护的 SEooC,以便整个软件维护生命周期可以独立应用于该项目。
审核编辑:郭婷
全部0条评论
快来发表一下你的评论吧 !