安全软件秘诀——根据ISO / DIS 26262开发ECU基础软件

原文链接：Recipe for Safe Software

安全软件秘诀

根据ISO / DIS 26262开发ECU基础软件

随着新的ISO 26262标准的引入，安全相关功能的要求变得比以前更加具有挑战性。同时，它们也被定义得更加精确和清晰了。经过正式验证的系统和对现有解决方案的重用，在这里不再互相矛盾。硬件和软件中的通用安全模块可以提供经过验证的组件。

ISO 26262目前是投票阶段的标准草案，但预计在2011年将会成为具有约束力的安全标准。它以可应用的方式定义了电气/电子（E/E：Electric/Electronic）系统的功能安全性。这个未来的标准是基于在各种行业中使用的IEC 61508标准，并且还定位在汽车领域的安全相关和非安全相关的功能常常是相互关联，因而并不能总是明确的彼此隔离的情况。ISO 26262的目标是更好地理解与安全相关的功能，并尽可能地缩小其解释范围。

工程开发上面临的一个挑战是需要事先评估所有潜在的危害和风险，并采取适当的措施来降低这些风险。为了达成这一点，ISO规定在开发之初，必须进行“危害和风险分析”。在被考虑的系统内，分析所有的操作状态及与其相关的故障类型，并识别各种潜在的危险情况。之后，每个危害都要被分配一个从A到D的安全要求等级（ASIL：Automotive Safety Integrity Level 汽车安全完整性等级），其中A是最低的，D是最高的安全等级。

随着ASIL等级的提高，对系统的硬件指标（FIT率、测试覆盖率等），以及软件的开发过程（测试深度、需求跟踪、文档评审等）的要求也在提高。系统供应商在现有的高质量要求之上，还必须满足这些更高的要求。

通过标准化和重用来掌握上升的复杂性

近年来，各种车载功能不仅是在数量和复杂性上越来越高；经常还会分布在整个车辆中。这种趋势，一方面源于所使用的处理器的计算能力的显著提高，另一方面是网络中更大的可用带宽。

同时，要实现的功能已经如此复杂，传统的开发方法已经不能满足这种架构的要求。这种局面促使OEM厂商们，在2003年联合到了AUTOSAR开发伙伴关系中。他们的共同目标是为ECU定义统一的软件架构，并将硬件与软件解耦。

在定义AUTOSAR之前，通信协议栈和诊断程序是汽车原始设备制造商（OEM：Original Equipment Manufacturer）的主要关注焦点。伴随着AUTOSAR，基础软件已经经历了显著的扩张。除了早先涵盖的CAN、LIN、FlexRay和诊断等领域，现在基础软件还包括操作系统、看门狗、存储协议栈和微控制器的驱动程序层。

在2009年底发布4.0版本时，AUTOSAR基础软件达到了非常高的复杂程度。超过80个软件模块被通过系统描述文件（AUTOSAR系统配置描述）定义；它们被通过强大的工具进行配置，并自动生成它们的代码。

用于安全相关ECU的AUTOSAR基础软件的需求

除了功能上的要求外，还有一个关键要求：基础软件不得“干扰”安全相关软件。这个意思是双重的：一方面，基础软件一定不能干扰安全软件的内存；另一方面，基础软件不得请求比原来想要的更多的执行时间。总之，这些条件也被称为“免于干涉”。

看似显然的方法是基于ISO 26262归类的安全相关软件的标准，开发整个基础软件。但是，正如已经提到的那样，AUTOSAR基础软件非常复杂，功能范围很大，其规格要经过短暂的修订周期。这使得基于ISO 26262的开发将会非常昂贵。

另一种方法是实现一个保护层（软件分区），将安全相关软件与基础软件可靠地分开而不受干扰。AUTOSAR已经包含了以下功能：存储器保护和程序流程监控。这个功能使得针对根据QM过程的开发的基础软件和根据ISO 26262所需的ASIL要求开发的保护层，来执行ASIL的分解（参见下一节）成为可能。因此，只需要根据ISO 26262开发内存保护和运行时行为（带有看门狗的程序流程监控）的模块就足够了。

根据ISO 26262使用ASIL分解

如前所述，ISO 26262不一定要求重新开发所有的软件机制。为了达到一个确定的ASIL，对应达成某个定义的必要的安全目标，可以使用独立的元素的组合和将安全要求合适地划分为冗余的安全要求。例如，将ASIL B等级和ASIL A等级的两个组件组合在一起达到ASIL C等级，同时满足特定要求（图1）是可能的。

ASIL分解可以在系统、硬件和软件层面上执行。在执行分解时，应注意确保硬件架构指标不受影响，并且不存在违反安全目标的可能性。此外，ISO 26262要求基于原始ASIL等级（在我们的示例中，为ASIL C）的安全目标进行强制性确认评审。

图1：ASIL分解：在基本软件中添加一个安全层，以达到ASIL D

为了保证ECU中不同ASIL等级的软件组件的必要独立性，该标准定义了维护和验证“免于干扰”的规则。这些规则必须保持和验证。这是因为在安全相关和非安全相关要素的特殊情况下，元素的“共存（coexistence）”需要适当的测量和验证。

在开发过程中，没有任何具体用例（“事项”）的通用组件（子系统、硬件组件、软件组件），也因此没有为他们定义安全目标，可以根据ISO 26262开发为所谓的“上下文无关的安全要素”（SEooC：Safety Elements out of Context）。

在这种情况下，由于要满足的适用的“安全要求”是未知的，在元素的帮助下可以知道，因此必须做出“假设”并相应地形成文件（图2）。

图2：在开发所谓的“上下文无关的安全要素”（SEooC）之前，必须做出假设并记录

首次使用SEooC时，必须检查附带的安全手册，以确定所做的假设是否符合用例中定义的安全目标和安全要求，以及它的一致性是否得到了支持，并且没有产生矛盾。然后必须保证和验证，是在正确按安全手册的来使用。

验证层的通用实现

TTTech Automotive在其“SafeExecution”产品中开发了一个通用监控层，符合“共存”的应用要求，“免于干扰”，并有助于有效重用现有组件来降低成本。通过集成内存保护和程序流程监控模块，可以可靠地检测QM开发部分（基础或应用软件）中的潜在错误，并可以启动适当的错误处理（图3）。

图3：必须根据安全手册将SafeExecution模块集成到现有系统中，以满足ISO 26262的要求

用户必须根据其安全手册集成SafeExecution模块，以实现满足ISO / DIS 26262要求的系统。

除了经过验证的端到端（E2E：End-to-End）通信解决方案“SafeCOM”， SafeExecution是TTTech的第二个用于开发与安全相关ECU的模块。

MICROSAR作为一个整体安全解决方案

为了从单一来源获得经过验证的基础软件，Vector和TTTech将通用软件模块SafeCOM和SafeExecution集成到了MICROSAR——来自Vector的经过实践验证的AUTOSAR解决方案（图4）。

图4：通过添加软件模块SafeCom和SafeExecution，Vector的MICROSAR基础软件成为AUTOSAR基础软件的受保护解决方案

重用经过认证的中央软件组件，降低了应用程序集成的成本。TTTech和Vector共同提供了一个通用的标准解决方案，可以最大限度地降低符合ISO 26262标准的安全相关ECU的开发成本。

本文是对在德国发行的“Elektronik automotive, 11/2010”里面刊登的文章内容的英文翻译。

图像提供方：Vector Informatik and TTTech Automotive

作者：

Joachim Kalmbach（工商管理硕士（FH））
在罗伊特林根应用科技大学学习计算机科学与自动化。2006年，他加入了斯图加特的Vector Informatik公司，目前担任嵌入式软件领域的产品经理。他的工作重点是AUTOSAR和功能安全。

Thomas Wenzel博士
自2006年以来，他一直在汽车技术与流动研究所工作，自2010年3月起一直从事功能安全领域的管理工作。在担任该职位之前，他在考文垂大学获得控制工程博士学位。



Martin Fassl

工程物理（维也纳技术大学）研究生工程师；自1997年以来，他一直从事电信，航空航天和汽车领域的硬件和软件开发工作。自2008年以来，他一直在TTTech Automotive GmbH担任开发工具和标准软件的产品经理。