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

摘要

当前汽车智能化、 联化、电动化趋势明显，国内整车厂对汽车电子软件重视度逐渐提高，整车厂也开始着手参与到控制器软件开发过程中。文章调研分析了当前常用的几种汽车电子软件开发模式，从整车厂的角度出发， 基于软件开发、软件迭代、软件维护三个过程评价不同模式的优缺点，并提出汽车电子软件架构的改进方向应为如何在不使用配置工具的情况下，降低底层软件的开发难度，提高应用层软件以及底层软件的可移植性和可剪裁性。

1 绪论

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

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

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

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

2.1  OSEK 标准概述

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

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 可以彼此独立使用，在不同的控制器中不依赖于其他部分而单独实现。

图 1   OSEK 体系架构

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

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

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

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 规范。

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

图 2 AUTOSAR 标准架构

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

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

基础软件层（BSW）是直接与硬件进行数据交换，将硬件的不同功能进行抽象，为上层提供基础的软件支持。由于基础软件层是对硬件进行直接操作，该部分软件差异性较大，为了对这部分内容做标准化，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 架构的解决思路，研究如何在不使用配置工具的情况下，降低底层软件的开发难度，并提高应用层软件以及底层软件的可移植性和可剪裁性。

参考文献

[1]   李建.现代汽车电子技术的应用现状及发展趋势[J].电子技术与软

件工程, 2016(21):255-256.

[2]   孙康慧.中国汽车电子产业创新体系构建研究[D].吉林:吉林大学管理学院,2011.

[3]   汤志强.汽车 CAN 络中 OSEK 络管理系统设计与优化[D].合肥:合肥工业大学,2014.

[4]  ISO 17356-2:2005,Road vehicles-Open interface for embedded auto

-motive applications-Part 2:OSEK/VDX specifications for binding OS, COM and NM[S].

[5]  ISO 17356-3:2005,Road vehicles-Open interface for embedded auto

-motive applications-Part 3:OSEK/VDX Operating System (OS)[S].

[6]  ISO 17356-4:2005,Road vehicle-Open interface for embedded auto

-motive applications-Part 4:OSEK/VDX Communication(COM)[S].

[7]  ISO 17356-5:2006,Road vehicles-Open interface for embedded auto-motive applications-Part 5:OSEK/VDX Network Management (NM)[S].

[8]   吕亮.基于 AUTOSAR 的纯电动车整车控制系统模块化研究[D].吉林大学,2015.

[9]   AUTOSAR.Software Component Template.pdf.http://www.autosar. org/.2020.

[10]  AUTOSAR.Specification of RTE Software Requirements on BSW Modules for SAE J1939.pdf.http://www.autosar.org/.2020.

[11]  AUTOSAR.Requirements on Methodology.pdf.http://www.autosar. org/.2020.