2. S7协议初探：S7协议的历史、S7协议在西门子PLC中的地位、S7协议通讯模型
各位同学，咱们今天聊聊S7协议。说实话，这个协议我用了十几年，每次跟新人讲的时候，我都喜欢先问一个问题：你知道西门子PLC之间是怎么“说话”的吗？
嗯，答案就是S7协议。它不是什么高深莫测的东西，说白了就是西门子自己定义的一套“聊天规则”。今天我就带大家把它的来龙去脉、江湖地位，还有通讯模型，一次性捋清楚。
2.1 S7协议的历史：从“闭门造车”到“工业标准”
咱们先往回倒一倒。上世纪90年代，西门子推出了S7-300/400系列PLC。那时候工业通讯还比较混乱，各家有各家的玩法。西门子当时想：我总不能让我家的PLC跟别家设备说话还得看别人脸色吧？
于是，S7协议诞生了。它最早是西门子内部使用的私有协议，专门用于SIMATIC系列产品之间的通讯。我记得我2008年第一次接触S7-300时，用的还是MPI（多点接口）电缆，那速度慢得让人抓狂——187.5kbps，传个几百字节的程序都得等半天。
后来随着以太网普及，西门子在2005年左右推出了S7-1200和S7-1500，S7协议也顺势跑上了以太网。这时候它才真正“出圈”，成了工业自动化领域的事实标准。
我个人的理解是，S7协议的发展经历了三个阶段：
- 第一阶段（1990s-2000s）：纯私有协议，跑在MPI/Profibus总线上。那时候想跟西门子PLC通讯？要么买西门子的软件，要么自己逆向工程——我当年就干过这事，累得够呛。
- 第二阶段（2005-2015）：以太网化，S7协议封装在TCP/IP里。这时候第三方设备终于能“合法”跟西门子PLC通讯了，但协议细节还是不公开。
- 第三阶段（2015至今）：半开放状态。虽然西门子没正式公开协议文档，但社区已经通过抓包分析把S7协议摸得差不多了。像Snap7、LibNoDave这些开源库，就是基于逆向工程搞出来的。
核心观点：S7协议从“黑盒”走向“灰盒”，是工业通讯民主化的一个缩影。现在你不需要花几万块买西门子的通讯软件，用开源库就能搞定90%的需求。
2.2 S7协议在西门子PLC中的地位：它是“心脏”
你想想看，西门子PLC家族那么庞大——S7-200、S7-300、S7-400、S7-1200、S7-1500，还有各种ET200远程IO站。它们之间怎么协同工作？靠的就是S7协议。
我打个比方：S7协议就像是西门子PLC的“普通话”。不管你是哪个型号、哪个年代的PLC，只要支持S7协议，就能互相读写数据、交换状态、同步程序。没有它，西门子的自动化系统就是一盘散沙。
具体来说，S7协议在西门子体系里扮演了三个角色：
- 编程调试的通道：你用TIA Portal或者Step 7下载程序、在线监控、强制变量，底层走的都是S7协议。我刚开始做项目时，有一次下载程序死活连不上PLC，最后发现是S7连接数满了——嗯，这个坑后面会细讲。
- 设备间通讯的桥梁：两台S7-1500之间做PUT/GET通讯，或者S7-1200跟S7-300交换数据，都是S7协议在干活。它支持点对点、多点广播，甚至路由转发。
- 上位机交互的接口：这是咱们课程的重点。WinCC、Kepware、甚至你自己写的C#程序，想跟PLC交换数据，最终都得通过S7协议。说白了，它是“工业物联网”的第一公里。
个人经验：我见过不少工程师，觉得S7协议太复杂，直接用OPC UA绕过去。但说实话，在实时性要求高的场景（比如运动控制、高速数据采集），S7协议比OPC UA快一个数量级。我的建议是：能走S7就走S7，实在搞不定再上OPC。
2.3 S7协议通讯模型：它到底是怎么工作的？
好，咱们进入正题。S7协议的通讯模型，说白了就是“客户端-服务器”模式。但跟普通的HTTP不一样，它有几个独特的地方。
先看一张图，这是我用SVG画的S7协议通讯模型框架：
这张图展示了S7协议通讯的核心架构。左边是上位机（客户端），右边是PLC（服务器）。它们之间通过TCP连接（端口102）交换S7 PDU（协议数据单元）。
咱们拆开来看：
2.3.1 通讯角色：谁主动，谁被动？
S7协议是典型的主从模式。上位机永远是主动方，PLC永远是被动方。也就是说，只有上位机可以发起请求——比如“把DB1.DBW0的值读给我”、“把Q0.0置位为1”。PLC不会主动给上位机发数据，除非你事先在PLC里写了PUT/GET指令（那是另一种玩法）。
我刚开始做项目时，总想着让PLC主动上报故障。后来发现，S7协议不支持服务器主动推送。怎么办？只能让上位机轮询——每隔100ms读一次故障字。嗯，这就是工业通讯的“笨办法”，但确实管用。
2.3.2 通讯过程：三步走
S7协议的通讯过程，说白了就三步：
- 建立连接（Connection Setup）：上位机向PLC的102端口发起TCP连接。PLC收到后，会回复一个确认包。这时候连接就建立了。
- 数据交换（Data Exchange）：上位机发送S7请求帧（比如读DB、写M区），PLC处理请求后返回响应帧。这个过程可以反复进行，直到通讯结束。
- 断开连接（Disconnection）：上位机主动关闭TCP连接，或者超时自动断开。
这里有个细节：S7协议在TCP之上还有一层自己的握手协议。第一次连接时，上位机和PLC会交换一些参数，比如PDU长度、最大报文大小等。我当年用Wireshark抓包时，看到这些握手包还以为是垃圾数据，后来才明白——这是双方在“谈条件”。
避坑指南：我曾经遇到过一个问题——上位机连上PLC后，读了几次数据就断开了。查了半天，发现是PDU长度协商出了问题。PLC默认的PDU长度是240字节，但我的上位机库设成了480字节。两边对不上，PLC直接拒绝通讯。所以，一定要确保PDU长度一致。
2.3.3 数据模型：PLC里的“内存地图”
S7协议能读写哪些数据？说白了，就是PLC里的各种存储区。我整理了一个表格，方便大家对照：
| 存储区 | 符号 | 说明 | 常见用途 |
|---|---|---|---|
| 过程映像输入 | I | 数字量输入，字节寻址 | 读取传感器、按钮状态 |
| 过程映像输出 | Q | 数字量输出，字节寻址 | 控制继电器、指示灯 |
| 位存储器 | M | 中间变量，位/字节/字/双字 | 临时标志、中间计算结果 |
| 数据块 | DB | 用户定义的数据存储区 | 工艺参数、配方数据、报警信息 |
| 定时器 | T | 定时器当前值 | 读取定时器剩余时间 |
| 计数器 | C | 计数器当前值 | 读取计数值 |
我个人最常用的是DB块。为什么？因为DB块是结构化数据，你可以把温度、压力、流量这些工艺参数放在一个DB里，上位机一次性读取，效率高、管理方便。
2.3.4 报文格式：S7 PDU长什么样？
咱们不深入每个字节，但得知道S7报文的基本结构。一个典型的S7请求帧包含：
- TPKT头（4字节）：TCP传输层头部，包含报文总长度。
- COTP头（3字节）：ISO传输层头部，用于区分不同的S7连接。
- S7头（10-12字节）：协议核心，包含功能码（读/写/控制）、参数长度、数据长度等。
- 参数区：具体操作参数，比如读DB1的起始地址、长度。
- 数据区：如果是写请求，这里放要写入的数据；如果是读响应，这里放读到的数据。
我刚开始用Wireshark分析S7报文时，看到这些十六进制数据头都大了。后来发现，其实你不需要记住每个字节的含义——用Snap7或者Sharp7这些库，它们已经帮你封装好了。你只需要调用ReadDB()、WriteDB()这些函数就行。
我的建议：如果你想深入理解S7协议，可以花一个下午用Wireshark抓包看看。不用全看懂，就看请求和响应的对应关系。你会发现，读一个DB块，其实就是发一个“读请求”帧，然后收一个“读响应”帧。就这么简单。
2.4 小结：S7协议到底牛在哪？
说了这么多，总结一下S7协议的核心优势：
- 轻量高效：报文开销小，实时性高。在100Mbps以太网上，单次读写延迟可以做到1ms以内。
- 兼容性好：从S7-200到S7-1500，甚至老掉牙的S5（通过适配器），都能用S7协议通讯。
- 功能丰富：不仅支持读写数据，还能控制PLC运行/停止、上传下载程序、诊断故障。
当然，它也有缺点——毕竟是私有协议，文档不公开，调试起来全靠经验。但话说回来，工业通讯哪有十全十美的？
好了，这一章咱们把S7协议的来龙去脉、江湖地位和通讯模型都捋了一遍。下一章，我会带大家动手搭建一个S7通讯环境，用Snap7库写一个简单的上位机程序，真正跑起来。到时候你们会发现，S7协议其实没那么神秘——说白了，就是发几个字节，收几个字节的事。
重要提醒：在实际项目中，千万不要在生产线上直接测试S7通讯。我见过有人把PLC的DB块写乱了，导致整条产线停机。建议先在实验室环境，用仿真PLC或者闲置的PLC做测试。
公众号:蓝海资料掘金营，微信deep3321