AUTOSAR_BSW03_五千字字长文解说AutoSAR，看完了你会有系统的了解

AUTOSAR_BSW03_五千字字长文解说AutoSAR，看完了你会有系统的了解

一直在想，文章不应该是长篇大论，文章的首要目的一定得是有趣，得让人发自内心的想要看下去，就好像我的偶像赵本山的小品一样。

技术文章也一样。

我尽我所能写的有趣、通俗、易懂，让你看了一遍之后，对于标题的内容有大致的印象。

当然建议大家不要死记硬背，理解至上，想不通的时候就回来翻翻，我也一样。就像一本笔记；

正文开始：

网上介绍autosar 发展史的已经很多了！

但是很多都是流水账，既然是流水账，就没有什么参考的意义，我觉得脱出了我们大部分人想看的目的。

看历史的目的应该是以史为鉴，知道来源，以便于对于autosar的内涵理解的更加透彻！！！

那我接下来从结构方面介绍下autosar的发展史；

0.啥是autosar？明白不？

1.为什么会有autosar？

2.autosar的出现做到了什么？对市场有什么改变？

3.接触autosar的目的是什么？

4.autosar的本质以及同生活的结合。

5.工作中想问问大家，工作中是否都能接触到autosar？

附赠自动驾驶最全的学习资料和量产经验：链接

0.啥是autosar？明白不？

官方术语：AUTOSAR 就是AUTomotive Open System ARchitecture的简称，中文翻译就是汽车开放系统架构

开放的理解：谁都能用；（只要你用得起，购买一套架构至少都是百万RMB起）

说人话：

将汽车电子控制单元（ECU）的软件底层做了一个标准的封装。使得大家都能共用一套底层软件，只需要修改其中的一些参数，就可以匹配不同硬件，也可以匹配不同的应用层软件。如此之后，用户只需要专心负责应用层功能开发即可，底层都交给AutoSAR工程师就行了。

1.为什么会有autosar？

举个例子，原来你想支持针对CAN收发器A 芯片写一套协议，你从甲公司花了一两年写了一套，也许勉勉强强能用，忽忽悠悠可以通信，，，

你觉得自己厉害了，你跳槽了，到了乙公司，用了一个CAN收发器B，你发现甲公司写好的东西，到了这完全不能用，能用的只有C语言的关键字和结构语句。。。。

于是你蒙了，一切都要重头再来；；；

你觉得没听懂？ 啥是收发器？

好吧，换个思路，结合生活举个例子；

想象一下，汽车制造行业就像是一个繁忙的厨房，而每一辆汽车就是一道复杂且精致的菜肴。在这个厨房里，有各种各样的厨师（即汽车制造商和供应商），他们各自擅长不同的烹饪技巧（即不同的汽车电子系统技术），但他们都需要遵循一定的规范和流程来确保菜肴（即汽车）的质量和一致性。

再拿CAN 来说，底层的CAN协议，逃不开数据的收发和传递，速率几乎又是确定的。

因此，各家厂商如果都把精力花在CAN的底层开发上，岂不是很亏，因为既没有任何经济效益，也不会有利于企业发展。毕竟CAN协议是开放且透明的。

所以，不如把更多精力花在应用层的算法和控制逻辑上（炒菜的火候控制和菜品的制定）而不是说，花在餐具的雕花上。毕竟一把炒菜的铲子，你翻出花了，他的功能也是很单一的炒菜。类似于，can通讯你写出花来，也是保持固定的速率和其他VCU通讯。

这就是AUTOSAR 存在的意义——呼吁大家不要在铲子上雕花了！！大家都去想想怎么搞出更好吃的菜吧！！那才是最主要的。

这也就是Autosar的口号：

从标准上合作，在实现上竞争！！

这一点，autosar联盟真的做到了。

目前市面上，但是是控制领域的ECU 几乎都是通用类Autosar架构、大家都不再重复造轮子。而是去研究应用领域的算法和控制、。

(好吧，我就是一个雕花的工具人。)

有了以上的知识铺垫，相信你对于autosar的目的已经有了大概 的了解。

下面的内容咱们就聊聊它咋实现的。

2.autosar的出现做到了什么？对市场有什么改变？

首先，这个事情需要世界上大多数汽车厂家和供应商一起参与，要不搞不起来。

实际上天下苦秦久矣，很多人都希望这一点，大家都联合起来， 又想起那句口号！全世界汽车厂家联合起来！大家一起降低成本，一起赚钱！

哪些人联合起来了？

如图 基本上世界上大一点的汽车厂和Tier1 供应商都参与进来了（就是一级供应商，直接给主机厂供货的）

他们联合起来干了啥？

总结起来制定了一整套的底层标准。

如下图：

说白了就是，哎呀，大家都不要瞎特么写驱动啦，搞得我写的你看不懂，你写的我看不懂。

就好像支持TyPEC协议的手机都可以用同一根充电线一样；

大家都按照这套标准来写底层代码，只要你符合了这套标准，那么大家的ECU 产品就都是想通的，

统一这个标准很难办，花了很多年，至今也有二十多年了。

二十多年干了啥？

不断完善下面这个图的细节内容：

但是，但是来了，这里说的，其实是标准，就是思想框架，真正的实现代码， 是每家公司都能写出来的吗？

当然不是；看图说话；

z

整套标准的要求之严格，联系之紧密，远超你的想象。

严格到普通的厂家想写出来难如登天，只有专门研究autosar的厂家才能写出这套完善的架构。

目前市面上，仅有有限的几家成熟的autosar产品公司。

例如

Vector

西门子的Mnetor 工具商，

国内据我所知也有在研究autosar底层实现的，例如经纬恒润等。不过暂无新闻。

所以说，现如今大部分的控制器和整车厂家，都基本是Autosar 的应用工程师。而不是开发。

应用什么呢？？ 根据这套标准，写出来的工具包，我们到底怎么用？效率怎么提高的？

我们接着往下聊。

先总结下：

使用AutoSAR前的状态

1、原始状态

也就是大家经常使用的敲代码法，目前也有一部分简单的ECU（汽车电子单元，简单的说就是汽车上的某个控制器，比如锂电池管理单元BMS、电机控制单元MCU都可以叫做ECU）在使用这种方式开发，缺点比较明显，主要就是软硬件耦合严重导致的，可以归结为以下：

1. 开发效率低下

2. 开发周期长

3. 代码合作开发难、维护难

4. 可重用性差（例如更换硬件平台后，代码几乎是需要重新开写的）

5. 随着代码量的增加，代码质量也随之下降

2、进阶状态

在代码法的基础上，通过有经验的架构师做出一套优化架构，并且结合一些操作系统（OS）对代码进行封装，这样一来便可以大大降低代码法的很多弊端，一名好的架构师设计出来的架构往往可以起到几倍到十几倍的效率增幅，不过缺点仍然有：

1. 对于不同的客户，由于各家客户需求不同，重用性依然不好

2. 软件耦合也会存在，同时该方法的优劣和架构师的能力直接挂钩

如下图是在AuotSAR以前常用的OSEK架构，对比后面图片的AutoSAR架构，可以看出OSEK的耦合还是挺严重的

四、使用AutoSAR后的状态

1、软硬件隔离

大家经常能看到的下图能很形象的说明这一点，隔离后的好处就是不管你用NXP的还是英飞凌的亦或者是TI的；不管你的硬件是怎么设计的，我们都不用修改我们的代码，只需要配置一下AutoSAR，告诉它我换硬件了，然后AutoSAR帮你匹配硬件。当然，实际操作起来还是需要对AuoSAR配置的熟练掌握

可以说，通过Autosar 让底层开发变成了一件很简单，效率非常高的事情。

3.接触autosar的目的是什么？

自然是为了理解、使用、提高工作效率。

这个话题很大，现如今，我们步入工作接触Autosar，已经不会再去管它有多么光辉的历史了，

我们考虑的就是眼前**，怎么把这个工具用好、配置好。这是核心中的核心**

就好像现如今的人们，都会用智能手机，不过已经没有人关注从电话到智能手机的发展过程。

我们继续。

架构上来讲，首先我们来看一张整体的架构图，以后我们会在这张图上细分和深入，添加细节来补充完整。首先就能看出AutoSAR主要分为3个层级：应用软件层

（AppL），实时运行环境（RTE）和基础软件层（BSW）

应用软件层主要就是用来存放我们自己的代码的地方（这就是前面提到的，在实现上竞争，主要的实现就是APPL算法的开发，也就是说，算法工程师不必在意底层架构，完全可以随心所欲实现自己想要的内容。只要不超出底层给出的API 功能）

实时运行环境是提供应用层所需的资源，同时将应用层和底层隔离。

基础软件层是将硬件做封装，一直封装到一个标准的操作系统的状态，以便上层可以标准化调用系统服务，这里又分几个部分，

上图中应用层和BSW层都比其他层大一些，这是因为它们两还可以再做细分，接下来我们看下面这张图，我们将应用层和基础软件层做了细分，就这几层现在做分别的讨论：

应用软件层

该层是由一个一个SWC组成的，每个SWC咱们可以理解为一个.c文件，而整个应用软件层就是一个文件夹。用下面这张图应该很好的说明了对应关系：

1. 图中右边的工程只是为了大家理解建立的一个样板，与Vector的实际工程还有很大区别，将会在后续章节中讲到

2. composition SWC和其他更加详细的说明会在后面讲

3. 可以看出：这里的整个工程就是我们的AutoSAR架构，而其中的AppL、RTE和BSW都分别对应一个文件夹，而我们的SWC组件就是一个一个的.c文件（和.h）

实时运行环境

做一个不太恰当的比喻：把BSW比作我们的windows系统，AppL就是开发的应用软件，而RTE更像是一个虚拟机，将上层应用和底层操作系统隔绝开的同时，又兼容了不同厂商开发的软件。（实际上更像是电话转接员的工作，这里在后面讨论）

基础软件层

基础软件层又分为4大部分：

1. 硬件抽象层（MCAL）：可能用过STM32的童鞋应该都知道库的概念，硬件抽象层又叫MCAL，就是将芯片的寄存器操作都封装成一个AutoSAR规定的统一的库Api。就是说这套Api是不同厂商都支持的，但是底层怎么实现，就是芯片厂商的事了。同时也有软件工具EB，可以通过界面配置MCAL功能

2. ECU抽象层：如果说MCAL只封装了芯片，那么ECU抽象层就是将硬件上所有的硬件都进行了封装。比如我们的控制器上有一个主芯片英飞凌的TC275，还有采样电路，电源电路，CAN电路等等。而MCAL就是封装了芯片上有的功能。而ECU抽象层就是将所有的这些都做一个统一的封装。所以不管硬件是如何实现的，这里封装后，也形成了统一的Api

3. 服务层：这里有是更加高级的一层了，服务层里是包含操作系统（OS）的。OS将使用ECU抽象层的Api，再对上层暴露出服务接口，其实就是嵌入式实时操作系统（RTOS）所作的工作。

4. 复杂驱动：又叫做CDD，主要工作是将AutoSAR未定义的一些功能封装起来，给应用层提供接口来调用这些功能。（简单说就是其他的概念）

Autosar 开发工具链上

上面简单提过，有Vector 等等，这里从软件层面聊下；

目前主要是2大流派：

• MATLAB +DaVinci（国内主流，参考书籍有《基于AUTOSAR规范的车用电机控制器软件开发》）

• MATLAB +ETAS（博世和联电主要用这个，参考书籍有《AUTOSAR规范与车用控制器软件开发》）

这里我们就选国内常用的Matlab（MathWork） +DaVinci（Vector）来详细说明一下：

Matlab：

大家应该都很熟悉了，主要是用Simulink做代码生成的，就是我们的应用层软件就需要Matlab来开发，当然手写也是可以的，不过弊端就很多

了，这个看预算和需求吧

DaVinci Developer： 主要用来设计AppL的程序架构

DaVinci Configurator pro： 主要用来配置BSW和自动生成RTE的

EB Tresos： 主要用来配置MCAL的，可以兼容英飞凌和恩智浦的芯片. （可见并不是支持市面上所有的芯片)

Vector还有其他的一系列的工具：比如Canoe、Canape等，这里就暂时略过。

4.autosar的本质以及同生活的结合。

Autosar的本质，应该说就是分层的概念和我们生活息息相关。

你在用鼠标的时候，你会考虑鼠标的信息流是如何和电脑结合的吗？ 不用的

你在吹空调的时候会考虑空调系统是怎么运作的吗？实则不需要：你只要掌握几个按钮的意思就够了。

工作中用上这种分层的概念可以提高工作效率；

例如，你可以把常用的数据信息封装成一个sheet集合，而不是在每次需要的时候到处找；

例如，你在工作拆解任何的时候，就可以用下分级的概念，先做完底层重复工作，再借用上级任何调用重复工作。

比如，python ，很多时候用的就是分层概念，它把重复的工作封装成一个功能了；对！ 这句话很经典，autosar就是把重复的底层驱动撰写工作封装到一起了！！！！