UDS服务基础篇之2F
前言
在汽车ECU诊断服务开发的过程中，有很多常见的诊断服务，比如10, 11, 22, 2E等，但是对于2F服务则会显得有些陌生，因为这类诊断服务主要在车身域比较常见，比如车窗控制，传感器开关、执行器控制等。除此以外，在其他车身域也有不同程度的使用，只不过相对较少。
接下来，让我们带着下列思考一起来了解一下这个较为神秘的2F服务吧！
-
2F服务是做什么的呢？
-
它的诊断服务请求及回复是怎样一种方式？
-
与31服务Routine Control相比，又有什么区别呢？
这篇，我们来一起探索并回答这些问题。为了便于大家理解，以下是本文的主题大纲：
正文
UDS诊断服务协议都以ISO标准ISO14229-1来集中体现，如需了解其他更多诊断服务的精彩使用，可以参考此文档，本文以**ISO14229-1（2020）**协议作为参考来解读2F服务。
服务功能
功能描述
2F服务作为输入输出控制服务，其全称为InputOutControlByIdentifier。该服务是用于client主动请求server去对相关输入输出信号进行控制。所谓的输入输出控制简而言之就是屏蔽实际的输入输出信号值，取而代之的是client主动以某种特定的控制方式去设置这些信号值。
2F服务会对所需要受控的信号进行编组，同时分配一个特定的DataIdentifier(即DID)来实现1个或多个信号参数的控制。但有时发送2F诊断服务时我们不需要对所有信号进行控制，那么此时我们可以引入controlEnableMask来实现只对特定信号的控制，后文会举出实例来体现该参数的使用。
有小伙伴们在此会发问了，虽然可以对信号进行控制，但是怎么知道软件内部有没有真正的起作用呢。
别着急，此时要引入一个新的服务22(ReadDataByIdentifier)，该服务可以通过信号所在的DID去获取对应的数值，然后与2F请求设置的数值比较是否相同，进而便可以知道2F控制是否生效。
本文不会对22服务展开，只会提到其基本使用，具体细节可参考上文提到的协议标准。也就意味着支持2F的DID必然支持22服务，反之则不然。
一般而言，2F服务主要用于较为简单的输入输出控制，而更为复杂的输入输出控制使用31(Routine Control)服务则更为合适。
如下图1所示，较为清晰的描述了2F服务的主体功能:
应用场景
2F服务主要针对输入输出控制，列举常见的使用场景如下：
- 车窗的升降控制；（OutputControl）
- 直连执行器的启动与停止；（OutputControl）
- 车灯的开启与关闭；（OutputControl）
- ADAS相关功能的配置开启与关闭；（InputControl）
- LED报警灯的驱动与关闭；（OutputControl）
服务请求
所谓服务请求就是客户端（以下统称为Tester）按照UDS协议规范来发送一系列诊断指令，等待ECU（以下统称为Server）响应的过程。
请求格式
如下图2所示，Tester需要按照以下的格式要求来发送至Server：
诊断请求格式中包含四大部分：
-
SID: 诊断服务2F的标识符；
-
DataIdenfier: 服务请求受控cs所分配的DID；
-
ControlOptionRecord: 表示控制模式及控制的相关参数组成的数据集；
- IOCP: 控制模式；
- CS：需要被控制的参数；
-
controlEnableMaskRecord: 若CS参数个数超过1个时，此时可以使用CM来实现对不同参数的控制，但只有1个CS参数时，则不应该使用CM参数，否则会回复NRC13表示请求的长度不满足要求。
控制参数(IOCP)
控制参数IOCP是一种控制输入输出的控制模式，如下图3所示，有以下4种控制模式：
在使用4个参数时，需注意以下两点内容：
- IOCP参数并不是2F服务的子服务，2F服务没有子服务，这点要明确；
- 在使用00 ，01，02时，诊断请求不需要加入受控参数controlState参数以及enable Mask，只需执行诊断请求 2F + DID +Byte Number,但其诊断回复还是要带有该DID所控制的参数的值;
- IOCP中的4个参数并不是都需要支持，取决于客户需要，一般而言，00，03都会支持，其余两项可选；
请求实例
1. 单参数控制
以控制发动机进风门位置为例，以DID（9B00）控制该参数，转化关系为：Air Inlet Door Position [%] = decimal(Hex) × 1 [%]。
Tester请求控制该参数值达到0x3C，发送指令如下图4所示：
其中，0x2F为诊断请求SID，0x9B00为受控参数的DID，0x03为表示开启对该参数的控制，0x3C表示控制该参数的值达到0x3C。
有时候，当不断使用22服务去检查是否达到请求设定的值时，会发现并没有立马达到，因为有时候受控过程本身就是一个逐渐变化的过程，所以只要经过一定的合理时间并最终达到设定的值，那么就没有问题。
2.多参数控制
当受控参数超过1个时，此时我们有必要引入controlEnableMask来实现对不同受控参数的自由控制。
其基本原理就是将对应参数与controlEnableMask的bit位进行一对一Mapping，若bit位为1，则表明对应的参数将受控，若为0，则表明对应的参数不受控。
如下图5所示，DID(0x0155)控制了5个参数：IAC，RPM，PPA，PPB，EGR。这5个参数在controlEnableMask中的对应关系展示如下：
这里以仅控制IAC参数为例，由上可知，按照bitMap关系，可得出此时的controlEnableMask为0x80，即下图6所示：
在执行2F服务多参数请求，有以下几点内容需要注意：
- 受控的第1个参数必须对应controlEnableMask的最高位，其余参数按照排列顺序逐位类推；
- 当仅需要控制某个参数或多个参数时，controlEnableMask中未置位的对应参数的值将不会受到控制；
服务响应
服务响应表示的是Server接收到来自Tester的诊断请求之后，按照UDS诊断规范回复的诊断响应。
响应格式
如下图7所示，Server的诊断响应格式（positive response）如下：
诊断响应由以下
- Response SID： Positive Response SID = request SID + 0x40 （即0x2F + 0x40 = 0x6F）；
- Data Identifier： 与诊断请求一致的DID；
- **ControlOptionRecord：**表示控制模式及控制的相关参数组成的数据集；
- IOCP： 与诊断请求相同；
- CS： 与诊断请求的控制参数相同，其顺序也应当一致；
相比诊断请求，我们会发现2F服务的诊断响应中不会包含controlEnableMask，无论诊断请求是否包含Mask。有时候测试的过程中容易犯这个错误，所以在此提个醒，防止翻车。
正响应实例
1.单参数控制
在上述诊断请求中，使用DID(0x9B00)来控制进气门参数，Server回复的正响应格式如下图8所示：
可见，进气门的控制是一个渐变的过程，达到诊断请求设定的值需要一定的时间，所以此时给到的正响应并不是设定的值，而是当前的实时值，此时便可以通过22服务不断去读取该DID是否达到了诊断请求的值。
2.多参数控制
当控制参数为多个时，针对如上所述的2F服务多参数请求，相应的诊断响应如下图9所示：
针对2F服务的多参数请求，诊断响应的参数值无论是否被请求控制，都应该给出实时值，只不过受控参数IAC的值应最终与请求的值相同而已。
负响应NRC支持
有时候，由于诊断请求中的长度不对，准入条件不满足等原因，并不是每次诊断请求都会回复正响应。
因此为了识别到到底是哪类错误，UDS统一用**NRC(Negative Response Code)**来表征所有诊断服务使用的错误类型，以便于更好的定位并排查问题，且所有的诊断服务都会存在负响应，。
那么对于2F服务负响应的格式如下：
诊断服务负响应格式： 0x7F + Request SID + NRC。
以此类推，2F服务诊断服务负响应： 0x7F + 0x2F + NRC。
UDS定义NRC为导致当前诊断服务无法正常进行的原因。对于2F支持的NRC有哪些呢，请看如下表1所示：
上述列出的NRC并不是需要全部支持，取决于具体的使用场景及客户需求。
比如以下场景：
- 若没有为2F服务设置使能条件，那么就不需要NRC22，反之若支持NRC22，必须列出相应的使能条件；
- 若请求的DID并不需要安全解锁，那么就不需要支持NRC33，反之若支持NRC33，则至少存在一个DID在执行2F服务时需要安全解锁，NRC34同理；
- NRC13, NRC31则必须支持；
- 当多种错误同时发生时，UDS协议规定了NRC的优先级，具体细节可查看IS014229-1标准文档。
- NRC优先级如下图10所示，可用于测试参考验证；
往期精彩：
AUTOSAR基础篇之BswM
AUTOSAR基础篇之Event
UDS之时间参数总结篇
AUTOSAR基础篇之FiM
深夜码字不易，恳请多多点赞，关注，转发，收藏！
更多精彩内容，敬请关注微信公众号“ADAS与ECU之吾见”！ 扫码轻松关注：
公众号后台回复关键字“加群”，便可免费加入AUTOSAR技术交流群，共同探讨CP，AP，SOA，信息与功能安全等前言热点话题！
