基于UDS协议的OBD诊断服务标准SAE J1979-2研究

俞林炯

(上汽大众汽车有限公司，上海 201805)

车载诊断(OBD)功能随着排放法规的引入，从20世纪80年代至今，已经历了多轮迭代和更新。2007年7月执行的GB 18352.3—2005《轻型汽车污染物排放限值及测量方法(中国Ⅲ、Ⅳ阶段)》引入了OBD系统及其功能要求。随着环保要求的提升，2020年7月实施的GB 18352.6—2016《轻型汽车污染物排放限值及测量方法(中国第六阶段)》对OBD功能的要求已达到了世界前列。到2020年，全国机动车保有量达3.72亿辆，四项污染物排放总量为1 593万t，而汽车是其主要贡献者，其中汽油车的CO排放超过汽车排放总量的80%、HC超过70%，柴油车的NOx排放超过汽车排放总量的80%。2021年10月国务院印发的《2030年前碳达峰行动方案》提出了关于碳达峰碳中和的重大战略决策，可以预见，机动车污染物排放监管在未来一段时间内会进一步加强，对OBD的要求[包括诊断服务/测试模式(以下统称OBD诊断服务)标准]也应同步升级。

1 当前的OBD诊断服务

从GB 18352.3—2005到GB 18352.5—2013《轻型汽车污染物排放限值及测量方法(中国第五阶段)》，汽车排放法规中OBD诊断服务采用的标准是ISO 15031-5：2001《道路车辆-车辆与排放有关诊断用的外部试验装置之间的通讯-第5部分：排放有关的诊断服务》，并通过满足ISO 15031-4要求的诊断工具输出信息。从GB 18352.6—2016开始，OBD诊断服务的标准换成了SAE J1979_201202《电子/电气诊断测试模式》(下称J1979)，通过满足SAE J1978规定的扫描工具输出信息，明确规定了相应信息，包括准备就绪状态(J6.4.1)、数据流(J6.4.2)、冻结帧(J6.4.3)、故障代码(J6.4.4)、测试结果(J6.4.5)、软件标定识别码(J6.4.6)、软件标定验证码(J6.4.7)、车辆识别码(J6.4.8)、ECU名称(J6.4.9)、IUPR率跟踪(J6.5)要求。其他与GB 18352.6—2016配套的需监测OBD功能的法规(如GB 18285—2018《汽油车污染物排放限值及测量方法(双怠速法及简易工况法)》和HJ 1237—2021《机动车排放定期检验规范》)也规定按照J1979提供标准化输出。

从技术上讲，ISO 15031-5和J1979是等效的，不同时期的应用是由排放法规中OBD部分要求的引用/参考源不同所致。J1979是为满足美国OBD法规而开发的标准，用于1996年以后车型；ISO 15031-5是基于J1979开发的标准，它结合了美国的要求和欧洲OBD的要求，适用于2000年以后车型。GB 18352.3—2005～GB 18352.5—2013中的OBD标准参考欧洲法规，即EOBD，相应标准为ISO 15031-5；而GB 18352.6—2016的OBD采用美国标准，即OBD Ⅱ，相应标准为J1979。

J1979作为当前轻型车主流的OBD诊断服务标准，能满足绝大部分情况的需求，但从实际应用情况来看，还是存在一些局限，因而有行业代表建议CARB(California Air Resources Board)在OBD法规中采用SAE J1979-2_202104(下称J1979-2)，因为J1979-2标准能有效消除J1979中的局限。例如：1)随着插电式混合动力汽车(PHEV)的不断投产，当前基于J1979标准的2 B标准故障码即将用尽。而J1979-2可提供3 B标准故障码，能大大增加可用故障码数量。2)当前基于J1979标准的每个故障码ECU只输出一个冻结帧，且有优先级的区别，不利于维修和监管。而J1979-2可提供更多的冻结帧信息。3)当前基于J1979标准的就绪状态组数量有限，且无法详细到故障码级别。而J1979-2可拓展更多的就绪状态组，且可实现精确到DTC的就绪状态输出。4)当前基于J1979标准的测试结果标准化程度不够。而J1979-2可实现精确到DTC的测试结果输出，方便监管和维修。5)当前基于J1979标准的在用车检测频率指标(IUMPR)只能按组输出。而J1979-2可实现精确到DTC的IUMPR结果输出。

为此，CARB批准自MY23开始HD/MD车型以逐步过渡的方式采用J1979-2标准，到MY27要求100% 的产品采用J1979-2。尽管J1979-2标准正式发布时间不长，但已受到行业的高度关注。中国同样关注到了J1979-2的应用趋势。

2 J1979-2介绍

J1979-2《E/E diagnostic test modes:OBD-onUDS》可以理解为基于UDS协议的OBD诊断测试模式，正式版于2021年4月发布。J1979-2并非对J1979推翻重来，也不是简单地将J1979中的Service$01～$0A映射成UDS服务，而是基于UDS协议针对J1979支持的诊断服务(Mode$1～$A)进行升级和扩充。

UDS协议(ISO 14229)在汽车行业其实不是新技术，OBD也不是新功能，但两者的结合目前还是较新的要求。相比于排放OBD专用诊断服务(只针对与排放相关的控制器)，UDS协议的最大特点在于U即Unified。UDS面向整车所有ECU，且支持多种总线技术。目前的主要排放控制器如ECU、TCU等实际上已支持UDS标准，但为满足排放法规还要开发一组功能用于满足J1979。

无论是J1979-2还是J1979，定义的都是车载OBD系统与外部通用设备之间的通信，故可将其通信架构映射到开放系统互连(OSI)模型(ISO/IEC 7498-1和ISO/IEC 10731)进行介绍，进而清晰地展示J1979-2与J1979在通信方面的差异(见图1)。

图1 基于OSI架构的通信方式对比

以目前汽车行业内最常见的CAN总线为例，从物理层(Layer1)到传输层(Layer4)都是基于ISO 15765-4标准(功能上J1979/15031-5还支持SAE J1850、ISO 9141-2、ISO 14230-1/2等数据链路层和物理层，但技术较老，当今汽车行业已不再开发，故未在图1中列出)。两标准中会话层(Layer5)都是基于ISO 14229-2标准，表示层(Layer6)除J1979-2新增了SAE J1939-DA外，其他3种通信方式都一样。J1979-2相对于J1979的主要变化在于应用层(Layer7)，J1979-2的通信方式从J1979的ISO 15031-5/SAE J1979切换为ISO 14229-1/SAE J1979-2。此外，J1979-2还可以拓展到以太网总线技术，以适应更新更快的通信需求。综上，OBD诊断服务标准的更新其实只是对通信架构应用层的更新，基础通信层Layer1～Layer4保持不变，因而能大大降低技术升级的成本，可以将软硬件开发解耦，通过软件升级即可实现新标准。J1979与J1979-2的OBD诊断服务对比见表1。

从表1可以看出：J1979-2采用UDS协议ISO 14229-1中的4种服务实现了J1979的9种服务，其中J1979不具备的3种服务就是J1979-2的典型升级内容。

表1 J1979与J1979-2的诊断服务映射关系

3 OBD诊断服务实现方式对比

为便于阅读，基于J1979的诊断服务顺序(Service$01～Service$0A)进行诊断服务对比，最后补充J1979-2新增的3种诊断服务。研究内容基于J1979-2和对应的SAE J1979-DA，以CAN总线通信方式为基础，Layer1～Layer4基于ISO 15765-4协议。

3.1 Service$01请求动力总成诊断数据

J1979、J1979-2中Service$01对比见表2。

表2 Service$01对比

J1979中动力总成诊断数据通过Service$01和PID(Parameter identification)获取，PID数据长度为1 B，范围为$00～$FF。其中$00、$20、$40等并不表征实际的物理量，而是用来表征ECU对后面连续32个PID的支持情况。这种逻辑同样适用于下文中Service$06的MID/TID、Service$09的Infotype。

J1979-2动力总成诊断数据通过UDS协议的Service$22和DID获取，DID数据长度为2 B，范围为$F400～$F5FF。其中$F400、$F420、$F440等并不表征实际参数，而是用来表征ECU对后面连续32个DID的支持情况。这种逻辑同样适用于下文中MID/TID/ITID。ISO 14229-1附录C.1中预留了$F700～$F7FF的区间给OBD，但目前SAE J1979-DA中暂未使用。

DID其实是UDS协议中一个通用概念，与J1979的区别是，DID的区间在ISO 14229-1附录C.1中作了详尽分类，预留了专用区间给OBD法规使用。因此，在J1979-2中，MID/TID/ITID都属于DID，但其值不会重复，可直观地理解为J1979-2中High byte=F4/F5/F7的DID都用于Service$01。关于PID/DID的支持数量，两标准对ECU的响应要求一样，J1979要求ECU至少响应6个PID，J1979-2根据请求类型进行分类，要求物理请求的ECU至少响应6个DID、功能请求的ECU至少响应3个DID。PID/DID的定义参考SAE J1979-DA、Annex B-Parameter IDs。

3.2 Service$02请求动力总成的冻结帧数据

冻结帧信息的功能是提供出现排放故障时刻的必要数据信息，OBD标准中称为Freeze frame，UDS协议中称为Snapshot。冻结帧信息是J1979-2相比于J1979升级比较明显的服务，其主要变化见表3。

表3 J1979-2关于冻结帧功能的升级

冻结帧的信息需要结合排放法规来设置，以GB 18352.6—2016为例，失火和燃油系统具有更高的冻结帧优先级，若下一阶段从J1979切换成J1979-2，则企业无需再给失火和燃油系统的故障设置优先级。同样，原法规中针对失火和燃油系统专门设置的相似工况等要求也要酌情考虑调整。两标准中Service$02对比见表4。

表4 Service$02对比

J1979中冻结帧通过Service$02读取。J1979-2中冻结帧通过UDS的Service$19～SF$04读取，DTC snapshot record number为冻结帧序号，长度为1 B，UDS协议对其进行划分，其中$00、$F0用于OBD，与J1979-2对应：$00为首次出现的冻结帧，$F0为最近一次出现的冻结帧。

3.3 Service$03/$07请求排放相关的DTC

基于UDS协议的J1979-2在读取排放故障码服务方面相比J1979有进一步提升，但实现方式接近。考虑到Service$07和Service$03在功能上完全一致，合并在一起介绍。

J1979-2要求乘用车/轻型车使用SAE J2012-DA_DTC format_04格式的故障码，DTC format identifier=0x04，该格式的故障码为3 B DTC，具体信息参考SAE J2012-DA/ISO 15031-6。J1979要求的故障码为2 B格式的故障码。这是J1979-2中一个典型的故障码格式升级。

除故障码格式差异外，J1979-2可利用UDS协议的优势，根据故障码的状态和属性即DTC severity mask record对故障码进行精确筛选。J1979中未决故障码(Pending DTC)通过Service$07读取，确认故障码(Confirmed DTC)通过Service$03读取。J1979-2中未决故障码和确认故障码都是通过UDS的Service$19～SF$42读取，除保留原先的故障码读取功能外，还通过DTC status mask和DTC severity mask增加了筛选的功能。两标准中Service$03/$07对比见表5。

表5 Service$03/$07对比

FGID：功能组ID，按照UDS协议的定义，排放组为33。

DTC status mask：ISO 14229-1中详细定义了每一位的意思，其中bit2表示未决故障码，bit3表示确认故障码，DTC status mask =0x04表示可以请求未决故障码，DTC status mask =0x08表示可以请求确认故障码。

DTC severity mask：ISO 14229-1中详细定义了每一位的意思，高3位用来定义DTC severity information，低5位用来定义DTC class information，其中bit1表示故障等级是DTC class_1，这个是必须支持的故障等级，故Byte#5可以直接定义成0x02。

除完成常规的Pending DTC和Confirmed DTC获取外，测试员还可通过DTC status mask和DTC severity mask筛选其他属性的故障码。

3.4 Service$04清除排放相关诊断信息

故障清除功能在J1979-2中没有明显变化(见表6)。

表6 Service$04对比

J1979中清除排放相关故障码通过Service$04实现。J1979-2中清除排放相关故障码通过Service$14实现。尽管UDS协议中Service$14支持多种清除功能(包括清除特定的DTC)，但J1979-2只要求其中两种，分别为删除排放组(0x33)的故障码和删除所有(0xFF)的故障码。

3.5 Service$06请求监测系统诊断结果

J1979和J1979-2通过MID读取诊断结果的功能没有明显差异，都使用OBDMID(On-board diagnostic monitor ID)和相应的TID(Manufacturer defined test IDs)，两者的对比见表7。J1979-2新增的测试结果读取功能见3.9节。

表7 Service$06对比

J1979中通过Service$06读取诊断结果，MID数据长度为1 B，范围为$00～$FF。J1979-2中通过UDS的Service$22读取诊断结果，定义的MID(DID)数据长度为2 B，范围为$F600～$F6FF，可以直观地理解为High byte=F6的DID都用于Service$06。MID和TID的定义参考SAE J1979-DA、Annex D-Monitor IDs和Annex C-Test IDs。

3.6 Service$08请求控制OBD系统

对于OBD系统的控制请求，J1979和J1979-2定义较少，更多的功能都是原始设备制造商(OEM)开发和定义的，通过UDS协议的Service$31实现。两者的对比见表8。

表8 Service$08对比

J1979中控制OBD系统通过Service$08实现，定义的TID数据长度为1 B，范围为$00～$FF。J1979-2中控制OBD系统通过UDS协议的Service$31～SF$01实现，定义的RID数据长度为2 B，范围为$E001～$E1FF。RID的定义参考SAE J1979-DA、Annex F-Test-Routine IDs。

3.7 Service$09请求车辆信息

J1979、J1979-2中车辆信息都使用ITID(Infotype IDs)，常规的车辆信息读取功能没有明显差异，两者的对比见表9。J1979-2新增的IUMPR读取功能见3.9节。

表9 Service$09对比

J1979中车辆信息通过Service$09读取，定义的ITID数据长度为1 B，范围为$00～$FF。J1979-2中车辆信息通过UDS的Service$22(Read data by identifier)读取，定义的ITID(DID)数据长度为2 B，范围为$F800～$F8FF，可以直观地理解为High byte=F8的DID都用于Service$09。

对于外部测试设备，需测试排放控制器支持的标准，连接后需测试支持的协议，使用Service$22搭配ITID$F810。如果车辆上与排放相关的ECU支持J1979-2中至少一种UDS协议，就应在$F810输出0x01。ITID的定义参考SAE J1979-DA、Annex G-Infotype IDs。

3.8 Service$0A请求永久故障码

两标准中Service$0A的对比见表10。J1979中永久故障码的读取通过Service$0A实现，其功能与Service$03和Service$07类似。J1979-2中永久故障码通过基于UDS协议的Service$19～SF$55读取。

表10 Service$0A对比

3.9 J1979-2新增的OBD诊断服务

基于J1979的OBD诊断服务存在以下问题：1)Service$06按照MID和TID输出测试结果，由于很多TID是企业自定义的，在缺少相关资料的情况下监管部门和维修人员很难确认测试结果与监测项之间的关系。另外，测试结果展示的具体数值还能用来衡量其与故障阈值的距离，具有故障预判、维修验证等功能，如果能有针对性地获得排放相关故障码的测试结果，将大大提高车辆检查和维修效率。2)Service$09按照组的形式报告IUMPR结果，输出的Ratio是该组中最小的值，无法有针对性地读取排放相关故障码的IUMPR结果，且法规定义为跟踪需求的一些诊断并不会输出到GST。例如在进行OBD演示试验时，会出现演示项的Ratio并非该IUMPR组最小值的情况，导致分子增长无法体现在Service$09中。按照C6 OBD实施细则的要求，出现这类情况需要企业截图证明分子增长。如果能有针对性地读取每个有IUMPR要求的监测项的结果，则能大大提高监管效率。3)最近一次清除存储的故障代码后的诊断就绪状态(Readiness)按照组的形式通过PID$01展示，如果小组显示未完成，很难发现具体是哪些诊断未完成，给排放检验与维护带来困难。如GB 18285—2018第7.3节规定，在用车检查时若就绪状态未完成项超过2项，则要求车主在对车辆充分行驶后进行复检，而当前基于J1979的就绪状态展示的是组的就绪状态而非单个诊断的就绪状态，导致车主无法高效地对车辆进行行驶以满足就绪状态要求。

J1979-2能有效解决以上问题。基于UDS协议的Service$19的下属子功能SF$1A和SF$06可有效解决上述问题1和问题2，而且存在进一步扩展功能的可能；Service$19的下属子功能SF$56可按照就绪状态组获得该组所有故障码相应的诊断状态，确认单个诊断的就绪状态，有效解决上述问题3。

请求支持的DTC扩展记录信息(Request supported DTC extended record information)功能通过基于UDS协议的Service$19～SF$1A(Report DTC extended data record identification)实现，可基于检验员指定的DTC extended data record number返回支持该拓展信息的故障码列表和对应状态(Status of DTC)，为SF$06提供基础信息。实现方式如下：

Byte#1:0x19

Byte#2:0x1A

Byte#3:0x90～0x9F(DTC extended data record number)

DTC extended data record number指定的扩展信息序号长度为1 B，范围为$00～$FF。ISO 14229-1附录D.8中对其有详细定义，其中0x90～0x9F段留给OBD，与SAE J1979-DA的Annex I-extended data items对应。典型的DTC extended data record number如下：

0x91:DTC based IUMPR

0x92:DTC based test result

3.9.2 请求支持的DTC扩展数据记录

请求支持的DTC扩展数据记录(Request DTC extended data record)功能通过基于UDS协议的Service$19～SF$06(Report DTC extended data record by DTC number)实现，除可基于检验员指定的DTC extended data record number返回支持该信息的故障码列表和故障状态外，还能返回其对应的数据记录(DTC extended data record)，这个功能很重要。在使用SF$06之前，先要通过SF$1A确认哪些DTC支持指定的DTC extended data record number。实现方式如下：

首先，应当制定促进科技发展方面的立法。比如，我国制定《科技促进法》、《科技人才促进法》等促进科技发展的法律，为科技发展提供制度环境。其次，应当完善已有的科技相关法律。比如，应当从促进科技发展的角度出发，完善《著作权法》、《专利法》、《商标法》、《网络安全法》等，为科技创新保驾护航，同时维护科研人员的智慧成果，激发其创新的积极性。最后，制定和完善规范科技运行的法律。比如，我国可以制定《科技伦理法》，对科技工作者和科学研究活动提出伦理性要求，禁止他们从事有违社会伦理道德的科研活动。另外，还可以制定法律禁止科学研究用于违法的行为。

Byte#1:0x19

Byte#2:0x06

Byte#3:DTC high byte

Byte#4:DTC middle byte

Byte#5:DTC low byte

Byte#6:0x90～0x9F

通过该子功能，可按照故障码获取相应的IUMPR信息和测试结果，从而大大拓展获取信息的渠道，作为Service$06和Service$09的补充。如确认某个DTC P1234-56支持0x91/0x92，即可通过SF$06请求P1234-56的DTC extended data record，获取该诊断的IUMPR信息和测试结果。

3.9.3 请求某就绪状态组的故障信息

请求某就绪状态组的故障信息(Request DTCs for a readiness group)功能通过基于UDS协议的Service$19～SF$56(Report DTC extended data record by DTC number)实现，可基于检验员指定的Readiness group identifier返回一个支持该信息的故障码列表及其故障状态(Status of DTC)。实现方式如下：

Byte#1:0x19

Byte#2:0x56

Byte#3:0x00～0xFE(RGID)

RGID(Readiness group identifier)参考SAE J1979-DA。通过该子功能，可按照就绪状态组获取组内每个DTC的诊断状态。如发现RGID$07显示未完成，可通过SF$56查看是由该组哪些诊断未完成导致的。

4 展望

新标准的实施除政策引导外，还需要原始设备制造商和相关配套标准一起推进。如Vector公司在2021年底宣布完成可满足J1979-2标准的ECU开发工具和测试设备。此外，与J1979-2配套的技术标准如SAE J2012、SAE J1699-3等都需作相应调整。

J1979-2相比于J1979的变化主要是对传统动力车辆OBD诊断服务的升级，从技术角度也能对纯电动汽车(BEV)的监管产生启示作用。尽管传统意义上的OBD只是针对车载污染物排放的控制，而BEV本身并不包含污染物排放源，但BEV由于性能下降/恶化间接导致的污染物影响不应被忽视，无论是从“实际表现偏离设计意图”等原则性角度定义BEV的OBD功能，还是从具象的BEV性能相关综合零部件诊断，相关的功能均不应被放弃，也需以与时俱进的标准化诊断服务作为保障。而OBDonUDS可很好地兼容内燃机车和BEV控制器应用层的数据标准化要求，且支持多种目前主流总线通信技术，可以为提出BEV的OBD监管需求提供技术基础。

5 结语

随着排放法规的不断更新，OBD诊断服务标准因不同市场、不同车型导致诊断工具和控制器软件不同的情况有望在引入J1979-2后得到统一。从当前OBD诊断服务/测试模式标准的局限性、J1979-2的功能和优势及实现方式三方面进行研究，J1979-2标准在保留J1979标准功能的基础上进行升级，具有提供更多OBD信息的拓展性，且原始设备制造商针对J1979-2的软件技术升级的成本较低，具有较高的应用价值。随着J1979-2的升级，预计基于UDS协议的OBD诊断服务还会拓展出更多功能，同时可为实现BEV的OBD服务提供技术基础。相信J1979-2的应用能为污染物排放监管带来更高的环保收益，并提高车辆维修效率，建议将它作为中国下一阶段排放法规OBD部分的应用标准。