Realtime Software development system

Communication Protocols

Communication Protocols are the grammars through which computer-based devices communicate with one another, the way they organise and transmit the bits and bytes of electronic on-off (binary) signals, whose patterns encode data.

Simply, a protocol is a set of rules that governs how message containing data and control information are assembled at a source for their transmission across the network and then dissembled when they reach their destination.

The Veesta-Automation system performs those specific functions that it acts like a spider in the control and information web of the field. The data and information exchange with other systems is of a serial nature and by use of dedicated communication protocols. The other systems can be locally situated Intelligent Electronic Devices (IED) or remotely placed control or information management systems. The applied communication protocols vary of nature depending of the make of the other system and the type of information exchange where it is used for. The protocols are manufacturer specific proprietary or a defacto standard used within the industry segment and internationally standardised protocols.

Most often the system connections are of a point-to-point or multi drop nature with a clear master-slave hierarchy. Nowadays peer-to-peer and wide area network (WAN) protocols are becoming available as well. The Veesta-Automation system has its own real time data structures (RTD-elements) with are converted into the structures of the applied protocols. The RTD elements that are updated by the protocol can be used in the same way as other I/O elements (e.g. digital inputs/outputs, analog inputs, read from conventional I/O boards). They can be used for:

• Alarming.
• Display on graphical workstations.
• Input or output for (composed) objects.
• Transfer to other protocols who are linked/subscribed to the same data point

All available protocols can work in parallel and multiple instances of one protocol are supported where each instance can subscribe to its own defined data and command set.

• IEC 60850-5-101 protocol
• IEC 60850-5-103 protocol
• DNP3 Protocol
• Elcom-90 protocol
• TCP/IP and SLIP Protocol
• MODBUS RTU Protocol
• Alstom Courier Protocol
• ABB - RP570/571 Protocol
• ABB - INDACTIC 2033 Protocol
• GI74 Protocol
• TG709/E & TG809 Protocol
• WISP & WISP+ Protocol
• CDC 8890 Type II
• HITACHI Protocol


IEC 60850-5-101 protocol
The IEC 60850-5-101 protocol provides a standardized way to communicate with other systems. IEC 60870-5-101 provides a communication profile for sending basic telecontrol messages between two systems, which uses permanent directly connected data circuits between the systems. The IEC Technical Committee 57 (Working Group 03) have developed a protocol standard for Telecontrol, Teleprotection, and associated telecommunications for electric power systems. The result of this work is IEC 60870-5. Five documents specify the base IEC 60870-5. The documents are:

• IEC 60870-5-1 Transmission Frame Formats
• IEC 60870-5-2 Data Link Transmission Services
• IEC 60870-5-3 General Structure of Application Data
• IEC 60870-5-4 Definition and coding of Information Elements
• IEC 60870-5-5 Basic Application Functions

The IEC Technical Committee 57 has also generated a companion standard IEC 60870-5-101 especially for basic telecontrol tasks. The IEC 60870-5-101 is based of the five documents IEC 60870-5-1 to 5. The IEC 60870-5-101 protocol is a companion standard of the IEC 60870-5 standard, used for basic telecontrol tasks. The 101 Slave protocol for SAS2000 makes SAS2000 behave like a 101 outstation, allowing it to handle data requests and commands from a 101 master station. The protocol uses V24 communication lines, which can be connected directly to the Control Unit or to a communication channel. The implementation can handle redundant communication line configurations to increase the availability of the functional communication connection.

IEC 60850-5-103 protocol
The IEC 60850-5-103 protocol is designed for use with data transmission between IED’s like protection equipment and control systems. The protocol defines application service data units which specify the message layout and contents, and describing the order and situations in which these messages are sent. The communication board running the 103 protocol implementation provides a V24 interface RS232 at physical level and can support up to 10 relays on a single line when using an RS485 bus. The protocol implementation makes it possible to map protocol information elements on RTD elements of Veesta-Automation. The 103 information elements to be mapped may be of the following value types:

• Double Point Information (DPI).
• Measurand with Quality Descriptor (MEA). Linear scaling can be used to convert the MEA value to the correct engineering value.
• Short-Circuit Location (SCL).
A Short Circuit Location is a real value that represents the location as fault reactance related to primary values. It is given in Ohms. An SCL can be scaled by using the linear scaling.
• Single command.
• Double command (DCO).

Note: The set of information elements defined by the 103 specification is supported, but the information elements available for a particular relay depend on the type of relay and should be described in the relay interface documentation. DPI, SCL and MEA information elements can be mapped on input RTD elements. Commands can be mapped on output RTD elements.

DNP3 Protocol
DNP was originally created by Westronic, Inc. (now GE Harris) in 1990. In 1993, the 'DNP 3.0 Basic 4' protocol specification document set was released into the public domain. Ownership of the protocol was given over to the newly formed DNP Users Group in October of that year. Since that time, the protocol has gained worldwide acceptance, including the formation of Users Group Chapters in China, Latin America, and Australia. In January 1995, the DNP Technical Committee was formed to review enhancements and to recommend them for approval to the general Users Group. One of the most important tasks of this body was to publish the 'DNP Subset Definitions' document, which establishes standards for scaled-up or scaled-down implementations of DNP 3.0. DNP 3.0 is an open, intelligent, robust, and efficient modern SCADA protocol. It can

• request and respond with multiple data types in single messages,
• segment messages into multiple frames to ensure excellent error detection and recovery,
• include only changed data in response messages,
• assign priorities to data items and request data items periodically based on their priority,
• respond without request (unsolicited),
• support time synchronization and a standard time format,
• allow multiple masters and peer-to-peer operations, and allow user definable objects including file transfer.

The DNP3 protocol is a protocol based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working group 03 who have been working on an ISO 3 layer “Enhanced Performance Architecture” (EPA) protocol standard for telecontrol applications. It is used to exchange data between RTU’s and remote control points. DNP3 can be used for either Control Center communication as well as communication with protection relays or other Intelligent Electronic Devices.

Elcom-90 protocol
The Elcom-90 protocol provides a standardized way to communicate with Area Control Centres. Elcom-90 in Veesta-Automation implements all functionality needed for a complete responder system. The Elcom-90 subsystem consists of the following basic components:

Elcom-90 User Elements
The User Elements supports version 1, class 3 of the Elcom-90 protocol. Only responder functionality is supported. The next Functional Units are supported:

• Permanent/Dynamic Associations.
• Test association.
• Group Management.
• Group Definition.
• Group Read-out.
• Requested Data Transfer.
• Periodic Data Transfer.
• Unsolicited (mixed) data transfer.
• Supervisory Control Data Transfer.

Elcom-90 provider
The provider supports the Elcom-90 responder functionality for OSI layers 6 and 7. The implementation of the Elcom-90 Provider follows specifications of EFI as closely as possible. The TCP/IP protocol is supported as lower layer protocol. X.25 is not supported.

TCP/IP and SLIP Protocol
TCP/IP is supported as defacto standard protocol on both the substation ethernet network as well as on serial lines. Serial lines, (based on V24 connections) are used as the physical transmission layer. TCP running on serial lines is supported through SLIP (Serial Line Internet Protocol). The de-facto standard 'Van Jacobson compression' is supported for optimum serial line throughput. All data exchange on the substation ethernet network is based on TCP/IP. In the Veesta-Automation system TCP/SLIP can be configured at two sides of the system:

• A serial port of the Control Unit.
• A serial port of one of the Communication boards in the Interface Modules.

Control Unit TCP/IP or SLIP
This is to connect a (remote) PC running:

• The SGUI software for graphical user interface purposes.
• An FTP client program for file transfers such as Project Archives or Historic event, trend data and disturbance data files.
• A Telnet session for (remote) diagnostics.

LC212 TCP/SLIP
This is to connect Remote Control Centre protocol which run on top of TCP/SLIP. The TCP/SLIP interfaces on the Communication boards of Veesta-Automation implement the de-facto standard TCP and UDP protocols across a serial line (SLIP). This interface is used to provide the following services:

• Remote control by means of Elcom-90
• Remote terminal by means of Telnet

MODBUS RTU Protocol
Veesta-Automation supports both a slave and a master implementation of the MODBUS-RTU protocol. The MODBUS RTU Slave protocol provides a way to communicate with a MODBUS master and visa versa. MODBUS for Veesta-Automation will support up to four MODBUS interfaces at a time.

MODBUS function codes
The following MODBUS function codes are supported (depending on master or slave usage):

• Read coil status.
• Read input status
• Read output register
• Read holding register.
• Force single coil.
• Preset single register.
• Force multiple coils.
• Preset multiple registers.

Exception responses are generated by the slave if the master requests an invalid address or function.
The mapping of RTD elements to registers is done by a linear scaling.

Alstom Courier Protocol
The Courier communication language was created by Alstom for communicating with their K-series range of protection relays. It provides a means of retrieving and setting data cells in the relay’s menu system. In the context of Veesta-Automation, the Courier protocol is mainly used to exchange real-time values between menu cells of the protection relays and RTD elements. It is based on the ISO-OSI enhanced performance architecture (EPA). The Courier protocol layers correspond to the application layer of this model. For Veesta-Automation, the IEC 60870-5 standard is used for the link layer and physical connection. The Courier protocol implementation runs on Communication boards. Communication with the relays is performed via a KITZ conversion unit for each communications line which translates the IEC 60870-5 frame format into the K-BUS format that the relays use. Up to 32 relays per serial line can be supported with this configuration. The implementation of the COURIER protocol makes it possible to map relay menu cells on RTD elements. The COURIER menu cells to be mapped may be of the following value types:
• Binary flags
• Unsigned integer
• Signed integer
• Numeric Number
• IEEE floating point number

Read-only menu cells can be mapped on input RTD elements. Settings cells and password protected setting cells can be mapped on input and/or output RTD elements. For cells that can be reset, the reset cell function can be mapped on an output RTD element. Changing this element from 0 to 1 will trigger the reset cell.
The RTD elements that are updated by the protocol can be used in the same way as other I/O elements (e.g. digital inputs, analog inputs, read from conventional i/o boards). They can be used for:

• Alarming
• Display on graphical user interface
• Input or output for (composed) objects
• Transfer to the RCC through the RCC protocol

ABB - RP570/571 Protocol
The RP571 protocol is the intellectual ownership of ABB and is used to exchange data between Remote Terminal Units (RTU’s) and a Remote Control Point (RCP). The RTU and RCP are parts of a S.P.I.D.E.R. system. RP571 makes Veesta-Automation behave like a RTU200 equipment allowing it to handle data requests and commands from a S.P.I.D.E.R. station. Is protocols is supplied under a strict license arrangement with ABB.

ABB - INDACTIC 2033 Protocol
The Indactic 2033 protocol is the intellectual ownership of ABB and is used to exchange data between Remote Terminal Units (RTU’s) and a Control Center (CC). The RTU and CC are parts of a SCADA PN40 system. Indactic 2033 makes Veesta-Automation behave like a ABB-RTU equipment allowing it to handle data requests and commands from a Control Center station. Is protocols is supplied under a strict license arrangement with ABB.

GI74 Protocol
The GI74 protocol is developed and used by the National Grid Company Ltd., United Kingdom for the communication between their Area / National Control Centers and the remote outstations. The GI74 protocol allows a master station to retrieve data and send commands. The master station is always the initiating party in this case; i.e. the master sends requests, which are fulfilled by the protocol handler. The protocol supports a number of requests. The requests can be divided roughly into the following different types:

1. Control requests.
2. Read block requests.
3. Read word requests.
4. Send changes requests
5. Multiword cleardown requests.

TG709/E & TG809 Protocol
The TG709/E and TG809 protocols are the intellectual property of Siemens (formerly Landis & Gyr). This is readily available and field proven, licensed proprietary protocol which can be used on special request.

WISP & WISP+ Protocol
The WISP and WISP+ extended protocols are the intellectual property of Groupe Schneider (formerly Westinghouse Systems Ltd.). This is readily available and field proven, licensed proprietary protocol which can be used on special request.

CDC 8890 Type II
The CDC 8890 Type II protocol is the intellectual property of Siemens (formerly Control Data / Empros). The CDC 8890 Type II protocol is used to transfer data to and from an ETAG substation. CDC 8890 Type II makes Veesta-Automation behave like an 8890 RTU allowing it to handle data requests and commands from a master station.
The CDC 8890 Type II protocol allows a master station to retrieve data and send commands. The master station is always the initiating party in this case, i.e. the master sends requests which are fulfilled by the protocol handler. The protocol supports a number of requests. The requests can be divided roughly into three different types:

1. Control messages
This includes setpoint control. For digital control points a select-before-operate function and a direct operation function are supported.
2. Scan messages
These are used to obtain input data of a particular type, for example digital status indications and/or analog data. The scan requests also support the concept of tables. This allows certain data point to be categorized so that all these points can be read in one scan. Table configuration is performed from the master station and not via the application builder.
3. Memory read/write
These are used by the protocol for defining scan tables.

HITACHI Protocol
The Hitachi protocol is the intellectual ownership of HITACHI Japan and is used to exchange data between Remote Terminal Units (RTU’s) and a Control Center (CC). The RTU and CC are parts of a HITACHI SCADA system. Hitachi Protocol makes Veesta-Automation behave like a HITACHI-RTU equipment allowing it to handle data requests and commands from a Control Center station. Is protocols is supplied under a strict license arrangement with HITACHI.