ISO 26262标准是基于在各种行业中使用的IEC 61508标准，其目标是更好地理解与安全相关的功能，并尽可能地缩小其解释范围。

提前评估所有潜在的危害和风险，这是工程开发上面临的一大挑战，我们还需要采取适当的措施来降低这些风险。为了达成这个目标，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基础软件达到了非常高的复杂程度。通过系统描述文件（AUTOSAR系统配置描述），超过80个软件模块被定义，并通过强大的工具将软件模块进行配置，随之自动生成它们的代码。

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

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

根据ISO 26262归类的安全相关软件标准，去开发整个基础软件，这显然是个不错的方法。但是，正如前文所述，AUTOSAR基础软件非常复杂，功能范围很大，其规格要经过短暂的修订周期。这使得基于ISO 26262的开发将会非常昂贵，欢迎参加牛喀网9月21-21日在上海举办的软件功能安全技术培训，课程将会介绍AUTOSAR架构下的功能安全是实现方法，详情关注牛喀网，点击高级课程菜单了解。

另一种方法是实现一个保护层（软件分区），将安全相关软件与基础软件分开，互不干扰。

AUTOSAR已包含存储器保护和程序流程监控的功能。此功能使得可以根据QM和基于ISO 26262的所需ASIL的保护层执行基本软件的ASIL分解（参见下一节）。因此，只需要根据ISO 26262开发内存保护和运行时行为（带有看门狗的程序流程监控）的模块就足够了。

根据ISO 26262使用ASIL分解

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

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

图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）通信验证解决方案"SafeCOM"外，安全执行是 TTTech 中用于开发安全相关 ECU 的第二个模块。

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

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

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

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

总结

随着汽车行业往电气化、智能化方向发展，电子电气系统设计的安全性越显重要。高安全性的产品能够帮助企业提高其产品竞争力，减少由于不合理的风险造成的企业召回风险。伴随着ISO-26262功能安全标准的推行及国标的发布，汽车及零部件企业在自己电子电气产品的开发中符合这一标准势在必行。