Another new post

ICCP Functionality[edit]

Basic ICCP functionality is specified as “Conformance Blocks” listed below. The objects that are used to convey the data are defined in various parts of IEC 60870-6.

Block Description Data Examples:

  1. Periodic System Data: Status points, analogue points, quality flags, time stamp, change of value counter, protection events. Association objects to control ICCP sessions.
  2. Extended Data Set Condition Monitoring: Provides report by exception capability for the data types that block 1 is able to transfer periodically.
  3. Block Data Transfer: Provides a means transferring Block 1 and Block 2 data types as block transfers instead of point by point. In some situations this may reduce bandwidth requirements.
  4. Information Messages: Simple text and binary files.
  5. Device Control: Device control requests: on/off, trip/close, raise/lower etc. and digital setpoints. Includes mechanisms for interlocked controls and select-beforeoperate.
  6. Program Control: Allows an ICCP client to remote control programs executing on an ICCP server.
  7. Event Reporting: Extended reporting to a client of error conditions and device state changes at a server.
  8. Additional User Objects: Scheduling, accounting, outage and plant information.
  9. Time Series Data: Allows a client to request a report from a server of historical time series data between a start and end date.

Protocol Architecture[edit]

ICCP is based on client / server principles. Data transfers result from a request from a control centre (client) to another control centre (server). Control centres may be both clients and servers. ICCP operates at the application layer in the OSI model. As such any physical interfaces, transport and network services that fit this model are supported. TCP/IP over Ethernet (802.3) seems to be the most common. ICCP may operate over a single point-to-point link between two control centres; however, the more general case is for many control centres and a routed wide area network. The logical connections or “associations” between control centres are completely general. A client may establish associations with more than one server and a client may establish more than one association with the same server. Multiple associations with same server can be established at different levels of quality of service so that high priority real time data is not delayed by lower priority or non real time data transfers.

Access Control[edit]

ICCP does not provide authentication or encryption. These services are normally provided by lower protocol layers. ICCP uses “Bilateral Tables” to control access. A Bilateral Table represents the agreement between two control centres connected with an ICCP link. The agreement identifies data elements and objects that can be accessed via the link and the level of access permitted. Once an ICCP link is established, the contents of the Bilateral Tables in the server and client provide complete control over what is accessible to each party. There must be matching entries in the server and client tables to provide access to data and objects.


The wide acceptance of ICCP by the utility industry has resulted in several ICCP products being on the market. Although interoperability is not regarded as a high risk area, the standard is such that an implementation does not have to support all conformance blocks in order to claim compliance with the standard. A minimal implementation only requires Block 1. Only those blocks necessary to achieve the required functionality need be implemented. It is also not necessary to support all objects defined in the standard for any particular block. Extensive interoperability testing between products of some of the major vendors has been a feature of ICCP protocol development. Independent reports are available, as no doubt are reports from vendors. An ICCP purchaser must define functionality required in terms of conformance blocks required and the objects within those blocks. Application profiles for the ICCP client and server conformances must match if the link is to operate successfully.

Product Differentiation[edit]

ICCP is a real time data exchange protocol providing features for data transfer, monitoring and control. For a complete ICCP link there need to be facilities to manage and configure the link and monitor its performance. The ICCP standard does not specify any interface or requirements for these features that are necessary but nevertheless do not affect interoperability. Similarly failover and redundancy schemes and the way the SCADA responds to ICCP requests is not a protocol issue so is not specified. These non protocol specific features are referred to in the standard as “local implementation issues”. ICCP implementers are free to handle these issues any way they wish. Local implementation is the means that developers have to differentiate their product in the market with added value. Additional money spent on a product with well-developed maintenance and diagnostic tools may well be saved many times over during the life of the product if use of the ICCP connection is expected to grow and change.

Product Configurations[edit]

Commercial ICCP products are generally available for one of three configurations:

  1. As a native protocol embedded in the SCADA host.
  2. As a networked server.
  3. As a gateway processor.

As an embedded protocol the ICCP management tools and interfaces are all part of the complete suite of tools for the SCADA. This configuration offers maximum performance because of the direct access to the SCADA database without requiring any intervening buffering. This approach may not be available as an addition to a legacy system. The ICCP application may be restricted to accessing only the SCADA environment in which it is embedded.

A networked server making use of industry standard communications networking to the SCADA host may provide performance approaching that of an embedded ICCP application. On the application interface side the ICCP is not restricted to the SCADA environment but is open to other systems such as a separate data historian or other databases. Security may be easier to manage with the ICCP server segregated from the operational real time systems. The gateway processor approach is similar to the networked server except it is intended for legacy systems with minimal communications networking capability and so has the lowest performance. In the most minimal situation the ICCP gateway may communicate with the SCADA host via a serial port in a similar manner to the SCADA RTUs.


Test post

The DNP3 protocol has significant features that make it more robust, efficient, and interoperable than older protocols such as Modbus, at the cost of higher complexity.

In terms of the OSI model for networks, DNP3 specifies a layer 2 protocol. It provides multiplexing, data fragmentation, error checking, link control, prioritization, and layer 2 addressing services for user data. It also defines a Transport function (somewhat similar to the function of layer 4) and an Application Layer (layer 7) that defines functions and generic data types suitable for common SCADA applications. The DNP3 frame strongly resembles, but is not identical to the IEC 60870-5 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 monitors data points and generates events when it determines that the data should be reported (for example, when it changes value). These events are each placed in one of three buffers, associated with “Classes” 1, 2 and 3. In addition to these, Class 0 is defined as the “static” or current status of the monitored data.

The Remote Terminal Unit is initially interrogated with what DNP3 terms an “Integrity Poll” (a combined Read of Class 1, 2, 3 and 0 data). This causes the Remote Terminal Unit to send all buffered events and also all static point data to the Master station. Following this, the Master polls for the event data by reading Class 1, Class 2 or Class 3. The reading of the classes can all be performed together or each class can be read at a different rate, providing a mechanism to create different reporting priorities for the different classes. After an Integrity 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, and compatible; 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.