本系列Autosar 诊断入门介绍,会详细介绍诊断相关基础知识,如您对诊断实战有更高需求,可参见诊断实战系列专栏,快速链接:Autosar诊断实战系列导读
如您MCAL配置,通信,诊断Autosar全栈等实战有更高需求,可以参见AutoSar 实战进阶系列专栏,快速链接:AutoSar实战进阶系列导读
UDS(Unified Diagnostic Services)协议,即统一的诊断服务,是面向整车所有ECU的一种诊断通信方式,是基于ISO 14229规范的规范化诊断服务标准,其位于OSI模型中的应用层,如下图,UDS可基于不同的总线实现,如基于CAN总线可再结合ISO1576协议进一步实现传输层。
UDS诊断的本质是一系列服务,按照其不同功能可划分为六大类共26种,每种服务对应一个SID(Service ID),通过该行业标准协议,各主机厂、供应商及4S店等上下游企业可以读取或写入相关信息,或实现其他如刷新的功能,如在生活中4S店的工作人员会通过诊断仪读取汽车故障码、软件版本信息等辅助汽车的维修。
在本系列会先介绍UDS概述,再介绍其网络层实现,最后介绍Dem、Dcm及FiM各模块实现逻辑及代码调用关系。
UDS在Autosar中的通信链路为:CanDrv<—>CanIf<—>CanTp<—>PduR<—>DCM,在后续系列中会进一步介绍链路之间的调用关系,大家先对此有个大概印象即可。
在使用中,UDS诊断是基于问答形式实现,其中请求端发送诊断请求,ECU端进行响应,如下图,响应类型可进一步区分为肯定响应与否定响应。
按不同服务类型,诊断请求格式有如下三种:
格式1:[SID] + [Sub-Function]
格式2:[SID] + [DID]
格式3:[SID] + [Sub-Function] + [DID]
对应的肯定响应类型:
格式1:[SID + 40] + [Sub-Function]
格式2:[SID + 40] + [DID]
格式3:[SID + 40] + [Sub-Function] + [DID]
否定响应:[0x7F] + [SID] +[NRC]
否定响应格式为一种,其中NRC(Negative Response Code)
借用一张网图,个人认为总结的非常好(如有侵权,可联系作者删除)概括了UDS常用命令,大家可以保存下来,没事可以翻一翻。
DTC(Diagnositc Trouble Code),诊断故障码读取是UDS诊断中非常重要的一环,在ECU运行过程中如检测到故障如检测到汽车的三效催化器发生老化,会记录对应的故障码,不同的故障码根据故障严重及危害程度确定是否需要点亮仪表盘的发动机故障灯。在ISO 15031中对DTC故障码各Bit格式进行了定义:
其中以P0A9B该DTC码对应的状态为02进行解析DTC的八个状态位分别代表含义:
在ISO 14229中定义了28个Sub-Function,大家可以参考协议进一步学习,篇幅问题在这就不进一步介绍。
几个常用的Sub-Function:
19 02 :通过DTC 状态掩码获取DTC状态
19 0A:获取支持的所有DTC的状态
如应答为否定应答,则对应的否定NRC代号对应解析:
与读DTC相对立的一个服务就是清除DTC,14服务可以改变DTC的状态。DTC状态中的八个位,除bit4和bit6外均会被清零,包含当前故障(TestFailed)和历史故障(ConfirmedDTC)。bit4和bit6这两个testNotCompleted开头的会被强制置1。
如发送:14 FF FF FF ,清除所有DTC:
也可以按不同的Group进行,Group的划分在14229中有具体的定义:
如应答为否定应答,则对应的否定NRC代号对应解析:
最后声明:为更形象表达UDS相关内容,借用了较多Vector中的图片,仅作为知识总结交流,如有侵权可联系作者删除。