AUTOSAR简介

1. 简介

AUTOSAR全称为“AUTomotive Open System ARchitecture”，译为“汽车开放系统体系结构”；
AUTOSAR是一家由汽车电子、半导体和软件行业的汽车制造商、供应商、服务提供商等公司组成的全球开发合作伙伴组织；
AUTOSAR定义了三个文档组：Classic Platform(CP)、Adaptive Platform(AP)和Foundation(FO)，基于CP和AP的ECU基于共同标准FO实现彼此连接；

来自一个技术人的学习建议：
Q：初次学习AUTOSAR应该从哪些文件入手呢？
A：AUTOSAR是一个庞大的标准，包含了超过200份规范和20000个需求。建议从阅读标准中的Layed Software Architecture文档入手。接下来可以学习AUTOSAR方法论规范（Methodology）。在接下来就是有选择性的阅读AUTOSAR模板规范（TPS）和BSW的软件规范（SWS）了。

2. AUTOSAR核心思想

AUTOSAR提倡“在标准上合作，在实现上竞争”原则；
AUTOSAR核心思想是“统一标准，分散实现、集中配置”，即统一的开放平台、软件系统层次化模块化，降低应用与平台耦合性、统一格式的配置信息，集中配置生成系统；
一个汽车电子应用系统可包含多个相互关联的AUTOSAR组件。组件通过虚拟功能总线（VFB）提供标准通信机制与服务，实现平台无关性；

3. AUTOSAR功能

主要功能，如下图所示：

• 汽车功能可用性与安全性需求
• 保持汽车电子系统一定冗余；
• 可移植到不同汽车的不同平台；
• 将标准的基本系统功能转化为标准软件模块；
• 通过网络共享软件功能；
• 集成多个开发商提供的软件模块；
• 更好的进行软件维护；
• 充分利用硬件平台处理能力；
• 汽车电子软件的更新与升级；

AUTOSAR在汽车领域的应用，如下图所示：

AUTOSAR模块功能，如下图所示：

4. AUTOSAR标准分类

4.1 Classic Platform(CP)

CP框架进行方法(软件开发作业的流程和输入输出的形式的定义)以及应用程序接口(API)的标准化；
CP架构在最高抽象级别上区分了在微控制器上运行的三个软件层：应用程序、运行时环境 （RTE） 和基本软件 （BSW）：

• 应用软件层大多独立于硬件；
• 软件组件之间的通信通过RTE访问BSW；
• RTE表示应用程序的完整接口；
• BSW分为三个主要层和复杂驱动因素：服务、ECU抽象、微控制器抽象，服务分为代表系统、内存、通信服务基础结构；
  

4.2 Adaptive Platform(AP)

AP实现了 AUTOSAR Runtime for Adaptive Applications （ARA）；
Adaptive标准主要针对自动驾驶和娱乐系统应用相关的标准；
AP有两种类型的接口可用：服务和 API；
AP模块结构，如下图所示：

AP功能概述（图片来源于“搞一下汽车电子”）：

4.3 Foundation(FO)

FO目的是在 AUTOSAR 平台之间实现互操作性；
FO包含AUTOSAR平台之间共享的常见要求和技术规范；

4.4 Acceptance Test Classic Platform(AT)

4.5 Application Interface（AI）

5. AUTOSAR 软件架构

5.1 应用层

应用层包括应用软件组件、传感器、执行器软件组件；
应用层软件组件通过RTE进行内部通信和ECU资源访问；

5.2 运行环境层

RTE层与ECU、具体应用相关，应该为每个ECU分别实现；
RTE层为组件之间的通信提供了支持；
RTE层实现应用软件与硬件的无关性；

5.3 系统服务层

系统服务层包括通信、服务、操作系统，如操作系统服务、汽车网络管理、管理服务、存储服务、诊断服务、ECU状态管理；
系统服务层的实现与微控制器、ECU、具体应用相关；

5.3.1 操作系统

AUTOSAR操作系统不但以OSEK/VDX系统作为基础，同时也做了功能扩展，如下：

• 核心功能添加了软硬件计数器、带有时间同步的任务表、堆栈监控功能；
• 保护功能添加了时间同步保障、内存保护、服务保护、操作系统应用（任务执行、中断、延时、确定功能）、确定与非确定代码功能；
  ->时间同步保障：实现系统任务表时间同步、对芯片时间片的静态分配；
  ->内存保护：堆栈、私有数据、代码端的保护，分离不同应用程序在内存的物理位置；
  ->服务保护：避免错误、破坏性的系统调用；
  ->确定与非确定代码功能：确定代码可五点调用系统应用，不确定代码只能在一定限制下调用；

操作系统的扩展属性分级，如下：

• 扩展等级1：运用于普通的实时操作系统，包括任务管理、事件触发机制、计数、定时、消息传递等；
• 扩展等级2：OSEK系统和时间同步保障，有响应快、延时少、精准度搞；
• 扩展等级3：OSEK系统和内存保护，保障系统运行中不发生内存冲突；
• 扩展等级4：OSEK系统和时间同步保障、内存保护系统组成；

操作系统实现要求，如下：

• 静态配置；
• 实时系统特性；
• 优先级机制；
• 运行可靠，有自维护功能；
• 系统开销小，不需要外部资源；

5.4 微控制器抽象层

微控制器抽象层实现的不同硬件接口的统一，实现了对硬件的封装；
微控制器抽象层包括控制器驱动、管理微控制器的外设，如DIO、ADC、PWM、EEPROM、Flash、CCU、SPI、I2C等驱动；

5.5 复杂驱动模块

复杂驱动模块是复杂传感器和执行器操作模块的映射；

6. 软件框架

软件框架包括SWC、RTE、BS三个模块，模块定义如下：
SWC：应用层软件标准的定义；
RTE：应用层和基础层的接口；
BS：硬件驱动、网络通信、实时任务调度等底层服务程序,:BS又分为以下4个部分：

• 服务层
• ECU抽象层
• 微控制器层
• 复杂驱动层

软件架构的详细划分，如下图所示：

6.1 SWC

6.1.1 SWC概念

SWC是封装的、规范的、可重用的软件模块；
SWC是组织系统的基础单位；
SWC由核心功能（构建功能执行代码）、端口（输入端口和输出端口）、接口（VFB支持的两种通信接口，C/S通信接口和S/R通信接口）组成，如下图所示：

• AUTOSAR一个功能可由多个SWC组成；
• 每个SWC封装某个应用的部分功能；
• 所有的SWC都必须映射到唯一的物理ECU中；

SWC功能**<示例>**，如下图所示：

6.1.2 SWC要求

• 所需数据与所能提供数据
• 运行时需要的系统资源
• 对基础硬件和软件的要求
• 实现的功能

6.1.3 SWC独立性

• MCU型号无关
• 映射方式无关
• 与其他SWC位置无关
• 与系统中的SWC个数无关

6.2 RTE

RTE是ECU内部和ECU之间的信息交互中心；
RTE提供了通信抽象层，相同的接口与服务让不同ECU内部模块及ECU之间实现信息共享；
RTE将针对特定的ECU或系统配置进行裁剪（具体要求视ECU而定）；

6.3 BS

BS为SWC提供了基本服务；
BS处理标准规范和ECU自带功能模块，还包括服务（诊断协议、NVRAM、Flash和内存管理）、通信（网络框架（CAN、LIN、FlexRay）、I/O管理、网络管理）等；
BS结构，如下图所示：

注：OSEK基础标准包括：实时操作系统（OSEK-OS）、通信子系统（OSEK-COM）、网络管理系统（OSEK-NM）；

6.4 VFB

VFB将软件构件间、软件构件与基础软件间的通信进行了抽象；
VFB是虚拟硬件和独立映射系统的集合；
VFB为构件提供了标准的通信机制和服务；
VFB包含SWC标准化接口、设备驱动（底层软件中实现）、ECU抽象层（底层软件中实现）、AUTOSAR服务（底层软件中实现）；
VFE的特点，如下：

• 所有的VFB都连接在VFB上；
• VFB保证SWC之间、SWC与ECU之间的可靠通信；
• VFB是SWC独立于硬件的基础；
• VFB简化了SWC的设计；
  VFB通信方式，如下：

1. C-S通信
   
2. S-R通信
   

VFB结构原理图，如下所示：

7. AUTOSAR接口分类

AUTOSAR支持三种不同的接口，分别是AUOSAR接口、标准化AUTOSAR接口、标准化接口；如下图所示：

AUOSAR接口：描述原件接收和发送的数据和服务；
标准AUOSAR接口：AUOSAR框架定义的接口；
标准化接口：软件中具有的API；

基于AUTOSAR的ECU软件结构，如下图所示：

8. 规范与标准

8.1 SOME/IP

1. AUTOSAR_PRS_SOMEIPProtocol.pdf
   Scalable service-Oriented MiddlewarE over IP简称为SOME/IP，译为“基于IP可扩展的服务中间件”；
   属于AUTOSAR Foundation（FO）部分；
   该文档定义了SOME/IP协议规范，包括消息格式、传输标准等。

2. AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol.pdf
   SOMEIP Service Discovery简称为SOME/IP-SD，译为“SOME/IP服务发现”；
   属于AUTOSAR Foundation（FO）部分；
   该文档定义了SOME/IP-SD协议规范，SOME/IP-SD是基于SOME/IP进行实现的。

3. AUTOSAR_SWS_SOMEIPTransportProtocol.pdf
   SOME IP Transport Protocol简称为SOME/IP-TP，译为“SOME/IP传输协议”;
   属于AUTOSAR Classic Platform（CP）部分；
   该文档定义了大SOME/IP数据包的分段与重组规范，以及SOME/IP-TP实现方法与接口标准。

4. AUTOSAR_SWS_SOMEIPTransformer.pdf
   SOME IP Transformer简称为SOME/IP Transformer，译为“SOME/IP装换器”；
   属于AUTOSAR Classic Platform（CP）部分，是对“序列化”部分的一个补充；
   该文档定义Transformer的实现，实现可配置的数据序列化和反序列化；

5. AUTOSAR_SWS_ServiceDiscovery.pdf
   Service Discovery简称SD，译为“服务发现”；
   属于AUTOSAR Classic Platform（CP）部分；
   定义了AUTOSAR的SD软件规范；

6. AUTOSAR_PRS_TestabilityProtocolAndServicePrimitives.pdf
   Test ability Protocol And Service Primitives译为“测试能力协议和服务原语”；
   UpperTester简称为UT，译为“上限测试”；
   属于AUTOSAR Classic Platform（CP）部分；
   该文档定义了UT基于以太网传输的通信指令格式，该控制指令默认使用的是UDP:1000进行传输，指令格式使用类似SOME/IP的格式进行封装。
   汽车以太网测试之UpperTester

参考文章

汽车电子与软件 - 系列分享
详解AUTOSAR分层架构与软件组件
该文章中的绝大部分内容来自：微信读书《汽车嵌入式系统原理、设计与实现》- AUTOSAR体系简介，此处仅仅作为一个知识的传播；