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分类：
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的标准上是没有很明确的定义的，可由用户去实现。
|
