汽车控制器软件开发模式调研

张可可，周沛泽

（1.合肥工业大学汽车与交通工程学院，安徽 合肥 230009；2.安徽江淮汽车集团股份有限公司技术中心，安徽 合肥 230601）

关键字：汽车控制器；软件开发模式；汽车电子软件架构

1 绪论

随着汽车的智能化、网联化、电动化、共享化趋势，电子设备的配备成本在汽车整体成本中所占比例居高不下，甚至高达百分之四十以上[1]。汽车电子技术的发展趋向于集成化、智能化，当前汽车电子控制器在逐步取代机械控制系统，“软件定义汽车”已经成为未来汽车发展的共识。近年来的汽车行业发展显示，汽车行业70%的创新都来自于汽车电子[2]。

在以往大部分汽车控制器功能复杂度不高，汽车主要的创新点还停留在传统机械机构上的时候，整车厂对于汽车技术上的投入大多还是集中于发动机、变速箱和底盘的开发、标定和测试。大多数汽车电子零部件作为非关键零部件往往依赖零部件供应商进行开发，整车厂在零部件软硬件开发参与度不高，软件开发水平较低。

2 整车厂开发应用层软件的开发模式

整车厂在的软件开发过程的精力主要集中在应用层软件开发上，由供应商负责主导其他软件开发过程。为了方便应用层软件的移植，通常采用一些成熟的汽车电子软件架构，其中OSEK标准作为广泛应用的汽车电子软件架构标准经常在这种开发模式下被使用。

2.1 OSEK标准概述

1993年5月，德国汽车工业界提出了OSEK标准，其含义是汽车电子开放式系统及接口的标准化，得到了宝马、博世、欧宝、大众及西门子等企业和组织的支持。同时，法国的标志和雷诺公司也开发了一个类似的开放式系统VDX。在1995年召开的国际专题研讨会上，各厂商对OSEK和VDX标准达成了共识，产生了一个全新的标准OSEK/VDX，也被简称为OSEK标准[3]。

OSEK标准规范主要包含四个部分：OSEK操作系统规范（OSEK Operating System，OSEK OS）、OSEK通讯规范（OSEK Communication，OSEK COM）、OSEK网络管理规范（OSEK Network Management，OSEK NM）、OSEK实现语言（OSEK Implementation Language，OIL）。其中 OSEK OS、OSEK COM、OSEK NM可以彼此独立使用，在不同的控制器中不依赖于其他部分而单独实现[4]。

OSEK操作系统规范[5]是OSEK标准的核心内容，定义了一系列实时操作系统的内核机制和面向上层应用的标准API接口，包括任务管理和调度机制、中断机制、事件机制、资源管理及计数器和警报管理等。

OSEK通讯规范[6]为应用层软件提供了一个统一的通信环境，它定义了独立于所有通信协议之外的应用软件通信接口，规定了内部通信（ECU内部）和外部通信（ECU之间）时的行为方式。

OSEK网络管理规范[7]提供了一种整车系统各节点的休眠唤醒状态管理的策略。

OSEK操作系统作为OSEK标准最核心的内容，针对汽车电子的实时性高、任务调度类型多的特点，提出了一系列的调度方式，并为调度方式提供了定时器、报警器等不同的事件类型。OSEK操作系统内核针对汽车电子而设计，满足了大部分控制器任务调度需求，实现了基于操作系统的软件系统开放，提高了应用层软件的移植性，使独立开发的应用层软件在不同硬件平台进行复用成为可能。

2.2 开发模式的优势及局限性分析

这种开发模式，由整车厂提出系统需求，并对应用层软件进行开发，需求开发人员和应用层软件开发人员可以方便及时的沟通，避免了应用层软件开发人员对系统需求理解不充分。并且这种开发方式，可以很好地保护整车厂在控制器上的核心控制算法。整车厂对应用层软件进行开发，还有利于提高应用层软件的复用性，减少应用层软件开发周期，减少应用层软件存在的问题。

下面从整车厂的角度出发，在软件开发、软件迭代、软件维护过程对这种开发模式进行分析。

2.2.1 软件开发过程

这种软件开发模式下，对整车厂和供应商的分工有明确的规定，并且整车厂的开发需求都以标准接口文档的形式表达，减少了供应商软件开发人员的理解难度，方便软件开发人员的开发。

2.2.2 软件迭代过程

在控制器的迭代开发中，软件也要相应的进行迭代开发，应用层软件由整车厂开发的方式，保证了应用层软件不会因为硬件平台的切换、供应商的更改而无法使用。但是，由于底层软件是基于具体的软件需求开发的，当应用层软件需求变更，可能会导致底层软件也发生相应的变更，底层软件无法进行复用。而由于底层软件的复杂性，底层软件的变更周期和验证周期较长。

2.2.3 软件维护过程

应用层软件的沿用较好的减少了应用层软件算法出现的问题，避免了绝大部分软件问题的发生。但是应用层软件的增量开发、软件维护，需要一个较好的应用层软件框架支持，而OSEK标准或者其他一些通用的软件架构并没有对应用层软件架构有很好的指导，应用层软件架构往往不够清晰。这种情况导致应用层软件功能复杂度较高时，应用层软件内各单元耦合度过高，软件功能的删减修改牵扯较多，增加软件维护难度。

通过上面的分析，整车厂开发应用层软件的开发模式，在提高应用层软件复用性的同时，保护了整车厂的控制器核心算法。但是这种开发模式还存在两个问题：底层软件复用性差，更改难度大；没有应用层软件架构标准指导，应用层软件架构不合理会导致软件维护难度大。

3 基于AUTOSAR标准架构的开发模式

为了建立标准的汽车电子软件架构，优化应用层软件架构，并且降低控制器软件开发，国内多家整车厂开始倾向于使用AUTOSAR架构作为控制器软件自主开发方案。

3.1 Autosar架构概述

在2003年，由全球汽车制造商、零部件供应商及其他电子、半导体和软件系统公司联合建立了汽车开放系统架构联盟（AUTomotive Open System Architecture，AUTOSAR），并联合推出了一个开放化的、标准化的汽车嵌入式系统软件架构——AUTOSAR规范[8]。

根据AUTOSAR标准的分层规范，汽车嵌入式系统由上到下分为应用软件层（Application Software Layer，ASW）、运行时环境（Runtime Environment，RTE）、基础软件层（Basic Software Layer，BSW）、微控制器（Microcontroller）。为保证低耦合性和可移植性，在一般情况下，每一层级只能使用其下一层级所提供的接口和服务，并向其上一层级提供接口和服务，每层级仅能与其相邻的层级进行接口和服务的调用，不允许跨层级调用。

图2 AUTOSAR标准架构

应用软件层（ASW）是由一些软件组件组成[9]，软件组件是根据系统功能分解的最小子单元，软件组件是系统功能的模型化抽象，每个软件组件实现一个系统功能。通过多个软件组件间的合作执行，最终实现控制器的功能实现。

运行时环境（RTE）是AUTOSAR规范实现软硬件分离的重要手段[10]，RTE对上层的应用软件层的软件组件进行调度和通信接口做管理，对下层的基础软件层的服务进行进一步封装。应用软件层可以也只能通过RTE实现各个软件组件间、基础软件与软件组件间的接口通讯。RTE对基础软件的各项服务进行了标准化的定义，使得不同的开发者开发的软件组件都通过相同的接口与基础软件通信，实现了高度的可移植性。

基础软件层（BSW）是直接与硬件进行数据交换[11]，将硬件的不同功能进行抽象，为上层提供基础的软件支持。由于基础软件层是对硬件进行直接操作，该部分软件差异性较大，为了对这部分内容做标准化，AUTOSAR对基础软件层继续分为四层，服务层（Services Layer）、ECU抽象层（ECU Abstraction Layer）、微控制器抽象层（Microcontroller Abstrac-tion Layer，MCAL）和复杂驱动（Complex Drivers）。

3.2 开发模式的优势及局限性分析

基于Autosar标准的软件开发模式，软件分层更加明确，各层级之间的接口标准化更加彻底，有利于软件的移植和复用。软件组件的定义，增强了应用层软件的可裁剪性和可移植性。基于配置开发的方式，降低了底层软件的开发难度，让软件开发经验不足的整车厂也可以更大程度地参与软件开发过程中。

下面从整车厂的角度出发，在软件开发、软件迭代、软件维护过程对这种开发模式进行分析。

3.2.1 软件开发过程

首先，AUTOSAR基于配置工具的配置开发的方式，减少了代码的编写量，降低了软件开发难度。但是，依赖配置工具的开发方式，带来的成本增加过高，每个新项目都要重新购买软件的开发许可。而且，软件开发难度的降低并没有很明显地降低开发工作量，BSW的配置工具需要定义各层级的所有接口，对各层级接口进行匹配，这在代码中的实现其实并不复杂。

3.2.2 软件迭代过程

由于AUTOSAR软件组件的定义，应用层软件可以方便地裁剪和移植，方便应用层软件的迭代开发。而且底层软件都是基于配置开发，仅需要对相应的配置进行修改，修改难度低。但是，AUTOSAR并没有完全实现底层软件的重用，需求的变更依然会导致底层软件的重新配置，这在合作开发中依然会增加时间成本。

3.2.3 软件维护过程

由于AUTOSAR软件基于配置工具开发，手工编写代码量较少，很大程度地减少了软件出现的问题，软件可靠性强。并且软件分层明确，软件问题的查找和修复液较为简单。

通过上述的分析，基于AUTOSAR的软件开发模式，最大的优势在于软件开发难度低，软件可靠性高，软件修改和迭代也较为简单。但是AUTOSAR最大的问题在于，开发过于依赖配置工具，配置工具成本过高，很难在所有控制器中应用。并且，AUTOSAR也没有完全解决驱动软件的复用问题，项目开发中依然需要对驱动软件重复开发。

4 总结

本文调研了几种当前常用的控制器软件开发模式，分析了不同开发模式下制约软件开发的主要原因。

根据上述调研结果，AUTOSAR标准通过“软件组件”和基于配置开发的底层软件开发方式，基本解决了应用层与底层软件分离后，软件架构还存在的问题，但随之带来了配置工具的成本问题。因此，汽车电子软件架构的优化应该是基于应用层与底层软件分离的思想，借鉴AUTOSAR架构的解决思路，研究如何在不使用配置工具的情况下，降低底层软件的开发难度，并提高应用层软件以及底层软件的可移植性和可剪裁性。