怎么区分某个app发出来的报文

以太网帧头：目的mac+源mac+报文类型。对应ip包而言，报文类型是0800，所以0800是以太网帧头的结尾部分
IP报文头：大部分都是以4500开头的，4表示ipv4版本，5表示IP头长度是5个LW（20bytes），00是用来表示报文优先级的。可以通过找4500来确定ip头的起始位置
>如果遇到Modbus报文通信故障，可以从以下几个方面开始排查：
1、确认通讯设备：确认modbus报文是否能够被发送站接收，能否发出报文。
2、检查传输设备：检查用于传输modbus报文的串口、网络或无线设备等是否工作正常，是否有网络中断或其他故障。
3、检查映射：使用静态映射时，检查站外地址模式是否正确，通过动态映射是否能够正常地读写数据。
4、检查数据格式：检查数据值的格式是否正确，确认数据的长度和其他参数的准确性。
5、检查同步：检查报文的时序是否正常，确认报文的校验字段是否正确，以及报文长度是否正确。
通过以上这些检查，可以确定通讯故障的中原因，以便维修modbus报文通信。

UDS（Unified Diagnostic Services，统一的诊断服务）诊断协议是ISO 15765 和ISO 14229 定义的一种汽车通用诊断协议，位于OSI模型中的应用层，它可在不同的汽车总线（例如CAN, LIN, Flexray, Ethernet 和 K-line）上实现。UDS协议的应用层定义是ISO 14229-1，目前大部分汽车厂商均采用UDS on CAN的诊断协议。

UDS本质上是一系列的服务，共包含6大类26种。每种服务都有自己独立的ID，即SID。

肯定响应和否定响应的形式一定要熟记。

UDS的26种服务中，有7种很重要。它们分别是：

下面对这7个服务进行解读。

$10包含3个子功能，

ECU上电时，进入的是默认会话（Default）。如果您进入了一个非默认会话的状态，一个定时器会运转，如果一段时间内没有请求，那么到时间后，诊断退回到默认会话01 。当然，我们有一个$3E的服务，可以使诊断保持在非默认的状态。

报文包含4种类型 ，即

NRC：Negative Response Code（否定响应码) 。如果ECU拒绝了一个请求，它会回应一个NRC。不同的NRC有不同的含义。

八个数据字节，第一字节被网络层占用 。

02中的0代表网络层单帧SF，2代表 数据域有2个字节； 10是SID，02是子功能 。

02同上，10+40表示对SID的肯定回复，02是子功能。

03同上，7F表示否定响应，10是SID，22是NRC。

$3E服务用于向服务器指示诊断仪仍然连接在网络上，之前已经激活的诊断服务功能可以仍然保持激活状态。

例子：

27服务，加上一个子服务，再加上一个钥匙，这样的服务请求可以进行解锁。

比如下面的例子，2n-1是某个子服务，通过首轮种子的请求，首轮ECU会返回67+01+AA+BB+CC+DD，AA~DD就是种子了。之后第二轮，诊断端会利用种子进行运算（利用整车厂的算法），生成k1（不一定是1个字节），那么发送请求，27+02+[k1]。ECU同样也会通过种子算出k2。当k1和k2匹配时，解锁（Unlocked）成功。

$22读数据，
Request（请求）：

Response（响应）：

DID有一部分已经被ISO 14229-1规定了。比如0xF186就是当前诊断会话数据标识符，0xF187就是车厂备件号数据标识符，0xF188就是车厂ECU软件号码数据ID，0xF189就是车厂ECU软件版本号数据标识符。

$22写数据，
Request（请求）：

Response（响应）：

注意，比如0xF186这个DID不支持直接写入数据，需要用$10来进行会话转换。也就是说， 对于写数据的请求，一般来说需要在一个非默认会话，或解锁的状态下才能进行 。

DTC（diagnostic trouble code）：如果系统检测到了一个错误，它将其存储为DTC。DTC可表现为：一个显而易见的故障:通讯信号的丢失（不会使故障灯亮起）；排放相关的故障；安全相关的错误等。DTC可以揭示错误的位置和错误类型。通常DTC占用3个字节，OBD II占用两个字节。

故障码包括四个大类，分别是PCBU，P是powertrain动力系统，C是Chassis底盘，B是Body车身，U是network通信系统。一个DTC信息占用4个字节。最后一个字节是DTC的状态 。前两个字节是我们熟知的类似P0047的故障码。

$19 拥有28个子服务（Sub-Function）。常用的子服务有02（通过DTC状态掩码读取DTC），04（读取快照信息），06（读取扩展信息），0A（读ECU支持的所有DTC数据）。

清除（复位）DTC格式，它可以改变DTC的状态。3个FF代表清除所有DTC。

UDS 的诊断数据的发送与接收都是基于CAN，所以每个数据流都包含基本的CAN Message 的架构

根据上篇UDS文章的叙述，每一个PDU 包含控制信息PCI,数据信息Data

网络层 PDU（协议数据单元）PCI（协议控制信息）格式：具体如下图所示：

综上所述， N_PDU =N_PCI+N_DATA , N_PCI 的值主要集中的 前三个字节 ， N_DATA 值主要集中在 后面7位字节 。其中，

先面用连个例子进行说明，请参考！

[上传失败(image-b66bab-1538824826939)]

由于这个数据发送与接收都是单帧传输，所以第一个数据的高四位均为0，四个数据流中的第一个字节的低四位，02，03，02，06代表的为此帧数据含有几个字节，多余的数据位都用 00或者AA行填充。

[上传失败(image-b5e84b-1538824826939)]

数据发送为单帧，所以06代表发送的数据中含有6个字节，

回复为Positive Response，为连续帧。

参考资料：

---