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