IEC101

Supports unbalanced (only master initiated message) & balanced (can be master/slave initiated) modes of data transfer.

Link address and ASDU addresses are provided for classifying the end station and different segments under the same. Data is classified into different information objects and each information object is provided with a specific address. Facility to classify the data into high priority (class-1) and low priority (class-2) and transfer the same using separate mechanisms. Possibility of classifying the data into different groups (1-16) to get the data according to the group by issuing specific group interrogation commands from the master & obtaining data under all the groups by issuing a general interrogation. Cyclic & Spontaneous data updating schemes are provided. Facility for time synchronization Schemes for transfer of files

IEC 60870-5-104 (IEC 104) protocol is an extension of IEC 101 protocol with the changes in transport, network, link & physical layer services to suit the complete network access. The standard uses an open TCP/IP interface to network to have connectivity to the LAN (Local Area Network)and routers with different facility (ISDN, X.25, Frame relay etc) can be used to connect to the WAN (Wide Area Network). Application layer of IEC 104 is preserved same as that of IEC 101 with some of the data types and facilities not used. There are two separate link layers defined in the standard, which is suitable for data transfer over Ethernet & serial line (PPP - Point-to-Point Protocol) which doesn't really work very well.

Additional Synchronization Mechanisms

Control field data of IEC104 contains various types of formats /mechanisms for effective handling of network data synchronization auk_3010@yahoo.co.in

1. I Format It is used to perform numbered information transfer. It contains sendsequence number and receive-sequence number. The transmitter station increases sendsequence number when it sends any data and receiver increases receive-sequence number when it receives any data. The sending station has to hold the send APDUs in the buffer until it receives back the send sequence numbers as the receive sequence number from destination station. 2. S Format It is used to perform numbered supervisory functions. In any cases where the data transfer is only in a single direction, S-format APDUs has to be send in other direction before timeout (t2), buffer overflow or when it has crossed maximum number of allowed I format APDUs without acknowledgement (w). 3. U Format It is used to perform unnumbered control functions. This is used for activation and confirmation mechanisms of STARTDT (start data transfer) & STOPDT (stop data transfer) & TESTFR (test APDU). 4. Test Procedure Open but unused connections must be tested periodically (when it has crossed t3 after the last message) by sending TESTFR frames, which need to be acknowledged, by the destination station. The connection needs to be closed when there is no reply for the test message after timeout (t1) or when there are more numbers of Iformat APDUs than the specified k.more information IEC 60870-5-103 [IEC103] is a standard prepared by International Electrotechnical Commission Technical committee 57 for power system control and associated communications. It defines a companion standard that enables interoperability between protection equipment and devices of a control system in a substation. The device complying with this standard can send the information using two methods for data transfer - either using the explicitly specified application service data units (ASDU)or using generic services for transmission of all the possible information. The standard supports some specific protection functions and provides the vendor a facility to incorporate its own protective functions on private data ranges.

Supported Types

Type 1 -- Time-tagged message Type 2 -- Time-tagged message with relative time Type 3 -- Measurands I Type 4 -- Time-tagged measurands with relative time Type 5 -- Identification Type 6 -- Time synchronization Type 7 -- Start of General interrogation Type 8 -- General interrogation termination Type 9 -- Measurands II Type 10 -- Generic data Type 11 -- Generic identification Type 23-31 -- Used for transferring disturbance files

IEC 61850[1] is a standard for the design of electrical substation automation. IEC 61850 is a part of the International Electrotechnical Commission's (IEC) Technical Committee 57 (TC57)[2] reference architecture for electric power systems. The abstract data models defined in IEC 61850 can be mapped to a number of protocols. Current mappings in the standard are to MMS (Manufacturing Message Specification), GOOSE, SMV, and soon to Web Services. These protocols can run over TCP/IP networks and/or substation LANs using high speed switched Ethernet to obtain the necessary response times of < 4 ms for protective relaying.

History
Multiple protocols exist for substation automation, which include many proprietary protocols with custom communication links. Interoperation of devices from different vendors would be an advantage to users of substation automation devices. An IEC project group of about 60 members from different countries worked in three IEC working groups from 1995. They responded to all the concerns and objectives and created IEC 61850. The objectives set for the standard were: 1. A single protocol for complete substation considering modeling of different data required for substation. 2. Definition of basic services required to transfer data so that the entire mapping to communication protocol can be made future proof. 3. Promotion of high interoperability between systems from different vendors. 4. A common method/format for storing complete data. 5. Define complete testing required for the equipments which conforms to the standard.

IEC 61850 Features

IEC 61850 features include: 1. Data Modeling -- Primary process objects as well as protection and control functionality in the substation is modelled into different standard logical nodes which can be grouped under different logical devices. There are logical nodes for data/functions related to the logical device (LLN0) and physical device (LPHD). 2. Reporting Schemes -- There are various reporting schemes (BRCB & URCB) for reporting data from server through a server-client relationship which can be triggered based on pre-defined trigger conditions. 3. Fast Transfer of events -- Generic Substation Event (GSE) are defined for fast transfer of event data for a peer-to-peer communication mode. This is again subdivided into GOOSE & GSSE. 4. Setting Groups -- The setting group control Blocks (SGCB) are defined to handle the setting groups so that user can switch to any active group according to the requirement.

5. Sampled Data Transfer -- Schemes are also defined to handle transfer of sampled values using Sampled Value Control blocks (SVCB) 6. Commands -- Various command types are also supported by IEC 61850 which include direct & select before operate (SBO) commands with normal and enhanced securities. 7. Data Storage-- SCL (Substation Configuration Language) is defined for complete storage of configured data of the substation in a specific format. DNP3 (Distributed Network Protocol) is a set of communications protocols used between components in process automation systems. Its main use is in utilities such as electric and water companies. Usage in other industries is not common, although technically possible. Specifically, it was developed to facilitate communications between various types of data acquisition and control equipment. It plays a crucial role in SCADA systems, where it is used by SCADA Master Stations (aka Control Centers), Remote Terminal Units (RTUs), and Intelligent Electronic Devices (IEDs). It is primarily used for communications between a master station and RTUs or IEDs. ICCP, the Inter-Control Centre Protocol, is used for inter-master station communications. The DNP3 protocol has significant features that make it more robust, efficient, and self compatible than older protocols such as Modbus, at the cost of somewhat higher complexity. DNP3 is, in standard networking terms, mostly a layer 2 protocol. It provides multiplexing, data fragmentation, error checking, link control, prioritization, and layer 2 addressing services for user data. The DNP3 frame strongly resembles, but is not identical to the FT3 frame. It makes heavy use of Cyclic redundancy check codes to detect errors. The improved bandwidth efficiency is accomplished through event oriented data reporting. The Remote Terminal Unit is initially interrogated with what DNP3 terms a "Class 0 poll." This causes the RTU to send all static point data to the Master station. Then, as the data points generate events, these events can be placed in one of three buffers whose status is reported on every Remote Terminal Unit response. If there is data in that buffer, the buffer data flag is set. The Master can then see that there should be event data to be retrieved when issuing a poll for Class 1, Class 2, or Class 3. In other words, after a Class 0 poll, only significant data changes are sent. This can result in significantly more responsive data retrieval than polling everything, all the time, irrespective of whether it has changed significantly. The Remote Terminal Unit can also be configured to spontaneously report Class 1, 2, or 3 data, when it becomes available. The DNP3 protocol supports time synchronization with an RTU. The DNP Protocol has time stamped variants of all point data objects so that even with infrequent RTU polling, it is still possible to receive enough data to reconstruct a sequence of events of what happened in between the polls.

The DNP3 protocol has a substantial library of common point-oriented objects. The focus of this extensive library was to eliminate the need for bit-mapping data over other objects, as is often done in many Modbus installations. For example, floating point number variants are available, so there is no need to map the number on to a pair of 16 bit registers. This improves compatibility and eliminates problems such as Endianness. A Remote Terminal Unit for the DNP3 protocol can be a very small, simple embedded device, or it can be a very large, complex rack filled with equipment. The DNP User Group has established four levels of subsets of the protocol for RTU compliance. The DNP Users Group has published test procedures for Levels 1 and 2, the simplest implementations. While this protocol is robust, efficient, compatible, and secure; it is getting more and more complex and subtle as it ages. While this is partly due to more demanding industrial applications, it is also a reflection that SCADA concepts are not as simple as they might first seem. The goal of compatibility, seems more and more elusive as issues emerge from field experience.

Section About Index News License Who is using jamod? Download SF Project Home Changes Todo Getting Involved Discussion Fora Support Requests Mailing Lists Bug Reporting & Tracking Feature Request Knowledge Base Index Understanding the Protocol

SF > jamod

> kbase

PDF

Understanding the Modbus Protocol

About Modbus Protocol Basics o Modbus Functions o Exceptions o Modbus Data Model Modbus Implementations o Serial Modbus Implementations o IP based Modbus Implementations Critical Evaluation of the Specification(s)

About
This document introduces the reader to the Modbus protocol. It presents a basic protocol description and discusses the serial and the TCP based implementations.

Modbus Protocol Basics

Basically Modbus is an application layer protocol (see Figure 1) for communication between devices, mainly to exchange data typical for

Modbus/UDP Modbus/BIN Development Overview Project Guidelines Build Notes CVS Repository access information online browsing HOW-TO's Serial Master TCP Master UDP Master Process Image Serial Slave TCP Slave UDP Slave API Documentation Credits Project Credits Legal Notices

the field of automation.

Figure 1: ISO/OSI Context

At this level Modbus is a stateless client-server protocol (e.g. much like HTTP), based on transactions, which consist of a request (issued by the client) and a response (issued by the server). In the field where this protocol is usually applied, there exists a concept that is one of the possible schemas governing the lower level communication behavior on a network using a shared signal cable: Master-Slave. To prevent confusion, the following directed relations describe Master-Slave in terms of the Client-Server paradigm:

the Master is a Client the Slave is a Server

A transaction and it's context is visualized in Figure 2.

Figure 2: Modbus Transaction

The stateless communication is based on a simple package, that is called Protocol Data Unit (PDU). The protocol specification defines three types of PDU's:

Request PDU, consisting of: 1. a code specifying a function (Function Code, 1 byte) 2. and function specific data (Function Data, varying number of bytes) Response PDU, consisting of:

1. the function code corresponding to the request (Function Code, 1 byte) 2. and response specific data (Response Data, varying number of bytes) Exception Response PDU, consisting of: 1. the function code corresponding to the request + 0x80 (128), (Error Code, 1 byte) 2. and a code specifying the exception (Exception Code, 1 byte)

Figure 3 presents a visualization of these packages.

Figure 3: Modbus Protocol Data Units (PDU)

Modbus Functions
The specification defines a certain number of functions, each of which is assigned a specific function code. These are in the range 1-127 (decimal), as 129(1+128)- 255(127+128) represents the range of error codes. While the first published version of the specification defined different classes of functions (e.g. Class 0, Class 1, Class 2), the newly released specification (from http://www.modbus.org; see Knowledge Base Index) defines categories of function codes:

Public Are guaranteed to be unique and specify well defined functions that are publicly documented. These are validated by the community and a conformance test exists. User-Defined Are available for user-defined functions, thus their codes might not be unique. The specification defines the code ranges 65-72 and 100-110 for user-defined functions. Reserved These are currently used by some companies for legacy products and are not available for public use (these are not

discussed any further in the specification). The documentation for a function consists of: 1. a description of the function (i.e. what it is good for), it's parameters and return values (including possible exceptions). 2. the assigned Function Code 3. the Request PDU 4. the Response PDU 5. the Exception Response PDU The specification further documents defined and assigned public functions.

Exceptions
In certain cases, the response from a slave will be an exception. The primary identification of an exception response is the error code (function code + 128), which is further specified by the exception code. Assigned codes and descriptions can be found in the specification.

Modbus Data Model

The basic public functions have been developed for exchanging data typical for the field of automation. Table 1 contains the basic Modbus data types defined by the specification.

Table 1: Modbus Data Types

Name Discrete Input Discrete Output (Coils) Input Registers Holding Registers (Registers) Note The specification does not define the ways of organizing the related data in a device. However, the organization has a direct influence on Type single bit single bit 16-bit word 16-bit word Access read-only readwrite read-only readwrite Visual

the addresses used in basic access functions. (Thus always consult the device's documentation to learn about addressing in basic access functions!)

Modbus Implementations
Basically Modbus has been implemented and used over all types of physical links (wire, fiber and radio) and various types of lower level communication stacks. However, we will concentrate on the two basic types of implementations (which are supported by jamod): 1. Serial: Asynchronous Master/Slave 2. IP: Master/Slave

Serial Modbus Implementations

Modbus started it's life in form of an implementation for asynchronous serial network communication. The application level protocol operates directly on top of a serial interface and serial communication standards. The most common ones (over wire) are:

RS232 (EIA232): see The RS232 Standard RS422/RS485: see Introduction to RS422 and RS485

RS232 is used for short distance point-to-point communication, the same is valid for RS 422, which is a bidirectional extension of RS232 for industrial environments, that also supports longer distances. RS485 can be used for multipoint communication (i.e. multiple devices connected to the same signal cable), employing the Master-Slave paradigm (one master and n fixed address slaves). Figure 4 visualizes the possible network setups.

Figure 4: Serial Network Architectures

To enable the actual communication for this setups, the implementation extends the PDU with additional fields, better said, it wraps the PDU into a package with a header and an error checksum (see Figure 5). The resulting package is defined by the protocol specification as Application Data Unit (ADU), that has a maximum package size of 256 bytes. Note The maximum package size limitation of 256 bytes applies for all existing Modbus protocol implementations!

Figure 5: Serial ADU

The header is composed of an address field (1 byte) and the tail is an error checksum over the whole package, including the address field (i.e. header). For transmission the Modbus message (i.e. ADU) is placed into a frame that has a known beginning and ending point, allowing detection of the start and the end of a message and thus partial messages. There exist two transmission modes, which differ in encoding, framing and checksum: 1. ASCII Frames are encoded into two ASCII characters per byte, representing the hexadecimal notation of the byte (i.e. characters 09, AF). The error checksum is represented by a longitudinal redundancy check (LRC; 1 byte) and messages start with a colon (':', 0x3A), and end with a carriage return line feed ("CRLF", 0x0D0A). Pauses of 1 second between

characters can occur. 2. RTU Frames are transmitted binary to achieve a higher density. The error checksum is represented by a cyclic redundancy check (16 bit CRC; 2 byte) and messages start and end with a silent interval of at least 3.5 character times. This is most easily implemented as a multiple of character times at the baud rate that is being used on the network. The maximum pause that may occur between two bytes is 1.5 character times. jamod is designed to support both transmission modes, using an implementation which is based on the javax.comm API. Warning The RTU implementation does only support the Master side. It is working by the best effort principle, which means it might not work in a reliable way in a low-lantency real-time context. It is indeed possible to implement the serial transport based on other serial stack implementations (i.e. replacements for the Java Comm API implementation) like for example SerialPort ( http://www.scsystems.com/products/serialport/serialport.htm). According to the product info it supports around 20 platforms and it has been successfully used to implement the two serial transmission modes in Java (Master only, see Field Talk/Java, a commercial Master protocol pack from Focus Engineering).

IP based Modbus Implementations

A TCP/IP based Modbus protocol implementation (Modbus/TCP) has been recently committed as an RFC draft to the IETF. It uses the TCP/IP stack for communication (registered port is 502) and extends the PDU with an IP specific header (see Figure 6). The possible network setups are not governed by the specification; it is possible to setup multi-master systems or realize bidirectional communication (i.e. have nodes that are master and slave at the same time). However, the user should be well aware that there are implications from deviations of the Master/Slave schema.

Figure 6: Modbus/TCP ADU

The IP specific header (called MBAP in the specification) is 7 bytes long and composed of the following fields: 1. the invocation identification (2 bytes) used for transaction pairing; formerly called transaction identifier 2. the protocol identifier (2 bytes), is 0 for Modbus by default; reserved for future extensions 3. the length (2 bytes), a byte count of all following bytes 4. the unit identifier (1 byte) used to identify a remote unit located on a non-TCP/IP network

Critical Evaluation of the Specification(s)

There are a few points regarding the specification, which are definitely discussable: 1. The specification does not present a consistent naming for all of the basic simple data types. This propagates to the naming of a number basic data access functions. Probably it would be good to elaborate one consistent naming schema, to avoid confusion and allow better mind mapping. 2. The Modbus Encapsulated Interface (MEI) is exposed through a documented public function, without being further explained. 3. The properties of the protocol are perfectly suited for the use of UDP/IP as transport layer protocol: 1. it is stateless, 2. transaction oriented 3. and the package size is limited to 256 bytes, which should be easily transferable over any IP capable link (including IP over Serial) without the necessity to split the package. Especially if a real-time communication has to be achieved, it might be of interest to investigate in a Modbus/UDP implementation. Note For learning more about Modbus/UDP, please see: Modbus/UDP Specification.
by Dieter Wimberger

auk_3010@yahoo.co.in