UDS诊断系列之十一 输入输出控制(2F)服务 上
应粉丝要求,先来更新输入输出控制(2F)服务的内容。
输入输出控制(2F)服务顾名思义就是对输入和输出内容进行控制,这里的输入和输出一般指的是控制器的输入和输出引脚或者设备,例如仪表的各种灯就是仪表控制器的输出,而车内的各种灯光开关则是车身控制器的输入。
一、主要功能和响应规则描述
输入输出控制比较常用的场景就是用来进行一些下线检测,前面提到仪表的各种警告灯,在下线时如果想检查是否能够点亮,不太可能去制造相关的故障或状态来让仪表的灯点亮,所以输入输出控制这个服务就可以用在这里。通过控制仪表控制器的输出变量,来直接控制点亮相关的警告灯,来达到检测目的。
注意这里的控制是强制的,也就是说通过输入输出控制这个服务,可以直接改变原有的状态,不管原来是何种状态,都强制转换到服务所请求的状态,例如请求打开远光灯,那么请求之后无论车内的开关什么状态,远光灯都是打开状态,但是要注意这个控制的值应该在符合其正常或安全的范围内才可以被执行。同时,这里的控制也是临时的,一般输入输出控制仅在扩展会话下支持,且需要先通过安全访问才可以执行,也就是说,一旦按照诊断会话服务所介绍的跳转到了默认会话,那么所有被改变的内容都会恢复到被控制之前的状态。
输入输出控制和后面要说的例程控制(31)服务是不同的,输入输出控制服务仅控制简单的输入和输出状态,而复杂的输入和输出如需要控制发送某个协议信息并且需要进行编码的时候,则需要例程控制服务来进行。
输入输出控制服务会通过一个数据ID以及ID所代表的数据参数来表示其所控制的一个或一类输入或输出内容,这里的数据ID指的是两个字节的ID值,在22读取DID服务的时候会详细说明,假设看到这个服务内容的读者已了解其概念。ID里的数据可以是一个参数(控制一个输入或输出),也可以是多个参数(控制多个输入或输出),当包含多个参数的时候,如果OEM选择支持Control Mask的功能,那么需要一个Control Mask参数来表明本次控制的是ID所包含的参数里的哪一个。这个Mask是按位来排列的,举个例子,mask的第一个字节的最左边也就是最高位代表本次所控制的第一个参数,左边第二个位代表第二个参数,以此类推,每个位表示一个参数,不够一个字节后面用0补齐。Control Mask里的每个位“0”表示本次请求不对该位所对应的参数进行控制,“1”表示本次控制需要控制该位对应的参数。这里写了这么一大段话,着实是比较难理解,后来又不舍得删,下篇会有单独的章节将这个mask的内容。
当控制请求被成功执行或已经到了目标值,那么服务端(ECU)需要给出肯定响应,并且如果请求的控制参数是returnControlToECU的话,即使当前已经是由ECU自己控制被请求的参数了,也应该回肯定响应。这里需要注意的点是第一句话里的被成功执行或者已经到了目标值,为什么是这两种情况呢,因为有些输出控制是没有办法立即达到目标值的,比如发动机转速,如果控制它从当前的800转/分到3000转/分,在响应的时候只能说是开始控制了,但还没达到目标值,而有些控制是可以立即实现的,如开关输入以及灯光控制。
二、应用数据格式
1.请求报文
输入输出控制服务的请求报文格式相对于前面的几个服务更复杂一些,首先第一个字节一样是请求的服务ID;其次第二和第三个字节是数据ID,可以缩写为DID,它用来标记数据的编号,这里可以理解为用来标记后面要控制的一个或多个参数;紧接着后面是controlOptionRecord参数,这里面包含两部分内容,第一部分也就是整个请求的第四个字节inputOutputControlParameter表示控制参数,具体哪些见后面单独的章节,第二部分是controlState,也就是前面所说的要控制的状态参数,这里是1到m个,也就是说可以控制一个或多个,取决于DID如何定义,请求里是否包含这个参数参照后面inputOutputControlParameter章节;最后呢就是这个controlMask了,具体格式后面会有单独章节详细说明。
2.肯定响应报文
肯定响应报文和请求报文格式少了一个参数,第一个字节是肯定响应的服务ID,后面紧跟着DID和inputOutputControlParameter,然后是控制状态,注意没有controlMask参数。需要特殊说明的是controlState参数在这里需要填的数据是当前的状态,如果请求是控制车灯打开,那么这里的状态应该是打开,但如果请求是控制发动机转速,那么这里有可能并不是目标转速,因为控制仅仅是开始执行了,但到目标转速需要时间,而诊断响应的时间要求是50ms,没办法这么短时间一下子变换这么多。另外controlState是否需要ISO标准里说是参考附录E1,实际E1是要求都包含的。
内容太多,分两章说明,敬请谅解。
UDS诊断系列之十一 输入输出控制(2F)服务 下
UDS系列汇总链接
UDS诊断系列之十一 输入输出控制(2F)服务 上相关推荐
- UDS诊断系列之十 DTC控制(85)服务
DTC控制服务的主要作用是控制DTC的状态更新. 一.响应规则 DTC=diagnostic trouble code,DTC的状态是故障信息中的一个字节,用来表示故障当前的状态是正在发生还是仅仅发生 ...
- UDS诊断系列之二 ISO14229协议介绍(上)
ISO14229系列,涵盖了UDS的服务定义以及在各车载总线上的一些特殊应用指导,以及各总线类型所对应的下层协议要求,下面就是该系列中各协议所对应的内容清单. 协议编号 协议名称 协议内容 14229 ...
- UDS诊断系列之五 诊断会话控制(10)服务
诊断会话控制服务,其服务ID是0x10,主要功能为控制服务端的会话模式的切换. 一.诊断会话模式 诊断会话模式分为默认会话模式和非默认会话模式,不同的会话模式所支持的功能.权限.时间参数等等是不一样的 ...
- UDS诊断系列之三 ISO14229协议介绍(下)
上篇主要分享了一些基本概念和响应规则,里面提到了否定响应码,也提到了ISO14229-1的附录A是一张否定响应码的表格,里面详细介绍了否定响应码的具体含义.那么在什么时候给出什么样的否定响应码,这篇里 ...
- UDS诊断系列之四 诊断请求和响应
这一篇重点说一下诊断的请求和响应所包含的信息以及格式要求. 一.诊断数据单元 诊断数据单元一般包含地址信息和应用数据.应用数据长度,其中应用数据会包含服务ID.子功能参数(如果有)和应用数据参数: 1 ...
- UDS诊断系列介绍08-19服务
本文框架 1. 系列介绍 1.1 19服务概述 1.2 DTC故障码定义 1.3 DTC状态位 2. 19服务常用子服务 2.1 19 01服务 2.2 19 02服务 2.3 19 04服务 2.4 ...
- UDS诊断系列之九 诊断仪在线(3E)服务
诊断仪在线服务是一个功能最简单的服务了,它的功能只有一个,就是告诉服务端,也就是ECU,诊断仪仍然还在连接着,服务端不要走神(切换状态). 一.服务介绍 想象一个场景,我要用诊断仪给ECU发送一些数据 ...
- UDS诊断系列介绍10-28服务
本文框架 1. 系列介绍 1.1 28服务概述 2. 28服务请求与应答 2.1 28服务请求 2.2 28服务正响应 2.3 否定应答 3. Autosar系列文章快速链接 1. 系列介绍 UDS( ...
- UDS诊断系列介绍13-31服务
本文框架 1. 系列介绍 1.1 31服务概述 2. 31服务请求与应答 2.1 31服务请求 2.2 31服务正响应 2.3 31服务否定响应 3. Autosar系列文章快速链接 1. 系列介绍 ...
最新文章
- C语言编程题目(三)
- Ogre 编辑器二(用Ogre的地形组件加载天龙八部地形)
- 如何通过IP定位交换机
- 软件工程方法论为我们经软件开发有多大用处?谈谈你的看法。
- Jupyter notebook Ipython 魔法函数 Magic 计算代码(函数)耗时 Timing(%%time %time %timeit)
- Pytorch 张量tensor
- github 国内加速镜像
- VMware 修复 NSA 报告的 0day
- Retrofit + RxJava + OkHttp 让网络请求变的简单-基础篇
- Go语言编程(旧读书笔记)
- ArcMap通过空间校正工具转换BJ-54坐标系到WGS-84坐标系
- 知弥深度清理大师隐私政策
- 小球碰撞python代码_python开发的小球完全弹性碰撞游戏代码_python_脚本之家
- Android常用内存优化方式整理
- pcre2 知:介绍
- 亲爱的热爱的百度云全集资源
- [BZOJ3161]孤舟蓑笠翁
- 【技术知识】SVAC 2.0安全技术浅析
- Thumbnailator的简介和使用范例(图片压缩)
- 【Verilog语法1】加载存储器$readmemh和$readmemb函数的使用