导读:

因为这些年，AUTOSAR一直在普及，大家也越来越认识到这个AUTOSAR的重要性，所以用的人也非常多，所以这里面我就不去做这个AUTOSAR使用方面的介绍，本文主要还是想从我自己多年从事基础软件开发和用AUTOSAR软件的一些个人感受来谈。

AUTOSAR简介

先简单介绍下AUTOSAR，不论从这个组织架构上，还是涵盖范围上，以及标准实施上。其实AUTOSAR都是一个集大成者，九个核心会员基本上就不变了。他们一直在左右这个AUTOSAR的发展方向。

那其他的会员，也分不同层级，就看这个图上有很多圈儿，有第一层第二层，不同层级都有不同的权限，所以很多公司都想进这个圈。

AUTOSAR发展一直没有停止，基本上每年都会出新版本，从原来的1.0不成熟，到后面的3.0到4.0系列，现在的话已经到这个名字已经不那么叫了，不叫5.0了，叫R20，R21，这个名字就比较时尚了。在官网这些个版本都可以找到，有感兴趣的话可以去下载，比较一下有什么区别。你可以看一下主要的你想关注的部分。

不管怎么变，其实AUTOSAR它的核心思想并没有变，还是三条，第一个就是统一标准，提供一个开放的，一个通的标准文档，大家都可以看，免费的。第二个，就是实现可以分散，它有比较高的层次化和模块化，在结构上和硬件解耦，然后软件，上下层解耦。

经常看到一个口号，就是说AUTOSAR他是以什么方式来实现？标准合作实现来竞争，标准共享，大家凭本事自己去实现，最后来去互相竞争，这个基本上已经达成了共识。

从上图看比较明显，左边的话基本上就是由工具来实现，然后通过配置，还有一些个定义。最后生成代码到右边，是工程师比较较熟的过程了，就是做软件开发的一个基本的过程。

比如说写个自动代码，编译链接，然后后面做处理等等，当然这个反复迭代是是不可避免的，一定要反复迭代，因为很多需求也在变，包括OEM的需求在变，需求一直在变，基本上我们也都司空见惯了（这点是很正常的）。所以看起来是一个比较容易的事情，这种东西其实反复迭代可能好多遍，最后你才生成一个双方都满意的版本。

另外一个AUTOSAR的优点就是文档多，一般做别的开发，就感觉文档比较少，可参考的文档比较少，但是AUTOSAR不一样，它文档就很多，规范的话200多个，需求2600多个.按每页A4纸来算的话，大概有两万多页。高度的话差不多就是两米。他从软件架构、软件需求到软件详细设计，到设计用例。

AUTOSAR的三个主要优点

第一个就是很明显能缩短这个开发时间，如果你不使用AUTOSAR，要开发一个比较复杂系统，你基本上两到三年是要的。用了AUTOSAR的话，最慢半年搞定了，如果快的话可能更短，如果成熟的话。对单个模块开发的话更快，因为AUTOSAR已经帮你做好了，你只需要配一下可能一两周就搞定。

第二个：AUTOSAR他把你的文档架构都已经做好了。剩下后面的工作可能就是配一下，然后整合一下，因为AUTOSAR帮你把文档架构都已经做好了，所以架构师的角色也不需要了，基本上就不用配这个架构师了，开发人员的话，3分之2的人都可以裁掉了，所以看起来维持的几十个人团队，目前看来好像还挺大的，其实相比以前这种开发的话，人数已经少太多了。

第三个就是测试要求降低了，因为代码已经是由工具厂帮你做了，单元测试你可以就不用去做了，你如果需要的话，这些个认证，可以去跟供应商去要。

关于AUTOSAR的未来，图上的A点和B点就不用多说了，基于汽车的智能化发展越来越多，需求也越来越多，功能安全和信息安全也一定会涉及到。AUTOSAR持续更新，那么供应商也一定会提供这些模块。

主要是C点AUTOSAR是高度依赖于工具的，所以后面做的越来越智能，有些工具已经做的就很傻瓜，你默认配置可能就解决了80%的工作，剩下的20%出问题，可能有自动修复就帮你搞定了。

AUTOSAR的弊端

第一个弊端就是贵。这个买过的人都知道它很贵，就是基本上几百万，可能还还收费形式不一样，对针对不同的控制器，针对于不同的芯片项目都不一样。这个很贵。一般小厂的话，好像买这个可能要掂量掂量，因为什么都没产出的话，几百万就花掉了。另外一个，对于不满足需求部分，如果你想去让工具厂商去改，那这个费用也非常高的，而且时间很长。这是它的第一个弊端。

对于控制器来说AUTOSAR有这几个缺点

一，代码量庞大

他代码量特别大。因为它很多这种配置项，除了那些个可以预编译的以外，还会有很多也没有细看过，当然里面很多东西也不知道做什么，反正一个文件一个功能的话，它总是搞得比较复杂，当然从安全的角度是有他的道理的。和一个以前同样功能的控制器相比，代码相当于四到六倍，这个很常见，所以对于flash要求很耗资源。在选的时候，如果你想用AUTOSAR的话，你你可能真的要考虑考虑你的flash要选多大，加上现在的话，因为还有很多双备份刷新，你这个容量肯定翻倍了。

二、选项众多

因为想把这个工具，这个模块做的尽量覆盖所有功能。那么他一定有很多选项，那么你这个项目还要，那个项目不要，那么这些怎么办？你只能通过这种选项来配，所以这些选项特别多。而且有的选项互相牵连，你配错一个别的还配不下去？虽然有些很多东西可以默认，但是依然有很多是让你去自己去控制它的。

三、逻辑比较复杂

因为它里面大量的结构体，套结构体，结构体指针，指针又指向结构体，这个特别多，平时如果只是编译一下Demo虽然可能你用不到。但是量产的话肯定会有问题，有问题要排查，一旦排查起来，对于底层的话就是比较灾难了，就是你要看代码，这个时候因为代码不是自己写的，你就很难去很精确的定位到这个问题，可能配置开始检查，用调制器来来回回调试，所以对于问题的锁定就比较困难。

AUTOSAR的普及对行业的从业者带来了哪些影响？

因为我做这块儿比较久了，所以也接触了很多底层软件工程师，很多人反映说现在这个底层开发已经不像以前了，大部分从一个公司软件工程师，成为了一个工具人，只要你去点点鼠标，用工具去配就可以了。所以导致工程师的成就感不高。

另外一个，MCAL也不用写了。硬件驱动基本上MCAL靠本搞定，那么你不需要再去一行行读这个代码，读这个文档datasheet。大部分工作其实都可以通过这个配置来配出来，基本上他那个MCAL做的都比较智能，所以你配一下，可能下面一堆的这种写寄存器的工作就全部帮你搞定。

那因为第一个第二个，那么第三个特殊需求的开发能力变弱，AUTOSAR让基础软件开发变得高度统一，对工程师的能力要求越来越低，最终让整个行业从0到1的开发能力变低。因为整个AUTOSAR是对这个基础软件负责的，所以看右边这个图的话，AUTOSAR其实是整个在金字塔是偏底下的，也就是说最接近于硬件的，相当于。传统计算机里面的系统软件。

还有这个结构，其实越到下面越需要稳定，这样的话，才能保证上面的稳定，本上面的工作本来就不那么稳定，比如做些刷新，通过FOTA,SOTA更新上面的，那这个时候如果底层不稳定的话，整个系统就不会稳定，你这个控制器做出来肯定要出问题的。最终谁来买单？肯定是用户了，终端用户来买单，所以我觉得这个是个比较大的影响，就是不再有去深究这个技术的人员，而只去图产品开发快。

总结下来的话，有这么两点，第一个就是，个人得不到成长。在软件公司的话就沦为工具。甚至也不需要一些编程经验，所以成就感不足，那么很多人的话就就转型了，就不做这个了，去做比较热门的行业，比如说自动驾驶，或者说你想做一些算法。

第二个是AUTOSAR标准和实现基本上都在国外，主要是欧洲几个大公司，这基本上几个大公司都知道，国内也遇到这个问题，国内有几家的话也在做这个AUTOSAR开发，但是相比国外的话还有点差距，因为毕竟国外人比较多，一般做一个项目上千人做很久，国内的话。我还没有见到上千开发AUTOSAR的，可能搞个大几十人，就不错了。而且AUTOSAR要求比较高，看起来他好像就一个模块一个模块独立，其实并不是。就好像你去组织上千去去盖楼一样。你没有这方面建筑基础的话，你可能盖的都是平房，你想盖个摩天大厦的话，你得有很好的架构设计师，这块也是国内比较缺失的。没有之前那些积累的话，慢慢的话可能对国内的汽车基础软件是个影响。可能存在这种什么卡脖子的情况。大家现在被芯片搞得都比较担心了。虽然现在看起来好像这个问题没那么突出，但是我猜想可能这个问题早晚会凸显出来。除非像华为一样，他能够组织大量人力，有那么多有丰富的公司来做AUTOSAR。

针对以上弊端对工程师有哪些要求？避免成为工具人呢？

第一个，我们首先得承认AUTOSAR确实是个好东西，因为它的整个思想体系，还有一些文档都非常成熟，它是集世界上各大主机的思想于一体，很多需求都是他们提出来的，所以要做的话，其实还是要好好学习一下AUTOSAR。

尤其你如果想从事哪一部分的话，你要把这块读深入。真的读懂，而不是把那个文档去读一读，可能你真的要读需求，读文档。再读某家公司的代码，最后再反向思考去想一想，如果让你来写，如何写这个代码。这样长期积累下来，你才能不至于落后，你还是一个工程师。

第二个，AUTOSAR的需求，特别清晰。虽然很多描述的语言不多，每一个方格儿，那么里边还是比较清晰的，而且每个需求都有实现和详细设计对应。

第三个就是一个方法论的事情。AUTOSAR不仅是AUTOSAR的软件开发这么做。它里面更多地体现了一些似于哲学思想在里面。所以你把这些个慢慢积累起来的话，你也会树立一个正确的开发方法论，这对于你以后开发新的东西就有很好的指导作用，你也就知道应该怎么正向开发，应该先做什么，后做什么，给别人提供什么文档。

第四个接口比较明确。比如说每个接口定义很清楚，输出还有包含关系很明确，他每一个模块都有相互包含的文件，头文件包含关系非常清晰，之前是没有人整理的，而且这么大规模整理是没有的。所以最简单做法就是头文件全包含，看起来也编译肯定没问题，但是终不是规范的做法。

如果坚持想要做软件工程师的话，我觉得这六点还是要坚持下来

第一个：一定要有团队合作精神，交流分享，我觉得这个很重要，这个看起来和软件并没有关系，但是它是指导整个软件的一个大方向。因为有有些公司的这块文化，可能就不怎么交流。自己做一块儿，那么反正别人也不知道，我也只会这一块儿的话，比如说有什么事情耽搁，那你只能自己上，因为你的东西在你自己电脑上，那你不加班别人也没法替你加班。那还有的，就是在部门之间也要合作，有的公司连硬件原图都不给软件工程师的话，其实原理图的话是个很好的交互语言，这个语言不用，然后非要去写那个上百页的HSI软件，这个文档哪搞来搞去，搞来搞去，去耽误时间，觉得又没什么用。所以团队合作非常重要。

第二个是从一开始设计的时候，你要考虑这个软件是可能工程化量产，是不是有变形项目，还有多少配置可以去选择，这些个留出来，对以后升级做准备。不要一下子把这个接口定死，或者说就写成一个比较死的常量放那里。

第三个，既然是软件公司，这里提到软件不提编程好像说不过去，那么编程的话肯定要有，这就需要有长期的积累。

常用的话，现在其实底层主要是这个C语言，还有python，一些脚本语言，这些都会用到，这些个会很好的帮你去解决很多问题。做一些个小工具等等都不错。要理解一个问题，用多角度去理解，你考虑比较全面一点。往往我们可能只针对一个需求去做，还是从一个全面的，虽然作为基础软件底层工程师，还是要对整个硬件系统，整个物理世界。要比较清楚一点，这样的话你才知道你这个开发初衷到底是怎么做。

反正我看那个文档，国内大部分写的都觉得不太好。那你再看那个AUTOSAR文档，他确实写得很好，每一个都是很多页，而且没有什么太多的废话。所以当然这和国内环境有关系，因为很多公司是不留给文档写作时间的，其实文档占了整个开发很大一部分工作量，一定要把这部分时间留出来。有意识的去创造这么一个环境，可能就不是我们所能做到的，需要这个上面层面来支持这个事。

最后一个是测试，自己不做测试，扔给测试团队，有些东西，自己还要测一测的，因为你做开发之后，你不测的话，你真的不知道正确与否。那只有这种不断的测试，你开发的，测试自己去做，相当于就有这么一个PDCA的一个循环过程，不断提高自我。

关于修改静态代码

我们常说AUTOSAR，它分为静态代码和配置代码，静态代码的话就不需要修改，这个其实不绝对。因为需求，如果他那些已经提到的需求，他肯定覆盖到了，你认为他全覆盖到了，但是。这个世界上往往有例外，终归有需求它覆盖不到，那这个怎么办？你如果去找原厂去修改，那个时间又长费用又贵，其实也没几句话。这时候，你就要做到敢于去修改代码，敢于去看，当然你不要这种很盲目的，还要做到胆大心细，你要做好理解，做好文档，做好测试，整个你能想到全部做完了，这些个也满足你需求了，其实你可以改的。不要怕这种承担责任。因为一旦改了，这些公司说你改代码我就不管了。其实这个是不负责的。比如说有些个厂商要求CAN ID动态更改。这个没法去配。你只能自己去改。

还有大部分应该说现在的AUTOSAR底层，都没有个标定功能，但是有的公司就要求，因为他改这个东西，可能就不用去修改代码了，不用修改不用去编译了，可能改几个标定量就不用重新配了，那这个工作就是客户需求，也不是过分的需求，说怎么办？那还需要改。

第三个企标，每家企标大同小异，但是差异化部分也需要自己修改等等，包括复杂驱动，所以说我觉得还是要去敢于去修改这段代码。不要把AUTOSAR特别神秘化。

最后分享一下AUTOSAR技术交流群中对AUTOSAR的独到见解：

狭义上的autosar指的是依赖etas vector等工具软件支撑的配置开发（它让你怎么做，按套路来就行），广义上的autosar指所有能够把应用层，底层，芯片按模块区分，把静态代码和配置代码充分结构的编程方法。也就是说，即使不依赖任何工具，只要有这样一个开发目标，自己是可以构造出一套软件架构的，在此过程中可以参考autosar规范文档或者第三方的成熟代码，选择性的应用。只要最终能高效的做好项目软件，满足客户要求，就是autosar。