63
10.16638/jki.1671-7988.2021.01.020
张可可1,2，周沛泽2
（1.合肥工业大学汽车与交通工程学院，安徽 合肥 230009； 2.安徽江淮汽车集团股份有限公司技术中心，安徽 合肥 230601）
摘 要：当前汽车智能化、网联化、电动化趋势明显，国内整车厂对汽车电子软件重视度逐渐提高，整车厂也开始着手参与到控制器软件开发过程中。文章调研分析了当前常用的几种汽车电子软件开发模式，从整车厂的角度出发，基于软件开发、软件迭代、软件维护三个过程评价不同模式的优缺点，并提出汽车电子软件架构的改进方向应为如何在不使用配置工具的情况下，降低底层软件的开发难度，提高应用层软件以及底层软件的可移植性和可剪裁性。 关键字：汽车控制器；软件开发模式；汽车电子软件架构
中图分类号：U461.99 文献标识码：B 文章编号：1671-7988(2021)01-63-04
Research on Development Mode of Automobile Controller Software
Zhang Keke 1,2, Zhou Peize 2
( 1.School of Automotive and Transportation Engineering, Hefei University of Technology, Anhui Hefei 230009;
2.Anhui Jianghuai Automobile Group Co, ltd. Technology Center, Anhui Hefei 230601 )
Abstract: At present, the trend of automobile intellectualization, network connection and electrification is obvious. Dome -stic oems pay more attention to automobile electronic software gradually, and oems also start to participate in the develop -ment process of controller software Research, this paper analysed the current commonly used several kinds of automobile electronic software development mode, from the perspective of oems, based on the iterative software development, software, software maintenance process evaluation of the advantages and disadvantages of different modes, and put forward the improvement direction of the automobile electronic software architecture should be how to in the case of not using the configuration tool, decrease the difficulty of the underlying software development to improve application layer software and the underlying software portability and can be cut.
Keywords: Automobile controller; Software development mode; Automotive electronics software architecture CLC NO.: U461.99 Document Code: B Article ID: 1671-7988(2021)01-63-04
1 绪论
随着汽车的智能化、网联化、电动化、共享化趋势，电子设备的配备成本在汽车整体成本中所占比例居高不下，甚至高达百分之四十以上[1]。汽车电子技术的发展趋向于集成化、智能化，当前汽车电子控制器在逐步取代机械控制系统，“软件定义汽车”已经成为未来汽车发展的共识。近年
作者简介：张可可（1996.04-），男，学士学位，非全日制研究生，就读于合肥工业大学汽车与交通工程学院，并就职于安徽江淮汽车集团股份有限公司技术中心，智能网联工程师，助理工程师，主要研究方向为汽车电子技术。周沛泽（1992.09-），男，学士学位，就职于安徽江淮汽车集团股份有限公司技术中心，智能网联主管工程师，助理工程师，主要研究方向为汽车电子技术。
汽车实用技术
64 来的汽车行业发展显示，汽车行业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]。
图1 OSEK 体系架构
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 标准或者其他一些通用的软件架构并没有对应用层软件架构有很好的指导，应用层软件架构往往不够清晰。这种情况导致应用层软件功能复杂度较高时，应用层软件内各
张可可 等：汽车控制器软件开发模式调研
65
单元耦合度过高，软件功能的删减修改牵扯较多，增加软件维护难度。
通过上面的分析，整车厂开发应用层软件的开发模式，在提高应用层软件复用性的同时，保护了整车
厂的控制器核心算法。但是这种开发模式还存在两个问题：底层软件复用性差，更改难度大；没有应用层软件架构标准指导，应用层软件架构不合理会导致软件维护难度大。
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 也没有完全解决驱动软件的复用问题，项目开发中依然需要对驱动软件重复开发。
汽车实用技术
66 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.www.autosar.
org/.2020.
[10] AUTOSAR.Specification of RTE Software Requirements on BSW
Modules for SAE J1939.pdf./.2020. [11] AUTOSAR.Requirements on Methodology.pdf.www.autosar.
org/.2020.
（上接第59页）
系统诊断为压力传感器信号异常；当Tq ∆＞Tq_门槛值，a ∆＞a_门槛值且T ∆2＞T2_门槛值，系统诊断为液压系统故障，并输出诊断结果提示（故障代码、故障灯）。
图9 发动机万有特性表
车辆出现故障时，售后维修人员从TCU 读取诊断结果（故障码提示信息），根据故障码信息，确认故障原因。压力传感器压力信号异常时，系统直接判定，售后更换传感器即可；诊断结果为液压系统故障时，售后人员还需进一步检查确认，按照液压故障诊断方法排查油量、电磁阀、油泵及系统泄露问题。
6 结束语
本文从DCT 变速器压力控制、压力异常表现、影响因素
分析、故障诊断方法、售后诊断模块开发系统论述了压力异常产生机理及诊断方法。
随着自动变速器应用的普及，国内市场各主机厂已经开发或正在开发具有自主技术的DCT 自动变速器，市场面临的竞争除了本身的技术能力和制造品质之外，售后服务也是各家竞争的重点。自动变速器售后诊断的专业性、效率、准确
性决定了顾客满意度及产品口碑，本文介绍的诊断方法，有效地解决了DCT 变速器离合器压力异常故障液压系统、离合器压力传感器两者的故障判定，该方法已广泛应用到售后市场故障诊断当中。
参考文献
[1] 钟圆.湿式DCT 液压控制系统研究[J].西南大学学报：自然科学
版.2012,06.
[2] 陶勇超.浅谈DCT 双离合自动变速器[J].汽车与驾驶维修：维修版,
2018,05.
发布评论