|
以我有限的认知和体验来谈谈堂堂AUTOSAR的一些弊端，也不敢说是弊端，只能说是局限性吧。还请轻拍。
在此之前我先说说目前AUTOSAR在市面上使用的几种情况：
一种是号称的AUTOSAR，在AUTOSAR概念刚刚兴起的时候，不管是国内国外的汽车零部件厂商或者大小软件服务商在宣传语上都会宣传基于AUTOSAR架构，这种状况就像现在所有厂商都会宣传自己是符合功能安全一样。我此前在一个软件咨询公司待过，那会儿刚刚开始研究AUTOSAR的资料，还没有做项目，公司的页面就已经把我们软件是基于AUTOSAR开发的作为宣传了。这种情况很常见，我见过很多项目，软件部分是外包的，不管这个项目的预算多少，项目是否必要，技术要求上都会无脑将AUTOSAR，功能安全各种要求堆放上去，但因为主导此项目的人并不了解AUTOSAR或者功能安全的要求，软件外包服务商基本上在交付文档上借用AUTOSAR的一张图，介绍一下AUTOSAR的基本概念，软件交付的工程结构勉强有个AUTOSAR的分层结构就算过关了。造成这种现象也是有原因的，国内主机厂好面子，供应商为了生存，就形成了畸形供需的状况，总不能所有大小项目都被几个零部件巨头都承包了，现在这几个巨头依托于AUTOSAR和功能安全已经赚的金箔满盆，而且有越来越难伺候的趋势。
一种是购买了完整的工具链，投入人力和金钱尝试开发AUTOSAR的，这里又分两种，一种是作为预言项目，项目结了就交差，或者遇到困难就半途而废的，这在国内也常见。另一种是下决心好好整，希望能推向量产的。不管哪种，可以借用AUTOSAR核心会员的资源，利用他们的工具链，培训服务和软件服务，对于快速和深入学习AUTOSAR还是帮助很大的。AUTOSAR标准如果不借项目操作去理解，单看标准是很难的。
还有一种是不严格的AUTOSAR架构，就是用了AUTOSAR的核心概念，但是在实际使用中为了适应市面上各OEM的状况，在软件平台搭建时对AUTOSAR做了取舍，但核心架构和分层仍然AUTOSAR。我在几家零部件巨头的控制器软件方案中都看到了这样的情况。有的干脆舍弃了RTE这一层，使用了传统的接口进行软件集成，这样避免了国内很多厂家没有RTE环境而无法与基于AUTOSAR架构的基础软件进行集成。这和功能安全类似，国外强调的功能安全的概念，而不是标准，利用了标准的方法和理念，没有完全被标准束缚，他们通常都是自己对自己的认可，不像国内的企业需要请求第三方认证公司给自己发一个证，以此证明自己是优秀的，所以能看到国外的一些知名车企或者零部件厂商都是自己对自己认证，很少寻求第三方。此前和一个功能安全做了20年的资深工程师交流，他说功能安全是无止境的，而不是标准上的这些。我觉得这样是相对务实的。当前的AUTOSAR不管是工具链，还是大家的接受程度，以及国内普及度，都还是不够成熟的，做一些取舍是有必要的。
说了这么多，有些跑题了，下面谈一下我对AUTOSAR的一些弊端，从当前市面上几个AUTOSAR工具链的情况，以及国内外零部件厂商在AUTOSAR的使用情况来看，AUTOSAR在国外或是国内的运用情况并不成熟，至少与AUTOSAR最初的设计理念还有较大的偏离，而且对于量产项目而言在灵活性上还是有所欠缺，其软件复用性独立性也不如宣传的好使。从以下几个方面说说我在项目中的一些AUTOSAR在实际使用时的而一些弊端：
一，AUTOSAR工具链不便宜且不成熟，不是针对哪家工具链，现在市面上使用的就那么两三家，据了解，多多少少都存在问题，这两年在整个项目实施的过程，基本也是工具链逐渐更新修复BUG的过程，虽然项目已上车，软件也能稳定运行，但由于工具bug而调整的手写代码也让整个软件工程变得不那么“踏实”，软件集成由于这些修补代码也要变得格外小心。有的问题虽然并非算是工具bug，需要工具链支持而支持不了，工具链在适应实际项目需求时还是缺乏了灵活性。
二，工具链之间的兼容性影响了AUTOSAR软件宣传的复用性独立性效果。AUTOSAR号称的软件模块复用性和独立性，在实际体验中并没有宣传中的那样好。一方面是因为这些工具链厂商对于自己产品的问题修复已自顾不暇，没办法花精力处理这一问题；另一方面出于利益冲突，他们互相之间并没有做好的兼容性沟通和设计。当然还有个重要的原因，因为AUTOSAR的普及度还不够，矛盾暴露的还不够激烈。我向各个厂家咨询过相关的问题，是否能将另一家公司配置好的RTE环境的描述文件用在当前公司的工具链中，并顺利生产代码。没有一家可以打包票说没有问题，也没有人回复说尝试过。这会造成一些问题，原本希望通过AUTOSAR的优势，不同厂家一起合作完成一个软件项目，但由于工具链的兼容性而不得不保持工具链的一致性，这对于合作的限制是很大的。
三，集成效率偏低，难以适应项目频繁变更带来的影响。这在业内也不是新鲜事了，大家都碰到了这种困扰。BSW与策略的接口集成，有大量的工作，虽然都是体力活，但当前的情况，这一体力活不仅在操作上低效，在错误检查方面也不行，不如传统软件集成方式；另外由于项目变动需要调整CAN协议时，这一工作在传统集成时是简单的修改，但对于AUTOSAR项目来说是一个灾难性的变动，基本上可以说此前80%的集成工作需要重新做，当然这一问题有国内厂家系统阶段定义CAN协议太随意造成变更太随意的流程问题原因，不能全怪在AUTOSAR身上。
四，策略与BSW的适应性问题。AUTOSAR项目中，APP与基础软件的集成有两种方式，一种是自上而下，另一种是自下而上。拿MATALAB来举例，自上而下，是MATLAB策略软件将定义号的模块，接口，数据类型，调度周期等信息先做好定义生成ARXML文件，导入到AUTOSAR工具链中进行集成。自下而上，则是由AUTOSAR工具链定义好模块及接口，生成ARXML文件后导入到MATLAB中，MATLAB再在此框架中进行建模。但还是由于工具兼容性的问题，基本上目前只能实现自上而下的集成方式，自下而上的方式，由于MATLAB对于AUTOSAR接口的检查规则与其他厂家的规则不一致导致会报错，基本上无法这样实施。
五，调试问题。这是自动代码生成的通病，和MATLAB自动生成的代码一样，RTE generator生成的代码可读性上也很差，这给软件调试带来了不少麻烦，在C代码层级，信号的数据走向和函数调用需要一层一层的查询才能找到相应的数据关系。
六，汽车工程师对于AUTOSAR新理念的接受程度。AUTOSAR提出了很多新概念，例如标定量是通过描述文件进行描述，再由RTE进行统一管理生成代码。策略接口也不以简单直接的全局变量的方式与底层软件进行交互，而是对接口进行描述定义，由RTE统一进行接口匹配生产代码。其他还有RE,IB,Interface等这些抽象的概念给接触AUTOSAR的人带来了很多困扰。AUTOSAR的软件开发理念和传统嵌入式工程师的认知偏差还是有些大的，造成了一些排斥心理，这也是AUTOSAR普及度不高的一个原因。
小结一下：有一种说法，行业内的标准都是几个巨头为了巩固自己的垄断地位制定出来。各位辩证的看这个问题，AUTOSAR利弊都挺明显，不管怎样，目前看来也还是汽车软件开发发展的趋势，我个人也希望AUTOSAR能够越来越普及，以此来推动工具链或者标准在实际使用中的优化，毕竟是吃这碗饭的，担心自己丢了饭碗。。上面是自己的观点，认知有限，不对的地方望理解。 |
|
|
