论文部分内容阅读
摘要：本文详细论述了基于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
关键词：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