Configuration and Data Logging: Using a PCU to Translate From Process to SCADA

A process communication unit (PCU) acts as a communication front-end protocol converter for a SCADA system. The purpose is to get an effective connection between the SCADA system and the process. A PCU supports distributed environments, which means it can run physically separate from the SCADA system or on the local application server. Different configurations are available for single and redundant system topology. In this article, we will use a specific example of ABB’s PCU400, handling all the RTU protocol-specific networking, such as polling, interpreting the protocol messages, and forwarding the data to the application server via a LAN.

A PCU is an enhanced powerful communication unit, consisting of 1 to 64 lines (depending on hardware configuration) toward the RTUs. The PCU also has one or two high-speed Ethernet connectors, both of which are connected to the network manager’s LAN. The remote server protocol (RSP) is an RTU-type independent protocol used as a communication protocol between the remote communication server (RCS) application and the PCU400.

 

PCU400 Wireshark Logger

PCU400 captures the logs generated by the protocol driver and stored in Wireshark supported file format (pcap format). The module will not be started automatically, as the user should start this module when he wants to capture the logs generated—later log files can be analyzed using PCU400 Wireshark Logger.

Wireshark is a software that understands the different networking protocols and displays the encapsulation and the fields along with their meanings of different packets specified by different networking protocols. Currently, Wireshark supports DNP3.0, IEC 60870-5-101, and IEC 60870-5-104 protocols. The packet details pane in the Wireshark displays the current packet information of the IEC 60870-5-104 protocol.

 

Figure 1. Telegram trace of X88 (IEC60870-5-104 protocol) received from RTU560.

 

If we look closely at the information in Figure 1, the ASDU stands for Application Service Data Unit, which contains the transmitter value. Frame typeId is M_ME_NC_1 (13) for “measured value, short floating type number”. Information object address (IOA) is used to uniquely identify each item on the device and is transmitted in each ASDU. For example, IOA:10442 and value: 4.3 is process engineering value being transmitted from the RTU using IEC-104, as already highlighted in Figure 2.

The second snapshot given below shows the trace log file after connecting the PCU400 CAG server, containing the H20 protocol handler specific to the RP570 protocol telegram trace like analog value message (AVM) [Block=065, Value=1136]. The block (065) means the analog value could be AC generator current or voltage, and the “Value” field is the raw value (1136) coming from the AI card after analog to digital conversion. After conversion from RP570 protocol to RSP, the same telegram is presented as [Block=65, Value=18176]. 

 

Figure 2. Log file captured the H20 (RP570 protocol) telegram received from RTU.

 

Below, we will explain the hardware and software components for a better understanding of the whole PCU400 functionality as a front-end converter in order to understand how PCU400 internal processes are involved to convert process data from one protocol to another and then forward it to the master stations like the SCADA system.

 

Supported Protocols Towards RTUs and Master Station

PCU400 supports multiple protocols from different vendors like ABB, Siemens, and OPC industry standards. Inside the PCU400 system, a software bus called RSP is used to transport data to and from different master stations and RTUs. The few commonly known protocols are shown below:

 

Protocols	PCU400 ID	Vendor
IEC60870-5-101	X89	Ind. Standard
IEC60870-5-104	X88	Ind. Standard
ADLP180	H20	ASEA
Modbus Serial/IP	X30/X31
RP570/RP571	H20	ABB
Sinaut ST1	X29	Siemens
DNP 3.0 IP	X85

The PCU400 can be used as a communication front-end system for ABB Network Manager System and also  supports communication with RTUs using different protocols. PCU400 supports combined communication gateway and HMI functionality for use in substation automation applications. 

One PCU400 can communicate with more than one RTU using different protocols. In case the RTU does not support redundant communication lines, the PCU400 can communicate with one or more master stations. Even if the RTUs themselves do not support multiple master stations, data from the RTU(s) connected to PCU400 can be connected to more than one master station. Another useful application of PCU 400 is that it can make connections of new RTU to old master systems, as well as connect old RTUs to new master systems. 

 

PCU400 Hardware and Software 

The PCU400 software runs on a standard PC running the Microsoft Windows operating system and supports a web server. The local PCU application is only available for the protocol IEC 60870-5-104 and does not require any special hardware, therefore, it runs on the same hardware as the network manager SCADA system. 

The hardware of PCU400 is reminiscent of any typical PC, including a CPU, RAM, hard disk, optional removable disk drives, and network adapters (including RS-232).

Like hardware, different software components in the PCU400 system are DCU, SUP, CAG, CLK, and TRP. These are actually processes (programs) that run in each PCU400 computer, as shown in Figure 3.

 

Figure 3. Executable software components in PCU400.

 

Data Communication Unit (DCU)

A main component for the protocol handlers. The protocol handler is a software module serving a physical or logical communication line with a defined protocol.

 

XLD Module 

Handles various protocols which are run as separate executable processes in the PCU400 computer, like x88 and x89 for IEC60870-5-104 and IEC60870-5-101 respectively.

 

Microsoft Windows 

PCU400 uses services offered by the Windows operating system and accesses these through the Win32 application program interface.

 

Communication Port Drivers

Drivers for different physical communication ports on the computer, including COM, USB, TCP/IP, and other ports as applicable.

 

Supervisor (SUP)

Supervises other processes in the PCU400 system. If any critical error is detected, the supervisor may initiate a computer reboot.

 

Control Agent (CAG) 

Provides control, logging, and diagnostic facilities for the PCU400 system.

 

Clock Controller (CLK) 

Synchronizes the PCU400 clock from an external source and provides a high-accuracy clock for all PCU400 components by using the network time protocol (NTP). The PCU400 clock (CLK) is not the same clock as the computer/operating system clock. 

 

Trap List Handler (TRP) 

Forwards error messages from the other components in the PCU400 system to disk files on the hard disk.

 

PCU400 Logger 

Captures the logs generated by the protocol driver and stored in Wireshark supported file format (pcap format). 

 

Web Server 

Provides HMI functionality for accessing PCU400 using a thin client (web browser). Status information for all communication lines, RTUs, and process objects are available through the web interface. When the simulation mode is enabled, PCU400 will stop communicating with the process.

 

Internal PCU400 Architecture and Supported Protocols

The concept presented in Figure 4 describes a software bus called RSP, which is used to transport data to or from the different master stations and RTUs. Hnn and Xnn (where nn represents numbers from 01 to 99) are called protocol handlers with IDs like H20 (ADLP180/RP570), H40 (RSP),  X88 (IEC60870-5-104), and X89 (IEC60870-5-101), as seen in Figure 4.

 

Figure 4. Internal architecture of protocol handling in PCU400.

 

The letter H in the protocol handler ID indicates high-level driver (HLD), whereas X stands for eXternal high-level driver (XLD). The role of a HLD or XLD is to translate the external protocol to or from the RSP protocol used internally on the PCU400 software bus. The difference between a HLD and an XLD is that a HLD runs as an internal task in the PCU400 main process, while XLD runs as a separate Windows process (executable). The low-level drivers (LLDs) handle access to PCU400 physical ports. Examples of physical ports are COM (serial) and network ports like in Figure 4, showing L42 and L46, also called LLD ID. 

The following main protocols are available for master stations like Network Manager, Micro SCADA, etc.

 

Protocols	Protocol ID in PCU400
ADLP/RP570 ABB	H13
DNP 3.0	E32
EC60870-5-101  IEC60870-5-104 Industry Standard	X37
RSP  ABB	H40
Sinaut ST1  Siemens	H38

How to Configure the Communication Protocol per Line

After understanding the hardware and software components of PCU400, let's discover how to set up the protocol and related tasks in configuration files. We will discuss the scenario shown in Figure 5, where one RTU (collector type RTU400 ) is working on the RP570 protocol, and another device, RTU560, is communicating over the IEC-104 protocol to ABB Network Manager.

 

 

Figure 5. The line parameters and protocol handler modules hierarchy.

 

RTU/protocol#1: RTU400 communicating with PCU400 using the RP570 protocol.

RTU/protocol #2: RTU560 communicating with PCU400 using the IEC60870-5-101.

 

The following files are important from a configurations point of view:

 

LU_00.1INI

The file LU_001.INI, configured for RTU, contains the parameters for the protocol handler called HLD20, specific to RP570 protocol at RSP line number 1 (RSP lines 1-128). The parameters specified in this file will become the active settings. The parameters include:

 

[line]

lldport = 21 

lldtype = 42

lldbaud = 1200

 

In this example, the lldport is the port number i.e. COM21 at 1200 baud for the RSP line number 1. The parameter lldtype 42 is used with the RCM module.

 

LU_016.INI

The second file LU_016.INI is being set up for the protocol handler X88 dealing the IEC60870-5-104 at RSP line number 16 for the RTU-560. The file has the following entries:

 

[line]

LldType = 46

LldPort = 2404

 

L#46 describes the TCP/IP socket client, and  L46 connects to a specific TCP port which is 2404 in this case.

 

LineUnit.ini

The next important file is LineUnit.ini, which contains the definition of RSP line numbers and the communication protocol for each line. The template file usually defines all tasks with tasktype = 20 for RP570 or tasktype=88 for IEC-104 and the task_extid parameter equals the desired RSP line number.

 

[DCU_TASK_003]

task_type = 40 ; H40 RSP router  for the ABB NETWORK MANAGER 

task_extid = 0
 

[DCU_TASK_004]

task_type = 40 ; H40 RSP router  for the ABB NETWORK MANAGER

task_extid = 0

 

[DCU_TASK_005]

task_type = 20 ;RP570 / ADLP180 RTU master

task_extid = 1 ; RSP line no 1 for RTU400

 

[DCU_TASK_016]

task_type = 88 ;IEC60870-5-104 RTU Master

task_extid= 16 ; RSP line no 16 for RTU560

 

Task_003.ini & Task_004.ini

Another two files named as Task_003.ini and Task_004.ini are used for HLD40 at RSP line 0 and configured for ABB Network Manager TCP/IP socket connection #1 and connection #2

 

Task_003.ini 

lldport  = 6661 

LLDTYPE = 49 ; 

encryption = 2

principal = "[email protected]"

 

Task_004.ini 

lldport=6662

LLDTYPE = 49 ; 

encryption = 2

principal = "[email protected]"

 

Kerberos is currently supported for RSP communication with Network Manager (H40) using the L49 LLD. The encryption attribute “2” for authentication and encryption. The principal default value is "nms@domainname". The domain name should typically include the active directory server name. 

 

Translating Protocol Messages

The PCU400 can handle all the known industrial protocols like DNP 3.0, ADLP180, IEC104 and 101, etc., and can translate the multiple vendors’ protocol messages and forward them to the master station.