汽车软件为什么越来越强调AUTOSAR

 

图 1、 AUTOSAR分层软件结构

一说到AUTOSAR，大家是不是都会联想到图 1的分层软件结构呢？没错，这是其中的一部分。但，远非全部。

AUTOSAR全称是汽车开放系统架构，最初，欧美日传统汽车巨头即9家核心成员，关起门来一合计，就搞了这个软件架构，初衷外人已不可考。除了分层软件结构外，AUTOSAR主要还包括：方法论、应用接口。

为什么？

在业内，人们对AUTOSAR的评价毁誉参半，有人说提高门槛、方便垄断，有人说统一标准、降低成本。抛开传统汽车巨头曾经光环和优势话语权，我更喜欢把它叫做汽车软件架构。客观上，AUTOSAR规范了汽车软件的分层结构、开发方法、交互接口，实现了集中设计、分散实现，提供了一种工程实现方法和工具。

个人认为，AUTOSAR更重要的是一种软件工程的方法、流程和工具。业内人都知道，传统汽车上各种各样的电子控制单元（ECU）有几十上百个，这些ECU的作用也五花八门：为司机执行动作，给司机反馈信息，安全保护，等等，电动化、智能化的汽车上ECU就更多。软硬件工程量是极其浩大的。

    a、软件工程

汽车软件开发这一活动，首先是软件的工程。软件工程不仅仅是软件，软件只是工作输出，另一重要部分是工程问题，可以朴素地理解为：

软件工程=软件+工程

和许多其它的工程领域一样，此处的工程和管理学有很大的关系，是一种人文科学。可以简单理解成：

工程=人员+管理

单单从软件量来讲，AUTOSAR规范会增加软件的量，甚至会增加开发人员，的确抬高了开发汽车软件的门槛。但是，从软件的生命周期来看，开发之后，还有测试、维护、交接等活动，软件要如何保证可靠、可追溯、可维护？又单看开发活动，也还有需求分析、架构设计、人员组织，进度管理等等。从工程角度来讲，AUTOSAR是分解了工程难度，方便了分工合作，有利于经验传承。

    b、中国汽车现状

众所周知，燃油车时代，中国的汽车市场是合资的天下，自主品牌就是低端的代名词。本以为的市场换技术，只是剃头的挑子一头热，终究丢了市场还没换到技术。

有没有捡到一点便宜呢？AUTOSAR大概算一个。中国有大量的电子信息类理工毕业生，这是人才优势。大多数中国学生最擅长什么呢？考试和抄作业。高级点，设计一种体系化架构？没听说过。发展一种理论方法？不能够啊。于是AUTOSAR先弄一构架，让你把作业抄过来；再依葫芦画瓢一分解，汽车软件开发就变成了填空题。怕把作业抄错了，瞧，工具都一起准备好了。

是的，仅仅是捡到一些便宜。AUTOSAR并不是专门为谁设计，而是人家工程管理的具象化。欧美的管理是把人当人看的，承认人是会犯错的，这点没有机器可靠。又是把人不当人看的，流程里的人是完全可替代的，这点跟螺丝钉没有区别。中国的管理是把人当牛马看的，手里没皮鞭的就是干活的牛马，工作都交给他使劲抽便是。管理方面，在企业里面，很多中国领导是不合格的，没学会，或许压根不打算学。

    c、整车多个ECU

在汽车正向设计阶段，可以自顶向下分解，主要考虑整个软件需要哪些功能模块，各自有哪些动作，这些软件模块之间有什么联系，如何协调的问题。然后再考虑应该设置哪些控制器，软件模块怎么分配。最后把控制器分给相应的供应商去实现。这项活动由软件工具提供支持，该工具就是方法和流程的沉淀。这种自顶向下的优秀思想，完全可以全盘接受。

 

图 2、 系统配置

    d、零部件单个ECU

经过长期实践，单个汽车ECU，通常需求明确，而且规模不大，采用V模型（或者W模型）的流程是很合适的。ECU软件开发的V流程如图 3所示。

 

图 3、 V开发流程

汽车ECU通常有共同的一些软件功能。比如：电源管理、总线通信、参数存储、信息安全、软件更新等等。针对这些标准模块，AUTOSAR整理了详细说明书，包括了标准的软件功能，甚至函数原型。为MCU半导体厂商、ECU零部件供应商标准化流程化的软件开发提供了方便。

 

图 4、BSW基础软件模块

如何做？

AUTOSAR的确是个好东西，但还是有一些疑问。

我的ECU跑得好好的，要不要重新按规范开发？个人觉得不需要，老产品的可靠性已经过量产验证，新一代产品也是按需采用。在上一代生命周期内，如果发现了一些软件技术问题正好可以通过规范化克服掉，或者客户有要求，那就按规范来。

任何方法都有个适用范围。它可以很好解决传统汽车ECU软件的问题，但新兴的零部件大家都在摸索中，比如智能座舱更像手机或平板的开发，智能驾驶可能会采用NPU这类新硬件。它可以很好解决汽车软件工程的问题，但同是技术问题的ECU硬件开发可能就无能为力，更不能解决领导不屑技术类似管理方面的问题。

可能还有更好的架构，也许正在孕育中。尊重创新，勇于探索，破而后立。