需要注意的是,不是每一个服务都会有,看情况。对于企业需求规范,可以基于自身需求做详细定义即可。
Annex B
该附录表是关于Service 参数详细定义:
涉及到常规ECU通信和网络管理报文的使能与否。
Annex C
主要是关于DID内容的定义,一个DID表示ECU的一个数据内容,在诊断功能中经常跟Service 22/2E等服务配合使用,在AUTOSAR框架中,Tester发送诊断请求,先到DCM模块,需要获取DID内容时,需要基于RTE关联SWC,形成数据Link关系来获取所需要的数据内容。
对于DID内容,UDS中有如下定义:
主要分为两个内容:
-> 预留了相应区间,给用户自定义;
-> 关于通用的DID,做了声明定义。
需要注意的是在整车级别中,DID数量趋向于不够使用,这个时候可以采取单个DID,定义多重内容,减少DID数据资源。对于单个DID,在RTE端也是一个Runnable,至于这最终反馈什么内容,主要由用户自定义实现。
Annex D
该附录主要是关于DTC相关内容,关于DTC,涉及到不同的协议,对于DTC格式也不尽相同。如下所示:
在OBD关于DTC定义是2个Bytes,UDS协议关于DTC定义3个Bytes长度,特别是在ISO 15031中关于2个Bytes还有具体定义:
在附录表D中,ISO 14229协议定义了诸多内容:
-> groupOfDTC parameter definition;
-> DTCStatusMask and statusOfDTC bit definitions;
-> DTC status bit definitions;
-> DTC severity and class definition;
-> FunctionalGroupIdentifier definition
如果初次接触车载诊断,DTC这点是一个难点,特别是在AUTOSAR框架中,DEM模块关于此处有很多名词,若不理顺,会有很多点不容易理解:
1、DTC Status bit相互转换关系;
2、运行周期、检测周期、检测结果.....相关概念;
3、PreFailed、PrePassed、DTCFaultDetectionCounter等概念;
4、快照信息、扩展类统计数据等记录概念。
这些信息都在该附录表中有详细描述:
Annex E
该附录表主要关于IO Control(Input output control functional unit data-parameter definitions)相关内容定义。
Service 2F详细功能可参看如下链接:
Annex F
该附录表主要讲述Service 31(Routine functional unit data-parameter definitions)相关内容。
定义了Service DID可以应用的范围。关于Service 31具体功能可参看如下链接:
Annex G
主要是关于Upload and download functional unit data-parameter相关定义:
定义了相关参数,具体这边也可参看如下文章:
Annex H
Examples for addressAndLengthFormatIdentifier parameter values,详细如下:
Annex I
该附录表主要讲解Service 27相关内容,定义了ECU从Locked -> Unlocked流程示意图,以及等待时间。
关于Service 27详细内容也可参看如下文章:
Annex J
主要讲述了多Tester(Recommended implementation for multiple client environments)场景: