基于ModBus-TCP通信协议规范表达
MODBUS TCP/IP协议规范详细介绍
收藏此信息打印该信息添加：用户发布来源：未知
1．该规范的发展概况
原始版本1997年9月3日作为公共评论的草案。
再版1999年3月29日，即修订版1.0。
没有大的技术改动，仅作了补充说明。增加了附录A和B作为对一些常用执行问题的回应。
该Modbus/TCP规范在万维网上公开发行。它表明开发者的意愿是把它作为工业自动化领
域具有互用性的标准。
既然MODBUS和MODBUS/TCP作为事实上的“实际”标准，而且很多生产商已经实现了它的功能，此规范主要是阐述在互连网上具有普遍可用性的基于TCP通讯协议的MODBUS
报文的特殊编码。
2. 概述
MODBUS/TCP是简单的、中立厂商的用于管理和控制自动化设备的MODBUS系列通讯协议的派生产品。显而易见，它覆盖了使用TCP/IP协议的“Intranet”和“Internet”环境中MODBUS报文的用途。协议的最通用用途是为诸如PLC’s，I/O模块，以及连接其它简单
域总线或I/O模块的网关服务的。
MODBUS/TCP协议是作为一种（实际的）自动化标准发行的。既然MODBUS已经广
为人知，该规范只将别处没有收录的少量信息列入其中。然而，本规范力图阐明MODBU
S中哪种功能对于普通自动化设备的互用性有价值，哪些部分是MODBUS作为可编程的协议交替用于PLC’s的“多余部分”。
它通过将配套报文类型“一致性等级”，区别那些普遍适用的和可选的，特别是那些适用于特殊设备如PLC’s的报文。
2.1 面向连接
在MODBUS中，数据处理传统上是无国界的，使它们对由噪音引起的中断有高的抵抗力，而且在任一端只需要最小的维护信息。
编程操作，另一方面，期望一种面向连接的方法。这种方法对于简单变量通过唯一的“登录”符号完成，对于Modbus Plus变量，通过明确的“程序路径”容量来完成，而“程序路径”
容量维持了一种双向连接直到被彻底击穿。
MODBUS/TCP处理两种情况。连接在网络协议层很容易被辨认，单一的连接可以支持
多个独立的事务。此外，TCP允许很大数量的并发连接，因而很多情况下，在请求时重新
连接或复用一条长的连接是发起者的选择。
熟悉MODBUS的开发者会感到惊讶：为什么面向连接TCP协议比面向数据报的UDP
要应用广泛。主要原因是通过封装独立的“事务”在一个连接中，此连接可被识别，管理和
取消而无须请求客户和服务器采用特别的动作。这就使进程具有对网络性能变化的适应能力，而且容许安全特色如防火墙和代理可以方便的添加。
类似的推理被最初的万维网的开发者所采用，他们选用TCP及端口80去实现一个作为单一事务的最小的环球网询问。
2.2 数据编码
MODBUS 采用“big-endi an”来表示地址和数据对象。
这就意味着当一个数字表示的数量大于所传输的单一字节，最大有效字节将首先被发送。例如：
2.3参考编号的解释
MODBUS将其数据模型建立在一系列具有不同特征的表的基础之上。这四个基本表如下
l 离散输入单比特，由I/O系统提供，只读
l 离散输出单比特，由应用程序更改，读写
l 输入寄存器16比特，数值，由I/O系统提供，只读
l 输出寄存器16比特，数值，由应用程序更改，读写
输入和输出之间以及可寻址位和可寻址代码的数据对象之间的差别并不意味着任何应用性能的不同。如果这是我们所讨论的目标机械的最自然的解释，那么认为所有的四个基本表是相互覆盖的看法也是非常普通而完全可以接受的。
对于每一个基本表，协议允许单独选择65536个数据对象中的任何一个，而且对那些对象的读写操作可以跨越多个连续的数据对象，直到达到基于处理事务功能代码的数据大小限制。
这儿没有假定数据对象代表一种真正邻接的数据阵列，而这是大多数简单PLC’s的解释。
“读写常用参考”功能代码被定义为携带32位的参考值并且能允许在“非常”大的空间里可以直接访问数据对象。现在没有可以利用这一特点的PLC设备。
一个易造成混乱的潜在来源是用于MODBUS功能的参考值和用于Modico
n PLC’s的“寄存器值”之间的关系。由于历史原因，用户参考值使用从1开始的十进制数表示。而MODBUS采用更普通的从0开始的无符号整数进行软件数据整理分析。
于是，请求从0读取寄存器的Modbus消息将已知值返回建立在寄存器4：00001（存储类型4=输出寄存器，参考值00001）中的应用程序。
2.4隐含长度基本原则
所有的MODBUS 请求和响应都被设计成在此种方法下工作，即接收者可确认消息的完整性。对于请求和响应为固定长度的功能代码，仅发送功能代码就足够了。对于在请求和响应中携带不定长数据的功能代码，数据部分前将加上一个字节的数据统计。
当Modbus通过TCP运送，前缀中携带附加的长度信息以便接收者识别消息的边界，甚至消息被分成若干组进行传输。外在的和隐含的长度准则的存在，以及CRC-32检错代码（以太网）的使用使请求和响应消息中发生未被识别的错误的机率减至无限小。
3. 一致性等级概述
当从草稿开始定义一种新的协议，有可能加强编码方式和阐述的一致性。MODBUS由于其先进的特性，已经在很多地方得到了实施，必须避免破坏它已经存在的实施。
因此，已经存在的成套的处理类型被划分出一致性等级：等级0代表普遍使用且总体上一致的功能；等级2代表有用的功能，但带有某些特性。现存装置的不适应于互用性的功能也已确认。
必须注意到，将来对该标准的扩充将定义附加的功能代码来处理现存事实标准不适用的情形。然而，被提议扩充的详细资料出现在本手册中将会另人误解。通过将代码“随机的”发送或者即便是通过检查异常响应的类型来确定特别的目标装置是否支持特别的功能代码总是可能的，而且该方法将保证引入这些扩充的现使用的MODBUS设备的连续的互用性。事实上，这就是当前功能代码的分级原则。
3.1等级0
这是最小的有用功能，对主站和从站来说。
读乘法寄存器(fc 3)
写乘法寄存器(fc 16)
3.2等级1
这是附加的被普遍实现的和能共同使用的成套功能，正如前面介绍过的，许多从站把输入，输出，离散值和寄存器值作为同等的进行处理。
l 读线圈(fc 1)
l 读离散输入(fc 2)
l 读寄存器输入(fc 4)
l 写线圈(fc 5)
l 写单一寄存器(fc 6)
l 读异常状态字(fc 7)
此功能对于每一个从站系列显然具有不同的含义。
3.3等级2
这些是需要HMI和管理等例行操作的数据传送功能。
l 强制型多路线圈(fc 15)
l 读一般参考值(fc 20)
该功能可以处理并发的多个请求，而且能接收32位的参考数值。当前的584和984PL C’s仅使用此功能接收类型6的参考值（扩展的寄存器文件）。
该功能最适于扩充以处理大的寄存器空间和缺少诸如“未定位”变量的参考值的数据对象。
l 写一般参考值(fc 21)
此功能可以处理并发的多个请求，也可接收32位的参考数值。当前的584和984PLC’s仅使用此功能接收类型6的参考值（扩展的寄存器文件）。
该功能最适于扩充以处理大的寄存器空间和缺少诸如“未定位”变量的参考值的数据对象。
l 掩膜写寄存器(fc 22)
l 读/写寄存器(fc 23)
此功能把一定范围的寄存器输入和输出当作单一的处理事务。使用MODBUS是执行规则的带有I/O模块的状态影象交换的最好办法。
如此，高性能的通用的数据采集装置可以执行功能3，16和23，从而把快捷的数据规则交换（23）和执行特殊数据对象的需求询问或更新的能力结合起来（3和16）。
l 读FIFO队列(fc 24)
一个有点专用的功能，打算将表结构的数据象FIFO（用到584/984上的FIN和FOUT 功能模块）一样传送到主机。对于某种事件录入软件很有用。
3.4机器/厂家/网络的特殊功能
以下所有的功能，虽然在MODBUS协议手册中提到，但由于它们有很强的机器依赖性，因而不适于互用性的目的。
l 诊断(fc 8)
l 编程(484) (fc 9)
l 轮询(484) (fc 10)
l 获取通讯事件计数器值(Modbus) (fc 11)
l 获取通讯事件记录(Modbus) (fc 12)
l 编程(584/984) (fc 13)
l 轮询(584/984) (fc 14)
l 通告从站ID (fc 17)
l 编程(884/u84) (fc 18)
l 恢复通讯连接(884/u84) (fc 19)
l 编程(原理) (fc 40)
l 固件置换(fc 125)
l 编程(584/984) (fc 126)
l 通告本地地址(Modbus) (fc 127)
4. 协议结构
本部分阐述了通过MODBUS/TCP网络携带的MODBUS请求和或响应封装的一般格式。必须注意到请求和响应本体（从功能代码到数据部分的末尾）的结构和其它MODBUS变量具有完全相同的版面格式和含义，如：
MODBUS 串行端口- ASCII 编码
MODBUS 串行端口- RTU (二进制) 编码
MODBUS PLUS 网络–数据通道
这些其它案例仅在组帧次序，检错模式和地址描述等格式有所不同。
所有的请求通过TCP从寄存器端口502发出。请求通常是在给定的连接以半双工的方式发送。也就是说，当单一连接被响应所占用，就不能发送其它的请求。有些装置采用多条TCP连接来维持高的传输速率。
然而一些客户端设备尝试“流水线式”的请求。允许服务器以这种方式工作的技术在附录A中阐述。
MODBUS “从站地址”字段被单字节的“单元标识符”替换，从而用于通过网桥和网关等设备的通讯，这些设备用单一IP地址来支持多个独立的终接单元。
请求和响应带有六个字节的前缀，如下：
ModBus通信链路层格式：
byte 0: 事务处理标识符–由服务器复制–通常为0
byte 1: 事务处理标识符–由服务器复制–通常为0
byte 2: 协议标识符= 0
byte 3: 协议标识符= 0
byte 4: 长度字段（上半部分字节）= 0 (所有的消息长度小于256) byte 5: 长度字段(下半部分字节) = 后面字节的数量
byte 6: 单元标识符(原“从站地址”)
byte 7: MODBUS 功能代码
byte 8 on: 所需的数据
因而处理示例“以4的偏移从UI 9读1寄存器”返回5的值将是
请求：00 00 00 00 00 06 09 03 00 04 00 01
响应：00 00 00 00 00 05 09 03 02 00 05
一致性等级0-2的功能代码的应用的例子见后续部分
熟悉MODBUS的设计师将注意到MODBUS/TCP中不需要“CRC-16”或“LRC”检查字段。而是采用TCP/IP和链路层（以太网）校验和机制来校验分组交换的准确性。
5. 一致性等级的协议参考值
注意到在例子中，请求和响应列在功能代码字节的前面。如前所述，在MODBUS/TCP 案例中有一个依赖传输的包含7个字节的前缀。
ref ref 00 00 00 len unit前面两个字节的“ref ref”在服务器中没有具体的值，只是为方便客户端而从请求和响应中逐字的复制过来。单客户机通常将该值置为0。
在这个例子中，请求和响应的格式如下（例子是“读寄存器”请求，详述见后面部分）。
03 00 00 00 01 => 03 02 12 34
这表示给前缀加上一个十六进制的串联的字节，这样，TCP连接上的整个消息将是（假设单元标识符还是09）
起始地址读取个数
请求：00 00 00 00 00 06 0903 00 0000 01
响应：00 00 00 00 00 05 0903 0212 34
长度16位值（1234H）
(所有的这些请求和响应通过查询Modicon Quantum PLC规范采用自动工具来进行校验。
5.1等级0指令详述
5.1.1读乘法寄存器(FC = 3)
请求
Byte 0: FC = 03
Byte 1-2: 参考数值
Byte 3-4: 指令数(1-125)
响应
Byte 0: FC = 03
Byte 1: 响应的字节数(B=2 x指令数)
Byte 2-(B+1): Register values
异常
Byte 0: FC = 83 (hex)
Byte 1: 异常代码= 01 or 02
示例:
从偏移地址参考值为0 (Modicon 984中为40001)时的1个寄存器读得一个到十六进制的值1234H
命令字起始地址读取个数命令字长度16位值（1234H）
03 00 00 00 01 => 03 02 12 34
发送帧响应帧
5.1.2 写乘法寄存器(FC = 16)
请求
Byte 0: FC = 10 (hex)
Byte 1-2: 参考数值
Byte 3-4: 指令数(1-100)
Byte 5: 字节数(B=2 x word count)
Byte 6-(B+5): 寄存器值
响应
Byte 0: FC = 10 (hex)
Byte 1-2: 参考数值
Byte 3-4: 指令数
异常
Byte 0: FC = 90 (hex)
Byte 1: 异常代码= 01 or 02
示例:
对偏移地址为0(Modicon 984中为40001)的1个寄存器写入十六进制的值1234H 命令字起始地址指定数长度数值命令字起始地址指定数
10 00 00 00 0102 12 34 => 10 00 00 00 01
发送帧响应帧
5.2等级1指令详述
5.2.1 读线圈(FC 1)
请求
Byte 0: FC = 01
Byte 1-2: 参考数值
Byte 3-4: 比特数(1-2000)
响应
Byte 0: FC = 01
Byte 1: 响应的字节数(B=(比特数+7)/8)
Byte 2-(B+1): 比特值(最小意义位首先绕线圈!)
异常
Byte 0: FC = 81 (hex)
Byte 1: exception code = 01 or 02
示例
读参考值为0 (Modicon 984中为00001)时的1线圈得到的值1
01 00 00 00 01 => 01 01 01
注意到返回的数据的格式和big-endian体系结构不同。而且此请求如果调用乘法指令字且这些指令不以16位为界排列，那么该请求将在从站得到计算强化。
5.2.2读离散输入(FC 2)
请求
Byte 0: FC = 02
Byte 1-2: 参考数值
Byte 3-4: 比特数(1-2000)
响应
Byte 0: FC = 02
Byte 1: 响应的字节数(B=(比特数+7)/8)
Byte 2-(B+1): 比特值(最小意义位首先绕线圈!)
异常
Byte 0: FC = 82 (16进制)
Byte 1: 异常代码= 01 or 02
示例
读参考值为0 (Modicon 984中为10001)时的1离散输入得到的值1
02 00 00 00 01 => 02 01 01
注意到返回的数据的格式和big-endian体系结构不同。而且此请求如果调用乘法指令字且这些指令不以16位为界排列，那么该请求将在从站得到计算强化。
5.2.3 读输入寄存器(FC 4)
请求
Byte 0: FC = 04
Byte 1-2: 参考数值
Byte 3-4: 指令数(1-125)
响应
Byte 0: FC = 04
Byte 1: 响应的比特数(B=2 x 指令数)
Byte 2-(B+1): 寄存器值
异常
Byte 0: FC = 84 (hex)
Byte 1: 异常代码= 01 or 02
示例
读参考值为0 (Modicon 984中为30001)时的1输入寄存器得到十六进制的值1234
04 00 00 00 01 => 04 02 12 34
5.2.4 写线圈(FC 5)
请求
Byte 0: FC = 05
Byte 1-2: 参考数值
Byte 3: = FF 打开线圈, =00 关闭线圈
Byte 4: = 00
响应
Byte 0: FC = 05
Byte 1-2: 参考数值
Byte 3: = FF 打开线圈, =00 关闭线圈(回波)
Byte 4: = 00
异常
Byte 0: FC = 85 (16进制)
Byte 1: 异常代码= 01 or 02
示例
将值1在参考值为0（Modicon 984中为00001）时写入1线圈
05 00 00 FF 00 => 05 00 00 FF 00
5.2.5 写单一寄存器(FC 6)
请求
Byte 0: FC = 06
Byte 1-2: 参考数值
Byte 3-4: 寄存器值
响应
Byte 0: FC = 06
Byte 1-2: 参考数值
Byte 3-4: 寄存器值
异常
Byte 0: FC = 86 (16进制)
Byte 1: 异常代码= 01 or 02
示例
将十六进制值1234在参考值为0（Modicon 984中为40001）时写入1线圈
06 00 00 12 34 => 06 00 00 12 34
水文通信协议规范
湖南省山洪灾害监测预警系统水文通信协议规范
目录 1 总则 (1) 2 术语、符号和代号 (3) 3 数据报文传输规约 (5) 3.1帧结构 (5) 3.1.1本标准采用异步式传输帧格式。 (5) 3.1.2传输规则应按以下规定执行 (5) 3.1.3链路层应符合以下规定： (6) 3.1.4报文传输 (7) 3.2链路传输 (8) 3.3物理层规约 (9) 4 数据传输报文及数据结构 (10) 4.1应用层数据编码规定 (10) 4.1.1链路用户数据编码格式 (10) 4.1.2站点水情信息编报 (11) 4.1.3水情信息编码分类码 (11) 4.1.4水情站码 (12) 4.1.5测报时间码 (12) 4.1.6要素标识符 (13) 4.1.7数据编码 (14) 4.2水文信息编码 (14) 4.2.1降雨量编码 (14) 4.2.2蒸发量编码 (16) 4.2.3河道水情编码 (17) 4.2.4水库（湖泊）水情编码 (19) 4.2.5闸坝水情编码 (20) 4.2.6泵站水情编码 (22) 4.2.7潮汐水情编码 (23) 4.2.8土壤墒情编码 (25) 4.3数据传输报文结构 (27) 4.3.1 链路测试(AFN=02H) (27) 4.3.2 参数设置（AFN=04H） (28) 4.3.3 参数查询（AFN=0AH） (31) 4.3.4 控制命令（AFN=0CH） (32) 5 通信方式和误码率 (34) 5.1通信方式 (34) 5.2误码率 (36) 6 仪表设备数据传输规约 (37) 6.1仪表数据通信规约 (37)
7 数据传输的考核 (38) 7.1考核内容和指标 (38) 7.2考核方法 (38) 附录A 事件记录表 (39) 附录B 编码要素及标识符汇总表 (40) 附录C本标准用词说明 (47)
多机通信协议规范
通信协议 来自中国工控网 所谓通信协议是指通信双方的一种约定。约定包括对数据格式、同步方式、传送速度、传送步骤、 检纠错方式以及控制字符定义等问题做出统一规定，通信双方必须共同遵守。因此，也叫做通信控制规程，或称传输控制规程，它属于ISO'S OSI七层参考模型中的数据链路层。 目前，采用的通信协议有两类：异步协议和同步协议。同步协议又有面向字符和面向比特以及面向 字节计数三种。其中，面向字节计数的同步协议主要用于DEC公司的网络体系结构中。 串行通讯简单认识 串行通讯的基本概念：与外界的信息交换称为通讯。基本的通讯方式有并行通讯和串行通讯两种。 一条信息的各位数据被同时传送的通讯方式称为并行通讯。并行通讯的特点是：各数据位同时传送，传送速度快、效率高，但有多少数据位就需多少根数据线，因此传送成本高，且只适用于近距离（相距 数米）的通讯。 一条信息的各位数据被逐位按顺序传送的通讯方式称为串行通讯。串行通讯的特点是：数据位传送，传按位顺序进行，最少只需一根传输线即可完成，成本低但送速度慢。串行通讯的距离可以从几米到几 千米。 根据信息的传送方向，串行通讯可以进一步分为单工、半双工和全双工三种。信息只能单向传送为 单工；信息能双向传送但不能同时双向传送称为半双工；信息能够同时双向传送则称为全双工。 串行通讯又分为异步通讯和同步通讯两种方式。在单片机中，主要使用异步通讯方式。 MCS_51单片机有一个全双工串行口。全双工的串行通讯只需要一根输出线和一根输入线。数据的输 出又称发送数据（TXD），数据的输入又称接收数据（RXD）。串行通讯中主要有两个技术问题，一个是数 据传送、另一个是数据转换。数据传送主要解决传送中的标准、格式及工作方式等问题。数据转换是指 数据的串并行转换。具体说，在发送端，要把并行数据转换为串行数据；而在接收端，却要把接收到的 串行数据转换为并行数据。 单工、半双工和全双工的定义 如果在通信过程的任意时刻，信息只能由一方A传到另一方B，则称为单工。 如果在任意时刻，信息既可由A传到B，又能由B传A，但只能由一个方向上的传输存在，称为半双工传输如果在任意时刻，线路上存在A到B和B到A的双向信号传输，则称为全双工。 电话线就是二线全双工信道。由于采用了回波抵消技术，双向的传输信号不致混淆不清。双工信道有时也发信道分开，采用分离的线路或频带传输相反方向的信号，如回线传输。 --------> <--------> --------> A---------B A----------B A---------B <-------- 单工半双工全双工
通讯协议标准
编号： 密级：内部 页数：__________基于RS485接口的DGL通信协议（修改） 编写：____________________ 校对：____________________ 审核：____________________ 批准：____________________ 北京华美特科贸有限公司 二○○二年十二月六日
1.前言 在常见的数字式磁致伸缩液位计中，多采用RS485通信方式。但RS485标准仅对物理层接口进行了明确定义，并没有制定通信协议标准。因此，在RS485的基础上，派生出很多不同的协议，不同公司均可根据自身需要设计符合实际情况的通信协议。并且，RS485允许单总线多机通信，如果通信协议设计不好，就会造成相互干扰和总线闭锁等现象。如果在一条总线上挂接不同类型的产品，由于协议不一样，很容易造成误触发，造成总线阻塞，使得不同产品对总线的兼容性很差。 随着RS485的发展，Modicon公司提出的MODBUS协议逐步得到广泛认可，已在工业领域得到广泛应用。而MODBUS的协议规范比较烦琐，并且每字节数据仅用低4位（范围：0~15），在信息量相同时，对总线占用时间较长。 DGL协议是根据以上问题提出的一种通信协议。在制定该协议时已充分考虑以下几点要求： a.兼容于MODBUS 。也就是说，符合该协议的从机均可挂接到同一总线上。 b.要适应大数据量的通信。如：满足产品在线程序更新的需要(未来功能)。 c.数据传输需稳定可靠。对不确定因素应加入必要的冗错措施。 d.降低总线的占用率，保证数据传输的通畅。 2.协议描述 为了兼容其它协议，现做以下定义： 通信数据均用1字节的16进制数表示。从机的地址范围为：0x80～0xFD，即：MSB=1； 命令和数据的数值范围均应控制在0~0x7F之间。即：MSB=0，以区别地址和其它数据。 液位计的编码地址为：0x82~0x9F。其初始地址(出厂默认值)为：0x81。 罐旁表的编织地址为：0xA2~0xBF。其初始地址(出厂默认值)为：0xA1。 其它地址用于连接其它类型的设备，也可用于液位计、罐区表地址不够时的扩充。 液位计的命令范围为：0x01~0x2F，共47条，将分别用于参数设定、实时测量、诊断测试、在线编程等。 通信的基本参数为：4800波特率，1个起始位，1个结束位。字节校验为奇校验。 本协议的数据包是参照MODBUS RTU 通信格式编写，并对其进行了部分修改，以提高数据传输的速度。另外，还部分参照了HART协议。其具体格式如下： 表中，数据的最大字节数为16个。也就是说，整个数据包最长为20个字节。 “校验和”是其前面所有数据异或得到的数值，然后将该数值MSB位清零，使其满足0~7F 的要求。在验证接收数据包的“校验和”是否正确时，可将所有接收数据(包括“校验和”)进行异或操作，得到的数据应＝0x80。这是因为，只有“地址”的MSB=1，所以异或结果的MSB也必然等于1。 本协议不支持MODBUS中所规定的广播模式。 3.时序安排 在上电后，液位计将先延迟10秒，等待电源稳定。然后，用5秒的时间进行自检和测试数据。
Modbus标准通讯协议格式
Modbus通讯协议 Modbus协议 Modbus协议最初由Modicon公司开发出来，在1979年末该公司成为施耐德自动化(Schneider Automation)部门的一部分，现在Modbus已经是工业领域全球最流行的协议。此协议支持传统的RS-232、RS-422、RS-485和以太网设备。许多工业设备，包括PLC，DCS，智能仪表等都在使用Modbus协议作为他们之间的通讯标准。有了它，不同厂商生产的控制设备可以连成工业网络，进行集中监控。 当在网络上通信时，Modbus协议决定了每个控制器须要知道它们的设备地址，识别按地址发来的消息，决定要产生何种行动。如果需要回应，控制器将生成应答并使用Modbus 协议发送给询问方。 Modbus协议包括ASCII、RTU、TCP等，并没有规定物理层。此协议定义了控制器能够认识和使用的消息结构，而不管它们是经过何种网络进行通信的。标准的Modicon控制器使用RS232C实现串行的Modbus。Modbus的ASCII、RTU协议规定了消息、数据的结构、命令和就答的方式，数据通讯采用Maser/Slave方式，Master端发出数据请求消息，Slave 端接收到正确消息后就可以发送数据到Master端以响应请求；Master端也可以直接发消息修改Slave端的数据，实现双向读写。 Modbus协议需要对数据进行校验，串行协议中除有奇偶校验外，ASCII模式采用LRC校验，RTU模式采用16位CRC校验，但TCP模式没有额外规定校验，因为TCP协议是一个面向连接的可靠协议。另外，Modbus采用主从方式定时收发数据，在实际使用中如果某Slave站点断开后（如故障或关机），Master端可以诊断出来，而当故障修复后，网络又可自动接通。因此，Modbus协议的可靠性较好。 下面我来简单的给大家介绍一下，对于Modbus的ASCII、RTU和TCP协议来说，其中TCP和RTU协议非常类似，我们只要把RTU协议的两个字节的校验码去掉，然后在RTU协议的开始加上5个0和一个6并通过TCP/IP网络协议发送出去即可。所以在这里我仅介绍一下
DLT645通信协议详情
1应用范围 本规范规定了电能表进行点对点的或一终端对多台电能表进行一主多从的本地通讯接口进行数据交换的技术要求，规定了本地系统硬件和协议规范。规定了物理连接、通讯链路及应用技术规范（数据的基本格式、校验方式、编码传输规则等）。 本规范主要参考了部颁DL/T 645-1997多功能电能表通信规约，根据我公司的DSSD331-3、DTSD341-3电能表的特色做了相应的扩展。本规范中未给出的一些例子和示意图请参见部颁规约。 2引用标准 下列标准所包含的条文，通过在本标准中的引用而构成为本标准的条文。本标准出版时，所示版本均为有效，所有标准都会被修订，使用本标准的各方应探讨使用下列标准最新版本的可能性。 DL/T 645-1997 多功能电能表通信规约 DL/T 614-1997 多功能电能表 3术语 3.1费率装置tariff device 固定的数据采集与处理单元，通常与电能表连接或与电能表组装在一起。 3.2手持单元（HHU）hand-heldunit 能与费率装置或电能表进行数据交换的便携式设备。 3.3数据终端设备data terminal equipment 由数据源、数据宿或两者组成的设备。
3.4直接本地数据交换direct local data exchange 一组费率装置与数据终端设备通过总线连接进行数据交换。 3.5本地总线数据交换local bus data exchange 一组费率装置与数据终端设备通过总线连接进行数据交换。 3.6远程数据交换remote data exchange 通过数据网络，数据采集中心与一台或一组费率装置之间的数据交换。 3.7主站master station 具有选择从站并与从站进行信息交换功能的设备。本标准中指手持单元或其它数据终端设备。 3.8从站slave station 预期从主站接收信息并与主站进行信息交换的设备。本标准中指费率装置。 3.9总线bus 连接主站与多个从站并允许主站每次只与一个从站通信的系统连接方式（广播命令除外）。 3.10半双工half-duplex 在双向通道中，双向交替进行、一次只在一个方向（而不是同时在两个方向）传输信息的一种通信方式。 3.11物理层physical layer 规定了数据终端设备或手持单元与费率装置之间的物理接口、接口的物理和电气特性，负责物理媒体上信息的接收和发送。 3.12数据链链路层data-link layer 负责数据终端设备与费率装置之间通信链路的建立并以帧为单位舆信息，保证信息的顺序传送，具有传输差错检测功能。 3.13应用层application layer
常用几种通讯协议
常用几种通讯协议 Modbus Modbus技术已成为一种工业标准。它是由Modicon公司制定并开发的。其通讯主要采用RS232，RS485等其他通讯媒介。它为用户提供了一种开放、灵活和标准的通讯技术，降低了开发和维护成本。 Modbus通讯协议由主设备先建立消息格式，格式包括设备地址、功能代码、数据地址和出错校验。从设备必需用Modbus协议建立答复消息，其格式包含确认的功能代码，返回数据和出错校验。如果接收到的数据出错，或者从设备不能执行所要求的命令，从设备将返回出错信息。 Modbus通讯协议拥有自己的消息结构。不管采用何种网络进行通讯，该消息结构均可以被系统采用和识别。利用此通信协议，既可以询问网络上的其他设备，也能答复其他设备的询问，又可以检测并报告出错信息。 在Modbus网络上通讯期间，通讯协议能识别出设备地址，消息，命令，以及包含在消息中的数据和其他信息，如果协议要求从设备予以答复，那么从设备将组建一个消息，并利用Modbus发送出去。 BACnet BACnet是楼宇自动控制系统的数据通讯协议,它由一系列与软件及硬件相关的通讯协议组成,规定了计算机控制器之间所有对话方式。协议包括:(1)所选通讯介质使用的电子信号特性,如何识别计算机网址,判断计算机何时使用网络及如何使用。(2)误码检验,数据压缩和编码以及各计算机专门的信息格式。显然,由于有多种方法可以解决上述问题,但两种不同的通讯模式选择同一种协议的可能性极少,因此,就需要一种标准。即由ISO(国际标准化协会〉于80年代着手解决,制定了《开放式系统互联(OSI〉基本参考模式(Open System Interconnection/Basic Reference Model简称OSI/RM)IS0- 7498》。 OSI/RM是ISO/OSI标准中最重要的一个,它为其它0SI标准的相容性提供了共同的参考,为研究、设计、实现和改造信息处理系统提供了功能上和概念上的框架。它是一个具有总体性的指导性标准,也是理解其它0SI标准的基础和前提。 0SI/RM按分层原则分为七层,即物理层、数据链路层、网络层、运输层、会话层、表示层、应用层。 BACnet既然是一种开放性的计算机网络,就必须参考OSIAM。但BACnet没有从网络的最低层重新定义自己的层次,而是选用已成熟的局域网技术,简化0SI/RM,形成包容许多局 域网的简单而实用的四级体系结构。 四级结构包括物理层、数据链路层、网络层和应用层。
Modbus+RTU+标准通讯协议格式
HLP_SV Modbus RTU 标准通讯协议格式 通信资料格式 Address Function Data CRC check 8 bits 8 bits N×8bits 16bits 1）Address通讯地址：1-247 2）Function：命令码8-bit命令 01 读线圈状态 上位机发送数据格式: ADDRESS 01 ADDRH ADDRL NUMH NUML CRC 注: ADDR: 00000 --- FFFF(ADDR=线圈地址－1)；NUM: 0010-----0040 (NUM为要读线圈状态值的二进制数位数) 正确时变频器返回数据格式： ADDRESS 01 BYTECOUNT DA TA1 DA TA2 DA TA3 DA TAN CRC 注: BYTECOUNT:读取的字数 错误时变频器返回数据格式： ADDRESS 0X81 Errornum CRC 注: Errornum为错误类型代码 如：要检测变频器的输出频率 应发送数据：01 01 00 30 00 10 3D C9（16进制） 变频器返回数据：01 01 02 00 20 B8 24（16进制） 发送数据：0030hex（线圈地址49） 返回的数据位为“0020”（16进制），高位与低位互换，为2000。即输出频率为 303（Max Ref）的50%。关于2000对应50%，具体见图1。
03读保持寄存器 上位机发送数据格式： ADDRESS 03 ADDRH ADDRL NUMH NUML CRC 注：ADDR: 0 --- 0XFFFF；NUM: 0010-----0040 (NUM为要读取数据的字数) ADDR=Parameter Numbe r×10-1 正确时变频器返回数据格式： ADDRESS 03 BYTECOUNT DA TA1 DA TA 2 DA TA 3 DA TAN CRC 注: BYTECOUNT:读取的字节数 错误时变频器返回数据格式： ADDRESS 0X83 Errornum CRC 如：要读变频器参数303的设定值 应发送数据：01 03 0B D5 00 02 95 BC （16进制） Parameter 303(3029)=0BD5HEX 变频器返回数据：“：”01 03 04 00 00 EA 60 B5 7B 返回的数据位为“00 00 EA 60”（16进制）转换为10进制数为60000, 表示303设置值为60.000 ※当参数值为双字时，NUM的值必须等于2。否则无法读取或读取错误。 05 写单个线圈状态 上位机发送数据格式： ADDRESS 05ADDRH ADDRL DA TAH DA TAL CRC 注：ADDR: 0 ---- 0XFFFF(ADDR=线圈地址－1)；DATA=0000HEX(OFF) OR FF00(ON) HEX 正确时变频器返回数据格式： ADDRESS 05 DATAH DATAL BYTECOUNT CRC 错误时变频器返回数据格式： ADDRESS 0X85 Errornum CRC 如：要使写参数为写入RAM和EEPROM 应发送数据：01 05 00 40 FF 00 CRC（16进制） 变频器返回数据：01 05 FF 00 00 01 CRC（16进制） 发送数据：0040hex（线圈地址65） 06 写单个保持寄存器值（只能写参数值为单个字的参数） 上位机发送数据格式： ADDRESS 06 ADDRH ADDRL DA TAH DA TAL CRC 注:ADDR: ADDR=Parameter Numbe r×10-1 正确时变频器返回数据格式： ADDRESS 06 ADDRH ADDRL DA TAH DA TAL CRC 错误时变频器返回数据： ADDRESS 0X86 Errornum CRC 如：要对变频器参数101写入1 应发送数据：01 06 00 03 F1 00 01 19 BD（16进制） 变频器返回数据：01 06 03 F1 00 01 19 BD（16进制） PARAMETER 101（1009）=03F1 HEX
FlexRay通信系统协议规范V2.1修订本A-勘误表V1
FlexRay Communications System Protocol Specification v2.1 Revision A Errata Sheet Version 1
Disclaimer This document as released by the FlexRay Consortium is intended for the purpose of information only. The use of material contained in this document requires membership within the FlexRay Consortium or an agreement with the FlexRay Consortium. The FlexRay Consortium will not be liable for any unauthorized use of this Specification. Following the completion of the development of the FlexRay Communications System Specifications commercial exploitation licenses will be made available to End Users by way of an End User's License Agreement. Such licenses shall be contingent upon End Users granting reciprocal licenses to all Core Partners and non-assertions in favor of all Premium Associate Members, Associate Members and Devel-opment Members. All details and mechanisms concerning the bus guardian concept are defined in the FlexRay Bus Guardian Specifications. The FlexRay Communications System is currently specified for a baud rate of 10 Mbit/s. It may be extended to additional baud rates. No part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permission in writing from the publisher. The word FlexRay and the FlexRay logo are registered trademarks. Copyright ? 2004-2006 FlexRay Consortium. All rights reserved. The Core Partners of the FlexRay Consortium are BMW AG, DaimlerChrysler AG, Freescale Halbleiter Deutschland GmbH, General Motors Corporation, Philips GmbH, Robert Bosch GmbH, and Volkswagen AG.
基于ModBus-TCP通信协议规范表达
MODBUS TCP/IP协议规范详细介绍 收藏此信息打印该信息添加：用户发布来源：未知 1．该规范的发展概况 原始版本1997年9月3日作为公共评论的草案。 再版1999年3月29日，即修订版1.0。 没有大的技术改动，仅作了补充说明。增加了附录A和B作为对一些常用执行问题的回应。 该Modbus/TCP规范在万维网上公开发行。它表明开发者的意愿是把它作为工业自动化领 域具有互用性的标准。 既然MODBUS和MODBUS/TCP作为事实上的“实际”标准，而且很多生产商已经实现了它的功能，此规范主要是阐述在互连网上具有普遍可用性的基于TCP通讯协议的MODBUS 报文的特殊编码。 2. 概述 MODBUS/TCP是简单的、中立厂商的用于管理和控制自动化设备的MODBUS系列通讯协议的派生产品。显而易见，它覆盖了使用TCP/IP协议的“Intranet”和“Internet”环境中MODBUS报文的用途。协议的最通用用途是为诸如PLC’s，I/O模块，以及连接其它简单 域总线或I/O模块的网关服务的。 MODBUS/TCP协议是作为一种（实际的）自动化标准发行的。既然MODBUS已经广 为人知，该规范只将别处没有收录的少量信息列入其中。然而，本规范力图阐明MODBU S中哪种功能对于普通自动化设备的互用性有价值，哪些部分是MODBUS作为可编程的协议交替用于PLC’s的“多余部分”。 它通过将配套报文类型“一致性等级”，区别那些普遍适用的和可选的，特别是那些适用于特殊设备如PLC’s的报文。 2.1 面向连接 在MODBUS中，数据处理传统上是无国界的，使它们对由噪音引起的中断有高的抵抗力，而且在任一端只需要最小的维护信息。 编程操作，另一方面，期望一种面向连接的方法。这种方法对于简单变量通过唯一的“登录”符号完成，对于Modbus Plus变量，通过明确的“程序路径”容量来完成，而“程序路径” 容量维持了一种双向连接直到被彻底击穿。 MODBUS/TCP处理两种情况。连接在网络协议层很容易被辨认，单一的连接可以支持 多个独立的事务。此外，TCP允许很大数量的并发连接，因而很多情况下，在请求时重新 连接或复用一条长的连接是发起者的选择。 熟悉MODBUS的开发者会感到惊讶：为什么面向连接TCP协议比面向数据报的UDP 要应用广泛。主要原因是通过封装独立的“事务”在一个连接中，此连接可被识别，管理和 取消而无须请求客户和服务器采用特别的动作。这就使进程具有对网络性能变化的适应能力，而且容许安全特色如防火墙和代理可以方便的添加。
通信服务协议(标准版)
Both parties jointly acknowledge and abide by their responsibilities and obligations and reach an agreed result. 甲方：___________________ 乙方：___________________ 时间：___________________ 通信服务协议
编号：FS-DY-20671 通信服务协议 为保护乙方的通信权利，维护甲方合法的通信经营权，双方本着自愿、平等的原则，达成协议如下： 一、协议双方的权利与义务 （一）乙方的权利与义务 1．依法使用电信的自由和通信秘密受法律保护。 2．有权自主选择使用甲方依法开办的固定电话通信业务。 3．有对甲方执行的收费项目和资费标准的知晓权。 4．应当在约定的时限内（全月）缴纳电信费用。 5．登记办理固定电话业务须提供真实、无误的乙方资料，并对乙方资料的准确性、真实性，承担法律责任。 6．乙方名称、结算方式发生变更时，应在一周内办理变更确认手续，因未按时办理变更手续造成的损失由乙方自行承担。
7．使用的用户终端设备必须符合国家规定的标准并取得进网许可证。 8．使用电信网络传输的信息内容及其后果由乙方负责。 9．配合甲方实施的固定电话服务变更。 （二）甲方的权利和义务 1．按照规定的标准收取各项费用。 2．按照国家规定的服务标准向乙方提供固定电话服务。并在营业场所公布收费项目和资费标准，并为乙方缴费提供方便。 3．甲方免费向乙方提供火警（119）、匪警（110）、医疗急救（120）、交通事故报警（122）等紧急电话的接入服务。 4．甲方免费向乙方提供长途话费详细清单查询，并为乙方保留话费信息半年。 5．根据国家关于电话交换设备技术规范书、国家计委和信息产业部对电信计费的有关规定，固定网本地电话不提供详细话单。 6．乙方对缴纳的电信费用有异议的，甲方有义务采取必要措施协助查找原因。
通信协议规范090316
GPS终端与平台通信协议规范 编 制 说 明 北京XXXXX有限公司 2008-12-18
目录 1、范围 (33) 2、规范性引用文件 (33) 3、术语、定义和缩略语 (33) 3.1.术语和定义 (33) 3.2.缩略语 (33) 4、网络通信业务流程 (44) 4.1网络通信业务流程 (44) 4.2短信通信业务流程 (77) 5、网络通信协议 (99) 5.1平台发往终端通信协议 (99) 5.1.1报文格式 (99) 5.1.2报文类型 (99) 5.1.3报文体 (1010) 5.1.3.1查询类 (1010) 5.1.3.2配置类 (1111) 5.1.3.3控制类 .................. 错误!未定义书签。错误!未定义书签。 5.2终端发往平台通信协议...................... 错误!未定义书签。错误!未定义书签。 5.2.1终端回复平台指令通信协议.............. 错误!未定义书签。错误!未定义书签。 5.2.1.1报文格式 ................ 错误!未定义书签。错误!未定义书签。 5.2.1.2报文类型 ................ 错误!未定义书签。错误!未定义书签。 5.2.1.3报文体 ................ 错误!未定义书签。错误!未定义书签。 5.2.2终端主动发往平台通信协议.............. 错误!未定义书签。错误!未定义书签。 5.2.2.1报文格式 ................ 错误!未定义书签。错误!未定义书签。 5.2.2.2报文类型 ................ 错误!未定义书签。错误!未定义书签。 5.2.2.3报文体 ................ 错误!未定义书签。错误!未定义书签。 6、短信通信协议................................ 错误!未定义书签。错误!未定义书签。 6.1平台发往终端通信协议...................... 错误!未定义书签。错误!未定义书签。 6.1.1短信指令格式.......................... 错误!未定义书签。错误!未定义书签。 6.1.2指令名................................ 错误!未定义书签。错误!未定义书签。 6.1.3指令参数.............................. 错误!未定义书签。错误!未定义书签。 6.1.3.1查询类 .................. 错误!未定义书签。错误!未定义书签。 6.1.3.2配置类 .................. 错误!未定义书签。错误!未定义书签。 6.1.3.3控制类 .................. 错误!未定义书签。错误!未定义书签。 6.2终端发往平台通信协议...................... 错误!未定义书签。错误!未定义书签。 6.2.1终端回复平台指令通信协议.............. 错误!未定义书签。错误!未定义书签。 6.2.1.1指令格式 ................ 错误!未定义书签。错误!未定义书签。 6.2.1.2指令名 .................. 错误!未定义书签。错误!未定义书签。 6.2.1.3指令参数 ................ 错误!未定义书签。错误!未定义书签。 6.2.2终端主动发往平台通信协议.............. 错误!未定义书签。错误!未定义书签。 6.2.2.1指令格式 ................ 错误!未定义书签。错误!未定义书签。 6.2.2.2指令名 .................. 错误!未定义书签。错误!未定义书签。 6.2.2.3指令参数 ................ 错误!未定义书签。错误!未定义书签。附1 ........................................... 错误!未定义书签。错误!未定义书签。
网络协议规范大全
在网络的各层中存在着许多协议，它是定义通过网络进行通信的规则，接收方的发送方同层的协议必须一致，否则一方将无法识别另一方发出的信息，以这种规则规定双方完成信息在计算机之间的传送过程。下面就对网络协议规范作个概述。 ARP(Address Resolution Protocol)地址解析协议 它是用于映射计算 机的物理地址和临时指定的网络地址。启动时它选择一个协议(网络层)地址，并检查这个地址是否已经有别的计算机使用，如果没有被使用，此结点被使用这个地址，如果此地址已经被别的计算机使用，正在使用此地址的计算机会通告这一信息，只有再选另一个地址了。SNMP(Simple Network Management P)网络管理协议 它是TCP/IP协议中的一部份，它为本地和远端的网络设备管理提供了一个标准化途径，是分布式环境中的集中化管理的重要组成部份。AppleShare protocol(AppleShare协议) 它是Apple机上的通信协议，它允许计算机从服务器上请求服务或者和服务器交换文件。AppleShare可以在TCP/IP协议或其它网络协议如IPX、AppleTalk上进行工作。使用它时，用户可以访问文件，应用程序，打印机和其它远程服务器上的资源。它可以和配置了AppleShare 协议的任何服务器进行通信，Macintosh、Mac OS、Windows NT和Novell Netware都支持AppleShare协议。 AppleTalk协议 它是Macintosh计算机使用的主要网络协议。Windows NT服务器有专门为Macintosh服务，也能支持该协议。其允许Macintosh的用户共享存储在 Windows NT文件夹的Mac-格式的文件，也可以使用和Windows NT连接的打印机。Windows NT共享文件夹以传统的Mac文件夹形式出现在Mac用户面前。Mac文件名按需要被转换为FAT(8.3)格式和NTFS文件标准。支持MAc 文件格式的DOS和Windows客户端能与Mac用户共享这些文件。 BGP4(Border Gateway Protocol Vertion 4)边界网关协议-版本4 它是用于在自治网络中网关主机(每个主机有自己的路由)之间交换路由信息的协议，它使管理员能够在已知的路由策略上配置路由加权，可以更方便地使用无级内部域名路由(CIDR)，它是一种在网络中可以容纳更多地址的机制，它比外部网关协议(EGP)更新。BGP4经常用于网关主机之间，主机中的路由表包括了已知路由的列表，可达的地址和路由加权，这样就可以在路由中选择最好的通路了。BGP在局域网中通信时使用内部BGP(IBGP)，因为IBGP不能很好工作。 BOOTP协议 它是一个基于TCP/IP协议的协议，它可以让无盘站从一个中心服务器上获得IP地址，现在我们通常使用DHCP协议进行这一工作。CMIP(Common Management Information Protocol)通用管理信息协议 它是建立在开放系统互连通信模式上的网络管理协议。相关的通用管理信息服务(CMIS)定义了访问和控制网络对象，设备和从对象设备接收状态信息的方法。 Connection-oriented Protocol/Connectionless Protocol面向连接的协议/无连接协议 在广域网中，两台计算机建立物理连接过程所使用的协议，这种物理连接要持续到成功地交换完数据为止。在Internet中，TCP(传输控制协议)即这一类型的协议，它为两台连接在网络上的计算机提供了可相互通信且确保数据成功传输的一种手段。面向连接的协议一定要保证数据传送到对方。在广域网中，对接收方的计算机不做在线状态，或接收能力的测试，都能使数据由一台计算机传输到另外一台计算机上的协议。这是包交换网络中的主要协议，在Internet中的IP协议即无连接协
Modbus标准通讯协议格式【最新】
Modbus通讯协议 下表是Modbus的功能格式： 1、读可读写数字量寄存器（线圈状态）： 计算机发送命令：[设备地址] [命令号01] [起始寄存器地址高8位] [低8位] [读取的寄存器数高8位] [低8位] [CRC校验的低8位] [CRC校验的高8位] 例：[11][01][00][13][00][25][CRC低][CRC高] 意义如下： <1>设备地址：在一个485总线上可以挂接多个设备，此处的设备地址表示想和哪一个设备通讯。例子中为想和17号(十进制的17是十六进制的11)通讯。 <2>命令号01：读取数字量的命令号固定为01。 <3>起始地址高8位、低8位：表示想读取的开关量的起始地址(起始地址为0)。比如例子中的起始地址为19。 <4>寄存器数高8位、低8位：表示从起始地址开始读多少个开关量。例子中为37个开关量。
<5>CRC校验：是从开头一直校验到此之前。在此协议的最后再作介绍。此处需要注意，CRC校验在命令中的高低字节的顺序和其他的相反。 设备响应：[设备地址] [命令号01] [返回的字节个数][数据1][数据2]...[数据n][CRC 校验的低8位] [CRC校验的高8位] 例：[11][01][05][CD][6B][B2][0E][1B][CRC低][CRC高] 意义如下： <1>设备地址和命令号和上面的相同。 <2>返回的字节个数：表示数据的字节个数，也就是数据1，2...n中的n的值。 <3>数据1...n：由于每一个数据是一个8位的数，所以每一个数据表示8个开关量的值，每一位为0表示对应的开关断开，为1表示闭合。比如例子中，表示20号(索引号为19)开关闭合，21号断开，22闭合，23闭合，24断开，25断开，26闭合，27闭合...如果询问的开关量不是8的整倍数，那么最后一个字节的高位部分无意义，置为0。 <4>CRC校验同上。 2、读只可读数字量寄存器（输入状态）： 和读取线圈状态类似，只是第二个字节的命令号不再是1而是2。 3、写数字量（线圈状态）：
CAN2.0B 协议规范
BOSCH CAN Specification Version 2.0 1991, Robert Bosch GmbH, Postfach 30 02 40, D-70442 Stuttgart
BOSCH ROBERT BOSCH GmbH, Postfach 30 02 40, D-70442 Stuttgart Sep. 1991 page 1 Recital The acceptance and introduction of serial communication to more and more applications has led to requirements that the assignment of message identifiers to communication functions be standardized for certain applications. These applications can be realized with CAN more comfortably, if the address range that originally has been defined by 11 identifier bits is enlarged Therefore a second message format (’extended format’) is introduced that provides a larger address range defined by 29 bits. This will relieve the system designer from compromises with respect to defining well-structured naming schemes. Users of CAN who do not need the identifier range offered by the extended format, can rely on the conventional 11 bit identifier range (’standard format’) further on. In this case they can make use of the CAN implementations that are already available on the market, or of new controllers that implement both formats. In order to distinguish standard and extended format the first reserved bit of the CAN message format, as it is defined in CAN Specification 1.2, is used. This is done in such a way that the message format in CAN Specification 1.2 is equivalent to the standard format and therefore is still valid. Furthermore, the extended format has been defined so that messages in standard format and extended format can coexist within the same network. This CAN Specification consists of two parts, with ?Part A describing the CAN message format as it is defined in CAN Specification 1.2;?Part B describing both standard and extended message formats. In order to be compatible with this CAN Specification 2.0 it is required that a CAN implementation be compatible with either Part A or Part B. Note CAN implementations that are designed according to part A of this or according to previous CAN Specifications, and CAN implementations that are designed according to part B of this specification can communicate with each other as long as it is not made use of the extended format. CAN Specification 2.0