如果你想要以一种透彻普适化的方式，去理解目前人类所有通信手段的根本，那OSI模型就是说这个的。

它是个逻辑模型。那7层结构是逻辑上的7个分层，所以它是个抽象模型，是个大的框架。

它不是在讲某一种具体的东西。它是想要说尽天下所有具体通信手段的共性，把万变不离其宗的东西说出来。所以它是按人类最大可能覆盖场景的集合去说的。

任何一个能叫出名的通信协议，比如应用最广泛的TCP/IP协议族中的多个协议，都是具体的通信方式。它们在逻辑上被抽象后，都可以归于OSI中的某一逻辑层

不同的具体通信协议，会省略或压缩不同的逻辑功能。毕竟每一类的场景还是有具体差别的。所以，每一个具体协议都是OSI的某个子集的一个具体实现方式。

因为历史和利益的缘由，不同的人、不同的公司，根据不同的需求和立场，就创造了这么多不同的通信协议。它们都以不同的各有所长的方式，实现了OSI中讲述的那些抽象功能。

按照工业上的基本现实来讲，就分两类：要么跑串口线，要么跑以太网线。

网线上跑的协议格外贴近OSI模型。如果你用网线上的抓包软件去看每一个抓到的以太网数据帧，它的代码都是层层包裹的。这层层中的每一层，就是对应OSI中的一个抽象层。

贴近物理的逻辑底层在最外面，贴近顶层应用的逻辑位于帧的最里面。现在的多种抓包软件，不仅把各个层给你分开，而且每一层中每一位的含义，以及进一步推演出来的信息，都说的清清楚楚，一览无余。

串口是比较老的东西，相对的当初的早期设计就简单一些，OSI中的靠近上部的一些层就省略了。但还是能和OSI中的不同层对应上。

串口最常用的协议modbus，就是相当于把上面的5个层给省略合并了。

MB-Master指令的职责，就是把PLC程序员用户在应用层面的信息需求，封装进Modbus协议中。封装完成后得到的东西，是要嵌入进第2层的，被第2层的协议包裹在里面。

这第2层的协议叫Uart，也就是波特率、起始位、数据位、校验位、停止位这些东西。MB-Comm-Load指令就是负责把master指令封装后的东西，进一步封装为Uart的协议格式，最后交给OSI底部第1层的485，用电信号去表达这个Uart报文。

485线路上的Uart报文，用示波器的探针搭在AB两根线上就能看到。如果你熟练的话，不借助工具，用眼睛就能解读其中的ModbusRTU报文。具体长下面的这个样子。

具体协议解读就是下面这样。可以看到ModbusRTU协议的报文，是如何嵌入在Uart报文的每一段8个数据位中的。

这上面的截图中，你能看到OSI模型的结构。

图中的连续锯齿波动，这就是最底层的485信号，这就是OSI的第1层物理层的表现。

连续的485信号锯齿中，出现了上下高低的错位排布。这些错位就是bit。不同高低排列的bit规律性，就是在表达uart协议中对于波特率、起始/数据/校验/停止等的约定。这就是OSI的第2层数据链路层的表现。

Uart信息格式中，每一段的8个数据位中嵌入的，就是Modbus报文的1个字节。把这些字节连起来，形成的RTU报文，就是OSI的第3-7层的一种实现。

串口通信中的自由口协议，和modbus协议，是平等的协议。只不过你需要自己定义Uart每一段的8个数据位中嵌入的内容，它所表达意思的规则。

明白了上面的叙述大意，就能理解ModbusTCP是什么。它就是把Modbus的基本报文略微调整一下，塞进以太网的TCP协议的纯数据部分之中。所以它是OSI中的第7层协议。

同理，西门子的S7协议也是OSI中的第七层协议。也是嵌入进TCP协议的纯数据部分之中。

这种从外到内的层层包裹，在编程上都是要耗费代码设计和计算时间的代价，所以包裹层数越多的协议，传输速度越慢。发送信息时候的层层打包，和接收时候的层层拆包，就和发快递一样，内外套好几个箱子就会费事，每一层箱子都要打标贴详述信息。越靠近OSI顶层的通信协议，因为封装代价就越慢。我用上位机测过，S7比TCP传输，总体上慢50倍。

但是仅有通信是远远不够的。

工控人面对的是项目工艺，这些工艺通过各种设备来实现。每个设备常常会用到不同的通信方式。

站在项目/工艺/设备的高度看通信，它们只是设备FB的IO。而且是非常固化的IO，因为你只能按照协议去执行，没有任何变化。

所有的变化，都是由于人的需求变化，导致的项目工艺需求的变化，导致的设备FB的使用变化，最后被表达为通信IO传送的内容变化。

在这个信息传递链中，通信单元本身的执行模式其实是完全不变的。快递小哥始终是快递小哥，区别是包裹中装的东西不同。

人是一切变化的根源。程序中越是靠近顶层的设计，越要包含各种可能的变化。而当你这么做到时候，会发现底层的通信执行，根本就是个固定跑龙套的。所有的复杂性都是来自于顶层。

这就注定了，在越来越复杂的需求框架设计中，通信执行底层本身，只会是越来越内聚化和边缘化。

这就是我把这种面向设备FB功能设计的通用解耦框架开源的原因。

----------------------------------------------------------------------

以前发的几篇相关帖子链接整理如下：

用自由口通信制作的ModbusRTU协议的Master指令的SCL源码

https://www.ad.siemens.com.cn/club/bbs/post_1725735_50_0_0.html#anch

通过以太网UDP协议经串口服务器进行ModbusRTU通信的SCL源码

https://www.ad.siemens.com.cn/club/bbs/post_1725940_50_0_0.html#anch

Modbus设备FB接口设计背后的理念

https://www.ad.siemens.com.cn/club/bbs/post_1792331_50_0_0.html#anch

1200自由口通信的报文和长报文的底层分析

https://www.ad.siemens.com.cn/club/bbs/post_1683110_50_0_0.html#anch

如何分析Modbus通信的执行快慢

https://www.ad.siemens.com.cn/club/bbs/post_1687399_50_0_0.html#anch

擅用博图中的Trace功能

https://www.ad.siemens.com.cn/club/bbs/post_1794586_50_0_0.html#anch

UDP的可靠传输与应用

https://www.ad.siemens.com.cn/club/bbs/post_1712883_50_0_0.html#anch