淡定地撸了一遍AUTOSAR的基本概念

1 AUTOSAR的解决方案

之前的文章《老板说项目要上AUTOSAR，我慌得一批》讲到了，面对日益复杂的汽车E/E架构，在欧洲大地上诞生的AUTOSAR组织，提出了解决方案。

而且做了标准化：

• 软件接口

• 交换格式

• 方法论

首先，其目标要：

软件功能模块在不同车型之间被重用

还有，标准化AUTOSAR的代码配置/建模工具

标准化接口（也可见上图）：

AUTOSAR Interface	“ AUTOSAR Interface”定义了软件组件和/或BSW模块之间交换的信息。该描述独立于特定的编程语言，ECU或网络技术。
Standardized AUTOSAR Interface	“Standardized  AUTOSAR Interface”是其语法和语义在AUTOSAR中标准化的“ AUTOSAR Interface”。“Standardized AUTOSAR Interface”通常用于定义AUTOSAR服务，这是AUTOSAR基本软件向应用程序软件组件提供的标准化服务。
Standardized Interface	“Standardized Interface”是一种在AUTOSAR中标准化的API，无需使用“ AUTOSAR Interface”技术。这些“Standardized Interface”通常是为特定的编程语言（如“ C”）定义的。

交换格式标准化（arxml）

arxml到底长什么样？以下截取一段来熟悉下：

<AUTOSAR>  <AR-PACKAGES>    <AR-PACKAGE>      <SHORT-NAME>DataTypes</SHORT-NAME>      <ELEMENTS>        <IMPLEMENTATION-DATA-TYPE>          <SHORT-NAME>uint8</SHORT-NAME>          <CATEGORY>VALUE</CATEGORY>          <SW-DATA-DEF-PROPS>            <SW-DATA-DEF-PROPS-VARIANTS>              <SW-DATA-DEF-PROPS-CONDITIONAL>                <BASE-TYPE-REF DEST="SW-BASE-TYPE">/DataTypes/BaseTypes/uint8</BASE-TYPE-REF>                <SW-CALIBRATION-ACCESS>NOT-ACCESSIBLE</SW-CALIBRATION-ACCESS>                <DATA-CONSTR-REF DEST="DATA-CONSTR">/DataTypes/DataConstrs/uint8_DataConstr</DATA-CONSTR-REF>              </SW-DATA-DEF-PROPS-CONDITIONAL>            </SW-DATA-DEF-PROPS-VARIANTS>          </SW-DATA-DEF-PROPS>          <TYPE-EMITTER>Platform_Type</TYPE-EMITTER>        </IMPLEMENTATION-DATA-TYPE>
        // 部分内容省略
          </ELEMENTS>        </AR-PACKAGE>      </AR-PACKAGES>    </AR-PACKAGE>  </AR-PACKAGES></AUTOSAR

再来看看其他几个基本概念：

SWC

SWC，即Software Component，是封装了部分或者全部汽车电子功能的模块，其包括了其具体的功能实现以及与对应的描述。

例如，我们可以把Dimmer、Switch、Door Control设计成SWC

SWC分类：

• Atomic component (最小的逻辑单元，无法再分)
• Application（普通应用类）
• Sensor/actuator（给Application提供I/O控制等）
• Composition（可以包含数个SWC的逻辑集合）

Port

Port是SWC之间通信用，算是SWC的组成部分。

Port分两大类：S/R(Sender/Receiver)和C/S(Client/Server)

Runnables

Runnables，即Runnable entities，也是SWC的组成部分，但它是运行在RTE里面，由RTE周期事件触发或者其他事件触发时调用。Runnable包含着实际运行的函数。

2 AUTOSAR的方法论

方法论，可以说是AUTOSAR的灵魂，就像一道菜的配料和方法，如果没有这个方法，那么食材仅仅是食材，而不是一道美味的菜肴。

既然，说方法论是AUTOSAR的灵魂，那么什么能承载这个灵魂，没有载体的灵魂就是孤魂野鬼啊。ARXML就能担此重任。其实，ARXML本质就是XML格式的文本，只是被AUTOSAR组织将其披上一件美丽的外衣。

方法论具体有哪些要求呢？见下图

方法论描述了从系统底层配置到ECU可执行代码产生过程的设计步骤。所以，这个ARXML文件也是挺复杂的。我们先看个图感受下：

这个ARXML关联着整个开发的方方面面

这个开发过程简单抽象起来就像：

抽取其中BSW的配置和生成过程来看看

 

3 AUTOSAR的实时环境

RTE，Run Time Environment实时运行环境，是整个AUTOSAR架构运行的桥梁，各个模块SWC之间的通信不是直接交互的，而是经过该层作为运行的基础，RTE里包含着OS大量的运行策略和服务。RTE也是VFB（Virtual Functional Bus）的实现。

• RTE需要配置(e.g. 把runnables对应到OS的tasks中去)

• 通过RTE的事件触发runnables的运行

• 生成调用runnables的task代码

• 配置OS的一部分 (tasks, events, alarms)

• 实现SWC之间的通信

• 每个ECU的RTE因SWC的需求而异

• RTE抽象了OS，防止SWC直接访问OS和BSW

4 AUTOSAR的基础软件

基础软件，即BSW。从AUTOSAR架构看，中间一层，都是BSW。

细化后

再细化

可以看出，其内容非常丰富，严格遵循着AUTOSAR的各项标准。

BSW抽象程度比较高，包含着许多基础软件。

从图上可以看出，其分了很多类，对应不同的功能。例如Memory、Communication、System等等。

特别一提的是，Complex Driver，是应对比较复杂的驱动的，这个在AUTOSAR的标准上是没有很明确的定义的，可由用户去实现。

Classic Autosar与Adaptive Autosar的比较

当前汽车控制器，如ECU与其他功能或信息娱乐性控制器有明显的不同，基于Autosar经典平台开发的汽车控制器，具有如下特点：

1、硬实时，可在us时间内完成事件的实时处理，硬实时任务必须满足最后期限的限制，以保证系统的可靠运行。

2、高功能安全等级，其可达到ASIL-D的安全等级。

3、对CPU、RAM或Flash等资源具有较低的占用率。

4、软件功能通常是固化不可动态变更的。

而信息娱乐性控制器，则正好与上相反，其一般会占用较大的硬件资源，且一般不具有实时性，因其一般运行在嵌入式PC上，如LINUX，而不是汽车级操作系统上，所以其即使出现故障也不会造成严重的安全事故。而Apdative Autosar则是连接这两者的桥梁，其具有如下特点：

1、软实时，具有毫秒级内的最后期限，且偶尔错过最后期限也不会造成灾难性后果。

2、具有一定的功能安全要求，可达到ASIL-B或更高。

3、与经典平台不同的是，它更适用于多核动态操作系统的高资源环境，如QNX。

Adaptive Autosar与Classic Autosar相比，虽实时性要求有所降低，但在保证一定功能安全等级的基础上，大大提高了对高性能处理能力的支持，以支持智能互联应用功能的开发，因此C++将成为Adaptive Autosar平台的主要开发语言。

Adaptive Autosar的出现并而是针对不同的应用场景升级，Classic Autosar平台支持高安全性和高实时性的应用场景，因此对于深度嵌入式的软件功能需部署运行在经典平台上；而Adaptive Autosar则支持大数据的并行处理，所以对于高性能运算的功能则需要运行在Adaptive平台上。