Dnpv30harris.docx
- 文档编号:15296879
- 上传时间:2023-07-03
- 格式:DOCX
- 页数:74
- 大小:50.90KB
Dnpv30harris.docx
《Dnpv30harris.docx》由会员分享,可在线阅读,更多相关《Dnpv30harris.docx(74页珍藏版)》请在冰点文库上搜索。
Dnpv30harris
第一章报文格式
本节定义应用层报文(APDU)的格式。
APDU这个词和分段(FRAFGMENT)是可以互换的。
在本规范说明书内主站被定义为发送请求报文的站,而外站则为从属设备,被请求回送报文的RTU或智能终端(IED)是事先规定了的。
在DNP内,只有被指定的主站能够发送应用层的请求报文而外站则只能发送应用层的响应报文。
图2-1示出在一个主站和外站之间应用层报文的顺序。
如图所示,主站将“应用层请求”发送给外站;外站回送“应用层响应”。
外站可以决定用“应用层非请求的响应”自发地发送数据。
主站外站
发请求收到请求并处理
可选的确认
接收响应发响应
可选的确认
重要变化被检出时
接收响应发非请求的响应
可选的确认
图2-1报文顺序
主站对一个外站必须在完成一个请求/响应回合之后才能对此外站发送其它的请求。
在请求的回合正在进行之中,主站有可能收到非请求的响应。
至于外站,也必须在完成一个请求/响应的回合之后,才能接受任何其它的请求或发送非请求的响应。
非请求的响应只能在请求/响应回合之前或之后发送,而不是在进行之时.一个外站若正处于非请求回合之中(即正在等待确认),它可以有条件地自主站接受一个请求令(详情,见3.3节――主站请求与非请求响应的冲突)。
此外,每个响应或请求都能包含1个或更多的单个分段。
然而每个分段都应是可领悟的(可解析的),因而是可执行的(因为功能码是属于每个分段的)。
对于报文存储能力有限的设备,建议应只送单个分段的请求报文而所期望的响应(它是全部分段的发送)则多于一个分段,这样是为了保证那些设备可以处理一个请求并集结起来,然而,更重要的是在接收下一个请求之前发送一个响应。
否则,多分段的报文将要多分段的响应,这种响应所要求的报文存储可能大于设备可用的容量。
2.1应用请求的格式
应用请求的报文格式示于图2-2。
APDU由一个包含报文控制信息的APCI数据块和包
含要由接收站处理的信息的`ASDU所组成。
在一个应用请求报文中,APCI常被称之为请求的报头(REQUESTHEADER)。
在DNP中,ASDU是可选用的,并且当报文的意义不能全部在请求报头中传递时才用得上它。
请求报头所包含的信息是如何组装一个多分段报文的信息以及关于报文目的的信息。
请求报头出现与所有应用层请求的APDUS中,如果请求报头隐含了请求所要求实现的全部信息,则ASDU就不存在了。
每个ASDU包含一个或多个数据单元的标志符(DUI)或对象标题和任选的与之相伴的信息对象(IO)或数据段。
对象标题可以规定为0或多于接收站所回送的多于报文内报头后所跟随的。
DUIIO┅┅IODUIIO
REQUESTHEADEROBJECTHEADERDATAOBJECTHEADERDATA
请求报头对象标题数据
APCIASDU
图2-2应用请求的格式
请求报头:
它标识报文的目的并且由APCI(应用规约控制信息)所组成
对象标题:
它标识后随数据对象
数据:
在对象标题内所指定类型的数据对象
2.2应用响应的格式
外站对(应用层的请求)APDU之响应或发自外站的非请求响应所具有的格式如图2-3。
此格式与请求等同。
在应用响应报文中,APDI常被称之为响应的报头(RESPONSEHEADER)。
响应报头包含了与请求报头同样的信息,又加上一个包含外站内部信息的附加字段。
响应报头永远是应用响应的一个部分。
响应的ASDU具有与请求报文相同的格式,但又有显著的例外(在第三章内说明)。
DUIIO┅┅┅┅IODUIIO
RESPONSEHEADEROBJECTHEADERDATAOBJECTHEADERDATA
响应报头对象标题
APCIASDU
图2-3应用响应格式
响应报头:
它标识报文的目的并且由APCI(应用规约控制信息)所组成。
对象标题:
它标识后随的数据对象。
数据:
为对象标题内所指定类型的数据对象。
第二章DNP报文字段的定义
本章说明请求与响应的报头(APCIs),它们控制了主站与一个外站之间应用报文的顺序与流向,以及包含DUI或对象标题的ASDU。
报头则用以将多分段(多APDU)的报文组装进应用用户数据(AUD)。
将对象标题用作信息对象(任选于报头之后者)的唯一标识。
3.1应用报头(APPLICATIONHEADER)
3.1.1请求报头(REQUESTHEADER)
请求报头(或APCI)具有两个字段。
每个字段为8位的字节,说明如下:
ApplicationControlFunctionCode
应用控制AC功能码FC
图3.1请求报头
3.1.2响应报头(RESPONSEHEADER)
响应报头有三个字段,说明如下。
ApplicationControlFunctionCodeInternalIndications
ACFCIIN内部信号
图3.2响应报头
3.1.3应用控制
应用控制字段的长度为一个8位字节。
它提供构造多分段应用报文所需的信息。
应用的报文可以被打包成若干分段,每个分段小到足以配适于应用报文的缓存。
对于分段缓存所推荐的规模为2048字节,以便保持与当前DNP设备的兼容性。
每个分段有一个应用报头和适当的对象标题,以至每个分段都可以作为独立的报文去处理,处理过后就可丢弃掉让出地方来给下一个分段。
76543210
FIRFINCONSEQUENCE
图3-3应用控制段
FIR:
此位若置“1”,表示本报文分段是整个应用报文的第一个分段。
FIN:
此位若置“1”,表示本报文分段是整个应用报文的最后一个分段。
CON:
在所收到的报文中,此位若置“1”,表示应用报文的发送方期待接收该分段的一
方在收方的应用报文中给予确认。
在确认报文内用一个应用功能码(0)。
SEQUENCE:
表示分段的号码。
分段号码0至15是为主站的请求和全部外站的响应保留的(不是非经请求的响应)。
分段号码16至31是为外站来的非经请求的响应保留的。
关于非经请求的响应,每个来自或发向同一外站的每个连续的分段也都必需有一个升序的序号(这个号码自15溢出到0)。
注:
一个未经请求的响应是外站发出的一个报文,通常它包含着事件数据,它会自动
发送给主站,主站无需为这个数据而询问外站。
注:
建议外站所报告的任何已变化了的数据在发送时均要求在响应中带有确认。
3.2通常的流控制
主站与外站之间请求与响应的信息流由响应与请求的报头以及应用程序的定时器和参
数控制着。
控制报文流的字段、定时与参数是:
(1)CON位:
此位的“置位/清除”系“启动/停用”对报文确认的响应(即CONFIRM),CONFIRM
响应是对先前的请求或响应报文之确认。
(2)FIR与FIN位。
(3)SEQUEST:
顺序号字段。
这个号码被用以组装多分段的报文以及识别哪一个响应匹
配于哪个特定的请求。
(4)主站与外站应用的响应逾时。
这些逾时规定了一个应用对一个响应必需等待多长时
间,或对CONFIRM响应要等待多长时间方才重发或异常地中断通信的回合。
(5)主站与外站应用的重发计数。
应用可以支持也可以不支持应用层的重发,重发计数
规定,如果响应失败,请求可重发几次,或者收不到CONFIRM响应时可将原响应重
发多少次。
一个外站在开始处理第二个请求之前,必须将前一个请求完全处理好并对它作出响应。
它不能同时处理多个请求。
主站发到外站的全部请求其序号为0至15。
发自外站的非请求的响应其序号则包括在16至31以内。
以下的规则支配着序号是如何工作的:
●序号自15滚到0或31滚到16。
从DNP主站发出的每个连续的请求分段都有一个升
序序号。
至于请求报文的重发则例外。
关于单个分段的请求在重发时其序号是不递
增的。
至于多分段请求的重发,所重发的请求中第一个分段的序号就是方才失败的
请求之最后分段的序号。
●对于单分段的请求其单分段响应具有与请求相同的序号。
●对一个单分段请求的多分段响应,它的第一个分段,具有与请求相同的序号。
至于多分段响应的后续分段,其序号是递增的。
●对于多分段请求的多分段响应,其第一个分段的序号与多分段请求的最后分段之序号相同。
使用这种顺序号码的方案保证外站和主站对通信网络上报文的失落与延迟的各种情况能够对付了。
以下的规则在外站和主站都是要遵守的:
▲当一个响应在逾越时限之后没有被收到,如果系统使用的是应用层重发,则该请求将仍用同一序号重发。
▲如果所收到的两个报文具有相同的序号,通常意谓着报文的响应未被对方站收到。
在这种情况下,就重发响应(不必要重新处理这个报文)。
▲如果所收到的两个CONFIRM响应具有相同的序号,则不理会第二个响应。
以下的几幅图说明了报文传送回合中的几个案例以及如何用序号防止出问题。
在所
例举的例中SEQ是序号以及CON是报文中的请求确认(CONFIRMREQUESTED)位。
在图中时间自左向右前进。
垂直的箭头表示外站与主站间的报文流。
案例之一说明典型的报文传送回合。
主站发送一个请求,外站予以响应以及主站CONFIRM这个响应,以后外站发送非经请求的响应给主站,当外站在发送响应时,它启动一个监视CONFIRM响应的定时器。
如果在收到CONFIRM之前已经逾时,则外站应重发这个响应。
案例之二示出一个与案一相似的情况,所不同者主站的请求即要一个CONFIRM响应又要求一个CONFIRM响应又要求一个常规的响应。
案例一
时间
主站请求CONFIRMCONFIRM
期望响应(SEQ=7)(SEQ=24)
(CON=0)
(SEQ=7)
外站对主站请求非经请求的
的响应响应
(CON=1)(CON=1)
(SEQ=7)(SEQ=24)
案例之二
时间
主站请求CONFIRM
期望确认(SEQ=2)
(CON=1)
(SEQ=2)
外站CONFIRM对主站请求
(SEQ=2)的响应
(CON=1)
(SEQ=2)
图3-4典型报文传送回合的流程图
注:
在图3-4中和以下几个图中,CON位在外站响应中置位。
在某些传送回合中(例如在响应内不含事件数据)CON位可能被清除.在这种情况下,由于通信的原因丢失了数据往往并不严重,外站就只当响应已被传送成功。
案例三说明来自外站的多分段响应。
在连续的分段中,序号是递增的,注意这种的下一个请求采用的序号为4。
案例四,外站的响应未被主站收到,外站等待CONFIRM,当CONFIRM监视定时器逾时时它就重发响应。
案例三
主站请求CONFIRMCONFIRM请求
期望响应(SEQ=2)(SEQ=3)(SEQ=4)
(CON=0)
(SEQ=2)
外站响应响应
FRAG.1FRAG.2
(CON=1)(CON=1)
(SEQ=2)(SEQ=3)
案例之四
时间
主站请求响应CONFIRM
期望响应未收到(SEQ=3)
(CON=0)
(SEQ=3)
响应CONFIRM未收响应
(CON=1)到逾时后,重(CON=1)
(SEQ=3)发响应(SEQ=3)
图3-5多分段的响应与RTU的CONFIRM逾时
从外站这一边,案例5与案例4是相同的。
在案例5中不同于案例4之处是主站CONFIRM了外站的第一个响应。
而外站没有收到此CONFIRM。
当外站重发响应时,主站将重发CONFIRM。
主站将不重新处理第二个响应。
案例6是主站的请求没有被外站收到。
在响应延迟逾时后,主站重发请求。
案例之五:
时间
主站请求CONFIRMCONFIRM
期待响应(SEQ=10)(SEQ=10)
(CON=0)
(SEQ=10)
外站响应未收到CONFIRM响应
(CON=1)RTU逾时重发(CON=1)
(SEQ=10)响应(SEQ=10)
案例之六:
时间
主站请求请求CONFIRM
期待响应响应逾时期待响应(SEQ=5)
(CON=0)重发请求(CON=0)
(SEQ=5)(SEQ=5)
外站请求未响应
被收到(CON=1)
(SEQ=5)
图3-6发生响应逾时的报文传送回合
案例7与案例4相仿。
两者中,外站给主站的响应均未被收到。
在案例4中,外站等待CONFIRM逾时并重发响应。
然而在案例7中,主站先逾时而重发请求。
外站自动停止对CONFIRM的等待并重发其先前的响应。
案例7还说明另一种可能的情况。
主站未收到的那个原始的响应系在通信网络中被延迟了。
主站重发请求,外站回答以及主站以一个CONFIRM结束了该回合的顺序。
于是外站的原始响应又达到了主站。
主站以为第一个CONFIRM没有被外站所收到。
所以它重发CONFIRM。
外站收到后,就不理会这第二个CONFIRM。
案例之8与案例之7相似。
在本案例中,外站的第一个CONFIRM在通信网络上被延迟了。
当这个CONFIRM终于到达主站时,它就被丢弃了。
案例之七:
时间
主站请求响应未被请求CONFIRMCONFIRM
期待响应收到期待响应(SEQ=8)(SEQ=8)
(CON=0)重发(CON=0)
(SEQ=8)请求(SEQ=8)
外站响应响应RTU对第二
(CON=1)(CON=1)个CONFIRM
(SEQ=8)(SEQ=8)忽略不计
案例之八:
时间
主站请求不CONFIRM在请求不主站又收到第一个
期待响应网络内延迟期待响应被延迟了的CONFIRM
(CON=1)主站逾时(CON=1)并丢弃它。
(SEQ=12)重发请求(SEQ=12)
外站CONFIRMCONFIRM
(SEQ=12)(SEQ=12)
图3-7在网络中响应被延迟了的流程图
案例九,外站等待CONFIRM逾时,外站重发非经请求响应。
主站最后收到了两次非经请求的响应。
它对响应不作第二次处理,但仍如同第一次那样作出响应,外站丢弃第二个CONFIRM,这说明这样一种情况,网络延迟虽未丢失报文但会导致逾时重发。
案例之九:
(UNSOL.RESP=非经请求的响应)
时间
主站非请求响应CONFIRM主站收到延迟CONFIRM
由于网络延(SEQ=30)的非请求响应(SEQ=30)
迟而未收到重发CONFIRM
外站非请求CONFIRM非请求RTU丢弃第
的响应等待的响应二个CONFIRM
(CON=1)重发(CON=1)
(SEQ=0)(SEQ=0)
图3-8由于网络延迟重发非请求的响应
3.3主站的请求与非请求响应之冲突
当外站发生了非请求响应时,有一种可能是在外站发送非请求响应的同时,主站也在发
送请求。
当外站期待收到对其非请求响应的CONFIRM时却收到了主站的请求。
主站正期待收到其请求的响应时收到了非请求的响应。
对上述情况以及类似情况的处理取决于主站所发出的请求之类型。
主站永远将立即处理非请求响应,即使主站正在期待先前所发请求之响应时,也要立即处理非请求响应。
如果外站要求确认(即CON位置位)主站就要立即发出对非请求响应之CONFIRM。
通常外站将立即处理请求,即使它正在期待先前所发请求响应之CONFIRM。
除了对系统数据(例如二进制输入数据,事件计数数据等等)的READ请求以外,所有的请求都按此处理。
这种操作模式被称之为立即处理(IMMEDIATE_PROCESSMODE)模式。
另一种办法是外站若正在等待先前非请求响应之CONFIRM时,它就不处理主站来的READ请求,在处理请求之前,将先等待CONFIRM.这种功能性的变异,其目的在于防止数据事件之丢失或重复。
这种操作的模式被称之为PROCES_AFTER_CONFIRM(确认后处理)模式。
3.3.1IMMEDIATE_PROCESS(立即处理)模式
图3-9和图3-10说明当这种的请求与外站非请求响应被同时发送时,且外站处于
IMMEDIATE_PROCESS模式(即所请求的不是一个READ请求)时的功能性。
在案例10中,这种立即响应于非请求的响应。
外站立即处理并对主站的请求作出响应。
注意两个CONFIRM响应自这种发送的次序可以与案例10中所示者相反。
这不会使外站感到困扰的。
案例11说明不要求一个CONFIRM的非请求响应之基本报文流。
案例之十:
时间
主站请求CONFIRMCONFIRM
期待响应(SEQ=7)(SEQ=24)
(CON=0)
(SEQ=7)
外站非请求对主站请求
的响应的响应
(CON=1)(CON=1)
(SEQ=24)(SEQ=7)
案例之十一:
时间
主站请求存储并处理CONFIRM
期待响应非请求的响应(SEQ=2)
(CON=1)
(SEQ=2)
外站非请求CONFIRM对主站请求
的响应(SEQ=2)的响应
(CON=0)(CON=1)
(SEQ=22)(SEQ=2)
图3-9同时的发送,立即处理模式
在案例十二中,非请求响应的CONFIRM正处在多分段响应中对两个分段的CONFIRM之
间。
案例十三说明非请求响应未被主站收到的情况。
外站先对主站的请求作出响应,然后在非请求响应等待CONFIRM的定时器逾时后重发非请求响应。
于是主站再CONFIRM此非请求响应。
注意,有可能第一个非请求响应会迟后到达主站(网络中的延迟),主站不会再处理此响应,但会再次回答,外站将丢弃此回答。
案例之十二:
时间
主站请求期待CONFIRMCONFIRMCONFIRM
响应(SEQ=2)(SEQ=18)(SEQ=3)
(CON=0)
(SEQ=2)
外站非请求响应响应
响应#1分段#2分段
(CON=1)(CON=1)(CON=1)
(SEQ=18)(SEQ=2)(SEQ=3)
案例之十三:
时间
主站请求主站未收到CONFIRMCONFIRM
期待响应非请求响应(SEQ=3)(SEQ=28)
(CON=0)
(SEQ=3)
非请求响应响应RTU对非请求响应非请求响应
(CON=1)(CON=1)的CONFIRM等待逾(CON=1)
(SEQ=28)(SEQ=3)时(SEQ=28)
图3-10同时的发送,立即处理模式
3.3.2PROCESS_AFTER_CONFIRM(确认后处理)模式
当外站收到一个对系统数据的READ请求时,并且先前一个非请求响应也尚未得到CONFIRM时,外站将不处理READ请求,直到非请求响应获得CONFIRM为止。
如果外站立即处理了READ请求,就要承担失落数据或数据重复的危险。
这是因为有可能READ请求所要的数据对象已经在尚未CONFIRM的非请求响应之中了。
案例十四说明READ请求已被收到而外站正在等待CONFIRM之时的情况,外站不处理READ请求,直到收到CONFIRM之后。
案例十五与十四相似,但非请求响应未被CONFIRM。
外站必须重发非请求响应,直到被CONFIEM或者达到了所组态的重发次数极限为止。
如果已达到此极限,则外站将在内部重新缓存此数据于非请求响应,响应任何尚未解决的请求,然后再试送非请求响应。
案例十四:
时间
主站请求对非请求CONFIRM
期待响应响应(SEQ=2)
(CON=0)CONFIRM
(SEQ=3)(SEQ=18)
外站非请求响应RTU等待RTU现在响应
(CON=0)CONFIRM处理主站(CON=1)
(SEQ=18)不处理请求请求.(SEQ=2)
案例十五:
时间
主站请求主站收不到CONFIRMCONFIRM
期待响应非请求响应非请求响应(SEQ=3)
(CON=0)(SEQ=28)
(SEQ=3)
外站非请求响应RTU等待非请求响非请求响应响应
(CON=1)应的CONFIRM逾时(CON=1)(CON=1)
(SEQ=28)重发非请求响应(SEQ=28)(SEQ=3)
图3-11同时发送,PROCESS_AFTER_CONFIRM模式
3.4出错后的恢复
DNP应用层依靠数据链路层作所有报文的发送接收与检错,应用层不负责对通信问题的恢复。
如果一个通信回合的故障被数据链路层报出,应用层应中止应用层的通信回合并向用户报告出错。
此外,主站应用层应指示出全部外站响应内的内部信号值。
用户层负责启动任何一种出错的恢复步骤,用户层特别应利用自任何外站响应发送回来的内部信号(IIN)。
3.5功能码
功能标识着报文的目的.这个字段的长为一个8位字节。
有两组功能码;一个用于请
求,另一个用于响应。
代码功能说明
传输功能码
0确认用于对请求与响应报文分段之确认。
对此报文不要求响应。
1读请外站送所指定的对象;以所请求的对象(可用的对象)作响应。
2写向外站存入指定的对象;以操作的状态作响应。
控制功能码
3选择选择或打开输出点但不置定或产生任何输出作用(控制,设置数值,模
拟输出);以所选控制点的状态作响应。
“操作”功能码被用以激活
这些输出。
4操作对于由“选择”功能所已选定的点设置或产生输出动作;用控制点
的状态作为响应。
5直接操作选择并设置或操作指定的输出,用控制点的状态作响应。
6直接操作选择并设置或操作指定的输出,但不发送响应给请求方。
――无确认
冻结功能码
7立即冻结复制指定的对象于一个冻结缓存,并以操作的状态作响应。
8立即冻结复制指定的对象于一个冻结缓存,不用报文作响应。
――无确认
传输功能码
9冻结与清除复制指定的对象于一个冻结缓存,然后清除对象,用操作的状态作
响应。
10冻结与清除复制指定的对象于一个冻结缓存,然后清除对象,不用报文去响应。
――无确认
11有时间的在指定的时间和时间间隔上,复制指定的对象于一个冻结缓存,用
冻结操作的状态作响应。
12有时间的冻结复制指定的对象于冻结缓存,在指定的时间和时间间隔上,不用报
――无确认文去响应。
应用的控制功能码
13冷再启动实现所要求的复位顺序;以指示时间的时间对象作响应,直到外站
可以工作为止。
14热再启动实现所要求的部分复位顺序;以指示时间的时间对象作响应,直到
外站可以工作为止。
15将数据初始将指定的数据初始化到上电的初始值;以操作的状态作响应。
化到缺省值
16初始化应用使指定的应用程序准备就绪运行;以操作的状态作响应。
程序
17启动应用程序启动指定应用程序运行;以操作的状态作响应。
18停止应用程序停止指定的应用程序;以操作的状态作响应。
代码功能码说明
组态功能码
19保存组态将指定的组态数据保存入非易失的存储器用一个指示时间对象
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- Dnpv30harris
![提示](https://static.bingdoc.com/images/bang_tan.gif)