车载软件，因AUTOSAR而改变（上）

车载软件体量的增加

ECU（电子控制元件）的数量，被视为汽车电子化进程的指标之一。

1980年代初期，汽车开始安装ECU，当时的ECU数量仅有2~3个，如今，一辆高级汽车上至少安装了上百个ECU。基本上，这些ECU都是由经过优化的硬件和车载软件组成，其可用于控制汽车系统。各个ECU是不通用的，意味着一个ECU只能控制一个汽车系统。例如，控制发动机点火正时的ECU，不能控制转向系统或仪表盘等其他系统。

如上所述，一个ECU的作用仅仅是控制一个汽车系统，意味着随着车载软件的增加，搭载ECU的数量也会随之增加。但实际上，这种比例关系并不成立。在现在的汽车中，要控制某一系统，不仅需要主系统的ECU，还需要与该系统相关的其他系统的ECU的数据。因此，汽车内搭载的ECU是通过 络连接的，能够共享各种信数据。在通过 络连接ECU的情况下，即使仅新增1个ECU，也需要对已有的搭载了ECU的车载软件加以变更，使之与新的ECU相关联。此外，对于现代的汽车来说，一旦类似的迭代次数增加，相对于ECU搭载数量，车载软件的数量呈指数倍增加。

车载软件的数量规模增大对于汽车厂商来说并没有太大的影响，只要能够重复利用与车载软件相关的资产，就能将其影响最小化。然而，现有的车载软件是以能够在特定系统上达到最佳运行状态为目的开发的，并且根据汽车厂商的特定车型不同，所开发的车载软件也不相同。因此，即使某汽车厂商想要在新车型上重新使用现有车型的软件，也很有可能需要进行大规模的改造。

通过模型化提高车载软件的利用率

AUTOSAR (Automotive Open System Architecture)是以欧洲汽车公司为中心所制定的标准。其目的是应对车载软件规模爆发性的增大，通过提重复使用率来解决大规模改造的难题。推进该标准制定的联盟组织，也被成为AUTOSAR。

已搭载的车载软件，基本上是与硬件和系统一一对应来开发的(图1 (a))。与此相反，AUTOSAR将车载软件定义为分层软件体系结构（图1（b））。每个级别使用的软件都经过了模块化和层次化，因此可以重复使用。

图 1

如图2显示了AUTOSAR定义的软件架构的结构。从上到下可分为三层，分别为应用层、RTE层(Run time Environment)和BSW层(Basic Software)。

图 2

应用层由多个模块化的软件组件(SW-C)组成。每个SW-C都封装了各种应用的功能集，用于实现汽车控制的功能，可大可小。每个SW-C只能运行在一个ECU中，也可称为AtomicSW-C。与以往的车载软件不同是，由于SW-C不依赖硬件，即使ECU搭载于不同的硬件上，也可以被重复利用。

BSW在连接硬件和车载软件的层次上，相当于传统的OS、驱动器、中间件。BSW大致可分为服务层、ECU抽象层、微控制器抽象层(MCAL)和复合驱动器层四种。并且，对应车载软件所运行的每个作用，这4个层的内容也被分割成若干个小模块。这些模块也可以再利用，还可以作为通用产品进行销售。

RTE实现了应用层SW-C之间、应用层SW-C与BSW之间的具体通信。在现有的车载软件中，通信是在SW-C之间直接进行，但在AUTOSAR中，只能通过RTE来通信。当然，SW-C与BSW之间的通信也是通过RTE来进行。

另外，通过AUTOSAR，无需考虑ECU就能开发车载软件的架构(图3)。

图 3

首先，汽车厂商的技术人员将SW-C连接到虚拟功能总线（VFB）的抽象接口来进行开发。实际上，这些SW-C中是嵌入了ECU的，而这些ECU之间又通过 络连接起来，以实现汽车的功能。所以，VFB实际上是已经连接到了ECU和 络，技术人员可以模拟现实中所需的所有元件，如此一来，无需考虑ECU，也能开发出SW-C。

接下来，确定实际搭载在汽车上的每个ECU的规格以及连接ECU的 络拓扑。此时，还需要确定在各ECU中使用了什么样的BSW。根据ECU的规格、 络的拓扑、要使用的BSW信息以及关于连接SW-C的虚拟功能总线的说明，将SW-C分配给每个ECU。同时，对应每个ECU生成RTE。

另外，使用虚拟功能总线进行SW-C的操作仿真、SW-C的分配、RTE的生成，都必须用专用的工具。并且规定在工具之间交换的信息由XML (Extensible Mark up Language)来记述。

AUTOSAR的实现方案

有关AUTOSAR的大部分会议和活动都是以欧洲国家为中心展开。因此，AUTOSAR标准的制定，主要反映来自欧洲的汽车厂商和Tier 1等的要求。此外，对于量产车的采用，欧洲的汽车厂商也是先行一步。所以，支持AUTOSAR的开发工具和BSW，大部分都是由欧洲的工具供应商提供的。

但是，近几年，AUTOSAR进入国内，除此之外，日本也有不少AUTOSAR的导入案例。接下来的内容，我们将为大家介绍欧洲和日本的AUTOSAR案例及其使用的开发工具。

Bosch

德国博世集团在推进AUTOSAR方面非常积极。

为了AUTOSAR应用于车载软件，博世首先规定了AUTOSAR导入的阶段/状态（图4）。尽管Bosch的车载软件与AUTOSAR互不兼容，但传统上是使用与SW-C和BSW的分层相同的概念搭建的。博世将已有车载软件的状态，设置为“Status A”，仅采用了符合AUTOSAR的BSW通信模块的状态，设置为“Status B”，部分采用了符合AUTOSAR的SW-C和RTE的状态，设置为“Status C”。完全采用多个符合AUTOSAR要求的SW-C、RTE和BSW的步骤设置为为“Step 1”。在Step 1中，一半以上的软件符合AUTOSAR的要求。在随后的“Step 2”中，大多数软件将符合AUTOSAR的要求。

图 4 Bosch公司设想的引入AUTOSAR的状态/阶段（提供：Bosch公司）在这个图中，“现有SW-C”、“现有BSW”表示相当于传统使用的SW-C和BSW。另外，关于适用于AUTOSAR的SW-C、BSW，分别表示为“AUTOSARSW-C”、“AUTOSARBSW”。

根据Status A，Bosch制定了在各汽车系统中如何导入AUTOSAR的步骤蓝图。首先，从Status A向Status B/C过渡开始，计划是从2006年下半年开始完成动力总成转换，从2008年开始完成横向防滑装置(ESC)、自适应巡航控制(ACC)、 关ECU的转换，从2009年开始完成车身系统和自动泊车系统的转换。其次是Step 1的过度计划。2009年下半年完成动力总成的转换，2011年开始完成ESC、ACC、和 关ECU的转换。在Step 2到Step 3的最后阶段过度计划中，2011年开始动力总成的转换，2012年开始ESC和ACC的转换，2012年下半年开始完成车身系统的转换，2013年开始 关ECU的转换。另外，预计自动泊车系统将从2011年开始，并跳过Step 1，直接过渡到Step 2。

以上既博世导入AUTOSAR的案例，文章上篇到此结束。下篇，我们将为大家介绍日本软件平台和架构(JASPAR)联盟以及AUTOSAR工具的开发。

AUTOSAR重新定义了嵌入式汽车软件的编写方式，从而实现了对软件组件的重复使用、交换、升级和整合，过程十分简便。11月，牛喀学城特约讲师将开讲《汽车电子系统软件架构AutoSAR实践技术培训》。本课程会对AUTOSAR主流话题进行深入详解以及探讨AUTOSAT的系统解决方案，并结合工具对AUTOSAR的应用进行现场操作演示，同时还会讲解适用于自动驾驶系统的Adaptive AUTOSAR的架构和应用。

扫描以下二维码，参加AUTOSAR软件架构技术培训，理论和工具操作结合，详情扫描如下二维码，预览培训PPT，不可错过！