AUTOSAR架构诊断功能简介.docx

AUTOSAR架构诊断功能简介AUTOSAR架构诊断功能简介 随着计算机及嵌入式技术被愈加广泛融入到汽车工程中，整车内的CAN总线网络构造由于ECU的增加愈加困难，与之正相关提高的是汽车电子开发验证困难度 电子限制系统强大的可操控性虽使车辆运行性能较之传统机械猛兽更为迅猛稳定，但同样也对产品前期设计开发，整车的制造生产，及售后工程部门的修理处理方面提出了挑战因此各OEM迫切须要一套满意高精确性，实时性及高效性的汽车诊断系统，来应对现阶段分别式的软件设计、测试流程 目前最主要措施之一就是前面介绍过三次的AUTOSAR〔Automotive Open System Architecture,汽车开放系统架构〕，主流整车制造商及零部件供给商盼望对ECU 嵌入式软件架构进展规划统一来实现车辆故障诊断的标准化 1「车辆诊断」定义 对于整车厂而言，诊断分为两类，易于被用户感知的仪表故障灯显示隶属主机厂采纳的诊断模式〔Onboard Diagnostic System〕，通过车内模块自带的诊断系统对ECU的软硬件及各传感器参数进展某些常见故障的实时监控与发觉，当系统判定电控系统出现故障时，会以仪表警示灯亮的形式来告知驾驶者，并在ECU的EEPROM或Flash内对相关DTC〔Diagnostic Trouble Codes〕进展存储，以便后续车辆被送至售后处，工程师对其进展故障检测时读取分析处理。

值得记住的是，诊断技术首先由通用汽车引入诊断其次种类型为离线诊断模式〔Offboard Diagnostic System〕，即将外部设备接在OBD诊断口上与整车网络各ECU进展通讯，以对各模块数据实行监控与检测分析诊断设备通过发送满意诊断协议定义的诊断效劳来实现诸如对已存储DTC的读取与去除，利用其他的整车限制指令来实现对车辆的动静态限制目前OEM在产品前期开发及售后过程中最常见的两种通信工具有美国英特佩斯公司的NeoVI fire(目前已有fire 2)/ RED + Vehicle SPY3及Vector的CANoe CAN工厂制造环节中因可能须要进展整车ECU的批量刷新而选择其他支持并行刷新及测试的设备，详细何种这里不作介绍至于外部测试工具如何对总线ECU发起合法消息恳求并进展正常通讯，并遵照规那么解析出反应报文的含义，那么须要参考整车网络架构中应用层的诊断通信协议定义2诊断协议标准 参照互联OSI 7层模型，把目前整车网络中最常用的ISO〔International Standards Organization〕与SAE〔Society of Automotive Engineers〕两套标准协议做出如下归类：简洁介绍两个最常见且较有代表性的诊断体系标准，假设须要可自行检索下载阅读： ISO 15765Road Vehicles-Diagnostics on Controller Area Network，是车辆基于CAN诊断的标准协议。

通讯方面开发实力强的公司会进展协议定制，如北美通用〔GM〕在ISO 15765-2的根底上进展定制化开发出应用于Service Layer及Transport Layer的GMLAN，该协议也被其他某些厂家采纳ISO 14229ISO 14229，也就是近年常被行业内提及的UDS protocol〔Unified Diagnostic Service〕标准中定义出了诊断效劳在数据链路上的独立需求通过标准化的诊断效劳，用户可以运用诊断工具〔Client端〕干脆限制ECU〔Server端〕的电子燃油喷射、节气门转角、转速、ABS系统、EPS模块等〔是否能联想到某前瞻扩展领域的应用〕3AUTOSAR诊断重要组成 之前几篇也介绍过AUTOSAR的软件架构，AUTOSAR诊断功能模块主要实现局部为ECU软件中的故障诊断事务管理(DEM)以及故障诊断通信管理(DCM)，通讯接口如下图： 故障诊断事务管理DEMDEM那么负责干脆处理与DTC相关的诊断效劳，例如UDS中的0x19〔读取故障码〕及0x14〔去除故障码〕的效劳，在ECU运行过程中，Monitor Function会进展持续的status检测，一旦出现疑似故障时，会干脆调用DEM来进展故障check，确认后即可完成将诊断故障数据写入到EEPROM或者Flash中的过程。

对于诊断模式〔Onboard Diagnostic System〕，SWC在从DEM中读取到故障信息的同时，会将以故障灯的形式告知驾驶人员 故障诊断通信管理DCMDCM支持ISO 14229-1标准，主要负责确保诊断通信数据流，及包括平安访问在内的诊断状态限制，因此支持0x10(Session Control)、0x27(Security Access)当总线给该ECU发送UDS协议中定义的诊断恳求指令时，DCM会调用DEM、SWC或者是其他根底软件模块供应的接口进展如诊断恳求判定、诊断功能执行以及响应的反应 详细实现上，DCM分成三个子模块:诊断效劳处理器〔Diagnostic Service Processing, DSP〕DSP位于DCM的最上层，可理解为一个包含了通用性诊断效劳的容器，用于处理各应用间共性的效劳，如故障相关信息等数据的处理当DSD完成诊断恳求处理并且将恳求转发出来后，DSP对该消息进展处理诊断效劳调度器〔Diagnostic Service Dispatcher, DSD〕DSD位于DCM中间层，当接收到诊断恳求后，会将恳求转发给DSP同样，在DSP完成诊断恳求处理后，也会将响应转发出来。

诊断会话层〔Diagnostic Session Layer, DSL〕DSL位于DCM最底层，主要负责接收模块上传的诊断恳求并最终发送出诊断响应数据，并管理、确保诊断协议的Timing以及诊断状态 数据交互及接口如下：无论是传统汽车电子架构亦或是将来新能源车型的逐步推广，车辆诊断技术在整个汽车产品的设计研发、工厂制造及售后环节中都会起到极其重要的作用从对K线到CAN，再到不久后的CAN FD以及Ethernet的支持，作为其核心的诊断通信协议也将会随着整车功能的完善及车载总线系统的更新迭代而日益丰富AUTOSAR的出现，促成了汽车电子软件的高效管理，其中所运用的如UDS的协议同样也将进一步推动汽车诊断领域的标准统一与开展 参考资料《AUTOSAR_LayeredSoftwareArchitecture》《Specification of Diagnostic Communication Manager V2.0.1》本文来源：网络收集与整理，如有侵权，请联系作者删除，谢谢！第5页 共5页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页第 5 页 共 5 页。