功能安全环境下自适应AUTOSAR系统的评估（一）：基础知识及方法论
内容提要：《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第一”篇章，介绍了相关问题描述、范围及方法论，并具体阐述了本专题连载感兴趣的基本技术主题：面向服务的架构、POSIX、软件平台架构、SOME/IP和GNU/Linux等。
摘要
汽车行业快速发展的技术一直在定义新的挑战，设定新的目标并采用更复杂的系统。因此AUTOSAR联盟开发了AUTOSAR自适应平台，旨在解决和服务新技术因素定义的需求。
使用基于开源开发的现有软件（特别是GNU/Linux）被认为是满足AUTOSAR自适应平台作为其操作系统定义的候选平台。然而，这对解决安全及其在安全关键环境中实施的适用性提出了新的挑战。
由于安全标准没有明确应对开源软件开发的使用，因此本专题连载文章提出了一种定制程序，旨在满足ISO 26262定义的GNU/Linux可能资格要求。虽然人们对GNU/Linux的行为规范知之甚少，以使其适合在安全关键环境中使用，概述的方法旨在利用其声称的POSIX标准合规性来验证GNU/Linux的规范要求。
为了在安全关键型应用程序中进一步使用具有高确定性的GNU/Linux，实施了软件分区机制来控制不同关键性应用程序之间操作系统的资源消耗，特别是计算时间和内存使用，从而实现不受干扰。该实施展示了避免对安全关键应用程序所需资源造成干扰的能力。
《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第一”篇章，介绍了相关问题描述、范围及方法论，并具体阐述了本专题连载感兴趣的基本技术主题：面向服务的架构、POSIX、软件平台架构、SOME/IP和GNU/Linux等。
1.简介
1.1 问题描述
近年来，新技术定义的新挑战和新目标正在迅速改变汽车行业。开发新系统的需求同时推动了新技术的发展，以服务于软件复杂性和不同应用程序之间交换的数据的大幅增加。以自动驾驶、Car-2-X应用程序以及更强的交互和连接为特征的新技术驱动因素，所有这些都封装在创新保护伞下，需要一个新的软件平台来支持这些驱动因素定义的新需求并允许远程增量部署，而无需生成完整的目标镜像，这在当前的AUTOSAR平台上不再可行。与静态、预先配置并因此受到约束的AUTOSAR经典平台不同，新的AUTOSAR自适应平台旨在提供一个具有更高计算能力、更高数据速率、新功能的动态部署、与非AUTOSAR应用程序的交互，甚至空中更新的环境。这鼓励了AUTOSAR自适应平台的独立开发，目的是仍然使两个平台在同一网络上共存并一起运行，而不危及多年来已被证明的现有经典AUTOSAR架构的稳定性。
因此，通过引入基于SOM/IP作为其通信协议的面向服务的体系架构（SOA）方法，定义了新平台的特性，以满足新的需求，该方法将允许在启动时和运行时建立通信路径，支持新功能的动态部署，并允许与非AUTOSAR应用程序进行交互。这是由操作系统指导的，该操作系统支持应用程序的动态启动和调度、资源的动态分配，并通过POSIX（应用程序接口）合规性维护不同操作系统之间的兼容性。此外，AUTOSAR自适应平台旨在补充汽车特定的功能，并维持该领域的基本属性，如可靠性、可用性、可维护性，以及本专题连载中最重要的安全性。
新平台最关键的功能组件是操作系统。操作系统提供应用程序所需的服务，管理可用资源并授予对底层硬件的访问权限。因此，它被认为是在安全关键环境中成功实施系统的核心基础。此外，操作系统往往是最复杂的软件，考虑到上市时间因素，与重新发明已经存在的软件相比，重用现有软件具有巨大的优势。
通过开源软件（OSS）开发重新使用已有软件，不仅可以显著降低开发成本和缩短开发时间，还可以提供更好的软件，更加注重软件本身的功能和质量，而不是市场竞争。这是GNU/Linux的核心基础；过去几年中发展最快的操作系统之一，最近引起了嵌入式应用程序的极大兴趣。基于前面提到的因素，GNU/Linux被选择作为应用程序的操作系统进行评估，因为它不仅能够通过其增强的实时扩展补丁在一定程度上满足实时要求，而且还将通过其符合POSIX的应用程序接口保持其他操作系统之间的兼容性，如AUTOSAR自适应平台规范要求所定义。
然而，这里的问题在于如何将GNU/Linux作为AUTOSAR自适应平台的操作系统，使其在安全关键的环境中运行，并确保其安全运行。这意味着系统的开发过程必须遵循某些标准，以保证其在安全关键环境中运行的能力。在汽车行业，这是由国际标准化组织（ISO）通过ISO 26262标准进行监管的，该标准为所有开发和使用的汽车电子和电气设备在安全相关系统的整个生命周期中定义了功能安全规则。通过应用ISO 26262标准，根据系统失效的后果对有关系统关键性的信息进行分类，并相应地通过核算的安全措施确定应用程序的安全要求。然后，必须通过不同的验证和测试技术来满足这些安全要求，作为确保系统在安全关键环境中安全实施的证据。
1.2 范围
本专题连载的目的是评估在安全关键环境中使用GNU/Linux作为AUTOSAR自适应平台操作系统的可能性。因此，需要对GNU/Linux开发过程进行检查和评估，以满足ISO 26262定义的标准要求。此外，由于操作系统负责应用程序之间的资源管理，因此必须提供保证，以确保在自适应平台上运行的应用程序之间，在内存访问和所需执行时间方面的安全交互，例如在ISO 26262上下文中称为“免于干扰”。
1.3 方法论
GNU/Linux适用性的评估是根据ISO 26262标准进行的，并根据该标准应用软件开发过程要求。ISO 26262通过定义资格程序要求来解决软件的重用问题，但它没有处理在这种情况下使用开源软件开发的问题。因此，需要确定和论证差距，目的是制定适合GNU/Linux的资格认证程序要求。
为了进一步在安全关键型应用中适当使用GNU/Linux，将使用现有的内核功能来实现软件分区机制，以提供对不同关键性系统之间的操作系统资源访问（特别是计算时间和内存使用）的控制，以便实现免于干扰。为此，AUTOSAR自适应平台演示应用程序将作为安全关键应用程序进行处理，目的是保护其所需资源免受模拟非安全关键任务的影响。最后，根据安全要求验证所实现的分区机制，以评估其在应用程序安全行为执行方面的有效性。
2.基础知识
本章介绍了本专题连载感兴趣的基本技术主题，这些主题将在整个过程中使用。
2.1 AUTOSAR自适应平台
“AUTOSAR（汽车开放系统架构）是汽车相关方的国际开发合作伙伴关系，成立于2003年。它的目标是为汽车电子控制单元 (ECU) 创建和建立开放且标准化的软件架构”。
其主要目标是通过不同应用软件功能之间的标准化接口建立ECU软件参考架构的工作定义，以跟上汽车行业快速发展的车辆技术；这涉及标准化ECU平台软件（例如操作系统、通信堆栈、内存管理等），并建立通用模型以增强互操作性。此外，AUTOSAR的目标包括提高ECU对车辆和平台变体的可扩展性、提高软件的可转移性以及确保遵守可用性和安全性要求。反过来，这可以更好地适应流程和产品日益复杂的情况，从而确保整个产品生命周期的可维护性。
为了继续满足新技术定义的要求，并满足不断发展的市场的需求，AUTOSAR开发合作伙伴引入了新标准：AUTOSAR自适应平台。这一目标的驱动因素是，以一种自适应分布式方式独立开发应用程序，同时支持与其他非AUTOSAR应用程序的更强交互，以及通过无线方式提供系统更新的能力。AUTOSAR自适应平台可以进一步为环境提供更高的计算能力、更高的数据速率以及新功能的动态部署，而无需为硬件生成完整的目标镜像。新平台的特性是由前面提到的要求定义的，这些要求将在以下几点的整个过程中进行讨论。
2.1.1 面向服务的架构
面向服务的体系架构 (SOA) 是一种基于应用程序组件和其他软件组件之间交换的服务的使用来创建软件体系架构的方法。它实现了服务重用的想法，当需要升级和其他修改时，无需从头开始；它创建了一种高效、灵活的方式来互连系统以执行特定的工作，从而提高了系统的可扩展性和可重用性，同时简化了不同应用程序的共存。
图1：面向服务的通信范式
服务交换基于面向服务的通信（SOC）范例，其中“应用程序被解释为一组数据提供（传感器）、数据处理（应用程序逻辑）和数据消耗（执行器）服务”。如图1所示，通信路径遵循生产者/消费者或客户端/服务器模型，其中一些应用程序作为生产者提供服务，而其他应用程序作为消费者订阅服务。
这允许引入独立于供应商、产品、技术的新服务，并且无需引入底层程序的变化，这进一步支持在运行时建立通信路径。
2.1.2 POSIX
POSIX是IEEE委员会与Open Group合作定义的“可移植操作系统接口”标准化，专门描述了实时和嵌入式操作系统的运行环境。该标准旨在允许应用程序之间的可移植性以及不同操作系统之间的兼容性。这可以通过指定有关进程和线程管理、基本进程间通信 (IPC) 以及信号和中断处理程序的通用定义来实现。
不同操作系统及其应用程序之间的通用接口，可以通过交换服务的能力进一步补充面向服务的方法，通过创建具有多个协作任务的并发程序，而不受特定软件架构平台实现的限制。
2.1.3 软件平台架构
图2显示了自适应平台架构逻辑，其中应用程序在自适应应用程序 (ARA) 的AUTOSAR运行时之上运行，通过功能集群提供的应用程序接口进行交互。“功能集群通常作为进程实现，属于自适应平台基础或自适应平台服务。Adaptive Platform Foundation提供了Adaptive Platform的基础功能，平台标准服务称为Adaptive Platform Services”。
与操作系统交互时，应用程序编程接口(API)受C++标准库1或PSE51接口的约束，这是IEEE委员会定义的POSIX系列标准化配置文件的一部分，特别是IEEE Std 1003.1。“选择PSE51是为了为现有POSIX应用程序提供可移植性，并实现应用程序之间的不串扰”。
图2：AUTOSAR自适应平台
与经典平台相比，自适应平台引入了巨大的特征变化，主要表现为引入ARA以允许实现面向服务的通信概念。本章末尾对这两个平台进行了比较。
2.1.4 SOME/IP
SOME/IP“基于IP的可扩展服务导向中间件”是一种汽车/嵌入式通信协议，支持远程过程调用、事件通知和底层序列化/有线格式。SOME/IP由AUTOSAR指定以适应设备不同尺寸和不同操作系统的产品，旨在满足汽车嵌入式系统行业的需求和以太网技术解决方案的引入——SOME/IP在经典平台AUTOSAR的4.1版中引入。
基于面向服务的通信 (SOC) 范例，关键点是让应用程序将其功能和行为表示为总线上的服务，独立于底层软件平台。如图3所示，应用程序之间基于SOME/IP协议以客户端/服务器方式交换数据的通信API序列化和反序列化。仅订阅需要的数据并到达客户端；与传统方式不同的是，无论接收者如何，所有数据都会被广播。而且SOME/IP可以在不同的操作系统甚至没有操作系统的嵌入式设备上实现；旨在提供兼容性，并允许与板外系统和非AUTOSAR应用程序进行更强的交互。
图3：基于SOME/IP的面向服务的通信
2.1.5 操作系统要求
操作系统负责自适应平台所有应用程序的资源管理以及它们与较低硬件层的交互。这也构成了功能集群，而功能集群又被实现为应用程序。“AUTOSAR 没有为自适应平台指定新的操作系统，而是定义了自适应应用程序使用的执行上下文和所需的操作系统接口(OSI)”。
为了满足AUTOSAR对自适应平台定义的要求，OSI应该支持POSIX标准库，即IEEE1003.13标准。它还应该支持C++标准库作为ARA接口的一部分，ARA接口是自适应应用程序的标准应用程序接口-如下图所示。此外，操作系统应通过启动和运行期间的动态调度功能和通信路径的动态配置来支持软件应用程序的动态行为。
图4：应用程序之间面向服务的通信的图示
其中，操作系统应提供系统内存预算机制、CPU时间预算机制以及应用程序隔离的多进程支持，如AUTOSAR所定义。
这些规范反映了选择操作系统来提供预期服务时的要求，因此本专题连载的目的是评估GNU/Linux作为安全关键环境中自适应平台操作系统的适用性。
2.1.6 AUTOSAR经典平台与AUTOSAR自适应平台
下表总结了自适应平台的主要特征，并描述了与经典平台的差异。
表1：经典平台与自适应平台的比较
虽然经典平台的通信协议基于在运行时（操作）之前静态预配置的基于信号的范例，但自适应平台基于面向服务的通信，允许动态启动通信路径。类似地，自适应平台应支持的应用程序的动态调度将允许在运行时动态部署应用程序。另一个重要特征是内存管理单元，通过它操作系统执行的每个进程（任务）都有自己的虚拟地址，并且不识别其他进程（任务）的存在。这有助于实现应用程序之间免受干扰的自由，即使在运行时部署它们之后也是如此。当然，这一切都是通过符合POSIX标准的操作系统来实现的，以允许其他应用程序之间的兼容性。
更重要的是，AUTOSAR无意用自适应平台取代经典平台，但目标是让两个平台在同一网络上共存并一起运行，而不危及多年来已被证明的现有经典架构的稳定性。同样，自适应平台的引入旨在进一步补充汽车特定功能，并维持该领域的基本属性，例如可靠性、可用性、可维护性，以及本专题连载中最重要的属性，即安全性。
2.2 GNU/Linux
GNU/Linux是一种使用GNU软件和Linux组合作为内核的操作系统，因此命名为“GNU/Linux”。然而，这造成了自由软件社区和开源软件社区成员之间名称的混淆。因此，在本工作的其余部分中，GNU/Linux用于指代整个操作系统，而术语Linux将用于指代内核本身。
图5：GNU/Linux架构
Linux（内核）是操作系统最重要的部分，因为它管理对作为用户应用程序运行的操作系统程序所需的硬件资源的访问。它在所谓的“内核空间”中运行；通过其系统调用接口与这些应用程序进行交互（如图5所示）。
另一方面，GNU/Linux由内核以外的许多程序组成，其中可能包括图形用户界面、编译器、特定库和许多其他服务。然而，如果没有内核，操作系统就无法提供这些服务。
2.2.1 免费和开源软件
开源软件(OSS)是一种具有任何人都可以检查、修改和增强源代码的软件。开源软件开发可以被视为来自多个独立来源的协作开发，这些来源在一定协议下共同工作，旨在创建比任何单个实体可以产生的更广泛的设计范围。这些协议影响人们从软件中受益的方式，无论是通过部署、研究还是分发软件。
这种思想与自由源软件的思想类似，也赋予用户运行、复制、分发、研究、更改和改进软件的自由。然而，免费并不意味着收费免费，而是作为一种自由问题的免费。正如“自由软件社区”的创建者Richard Stallman的一句名言：“要理解这个概念，你应该将‘自由’视为‘言论自由’，而不是‘免费啤酒’” 。
这两个定义有很多共同点，GNU软件最初是作为自由软件推出的，现在采用Linux作为内核后，GNU/Linux成为由开源软件社区许可的开源软件。
2.2.2 开源软件开发
GNU/Linux的开发过程遵循开源开发模式，软件的开发和审查由公众：Linux社区来完成。这可能意味着代码可以很容易地更改，但是，这里的情况并非如此。更改代码的过程非常严格，以保证软件的完整性。
GNU/Linux的开发实际上遵循着非常严格的分级组织结构，很少有开发者有权力对源代码进行修改。组织结构可以映射为金字塔，如图6所示，在底层，开发人员只能将错误通知其直接上层。下一个级别的开发人员可以创建补丁并提供特定的“维护者”。每个维护者负责不同的子架构，例如“USB”、“网络”等。如果维护者批准引入的补丁。然后，该补丁会被转发到金字塔的顶层进行批准，Linux的创始人Linus Torvalds或Andrew Morton就坐在那里。
图6：Linux组织结构
开源开发模型的主要优点之一是代码可以由不同的角色监控。此外，项目的利益相关者之间交换信息，因此需要有效且可靠的沟通管理。不同利益相关者之间的沟通渠道以电子邮件交换的形式表示，并通过多种开发工具的支持，例如Bugzilla和Git。这些工具进一步促进了错误跟踪过程和修订历史记录控制，这有助于高效的测试和调试过程。
在开源开发方面，软件管理和产品交付非常独特。在使用开源开发模型时，与瀑布模型不同，需求是基于软件产品的早期版本，而不是在项目启动之前实际定义的。因此，敏捷编程方法最适合开源软件开发，因为它们的迭代和增量行为总是可以回到之前的状态；程序可以独立运行。
2.2.3 实时能力
Linux内核并不是为支持实时应用程序而设计的，但是，在过去几年中，随着Linux适应嵌入式世界的趋势，内核开发人员社区一直致力于PREEMPT-RT补丁。目的是提供一个完全可抢占的内核，以支持机器人、数据采集系统和制造工厂等潜在应用的硬实时要求。
实时调度本质上是确定性的，虽然Linux的调度机制仅限于先进先出（SCHED_FIFO）和循环（SCHED_RR）调度策略，但PREEMPT-RT补丁的引入对于确保某些任务不仅具有恒定的CPU时间，而且具有固定的时间片至关重要。AUTOSAR已经为自适应平台操作系统指定了这一点，他们建议引入额外的调度策略，例如最早截止时间优先算法(SCHED_DEADLINE)来满足任何执行要求，因为上述默认调度策略可能无法保证所有实时场景的正确执行。
Linux内核实时功能的引入使其在安全关键型应用程序中被采用——在这些应用程序中，时间是一个敏感的问题——离现实不远。
2.2.4 商用现成软件
商用现成 (COTS) 软件描述了可从商业来源获得的现成软件组件，可以购买、租赁甚至许可给公众。COTS主要是为一般应用目的而开发的，只需很少的修改或无需修改即可使用。考虑到从头开始开发所有内容的成本，COTS被认为比内部开发成本更低。因此，使用COTS可以缩短开发时间，从而提高生产率。COTS的典型示例是操作系统（如Windows和GNU/Linux）、数据库系统（如Oracle和Microsoft SQL Server）以及库或其他可重用软件。
2.3 安全
随着先进技术的引入，嵌入式软件的复杂性增加，涉及协调不同ECU之间交换的大量数据。这种增加的复杂性使得软件和电子设备的运行正确性和及时性变得非常关键，这使得现代汽车在车轮上运行的安全关键计算机系统变得非常复杂。在下面的小节中，我们将讨论安全的定义、评估和实现方法。
2.3.1 安全的定义
在交付可信任的预期功能时，安全性是定义系统可靠性的主要属性之一。在这种一般情况下，安全性可以定义为通过避免与系统可靠性一致的失效的能力来避免灾难性事件的概率。
定义其他三个属性（即可靠性、可用性和可维护性）对于完整的可靠性至关重要，这些属性包括以下概念：
·可靠性：是指在特定时间内服务的连续性，不会出现预期的失效。
·可用性：是系统的准备情况（使用）或系统在任何给定时间按预期工作的概率。
·可维护性：是指处理修复、修改和更新的能力。
所有四个属性对于系统能够按预期执行的信任度（可靠性）都起着极其重要的作用。
然而，安全还有另一个定义，即电气和电子 (E/E) 系统的潜在故障不会对个人造成不合理的风险。这被称为功能安全，主要关注随机硬件故障以及系统设计中的系统故障（无论是在软件开发还是硬件开发过程中）所产生的风险。功能安全与可靠性方面有所区别，因为前者涉及系统属性，而后者涉及安全特性。通过以下示例可以更好地说明这一点——实施紧急制动被视为安全功能，而防止不必要的制动干预则被视为功能安全。因此，构建实现可靠性的功能应通过功能安全进行控制，以评估和确保其对该功能的实际贡献。
汽车领域功能安全系统的评估可以应用国际标准化组织（ISO）26262定义的要求进行评估，该标准专门针对汽车设备进行了调整。
2.3.2 汽车安全标准ISO 26262
ISO 26262标准的发布是为了解决安全相关电气和电子 (E/E) 汽车系统日益复杂的问题。ISO 26262是针对安全相关E/E汽车系统的基于风险的安全标准，允许评估危险运行情况产生的风险。因此，可以相应地定义安全措施，旨在避免或控制系统失效并检测或控制随机硬件失效。它由10个部分组成，约750个条款，涉及硬件和软件级别的系统设计及其相关流程。
2.3.3 ISO 26262定义
ISO 26262在其术语表中定义了以下定义，作为第1节的一部分。出于本专题连载的目的，仅包含ISO 26262定义的一些术语，这些术语将在整个专题文章中使用。此外，这些术语并没有按照确切的顺序表示；或者以一种顺序呈现来对所执行程序及其工作成果的理解。
·安全：是指不存在不合理的（被判断为不可接受的）风险。
·安全状态：是一个相关项没有不合理风险水平的运行模式。
·风险：是危害发生的概率和危害严重程度的组合。
·危险：是由物品的故障行为造成的潜在伤害源。
·故障行为：是指相关项相对于其设计意图的失效或意外行为。
·系统性失效：是指以确定性方式与某个原因相关的失效，只能通过改变设计或制造过程、运行程序、文件或其他相关因素来消除。
·失效：是指元件执行所需功能的能力终止（注意：不正确的规范是失效的根源）。
·错误：是指可能导致元件或相关项发生故障的异常情况。
------------
· 危害分析和风险评估：是一种对物品的危害事件进行识别和分类的方法，并指定与预防或减轻相关危害相关的安全目标和ASIL，以避免不合理的风险。
· 汽车安全完整性等级 (ASIL)：是四个等级之一，指定ISO 26262中项目或元素的必要要求以及为避免不合理的残余风险而应用的安全措施，其中D代表最严格的等级，A代表最不严格的等级。
· 安全目标：是危害分析和风险评估结果的顶层安全要求。
· 功能安全概念：是功能安全需求及其相关信息对架构元素的分配以及实现安全目标所需的交互的规范。
· 功能安全要求：是实现独立的安全行为或实现独立的安全措施的规范——包括其安全相关属性，其中包括有关ASIL的信息，以便实现或维持项目的安全状态，同时考虑到已确定的危害事件。
· 技术安全概念：是技术安全要求的规范及其对系统元素的分配，以供系统设计实施。
· 技术安全要求：是为实现相关功能安全要求而衍生的要求。
· 安全措施：是避免或控制系统失效的活动或技术解决方案（安全机制）。
· 安全机制：是E/E功能或元件实现的技术解决方案，用于检测故障或控制失效以实现或维持安全状态。
2.3.4 安全生命周期
ISO 26262定义的要求适用于所开发系统整个生命周期中进行的所有活动，形成ISO 26262定义的“安全生命周期”。安全生命周期管理遵循行业V模型开发流程的安全关键应用程序开发中涉及的各种元素的识别、设计、监控和评估。下图显示了V模型的左侧，以及以蓝色显示的每个过程的主要意图（工作产品）。
图7：ISO 26262安全生命周期
安全生命周期从概念阶段开始，概念阶段从相关项的功能、已知危害、接口、环境条件及其法律要求的定义开始。接下来是危害分析和风险评估流程，旨在识别和分类物品的危害事件，通过该流程根据其定义的相关ASIL指定安全目标。这样可以采取必要的措施来预防或减轻相关危害，以避免不合理的风险。
因此，功能安全要求被指定并分配给子系统，旨在实现前一阶段定义的安全目标。功能安全要求的规范涉及所需的安全措施，这些措施将由分配的组件执行以满足定义的安全目标。
这启动了系统级别的开发过程，其中功能安全要求规范被转换为技术安全要求规范。随后，系统设计过程的开发开始，目的是设计一个既符合功能要求，又符合前一阶段指定的技术安全要求规范的系统。
最后，这些需求被转化为软件安全需求和硬件安全需求，构成各自开发过程的开始。
2.3.5 危害分析与风险评估
危害分析和风险评估的主要目的是识别和分类可能威胁系统安全的相关项的危害事件，从而制定预防和减轻其发生的安全目标。这是通过以下方式完成的：(1)场景分析和危害识别：通过识别可能导致相关危害事件的物品潜在的意外行为，这需要对物品、其功能和边界进行明确的定义。(2)危害事件分类：根据可能造成伤害的严重程度、车辆暴露于危害发生可能性的时间以及典型驾驶员为防止伤害而采取行动的倾向，对每种危害进行分类 。(3)汽车安全完整性等级(ASIL)确定：根据执行的分类确定安全目标及其相关ASIL。
ASIL代表对某个项目设定的最低要求集，旨在控制或减少随机硬件失效导致的失效发生并避免系统失效。因此，ASIL可以用严重性（S）、暴露概率（E）和可控性（C）属性来表示；其中每个属性根据相关危害事件按级别进行描述，从而产生四个ASIL级别。ASIL A到ASIL D，其中ASIL D规定了最高的完整性要求，ASIL A规定了要达到的最低完整性要求。
为了说明这一点，以下示例描述了对线控制动系统进行的危害分析和风险评估：
图8：线控制动系统的危险分析和风险评估
失效模式描述了可能导致相关危害事件的相关项的潜在意外行为，因此定义车辆的状态、运行条件及其环境非常重要。这样可以正确估计相关属性。考虑到无制动危害及其运行条件，车辆暴露于这种情况的时间是中等概率E3。然而，如果发生这种情况，控制它的可能性非常小，并且可能会造成严重伤害，因此是ASIL C。另一方面，在给定运行条件下发生不对称制动，这种情况的暴露时间的概率较高E4。然而，可控的可能性更大，严重性的危害也更小，因此是ASIL A。
每个ASIL根据其完整性定义了不同的要求，以保证预防或减轻相关风险。根据ISO 26262的规定，每个元素都应继承其在早期阶段定义的安全目标所实现的最高ASIL。（见图7）然而，将整个软件开发到如此高的完整性是一项非常繁重的任务，这将导致非常高的开发成本。此外，将安全需求分配给较小的子系统和相应的软件组件可能会导致将需求分配给已经具有不同ASIL的不同安全目标的软件组件，甚至分配给非安全需求。这创建了一个混合关键性系统，其中必须提供保证以允许不同关键性组件共存，以保证安全关键组件不会受到非安全关键组件的影响。
2.3.6 免于干扰
如果要实施混合关键性系统，则必须证明不同关键性组件之间的安全共存。这可以保证高关键性或高ASIL的组件不会受到其他关键性较低的组件的影响。ISO 26262将其定义为免于干扰（6-附件D），其中应考虑以下形式的干扰：
· 空间不受干扰
确保一个软件组件无法更改另一组件的代码数据，从而保证高关键组件的安全内存访问。
· 暂时不受干扰
确保安全相关组件有必需的计算时间并按预期执行，从而保证高度关键组件的正确时间执行。
· 信息交流
确保安全相关数据在损坏和丢失时得到识别，从而保证数据的安全交换。
为了实现不同临界度部件之间不受干扰的自由度，必须考虑安全机制来检测或避免这种干扰的影响，或者换句话说，检测或避免可能导致干扰的故障的发生。下一小节将简要介绍安全机制的方法。
2.3.7 安全措施和安全机制
故障预防是一种安全措施，涉及避免引入故障的方法。这可以通过软件质量管理方法来改进开发过程，从而减少生产系统中引入的故障数量。例如，使用强大的编程范式和严格的硬件设计规则。
故障排除是一种安全机制，在系统生命周期的开发阶段通过广泛的验证、诊断和纠正程序来执行。
故障预测是一种安全机制，旨在评估系统的故障发生及其激活频度情况。
容错是一种安全机制，旨在通过错误检测和系统恢复技术避免失效。错误检测的一个例子是看门狗，它允许系统识别错误的发生，从而可以执行相应的安全机制。而对于系统恢复，其目的是将包含错误和可能故障的系统状态转换为它们的存在不影响系统整体安全的状态。众所周知的系统恢复技术的一个例子是冗余。它旨在通过复制或添加手段来创建容错系统，以确保提供所需的服务。另一种恢复技术是故障隔离，即使故障存在，也不会对系统的整体安全产生影响。隔离方法的一个例子是软件分区机制。这种方法是本专题连载的重点，将在后续连载篇章中进行更详细的讨论。
更多内容，请关注“功能安全环境下自适应AUTOSAR系统的评估（二）：评估Linux在安全关键环境中的适用性”，关注牛喀网，学习更多汽车科技。有兴趣的朋友，可以添加牛小喀微信：NewCarRen，加入专家社群参与讨论。
会议更多信息及洽谈，详询“牛小喀”微信：NewCarRen
作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！
相关文章
