AUTOSAR是AUTomotive Open Systems ARchitecture的缩写，核心成员由欧洲、美国等大型OEM和头部Tier 1组成，包括大众、宝马、博世、大陆等。其意在定义一套标准的汽车电子软件架构方案，以便应用于不同的平台，提高软件复用，降低开发成本。自从2003年AUTOSAR成立以来，已经走过了十几个年头，认可和吐槽的声音同在，但是站在行业内部来看，使用的厂商也越来越多，国内外传统供应商、主流OEM、亦或是跨界玩家华为都开始在引入AUTOSAR架构。AUTOSAR到底能否像其初衷一样，给汽车电子的开发带来便利，还是说是一种累赘。今天站在行业从业者的角度，来窥探一下AUTOSAR的利弊。1、AUTOSAR提倡的软件分层、模块化、封装，如图1所示，将软件分层协议栈、硬件、系统服务、应用层四大块，这样的好处在于当硬件需要进行更新迭代的时候，软件移植的时间成本、人力成本会有相应的减小，提高软件的复用度。例如在实际的项目中，通常过个几年需要升级主控MCU，通常只需要更改MCAL和OS就行。2、接口的标准化。一方面如上述所说，有利于降低软件的移植成本，另外在供应商和多家OEM进行软件合作的情况下，如果都遵循AUTOSAR标准接口，那供应商在平台软件的基础上，所需的适配工作量会有相应的减少。
3、目前AUTOSAR基础软件，都是基于工具生成代码，首先代码质量方面有一定的保证(虽然现在主流的工具厂商的静态代码也有bug)。
4、对于主机厂而言，目前新能源车的三电都有自主开发的想法，而当前的组织架构通常是BMS、VCU、MCU在三个不同的科室，如果在自主开发过程中都采用AUTOSAR架构，这样就可以集中BMS、VCU、MCU的开发人员一起开发，集思广益，减少自主开发的风险。5、对于用人公司而言，以前找嵌入式开发人员，来做基础软件开发，工程师来了得消化祖传代码，通常都会缺乏文档，这个过程通常无比难受。如果采用AUTOSAR架构的话，直接招聘有相应工作经验的，以前的工作经验的复用程度更高，融入到新工作的时间很有明显的减少。6、AUTOSAR是一个符合ISO26262标准的软件架构，从ISO26262的第6部分的7.4章节，可以看出，功能安全要求软件架构具有模块化、封装、简单的属性。另外在7.4.11和7.4.14提到的软件安全机制中，需要软件能进行内存分区，对不同ASIL等级的模块进行内存隔离，另外还需要实现控制流监控，这些在AUTOSAR架构中，都可以相对比较简单的实现。AUTOSAR的引入确实能带来不少好处，但是也要克服其带来的一些不足。1、出现问题排查麻烦。一方面代码不是工程师写的，工程师需要熟悉工具静态代码的实现逻辑，才能很好排Bug，而且如果需要了解某些模块在特定场景下的实现方案，这些只能自己抠代码，工具厂商的技术支持人员通常给不了啥支持。不过这些被坑多了，也就慢慢懂了。2、集成效率差，尤其是在项目的需求在频繁变更的情况下，例如常见的dbc变更，dbc一变更，60%~70%的基础软件要重新做一遍，简直是噩梦，而且还容易出错，不过目前大部分也在考虑用自动化脚本直接操作armxl文件，解决这种重复性的工作。
3、资源消耗大。AUTOSAR的代码很耗Flash资源，可能这也是模块化、分层的代价吧。不过随着随着汽车电子的MCU逐渐强大，以及刷新方法采用速度更快的方式，资源的消耗不是啥大问题。
对于AUTOSAR的利弊就讲到这里吧。AUTOSAR的使用目前还在发展阶段，以后能发展到什么程度，需要大家一起努力，我们拭目以待。
|
