AUTOSAR介绍

1、AUTOSAR架构介绍

        AUTOSAR(AUTomotive Open System ARchitecture，汽车开放系统架构)是汽车和软件行业领先公司的全球合作联盟，为智能移动开发和建立标准化的软件框架以及开放的E/E系统架构。考虑到目前和未来市场中不同的汽车E/E架构，AUTOSAR联盟为汽车软件架构建立了开放的行业标准。因此AUTOSAR有两种含义，一是代表AUTOSAR联盟，二是代表AUTOSAR软件架构。

1.1 AUTOSAR基本原理

        相比传统软件架构，AUTOSAR在上层软件和底层硬件平台之间嵌入标准的中间层，实现了软硬件的解耦。AUTOSAR的口号是标准上协作，实现上竞争。

        通过软硬件解耦，缩短研发周期和降低研发成本，同时通过软件的复用提供研发质量和效率。由于有统一的标准（软件接口，文件交换格式，方法论），因此OEM、供应商、工具提供商等可以协同开发，简化软件系统的集成，软件模块可以复用和高效率的衍生，提高了研发效率，降低整体软件的研发成本。

1.2 基本的AUTOSAR方法

        下图是简化版的AUTOSAR开发工作流。AUTOSAR将应用软件和硬件平台进行解耦，在应用软件和基础软件与硬件之间嵌入虚拟功能总线，应用之间的通信或者访问硬件资源等都是通过虚拟功能总线进行资源交换。在Classic Platform中虚拟功能总线为RTE层，在Adaptive Platform中虚拟功能总线为ARA层。由于AUTOSAR采用自上而下的方法论，从架构设计、接口描述，软件开发，功能组件集成都是采用模型开发。因此可以使用代码生成工具，将SWC描述文件、ECU描述文件、系统约束文件等导入工具后可以生成可执行代码。

1.3 目标

        无论是AP AUTOSAR还是CP AUTOSAR，总体目标是一致的：

• 更好的管理数量增多，功能复杂度增加的汽车ECU

• 改善ECU软件质量和可靠性

• 提升产品升级灵活性，缩短产品推向市场的时间

• 可拓展的架构解决方案

2、AUTOSAR Classic Platform架构

        Classic AUTOSAR将微控制器上的软件抽象为三个软件层：应用程序、运行时环境(RTE)和基本软件(BSW)。其中BSW分为三个主要层：服务层、ECU抽象层和微控制器抽象层。应用与应用之间，以及应用于BSW之间的通信都是经过RTE完成数据交换，因此做到了应用与硬件的完全独立。

        Classic AUTOSAR是分层软件体系结构，软件需求在设计时通过每一层的静态配置来实现。因此，对于运行时的更改，它的灵活性较低，但是这点还是可以接受的，因为这个平台通常在车辆的生命周期内保持稳定，因为被控制的传感器和执行器的应用逻辑不会改变，传感器和执行器仍然履行它们本身的功能。

3、AUTOSAR Adaptive Platform架构

        Adaptive AUTOSAR平台为AUTOSAR应用实现了运行环境ARA。使用两种接口完成数据交换：服务和API。平台由功能集群组成，这些集群按服务和自适应AUTOSAR基础进行分组如下。

        Adaptive AUTOSAR解决了新一代汽车高性能需求、连接性和持续软件无线(OTA)更新带来的新市场需求，它作为多个供应商的软件集成平台，解决了Classic AUTOSAR经典架构的局限性，其为灵活性而设计的，以便在运行时支持软件更改。Adaptive AUTOSAR构建在POSIX操作系统之上，由不同的功能模块组成，这些模块被划分在服务模块和基础模块上,它的的通信是面向服务类型的，会将网络绑定到DDS或者SOME/IP使用以太网与其它ECU通信。

        由于外部系统的发展或功能的改进，在车辆的生命周期中，车辆中的软件需要更改。由于AUTOSAR Classic Platform(CP)标准不能完全解决以上需求，因此，AUTOSAR组织提出了AP平台的标准，AP平台主要提供了高性能的计算和通信机制以及灵活的软件配置，例如支持OTA软件升级。

4、AUTOSAR CP平台与AP平台特性比较

4.1 芯片类型

        CP AUTOSAR一般运行在8bit、16bit、32bit的微控制器（MCU）中，如英飞凌的TC3xx，瑞萨的RH850等。

        AP AUTOSAR可以运行在64bit的高性能处理器（MPU）、CPU等中，如瑞萨的H3，英伟达的Xavier等。除此之外，AP AUTOSAR也可以运行在虚拟硬件上。

        PS：有些公司可能会将某种POSIX OS移植到如TC3xx中，进而在TC3xx中使用AP，这种例子很少见，且不推荐。

4.2 芯片算力

        运行CP AUTOSAR 的芯片算力一般低于1000 DMIPs

        AP AUTOSAR可以运行在算力高于20000 DMIPs的芯片上

        综上，AUTOSAR包含了Classic Platform和Adaptive Platfrom。Adaptive Platform并不是用来取代Classic Platform或者非AUTOSAR平台，而是为了相互兼容，协作并满足未来的需求。

4.3 OS类型

        CP AUTOSAR OS是基于OSEK标准的。

        AP AUTOSAR OS是POSIX OS，且至少应包含PSE51子集

4.4 架构

        CP AUTOSAR是分层的软件架构，有较为明显得上下层关系，如下图所示：

        从下到上依次为：

        1、微控制器层（HW）

        2、基础软件层（BSW）

• 微控制器抽象层

• ECU抽象层

• 服务层

• 复杂驱动

        3、RTE层

        4、Application层

        AP AUTOSAR一般是指ARA（AUTOSAR Runtime for Adaptive Applications），主要由两部分组成（Foundation和Service），如下图所示：

        上图中，所有的模块都称为功能集群（Functional Clusters, FC）。

        上图中，蓝色的FC属于Foundation的部分，橘色的部分属于Service的部分。

        无论是Foundation部分的FC，还是Service部分的FC，都不是上下层关系。

4.5 架构设计原则

        CP AUTOSAR架构设计原则为：

• CP AUTOSAR将于硬件相关的以及通用系统功能定义为BSW模块

• 应用功能定义为独立的软件组件SWC

• RTE分离SWC和BSW

• BSW可配置，并且可以被多个产品线的ECU重复使用

• 不开源

        AP AUTOSAR架构设计原则为：

• 遵循面向服务的架构SOA设计范式（理念）

• 充分利用其他领域软件成熟技术，重用软件市场成熟组件，缩短开发周期

• 充分利用各种开源软件

4.6 开发流程

        开发流程来看，CP与AP都主要都包括以下三个阶段：

• 设计阶段：设计ARXML

• 代码生成：基于ARXML生成代码

• 集成：集成Application，编译调试等

        主要有以下不同：

        在AP AUTOSAR设计阶段，需要进行Service与Manifest的设计，而CP则不用。CP需要进行ECU配置设计，而AP没有ECU配置这个设计项。

        当然，CP 与AP都需要进行系统设计，诊断设计，具体的不同体现在设计时。

        在代码生成时，CP是生成基础软件模块相关的代码，AP生成的是FC相关的代码和Manifest，需要注意的是，AP中不是所有的FC都会生成相关的代码和Manifest。

        集成时，AP AUTOSAR需要考虑 OEM Application Cloud，而CP则不用。

        CP 与AP开发流程如下图所示：

        蓝色虚线框表示CP AUTOSAR的开发流程，绿色表示AP AUTOSAR的开发流程。

        上图中，在代码生成阶段没有体现AP要生成Manifest，实际开发时需要。

        上图中，只是一个简单的整理，并没有涵盖AUTOSAR所有需要设计的内容。

4.7 接口类型

        CP AUTOSAR常用的接口是Sender-Receiver，Client-Server等

        AP AUTOSAR常用的接口是Service Interface等

        当设计CP AUTOSAR与AP AUTOSAR之间的通信时，需要进行信号到服务的转换设计！当前能提供该功能（已经用在具体项目了）的公司只有一家日本公司！

4.8 通信方式

        CP AUTOSAR是基于信号的通信，主要包括CAN、Lin、FlexRay等。

        AP AUTOSAR是面向服务的通信，支持基于以太网的IPC、RPC等。

        CP AUTOSAR虽然可以支持SOME/IP，但是，CP AUTOSAR中SOME/IP只不过是把Sender-Receiver的CAN通信转换成了Client-Server的以太网通信，整个通信链路仍是静态配置的，并不是真正的面向服务的通信。

        这也是为什么AUTOSAR官方说AP AUTOSAR是SOA，但从来不会说CP AUTOSAR是SOA。

4.9 调度方式

        CP AUTOSAR OS采用固定的任务调度配置。在OS Task中调度BSW Main Functions以及SWC的Runnable Entities，按既定规则顺序执行。并协同BSW Modules和App SWC的模式切换。

        AP AUTOSAR 支持多种动态调度策略，配置在运行时完成，配置信息在Manifest文件中体现。

        AP AUTOSAR中与调度相关的模块主要为执行管理（EM）和状态管理（SM），应用程序运行在Process、Thread中。

        CP AUTOSAR中，任务的调度周期可以到us级别。而AP AUTOSAR是在ms（一般是几十上百）级。

4.10 Safety

        根据AUTOSAR官方的说法，在功能安全上，CP AUTOSAR可以支持高达ASIL-D的系统开发。AP可以支持高达ASIL-B的系统开发。

        当然，这并不意味着，使用AP时，最多只能设计出ASIL-B的系统。

        更深的内容就跟功能安全有关了，建议参考以下ISO26262以及CP & AP AUTOSAR与功能安全相关的文档。

        CP AUTOSAR中的Safety机制主要有：

        1、与OS相关的Safety机制：

• 内存保护

• 时序保护

• 硬件保护

        2、E2E保护

        3、看门狗管理器

• Alive 监视

• Deadline 监视

• Logic 监视

        4、硬件诊断

• Core Test

• RAM Test

• Flash Test

        AP AUTOSAR中支持E2E。同时也提供了以下恢复措施：

• 请求SM切换到指定Function Group状态

• 请求EM重新启动指定进程

• 将错误信息转发到应用程序