Understanding and Using DNPDIAG for SCADAPack x70 Diagnostics

This example provides an overview of the DNPDIAG command-line utility available on Schneider Electric SCADAPack x70 devices. This powerful tool allows users to monitor and diagnose DNP3 protocol communications, aiding in troubleshooting and system analysis.

DNPDIAG is a command-line diagnostic tool that displays various aspects of the DNP3 protocol communication occurring on a SCADAPack x70 device. It allows you to filter and focus on specific communication channels, protocol layers, and device addresses, providing valuable insights into data exchange.

How to Access DNPDIAG:

You access DNPDIAG through the command-line interface of your SCADAPack x70 device. This typically involves establishing a connection using a terminal emulator (like PuTTY), a serial connection, or a network connection (like Telnet or SSH, if configured).

For example in RemoteConnect, the SCADAPack 474 serial port is default set to command line.

Also, you can enable Telnet service in RemoteConnnect for the network connection access. Telnet is not a secure protocol since it sends data in cleartext. It is recommended that Telnet be disabled on the device when not in use.

Example Using Telnet and Explanation:

Let's analyze a DNPDIAG session on a SCADAPack x70 device accessed via Telnet. Assume the device has a DNP3 address of 1 and we are monitoring Ethernet port 1 (ETH1).

1. Initial State:

   
   This output shows the current enabled DNP3 diagnostic filters. In this case, several filters are already active, including ETH1, APPL, EVENTS, LINK, NETWORK, TIME, TRANSP, USER, and SECURITY. The legend at the bottom indicates the prefixes used for different layers in the subsequent diagnostic output.

2. Enabling All Applicable Filters:

   The command dnpdiag e *.* attempts to enable all available filters except BYTES, DBASE, and RAW_NET (as per the documentation). The output confirms that the previously enabled filters remain active.

3. Initiating Diagnostic Display:

   The diag command (which might be an alias or another command to view the active DNPDIAG output) starts displaying the real-time DNP3 communication based on the enabled filters.

4. Analyzing the Diagnostic Output:

   18:46:33.280: ***> ETH1  30000*>00001 DNP3 FRAME ADDRESSED TO ME
   
   18:46:33.280: ---> ASSOC     Primary Frame - Unconfirmed User Data
   18:46:33.280:             LEN(20) DIR(1) PRM(1) FCV(0) FCB(0) DEST(1) SRC(30000)
   
   18:46:33.280: ~~~> [30000]     Transport Header
   18:46:33.280:             FIR(1) FIN(1) SEQ# 36
   
   18:46:33.280: ===> [30000]     Application Header, Read Request
   18:46:33.280:             FIR(1) FIN(1) CON(0) UNS(0) SEQ# 13
   
   18:46:33.281: <+++ [30000]     Build DNP3 Message: Read Response
   
   18:46:33.281: <+++ [30000]     Build DNP3 Message: Read Response
   
   18:46:33.281: <+++ [30000]     Build DNP3 Message: Read Response
   
   18:46:33.281: <+++ [30000]     Build DNP3 Message: Read Response
   
   18:46:33.281: <+++ [30000]     Insert request in queue: Read Response
   
   18:46:33.281: <=== [30000]     Application Header, Response
   18:46:33.281:             FIR(1) FIN(1) CON(0) UNS(0) SEQ# 13 IIN(0x0000)
   
   18:46:33.281: <~~~ [30000]     Transport Header
   18:46:33.281:             FIR(1) FIN(1) SEQ# 29
   
   18:46:33.281: <--- ASSOC     Primary Frame - Unconfirmed User Data
   18:46:33.282:             LEN(18) DIR(0) PRM(1) FCV(0) FCB(0) DEST(30000) SRC(1)
   

   • 18:46:33.280: ***> ETH1 30000*>00001 DNP3 FRAME ADDRESSED TO ME: This line indicates a DNP3 frame received (>) on Ethernet port 1 (ETH1). The source DNP3 address is 30000 and the destination address is 00001 (our device). The ***> prefix signifies network layer information.

   • 18:46:33.280: ---> ASSOC Primary Frame - Unconfirmed User Data: This shows the link layer information (--->). It's a primary frame (PRM(1)) containing unconfirmed user data. The length (LEN), direction (DIR=1 for received), frame control bits (FCV, FCB), destination address (DEST(1)), and source address (SRC(30000)) are displayed.

   • 18:46:33.280: ~~~> [30000] Transport Header: This line displays the transport layer header (~~~>). The [30000] likely refers to the source address context. FIR(1) and FIN(1) indicate this is the first and final segment of the transport layer message, and SEQ# 36 is the sequence number.

   • 18:46:33.280: ===> [30000] Application Header, Read Request: This shows the application layer header (===>). It's a read request (Read Request). CON(0) indicates it's not a confirmed request, UNS(0) is unsolicited response, and SEQ# 13 is the application layer sequence number.

   • 18:46:33.281: <+++ [30000] Build DNP3 Message: Read Response: This indicates the user application (<+++) is building a DNP3 read response message. The < indicates a transmit operation.

   • 18:46:33.281: <=== [30000] Application Header, Response: This is the application layer header of the response (<===). It's a response to the read request, with IIN(0x0000) indicating no internal indications bits are set.

   • 18:46:33.281: <~~~ [30000] Transport Header: The transport layer header of the response (<~~~).

   • 18:46:33.281: <--- ASSOC Primary Frame - Unconfirmed User Data: The link layer frame of the response (<---), now being transmitted (DIR(0)). The destination is 30000 and the source is 1.

   The subsequent lines follow a similar pattern, showing further DNP3 requests and responses. The "Binary Input Event" lines indicate asynchronous events being generated by the device.

게시 대상: 슈나이더 일렉트릭 Korea