S7协议解析

S7

1 西门子通信场景

西门子设备使用多种不同现场总线协议，例如：MPI、Profibus、IE 、Profinet 等。Profinet用于将PLC连接到IO模块，而不是设备的管理协议。S7以太网通信协议，主要用于将PLC连接到(i)pc站(PG/PC - PLC 通信)。

大多数情况下，西门子通信遵循传统的主从模式(master-slave)或者**CS模式(**client-server )。

其中PC（master/client）将S7请求发送到现场设备（slave/server)。这些请求用于从设备查询或向设备发送数据或发出某些命令。
当PLC作为通信主站时（master）有一些例外，通过FB14/FB15设备可以向其他设备发起GET和PUT请求。
1
2

在S400系列中，实现了所谓的循环数据I/O功能，这类似于传统的发布者 - 订阅模型。PC可以订阅某些事件，而不是PLC 定期推送所请求的数据送到网络。还有一个合作伙伴（Partner ）或点对点模型，当一个活动的合作伙伴请求连接并调用阻止发送（Block Send），与此同时被动合作伙伴调用阻止接收（Block Receive）方法。

2 S7的OSI模型

其中，第1~4层会由计算机自己完成（底层驱动程序）；
第5层TPKT，应用程数据传输协议，介于TCP和COTP协议之间；这是一个传输服务协议，主要用来在COTP和TCP之间建立桥梁；
第6层COTP，COTP 是 OSI 7层协议定义的位于TCP之上的协议。COTP 以“Packet”为基本单位来传输数据，这样接收方会得到与发送方具有相同边界的数据；
第7层，S7 communication，这一层和用户数据相关，对PLC数据的读取报文在这里完成；
1
2
3
4

刚看到TPKT和COPT也许会很迷惑，其实在具体的报文中:

	1、TPKT的作用是包含用户协议（5~7层）的数据长度（字节数）；
	2、COTP的作用是定义了数据传输的基本单位（在S7Comm中 PDU TYPE：DT data）；
1
2

计算机与PLC进行通讯，可以连接102端口，这是西门子开放的一个通讯端口；

3 S7协议的通讯流程

计算机与1500PLC进行S7Comm以太网通讯，需经过三个过程：

<1>“握手”

           当PC与PLC通过Socket建立链接时，会进行“三次握手”，这是标准的TCP连接方式；这个过程会有Socket自动完成；
1

<2> 通讯请求

          在“握手”之后，并不能马上进行数据交换，还需要"通讯请求"过程。这个过程包含两次报文交换：

            1> PC 发送COTP报文给PLC；在COTP报文中包含“连接请求”和“destination TSAP” - 明确CPU的机架号和槽号；

                  PLC反馈COTP报文，包含“连接确认”；

                    这样PLC就清楚了需要和那个CPU来进行数据通讯；

            2> PC 发送S7Comm报文给PLC；在S7 communicaton报文中包含“通讯请求”；

                  PLC反馈S7Comm报文。
1
2
3
4
5
6
7
8
9
10
11

<3> 交换数据

           数据读写就在这个过程内完成。我们可以组织报文来实现我们需要的功能。这个过程内的报文是S7Comm格式；  

           具体实现时，需要对S7Comm中的第5、6、7层进行编程。
1
2
3

4 S7的协议解析

4.1 S7 PDU

S7协议TCP/IP实现依赖于面向块的ISO传输服务,S7协议包含在TPKT和ISO-COTP协议中，允许PDU（协议数据单元）通过TCP承载。
ISO overTCP通信定义在RFC1006中，ISO-COTP定义在RFC2126其是基于ISO 8073协议（RFC905）。该结构如下图。

S7协议是面向功能/命令的，这意味着传输由S7请求和适当的应答组成（极少数例外）。在连接建立期间协商并行传输的数量和PDU的最大长度。

S7 PDU包含三部分：

头(Header)：包含长度信息，PDU参考和消息类型常量

参数(Parameters)：内容和结构根据PDU的消息和功能类型而有很大差异

数据(Data)：该数据是一个可选字段来携带数据，例如存储器值，块代码，固件数据等
1
2
3
4
5

根据实现的功能不同，S7 communication协议的结构会有所不同；例如，请求数据报文只包含前两部分；

<1>Header

   *01(1 byte): protocol Id: 0x32;

   *02a(1 byte): ROSCTR: Job (01);

   *02b(2 byte): redundancy identification (reserved): 0x0000;

   *2c(2 byte): protocol data unit reference; it’s increased by request event;

   *2d(2 byte): parameter length - the total length (bytes) of parameter part;

   *2e(2 byte): data length; 读取PLC内部数据，此处为00 00；对于其他功能，例如：读取CPU的型号，此处为Data部分的数据长度；
1
2
3
4
5
6
7
8
9
10
11

<2>Parameter（读取数据）

  *3(1 byte): function code: Read Var (0x04)；writeVar (0x05);

    *4(1 byte): item count;

    *5(1 byte): variable specification: 0x12;

    *6(1 byte): length of following address specification – is 7~12length in byte;

    *7(1 byte): syntax Id: S7ANY (0x10);

    *8(1 byte):transport size: BYTE(2);

    *9(2 byte): requested data length;

    *10(2 byte): DB number; 如果访问的不是DB区域，此处为00 00；

    *11(1 byte): Area: 0x84= data block(DB); 0X82= outputs(Q); 0x81=inputs(I); 0x83= Flags(M); 0x1d= S7 timers(T); 0x1c= S7counters(C);

    *12(3 byte):address- start address from zero bit

    *5~*12构成了一个基本的数据请求单元[Item],对多个不同地址区域的数据请求，就是有多个[Item]构成的。

     Parameter部分的数据结构可以总结为：

                 [Function code ]+ [Item count] + Item[1] + Item[2]  . . . Item[n]  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<3>Data

      这一部分与功能有关，例如：读取CPU型号、向CPU存储区写数据；在请求数据报文中此部分不包含任何数据。
1

4.2 头

头长度为10-12个字节，确认消息包含两个额外的错误代码字节。除此之外，标头格式在所有PDU中是一致的

字段：

Protocol ID： [1b]协议常量，始终设置为0x32

Message Type： [1b]消息的一般类型（有时称为ROSCTR类型），消息的其余部分在很大程度上取决于Message Type和功能代码。

                0x01- Job Request：主站发送的请求（例如读/写存储器，读/写块，启动/停止设备，通信设置）

                0x02- Ack：从站发送的简单确认没有数据字段（从未见过它由S300 / S400设备发送）

                0x03- Ack-Data：带有可选数据字段的确认，包含对作业请求的回复

                0x07- Userdata：原始协议的扩展，参数字段包含请求/响应id，（用于编程/调试，SZL读取，安全功能，时间设置，循环读取..）
1
2
3
4
5
6
7

Reserved： [2b]始终设置为0x0000（但可能忽略）

PDU reference： [2b]由主站生成，每次新传输递增，用于链接对其请求的响应，Little-Endian（注意：这是WinCC，Step7和其他西门子程序的行为，它可能是随机的生成后，PLC只将其复制到回复中）

Parameter Length： [2b]参数字段的长度，Big-Endian

Data Length： [2b]数据字段的长度，Big-Endian

(Error class)： [1b]仅存在于Ack-Data消息中，可能的错误常量查看协议常量

(Error code)： [1b]仅出现在Ack-Data消息中，可能的错误常量查看协议常量

4.3 parameter

parameter参数取决于Message Type和功能代码。这里分析仅针对Message Type为：

    （1）0x01- Job Request：主站发送的请求（例如读/写存储器，读/写块，启动/停止设备，通信设置）

   （2） 0x03- Ack-Data：带有可选数据字段的确认，包含对作业请求的回复
1
2
3

Job和Ack Data消息的parameter都是以功能代码开头，其余字段的结构取决于此值。

4.4 设置通信[0xF0] ——即S7协议开始

在可以交换任何其他消息之前，在每个会话开始时会发送该消息对（Job 和Ack Data）。它用于协商Ack队列的大小和最大PDU长度，双方都声明其支持的值。Ack队列的长度决定了可以在没有确认的情况下同时启动的并行作业的数量。PDU和队列长度字段都是大端。

字段：

function code：功能代码，通信设置为0xf0

reserverd：保留字段，默认为ox00

Max AmQ Caller ：Ack队列的大小（主叫）

Max AmQ Callee：Ack队列的大小（被叫）

PDU length： PDU长度。
1
2
3
4
5
6
7
8
9

4.5 S7寻址模型。

通过指定变量的存储区域，地址（偏移量）及其大小或类型来执行数据读取和写入操作。

如前所述，通过指定地址来访问变量，该地址由三个主要属性组成。

1、存储区域：

Merker： [M]任意标记变量或标志寄存器驻留在这里。

Data Block： [DB] DB区域是存储设备不同功能所需数据的最常见位置，这些数据块编号为地址的一部分。

Input： [I]数字和模拟输入模块值，映射到存储器。

Output： [Q]类似的存储器映射输出。

Counter： PLC程序使用的不同计数器的[C]值。

Timer： PLC程序使用的不同定时器的[T]值。
1
2
3
4
5
6
7
8
9
10
11

还有其他不太常见的存储区域（例如本地数据[L]和外设访问[P]等）。

2、变量类型
变量的类型决定了它的长度以及它应该如何解释。一些例子是：

BIT：[X]一位。

WORD：两个字节宽的无符号整数。

DINT：四字节宽的有符号整数。

REAL：四个字节宽的IEEE浮点数。

COUNTER：PLC程序计数器使用的计数器类型。
1
2
3
4
5
6
7
8
9

示例：

变量的示例地址是DB123X 2.1，它访问数据块#123的第三个字节的第二个位。

在这个简短的介绍之后，回到协议的变量读/写的实现。
S7协议支持使用不同的寻址模式在单个消息中查询多个变量读/写。
主要有三种模式：

any-type：这是默认的寻址模式，用于查询任意变量。为每个寻址变量指定所有三个参数（区域，地址，类型）。

db-type：这是专门用于解决DB区域变量的特殊模式，它比any-type地址更紧凑。

symbolic-addressing： S7-1200/1500系列设备使用此模式，允许使用预定义的符号名称寻址某些变量。此处不会详细介绍此模式。
1
2
3
4
5

对于每种寻址模式，Parameters头的结构方式相同：

    Function Code： [1b]读取的常量值0x04或写入作业和回复的0x05。

    Item Count： [1b] Request Item结构的数量。

    Request Item：此结构用于解决实际变量，其长度和字段取决于所使用的寻址类型。这些项目仅存在于作业请求中，无论寻址模式是什么，还是读取或写入请求，都会从相应的Ack数据中发出。
1
2
3
4
5

4.6 DATA

S7 PDU 的Data 部分根据消息的类型（read/write）和方向（Job/Ack Data）而变化：

    Read Request：该Data 部分是空的。

    Read Response： Ack数据消息的Data 部分由Data Item结构组成，每个结构对应于原始请求中存在的每个 Request Items。这些项包含读变量的实际值，格式取决于寻址模式。

    Write Request：包含与读响应类似的 Data Items，一个用于 Parameter头中的每个Request Items。类似地，这些包含要在从设备上写入的变量值。

    Write Response：Ack数据消息的数据部分只包含原始 Write Request中每个Request Items的一个字节错误代码。有关错误代码值，请参阅协议常量。
1
2
3
4
5
6
7

总而言之，Request Item 始终包含变量的描述，其中多个可以在作业请求中发送，而 Data Item包含所描述变量的实际值。所述 Data Item的结构必须开始于偶数字节，所以如果它们的长度是奇数且有以下 Data Item然后将它们填充以零字节。

剩下要讨论的是Request/Data Item结构的格式。如前所述，它们依赖于所使用的寻址模式，因此将基于此介绍它们。

https://www.jianshu.com/p/0e9f74d683b4
http://www.zyiz.net/tech/detail-112446.html
https://www.likecs.com/default/index/show?id=94470

4.7 一些字段