基于AUTOSAR的BCM诊断开发

刘永宏 张巧娥 樊昀

摘要：本文详细论述了基于AUTOSAR的车身控制系统（BCM）的诊断开发，重点介绍了基于AUTOSAR的诊断模块功能及诊断实现，包括诊断通信管理和诊断事件管理两大核心模块，以及诊断功能定义、诊断软件设计、诊断测试等内容。本文对主机厂开发电控系统诊断具有一定的指导和借鉴意义。

关键词：AUTOSAR;车身控制系统（BCM）;诊断开发

1 前言

随着车辆中电子控制系统越来越多，对算法和控制精度要求越来越高，系统中任意一个部件的故障，比如机械故障或电气故障，都可能导致整个系统的故障，对于这些故障，由于电子控制系统的复杂性，传统的汽车诊断和维修的方法难以满足故障诊断在实时性和准确性上的需求^[1]。车身控制系统（ BCM）主要功能是控制汽车外部灯光、内饰灯、门灯、前后雨刮、中控门锁、后视镜折叠、防盗等，并配合其他控制器完成对车窗、电动座椅的控制，主要是用于增强汽车的安全、舒适和方便性。几乎与车上的所有电子单元有直接或者间接的关联，包涵了网络，智能化控制，软件标准化等研究议题。为加强汽车电子控制系统软件的功能，提高车用电子控制系统软件的可重用性，增强系统软件的可配置性，加快汽车电子控制系统软件的开发效率，改善系统软件的可靠性和稳定性，由全球汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合推出了汽车开放系统架构标准AUTOSAR（ Automofive Open System ArChitecture），其目的是为汽车电子软件开发提供开放的、标准化的软件架构^[2]。AUTOSAR的出现不仅解决了汽车电子软件开发中遇到的问题，也解决了目前汽车电子控制系统故障诊断所遇到的问题。在AUTOSAR架构中，其中很重要的一部分就是诊断系统，AUTOSAR诊断系统的目的是适应所有的诊断标准和协议。

2 AUTOSAR诊断系统介绍

2.1 AUTOSAR分层架构

AUTOSAR的目标是实现汽车电子软件系统的基本功能，并标准化功能接口，使得软件模块易于集成和复用，切实提高软件的更新和开发的效率。为了实现这个目标，AUTOSAR按照层次化、模块化的软件开发和设计思想，将ECU软件架构分成了应用层（ Application Layer）、运行时环境（ Runtime Environment，RTE）层以及基础软件（ Basic Software，BSW）层^[3]，如图1所示。

在AUTOSAR标准中也对诊断相关模块进行了定义，其架构如图2所示，AUTOSAR中的诊断模块主要包括：应用层诊断策略模块（ SWC）、處于BSW层的主要有FIM模块（根据诊断结果使能或禁止软件构件内部的功能实体）、ECUStateManager（ECU状态管理）、DCM（诊断通信管理）、DEM（诊断事件管理）、NVRAMManager（非易失性存储器管理）。DEM和DCM是诊断中的核心模块：DEM将故障的故障码和冻结帧存储到存储器中，在需要时将数据提供给DCM;DCM为诊断提供通信服务以及根据外部诊断工具的要求和DEM共同提供诊断服务，它会将外部诊断工具所需要的信息从DEM中获取并传递过去^[4]。

2.2 诊断核心模块介绍

2 .2.1 诊断通信管理模块（ Diagnostic Communication Manager）

DCM模块遵循ISO I4229-1、ISO I5031-5、ISO 15765-4和SAE J1979标准，能直接处理0x10、0x27和0x3E服务。DCM模块的主要功能在于保证诊断的数据流管理诊断状态，尤其是诊断会话和安全状态。此外，DCM模块需要榆查所请求的诊断服务是否支持以及所请求的服务是否能在当前会话状态下执行，当收到AUTOSAR支持的OBD诊断服务的请求时，DCM会通过调用DEM或SWC模块提供的接口来响应。

AUTOSAR建议使用三个功能子模块实现DCM，分别是DSL（Diagnostic Sessinn Layer，以下简称DSL）、DSD（ Diagnostic Service Dispatcher，以下简称DSD）和DSP（ Diagrmstic ServiceProcessing，以下简称DSP）^[5]。主要功能块组成如下：

（1） DSL（诊断会话层）子模块负责确保诊断请求和响应的数据流，监控诊断协议的时间和管理诊断状态。其主要功能有：请求处理，转发诊断请求给DSD子模块;响应处理，转发DSD子模块的响应给上位机;通信安全等级管理;会话状态管理，在会话状态改变时通知相关模块;诊断协议管理，能够处理不同的诊断协议，管理相关资源;通信模式处理。

（ 2） DSD（诊断服务分配）主要负责检查从网络上接收到的诊断请求的合法性，并将其转发给一个数据处理器。当DSL确认收到了一个诊断请求时，会通知DSD子模块，这时DSD会对这个请求进行分析，确认诊断会话的合理性，是否达到了允许的服务安全等级，然后分析诊断请求信息中的诊断服务标识来启动相应的处理，将诊断请求转发给对应的数据处理器，如DSP。当数据处理器完成数据的处理后，会触发DSD发出一个响应信息。

（ 3） DSP（诊断服务处理）主要处理相应的诊断服务的请求，这是DCM中最核心的模块。当收到DSD发来的请求时，DSP会处理这个诊断服务，主要包括以下几步：分析这个诊断请求信息;检查请求的格式，并且确}人这个请求是否支持;从DEM、SWC或AUTOSAR中其他的模块中请求所需要的数据，主要是DEM和swc;收集好所有数据后，按照标准组织好返回信息。

2.2.2诊断事件管理模块（Diagnostic Event Manager）

DEM模块遵循的标准与DCM相同，负责直接处理与DTC（ Diagnostic Trouhle Code）相关的服务。当应用软件组件中的Monitor Function（故障诊断算法）检测到故障时，将通知DEM模块处理和存储相应的故障诊断事件（由Event ID进行标识）。如果经过判定确诊为故障，则调用NVRAMManager（非易失存储器管理器），提供的接口将其存取到非易失存储器中（如Flash或者EEPROM），同时通知应用层软件点亮故障灯，提醒驾驶人员相应的故障信息。

3 诊断设计

当前，整车厂和供应商采用在线诊断与离线诊断相结合的诊断方法。在线诊断通过ECU内部软硬件实现自诊断。BCM借鉴传统的诊断方式，在汽车运行过程中，自诊断系统实时监控电子控制系统各组成部分的工作状态，从而检测电子控制系统中的故障。自诊断系统一方面将检测出的故障通过一定的方式（比如报警指示灯）向驾驶员发出警告，另一方面将故障代码及相关数据存人ECU存储器。离线诊断通过外部诊断设备读取相应的诊断信息，实现诊断操作。实现离线诊断的关键在于如何实现诊断设备和ECU之间的通信机制和诊断服务，即诊断协议。

目前，诊断协议标准主要分为ISO和SAE两种体系。美国使用SAE标准体系，包括中国在内的多数国家使用ISO标准体系。在乘用车领域，OEM正从自定义诊断协议逐渐转向ISO标准。在商用车领域，OEM沿用SAE诊断，欧洲OEM在此基础上增加了ISO诊断。表1列出了部分ISO和SAE标准对照。

目前通行的车辆控制器的诊断服务有两种：法规要求的和扩展的诊断服务。

1）法规要求的服务是基于IS015031-5并要ECU强制执行的服务。服务范围0x01-0x0A，

主要目的在于控制和减少车辆排放。

2）扩展服务基于IS014229-1，并且是非强制性的。用于建立对于诊断系统的通用需求。其中，扩展服务可以读取非排放相关的DTC，和对ECU的flash内存进行编程。乘用车BCM的故障诊断，主要是基于IS014229的UDS扩展诊断。目前，AUTOSAR Version 3.1诊断功能共支持9个OBD服务。参照表3-1可知，AUTOSAR不支持OBD诊断标准中的Ox05服务（请求氧传感器监测结果），原因在于基于CAN总线的Ox05服务可以通过0x06服务实现。

主要包括读写基本信息（0x22&0x2E）、输入输出控制功能（0x2F）、故障诊断码定义等内容。

读写基本信息（0x22&0x2E）包括：

OEM整车配置定义，比如车速上锁、防盗报警配置;

ECU生产时间标识;

软硬件版本号;

读写ESK和PIN码等。

输入输出控制功能（0x2F）包括：

室外灯控制，比如左右转向灯闪烁、前雾灯继电器控制、后雾灯继电器控制、远光灯继电器控制等;

雨刮/雨刷洗涤输入输出状态，比如前雨刮低速模式、前雨刮高速模式等;

报警状态，比如防盗/中控锁LED、报警喇叭等;

MCU输出状态，比如中控上锁继电器（执行一次上锁动作后自动转为ECU控制）、中控解锁继电器（执行一次上锁动作后自动转为ECU控制）、电动车窗使能继电器（持续打开）、行李箱开启继电器（执行一次上锁动作后自动转为ECU控制）等;

室内灯控制及电池节电输出状态，比如室内灯（持续100%占空比运行）、节电输H{继电器（持续打开）等;

后除霜控制，比如后除霜继电器控制。

故障诊断码（读取故障码（0x，清除故障码0x14）主要包括：

前雨刮雨刷，比如前雨刮停止位開关故障、前雨刷洗涤开关故障（周期内停止开关状态一直未变）、前雨刷洗涤开关故障等;

灯光故障，比如远光灯电路故障（对电池短路/对地短路）、近光灯电路故障（对电池短路/对地短路）、位置灯电路故障（对地短路或开路/对电池短路）、室内灯电路故障、前雾灯电路故障等;

发动机防盗系统故障，比如天线线圈故障、基站通讯故障、无发射器或发射器无效、没收到EMS挑战码等。

车窗故障，比如左前车窗欠压故障（电压低于9V）、右前车窗控制器内部故障（电机温度超过设定值）、右前车窗按键故障（摇窗机按键闭合时间>60s）、右前车窗电机故障（电机无法正常运行）、右前车窗欠压故障（电压低于9V）、左后车窗控制器内部故障、左后车窗按键故障、左后车窗电机故障、右后车窗控制器内部故障等。

例程控制（ 0x31）

包括钥匙学习命令和钥匙擦除命令等。

考虑到系统基于CAN总线的诊断操作和软件升级的需要，需要对系统进行安全认证和模式切换的管理。系统被分为三个模式：默认模式，扩展模式和编程模式。除了对车辆软件进行bootloader升级在编程模式下外，其它操作都在默认和扩展模式下。其中车辆正常运行时在默认模式下。进入编程模式和扩展模式都需要安全认证。安全访问的流程如下：

1）客户端请求种子;

2）服务器端发送种子;

3）客户端发送密钥;

4）服务器端响应密钥是有效的，并且进行自身解锁。

4 离线诊断测试

为了使BCM的诊断测试更加方便快捷，开发了一套Windows平台下基于CAN总线的车身诊断系统软件。装有该软件的平板电脑，通过OBD接口适配器与汽车总线相连，在整个诊断过程中，适配器主要实现两个功能，一是将平板发送的数据转换成CAN或者K信号发送到整车网络上，二是将整车网络上ECU返回的应答信号转换成USB或者蓝牙信号返回给PC机。从而实现PC机遇整车网络上的ECU数据交互。

通过对图形化界面的操作进行诊断测试。该软件可以实现读取故障码和清除故障码、读写数据流、执行器测试、防盗匹配、钥匙学习、软件升级等主要功能，系统架构如图3所示，通过上位机pad的诊断软件发送诊断请求，通过OBD适配器进行数据传输实现与ECU的诊断通信。

如图4所示，诊断仪软件架构分为几个部分：

1、底层通信模块，主要实现CAN通信;

2、诊断通信模块，实现诊断服务;

3、功能界面，实现诊断服务动态库的调用已实现各诊断功能。

通过诊断仪直观，方便快捷的诊断测试和图形化的显示方式，使得BCM的诊断操作更加直观;通过读数据流、故障码、例程控制等操作，可以快速实现诊断测试通过CAN总线的数据监测，可以很好的分析过程数据，帮助查找问题原因。功能选取界面、读取数据流界面、数据分析界面分别如图5、图6、图7所示：

5 结论

AUTOSAR的出现加强汽车电子控制系统软件的功能，提高车用电子控制系统软件的可重用性，增强系统软件的可配置性，加快汽车电子控制系统软件的开发效率，改善系统软件的可靠性和稳定性。不仅解决了汽车电子软件开发中遇到的问题，也解决了月前汽车电子控制系统故障诊断所遇到的问题，AUTOSAR将成为必然趋势，对汽车电子软件开发的T作流程和商业模式都将带来意义深远的变革。

参考文献：

[1]罗端，李红等基于AUTOSAR的汽车电子诊断系统的开发[J].汽车工程，2012，（ V01.34） N0 2：179-183.

[2]AUTOSAR.Autosar Technical Overview[S/OL].http：//www.autosar.org/

[3]AUTOSAR GbR. AUTOSAR Methodology V1.2.1 [S]. 2008

[4]AUTOSAR GbR. Specification ofDiagnostic Event Manager V3.1[S]. 2008

[5]AUTOSAR GbR. Specification of Diagnoscic Communication Manager V3.1[S]. 2008