下载掌阅APP，畅读海量书库
立即打开
随着信息技术与汽车制造技术的深度融合与快速发展，自动驾驶领域关键技术层出不穷，拓展了算法能力边界的同时也带来了软件复杂度的极大提升。为了应对这一发展趋势，涵盖实时操作系统、支撑软件、自动驾驶软件在内的多层软件架构设计逐渐成为主流。
智能网联汽车计算平台软件系统是指适用于异构计算平台、能够实现自动驾驶系统功能，并保证其运行安全性、实时性、可靠性、可扩展性的软件集合。从计算平台来看，智能网联汽车计算平台软件系统可以分为高性能计算平台和安全计算平台两个子系统；从软件层次来看，其包含操作系统层、支持软件层和应用层，如图2-14所示。其中，操作系统层主要包括实时操作系统、虚拟机和板级支持包等；支持软件层主要包括AUTOSAR设计初衷、Classic AUTOSAR和Adaptive AUTOSAR架构等。从软件架构来看，上层功能主要通过下层提供的接口实现。支持软件层支持AUTOSAR架构。
为了统一标准，全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合成立联盟，致力于为汽车工业开发一个开放的、标准化的软件架构，名为汽车开放系统架构（Automotive Open System Architecture, AUTOSAR）。AUTOSAR针对操作系统层、支持软件层、应用层等各个功能组件的定义、分层架构、组件接口等进行定义。当前，AUTOSAR已经成为智能网联汽车行业广泛接受的标准，全球超过100家各类型主流厂商采用该框架开发软件系统。AUTOSAR标准有效地降低了系统集成和调试的复杂度，为未来自动驾驶软硬件系统的货架式采购奠定了基础。
功能安全是车载计算平台软件系统的重要基础。为了满足功能安全，国际标准化组织提出了ISO 26262《道路车辆功能安全》，它是主要针对普通乘用车中与安全相关的电子电气系统制定的功能安全标准。2017年，中国国家标准化管理委员会颁布了针对道路车辆功能安全的国家标准GB/T 34590《道路车辆 功能安全》，规范了全生命周期（设计、开发、生产、运行、服务、报废）内的功能安全要求和流程管控要求，对于从设计开发源头提升车辆安全技术水平具有重要的指导意义，它与ISO 26262一脉相承。
随着安全性、经济环保性、舒适性、便捷性等要素逐渐渗透到汽车设计、制造的所有环节，汽车电子系统的复杂度快速增加，越来越多的数据在整车电子系统中被处理与被传递。如何让汽车电子系统开发更灵活、更有效率，成为汽车从业者需要解决的重要问题。2003年，汽车产业与汽车电子产业巨头（包括BMW、Bosch、Continental、Daimler Chrysler、Volkswagen、Siemens VDO）联合建立了AUTOSAR联盟，并建立了一套开放的汽车电子电气架构——AUTOSAR。随着多年的发展，越来越多的行业内的公司加入到了AUTOSAR联盟中，这其中有汽车整车厂、汽车零部件供应商、芯片制造商以及工具制造商，AUTOSAR也成了汽车电子化/电气化设计的发展方向。
1.为什么要用AUTOSAR
（1）设计标准化、模块化，易于集成
AUTOSAR通过多个抽象层设计将硬件、不同层软件进行封装，大大降低了系统集成的复杂度和成本。软硬件提供商设计产品时，只需要考虑AUTOSAR模块设计原则，即可实现与其他产品的兼容性。
（2）组件可配置化
用户可以根据不同的应用对软硬件组件进行灵活配置。
（3）针对运行环境（Run Time Environ ment, RTE）进行标准化设计
RTE是AUTOSAR架构的重要组成部分，其主要规范了软件组件、操作系统及基础服务组件之间的关系与接口。对上层软件组件，RTE提供标准的通信、调度管理、服务接口；对系统服务，RTE支持POSIX标准的操作系统；对服务组件，RTE支持标准的服务虚拟化层接口。用户需要针对ECU控制器的特点进行配置并生成RTE。
（4）具有标准的测试规范
AUTOSAR针对功能和通信总线制定了标准的测试规范，测试规范包括对于AUTO-SAR的应用兼容性（如RTE的需求、软件服务行为需求和库等）和总线兼容性（总线处理行为和总线协议等）。标准的测试规范大大降低了基于AUTOSAR的软硬件系统的测试与集成成本。
2.Classic AUTOSAR
早期AUTOSAR主要针对确定性较强的软件系统，又被称为Classic AUTOSAR，如图2-23所示。
Classic AUTOSAR的分层式设计主要是为了实现各软件和硬件模块的独立性。
图2-23 Classic AUTOSAR（见彩插）
1）AUTOSAR运行环境隔离了上层的应用软件层（SWC）和下层的基础软件层，摆脱了以往ECU软件开发与验证时对硬件系统的依赖。
2）应用软件层通过RTE提供的标准接口实现调用与通信。RTE作为虚拟功能总线（VFB），实现了底层基础软件与网络拓扑结构（软件组件通信关系）的抽象。当系统进行配置时，软件组件就会被映射到指定的ECU上，而同时组件间的虚拟连接也被映射到了CAN、FlexRay、MOST等总线上。软件组件利用预先定义好的端口，通过VFB来实现通信。RTE依赖下层提供的API实现功能。
3）服务层、ECU抽象层、MCU抽象层及复杂设备驱动层又被称为基础软件层。
①服务层主要包括通信服务、内存服务及系统服务。通信服务（Communication Services）指针对软件系统所有通信实体进行了统一封装和通信调度。通信实体包括ECU内部或跨ECU的软件组件、通信接口（CAN、LIN、FlexRay）等。通信服务对上（应用软件层）隐藏了协议、报文属性，任何实体可以通过统一接口进行通信、网络管理及诊断。内存服务（Memory Services）主要指对控制器各类型存储器进行封装，隐藏了内存地址等细节，为数据的保存、加载、校验保护、验证以及安全存储提供了统一的接口。系统服务（System Services）主要包括中断管理、资源管理、任务管理等内容。
②ECU抽象层主要包括4部分内容：I/O硬件抽象层（I/O Hardware Abstraction Layer）、通信硬件抽象层（Communication Hardware Abstraction Layer）、内存硬件抽象层（Memory Hardware Abstraction Layer）、车载硬件抽象层（On-board Hardware Abstraction Layer）。I/O硬件抽象层将不同I/O设备通道进行封装并向服务层提供统一接口。通信硬件抽象层在通信信道的层次进行了抽象，将CAN、FlexRay、LIN、MOST等信道封装为统一接口。内存硬件抽象层对片内、板上的内存资源进行统一封装，如将片内的EEPROM和片外的EEPROM进行处理并提供统一访问接口。车载硬件抽象层对ECU上特殊的一些外设进行封装，如看门狗、时钟等。经过ECU抽象层的处理，上层软件的开发与ECU硬件解耦合。
③MCU抽象层包括4部分内容：I/O驱动（I/O Drivers）、通信驱动（Communication Drivers）、内存驱动（Memory Drivers）、微处理器驱动（Microcontroller Drivers）。I/O驱动用于对接模拟及数字I/O信号，如ADC、PWM等。通信驱动用于对接SPI、CAN等通信芯片。内存驱动用于对接Flash、EEPROM及外部映射设备（外置Flash）等。微控制器抽象层向上提供统一接口，上层软件的开发与具体微控制器解耦合。
④复杂抽象层接口设计虽然有利于设计解耦合，但是会引入额外处理延迟。复杂设备驱动（Complex Device Drivers）层用于对接对实时性方面具有严苛要求的设备/子系统，通过跨层设计模式在底层驱动部署实时性保障等机制，以降低由于多层软件调用而产生的延迟。复杂设备驱动层可以用于看门狗（WatchDog）、时钟模块（Clock Unit）等。
3.Adaptive AUTOSAR
Classic AUTOSAR要求用户对ECU、MCU上运行的软件具有深刻的理解，并在构建系统时提出严格的约束，如每个任务的计算时间、任务数量与类型等。随着软硬件系统与算法复杂度的快速增加，尤其是多核系统的使用导致用户无法对软件系统提出严格约束。因此，AUTOSAR委员会针对Classic AUTOSAR标准中RTE层进行扩展，如图2-24所示。其中，ARA为AUTOSAR Runtime for Adaptive Applications的缩写。
图2-24 Adaptive AUTOSAR软件架构（见彩插）
Classic AUTOSAR主要用于传统汽车域控制器，它将固定的软件功能、计算复杂度与硬件计算平台进行深层次耦合；Adaptive AUTOSAR主要用于持续进化的自动驾驶领域，它在保证软件架构灵活性的同时，提供有效的通信手段和足够的处理能力。换句话说，Adaptive AUTOSAR不是Classic AUTOSAR的替代，而是为了实现软件设计灵活性而提出的另一个方案。
具体来说，Classic AUTOSAR与Adaptive AUTOSAR的核心区别如下：
1）针对内存地址管理，从统一地址空间管理更新为针对每个应用设置独立的虚拟地址空间进行管理，增加了访存的安全性。
2）基于静态连接关系和具有周期性的通信机制，更新为面向服务、通信关系动态可配置的方式。
3）基于OSEK操作系统更新为支持任何POSIX标准的操作系统。
4）执行代码由直接在ROM执行更新为代码在内存中执行，执行前需要从非易失存储器加载到内存的方式。
5）任务调度方法由静态定义执行顺序更新为支持多种动态调度策略。
1.实时操作系统
操作系统是管理计算机硬件与软件资源的程序，其主要功能包括管理与配置内存、决定系统资源供需的优先次序、控制输入设备与输出设备、操作网络与管理文件系统等。通用操作系统的设计目标为充分利用计算能力、完成任务越多越好。然而，在工业生产等应用领域，任务完成时间的确定性至关重要。为了满足这类应用的需求，实时操作系统应运而生。实时操作系统是指在一定时间约束内完成任务的操作系统。需要强调的是，实时操作系统注重计算时间的稳定，而非计算快。实时操作系统分为硬实时和软实时，分别指任务执行时间抖动在毫秒和微秒级别。两种实时操作系统的选择取决于应用的需要。例如：汽车安全气囊的控制必须要在固定时间内完成，否则可能导致安全问题；视频流处理虽然也有计算时间的约束，但是丢帧只是会导致视频不流畅而不会导致安全问题。
为了保证任务实时性，产业界主要通过优化操作系统内核等方式达到设计目的。内核作为操作系统的核心软件组件，是连接应用程序和硬件的一座桥梁。内核直接操作硬件，并以系统调用的形式向应用程序提供必要的服务。
实时操作系统主要分为微内核（Micro Kernel）和宏内核（Macro Kernel）两类，其基本结构如图2-25所示。微内核架构中，内核只实现了基本的调度、内存管理和通信服务；其他操作系统必需的服务，如设备驱动、文件系统、应用进程通信等，在用户态进程实现。宏内核则将所有基本服务都在内核中实现。
图2-25 微内核与宏内核的基本结构（见彩插）
微内核与宏内核的主要区别见表2-1。
表2-1 微内核与宏内核的主要区别
微内核的主要特点在于其稳定性，这点在工业控制与自动驾驶等应用领域中至关重要。因此，目前主流的商用实时操作系统都采用了微内核设计。然而，微内核仅包含基本功能，用户应用运行时会频繁在用户态和内核态之间切换，导致基于微内核的实时操作系统效率不如宏内核高。为了解决这一问题，风河等主流实时操作系统提供商采用特殊标志位来记录当前系统是否在内核态运行，大大降低了用户态与内核态之间的切换成本。
一般情况，用户通过实时操作系统提供的任务调度算法对应用程序的执行顺序与时间进行约束。调度算法决定当前等待被执行的任务中哪个应当优先被执行。主流实时操作系统提供如下基础调度算法：
（1）SCHED_FIFO
SCHED_FIFO优先处理高优先级任务，相同优先级任务则实行先进先出策略。具体来说，任务执行时，高优先级任务会抢占低优先级任务；低优先级任务只能等到高优先级主动退出才能够执行；对于同等优先级任务调度，先运行的任务一直占据CPU，直到完成计算后，其他同等优先级任务才能得到时间片。该策略主要用于实时任务的调度。
（2）SCHED_RR
SCHED_RR基于CPU时间片对任务进行调度。针对不同优先级任务调度时，SCHED_RR优先将CPU时间片分配给高优先级任务；同等优先级任务调度时，SCHED_RR按照队列先后顺序为每个任务分配一个CPU时间片，时间片结束后仍未完成计算的任务需要重新进入就绪队列末尾（时间片用完）或等待队列（因等待资源而放弃CPU）中。该策略主要用于实时任务的调度。
（3）SCHED_OTHER
SCHED_OTHER为分时调度策略。进行调度时，SCHED_OTHER为就绪队列中所有任务进行动态优先级计算，并选择优先级最高的任务执行。当这个时间片使用完或主动放弃CPU时，该任务重新进入就绪队列末尾（时间片用完）或等待队列（因等待资源而放弃CPU）中。SCHED_OTHER属于非实时调度策略。
用户在任务创建时可以通过设置优先级决定哪些线程需要优先处理；通过设置任务nice值决定该任务每次获得时间片的大小，nice值越小，时间片越大。目前，学术界和产业界提出一些拓展调度策略，将任务截止日期、任务等待时间等作为计算优先级的重要因素。
2.板级支持包
智能网联汽车计算系统由硬件计算平台、系统软件和应用组成。硬件计算平台是系统软件和应用程序运行的硬件基础，目前主流方案基于多种类型的核心计算芯片。如何适配基于不同类型芯片的硬件平台是系统软件需要解决的重要问题。板级支持包（Board Support Package, BSP）是操作系统与不同硬件平台的媒介，其一方面适配了底层硬件的多样性，另一方面向操作系统提供了统一的接口。
不同的操作系统有不同定义形式的BSP，要求BSP所实现的功能也有所不同。在嵌入式Linux系统中，主要是初始化底层硬件并引导操作系统；同时，BSP又是和硬件相关的，还要考虑对硬件的初始化操作。BSP与处理器的指令集架构、硬件板卡的配置等相关。同一个嵌入式操作系统，针对不同的CPU需要不同的BSP支持；即使同一种CPU，也可能由于外设不同需要相应的修改（如外部扩展DRAM的大小、类型改变）。具体来说，其主要作用包括：
1）初始化底层硬件，为操作系统提供底层硬件信息。
2）初始化相关硬件设备，主要是存储设备、通信设备。
3）检测系统硬件是否正常。
4）加载操作系统并启动系统运行。
系统加电时，BSP从位于0地址的非易失存储器FLASH中执行，从串口或网卡的数据寄存器中读取数据，把核心和文件系统下载到内存中指定的位置。下载完成后，BSP程序将CPU中的程序计数器PC置为内核在内存中的起始地址并启动内核（操作系统）。
3.虚拟机
虚拟机（Hypervisor）是一种运行在物理服务器和操作系统之间的中间软件层，可允许多个操作系统和应用共享一套基础物理硬件，如图2-26所示。每个虚拟机具有一套独立于实际硬件的虚拟硬件环境（包括处理器、内存、I/O设备）。各个虚拟机共享物理计算资源，通过虚拟机监视器（Virtual Machine Monitor, VMM）进行管理。VMM是一层位于操作系统和计算机硬件之间的代码，用来将硬件平台分割成多个虚拟机。VMM运行在特权模式，主要作用是隔离并且管理上层运行的多个虚拟机，仲裁它们对底层硬件的访问，并为每个客户操作系统虚拟一套独立于实际硬件的虚拟硬件环境（包括处理器、内存、I/O设备）。VMM采用某种调度算法在各个虚拟机之间共享CPU，如采用时间片轮转调度算法。
图2-26 虚拟机示意图
虚拟机主要分为两种：Type 1直接从硬件芯片启动引导，可以提供最佳的性能；Type 2则是在基础操作系统（如Linux）引导之后才启动，在功能性和可管理性方面比较占优势。目前，主流实时操作系统均支持以上两个类型的虚拟化技术。
在电动汽车电子电气系统中，虚拟机可以提供如下功能。
1）虚拟机可以将软件系统划分为多个独立子系统，每个子系统的运行环境、软件架构互不影响。这一功能有利于系统集成，每个供应商都可以拥有逻辑上独立的运行空间。
2）对底层来说，虚拟机将若干线程/任务进行打包，有利于硬件计算资源的高效分配与调度。虚拟机将真实环境与虚拟环境相隔离，为信息安全防护提供了一层缓冲，增加了信息安全性。
3）目前，AUTOSAR组织将虚拟机列为Adaptive AUTOSAR框架的重要组成部分。
4.OSEK
OSEK是Classic AUTOSAR架构推荐采用的操作系统标准，它主要针对汽车电子开放式系统及其接口进行规范。OSEK主要由四部分组成：操作系统规范（OSEK Operating System，OSEK OS）、通信规范（OSEK Communication, OSEK COM）、网络管理规范（OSEK Net Management, OSEK NM）和OSEK实现语言（OSEK Implementation Language, OIL）。此后，各软件生产厂商都相继推出了符合OSEK规范的产品，比较典型的有WINDRIVER公司的OSEKWorks、ETAS公司的ERCOSEK、MOTOROLA公司的OSEKturbo和美国密西根大学的EMERALDS-OSEK等。随着该规范应用的不断深入，其结构和功能不断完善和优化，版本也不断升级和扩展。OSEK主要有以下特点：
（1）实时性
由于越来越多的微处理器被应用到汽车控制领域，如汽车的防抱死制动系统、动力设备的安全控制系统等，这些系统直接关系着人的生命安全，即使出现丝毫的差错也会导致危及生命安全的严重后果，因此要求操作系统具有严格的实时性。OSEK操作系统通过静态的系统配置、占先式调度策略、提供警报机制和优化系统运行机制，以提高中断响应速度等方法来满足用户的实时需求。
（2）可移植性
OSEK规范详细规定了操作系统运行的各种机制，并在这些机制的基础上制定了标准的应用程序编程接口，使那些独立编写的代码能够很容易地整合起来，增强了应用程序的可移植性。OSEK还制定了标准的OIL，用户只需更改OIL配置文件中与硬件相关部分，便可实现不同微处理器之间的应用程序移植。通过这些方法，减少了用于维护应用程序软件和提高它的可移植性的费用，降低了应用程序的开发成本。
（3）可扩展性
为了适用于广泛的目标处理器，支持运行在广泛硬件基础上的实时程序，OSEK操作系统具备高度模块化和可灵活配置的特性。它定义了不同的符合级别（Conformance Classes），并采用对不同应用程序有可靠接收能力的体系结构，从而增强了系统的可扩展性。OSEK操作系统可以在很少的硬件资源（RAM、ROM、CPC时间）环境下运行，即便在8位微处理器上也是如此。
OSEK操作系统标准为汽车电子软件系统的稳定性和可靠性奠定了重要基础，在Classic AUTOSAR架构中占有不可或缺的地位。然而，随着以多核处理器、虚拟化、软件交互复杂化等为典型特征的计算系统快速发展，OSEK平台的适用性逐渐降低。在Adaptive AUTOSAR中，POSIX替代了OSEK成为操作系统推荐的标准。
5.POSIX
POSIX指可移植操作系统接口（Portable Operating System Interface of UNIX，缩写为POSIX），是IEEE协会为保证兼容性而提出的一个针对操作系统的规范，其正式标准为IEEE 1003，对应国际标准ISO/IEC 9945。
POSIX标准涵盖了以下内容：
1）针对必要的概念和术语进行了标准化，如绝对路径、存取模式、地址空间、适当权限、定时器、异步I/O操作、后台进程、后台进程组、块文件、阻塞进程等。
2）针对基本的类型进行了定义，如dev_t用于设备号、gid_t用于进程标志符、ino_t用于文件序列号、inode_t用于一些文件参数、link_t用于连接内容、off_t用于文件大小、pid_t用于进程或进程组标志符等。
3）规范了进程与信号的控制与使用，如进程的创建、执行与终止等，以及进程收到信号的处理、进程挂起与延迟等。
4）对进程运行环境的规范，如进程标识符及相关操作、用户与用户组及相关操作、获取环境变量方法等内容。
5）规范了文件与目录的操作，如获得路径、打开文件、连接文件、创建目录、文件属性等。
6）针对输入与输出进行规范，如管道的使用，文件的读写操作，文件同步、异步输入与输出等。
7）定义了设备驱动和分类函数，如终端的定义与使用等。
8）针对C语言提供基本的支持，如基础时间函数、输入输出规范（包括文件操作）、非局部跳转、时间域设置等。
9）针对系统数据库进行了规范，其中主要涉及组数据库和用户数据库。组数据库主要包括组名、组ID和属于该组的用户列表。用户数据库包括用户名、用户ID、初始化目录、初始化用户程序等。
10）规范了数据交换形式，主要包括tar格式、cpio格式、字节流等。
11）线程同步操作的定义，主要涉及信号量的使用等。
12）定义了基础内存管理服务，包括进程内存的使用、内存映像函数、共享内存工具等。
13）任务调度的基本规范，包括调度参数、主要的调度策略、设置和获取调度参数的方法等。
14）系统时钟和定时器的定义，如时间的格式、操作时间的函数、定时器的使用、休眠函数的使用等。
15）规范了进程消息传递机制，如队列的定义和使用等。
任何POSIX规范的操作系统都符合上述描述并提供相应接口。同时，应用开发采用POSIX提供的接口可以获得更好的移植性。与OSEK标准操作系统相比，POSIX系统的系统镜像较大（通常在MB），需要加载到内存运行，启动时间较长（通常在几秒到几十秒之间）。然而，POSIX操作系统由于支持的计算平台种类多、兼容性好、代码重用率高等，逐渐成为电动汽车电子电气系统的主流操作系统。
目前，最新的Adaptive AUTOSAR（2019年3月发布）支持POSIX PSE51版本接口。相关POSIX版本号及其主要特点见表2-2。需要注意的是，虽然Adaptive AUTOSAR推荐的架构不包含内存管理单元、文件系统等，但是方案提供商依然可以提供相应特性。
表2-2 相关POSIX版本号及其主要特点
与Classic AUTOSAR不同，Adaptive AUTOSAR标准仍处于快速迭代阶段，每年更新两个版本。
安全性、实时性、计算能力和可扩展性是汽车电子电气软件系统需要保障的重要特性。然而，目前没有任何单一解决方案可以满足上述要求。基于Classic AUTOSAR、Adaptive AUTOSAR及普通架构的软件系统特点（图2-27），为了满足汽车电子电气软件系统要求，主要汽车电子厂商推出了基于AUTOSAR的异构系统软件解决方案。
图2-27 软件架构主要特点示意图
1.Vector
Vector是总线开发工具、网络节点测试验证工具和嵌入式软件组件供应商，为汽车总线网络的设计、建模、仿真、分析、测试以及ECU的开发、测试、标定和诊断等领域提供了一系列强有力的软硬件工具和源代码。
MICROSAR是Vector的Classic AU-TOSAR方案，它支持安全域与非安全域的混合架构，如图2-28所示。MICROSAR方案包括实时操作系统、基础支撑软件、看门狗、安全通信机制、运行环境等内容。MICROSAR的主要特点如下：
图2-28 Vector MICROSAR方案
（1）MICROSAR.OS
MICROSAR.OS是Vector推出的实时操作系统，其开发严格按照ASIL-D规范，符合OSEK架构。该OS支持单核或多核架构，针对每个计算核心的任务可以检测实际执行时间是否超过预算。针对野指针、栈溢出、访问越界、上下文切换访存成本高等问题，Vector通过优化栈指针，程序计数器和内存保护单元（Memory Protection Unit, MPU）配置等方法对内存使用不合法行为进行检测，同时保证了上下文切换的安全性。
MICROSAR.OS支持Classic AUTOSAR4.3新增的安全特征，即用户模式对外设寄存器的读写及中断源控制接口。
（2）MICROSAR.RTE
Vector在标准Classic AUTOSAR的基础上进行了拓展，形成MICROSAR.RTE。其部分新特性如下：①MICROSAR.RTE自动生成包括所有RTE API的SWC模板，方便用户开发；②提供额外的内存保护机制；③基于AUTOSAR提出的“Mode-Dependent Runnables”概念，可以对初始化程序进行配置；④支持以HTML等形式向用户报告当前RTE资源使用情况；⑤支持多核。
（3）MICROSAR.COM
MICROSAR.COM主要实现了AUTOSAR的通信服务，它可以支持任意数目的通信信道，用户应用不需要关心数据是否发送到/接收自本地还是其他控制器。该模块需要针对特定协议的总线模块和MCAL支持。MICROSAR支持CAN、ETH、LIN、FR、IPC等协议与通信方式。与标准AUTOSAR不同，MICROSAR.COM可以作为网关对通信声明进行配置，提供了针对通信拓扑的灵活性。此外，它可以将CAN、LIN、Flex Ray等数据转发到以太网，以便于用户调试与分析。
（4）MICROSAR.MEM
针对内存管理，MICROSAR.MEM可以对Flash、EEPROM等类型存储器进行管理、错误检查、信息恢复等。其中，Ea是EEPROM的接口，Fee为Flash的抽象接口，Memif在Ea和Fee上层提供统一的抽象接口，Nvm作为非易失存储器管理向Ea、Fee设备的存储信息管理与读写，同时将一些关键数据进行冗余存储以提高数据保护能力。
（5）MICROSAR.SYS
该模块提供ECU状态管理、跨ECU时间同步、通信信道与网络的控制、监控上层SWC是否正常工作、看门狗等功能。看门狗是MICROSAR.SYS的基础，它支持对用户应用和基础软件的监控，而且在必要的时候可以对ECU进行重置。MICROSAR.SYS可以与硬件看门狗配合使用，通过SPI总线向硬件看门狗报告状态。通过软硬件结合的方式，看门狗具有较高的可靠性。
（6）MCAL与MICROSAR.EXT
MCAL为AUTOSAR驱动软件，MICROSAR.EXT为针对特定外部设备的驱动。Vector针对主流传感器与执行器提供设备驱动，缩短用户开发时间。
（7）MICROSAR.AMD
为了能够监控实际系统中各个软件组件的运行情况并方便调试，Vector开发了MICROSAR.AMD组件。它主要负责报告包括应用与基础支持软件在运行中发生的事件与错误信息，同时监控系统CPU负载与软件执行事件。调试信息通过通用校准协议（Universal Calibration Protocol, XCP）将内部变量进行追溯，并通过CANape或CANoe. AMD在PC端使用图形界面查看。
目前来看，Vector提供的方案可以涵盖Classic AUTOSAR系统及开发的各个方面，是广泛被认可的Classic AUTOSAR方案提供商。
考虑到相关标准处于快速迭代阶段，Vector Adaptive AUTOSAR方案仍在快速更新阶段。Vector的Adaptive AUTOSAR称为Adaptive MICROSAR，它主要包括ARA及一套高效开发与集成环境。Adaptive MICROSAR用于适配高性能计算平台，整个方案支持ASILD标准（ARA、虚拟机与POSIX操作系统）。此外，Adaptive MICROSAR支持多个版本POSIX及安全的C++STL库。Adaptive MICROSAR各个模块及其支持标准如图2-29所示。
Adaptive MICROSAR支持较为完整的SOME/IP绑定（通信层），且在跨硬件平台通信时还可以与进程通信机制相结合以达到更高的性能；支持针对TCP链接进行生命周期管理；支持网络通信优先级设定；提供静态服务发现机制以加速系统启动；提供基于XCP的调试机制；保持与Adaptive AUTOSAR同步演进；提供单元和集成测试工具。
在开发配套软件方面，Vector提供包括系统设计到产品验证的整套工具链，开发过程及每个阶段对应的工具如图2-30所示。其中：
1）DaVinci Configurator Pro用于定义MICROSAR基本软件组件及RTE，基本组件可能来源于Vector或第三方。
图2-29 Adaptive MICROSAR各个模块及其支持标准（见彩插）
2）PREEvision是一个基于模型的车载电子电气系统设计软件，它用于定义需求、设计功能分布、定义组件及数据通信关系等。
3）vVIRTUALTarget Pro用于仿真RTE中仿真验证软件组件。
4）CANdelaStudio用于设计诊断功能。
5）vVIRTUALTarget Basic用于仿真ECU等硬件平台验证软件组件。
6）TA Tool Suite用于设计、仿真、优化和验证嵌入式单核/多核实时系统。
7）CANape用于测量和校准内部数据。
8）CANoe用于开发、测试和分析硬件平台及网络。
图2-30 Vector MICROSAR实施阶段与工具链示意图
2.TTTech
TTTech针对AUTOSAR提出了包括MotionWise中间件及确定以太网的解决方案，它同时支持Classic AUTOSAR及Adaptive AUTOSAR，如图2-31所示。用户开发时，可以选择使用AUTOSAR标准接口或者TTTech标准接口；后者既可以在Classic AUTOSAR平台也可以在Adaptive AUTOSAR平台运行。MotionWise支持ASIL-D安全标准。
图2-31 TTTech方案（红色为TTTech提供）（见彩插）
与Vector不同，TTTech不提供操作系统及虚拟机。用户可以选择任何支持POSIX标准的操作系统及相应的虚拟机实现系统。与Adaptive AUTOSAR相比，MotionWise具有以下特点：
1）MotionWise可以在不同硬件平台进行部署，在各个平台提供统一的运行环境，用户程序可以在运行Classic AUTOSAR、Adaptive AUTOSAR和POSIX的软件系统之间切换。
2）提供基于时间帧的任务调度方法，用户可以指定每个处理核心的任务执行时间，进而保证整个软件系统的实时性。任务排布时间精度达到毫秒级。
3）基于MotionWise标准开发的软件应用，可以在任何运行MotionWise中间件的硬件平台之间无缝切换。
4）MotionWise支持对单个计算任务、一系列顺序执行计算任务（分布在多个组件）的实时性进行保证，保证若干顺序执行的任务延迟稳定。此外，MotionWise可以在异构硬件平台进行部署，保证跨平台任务执行的实时性和确定性。
5）传统软件开发流程中，软件设计者针对需求进行拆解，并对各个子系统的功能和性能进行设计。软件开发人员按照设计文档进行实施，并交由软件设计者进行集成。一般情况下，软件设计者通过CPU计算时长描述子系统性能需求。然而，这些子系统在进行集成时可能由于关键计算资源竞争等原因造成资源冲突。MotionWise提供基于时间帧的调度方式，软件设计者在设计子系统时可以明确每个子系统的CPU时间片长度，保证后期系统集成时各个子系统不会恶性竞争CPU资源。
相比其他AUTOSAR方案，MotionWise由于采用了确定调度（deterministic scheduling）具有更强的系统确定性和实时性。无论当前CPU负载有多高，MotionWise都可以做到强实时性。确定调度是指将CPU处理核的时间片与任务线程进行绑定，在每个时间周期的固定时刻运行该线程。通过编排CPU时间片，MotionWise可以精心设计各个任务的执行顺序与时间，避免了通用调度策略由于抢占造成的不确定性，以及线程频繁切换带来的资源浪费。然而，越来越复杂的软件系统为CPU时间片的高效分配带来极大的挑战，要求开发人员对软件系统具有深刻的了解。
需要强调的是，MotionWise提供端到端的延迟保证服务。具体来说，用户在进行软件系统设计时可以配置任务软件在各个处理核的精确运行时间（任务执行时间排布表），并根据任务执行时间排布表中该任务的计算结束时间估计其数据交互时间，进而通过配置以太网交换机进一步降低两个任务之间的通信延迟。
如图2-32所示，TTTech提出时间确定以太网方案，名为TTEthernet，它支持以下三种网络数据交换机制：
1）时间触发传输。即在交换芯片上实施确定性调度，将固定时间片分配给固定数据流或者端口。
2）限制流量传输。即限定数据流或端口之间的数据流量带宽。
3）尽力服务。交换机对该类型采用尽力而为的交换策略，不保证任务之间数据报文的传输延迟。
图2-32 TTEthernet传输机制示意图
TT—时间触发传输 RC—限制流量传输 BE—尽力服务
目前，奥迪（zFAS系统）、Renesas、宝马、英飞凌、保时捷等主流汽车、汽车电子厂商都采用了MotionWise系统。此外，该系统在多款L2、L3级别的自动驾驶系统中进行了部署。
3.Windriver
Windriver是世界主要的软件系统提供商之一，它具有超过17年安全系统设计经验，产品覆盖航空、航天等传统功能安全领域。2019年，Windriver基于Adaptive AUTOSAR推出了汽车软件系统解决方案，该方案主要包括实时操作系统、板级支持包、虚拟机、Adaptive AUTOSAR服务与API等，如图2-33所示。Windriver提倡针对安全需求进行拆解，尽量减少需要进行安全认证的代码数量。因此，Windriver方案允许用户在同一硬件平台灵活部署不同安全等级应用，从而降低用户开发与认证成本。
图2-33 Windriver Adaptive AUTOSAR
Windriver实时操作系统称为VxWorks，它支持ASIL-D安全标准，是业界最成熟的实时操作系统方案。VxWorks允许用户根据需求设计基于时间和空间的任务调度策略，并提供经过安全认证的软件开发平台。VxWorks支持时间触发以太网标准，可以通过标准规范为数据流设定转发时间片。主机与交换机之间可以达到高精度时间同步。WRLinux是Windriver推出的非实时操作系统，它基于Yocto框架，支持POSIX标准。WRLinux是非实时系统域的重要基础。
Helix Virtualization Platform（HVP）是Type 1型虚拟机，可以支持实时软件系统域与非实时软件系统域同时部署。由于采用了硬件虚拟化指令集，HVP部署不会带来硬件性能的显著下降。HVP支持软件栈的时域与空间域的隔离，保证用户软件运行环境隔离，提高安全性。HVP运用处理器中的硬件虚拟加速器，可以实现高性能计算周期和低成本I/O访问。此外，其占用空间极小，同时可以达到高吞吐量和低延迟的进程间通信（IPC）。
Windriver提供Adaptive AUTOSAR中间件。其方案在设计时就以功能安全为目标，相关产品在设计时综合考虑了功能安全因素，尤其在防止软件失效方面具有较高的检测与恢复能力。
与其他方案相比，Windriver方案具有以下特点：
1）安全的网络协议栈。为了保证网络通信的实时性，Windriver提供从驱动到网络协议栈的高效部署与设计，如图2-34所示。具体来说，它既支持将网络协议栈部署在操作系统内核，又可以部署在容器内（将针对协议栈的攻击隔离在容器内）；既可以部署单个协议栈，又可以部署多个网络协议栈（使用户程序在协议栈层实现隔离）。
图2-34 安全网络协议栈
2）高灵活性Edge Sync机制。Windriver Edge Sync支持传统ECU设备升级协议，并允许用户采用增量更新方式通过以太网进行升级。
3）提供高效的任务调度方法。Windriver帮助用户对应用的最长执行时间进行测量和计算，并提供针对截止时间的任务调度方法。
4）提供计算资源隔离机制。Windriver支持针对应用的权限控制，如是否允许某些应用调用open()函数、信号量、消息队列、数据区等。此外，该机制还允许系统管理员设置每个应用的最大内存使用量等。
5）降低应用开发和部署成本。HVP支持基于标准的开放式设备虚拟化框架，可有效支持第三方操作系统，无需仿真成本，从而实现跨产品线的高可移植性。具体来说，它支持ARINC 653、APEX API、POSIX和FACETM等平台，支持独立构建、链接和加载（IBLL），允许根据RTCA DO-297集成模块化航空电子设备（IMA）标准进行软件应用程序的独立异步开发、测试和交付。
6）提供较高的灵活性。HVP支持开发和部署运行机器学习与分析等应用程序的静态或动态配置系统，还可使不同安全级别的系统满足安全认证和通用应用要求。HVP允许这些应用程序在同一平台共同运行，不仅可确保各应用的独立域，还支持各应用间相互协作与高效通信。
7）WRLinux是Windriver针对嵌入式的开源Linux解决方案（非实时）。Windriver维护WRLinux并向用户提供安全漏洞检测、评估、通知与补救业务，并提供开源软件合规文档等，以方便用户使用。最新的WRLinux基于Yacto2.6框架与Linux内核4.18，支持GCC8.2、GDB8.2、Glibc 2.28、Binutils 2.31。
Windriver自动驾驶软件系统方案尚未发布（截至2019年6月）。