本来应该是接着之前的一篇文章继续写《UDS（ISO14229)诊断协议（三）》呢，恰巧小编今天的工作内容涉及到了UDSonLIN，所以就想着正好今天就先写写这个方面的话题吧，虽然这部分内容是UDS第七部分的内容，但是和前面部分的关联性不是特别的强，所以是可以单独查看的。
UDSonLIN实现的需求
首先说明一点，LIN的诊断规范是遵循ISO17987的，所以UDS的LIN诊断是把14229定义的会话层协议做了必要的更改和接口适配以适用ISO17987.
在具体的实现层面，整车制造商应该根据ISO17987的协议制定LIN主节点和从节点之间交互的UDSonLIN的信息。
定义诊断等级
LIN通讯从节点的架构、诊断通讯表现和需要的传输协议根据诊断服务功能分为三个等级，所以，要根据从节点诊断功能和复杂性的等级分配诊断等级。
诊断等级一
智能和简单的设备，比如像智能传感器和执行器，不需要诊断功能或者很少的诊断功能。执行器的控制、传感器的读取以及故障存储的处理都是由主节点通过帧的信号完成的。因此，对于这些任务，具体的诊断支持是不需要的。故障指示也通常是基于信号的。
诊断等级二
诊断等级二和诊断等级一从节点是类似的，但是诊断等级二需要支持节点标识。这个扩展的节点标识是车辆制造商需要的。使用ISO14229诊断服务的测试设备或者主节点可以请求扩展的节点标识信息。执行器的控制、传感器的读取以及故障存储的处理都是由主节点通过帧的信号完成的。因此，对于这些任务，具体的诊断支持是不需要的。故障指示也通常是基于信号的。
诊断等级三
诊断等级三从节点是带有增强应用功能的设备，比较典型的是执行本身信息的处理（比如，功能的控制，本身传感器和执行器的闭环）。从节点执行的任务超过了基本的传感器和执行器功能，因此需要扩展的诊断支持。直接执行器控制和传感器的raw value一般不通过LIN的frame和主节点进行交互。ISO14229的I/O控制、传感器数值读取以及参数配置都需要。
诊断等级三有内部的故障管理，同时具有相关的读取和清楚故障功能。作为可选项，从节点也可能支持刷写程序，这需要实现bootloader和必要的诊断服务区解锁程序进行初始化和数据的传输。
诊断等级二和诊断等级三最主要的区别是从节点和主节点诊断能力的分配。
LIN节点的需求
主节点需求
主节点在大多的实现中都是高性能的ECU，一般都支持UDS的诊断服务。主节点和外部的设备通过主网络连接，主节点应该可以通过主网络接收从节点的所有诊断服务，然后把这些诊断信息路由给合适的LIN网络。然后，从节点的响应再由主节点路由回主网络。
所有从节点的诊断请求和响应消息都可以在网络层路由（不是应用层）。主节点应该实现LIN的传输协议（ISO17987)以及主网络的传输协议(ISO15765-2）。
主节点的故障管理、传感器读取和I/O控制
诊断等级一和诊断等级二从节点提供基于信号的故障信息并且通过LIN帧的信号访问传感器和I/O。那么主节点就有义务处理从节点基于故障的信号和相应的DTC，LIN的主节点服务于外部测试设备的直接UDS请求服务，然后作为一个诊断应用层的网关。UDS服务提供LIN线访问传感器和执行器信号。
诊断等级三的从节点独立于诊断入口，LIN的主节点不实现诊断功能对于具备诊断等级三的从节点。
从节点的需求
从节点一般是不包含复杂数据通信的电子设备，同样从节点需要发送的诊断数据也非常少。因此，大部分的从节点应该发送简单的诊断信息，比如通过帧信号发送错误状态。
尽管诊断和节点配置服务使用的同一个frameID，0x3C主节点请求的frameID，0x3D从节点响应的frameID，配置和诊断使用不同的服务。节点配置可以由主节点单独的执行，而诊断一般是路由外部或者内部测试设备的诊断请求。两个情况使用相同的NAD（节点地址）和传输协议，不同的是配置一般使用单帧（SF）。只有从节点有节点地址。
基于信号的诊断
从节点实现
基于信号的诊断由诊断等级为一和二的从节点实现，这样的从节点没有故障存储和可以直接通过外部设备读取故障信息的协议。
一般通过帧信号发送故障状态有两种类型：
（1）周期性的发送，这种故障状态定义在现有的周期帧当中；
（2）非周期发送；
每一个从节点应该发送由从节点监控的故障信息给到主节点，通过LIN的帧的信号。这些状态信息应该包含当前从节点组件的失效状态，这些信号应该支持以下的状态定义：
如果一个组件实现多个功能，可以为每一个功能分配一个状态信号。
主节点的实现
失效状态信号应该分配给每一个可以在主节点产生独立DTC的失效。
这个信息用来给主节点指示一个组件的失效，然后用来存储相应的DTC。
UDSonLIN服务实现
UDSonLIN的服务概览
下面的这张图中显示的是所有可用于UDSonLIN实现的服务。它是所有可用服务的汇总。
使用ISO14229这一部分的具体应用实现UDSonLIN可能会受可用服务数量的限制以及分配它们到具体的应用区域和诊断部分（默认会话/编程会话）。所有诊断数据的长度限制是由数据链路层应用决定的。
诊断和通讯控制功能单元
通讯控制服务（0x28）
由上面的图片我们可以看到，通讯控制和对事件的响应是有单独的LIN要求的。这里我们提到的就是通讯控制服务。
通过使能和禁用正常通讯达到两种状态，第一，使能正常通讯的时候就是交错的诊断；第二，禁用正常通讯的时候，就是单纯的诊断。
事件响应服务（0x86）
应用层需求
应用层服务
应用层主要用来定义客户端和服务器这样的系统去执行一些功能，比如测试、检查、监控、诊断或者基于车辆的软件刷写。
UDSonLIN的消息长度是定义在ISO17987-2协议中的。
消息的缓存是由会话层控制并且是由数据链路层请求，当一个消息被监测到并且消息长度是可用的。
在可接受的最大数据定义中，主节点应该和它所有的从节点保持一致，以避免数据的丢失。
在某些具体的额服务中可能会超过最大数据长度限制，比如读取DTC。在这种情况下，ISO14229的否定响应可以被使用。
应用层协议
这一部分的应用层协议和ISO14229-1中定义的协议是一样的。这一部分我们还没有给大家分享完，后期大家可以通过本专栏的文章查看。
应用层时间
LIN的主节点和从节点关于诊断消息的应用时间需求应该根据ISO17987-2的内容进行实现。
P2Server_max这个数值应该根据ISO14229-2会话层的定义处理。
因为排放相关的系统对时间严苛的要求，不建议把LIN总线连接到排放相关的主ECU上，如果LIN从节点对排放相关通讯产生任何影响，例如排放相关通讯的排放相关数据。
车辆制造商有责任保证，如果一个客户端不需要响应消息，服务端可能需要更多的超过P2Server的时间去处理请求消息，客户端连续请求之间应该插入足够的时间。
基于实现的选择，有两种可能性：
1）主节点接收到第一帧数据后立马转发出去；
2）主节点接收到所有的请求再转发给从节点；
主节点有义务使用合适的调度或者调度表提供请求数据给从节点和接收从节点的响应。
下图展示了LIN诊断消息由CAN路由的过程：
传输层/网路层接口适配
协议数据单元TPDU和LIN网络协议数据单元N_PDU的映射。整个协议实现需要参考ISO17987-2，并且需要支持多帧数据的。
其映射关系如下图：
参数的映射如下图：
网路层和OSI更高层地址的映射不是必须的，只需要完全的复制即可。
关于UDSonLIN就和大家分享这么多，如果有什么问题欢迎大家留言。本文首发自公众号《汽车技术馆》。