DNP3 模拟器使用教程

我们之前看过了法国施耐德的Modbus、德国西门子的S7comm，这次就让我们把目光投到美洲，看看加拿大的HARRIS的DNP3有什么特别之处。

一、DNP3协议概述

DNP3全称是Distributed Network Protocol 3，分布式网络协议3，是一种应用于自动化组件之间的通讯协议，常见于电力、水处理等行业。

它比起s7comm大刀阔斧做的协议栈要简单的多，是完全基于TCP/IP的，只是修改了应用层（但比modbus的应用层要复杂得多），在应用层实现了对传输数据的分片、校验、控制等诸多功能。

DNP借助TCP在以太网上运行，使用的端口是20000端口。

SCADA可以使用DNP协议与主站、RTU、及IED进行通讯。

DNP协议标准由IEEE提出，参考了IEC 870-5、以及其他一些IEC协议。主要为了解决SCADA行业中，协议混杂、没有公认标准的问题。

DNP协议有一定的可靠性，这种可靠性可以用来对抗恶劣环境中产生的电磁干扰、元件老化等信号失真现象，但不保证在黑客的攻击下、或者恶意破坏控制系统的情况下的可靠性。

DNP协议提供了对数据的分片、重组、数据校验、链路控制、优先级等一些列的服务，在协议中大量使用了CRC校验来保证数据的准确性。

以下是一些DNP协议的特点：

• DNP3.0规约是一种分布式网络协议，适用于要求高度安全、中等速率和中等吞吐量的数据通信领域。
• DNP3.0规约以IEC870-5标准为基础，该规约非常灵活，满足目前和未来发展的要求，且与硬件结构无关。
• DNP3.0规约采用网络通信方式。
• DNP3.0规约支持点对点、一点多址、多点多址和对等的通信方式。
• DNP3.0规约支持问答式和自动上报数据传输方式。
• DNP3.0规约支持通信冲突碰撞避免/检测方式，能保证数据传输的可靠性。
• DNP3.0规约支持传送带时标的量，尤其有利于配电自动化系统采集分时电度值和分析事故原因。
• 灵活采取适当的扫描方式，DNP3.0规约可以在一定程度上实现实时优先级。

二、DNP3报文格式

DNP3.0规约的文本共分4部分：数据链路层规约，传输功能，应用层规约及数据对象库。

DNP3.0 可以承载在 TCP 链路上。

可以看到，在应用层DNP3分为了几个部分来处理，就像是在应用层是又搭建了一个协议栈一般。下面就让我们细致的探索一下。

数据链路层规约

首先是数据链路层，这个名字听着有点出戏（OSI第二层的链路层一脸懵逼）……它主要是规定了传输的规则，在官方文档上将这部分的数据单元称为LPDU。

数据链路层规约文件规定了DNP3.0版的数据链路层，链路规约数据单元(LPDU)以及数据链路服务和传输规程。
数据链路层采用一种可变帧长格式：FT3。
一个FT3的帧被定义为一个固定长度的报头，随之以可选用的数据块。每个数据块附有一个16位的CRC校验码。固定的报头含有2个字节的起始字，1个字节的长度，1个字节的控制字，1个16位的目的址，1个16位的源地址和1个16位的CRC校验码。

DNP 协议FT3 如下：

注：控制 control 1 字节。

它的组成很简单，主要就是以下几部分：

start bytes，表明数据开始的起始字节，固定为0x0564
length，长度
control，控制字，这是最重要的一个字段，用一个字节来进行标记
- 0，链路重置
- 1，进程重置
- 3，请求发送数据
- 4，直接发送数据
- 9，查询当前链路的状态
- 0，同意
- 1，拒绝
- 11，回应当前链路状态
- 第一位，direction，听着很高端，但其实就是表明发送的方向
- 第二位，primary，表示发送设备是主设备还是从设备
- 第三位，FCB，翻译过来是“帧的计数位”，但实际上不是用来计数而是用来纠错的。如果是response的话则为保留位
- 第四位，FCV，这一位说明FCB是否有效，在上图中为0，就表示FCB未开启。如果是response的话则为DFC，数据链路层是否发生缓冲区溢出
- 后四位，控制方法码，这个码可没有S7comm的功能码那么“变态”，它并不直接指示功能，只是对包进行分类而已，更像是Type，对于主设备来说对于从设备来说
Destination，目标地址，16位
Source，源地址，也是16位
checksum，校验码，DNP3采用的是CRC算法

1、DIR: 方向(DIRECTION)位

DIR=1 表示此帧自A发向B(即主站发出方向)
DIR=0 表示此帧自B发向A(即发向主站方向)

2、PRM: 原发标志位(PRIMARY)

PRM=1 表示此帧来自原发站(通信发起站)
PRM=0 表示此帧来自响应站(通信应答站)

注意:原发站不一定就是主站,外站也可以是原发站。

3、FCB：帧的计数位(FRAME COUNTBIT)

系用以防止对同一个副方站丢失或重复信息帧，每次成功地完成一次发送并确认(SEND-CONFIRM)服务(即由同一个原发站起动，向同一个副方站的发送服务)后该位就翻转一次。

4、FCV：帧计数有效位（frame count valid）,它可使FCB位生效。

FCV=0 表示FCB位无效。
FCV=1 向副方站指示本帧的FCB位状态有效，必须和FCV置位的最近一帧之FCB位状态进行校核

5、DFC 数据流控制位

防止从站的数据溢出,如果主站送入的数据导致从站数据溢出,则相应消息中包含这个标示位,需要主站通过查询链路状态进行恢复.

6、功能码

传输层报头数据块

数据链路层结束，接下来又冒出来个TC（Transport control），看这个名字就知道是要仿照OSI的传输层，不过这个比起上面可要简单很多，实现的功能主要就是标注当前的包是第几个包。

这部分定义对于DNP数据链路层充当伪传输层的传输层功能。伪传输层功能专门设计用于在原方站和副方站之间传送超出链路规约数据单元(LPDU)定义长度的信息。

第一位是final，标识是否为最后一个包
第二位是first，标识是否为最后一个包
后六位为seq，表明当前是第几个包

这里可以注意到一个小细节，本来六位标识的话，包的数量为2的6次方，也就是0到63，乍一看好像是一次最多拆分成这么多包，但是因为有first位、final位，只要final位不为1，那就可以一直传啊！事实上也是如此，在真实情况中，传到63后，下一个包会从0再继续。所以这个设计可太巧妙了，乍一看是“浪费”了两位，实际上反倒是彻底解除了位数的限制。

其中：传输层报头——传输控制字，1个字节；数据块——用户数据，1～249个字节。

FIN 表示是否是最后一帧

FIN=0 非最后一帧
FIN=1 最后一帧

FIR 表示构成报文的第一帧

FIR=0 非第一帧
FIR=1 第一帧

应用规约

接下来到了DNP3的应用层的应用层，别觉得很怪，人家就是这么起的名字……

这部分定义了应用层报文(APDU)的格式。这里，主站被定义为发送请求报文的站，而外站则为从属设备。被请求回送报文的RTU或智能终端(IEDs)是事先规定了的。在DNP内，只有被指定的主站能够发送应用层的请求报文，而外站则只能发送应用层的响应报文。

应用报文格式

请求(响应)报头——标识报文的目的，包含应用规约控制信息(APCI)；对象标题——标识后随的数据对象；数据——在对象标题内的指定类型的数据对象。

应用报文报头字段的定义

请求报头分应用控制、功能码两个字段。每个字段为8位的字节；响应报头分应用控制、功能码、内部信号字3个字段。每个字段也为8位的字节。

请求包头

响应包头

APCI

字段含义：

FIR：此位若置“1”，表示本报文分段是整个应用报文的第一个分段。

FIN：此位若置“1”，表示本报文分段是整个应用报文的最后一个分段。

CON：此位若置“1”，表示应用报文的发送方期待接收该分段的一方在收方的应用报文中给予确认接受方予以确认，且在确认报文内用一个应用功能码(0)。

SEQUENCE：表示分段的号码。

分段号码0至15是为主站的请求和全部外站的响应保留的(不是主动上报的响应)。分段号码16至31是为外站来的主动上报的响应保留的。关于主动上报的响应，每个来自或发向同一外站的每个连续的分段也都必需有一个升序的序号(这个号码自15溢出到0)。

主站与外站应用的响应逾时。这些逾时规定了一个应用对一个响应必需等待多长时间，或对CONFIRM响应要等待多长时间方才重发或异常地中断通信的回合。

主站与外站应用的重发计数。应用可以支持也可以不支持应用层的重发，重发计数规定，如果响应失败，请求可重发几次，或者收不到CONFIRM响应时可将原响应重发多少次。

一个外站在开始处理第二个请求之前,必须将前一个请求完全处理好并对它作出响应。它不能同时处理多个请求。

主站发到外站的全部请求其序号为0至15。发自外站的非请求的响应其序号则包括在16至31以内。

注：一个未经请求的响应是外站发出的一个报文，通常它包含着事件数据，它会自动发送给主站，主站无需为这个数据而询问外站。

注：建议外站所报告的任何已变化了的数据在发送时均要求在响应中带有确认。

应用层报文主要有以下几部分组成：

control 控制字，按位分为以下：
- 第一位，first，表明是否为第一个
- 第二位，final，表明是否为最后一个
- 第三位，confirm，表明是否需要回复，图中即表示不需要回复
- 第四位，unsolicited，表明是否为主动提出的
- 后四位，seq，为队列号，这里的设计和上面传输层的类似，同样可以支持大于2的四次方的包的数量
function code，最最最最重要的字段，指明功能，图中为0x01，即读取数据，0x2就是写数据，这里不再详细说明，在具体的流量分析中我们再来细看。
read request data object，即要读的数据对象，这里用了qualifier用来限制要读取的对象是什么，个人觉得这里说是数据对象倒不如说是对数据对象的限制。这里wireshark的解析同样有点问题，应该是object、qualifier、range各为一个字段，但wireshark把他们都套进去了，我们还是按分开的来分析。object，即对象，它主要有两部分组成：这里给大家一份可以查询的表格，有需要时查表即可。

Obj，即图中的0x3c，这里是数据的基本类型，比如离散还是模拟

var，即图中的0x02，进一步说明数据的类型，比如是模拟的话，那你是32位还是64位

到这就可以完整的说明数据的类型了，接下来就是限定词，给出了一系列的限制。

第一位，保留，wireshark同样没有给出解析信息

三位，限定码，这个不太好理解，简单点说是表明一个数据对象的索引的字节数

后四位，range，也就是指定的范围的意思，图中6即为读取所需类型的全部数据。往后就是最后的对象了，这个包中并没有，之后会看到。

到这里我们就把DNP3的细节过了一遍，可以看到，DNP3在自己的应用层又搭建一个简易的协议栈用来传输数据，让他有了自己的数据检测、数据分段功能，虽然有很多巧妙的设计带来了传输的帮助，但是其略显繁琐的设计必定要也会导致性能的下降，同时我们也可以看到，它在安全性方面，实在是没什么保障。

对象标题

报文的对象标题制定包含在报文中的数据对象或是被用来响应此报文的数据对象。
应用报文中，对象、限定词、变程的灵活使用，可以表示多种数据类型和数据表示格式，满足用户的不同需要，这也是DNP3.0规约的一大优点。

功能码

file-read

最重要的参数显然就是object了，这里指定了一堆东西，实际上咱们大部分都可以不管了，注意file control mode为read，也就是读，而文件的最大块的size为1024，最后的filename是重点，也就是说主设备发送了一个请求，想要打开testfile.txt文件

从设备回复：“ok，最后的块为第一个块，文件的数据为XXXX”，这里从设备帮我们确定了文件的块数，并将数据返回给我们，数据即为：This is a test file。

从设备：“ok，已关闭”。

到此读文件的过程完毕，可以看到虽然看上去很繁琐，但整体就是简单的“对话”，比起s7comm来说相当容易分析了。write的过程类似，我们就只看write包吧。

file-list-directory

总体流量包很清晰，基本和read file一样，都是打开文件、读文件、关闭文件三部曲，但中间穿插了一些奇奇怪怪的东西，实际上就是DNP3对数据的分段处理，让我们具体看看：

主设备：“我想打开name为.的文件”，有Linux基础的同学应该都知道这个name就是文件夹。

从设备：“有点多。。。你等等”。

由于目录的所包含的内容过多，所以并不能一次传输完成，所以这时就要借助传输层的机制来实现分段了。

我们上面说过，传输层通过控制字对每一段进行划分，第一个包即为01XXXXXX。

第二个包为00xxxxxx+1，如此就是实现了分段，而最后一个包变为10xxxxxx，那么主设备也知道了，哦，数据传输完了。

freeze

其实这样的流量包特别特别简单，但是主要是想提一下freeze这个操作的含义，request如下。

可以看到没什么特别的地方，还是简单的指定了数据对象而已，再看看response就要复杂得多。

里面有一堆参数，我们先不着急看，先搞明白什么是freeze

freeze翻译成中文有冻结的意思，具体的操作是将指定的数据对象放到一个缓冲区（称其为冻结缓冲区）中，但根据他的功能，我觉得叫做shotsnap或许更为合适，它有以下几种类型：

immediate Freeze，0x7，冻结，需要从设备给予回应
immediate Freeze no ack，0x8，冻结，不需要回应
Freeze&Clear ，0x9，冻结，删除原来的数据（这才是真正的冻结吧，打入冷宫），需要从设备回应
Freeze&Clear no ack，0x10，同上，但无需回应
Freeze with Time，0x11，指定时间冻结

我们这里用的显然是0x7的，所以不会对原来的数据造成损失，可以看到回复包中一堆的参数，表明的是从设备的“状态”问题，包括像是设备是否重启、设备是否有问题、时间同步等等，这里就不在一一说明了。

full-exchange

下面来看看这个流量包，开头是TCP的三次握手。

第一个DNP就是个让人懵圈的包，从下面很容易看出来1为主设备，130为从设备，怎么上来130就response了呢？其实这是一种特殊情况，我们可以打开包来具体。

我们发现它自发的向主设备发送了一系列的状态信息，而在这之中只有1位是1，重启。那我们可以推测，设备应该是刚刚经历了一次重启，所以它在与主设备重新获得联系后赶紧发送了当前的状态，虽然违背了request-response的规则，但是也不无道理，毕竟主设备在从设备重启后的第一时间就需要知道从设备的相关信息。那我们同样也可以猜测，这个function code很有可能就是从设备在特殊情况下自发传输某些数据。再结合官方文档，我们就可以真正理解这个function，确实是自发上送数据。

接着就是正常的请求包了。

function code为0x15，其实恰好上面，是禁止自发上送某些信息，这个也很好理解，毕竟从设备也不可能说是把数据都自主上传吧，主设备肯定要做一些限制，所以这里就开始对class1 class2 class3进行限制，不允许对这些进行自发的上送。

从设备对该function进行了标准的response，接着主设备又发送了confirm表示确认（该function也是一种特殊情况，不需要从设备进行回复），接下是一个write的function。

write是看明白了，写的是0也看明白了，但是他写了个啥？intenal indication？上网一搜，啥也没有；谷歌翻译，内部指示，一脸懵逼。

实际上这可不是什么内部指示，只不过是wireshark给的一个名词而已，我们仔细向上翻，其实是能在response里找到的，就是我们之前说得很简单的“状态”，wireshark给的这个名字让我们产生了误解而已。

所以write就是在改写从设备的“状态”信息，看看response有什么变化。

这次全都是0了，可以看到算是恢复了初始状态。

接着进行read操作，读取了相应的信息。最后使用0x15的相反功能，允许自发上送数据，允许从设备对class1、2、3进行上送操作，tcp四次挥手，该包完毕。

lan-time-sync

先看看整体的流量包

大家要是去查现成的资料的话可能会找不到这个Record Current Time的function说明，如果按照它的function code去查的话找到的可能是“未使用”三个大字。

实际上这是因为2017年DNP3进行了一次更新，加入了部分新的function，其中就有这个，实际上就是功能就是记录当前的时间，response倒没什么特别的，接下来是个write操作

它去写的是时间和日期，传送的方式是时间戳，非常简单。

应用报文交互原则：

序号工作规则

1、序号自15滚到0或31滚到16。从DNP主站发出的每个连续的请求分段都有一个升序序号。至于请求报文的重发则例外。关于单个分段的请求在重发时其序号是不递增的。至于多分段请求的重发，所重发的请求中第一个分段的序号就是方才失败的请求之最后分段的序号。

2、对于单分段的请求其单分段响应具有与请求相同的序号。

3、对一个单分段请求的多分段响应，它的第一个分段，具有与请求相同的序号。至于多分段响应的后续分段，其序号是递增的。

4、对于多分段请求的多分段响应，其第一个分段的序号与多分段请求的最后分段之序号相同。

重发处理规则

1、当一个响应在逾越时限之后没有被收到，如果系统使用的是应用层重发，则该请求将仍用同一序号重发。

2、如果所收到的两个报文具有相同的序号，通常意谓着报文的响应未被对方站收到。在这种情况下，就重发响应(不必要重新处理这个报文)。

3、如果所收到的两个CONFIRM响应具有相同的序号，则不理会第二个响应。

主站的请求与非请求响应之冲突

当外站发生了非请求响应时,有一种可能是在外站发送非请求响应的同时,主站也在发送请求。当外站期待收到对其非请求响应的CONFIRM时却收到了主站的请求。主站正期待收到其请求的响应时收到了非请求的响应。

对上述情况以及类似情况的处理取决于主站所发出的请求之类型。

1、立即处理模式(IMMEDIATE PROCESS)

2、确认后处理模式(PROCESS AFTER CONFIRM)

主站永远将立即处理非请求响应，即使主站正在期待先前所发请求之响应时，也要立即处理非请求响应。如果外站要求确认(即CON位置位)主站就要立即发出对非请求响应之CONFIRM。

通常外站将立即处理请求,即使它正在期待先前所发请求响应之CONFIRM。除了对系统数据(例如二进制输入数据，事件计数数据等等)的READ请求以外，所有的请求都按此处理。这种操作模式被称之为立即处理(IMMEDIATE_PROCESS MODE)模式。另一种办法是外站若正在等待先前非请求响应之CONFIRM时，它就不处理主站来的READ请求，在处理请求之前,将先等待CONFIRM.这种功能性的变异，其目的在于防止数据事件之丢失或重复。这种操作的模式被称之为PROCES_AFTER_CONFIRM(确认后处理)模式。

当外站收到一个对系统数据的READ请求时,并且先前一个非请求响应也尚未得到CONFIRM时，外站将不处理READ请求，直到非请求响应获得CONFIRM为止。如果外站立即处理了READ请求，就要承担失落数据或数据重复的危险。这是因为有可能READ请求所要的数据对象已经在尚未CONFIRM的非请求响应之中了。

出错后数据恢复

DNP应用层依靠数据链路层作所有报文的发送接收与检错，应用层不负责对通信问题的恢复。如果一个通信回合的故障被数据链路层报出，应用层应中止应用层的通信回合并向用户报告出错。此外，主站应用层应指示出全部外站响应内的内部信号值。用户层负责启动任何一种出错的恢复步骤，用户层特别应利用自任何外站响应发送回来的内部信号(IIN)。

DNP设备识别方法

DNP3可通过TCP/UDP进行封装，以便在以太网上运行，支持DNP3协议的从设备默认会开放TCP的20000端口用于通信。DNP3协议在设计之初依然是没有考虑到安全、认证等的一些因素，以致后来出现了Secure DNP3（主要加强了认证）。在DNP3目前的应用、传输上个人的观点还是要比MODBUS可靠，DNP3在主站会话上需要约定目的地址、源地址，而从设备收到后需要验证目标地址，然后再进行处理，如果目的地址不相同则会根据在协议栈实现的处理上来决定是否不响应和关闭连接，或者返回异常功能报文等。想要精准识别运行在tcp的20000端口的服务是否为DNP3，可以使用DNP链路层协议(协议格式如下图)。

将其封装成需要发送的识别报文，这样便可以枚举出想要通信设备的目的地址，又能准确判断该端口运行有DNP3服务，并且报文构造相对简单。

在协议的控制字方面可以使用协议中的9号功能码请求链路状态，相应的设备如果响应回复一般则会返回11，如下图为控制字格式：

如下图为功能码取值：

需要注意的是正因为设备对非法连接(目的地址)请求的处理方式不一样，在应用到实际的全网扫描中不可能全部尝试到所有的地址(目的地址长2个字节，范围在0-65535)，另外还需要实现协议的CRC的算法。这样从实现到扫描整体的代价都会比较大。

那么我们可以看一下Shodan在DNP协议的识别这块是如何做的，如下图是在公网监听了tcp/20000端口后收到的包。

我们可以看到Shodan在针对DNP3协议在公网扫描识别上，也还是采用了枚举的方式，并且看似有些暴力，再根据下图你会发现Shodan总共尝试了101个地址。

故你会在Shodan检索port:20000时发现设备的源地址（Source address/对应主站的目的地址）都没有超过100。

那我们实现针对DNP的扫描插件时也可参照Shodan的做法，在组包时定义一段范围的地址来进行批量探测，并且探测1-100的目的地址组包大小有1010个字节，在批量扫描探测时还要受网络收发延时影响。所以Shodan目前能检索到的数据也不足1000，现在看来貌似也没有相对好的做法。

根据Shodan的套路这个扫描规则还是很好制定的，我们可以定义一个探测包，再定义判断返回报文的长度、包头部是否为DNP的协议头0x05，0x64，然后解析源、目的地址、功能码，非常简单就能实现一个与Shodan一模一样的针对DNP3协议扫描的基于NMAP的NSE插件。

三、DNP3模拟器使用

下载DNP3模拟器，请移步到：

DNP3工业协议模拟器-网络基础文档类资源-CSDN下载

DNP3模拟器支持：

多服务器模拟
支持串口、TCP IP 通信
3 级合规性
支持文件传输（文件读取，文件写入），目录命令。
支持主动响应、八进制字符串、虚拟终端输出
支持“Select-Before-Operate”和“Direct-Execute”命令执行模式
支持二进制输出（CROB）和模拟输出命令
支持，冻结计数器输入，冻结模拟输入类型，
设备属性支持
请求和主动报告
生成模拟点变化
生成二进制点变化（单/1位和双/2位）
生成计数器“计数”
进程计数器冻结操作
时钟同步

参考网址：

GitHub - FreyrSCADA/DNP3: DNP3 Protocol - Outstation Server Simulator, Client Master Simulator, Source Code for Windows and Linux (ARM) -C, C++, C# .NET Programming - Complete Implementation including file transfer

添加和删除客户端

我们可以在模拟器中添加多达50个客户端节点。每个客户端节点都将独立工作。我们还可以删除客户端。

模拟器窗口显示状态和连接的通信通道

TCP–IP地址、端口号。

UDP–IP地址、端口号

Serial – Com 端口号

Com端口号

客户端配置

客户端协议配置窗口显示实际的协议设置。

配置参数如下：

1）通信模式-通信模式串行/TCP\u IP/UDP

2）串行端口号-串行COM端口号

3）波特率-串行位/波特率

4）字长-序列字长

5）停止位-串行停止位

6）奇偶校验-串行奇偶校验

7）流量控制-流量控制

8）消息间延迟-消息发送和接收之间的时间仅适用于发送消息后

9）传输延迟-发送前的传输延迟

10）传输后延迟-发送后延迟

11）传输字符间延迟-发送期间字符之间的延迟

12）传输字符超时-如果未发送字符，则超时

13） Transmit Character Retries-要发送的重试次数

14）传输消息超时-如果未发送整个消息，则消息超时

15）传输消息重试-传输-重试消息以重试整个消息

16）接收前延迟-接收前延迟

17）接收后延迟-接收后延迟

18）接收字符间延迟-接收期间字符之间的延迟

19）接收字符超时-未接收字符时超时

20） Receive Character Retries—接收字符的重试次数

21）接收消息超时-如果未接收到整个消息，则消息超时

22）接收消息重试-接收-消息重试以重试整个消息

23）TCP源IP地址-TCP、客户端、绑定套接字的IP地址

24）TCP端口号-TCP、客户端、绑定套接字的端口

25）UDP源IP地址-UDP、客户端、绑定套接字的IP地址

26）UDP端口号-UDP、客户端、绑定套接字的端口

27）主地址-预期的主/客户端地址范围为0到65519

28）从站/从站地址-从站/从站地址范围0到65519

29）链路层超时-链路层超时（毫秒）（最小1000ms-最大）

30）应用层超时-应用层超时（毫秒）5*Linklayer超时

31）轮询间隔-1,2,3类-123类轮询间隔（毫秒）（最小1000ms-至2147483000ms）

32）集成轮询间隔-0,1,2,3类-0123类轮询间隔（毫秒）（最小1000ms-至2147483000ms）

33）轮询间隔-0级-0级轮询间隔（毫秒）（最小1000ms-至2147483000ms

34）轮询间隔-1级-1级轮询间隔（毫秒）（最小1000ms-至2147483000ms

35）轮询间隔-2级-2级轮询间隔（毫秒）（最小1000ms-至2147483000ms

36）轮询间隔-3级-3级3轮询间隔（毫秒）（最小1000ms-至2147483000ms

37）启用UTC时间-启用UTC时间/本地时间

38）未经请求-启动时启用响应-启用客户端在statup上发送未经请求的消息

39）启用冻结模拟输入支持-假堆栈不会为冻结模拟输入创建点

40）启用文件传输-启用文件传输支持

41）文件操作超时-文件读取/写入超时（毫秒），最小10000毫秒

42）即使时间戳更改，也调用Update Callback-如果为true，时间戳更改也会创建updatecallback

43）命令超时-命令超时（毫秒），最小3000ms

客户端数据配置

客户端数据配置窗口显示点列表配置。

DNP组可供选择

二进制输入-二进制输入（DNP3Group 1）

双输入-双位二进制输入（DNP3Group 3）

二进制输出-二进制输出（DNP3Group 10）

计数器输入-计数器输入（DNP3Group 20）

模拟输入-模拟输入（DNP3Group 30）

模拟输出-模拟输出（DNP3Group 40）

八进制字符串-八进制字符串（DNP3Group 110）

VIRTUAL_TERMINAL_输出-虚拟端子串（DNP3Group 112）

车站命令

在Data object（数据对象）窗口的plain space（普通空间）中，只需右键单击，station command（车站命令）窗口将打开，

命令窗口还将显示结果，即发送命令成功或失败。

Point命令

单个命令具有点命令。

只需右键单击数据对象窗口中的命令点，

流量窗口

在此我们可以监控DNP、TCP、UDP、串行通信的流量。

这样我们可以节省流量，清除交通堵塞

日志窗口

用于内部参考的日志窗口

在日志中，我们可以监视客户机和主机之间的命令交换，并且可以选择保存日志并清除日志。

其他DNP3模拟器介绍

如下工具可以快速帮你熟悉、调试、仿真、测试DNP3协议：

opendnp3

opendnp3是automatak开源的基于IEEE-1815 (DNP3)的开源协议栈。

Aegis™

Aegis™是automatak开源的一个针对工控协议进行模糊测试(Fuzz)的框架，其中包含对DNP3协议模糊测试的模块，官方的Project Robus项目曾经发布过多个应用在DNP3协议健壮性上的漏洞，官方在发布MODBUS模块后貌似没有再继续开源了。

Protocol Test Harness

Protocol Test Harness是Triangle MicroWorks公司开发的一款协议仿真、调试软件，软件可以仿真多种工控协议包括DNP3，可以方便你完成调试、仿真。