1　概述
　　配电自动化系统的线路终端单元(FTU，Feeder Terminal Unit)数量多、安装分散、通信数据量少。在过去输电网调度自动化系统中使用的循环(CDT)规约不适合于配电自动化FTU与控制主站间的通信，因为它要求有上下行两个通道，投资大，并且由于每一点需传输的数据量少，通道利用率很低。配电自动化控制主站与FTU之间一般采用点对多点的通信通道配置方式，当子站较多时，使用查询式规约(如SC1801)采取问答方式把所有的FTU访问一遍，所用时间往往很长，会影响重要的变化信息(如开关变位、故障信息等)及时上传。因此，比较合适的方式是FTU能够主动向控制主站报告遥信量变位及故障信息等，主站只是间隔一定的时间(如半个小时)访问各FTU，读取一些静态变量(如模拟量、开关状态量等)以及确认FTU是否工作正常。
　　我国已把IEC 870.5-101列为远动通信标准规约。然而，尽管IEC 870.5-101能支持子站自发响应上报变化信息，但不能用于点对多点通道配置方式，它直接作为配电自动化系统FTU与控制主站的通信规约还不是很理想的。DNP 3.0通信规约支持自发响应方式，是一种比较适合于配电自动化RTU/FTU与主站间的通信规约。供电部门在实施配电自动化工程时，可直接使用DNP 3.0，亦可借用DNP 3.0自发响应处理机理修改IEC 870.5-101，使其适应配电自动化RTU/FTU通信需要。本文简单介绍了DNP 3.0的构成，重点介绍其消息碰撞问题及处理方式，供广大配电自动化工作者参考。

2　DNP 3.0规约简介
　　DNP 3.0(Distributed Network Protocol Version 3.0)最初由美国HARRIS公司推出，已被IEEE推荐为RTU/FTU与主站间的通信规约。DNP3.0在北美地区应用比较多，我国的香港及大陆一些开展配电自动化工作的供电部门也有选择DNP 3.0的。现在世界上有专门的DNP用户组织，负责规约的管理。
　　DNP 3.0是遵循ISO/OSI七层参考模型的开放式远动通信规约。与IEC 870.5-101比较，DNP 3.0也规定了类似的物理层、链路层及应用层的内容。由于IEC 870.5-101链路层每一帧中所传送的应用数据不超过255个字节，为了方便应用层传输大容量数据块，DNP 3.0增加了一个传输层，将超过255个字节的应用数据分成若干个不超过255字节的数据子模块，送到链路层传输。DNP 3.0与IEC 870.5-101的另一个重要区别是，能够在多种通信网络拓扑结构下支持自发响应(unsolicited response)方式。

3　DNP 3.0链路层消息传输碰撞及处理
3.1　消息传输时的碰撞情况
　　SCADA通信网络通常有直接总线和串联总线两种物理拓扑方式。直接总线拓扑方式具有两个物理节点，这两个节点直接相连，通常用于点对点通信；串联总线拓扑方式中多个节点均联接在同一条通信线上，通常用于点对多点通信，其中一个节点是SCADA主站，该节点向其他节点发送/接收信息，其他所有的节点向这个主站节点接收/发送信息。
　　DNP 3.0数据链接有2线半双工及4线全双工两种通信方式。DNP 3.0对这两种方式的处理是不相同的。
　　 在直接总线拓扑方式下，一个主站只与一个RTU通信，若使用4线全双工方式则在线路上不会有任何消息碰撞的机会。但如果使用2线半双工方式，那么当两个装置同时试图传输数据时碰撞问题就产生了。另一种较特别的线路联接方式如图1所示，这是一种利用公共交换网络(PSN，Public Switched Network)拨号通信方式，是典型的2线制，但从RTU到调制解调器是4线制，此时使用全双工方式进行数据链接，拨号调制解调器必须利用RTS和CTS才能解决碰撞问题。

图1　主站与RTU通过调制解调器的直接联接示意图
Fig.1　Point to point dial up connection

　　在串联总线拓扑方式下，主站与多个RTU通信，所以无论是2线制还是4线制都有发生碰撞的可能性。在2线通信的情况下，主站与RTU之间，RTU与RTU之间，在通信时都有可能发生消息碰撞；在4线通信的情况下，主站与RTU之间不会发生消息碰撞，但是当RTU彼此之间通信时还是有消息发生碰撞的可能性。
3.2　DNP 3.0对碰撞问题的处理
3.2.1　半双工通信方式下的碰撞处理
　　在两线半双工方式下，当主站或RTU在线路上有数据传输时，物理层应该能够返回一个数据载波检测指示(DCD，Data Carrier Detection)，表明此时有一个站正在线路上传输数据，禁止其他站使用该线路。反之，当DCD没有作出指示时，表明此时线路空闲，任何一个站都可以使用该线路进行数据传输。由此而产生的问题是：由于DNP3.0数据链接协议不为RTU设置优先级，所以当线路空闲时，若有多个RTU同时要求使用该线路向主站传送消息时，则会产生碰撞问题。这种现象发生后，DNP3.0规定所有RTU均停止消息的发送而等待一个时间延迟，然后再次检测DCD指示。若发现线路仍然是空闲的，则可以发送消息；若发现线路已被其它RTU抢先使用，则继续等待一个时间延迟，直到DCD指示线路空闲。主站利用这个时间延迟来控制线路的使用，并阻止多个RTU同时进行消息传输。
　　对RTU消息发送时间延迟的设定，DNP3.0提供了如下几种配置方案：
　　(1)在点对点配置中，这个时间延迟被设定为主站最小时间(master-min time)。主站最小时间为主站检测DCD所需时间、开始消息传输的时间与系统传播延迟时间之和。
　　(2)在多点配置中，时间延迟的设置有两种方法：
　　1)为每个RTU设置固定的时间延迟(每个RTU的时间延迟各不相同，且均大于主站最小时间)，以此来标识RTU的优先级。重要站的时间延迟较短，优先级较高；非重要站的时间延迟较长，优先级较低。这种方法的优点是重要站的信息能够较快地上传给主站，不足之处是当重要站没有消息传输时，非重要站可能要浪费掉许多时间才能将消息发送出去。
　　2)让每个RTU等待一个随机的时间延迟。该时间延迟大于主站最小时间而小于主站最大时间(master-max time)。主站最大时间的值是系统中联接的RTU数目的函数。在这种方式下，每个站均以同样的方法配置，平均浪费的时间为主站最大时间减去主站最小时间并除以2。如果两个站等待的随机时间恰好相同，则还会发生碰撞(主站最大时间越小，发生这种情况的可能性就越大)。发生这种情况后，相碰撞的两个站只能再去等待一个随机的时间，直到此时间值不同为止。
3.2.2　全双工通信方式下的碰撞处理
　　在4线全双工点对点通信方式下，因为有两个相对独立的通道分别用于接收和发送消息，所以主站和RTU可以在任意时刻传输数据而不存在碰撞的可能性。在这种情况下，主站仍然具有对线路的控制权，只是由于它仅与一个RTU通信，所以不需要去检测DCD和考虑禁止对其他RTU的通信问题。
　　 在4线全双工多点通信方式下，因为4线系统的两个通信通道相对独立，并且通常只能检测接收方向的通信情况，所以碰撞避免问题相对地较为复杂。4线系统对消息的发送和接收是在不同的线路中进行的。主站能够在任意时刻无碰撞地传送消息，但是却不一定能够立即收到数据链接的确认信息，因为此时或许有其他RTU正在使用着主站的接收线路向主站上报信息，或者此时有碰撞发生。由于没有办法判断是否有其他RTU正在使用着主站的接收线路，所以RTU消息碰撞的发生将是没有规律可循的。解决这种碰撞情况的办法是：
　　(1)当有RTU正在使用主站的接收线路时，该RTU利用一个控制回路(例如RS-232的RTS)向其他RTU发一个信号。该信号必须发送到其他所有的RTU中，用于指示主站的接收线路正在被使用；当该RTU发送信息结束后，再利用一个控制回路(例如RS-232的CTS)向其他RTU发一个信号，以指示对主站接收线路的使用已经结束。
　　(2)另一种简单的解决办法是允许RTU发生消息碰撞。在这种情况下，主站仍然能够发送高优先级的消息，但是当某些碰撞情况发生时，这种方法可能会导致因RTU超时而造成的信息丢失。
　　前面介绍过，拨号调制解调器使用4线全双工线路，而拨号线路是典型的2线点对点线路。DCD只能指示两个调制解调器之间通过PSN联接是否成功，而不能说明线路上是否有数据传输。在这种较特别的线路联接方式下，必须利用串行口的RTS和CTS来解决碰撞问题。CTS用于向数据链接指示可以安全地传输数据。在传输每帧数据之前，DNP3.0数据链接需首先声明RTS，并且在传输数据前等待CTS变成高电平。如果DCD变成低电平，则认为数据链接失败并准备重新拨号。

4　DNP3.0应用层消息碰撞及处理
　　DNP3.0规约在应用层的消息处理上也有一种碰撞的情况。这种碰撞情况表现为：主站请求与RTU自发响应同时发生时，主站接收到的不是它所请求的响应，而是RTU的自发响应；RTU接收到的不是主站对自发响应的确认信息，而是主站的请求命令。
　　对主站而言，发生这种碰撞情况后，主站总是立即处理RTU的自发响应，及时地向RTU返回确认信息；对RTU而言，对类似碰撞情况的处理需要视主站发出的请求命令的类型而定。
　　(1)立即处理方式
　　发生上述碰撞情况后，RTU不等待自发响应的确认信息而立即处理主站的请求命令，称这种方式为立即处理方式。DNP3.0对除“读”请求(例如二进制输入数据请求，计数事件数据请求等等)之外的所有请求命令均采用这种处理方式。
　　较特别的一种情况如图2所示。主站接收不到自发响应信息，没有向子站发出确认(CONFIRM)信息，RTU首先响应主站的请求，当自发响应响应确认超时后，RTU重新发送自发响应信息。当然，如果是由于网络的原因而造成超时，那么主站最终还将能够接收到第一次的自发响应信息。此时，主站仍对其作出答复，但RTU则置之不理。

图2　应用层碰撞情况之一
Fig.2　Information collision in application layer,case 1

　　(2)确认后处理方式
　　主站发出的请求命令为“读”请求时，若恰好有自发响应发生，则RTU在收到CONFIRM信息后才开始响应“读”请求，称这种方式为确认后处理方式。如果RTU对“读”请求采用立即处理方式，那么当主站所要“读”的数据恰好已经被包含在这个还没有被确认的自发响应中时，就很可能会引起数据的重复或丢失。而采用确认后处理方式便能有效地处理这种情况。
　　较特别的一种情况如图3所示。主站没有确认自发响应消息，此时RTU将重发自发响应的响应消息，直到接收到主站的确认信息，或者达到了预先配置的重发次数。如果重发次数达到预先配置的重发次数后仍没有收到主站的确认信息，那么RTU在内部把自发响应的响应数据重新放入缓冲区，然后处理主站的请求命令，最后再次重发自发响应响应消息。

图3　应用层碰撞情况之二
Fig.3　Information collision in application layer,case 2

5　结束语
　　目前，我国许多地区正在开展配电自动化系统建设工作，一个地区的配电自动化系统包含许多的现场智能终端装置，采用开放性的标准通信规约能够保证使配电自动化系统主站与现场智能终端装置方便地互联，减少建设投资。在市场竞争激烈、专业化分工越来越细的今天，没有任何一个厂家能够制造生产系统中所有的产品，因此，采用开放性的标准通信规约，能够使所建设的配电自动化系统优选不同厂家的产品，以提高系统性能。
　　DNP 3.0是一种开放性规约，支持子站自发响应上报变化信息方式，比较适合在配电自动化主站与现场RTU/FTU通信中应用。IEC 870.5-101用于点对多点通道配置时，不支持自发响应方式。在实际应用中可参考DNP 3.0自发响应处理方式修改IEC 870.5-101，使其能够满足配电自动化通信的要求。