1   引言

汽车更像是一个数据中心。

把所有的汽车系统都看成是在单一操作系统上运行的计算机，这是一个常见的错误。实际上，一辆普通的汽车有很多电子控制单元（ECU），就像一台台小型的计算机。它们都是不同的，负责不同的功能，工作在不同的操作系统上。

2   AUTOSAR

AUTomotive Open System ARchitecture (AUTOSAR)是2003年成立的一个由汽车相关方组成的全球开发伙伴关系。它追求的目标是为汽车电子控制单元（ECU）创建和建立一个开放和标准化的软件架构。目标包括对不同车辆和平台变体的可扩展性、软件的可转移性、对可用性和安全性要求的考虑、不同合作伙伴之间的合作、自然资源的可持续利用以及在整个产品生命周期内的可维护性。

AUTOSAR提供了一套描述基本软件模块的规范，定义了应用接口，并建立了基于标准化交换格式的通用开发方法。AUTOSAR分层软件架构所提供的基本软件模块可以应用于不同厂商的汽车和不同供应商的电子元件，从而降低研发支出，以便适应日益复杂的汽车电子和软件架构。

基于这一指导原则，AUTOSAR的设计旨在为创新的电子系统铺平道路，以进一步提高性能、安全性和环境友好性，并在车辆的使用寿命内促进软件和硬件的交换和更新。它的目的是为即将到来的技术做好准备，并在不影响质量的情况下提高成本效益。

2.1软件架构

AUTOSAR采用三层架构：

1.   基础软件：标准化的软件模块（大部分），没有明确的汽车工作，但提供运行上层软件层功能部分所需的服务。

2.   运行时环境（RTE）。中间件，它从网络拓扑中抽象出来，用于应用软件组件之间和基本软件与应用程序之间的ECU内部和内部信息交换。

3.   应用层：与运行时环境交互的应用软件组件。

2.1.1 实时操作系统 

实时操作系统(RTOS)是一种旨在为实时应用程序提供服务的操作系统(OS)，这些应用程序在收到数据时进行处理，通常没有缓冲区延迟。处理时间要求（包括任何操作系统延迟）以十分之一秒或更短的时间增量为单位。

实时系统是一个有时间限制的系统，它有明确的、固定的时间约束。处理必须在规定的约束条件下完成，否则系统将失败。它们要么是事件驱动的，要么是分时的。事件驱动系统根据任务的优先级在任务之间进行切换，而分时系统则根据时钟中断来切换任务。大多数RTOS使用的是先发制人的调度算法。

RTOS的一个关键特征是其关于接受和完成应用程序任务所需时间的一致性水平，这种可变性就是 "抖动（jitter）"，一个 "硬"的实时操作系统(Hard RTOS)比一个 "软"的实时操作系统(Soft RTOS)的抖动要小。在硬RTOS中，迟答是一个错误的答案，而在软RTOS中，迟答是可以接受的。

主要的设计目标不是高吞吐量，而是保证软件或硬件的性能类别。一个RTOS如果通常或一般能满足某个截止日期，就是软实时操作系统，但如果它能确定性地满足某个截止日期，就是硬实时操作系统。

一个RTOS具有先进的调度算法。调度器的灵活性使得计算机系统能够更广泛地协调进程的优先级，但实时操作系统更经常地致力于一组狭窄的应用程序。

实时操作系统的关键因素是最小的中断延迟和最小的线程切换延迟。一个实时操作系统的价值更多的是它的响应速度或可预测性，而不是它在给定时间内可以执行的工作量。

在汽车领域中，我们可以粗略地把它们分为两大类。

2.1.2 基础软件和运行时环境

第一类是与传感器一起工作并控制汽车的ECU：转向、制动、消耗燃料、换挡。

不同的操作系统负责管理这些ECU，但肯定应该是像QNX或MINIX这样的实时操作系统。

2.1.2.1    QNX 

QNX是一个类似 Unix 的商用实时操作系统，主要面向嵌入式系统市场。QNX是最早商业化成功的微内核操作系统之一，截至2020年，QNX已被应用于汽车和手机等多种设备中。

该产品最初是由加拿大公司Quantum Software Systems在20世纪80年代初开发的，后来改名为QNX Software Systems。该公司最终于2010年被黑莓有限公司收购。

作为一种基于微内核的操作系统，QNX 的理念是将操作系统内核的大部分内容以若干小任务的形式运行，这些小任务被命名为资源管理器。这有别于传统的单片机内核，因为在传统的单片机内核中，操作系统内核是一个非常庞大的程序，由大量具有特殊能力的部分组成。在 QNX 的情况下，微内核的使用可以允许用户（开发人员）关闭任何他们不需要的功能，而无需改变操作系统。

该系统的体积相当小，早期的版本可以装在一张1.44 MB的软盘上。

QNX Neutrino（2001 年）已被移植到多个平台上，现在几乎可以在嵌入式市场上使用的所有现代中央处理器（CPU）系列上运行，包括 PowerPC、x86、MIPS、SH-4 以及与之密切相关的 ARM、StrongARM 和 XScale。

QNX 为非商业和学术用户提供授权。

黑莓公司设计的黑莓PlayBook平板电脑采用QNX版本作为主要操作系统。运行BlackBerry 10操作系统的黑莓设备也是基于QNX。

QNX 还被用于汽车信息娱乐系统，许多主要汽车制造商都提供了包含嵌入式 QNX 架构的变体。流行的 SSL/TLS 库（如 wolfSSL）也支持 QNX。

2.1.2.2    MINIX

Minix是一个符合POSIX标准的基于微内核架构的类Unix操作系统。 

MINIX的早期版本是由Andrew S. Tanenbaum为教育目的而创建的。从MINIX 3开始，开发的主要目的从教育转向创建一个高可靠性和自愈性的微内核操作系统。MINIX现在是作为开放源码软件开发的。

2.1.3 管理应用程序环境

它启动的是用户最常见的系统应用，如信息娱乐系统。负责这一级的操作系统可以是Linux、Android、QNX，甚至是Windows，就像平常的电脑一样，控制整个系统。

在这种情况下，软件开发和其他领域的软件开发一样。

2.1.4 与普通操作系统不同之处

AUTOSAR操作系统在几个方面与普通操作系统不同。

首先，它是静态配置的。这意味着与Linux或Windows不同，你不能仅仅通过API创建新的任务。你需要在设计任务时定义所有你需要的任务。

其次，虽然它被称为操作系统，但实际上它只是一个调度器（还有其他一些位）。其他你可能在 "传统的操作系统"中找到的东西（例如设备驱动程序）都是由AUTOSAR堆栈的其他部分来处理的。

第三，调度遵循固定的优先级先发制人的方法，而不是（比如）其他操作系统可能使用的时间分割。 

2.2方法论

l  系统配置描述包括所有系统信息和不同ECU之间约定的信息（如总线信号的定义）。

l  ECU摘录：包含特定ECU所需的系统配置描述中的信息（如特定ECU可以访问的那些信号）。

l  ECU配置描述：包含特定ECU本地的所有基本软件配置信息。使用这些信息来构建可执行软件，基本软件模块的代码和软件组件的代码出来。

2.2.1 经典平台

AUTOSAR经典平台是基于OSEK的嵌入式实时ECU的标准。它的主要可交付成果是规范。

AUTOSAR Classic Platform 架构在最高抽象层次上区分了运行在微控制器上的三个软件层：应用程序、运行时环境 (RTE) 和基础软件 (BSW)。

应用软件层主要与硬件无关。

软件组件之间的通信和对BSW的访问都是通过RTE进行的，RTE代表了应用程序的完整接口。

BSW主要分为三层和复杂的驱动程序。

1.  服务层

2.  电子控制单元（ECU）抽象化

3.  微控制器抽象

服务被进一步划分为代表系统、内存和通信服务基础设施的功能组。

经典平台的一个基本概念是虚拟功能总线（VFB）。这个虚拟总线是一组抽象的RTE，还没有部署到具体的ECU上，并将应用程序与基础设施解耦。它通过专用端口进行通信，这意味着应用软件的通信接口必须映射到这些端口。VFB处理单个ECU内部和ECU之间的通信。从应用的角度来看，不需要对低层技术或依赖性的详细了解。这支持独立于硬件的开发和应用软件的使用。

经典平台还可以通过使用Franca接口定义语言(Franca IDL)来集成非AUTOSAR系统，如GENIVI。

2.2.2 自适应平台

新的需求要求开发自适应平台。一个突出的例子是高度自动驾驶，在这种情况下，驾驶员将驾驶责任暂时或者部分转移到车辆上。这可能需要与交通基础设施（如交通标志和红绿灯）、云服务器（如访问最新的交通信息或地图数据）进行通信，或使用微处理器和高性能计算硬件进行并行处理，如图形处理单元（GPU）。

此外，Car-2-X应用需要与车辆和车载系统进行交互。这意味着系统必须提供安全的车载通信、支持跨域计算平台、智能手机集成、整合非AUTOSAR系统等。同时，基于云端的服务也需要专门的安全手段，如安全云端交互、应急车辆抢占等。它们将实现远程和分布式服务，如远程诊断、空中(OTA)更新、维修和交换处理。

为了支持客户应用的动态部署，并为需要高端计算能力的应用提供环境，AUTOSAR目前正在对AUTOSAR自适应平台进行标准化。其核心是一个基于POSIX标准的操作系统。该操作系统可以通过根据IEEE1003.13的POSIX子集（即PSE51）从应用中使用。自适应平台的主要特点之一是面向服务的通信，因为该平台是基于面向服务的架构。

自适应AUTOSAR是使用C++开发和编写的，C++是一种面向对象的编程语言。使用自适应平台进行车内联网的通信协议是基于以太网通信协议的SOME/IP。

自适应平台有两种类型的接口：服务和应用编程接口（API）。该平台由功能集群组成，这些功能集群由服务和AUTOSAR自适应平台基础组成。

功能集群：

1.   组装自适应平台的功能。

2.   确定需求规格的分组。

3.   从应用和网络角度描述软件平台的行为。

4.   对实现自适应平台的架构的最终SW设计不设限制。

AUTOSAR自适应平台中的功能集群每台（虚拟）机器至少要有一个实例，而服务可以分布在车内网络中。

自适应平台的服务包括：

1.  更新和配置管理

2.  状态管理

3.  网络管理

4.  诊断

AUTOSAR自适应平台包含规范和代码。与经典平台相比，AUTOSAR开发了一个实施方案，以缩短验证周期并说明基本概念。该实现可供所有 AUTOSAR 合作伙伴使用。

2.2.3 基金会

基金会标准的目的是加强AUTOSAR平台之间的互操作性。基金会包含AUTOSAR平台之间共享的共同要求和技术规格（例如协议）以及共同方法。

2.2.4 验收测试

2014年，AUTOSAR验收测试被引入，以最大限度地减少测试工作和成本。验收测试规范是使用各平台的指定接口的系统测试规范。同时，它们也在考虑总线上的指定行为。它们可以被看作是给定平台功能的黑盒测试案例。标准验收测试规范有助于实现这些目标。

2.2.5 标准化应用接口

各厂家和供应商功能接口的标准化以及不同软件层之间接口的标准化被视为实现AUTOSAR技术目标的基础，只有将具体的接口内容在物理和时间表示上标准化，才能实现所需的集成兼容性。

2.2.6 组织架构

AUTOSAR定义了六个不同级别的成员。伙伴的贡献因伙伴关系的类型而不同：

1.  核心合作伙伴

2.  战略合作伙伴

3.  高级合作伙伴

4.  准合伙人

5.  发展伙伴

6.  出席者

核心合作伙伴包括创始伙伴BMW, Bosch, Continental, Daimler AG, Ford, General Motors, PSA Peugeot Citroën, Toyota, and Volkswagen。这些公司负责AUTOSAR开发伙伴关系的组织、管理和控制。在这个核心中，执行委员会确定整体战略和路线图。 指导委员会管理日常的非技术操作和合作伙伴的接纳、公共关系和合同问题。 主席和副主席的任期为一年，代表指导委员会进行这方面的工作。 AUTOSAR发言人负责与外界的沟通。

战略伙伴从高级伙伴圈子中任命，任期两年，在各种技术、组织和日常过程中支持项目负责人团队。他们还为项目负责人提供新的战略投入。

准合伙人（Premium）和发展伙伴（Development）成员对由核心伙伴建立的项目负责人团队协调和监督的工作包做出贡献。AUTOSAR 已经发布的标准文件正在被业界使用。

AUTOSAR的与会者目前正在参与学术合作和非商业项目。

截至2019年年中，共有270多家公司参与AUTOSAR开发合作。

3   参考

https://www.autosar.org/

https://en.wikipedia.org/wiki/MINIX

https://en.wikipedia.org/wiki/QNX

https://en.wikipedia.org/wiki/Real-time_operating_system

https://www.quora.com/What-operating-systems-are-used-in-cars

https://www.quora.com/What-types-of-operating-systems-are-being-used-in-autonomous-vehicles

https://en.wikipedia.org/wiki/AUTOSAR