精华内容
下载资源
问答
  • 一种特殊的技能,基于西门子s7协议的labview程序。
  • 西门子S7协议解析.pdf

    2019-05-13 09:39:43
    西门子S7协议解析,方便各位理解S7协议,从而开发与西门子PLC连接的程序
  • 原标题:工控协议 | 西门子S7协议学习分享*本文作者:gongmo,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。0×1前言随着网络安全的发展,工控安全也越发的走进信息安全人员的工作当中。由于工控安全的文章较少...

    原标题:工控协议 | 西门子S7协议学习分享

    *本文作者:gongmo,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。

    0×1前言

    随着网络安全的发展,工控安全也越发的走进信息安全人员的工作当中。由于工控安全的文章较少,所以写一篇工控协议的分析文章,抛砖引玉,欢迎各位大神共同交流。,而且西门子的plc在工控行业也算是比较流行的设备了,所以这是一篇关于西门子的s7协议的分析文章(适用于s7-300,s7-400,s7-1200)。

    0×2关于组态

    学习西门子s7协议,首先得明白西门子plc的大概构造。虽然我们不必像专门编写PLC程序员那样……

    下图就是一个组态完毕的西门子s7300的模型

    72a3937622b7976610b48d658199a2aa.png

    根据标号,我们可以看出:

    1 电源模块,供电专用

    2 CPU模块,负责处理信息。

    4通信模块,也就是我们经常用网线接入fuzz通信的地方

    5数字量输入模块(DI)

    6数字量输出模块 (DO)(直观上讲,如果编写PLC较好的话,这一排会有小灯再闪,可以像流水灯一样)

    7模拟量输入模块(AI)

    8模拟量输出模块(AO)

    如下是一个helloworld级别的程序,表示电源接通状态,地址%Q0.1、0.2、0.3的3个灯会亮起。

    8174da7ce1d652d38d2ee5104c574219.png

    程序的意思左侧的表示为:接通电源则连接通过。

    右侧为:数据量输出模块对应的IO地址,通俗讲,就是对应的小灯的地址。

    0×3关于s7协议

    西门子s7协议在网络上分析的已经很多,但好像都缺少点简单粗暴的方法,绕多了就感觉一头雾水……

    其实很简单,想要用s7协议进行通信:只需要2步!

    1.发送COTP包请求连接。Plc回应一个COTP包,告诉客户端,确认连接。

    2.确认连接,完啦。

    那么,我们该如何分析这两步操作呢?自问自答一下,肯定是用wireshark抓取包啦。肯定又有人说啦,我们没有s7的plc啊,怎么抓包?(然后用这个做过度,引出下文的……)

    好啦,我们先解决这一步,其实很简单(类似把大象装冰箱里分几步…)

    1)下载snap7 1.4.2,连接:

    https://sourceforge.net/projects/snap7/files/

    2)安装一个虚拟机,win7 即可。

    3)把snap7中rich-demos里的serverdemo.exe和snap7.dll复制到虚拟机中,然后打开serverdemo.exe,输入ip地址,点击start即可。

    4)实体机打开clientdemo.exe即可。

    5)利用wireshark进行抓包分析,捕获的网卡为:VMnet8。

    捕获的数据如下截图:

    c646f02bd828cbc14395698edff565ee.png

    在进行报文分析前,我们首先把s7的大概分析如下:

    6c02bcf41785677bbefc02a9f0811d88.png

    从报文中,我们也可以得出连接的方法如下:

    第一步发送COTP申请连接,这一步主要是请求连接plc。

    请求连接码:0xe0.

    Bytebyte_cotp[22] = {

    0x03,0x00,0x00,0x16,0x11, 0xE0, 0x00, 0x00, 0x00, 0x01, 0x00, 0xC0, 0x01, 0x0A, 0xC1, 0x02, 0x01,0x00, 0xC2, 0x02, 0x01, 0x02 };

    截图如下:

    8553e20421eb928785ed9817b16497d8.png

    接着plc返回连接确认,如果我们要接受判断:就判断第6个字节是:0xd0即可。(不要看wireshark写着0x0d- -,还有不判断返回值也是可以的…不推荐而已)

    返回的连接码

    第二步:确定正式连接

    这次发送的就包括了TPKT和COTP以及S7的报文。如下图,这样就可以保证连接正确了。需要注意的项已经红框画出。

    bdd9df04760713e6eec50db11a35f308.png

    Byte conn[25] = {

    0x03,0x00,0x00,0x19,0x02,0xf0,0x80,0x32,0x01,0x00,0x00,0x00,0x00, 0x00, 0x08, 0x00, 0x00, 0xF0, 0x00, 0x00, 0x01, 0x00, 0x01,0x01, 0xE0 };

    至此,连接正式确立。之后,就可以发送正常的功能包了,比如通过clientdemo.exe发送stop命令,start命令等。一切自由发挥啦。

    但是如果想用一个命令控制DO输出模块上的灯亮的话,还是需要真实机器PLC的,这也是软件模拟的局限性了。

    0×4关于s7协议FUZZ

    Fuzz最常用的方法无非两种:盲fuzz和功能性fuzz。无论进行哪种fuzz,但是请注意保证tpkt和cotp的格式正确,其次还有字节长度正确。否则数据包不能经过验证,也到达不了想要的目的。

    *本文作者:gongmo,本文属 FreeBuf 原创奖励计划,未经许可禁止转载。返回搜狐,查看更多

    责任编辑:

    展开全文
  • 基于开源s7.NET协议,实现与西门子Smart200 PLC进行通讯,文件中包含了s7.NET协议源码以及实现通讯的Demo源码,新手通过该Demo能够轻松掌握通过西门子s7协议西门子所有PLC进行交互。
  • 当前资源包含西门子S7协议模拟器客户端和服务端,可用于西门子S7 通讯开发模拟测试,亲自测试没问题,欢迎下载。
  • 西门子S7协议介绍

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

    原文链接:http://gmiru.com/article/s7comm/

    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)。这些请求用于从设备查询或向设备发送数据或发出某些命令。当PCL作为通信主站时(master)有一些例外,通过FB14/FB15设备可以向其他设备发起GET和PUT请求。

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

    图1

    2. S7 PDU

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

     

    图2

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

    S7 PDU由三个主要部分组成:

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

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

    数据(Data):该数据是一个可选字段来携带数据,例如存储器值,块代码,固件数据等。

    2.1 头(Header)

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

     

    图3

    字段:

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

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

                        0x01- Job Request:主站发送的请求(例如读/写存储器,读/写块,启动/停止设备,通信设置)

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

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

                        0x07- Userdata:原始协议的扩展,参数字段包含请求/响应id,(用于编程/调试,SZL读取,安全功能,时间设置,循环读取..)

    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消息中,可能的错误常量查看协议常量

     

    2.2 parameter 

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

            (1)0x01Job Request:主站发送的请求(例如读/写存储器,读/写块,启动/停止设备,通信设置)

           (2) 0x03- Ack-Data:带有可选数据字段的确认,包含对作业请求的回复

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

    2.2.1.设置通信[0xF0]

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

    参数结构如下图所示:

     

    图4

    字段:

        function code:功能代码,通信设置为0xf0

        reserverd:保留字段,默认为ox00

        Max AmQ Caller :Ack队列的大小(主叫)

        Max AmQ Callee:Ack队列的大小(被叫)

        PDU length: PDU长度。

    2.2.1.1 S7认证和保护

    在配置CPU期间,可以设置三种保护模式。

                    没有保护:正如人们所期望的那样,不需要身份验证。

                    写保护:对于某些数据写入和配置更改操作,需要进行身份验证。

                    读/写保护:就像前一个一样,但某些读操作也需要验证。

    必须注意的是,即使启用了读/写保护,也会允许某些操作,例如读取SZL列表或读取和写入标记区域。其他操作(如读取或写入对象/功能/数据块)应返回权限错误。

    有两个与CPU关联的保护级别,他们是:分配保护级别和实际保护级别。

                    分配保护级别是配置期间设置的保护级别;

                    而实际的保护级别是适用于通信会话的当前保护级别。

    在正常操作期间,在通信设置之后,客户端通过查询SZL读取(SZL ID:0x0132 SZL索引:0x0004)得到读写权限,查询实际保护级别和分配保护级别。

    如果需要认证的密码以用户数据消息被发送到设备,这会降低有效的保护水平。

    任何人认为这至少提供了一点点安全性之前,但它不是。密码是六个字节,几乎以明文形式发送(与常量进行异或并移位)。它是可重放的,可以强制执行。该协议还不提供完整性或机密性保护,可以进行消息注入和修改。S7安全性的一般经验法则是,如果您可以ping设备,则可以拥有它。

    这里必须注意的是,S7-1200/1500系列设备使用略有不同的方法,保护级别处理稍有不同,发送的密码明显更长(实际上是密码的哈希),但它仍然是不变的,可重放。

    2.2.2 读/写变量[0x04/0x05]

    通过指定变量的存储区域地址偏移量)及其大小或类型来执行数据读取和写入操作。在进入协议细节之前,先简要介绍一下S7寻址模型。

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

    存储区域

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

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

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

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

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

        Timer: PLC程序使用的不同定时器的[T]值。

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

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

        BIT:[X]一位。

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

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

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

        COUNTER:PLC程序计数器使用的计数器类型。

    示例:

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

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

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

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

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

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

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

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

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

    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的一个字节错误代码。有关错误代码值,请参阅协议常量。

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

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

    2.2.2.1 具有任何类型寻址的项目结构

    下图显示了Request和Data Item结构:

     

    图5

    请求项的字段:

            Specification Type: [1b]该字段确定结构的主要类型,对于读/写消息,它总是具有值0x12,代表变量规范

            Length: [1b]此项目其余部分的长度。

            Syntax ID: [1b]此字段确定寻址模式和项结构其余部分的格式。它具有任意类型寻址的常量值0x10 。

            Variable Type: [1b]用于确定变量的类型和长度(使用常用的S7类型,如REAL,BIT,BYTE,WORD,DWORD,COUNTER等)。

            Count: [2b]可以用单个项结构选择整个相似变量数组。这些变量必须具有相同的类型,并且必须在内存中连续,并且count字段确定此数组的大小。对于单变量读或写,它设置为1。

            DB Number: [2b]数据库的地址,如果该区域未设置为DB,则忽略该数据库(参见下一个字段)。

            Area: [1b]选择寻址变量的存储区域。见协议常量的内存区域的常数。

            Address: [3b]包含所选存储区中寻址变量的偏移量。实质上,地址被转换为位偏移并在网络(大端)字节顺序中的3个字节上编码。实际上,由于地址空间小于5位,所以从不使用最重要的5位。作为一个例子,DBX40.3将是0x000143 40 * 8 + 3。

    数据项字段

    类似地,相关 Data Item的字段:

            Error Code: [1b]操作的返回值,0xff信号成功。在“ 写入请求”消息中,此字段始终设置为零。

            Variable Type and Count: [1b 2b]与 Request Item中的相同。

            Data:此字段包含已寻址变量的实际值,其大小为len(variable) * count。

    2.2.2.2 具有db-type寻址的项目结构

    下图显示了Reques ItemtData Item结构

     

    图6

    Request Item字段:

    Specification Type: [1b]与任何类型寻址相同。

    Length: [1b]此项目其余部分的长度。

    Syntax ID: [1b]确定寻址模式,db-type的常量值为0xb0 。

    Number of Subitems: [1b] 以下子项的数量。

    Subitem

            Size: [1b]指定从所选地址读取或写入的字节数。

            DB Number: [2b]寻址变量所在的DB。

            Address: [2b]将变量的字节偏移量放入给定的DB中。

     

    Data Item的字段:

    Error Code: [1b]操作的返回值,0xff信号成功。

    Variable Type: [1b]始终设置为0x09(八位字符串)。

    Length: [2b]剩余子响应数据的长度。

    Subresponse:

            Error Code: [1b]与Subitem请求关联的返回值。

            Data:要读取或写入的实际数据,解释这需要相应的Subitem

    2.2.3 阻止/下载[0x1a-1f]

    在西门子术语中,下载是主机将块数据发送到从机。上载刚好与此方向相反。在西门子设备上,程序代码和(大多数)程序数据以块的形式存储,这些块具有自己的头和编码格式,这里不再详细讨论。从协议的角度来看,它们是需要传输的二进制blob.

    西门子设备认可七种不同类型的块:

            OB:组织块,存储主程序。

            (s)DB :(系统)数据块,存储PLC程序所需的数据。

            (s)FC :(系统)功能,无状态功能(没有自己的内存),可以从其他程序调用。

            (s)FB :(系统)功能块,有状态的功能,通常有关联的(S)DB。

    这些块在up/download请求中使用特殊的ASCII文件名进行寻址。此文件名的结构如下:

            File Identifier [1 char]据我所知,它总是具有'_'的值。

            Block Type: [2个字符]确定块类型。

            Block Number: [5个字符]十进制格式的给定块的编号。

            Destination File System: [1 char]此字段的值可以是“A”表示活动,“P”表示被动文件系统。复制到活动文件系统的块会立即链接,这意味着它们会在PLC执行恢复后立即生效。另一方面,需要首先激活复制到被动文件系统的块。

    示例: 

    文件名是_0800001P,用于将OB 1复制到被动文件系统或从被动文件系统复制OB 1。

    ** 这里快速介绍一下块编码和内容保护。有两种措施可以保护程序和数据的内容,并允许程序库的分发。第一个称为专有技术保护,如果设置,则防止STEP7或TIA显示块的实际内容。不幸的是,这很容易绕过,因为它只是在块的标题中设置了两位并且可以很容易地被清除。另一个保护措施是块“加密”,实际上它只是一个线性变换的混淆(逐字节xoring和旋转常数),再次应该是微不足道的绕过。因此,不要依赖这些“安全”机制来保护您的专有技术。否则,数据块包含存储器的原始初始化图像。 **

    上传和下载块涉及3-3种不同类型的消息对。下面列出了相关的功能代码:

            请求下载 - 0x1a

            下载块 - 0x1b

            下载结束 - 0x1c

            开始上传 - 0x1d

            上传块 - 0x1e

            结束上传 - 0x1f

    这些消息的结构非常简单,但是消息序列(特别是下载)需要一些解释。

    2.2.3.1 上传块(0x1a)

    上传块序列非常直观,如下所示:

     

    图7

    Ack Data - Start Upload消息中,从设备告知块的长度,然后主设备继续发送Job - Upload Block消息,直到接收到所有字节。最后,它使用Job - End Upload消息关闭上传序列。块的实际数据由从Ack Data - Upload Block消息中发送。

    Job - Start Upload参数头:

            Function Code: [1b] 0x1d用于开始上传

            Function Status: [1b]仅用于上传消息,如果要发送更多数据,则设置为0x01。

            Unknown: [2b]总是0x0000。

            Session ID: [4b]与每个上传序列相关联的唯一ID,它在Ack Data - Start Upload消息中设置。

            Filename Length: [1b]以下文件名的长度。

            Filename:标识上面引入的块的文件名。

    Ack Data - Start Upload参数标题:

            Function Code: [1b] 0x1d用于开始上传

            Function Status: [1b]与上述相同。

            Unknown: [2b]总是0x0100。

            Session ID: [4b] 此处设置会话ID,连续消息使用相同的值。

            Length String Length: [1b]以下块长度字符串的长度

            Length String:编码为ASCII C字符串的块的十进制长度(不要问我为什么......)。

    作业 - 上传参数头:

    包含功能代码(0x1e),功能状态,未知(0x0000)和会话ID字段,如上所述。

    确认数据 - 上传参数和数据部分:

            Function Code: [1b] 0x1e用于上传

            Function Status: [1b]如果要发送更多数据,则设置为0x01。

           Data 部分:

                    Length [2b] 块数据的长度。

                    Unknown [2b]总是0x00fb。

                    Block Data上传数据块的一部分。

    Job - End Upload参数头:

             包含功能代码(0x1f),功能状态未知(0x0000)和会话ID字段,如上所述。

    Ack Data - End Upload参数头:

            只包含功能代码(0x1f)

     

    2.2.3.2 下载块(0x1b)

    上传和下载之间的关键区别在于,在下载过程中,通信方向发生变化,从站成为主站(很好)在初始请求下载交换后,从站发送作业消息,主站回复Ack数据,这是“仅从站回复”规则的唯一例外。发送 所有字节后,主服务器(原始服务器)发送下载结束作业以关闭下载会话。请参见下面的序列图。

     

    图8

    实际消息的结构与上传消息非常相似,所以这里只介绍差异。

    该 Job - Request Download 消息中包含了两个附加字段,该Block Length下载的块和Payload Length块(不块头的长度)。这两个字段都是编码为ASCII字符串的十进制数字。响应 Ack Data - Request Download 仅包含功能代码

    另一个显着的区别是,虽然会话ID字段存在但不使用(仍为0x00000000)而是在每个 Job - Download Block传输文件名。其余消息的结构与前面讨论的相同。

    2.2.4 PLC控制[0x28]

    PLC控制消息用于在从设备上执行修改其执行/存储状态的不同例程。这些命令用于启动或停止PLC控制程序的执行,激活或删除设备上的程序块或将其配置保存到永久存储器。这些消息的结构非常简单,它们将在不讨论确切细节的情况下进行解释。

     Job - PLC Control 消息由两个主要部分组成,被调用的方法和它的参数(也被编码为ASCII字符串)的ASCII名字。方法名称的结构与块传输部分中引入的文件名的方式类似。参数取决于方法类型,可以将它们视为参数。该 Ack Data消息仅包含PLC控制功能码。

    一些示例函数名称及其相关参数:

                _INSE:激活设备上下载的块,参数是块的名称(例如OB1)。

                _DELE:从设备的文件系统中删除一个块,该参数也是块的名称。

                P_PROGRAM:设置设备的运行状态(启动,停止,mem重置)。它在没有参数的情况下发送以启动设备,但是停止plc程序使用不同的功能代码(参见下一节)。

                _GARB:压缩PLC内存。

                _MODU:将ram复制到rom,该参数包含文件系统标识符(A/E/P)。

    2.2.5 PLC停止[0x29]

    所述PLC Stop消息是基本相同的PLC Control 消息。唯一的区别是消息中没有参数,并且例程部分始终设置为P_PROGRAM。不知道为什么它有单独的类型而不是使用参数来确定它是一个开始或停止消息。

     

    展开全文
  • 西门子 通过S7协议实现S7-1200与S7-200的通信pdf,西门子 通过S7协议实现S7-1200与S7-200的通信
  • 西门子以太网S7comm协议,与西门子S7-300 ,西门子828D数控通信的协议
  • 用于数据中心(服务器等)直接通信西门子PLC的S7协议,TCP/ip通信效率高,安全稳定 可以直接读取S7系列全部PLC,使用非常简单
  • 西门子PLC以太网S7协议通讯源码改进,在原基础上做了很大的改动
  • 西门子PLC-s7协议解析

    2021-02-03 12:06:55
    内含S7通讯库,协议解析表,通讯样例。
  • 西门子S7协议笔记

    千次阅读 2020-06-09 19:11:37
    TPKT(ISO Transport Service ontop of the TCP)TPKT是一种“封装”协议。它在自己的数据包中携带OSI数据包的数据有效载荷(负载),然后将结果结构传递给TCP,然后将该数据包作为TCP / IP数据包处理。将数据传递给...

    参考模型
    在这里插入图片描述
    TPKT(ISO Transport Service ontop of the TCP)TPKT是一种“封装”协议。它在自己的数据包中携带OSI数据包的数据有效载荷(负载),然后将结果结构传递给TCP,然后将该数据包作为TCP / IP数据包处理。将数据传递给TPKT的OSI程序不会察觉它们的数据将通过TCP / IP传输,因为TPKT模拟OSI协议传输服务访问点(TSAP:Transport Service Access Poin)。

    TPKT(Transport Service ontop of the TCP):通过TCP的传输服务。介于TCP和COTP之间。属于传输服务类的协议,它为上层的COTP和下层TCP进行了过渡。功能为在COTP和TCP之间建立桥梁,其内容包含了上层协议数据包的长度。一般与COTP一起发送,当作Header段。我们常用的RDP协议(remote desktop protocol,windows的远程桌面协议)也是基于TPKT的,TPKT的默认TCP端口为102(RDP为3389),其实它本身为payload增加的数据并不多,主要就是以下几个:

    versionreservedlengthpayload

    version,1byte,表明版本信息
    reserved,1byte,看到这个名字就知道是保留的了
    length,2byte,包括payload和这三部分在内的总长度

    COTP(Connection Oriented Transport Protocol/面向连接的传输协议),比较TCP与COTP两种协议,因为它们都是用于通过网络可靠地传输用户数据,基于数据流的与基于数据包的:COTP将数据包从一个用户传输到另一个用户,所以接收者将获得与发送者传输完全相同的数据边界。TCP将连续的数据流传输到接收器,因此TCP上的协议通常必须自己添加这样的边界(如TPKT协议)。

    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)。这些请求用于从设备查询或向设备发送数据或发出某些命令。当PCL作为通信主站时(master)有一些例外,通过FB14/FB15设备可以向其他设备发起GET和PUT请求。
      在这里插入图片描述

    S7 协议工作流程
    client与server通过socket建立连接,过程是标准的TCP连接方式,这一步完成连接的建立
    client发送COTP,请求连接PLC,报文中包含CR Connect Request和Destination TSAP,从而标识出CPU的机架号和槽号
    PLC返回COTP,确认连接,报文中包含CC Connect Confirm,此时server已经明确client与哪个CPU进行通讯
    client发送S7 Communication给server,报文中包含Setup communication,即通讯请求
    server返回S7 Communication给client,报文的ROSCTR为ACK_DATA,有确认的意思,包含了对作业请求的回复
    client与server发送交换数据的报文,仍以S7 Communication完成
    备注:2-5的步骤中,2与3完成数据传输前连接的功能,4与5则完成连接之后的通讯请求,如果绕过通讯请求的建立,在有TCP时就进行数据交换,服务器一般会直接断连
    2. 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):该数据是一个可选字段来携带数据,例如存储器值,块代码,固件数据等。
    2.1 头(Header)
    头长度为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读取,安全功能,时间设置,循环读取…)
    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消息中,可能的错误常量查看协议常量

    2.2 parameter
    Parameter.Function中的取值及其对应的功能:
    Function与Code对应关系

    Parameters CodeParameters Function
    0x00diagnostics
    0x04read
    0x05write
    0x1arequest_download
    0x1bdownload_block
    0x1cend_download
    0x1dstart_download
    0x1eupload
    0x1fend_upload
    0x28plc_control
    0x29plc_stop
    0xf0setup communication

    parameter参数取决于Message Type和功能代码。这里分析仅针对Message Type为:
    (1)0x01- Job Request:主站发送的请求(例如读/写存储器,读/写块,启动/停止设备,通信设置)
    (2)0x03- Ack-Data:带有可选数据字段的确认,包含对作业请求的回复
    Job和Ack Data消息的parameter都是以功能代码开头,其余字段的结构取决于此值。
    2.2.1.设置通信[0xF0]
    在可以交换任何其他消息之前,在每个会话开始时会发送该消息对(Job 和Ack Data)。它用于协商Ack队列的大小和最大PDU长度,双方都声明其支持的值。Ack队列的长度决定了可以在没有确认的情况下同时启动的并行作业的数量。PDU和队列长度字段都是大端。
    参数结构如下图所示:
    在这里插入图片描述
    字段:
    Function Code:功能代码,通信设置为0xf0
    Reserverd:保留字段,默认为ox00
    Max AmQ Caller :Ack队列的大小(主叫)
    Max AmQ Callee:Ack队列的大小(被叫)
    PDU length: PDU长度。
    2.2.1.1 S7认证和保护
    在配置CPU期间,可以设置三种保护模式。
    没有保护:正如人们所期望的那样,不需要身份验证。
    写保护:对于某些数据写入和配置更改操作,需要进行身份验证。
    读/写保护:就像前一个一样,但某些读操作也需要验证。
    必须注意的是,即使启用了读/写保护,也会允许某些操作,例如读取SZL列表或读取和写入标记区域。其他操作(如读取或写入对象/功能/数据块)应返回权限错误。
    有两个与CPU关联的保护级别,他们是:分配保护级别和实际保护级别。
    分配保护级别是配置期间设置的保护级别;
    而实际的保护级别是适用于通信会话的当前保护级别。
    在正常操作期间,在通信设置之后,客户端通过查询SZL读取(SZL ID:0x0132 SZL索引:0x0004)得到读写权限,查询实际保护级别和分配保护级别。
    如果需要认证的密码以用户数据消息被发送到设备,这会降低有效的保护水平。
    任何人认为这至少提供了一点点安全性之前,但它不是。密码是六个字节,几乎以明文形式发送(与常量进行异或并移位)。它是可重放的,可以强制执行。该协议还不提供完整性或机密性保护,可以进行消息注入和修改。S7安全性的一般经验法则是,如果您可以ping设备,则可以拥有它。
    这里必须注意的是,S7-1200/1500系列设备使用略有不同的方法,保护级别处理稍有不同,发送的密码明显更长(实际上是密码的哈希),但它仍然是不变的,可重放。
    2.2.2 读/写变量[0x04/0x05]
    通过指定变量的存储区域,地址(偏移量)及其大小或类型来执行数据读取和写入操作。在进入协议细节之前,先简要介绍一下S7寻址模型。
    如前所述,通过指定地址来访问变量,该地址由三个主要属性组成。
    存储区域:
    Merker: [M]任意标记变量或标志寄存器驻留在这里。
    Data Block: [DB] DB区域是存储设备不同功能所需数据的最常见位置,这些数据块编号为地址的一部分。
    Input: [I]数字和模拟输入模块值,映射到存储器。
    Output: [Q]类似的存储器映射输出。
    Counter: PLC程序使用的不同计数器的[C]值。
    Timer: PLC程序使用的不同定时器的[T]值。
    还有其他不太常见的存储区域(例如本地数据[L]和外设访问[P]等)。
    变量的类型决定了它的长度以及它应该如何解释。一些例子是:
    BIT:[X]一位。
    WORD:两个字节宽的无符号整数。
    DINT:四字节宽的有符号整数。
    REAL:四个字节宽的IEEE浮点数。
    COUNTER:PLC程序计数器使用的计数器类型。
    示例:
    变量的示例地址是DB123X 2.1,它访问数据块#123的第三个字节的第二个位。
    在这个简短的介绍之后,回到协议的变量读/写的实现。S7协议支持使用不同的寻址模式在单个消息中查询多个变量读/写。主要有三种模式:
    any-type:这是默认的寻址模式,用于查询任意变量。为每个寻址变量指定所有三个参数(区域,地址,类型)。
    db-type:这是专门用于解决DB区域变量的特殊模式,它比any-type地址更紧凑。
    symbolic-addressing: S7-1200/1500系列设备使用此模式,允许使用预定义的符号名称寻址某些变量。此处不会详细介绍此模式。
    对于每种寻址模式,Parameters头的结构方式相同:
    Function Code: [1b]读取的常量值0x04或写入作业和回复的0x05。
    Item Count: [1b] Request Item结构的数量。
    Request Item:此结构用于解决实际变量,其长度和字段取决于所使用的寻址类型。这些项目仅存在于作业请求中,无论寻址模式是什么,还是读取或写入请求,都会从相应的Ack数据中发出。
    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的一个字节错误代码。有关错误代码值,请参阅协议常量。
    总而言之,Request Item 始终包含变量的描述,其中多个可以在作业请求中发送,而 Data Item包含所描述变量的实际值。所述 Data Item的结构必须开始于偶数字节,所以如果它们的长度是奇数且有以下 Data Item然后将它们填充以零字节。
    剩下要讨论的是Request/Data Item结构的格式。如前所述,它们依赖于所使用的寻址模式,因此将基于此介绍它们。
    2.2.2.1 具有any-type任何类型寻址的项目结构
    下图显示了Request和Data Item结构:
    在这里插入图片描述
    请求项的字段:
    Specification Type: [1b]该字段确定结构的主要类型,对于读/写消息,它总是具有值0x12,代表变量规范。
    Length: [1b]此项目其余部分的长度。
    Syntax ID: [1b]此字段确定寻址模式和项结构其余部分的格式。它具有任意类型寻址的常量值0x10 。
    Variable Type: [1b]用于确定变量的类型和长度(使用常用的S7类型,如REAL,BIT,BYTE,WORD,DWORD,COUNTER等)。
    Count: [2b]可以用单个项结构选择整个相似变量数组。这些变量必须具有相同的类型,并且必须在内存中连续,并且count字段确定此数组的大小。对于单变量读或写,它设置为1。
    DB Number: [2b]数据库的地址,如果该区域未设置为DB,则忽略该数据库(参见下一个字段)。
    Area: [1b]选择寻址变量的存储区域。见协议常量的内存区域的常数。
    Address: [3b]包含所选存储区中寻址变量的偏移量。实质上,地址被转换为位偏移并在网络(大端)字节顺序中的3个字节上编码。实际上,由于地址空间小于5位,所以从不使用最重要的5位。作为一个例子,DBX40.3将是0x000143 40 * 8 + 3。
    数据项字段
    类似地,相关 Data Item的字段:
    Error Code: [1b]操作的返回值,0xff信号成功。在“ 写入请求”消息中,此字段始终设置为零。
    Variable Type and Count: [1b 2b]与 Request Item中的相同。
    Data:此字段包含已寻址变量的实际值,其大小为len(variable) * count。
    2.2.2.2 具有db-type寻址的项目结构
    下图显示了Reques Itemt和Data Item结构
    图6
    Request Item字段:
    Specification Type: [1b]与任何类型寻址相同。
    Length: [1b]此项目其余部分的长度。
    Syntax ID: [1b]确定寻址模式,db-type的常量值为0xb0 。
    Number of Subitems: [1b] 以下子项的数量。
    Subitem:
    Size: [1b]指定从所选地址读取或写入的字节数。
    DB Number: [2b]寻址变量所在的DB。
    Address: [2b]将变量的字节偏移量放入给定的DB中。

    Data Item的字段:
    Error Code: [1b]操作的返回值,0xff信号成功。
    Variable Type: [1b]始终设置为0x09(八位字符串)。
    Length: [2b]剩余子响应数据的长度。
    Subresponse:
    Error Code: [1b]与Subitem请求关联的返回值。
    Data:要读取或写入的实际数据,解释这需要相应的Subitem。
    2.2.3 阻止/下载[0x1a-1f]
    在西门子术语中,下载是主机将块数据发送到从机。上载刚好与此方向相反。在西门子设备上,程序代码和(大多数)程序数据以块的形式存储,这些块具有自己的头和编码格式,这里不再详细讨论。从协议的角度来看,它们是需要传输的二进制blob.
    西门子设备认可七种不同类型的块:
    OB:组织块,存储主程序。
    (s)DB :(系统)数据块,存储PLC程序所需的数据。
    (s)FC :(系统)功能,无状态功能(没有自己的内存),可以从其他程序调用。
    (s)FB :(系统)功能块,有状态的功能,通常有关联的(S)DB。
    这些块在up/download请求中使用特殊的ASCII文件名进行寻址。此文件名的结构如下:
    File Identifier: [1 char]据我所知,它总是具有’_'的值。
    Block Type: [2个字符]确定块类型。
    Block Number: [5个字符]十进制格式的给定块的编号。
    Destination File System: [1 char]此字段的值可以是“A”表示活动,“P”表示被动文件系统。复制到活动文件系统的块会立即链接,这意味着它们会在PLC执行恢复后立即生效。另一方面,需要首先激活复制到被动文件系统的块。
    示例:
    文件名是_0800001P,用于将OB 1复制到被动文件系统或从被动文件系统复制OB 1。
    ** 这里快速介绍一下块编码和内容保护。有两种措施可以保护程序和数据的内容,并允许程序库的分发。第一个称为专有技术保护,如果设置,则防止STEP7或TIA显示块的实际内容。不幸的是,这很容易绕过,因为它只是在块的标题中设置了两位并且可以很容易地被清除。另一个保护措施是块“加密”,实际上它只是一个线性变换的混淆(逐字节xoring和旋转常数),再次应该是微不足道的绕过。因此,不要依赖这些“安全”机制来保护您的专有技术。否则,数据块包含存储器的原始初始化图像。 **
    上传和下载块涉及3-3种不同类型的消息对。下面列出了相关的功能代码:
    请求下载 - 0x1a
    下载块 - 0x1b
    下载结束 - 0x1c
    开始上传 - 0x1d
    上传块 - 0x1e
    结束上传 - 0x1f
    这些消息的结构非常简单,但是消息序列(特别是下载)需要一些解释。
    2.2.3.1 上传块(0x1a)
    上传块序列非常直观,如下所示:
    在这里插入图片描述
    在Ack Data - Start Upload消息中,从设备告知块的长度,然后主设备继续发送Job - Upload Block消息,直到接收到所有字节。最后,它使用Job - End Upload消息关闭上传序列。块的实际数据由从Ack Data - Upload Block消息中发送。
    Job - Start Upload参数头:
    Function Code: [1b] 0x1d用于开始上传。
    Function Status: [1b]仅用于上传消息,如果要发送更多数据,则设置为0x01。
    Unknown: [2b]总是0x0000。
    Session ID: [4b]与每个上传序列相关联的唯一ID,它在Ack Data - Start Upload消息中设置。
    Filename Length: [1b]以下文件名的长度。
    Filename:标识上面引入的块的文件名。
    Ack Data - Start Upload参数标题:
    Function Code: [1b] 0x1d用于开始上传。
    Function Status: [1b]与上述相同。
    Unknown: [2b]总是0x0100。
    Session ID: [4b] 此处设置会话ID,连续消息使用相同的值。
    Length String Length: [1b]以下块长度字符串的长度。
    Length String:编码为ASCII C字符串的块的十进制长度。
    Job - Upload Block参数头:
    包含Function Code:(0x1e),Function Status:,Unknown:(0x0000)和SessionID字段,如上所述。
    Ack Data - Upload Block参数和数据部分:
    Function Code: [1b] 0x1e用于上传。
    Function Status: [1b]如果要发送更多数据,则设置为0x01。
    Data 部分:
    Length: [2b] 块数据的长度。
    Unknown: [2b]总是0x00fb。
    Block Data:上传数据块的一部分。
    Job - End Upload参数头:
    包含Function Code:(0x1f),Function Status:,Unknown:和Session ID字段,如上所述。
    Ack Data - End Upload参数头:
    只包含Function Code:(0x1f)

    2.2.3.2 下载块(0x1b)
    上传和下载之间的关键区别在于,在下载过程中,通信方向发生变化,从站成为主站(很好)。在初始请求下载交换后,从站发送作业消息,主站回复Ack数据,这是“仅从站回复”规则的唯一例外。发送完 所有字节后,主服务器(原始服务器)发送下载结束作业以关闭下载会话。请参见下面的序列图。
    在这里插入图片描述
    实际消息的结构与上传消息非常相似,所以这里只介绍差异。
    该 Job - Request Download 消息中包含了两个附加字段,该Block Length下载的块和Payload Length块(不块头的长度)。这两个字段都是编码为ASCII字符串的十进制数字。响应 Ack Data - Request Download 仅包含功能代码。
    另一个显着的区别是,虽然会话ID字段存在但不使用(仍为0x00000000)而是在每个 Job - Download Block传输文件名。其余消息的结构与前面讨论的相同。
    2.2.4 PLC控制[0x28]
    PLC控制消息用于在从设备上执行修改其执行/存储状态的不同例程。这些命令用于启动或停止PLC控制程序的执行,激活或删除设备上的程序块或将其配置保存到永久存储器。这些消息的结构非常简单,它们将在不讨论确切细节的情况下进行解释。
    Job - PLC Control 消息由两个主要部分组成,被调用的方法和它的参数(也被编码为ASCII字符串)的ASCII名字。方法名称的结构与块传输部分中引入的文件名的方式类似。参数取决于方法类型,可以将它们视为参数。该 Ack Data消息仅包含PLC控制功能码。
    一些示例函数名称及其相关参数:
    _INSE:激活设备上下载的块,参数是块的名称(例如OB1)。
    _DELE:从设备的文件系统中删除一个块,该参数也是块的名称。
    P_PROGRAM:设置设备的运行状态(启动,停止,mem重置)。它在没有参数的情况下发送以启动设备,但是停止plc程序使用不同的功能代码(参见下一节)。
    _GARB:压缩PLC内存。
    _MODU:将ram复制到rom,该参数包含文件系统标识符(A/E/P)。
    2.2.5 PLC停止[0x29]
    所述PLC Stop消息是基本相同的PLC Control 消息。唯一的区别是消息中没有参数,并且例程部分始终设置为P_PROGRAM。不知道为什么它有单独的类型而不是使用参数来确定它是一个开始或停止消息。

    展开全文
  • 西门子S7协议案例.zip

    2019-08-22 15:50:34
    上位机软件通过Socket方式与西门子1200交换数据,PLC做服务器端,读取DB1的数据; 打开Socket,发送握手03 00 00 16 11 E0 00 00 00 01 00 C0 01 0A C1 02 01 00 C2 02 01 00,回复03 00 00 16 11 D0 00 01 00 01 00 ...
  • 今天我们来分享一下关于西门子S7协议的通信分析。 西门子作为一个老牌工控企业,在中国市场拥有很高的市场占有率。如果要说起西门子的通信协议,相信大家多多少少能说出一些,比如MPI、PPI、USS、Profibus、...

    -Begin-

    前言

    前面我们对ModbusRTU协议、ModbusTCP协议、欧姆龙FinsTCP协议、三菱SLMP协议都做了说明:

    今天我们来分享一下关于西门子S7协议的通信分析。

    西门子作为一个老牌工控企业,在中国市场拥有很高的市场占有率。如果要说起西门子的通信协议,相信大家多多少少能说出一些,比如MPI、PPI、USS、Profibus、Profinet、S7等,但是西门子在协议的开放性方面还是相对要封闭一些,所以很多协议都是不开放的。

    在这里,我主要是结合Wireshark抓包工具,跟大家去分享一下,如何是一步一步抓取西门子S7通信协议底层通信报文的,希望通过我一步一步地分析,(获取资料加VX:xiketang777)让大家都能够对西门子S7协议有所了解的同时,也学会基本的抓包操作与报文分析。

    值得说明一下,西门子S7协议非开放协议,以下内容,仅供学习参考。

    环境搭建

    1、首先我们要准备要准备一个西门子的PLC,并保证PLC与PC之间的网络连接正常。PS:对于手头没有PLC的小伙伴,可以查看这篇文章:

    基于S7-PLCSIM Advanced搭建S7通信仿真环境

    2、为了抓取到通信的报文,需要实现PC与PLC之间的通信,这里我采用的方式是通过KepServer V6.4来实现,后台关键词:OPC学习套装

    3、安装Wireshark抓包软件(获取资料加VX:xiketang777),后台回复关键词:Wireshark

    4、认识S7协议的网络模型。

    图片

    操作步骤

    1、首先将KepServer与PLC之间的通信连接配置好;

    2、将Wireshark软件打开,并处于监控报文状态;

    3、将KepServer进行连接PLC,此时Wireshark软件中会出现报文的数据,将KepServer连接停止并关闭软件,同时将Wireshark的监控停止(获取资料加VX:xiketang777),以便进行后续的报文分析;

    协议分析

    1、我们发现西门子的S7通信并不是简简单单的TCP通信,在TCP执行三次握手之后,还需要发送两次连接验证,在两次连接验证之后,才进行真正的数据交互。

    2、三次握手过程,如下图所示:

    图片

    3、S7连接第一次验证,如下图所示:

    4、S7连接第二次验证,如下图所示:

    5、四次挥手过程,如下图所示:

    图片

    6、S7第一次验证发送报文分析:

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x0016

    COTP(第六层:表示层)

    该层总共占用18个字节:

    长度:0x11

    PDU类型(CR Connect Request 连接请求):0x0E

    目标引用:0x0000

    源引用:0x0001

    扩展格式/流控制:0x00

    参数代码 TPDU-Size:0xC0

    参数长度:0x01

    TPDU大小:0x0A

    参数代码 SRC-TASP:0xC1

    参数长度:0x02

    源TSAP Source TSAP:0x0201

    参数代码 DST-TASP:0xC2

    参数长度:0x02

    目标TSAP Destination TSAP:0x0201

    7、S7第一次验证返回报文

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x0016

    COTP(第六层:表示层)

    该层总共占18个字节:

    长度:0x11

    PDU类型(CC Connect Confirm 连接确认):0x0D

    目标引用:0x0001

    源引用:0x0006

    扩展格式/流控制:0x00

    参数代码 TPDU-Size:0xC0

    参数长度:0x01

    TPDU大小:0x0A

    参数代码 SRC-TASP:0xC1

    参数长度:0x02

    Source TSAP:0x0201

    参数代码 DST-TASP:0xC2

    参数长度:0x02

    Destination TSAP:0x0201

    8、S7第二次验证发送报文

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x0019

    COTP(第六层:表示层)

    该层总共占3个字节:

    长度:0x02

    PDU类型(DT Data):0XF0

    目标引用:0x80

    S7 Communication(第七层:应用层)

    该层总用占18个字节(获取资料加VX:xiketang777),并且分两部分:

    Header:

    协议ID(Protocol ID):0x32

    ROSCTR:0x01

    预留:0x0000

    协议数据单元引用:0x037C

    参数长度:0x0008

    数据长度:0x0000

    Parameter:

    功能码:0xF0

    预留:0x00

    最大AmQ(Calling):0x0001

    最大AmQ(Called):0x0001

    PDU长度:0x03C0

    9、S7第二次验证返回报文

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x0019

    COTP(第六层:表示层)

    该层总共占3个字节:

    长度:0x02

    PDU类型(DT Data):0XF0

    目标引用:0x80

    S7 Communication(第七层:应用层)

    该层总用占20个字节,并且分两部分:

    Header:

    协议ID(Protocol ID):0x32

    Ack_Data:0x03

    预留:0x0000

    协议数据单元引用:0x037C

    参数长度:0x0008

    数据长度:0x0000

    错误等级:0x00

    错误代码:0x00

    Parameter:

    功能码:0xF0

    预留:0x00

    最大AmQ(Calling):0x0001

    最大AmQ(Called):0x0001

    PDU长度:0x00F0

    10、读取数据发送报文:读取DB1.DBX0.0 开始的4个字节

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x001F

    COTP(第六层:表示层)

    该层总共占3个字节:

    长度:0x02

    PDU类型(DT Data):0XF0

    目标引用:0x80

    S7 Communication(第七层:应用层)

    该层总用占24个字节,并且分两部分:

    Header:

    协议ID(Protocol ID):0x32

    Ack_Data:0x01

    预留:0x0000

    协议数据单元引用:0x037D

    参数长度:0x000E

    数据长度:0x0000

    Parameter:

    功能码 Read Var:0x04

    通信项数:0x01

    通信项1:

    通信项Header

    变量指定:0x12

    地址长度:0x0A

    Syntax ID:0x10

    传输数据类型 byte:0x02

    通信项Param

    读取长度:0x04

    DB号:0x01

    存储区类型 DB存储区:0x84

    开始字节:0x000000

    11、 读取数据返回报文

    图片

    TPKT(第五层:会话层)

    该层总共占4个字节:

    版本号:0x03

    预留:0x00

    长度:0x001D

    COTP(第六层:表示层)

    该层总共占3个字节:

    长度:0x02

    PDU类型(DT Data):0XF0

    目标引用:0x80

    S7 Communication(第七层:应用层)

    该层总用占22个字节(获取资料加VX:xiketang777),并且分两部分:

    Header:

    协议ID(Protocol ID):0x32

    Ack_Data:0x03

    预留:0x0000

    协议数据单元引用:0x037D

    参数长度:0x0002

    数据长度:0x0008

    错误等级:0x00

    错误代码:0x00

    Parameter:

    功能码 Read Var:0x04

    通信项数:0x01

    通信项1:

    返回结果Success:0xFF

    传输数据类型 Byte/Word/DWord:0x04

    长度:0x0020

    数据:0x00000000

    -END-

    展开全文
  • 不需要组态,直接连接西门子,通过s7协议读写PLC,减少kepServer配置,直接读写PLC,项目刚用完的,c#直接可以使用。
  • 通过S7协议或opc协议远程连接西门子模拟器 1、环境准备 安装博途 下载:Nettoplcsim,https://sourceforge.net/projects/nettoplcsim/ 2、博途配置 添加PLC S7-1200、S7-1500需要设置允许PUT/GET通讯访问,...
  • 最近在使用C#与西门子1500PLC走S7协议通讯时,发现传输到PLC的数据与要传输的数据不一样,需要更改大小端。 根据数据类型写了一个更改大小端的方法 即交换字节顺序,如下: static byte[] convertArray = new byte[4...
  • 西门子SIMATIC TDC与WINCC基于S7协议的通讯pdf,西门子SIMATIC TDC与WINCC基于S7协议的通讯
  • 由于国内没有西门子S7协议的过多资料,以上文档是本人参阅外文资料,总结得来,十分详细
  • C# 读写西门子PLC数据,包含S7协议,s7支持S7-200,S7-200smart,S7-300PLC,S7-400PLC,S7-1200PLC,S7-1500PLC 使用一个开源的技术来读写西门子plc数据,使用的是基于以太网的TCP/IP实现,不需要额外的组件,读取...
  • 西门子S7 协议有哪些属性,优势及特征?pdf,西门子S7 协议有哪些属性,优势及特征?所有 SIMATIC S7 和 C7 控制器都集成了用户程序可以读写数据的 S7 通信服务。S7-400 控制器使用 SFB,S7-300 和 C7 控制器使用 FB...
  • 可以通过以太网(网口)经S7协议连接西门子200 200smart 300 400 1200 1500 PLC,读写变量没问题,支持XP WIN7 WIN10.
  • 西门子S7协议通讯代码(C#版),使PC与S7-200_300_400_1200通信
  • 西门子S7通讯协议API

    热门讨论 2014-01-27 20:32:59
    S7通讯协议 包含API函数说明和接口 整个编程的方式均有说明
  • 西门子s7-200 PPI通讯协议 西门子s7-200 PPI通讯协议
  • S7协议西门子私有协议但网上分析人数较多基本算半公开。 压缩包内附带协议解析文档与博客内较为一致,和协议的Server与Client模拟器以及示例的pcap报文
  • 本文是Snap7软件包系列教程的第2篇,我们来介绍下S7协议,包括如下几个主题:1、S7协议简介2、S7协议命令简介3、S7协议通信的角色与模式1、S7协议简介S7协议西门子S7系列PLC通信的核心协议,它是一种位于传输层之...
  • 西门子PLC S7-1200协议解析,分析了西门子PLC S7-1200的协议,包括两次握手所发送的命令,读取浮点数,整数,BOOL型变量时的命令,及各模块所需命令
  • 西门子s7Commplc协议

    千次阅读 2018-08-25 16:44:50
    /* packet-s7comm.c * * Author: Thomas Wiens, 2014 (th.wiens@gmx.de) * Description: Wireshark dissector for S7-Communication * * Wireshark - Network traffic analyzer * By Gerald Combs <g.....
  • 介绍了关于基于MODBUSRTU协议西门子S7-300与艾默生DeltaVD的详细说明,提供工业通讯协议的技术资料的下载。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 1,610
精华内容 644
关键字:

s7协议西门子