IDC Books - Technical Training that Works

SZ-E - Practical IEC 61850 for Substation Automation This manual is designed for personnel with a need to understand the techniques required to use and a.. Product #: sku123536646 Regular price: $127.22 $127.22

SZ-E - Practical IEC 61850 for Substation Automation

Price: $139.94
Ex Tax: $127.22

Available Options

* Options:
- +

This manual is designed for personnel with a need to understand the techniques required to use and apply IEC 61850 to substation automation, hydro power plants, wind turbines and distributed energy resources as productively and economically as possible.

This manual provides comprehensive coverage of IEC 61850 and will provide you with the tools and knowledge to tackle your next substation automation project with confidence.

Download Chapter List

Table of Contents

Chapter 1: Introduction

1

Introduction

 

1.1          Basic requirements of communication

Every data communication system requires the following:

  • A source of data (transmitter or line driver) which converts the information into
  • A form suitable for transmission over a link
  • A receiver that accepts the signal and converts it back into the original data
  • A communications link that transports the signal. This can be copper wire, optical fiber or a radio link

In addition, the transmitter and receiver must be able to understand each other. This requires mutual agreement on a number of factors. The most important of these are:

  • The type of signalling used
  • Defining what represents a logical ‘1’and a logical ‘0’
  • The codes that represent the data symbols
  • Maintaining synchronization between the transmitter and receiver
  • How the flow of data is controlled, so the receiver is not swamped
  • How to detect and correct transmission errors.

The rules governing the transmission process are called the ‘protocols’

Note: The term ‘communication’ will exclusively refer to digital data communication for the rest of the text, unless otherwise stated.

 

 

Figure 1.1

Data byte representation

 

Synchronous and asynchronous transmissions are two different methods of transmission synchronization. Synchronous transmissions are synchronized by an external clock, while asynchronous transmissions are synchronized by special signals along the transmission medium.

Asynchronous transmission is used for low data-rate transmission and stand-alone equipment. The block length is only 8 data-bits, permitting different clocks with only approximate synchronism to be used. Very commonly, the 8 bits represent an ASCII character. For this reason, frame synchronisation is often referred to as character synchronisation in asynchronous systems.

Synchronous transmission is used for high data rate transmission. The timing is generated by sending a separate clock signal, or embedding the timing information into the transmission. This information is used to synchronise the receiver circuitry to the transmitter clock. Because the clocks are synchronised, much longer block lengths are possible.

The type of framing, character or block, is sometimes used to indicate whether a system uses asynchronous or synchronous transmission. This terminology does obscure the important difference between the different methods of timing control.

 

1.2          Communication topologies

1.2.1          Logical and physical topologies

A logical topology defines how the elements in the network communicate with each other, and how information is transmitted through a network. The different types of media-access methods, discussed later, determine how a node gets to transmit information along the network. In a bus topology, information is broadcast, and every node gets the same information within the amount of time it actually takes a signal to cover the entire length of cable. This time interval limits the maximum speed and size for the network. In a ring topology, each node hears from exactly one node and talks to exactly one other node. Information is passed sequentially, in an order determined by a predefined process. A polling or token mechanism is used to determine who has transmission rights, and a node can transmit only when it has this right.

A physical topology defines the wiring layout for a network. This specifies how the elements in the network are connected to each other electrically. This arrangement will determine what happens if a node on the network fails. Physical topologies fall into three main categories... bus, star, and ring topology. Combinations of these can be used to form hybrid topologies to overcome weaknesses or restrictions in one or other of these three component topologies.

 

1.2.2          Bus topology

A bus refers to both a physical and a logical topology. As a physical topology, a bus describes a network in which each node is connected to a common single communication channel or "bus". This bus is sometimes called a backbone, as it provides the spine for the network. Every node can hear each message packet as it goes past.

Logically, a passive bus is distinguished by the fact that packets are broadcast and every node gets the message at the same time. Transmitted packets travel in both directions along the bus, and need not go through the individual nodes, as in a point to point system. Rather, each node checks the destination address that is included in the message packet to determine whether that packet is intended for the specific node. When the signal reaches the end of the bus, an electrical terminator absorbs the packet energy to keep it from reflecting back again along the bus cable, possibly interfering with other messages already on the bus. Each end of a bus cable must be terminated, so that signals are removed from the bus when they reach the end.

In a bus topology, nodes should be far enough apart so that they do not interfere with each other. However, if the backbone bus cable is too long, it may be necessary to boost the signal strength using some form of amplification, or repeater. The maximum length of the bus is limited by the size of the time interval that constitutes "simultaneous" packet reception.  Figure 1.2 illustrates the bus topology.

 

Figure 1.2
Bus topology

Bus topology advantages

Bus topologies offer the following advantages:

  • A bus uses relatively little cable compared to other topologies, and arguably has the simplest wiring arrangement
  • Since nodes are connected by high impedance tappings across a backbone cable, it's easy to add or remove nodes from a bus. This makes it easy to extend a bus topology
  • Architectures based on this topology are simple and flexible
  • The broadcasting of messages is advantageous for one-to-many data transmissions

Bus topology disadvantages

These include the following:

  • There can be a security problem, since every node may see every message, even those that are not destined for it
  • Diagnosis/troubleshooting (fault-isolation) can be difficult, since the fault can be anywhere along the bus
  • There is no automatic acknowledgment of messages, since messages get absorbed at the end of the bus and do not return to the sender
  • The bus cable can be a bottleneck when network traffic gets heavy. This is because nodes can spend much of their time trying to access the network

 

1.2.3          Star topology

A star topology is a physical topology in which multiple nodes are connected to a central component, generally known as a hub. The hub of a star usually is just a wiring center; that is, a common termination point for the nodes, with a single connection continuing from the hub. In some cases, the hub may actually be a file server (a central computer that contains a centralized file and control system), with all its nodes attached directly to the server.  As a wiring center a hub may, in turn, be connected to the file server or to another hub.

All signals, instructions, and data going to and from each node must pass through the hub to which the node is connected. The telephone system is doubtless the best known example of a star topology, with lines to individual customers coming from a central telephone exchange location. There are not many LAN implementations that use a logical star topology. The low impedance ARCnet networks are probably the best examples. However, you will see that the physical layout of many other LANs look like a star topology even though they are considered to be something else. An example of a star topology is shown in Figure 1.3.

 

Figure 1.3
Star topology

 

Star topology advantages

  • Troubleshooting and fault isolation is easy
  • It is easy to add or remove nodes, and to modify the cable layout
  • Failure of a single node does not isolate any other node
  • The inclusion of a central hub allows easier monitoring of traffic for management purposes

Star topology disadvantages

  • If the hub fails, the entire network fails. Sometimes a backup central machine is included, to make it possible to deal with such a failure.
  • A star topology requires a lot of cable.

 

1.2.4          Ring topology

A ring topology is both a logical and a physical topology. As a logical topology, a ring is distinguished by the fact that message packets are transmitted sequentially from node to node, in a predefined order, and as such it is an example of a point-to-point system. Nodes are arranged in a closed loop, so that the initiating node is the last one to receive a packet. As a physical topology, a ring describes a network in which each node is connected to exactly two other nodes, see Figure 1.4

Information traverses a one-way path, so that a node receives packets from exactly one node and transmits them to exactly one other node. A message packet travels around the ring until it returns to the node that originally sent it. In a ring topology, each node can act as a repeater, boosting the signal before sending it on. Each node checks whether the message packet's destination node matches its address. When the packet reaches its destination, the destination node accepts the message, and then sends it back to the sender, to acknowledge receipt.

As you will see later in this chapter, since ring topologies use token passing to control access to the network, the token is returned to sender with the acknowledgment. The sender then releases the token to the next node on the network. If this node has nothing to say, the node passes the token on to the next node, and so on. When the token reaches a node with a packet to send, that node sends its packet. Physical ring networks are rare, because this topology has considerable disadvantages compared to a more practical star-wired ring hybrid.

 

Figure 1.4
Ring topology

Ring topology advantages

  • A physical ring topology has minimal cable requirements
  • No wiring center or closet is needed
  • The message can be automatically acknowledged
  • Each node can regenerate the signal

Ring topology disadvantages

  • If any node goes down, the entire ring goes down
  • Diagnosis/troubleshooting (fault isolation) is difficult because communication is only one-way
  • Adding or removing nodes disrupts the network
  • There will be a limit on the distance between nodes

 

1.3          Communication techniques

Communication techniques are divided into two types: master-slave communication and peer-to-peer communication.

 

1.3.1          Master-slave communication

This is the simplest, most common, but also least flexible communication technique. Centralized control over the communication network is executed by the ‘master’, normally a SCADA master. The rest of the devices on the communication network are the ‘slaves’, and may only communicate on the network when requested or permitted by the master, and only with the master.

Master-slave communications usually result in inefficient use of communication bandwidth, and relatively slow speed of communication; although many systems allow priorities to be assigned to send/gather data more quickly to/from certain specified sites.

Deterministic response times are obtained with this technique. It can be used on any topology.

 

1.3.2          Peer-to-peer communication

The peer-to-peer communication technique allows all devices on the network to initiate communications with any other device on the network.

Although there is not a master and slave configuration, some techniques require a bus administrator to assume a certain amount of communication control over the network. One of the remote stations will then perform this role. Other techniques do not require a centralized communication controller and each device on the network will perform its own communication control. This demands far more complex protocols, but more flexibility, efficient use of bandwidth and hence far higher speeds of communication are obtained.

Although it is not functioning as a master, a SCADA system will normally receive the majority of the network data, and remote control commands will usually be initiated by the SCADA system. Although supervisory control and data acquisition are lost if the SCADA system should go down, network communications can still be retained (which is not the case in master-slave techniques).

 

1.4          Media access control methods

‘Rules’ are needed for data communications, otherwise there will be chaos, and no communication can exist. These rules govern the way stations will get access to the network, thus the term ‘media access control’.

 

1.4.1          Conventional polling

Conventional polling is the most common and simplest form of data communication. A master station requests data from each slave station in a predetermined sequence. If a slave does not respond in a defined time, the master retries (the number of retries depending on the programming), and marks the slave as non-responding if still no response is received.

Polling is illustrated in Figure 1.5.

Priorities may be assigned to slaves, meaning these stations will be polled at a higher rate than the normal stations. (Naturally, making all stations priority stations will defeat the purpose.) A priority message sent from the master station can override the standard polling sequence.

Polling can be used on virtually all physical media and any topology. The polling rate is dependent on the master and deterministic response times are obtained.

Polling result in inefficient use of bandwidth and relatively slow response times are characteristic of polling techniques.

No peer-to-peer communications are possible with polling.

(Note: Also commonly called ‘cyclic polling’)

 

Figure 1.5

Polling technique

Advantages of polling

  • Ease of programming
  • Reliability due to the simplicity of the philosophy
  • Failure of communication, either at the slave or due to a link failure, is detected relatively quickly.
  • No data collisions can occur on the network, therefore the data throughput is predictable and constant.
  • An efficient and predictable system for heavily loaded systems with each slave having constant data transfer requirements.

Disadvantages of polling

  • Systems that are lightly loaded with minimum data changes from slaves are inefficient and unnecessarily slow.
  • Slaves cannot communicate directly with each other, but have to do so through the master, adding complexity to the master programming, and resulting in slow communications between slaves due to the polling sequence.
  • Variations in the data transfer requirements of slaves cannot be handled as these are defined during programming.
  • Interrupt type requests from slaves requesting urgent action cannot be handled, as the master may be processing some other station.

 

1.4.2          Polling by exception

While maintaining most of the characteristics of conventional polling, this technique consists of the master requesting only event changes from the slave stations. If no changes have occurred during the polling cycle, no data will be returned to the master. This is a much more efficient data gathering technique for stations that have large amounts of data that varies infrequently.

Note that the protocol used in communicating between master and slave stations must support polling by exception, and both master and slave must understand the concept of events versus static data. Events are timetagged at the time of their occurrence, which is quite an improvement over conventional polling where the time of an event occurrence may be inaccurate by as much as the polling cycle time.

 

1.4.3          Time-division-multiplex media access

With time-division-multiplexing (TDM), each station has its own time slot, during which the station may send and receives data. This can be illustrated as in Figure 1.6. The time slot is fixed, independent of the network load. Deterministic response times are achieved, as there can be no collisions on the network.

A bus administrator is required to ensure that all stations comply with the network ‘rules’, also called centralised transport media arbitration.

TDM can be used on a ring or bus topology.

 

 

Figure 1.6

Illustration of TDM

Advantages of TDM

  • No data collisions can occur on the network, therefore the data throughput is predictable and constant.
  • It results in an efficient and predictable system for heavily loaded systems with each station having constant data transfer requirements.
  • Direct peer-to-peer communications are possible, although this is still relatively slow due to each station having to wait for its time slot.

Disadvantages of TDM

  • Systems that are lightly loaded with minimum data changes are inefficient and unnecessarily slow.
  • Variations in data transfer requirements cannot be handled as these are defined during programming.
  • Interrupt type requests from stations requesting urgent action cannot be handled.
  • A communication failure to a specific device may not be detected immediately,    except in protocols that use a technique called background polling or integrity polling. The bus administrator then polls each station (at a much slower rate) to verify that the central station’s data is up-to-date and to check the health of stations.
  • The network is still dependent on a central communications controller.
  • The configuration of the network is quite complex.

 

1.4.4          Token passing media access

The principle of this technique is illustrated in Figure 1.6. A token circulates around the ring. Any station that has something to report may take the token as it passes by, and that station then has exclusive access to the communication network. Once the station has completed its transmission, the token is released and circulates around the network again. This technique generally, but not necessarily, operates on a report-by-exception principle.

Semi-deterministic response times are obtained, as there can be no data collisions, but it cannot be pre-determined when a station is going to use the token or simply pass it on.

A centralized bus administrator is required to control the network communications.

Protocols that use this principle are either token ring or token bus protocols. Token ring protocols use a physical ring and messages pass through each station as it circulates around the ring. With token bus protocols, the token still circulates in a logical ring, but the physical network is a bus topology, with the result that failure of one station will not necessarily affect the network.

 

Figure 1.7

Illustration of token passing

Advantages of token passing

  • No data collisions can occur on the network.
  • Direct peer-to-peer communications are possible, faster than any of the previous techniques, with each station only having to wait for the token to pass by or be released by another station.
  • It results in a more efficient system for lightly loaded systems with each station having variable data transfer requirements.
  • Variations in data transfer requirements of the stations can be handled by the system.

Disadvantages of token passing

  • A communication failure to a specific device will only be detected when a specific response was requested from a station, and none was submitted. (This can be alleviated by background polling.)
  • The network is still dependent on a central communications controller.
  • The configuration of the network is quite complex.
  • Only semi-deterministic response times are obtained.
  • Unnecessary waiting times are still inherent to the technique (stations waiting for the token to pass).

 

1.4.5          CSMA/CD (carrier sense multiple access with collision detection)

With this technique, each station listens to the communication bus (multiple access), and sends when it has detected that the bus is idle (‘carrier sense’). If a collision occurs with another station, the transmission will be stopped, and after a random period the station will retry (collision detection).

All stations must be capable of supporting collision detection, collision avoidance, and recovery schemes. Methods for these vary considerably and thus have become a major issue in compatibility between different systems.

This technique is very efficient in maximizing the use of available bandwidth, and offer very flexible configuration options. It was designed to be used in a bus topology.

Response times are undeterministic, as network data load cannot be predetermined.

Ethernet communications are based on this technique.

CSMA/CD is illustrated in Figure 1.8.

 

Figure 1.8

Illustration of CSMA/CD

Advantages of CSMA/CD

  • Direct peer-to-peer communications are possible, faster than any of the previous techniques. This is the most suitable technique for peer-to-peer communications.
  • It results in a very efficient system for lightly loaded systems as well as still being efficient for heavily loaded systems.
  • Variations in data transfer requirements of the stations can be handled by the system.
  • Urgent requests for network access from a station can be handled instantly, except if another station already has access. Some protocols have priority access techniques.
  • No centralized bus controller is required.

Disadvantages of CSMA/CD

  • A communication failure to a specific device will only be detected when a specific response was requested from a station, and none was submitted (except if a SCADA system or centralised controller do background polling.)
  • The configuration of the network is very complex.
  • Non-deterministic response times are obtained.
  • Data collisions are an inherent drawback of the technique, requiring very involved data collision detection, avoidance, and recovery schemes.

 

1.5          The OSI model

The Open System Interconnection (OSI) model was developed by the International Standards Organisation (ISO) to provide a universally applicable structure for communication applications The OSI model consists of a seven-layer stack onto which the message (raw data) is modulated. The way in which the seven layers is applied (not all seven layers necessarily need to be used) actually defines the communication protocol. The OSI stack is illustrated in Figure 1.9.

 

 

Figure 1.9

Construction of OSI seven-layer stack

 

The concepts of the OSI layers are as follows. Each layer:

  • Performs unique and specific tasks
  • Provides service to the adjacent layer above
  • Uses the service of the adjacent layer below
  • Has knowledge of only its immediate adjacent layers

The functions of each layer are subsequently discussed, referring to Figure 1.8.

Physical layer

This layer provides the mechanical characteristics of the physical interface (the medium, e.g., copper, fiber optic, and the connectors), as well as the electrical characteristics (level and frequency of electrical/optical pulses).

Furthermore, the functional and procedural characteristics to activate, maintain, and deactivate the connection are defined.

Data link layer

The data link layer provides the synchronization (start/stop, length) and error control (detection and correction) for the information transmitted over the physical link. The information provided by the physical layer is used in defining this layer.

Network layer

This layer provides the means to route messages across networks and the ability to fragment large messages into frames that can be carried by the underlying network.

Transport layer

The transport layer provides end-to-end control and information interchange with the level of reliability that is required for the application (e.g., confirming connections, sequencing, etc.) This layer functions to liaise between the end-user(s) and the network.

Session layer

This layer supports the dialog requirements on the bus, determining who is allowed to talk, handling start/stop talking commands and communication relationships. In this context, application processes (AP) are defined, rather than physical stations.

Presentation layer

The presentation layer provides the interpretation and meaning of the information exchanged, in other words the coding or ‘language’ of the information.

Application layer

This layer directly serves the end-user, the AP, by providing the information to support the AP and manage the communication. This layer thus specifically defines the information and its context to the AP.

The specific application can be said to be directly on top of the application layer.

 

1.5.1          Communication using the stack

Figure 1.10  illustrates the way each layer of the OSI stack will add information to the raw data at the sender’s end, and strip away the added information at the receiver’s end to again arrive at the raw data, which is the actual required message.

 

Figure 1.10

Movement of data through the stack

 

A basic example will illustrate the process. (Note that this example is not the absolute rule, as every protocol will differ to a certain extent in the specific application of the layers. The example does illustrate the process, however.)

Example

A voltage value needs to be sent over a network. The value will be encoded into digital format by an analogue-to-digital converter, which is not part of the communications network. The AP in this instance is voltage measurement.

As Figure 1.10 shows, data will move down the OSI stack, each layer adding information to it. The application layer will add meaning to the digital data, which is only a value, by defining it as voltage, the type of voltage (e.g., line-to-line voltage), unit (V, mV, kV), etc. The presentation layer will then code this information into the appropriate language used, e.g., ASCII format. The session layer will initiate the transmission of this information onto the network, and the transport layer will control the transmission, ensuring reliability of the information and security of the transmission.

The network layer adds the routing and address information. The data link layer provides the synchronisation and error control bits, and the physical layer ensures that the complete frame at this stage is converted into the physical medium required for transmission, e.g., light pulses for a fibre-optic cable.

This information, which consists of a frame of digital bits, is now transmitted over the physical transmission media. The receiver receives this data and, in a process reversed to the one above, the ‘superficial’ information is stripped away until only the application data remain.

The critical importance that the sender and receiver process the data in exactly the same way can clearly be seen; otherwise the receiver will incorrectly interpret the information, or not even receive the information at all.

It will be noted that the full seven-layer stack is actually only required for network communications. For point-to-point type connections or for more basic networks using a communication technique where a master or bus administrator is present, the full seven stacks are not required. The enhanced protocol architecture (EPA) has been developed for this purpose, using a three-layer stack. The three layers basically correspond to layer 1, 2 and 7 of the seven-layer model (i.e., physical, data link and application layers). Some of the features of the presentation layer still required will then be added to the application layer, and network features required will be added to the data link layer.

This specific process by which the layers are added to the raw data actually defines the communication protocol. There are literally thousands of different ways of doing this, and thousands of different protocols have been used throughout the world at some stage or other. Initially protocols have not been clearly defined according to the OSI stack, and were developed according to the requirements of the specific manufacturer’s equipment. Proprietary protocols were at the order of the day, and different manufacturers’ equipment could as a rule not communicate to one another. Fortunately, certain protocols became widely accepted, and some manufacturers standardized on specific universally used protocols, e.g., MODBUS, DNP3.0 etc.

 

1.6          Communication Protocols

Some of the more popular and widely used communication protocols are listed in Table 1.1, with specific reference to protocols used in substations at present.

Table 1.1

Protocols used in substations

Protocol

Originally used by

Speed

Access principle

OSI layers

MODBUS

Gould-Modicon

19.2 kbps

Cyclic polling

1,2,7

SPABUS

ABB (exclusively)

19.2 kbps

Cyclic polling

1,2,7

DNP3.0

GE Harris

19.2 kbps

Cyclic polling (+)

1,2,7 (+)

IEC 60870-5

All

19.2 kbps

Cyclic polling

1,2,7

MODBUS +

Gould-Modicon

 

Token

1,2,7

PROFIBUS

Siemens

12 Mbps

Token

1,2,7

MVB

ABB

1.5 Mbps

TDM

1,2,7 (+)

FIP

Merlin-Gerin

2.5 Mbps

TDM

1,2,7

Ethernet + TCP/IP

All

10 Mbps

CSMA/CD

1–7

LON

ABB (exclusively)

1.25 Mbps

PCSMA/CD

1–7

UCA 2.0

GE

10 Mbps

CSMA/CD

1–7

 

1.7          Distributed Network Protocol 3.0 (DNP3)

DNP 3.0 is a specialised SCADA protocol initially developed by Harris Controls for electrical power utilities. It has since become an open protocol widely used for many power, gas, water, waste water and security applications around the world.

DNP3 uses the Application, Data Link and Physical layers, but adds some Transport functions. These are often referred to as the pseudo-transport layer, and are sometimes depicted as corresponding to the transport and network layers in a limited manner. This relationship is shown in the following drawing.

 

Figure 1.11

Relationship of EPA model to OSI 7 layer model

 

1.7.1          Application layer

The user data is the data arising from the user application. The user application can be visualized as a layer above the application layer, and could for example be a Human Machine Interface (HMI) program such as ‘Citect’ or ‘Intellution Fix’, or it could be an embedded program, such as a C+ application program. The data could be alarm and event data, digital status data, or even a data file such as a configuration file being passed from a master station to an RTU or an IED. On the other hand, in the case of many types of command being issued by a master station, there may be no data at all. A key point is that this data can be of any size. The total data size is not limited by the protocol.

The application layer initially forms the data into manageable sized blocks. These are called application service data units or ASDUs. The application layer then creates the application protocol data unit APDU by combining a header with the ASDU data. The application header is referred to as the application protocol control information, or APCI. This is either 2 bytes or 4 bytes in length, depending on whether the message is a request or a response. In the case of a command or other user request requiring no additional data, there is only a header, and no ASDU.

Depending on the total size of the data to be transmitted (the size of the ASDU), one or more APDUs are created. In the case that multiple APDUs are required, these are each termed Fragments. Whilst the number of fragments required representing an ASDU not limited, the size of each fragment is limited to a maximum of 2048 bytes.

 

1.7.2          Application message formats

Application messages are of two types, request and response. Each of these appears as one or more APDUs. Each APDU is made up of a header, which is termed the Application Protocol Control Information, and optional data, the ASDU.

 

Figure 1.12

Application message format

 

The request and response headers differ by one field. The response header includes an additional two-byte field designated Internal Indications (IIN). The content of the ASDU is not depicted in this drawing, but it is made up of data objects, each with an object header. These will be presented in detail later. For now the ASDU may be thought of merely as data.

 

1.7.3          Application control field

The application control field is the first byte of the control information, or APCI. It is used to control the communication flow. It has three bits or flags, plus a sequence number that is used to sequentially number fragments.

 

Figure 1.13

Application control field

 

Flow control is implemented by:

  • The FIR and FIN bits
  • The CON bit
  • Master and outstation response timeouts
  • Master and outstation retry counts (optional)

Using the following rules:

  • If CON = 1 a confirmation must be sent
  • Sequence number is incremented for each fragment
  • Sequence number rolls-over from 15 to 0, or 31 to 16
  • Response fragment has same sequence number as request fragment
  • If multiple request fragments, response starts at last request fragment number
  • Increment sequence number for each extra response fragment
  • A retransmitted response uses the original sequence number
  • Outstation must process one request before starting a second request

These are further detailed in the following subsections.

Message confirmations

  • If the CON bit is set, then a Confirmation is required
  • A confirmation response to a request has the same sequence number as the request
  • If two confirmation messages are received with same sequence number, ignore the second

Sequence numbers

  • Sequence number is 0–15 for requests, outstation responses, and the associated confirmations
  • Number rolls over from 15 to 0
  • Sequence number is 16–31 for unsolicited responses and confirmations
  • Confirmations have same sequence number as request or response
  • The first fragment of a response has the same sequence number as the request, or as the last fragment of a multi-fragment request
  • For a single fragment request re-try, the re-try has the same sequence number as the original request
  • For a multi-fragment request re-try, the re-try commences with the sequence number of the last fragment of the previous request

Identical sequence numbers

  • If two messages are received with the same sequence number, it usually means that the response message was not received by the other station. Re-transmit response
  • If two confirmation responses are received with the same sequence number, ignore the second response

 

1.7.4          Application function codes

The function code is the second byte of the application protocol control information. It follows the application control byte in both request headers from master stations, and response headers from outstations. The function code indicates what function is required to be performed.

Overview of function codes

 

 

Many of the functions need to identify specific data on which they operate. They do this with data object references that are included in the data within the ASDU, which follows the APCI header. In this section only the function codes themselves will be examined, with the referencing of the data objects being presented in following sections. In the function descriptions these data objects are referred to as ‘specified data objects’.

Request function codes

 

 

Transfer functions are those concerned with transferring defined data objects. These are the functions that acquire data from the outstation, or write control information to it.

 

 

 

The control functions are used to operate or change control points in an outstation. These may be control relay outputs, i.e. digital points, or analog setpoint values. These may be operated directly, with or without acknowledgment, or with the select before operate sequence.

The select before operate sequence is a security feature that is well known in the electrical supply industry. It provides an additional level of security to ensure against miss-operation arising from a corrupted message, or a human error such as selecting the wrong device from a group of similar devices shown on an HMI screen.

Select before operate sequence requires the following to occur:

  • Selection of the control points is made
  • The outstation responds with the identity and status of the selected points
  • The outstation starts a select-operate timer
  • The HMI displays the selected points differently, showing they have been selected
  • The operate function is sent for the selected points
  • The outstation will reject the operate message if the point identities do not match those of the previously selected points.
  • The outstation will de-select the points if the select-operate timer expires before the operate function is received

 

Freeze functions are typically used for the following:

  • Record system-wide state data at a common time (e.g. midnight)
  • Record status or value of specific point at regular intervals (e.g. for trending a flow rate)

 

The application control functions are coded in order of decreasing effect. The cold restart is a complete restart of the outstation, as if it had been de-powered and then repowered up. The warm restart may be used to reset the DNP3 application, but not necessarily do reset other application programs. Typically the warm restart is used to initialize its configuration and clear events stored in its buffers. Once either a cold or warm restart has been initiated, the master station should not attempt to communicate with the outstation until the restart time interval returned in the outstation’s response has elapsed.

The ‘initialize data to defaults’ could for example set up standard set points, and clear counters. The specific data objects to be initialized are identified in the request, but not the default values themselves. These are stored locally in the outstation, as fixed read-only data, or as parameters in non-volatile memory, for example.

 

The configuration referred to by these functions is the state of the parameters and settings that collectively determine the behavior of the outstation. It is not referring to a complete program or ‘configuration’ download. The save configuration function causes storing in a specified non-volatile memory location the settings that define the system’s configuration.

The enable and disable of unsolicited messages allows for a live change to this configuration aspect.

The assign class function allows for live assignment of data objects to classes. These are discussed later in the text. The effect of classes is to provide a broad means of referencing data, for example by allowing a read of all data in a particular class.

 

The delay measurement function is used immediately prior to performing a time setting by writing to the outstation clock. It is used over asynchronous serial links, for which the message transmission time is significant in comparison to the one-millisecond clock resolution. The outstation measures the time in milliseconds that it takes to turnaround the message, that is, the time from message receipt to sending the response to the master. The master station subtracts this time from the turnaround time it sees, to determine the time the messages spent in the communication system. It then divides that time by two to obtain an approximation of the one-way message delay from master station to outstation.

The record current Time function is used when performing a time setting over a LAN. In this case the transmission occurs essentially instantaneously, so no turnaround time measurement is needed. Both the master station and the outstation record the current values of their own clocks at the time this message is sent. Subsequently, the master sends its recorded time to the outstation, which calculates the time error from the difference between the recorded values.

Response functions

 

The response function codes apply for all messages from outstations, i.e. stations that are not designated as master stations. The only response these messages require (of the master station) is an optional confirmation on receipt by the master station.

 

1.7.5          Internal indications

 

Figure 1.14

Internal indications

The internal indications (IIN) field is a two-byte field that follows the function code in all responses. It is by using the internal indications that the outstation status is reported to the master following a request. Each bit in the field has a specific meaning, in accordance with the table. An outstation would have defined flags within its dynamic memory to correspond to the IIN field bits. These flags would then be copied in each response message. Descriptions of the detailed meaning of each bit are included in the following table.

 

 

 

1.7.6          The object header

In DNP3, the data is always comprised of two parts, object headers, and data objects. The object headers identify the data object types, and specific instances of those data that are being referenced by the message. These data may not necessarily be contained in the message; for example, a read request carries only the references identifying which data is required. The response to the read request will contain both the data identification and the data itself. The position of the object headers and data objects within the application protocol data unit, or message frame, is shown in the following drawing.

 

Figure 1.15

The object header

 

The ASDU is made up of one or more object header and data object fields, up to a maximum frame size of 2048 bytes including the frame header (the APCI).

The object header is between three and eleven bytes in length, and is made up of the object, qualifier and range fields. The object field is further subdivided into two bytes, which are the object group and object variation respectively. The range is between 0 and 8 bytes.

 

1.7.7          DNP Objects

The format of the object data is specified in the DNP Object Library. This specifies how many bits or bytes make up each object which belong to groups and have variations whether it has a time stamp etc.

A list of the object groups is shown in the table below. Full details of these and the object variations for each group is described in the DNP Object Library.

 

It can be seen from the table that the object groups are organized into decade ranges. Within each decade, there may be more than one object group. Each of these groups has its variations, making altogether a substantial number of individual objects.

Object variation zero

Object variation zero (0) is not used within any group, because this is reserved for a special purpose. When a master station specifies object variation zero in a request message, this defined to mean all variations of that particular object group. This allows the master station to obtain all object variations without identifying each one.

 

1.7.8          The qualifier and range fields

In the following sub-sections the operation of the qualifier and range fields are presented. After looking at the structure of these fields, and the meaning of the codes they contain, the different means of referencing data are presented. In the discussion, use is made of referencing ‘modes’. It is noted that the mode labels used here are not included within the DNP3 documentation, but are applied here to assist understanding of this complicated area.

It is noted that the reader may find point referencing in DNP3 somewhat difficult to grasp. This arises from the flexibility of referencing that has been provided for by the protocol. At the same time, it may be observed that although a number of different referencing modes and variations for each are defined in DNP3, in practice only a small number are generally used.

Purpose and structure

The qualifier and range fields follow the object field in the object header. These fields are used to identify the specific data points of each object group and variation that are being referred to. For example, this may simply be a range of consecutive points, in which case the start and stop point indexes will be included in the range field. Alternatively, a list of non-consecutive points may be required, and in this case the list of points must be provided separately. These cases, and others are all handled by the Qualifier and Range field values.

The qualifier and range fields are used both in request messages from master stations, and in response messages from outstations. For request messages, only identification of the data may be required. In response messages the data objects themselves may be included in the message.

The structure of the qualifier field is shown in the following diagram.

 

 

Figure 1.16

The qualifier field

The qualifier field is made up of two sub-fields. These are the qualifier code (or Q-code) and the index size (or I-size). The qualifier code value identifies the ways of referencing or identifying the data objects contained within messages. The index size sub-field specifies how many bits are used to reference the data (8, 16 or 32).

Range-index mode

The range-index mode is indicated by Q-codes 0,1 and 2.

In this mode the range field contains two numbers. These are the start and stop index values for the data objects.

Index values imply that in the outstation there is an index giving a one-to-one correspondence between the value of the index, and the actual locations within the device memory of the data objects. The use of indexes simplifies referencing of data objects because regardless of the object’s size, each consecutive number represents successive data objects. If the start and stop numbers are I1 and I2, then there are a total of I2-I1+1 data objects being referenced.

In the diagrams following, Q-code 0 is used, defining the range-index mode with eight-bit indexes. These can reference a maximum of 256 data objects. In the request message only the header is present. In the response message, the data objects follow the message.

In the response message only, it is possible to prefix each data object returned with an object size identifier. When this is desired, the I-size field is used to specify the size of the object size fields. This would only be required if the object sizes were variable within an object variation group. When object size fields are not required, the I-size field is set to zero, meaning the objects are packed in sequence without size fields. The diagrams following show the structure of the messages for each of these cases.

 

 

 

  • Non-zero Index-size is valid only with response messages (for this mode)
  • It is used when object size prefixes are required before each data object
  • The I-size codes 4, 5, and 6 are valid
  • They define 8, 16 and 32 bit object size fields respectively

 

 

 

 

1.7.9          The transport layer

The APDU from the application layer is interpreted purely as data to be transported by the transport layer. The transport layer breaks the message down into smaller units termed Transport Protocol Data Units or TPDUs. These are made up of a one-byte header, followed by a maximum of 249 bytes of data. So it will fit within one ‘Frame’ or LPDU at the Data Link layer.

 

The transport header

The single byte transport header contains two bits that identify the start and end of a sequence of frames (TPDUs), plus a six bit sequence counter, to allow reassembly of the message.

 

Figure 1.17

Transport header byte

The FIN and FIR bits identify whether this is a single frame message or where it fits into the message sequence.

 

1.7.10        The data link layer

This layer takes the TPDUs from the pseudo-transport layer and adds a 10-byte header to each. As the data link layer is also responsible for providing error detection and correction functions, error-checking codes are introduced here. A 16-bit cyclic redundancy code (CRC) is used. Each TPDU is converted to a frame of up to 292 bytes in length.

Data Link frame format

The frame format specifies a 10 byte header, followed optionally by up to 16 data blocks. The overall message size is limited to 292 bytes, which provides for a maximum data capacity of 250 bytes. Thus a fully packed frame will comprise the header plus 16 data blocks, with the last block containing 10 data bytes.

 

 

Figure 1.18

FT3 frame format

 

START:                          2 bytes: 0564 (hex)

LENGTH:                      Count of user data in bytes, plus 5, not counting CRC bytes

                                      This represents all data; excluding CRC codes following the LENGTH count byte. Its range is 0–255

CONTROL:                   Frame control byte.  See later section.

DESTINATION:             2 byte destination address (LSB, MSB)

SOURCE:                     2 byte source address (LSB, MSB)

CRC:                             2 byte Cyclic Redundancy Check code.

USER DATA:                 Each block has 16 bytes of user data. Last block has 1-16 as required.

 

Control byte

The control byte follows the start and length bytes in the frame format. It provides for control of data flow over the physical link, identifies the type, and indicates the direction. The interpretation of most of the control byte is dependent on whether the communication is a primary or a secondary message.

 

Figure 1.19

Control byte

DIR                    Direction

                          1 = A to B

                          0 = B to A

PRM                  Primary Message

                          1 = frame from primary (initiating station)

                          0 = frame from secondary (responding station)

FCB                   Frame Count Bit

FCV                   Frame Count Bit Valid

                          0 = ignore FCB

                         1 = FCV is valid

RES                  Reserved = 0

DFC                  Data Flow Control Bit. Set to 1 by secondary station if further send of  user data will cause buffer overflow.

FC                     Function Code

 

Direction bit

The DIR bit indicates the message direction between master and non-master stations. If a message is from a designated master station, this bit is set. Otherwise it is cleared.

Primary bit

The PRM bit is set if the frame is primary (initiating) or a secondary (responding). This is used directly in interpreting the function code. There are six valid function codes for primary frames, and five valid function codes for secondary frames.

Frame count bits

These are the frame count bit (FCB) and the frame count valid bit (FCV). These bits are only used for primary messages. The frame count bit is used to detect losses or duplication of frames to a secondary station. The frame count valid bit enables the use of the FCB. When the FCV bit is true, the FCB is toggled for each successful SEND–CONFIRM transaction between the same primary and secondary stations.

They work like this:

  • Following data link start-up or a failed transaction, a secondary station will not accept any primary SEND–CONFIRM frames with FCV=1 until a reset transaction is completed. This means it will only accept either a RESET Link or a RESET User Process command
  • After a secondary station receives a RESET Link frame from a primary and it responds with a CONFIRM, that link will be operational until a frame transmission error occurs
  • The secondary station will expect the next frame to contain FCV=1 and FCB=1
  • The next primary SEND-CONFIRM message will have FCV=1 and FCB=1. The secondary station will accept this as the FCB is valid and is set, as expected
  • Each subsequent primary SEND–CONFIRM message will have the FCB cleared or set in turn

Data flow control bit

The data flow control bit (DFC) is included in secondary frames. The secondary station will set DFC = 1 if a further SEND of user data will cause its buffer to overflow. On receipt of a frame with DFC = 1 a primary station will cease to send data, but will request link status until DFC = 0.

Data link function codes

The tables below show the detailed meanings for different values of the function code byte. The meanings are different depending on whether the message is a primary or a secondary transmission.

 

The following shortened version of the function codes is included in the sequence diagrams. The codes are preceded with a P or and S, representing primary or secondary codes.

 

 

1.7.11        The physical layer

The physical layer converts each frame into a bit stream over the physical media. In the original DNP3 documentation, a bit-serial asynchronous physical layer is specified. It calls for 8 bit data, 1 start bit, 1 stop bit, no parity, and RS-232C voltage levels and control signals.

 

1.7.12        Summary of DNP3 message build-up

The build-up of DNP3 messages has been shown from a top-down perspective to have the following features:

  • Application functions may or may not require the passage of data
  • Commands will often require no data
  • The Application layer parses the data into APDUs
  • The APDU maximum size is 2048 bytes
  • The Pseudo-Transport layer parses the APDU into smaller TPDUs
  • TPDU maximum size is 250 bytes
  • The Data Link layer adds headers and CRCs to form the LPDU
  • LPDU maximum size is 292 bytes, of which 250 bytes are data

 

1.7.13        DNP3 over a network

The idea of carrying DNP3 over a network environment involves encapsulation of the data frames from the DNP3 data link layer within the transport layer frames of the Internet protocol suite. That protocol stack then delivers the DNP3 data link layer frames to the destination location in place of the original DNP3 physical layer.

The following method has been recommended by the Technical Committee:

  • DNP3 shall use the Internet protocol suite to transport messages of LAN/WAN
  • Recommended physical link is Ethernet (others may be used however)
  • All devices shall support TCP and UDP
  • TCP must be used for WANs
  • TCP is strongly recommended for LANs
  • UDP may be used for highly reliable single segment LANs
  • UDP is necessary if broadcast messages are required
  • The DNP3 protocol stack shall be retained in full
  • Link layer confirmations shall be disabled

The resulting protocol stack is shown in the following diagram.

 

 

1.8          IEC 60870-5-101

1.8.1          Overview

The IEC 60870-5-101 protocol is defined with reference to layers 1,2 and 7 of the ISO 7-layer stack, also called the Enhanced Performance Architecture (EPA) model.

The protocol uses the octet representation of data. The frame is constructed as shown in Figure 1.20.

 

Figure 1.20

Frame construction

The ASDU is the data received from the application process. The ISO EPA model prescribes application protocol control information (APCI) to be added to the ASDU to form the application protocol data unit (APDU). However, this is not needed in the IEC 60870-5-101 protocol, hence the APDU is the same as the ASDU.

The data link layer adds the link protocol control information (LPCI) to the APDU to form the Link Protocol Data Unit (LPDU). This layer also prepares each data octet in the LPDU to be transmitted as an asynchronous serial character having one start bit (value=0), eight data bits (the data octet), one even parity bit and one stop bit (value=1).

Referring to Figure 1.20:

S = Start character

L = Length character

C = Link control character

A = Link address field

CS = Check sum character

E = End character

For up to 1.2 kb/s frequency shift keying (FSK) modulation is used, which is symmetrical and memory-less. It is suitable for most voice frequency analogue channels on base band transmission line, power line carrier, and radio communications media.

For speeds in excess of 1.2 kb/s, synchronous modems may be used.

Faster transmission, up to 19.2 kb/s, is also possible on directly connected data circuits using digital signal multiplexers.

 

1.8.2          Frame integrity

The LPDU frame provides a very high data integrity (IEC Integrity Class I2). There must be at least four bit errors in a received frame before an undetectable frame error is possible.

The parity check ensures that at least two bit errors in the contents of any character are required to cause an undetectable character error.

The sum check ensures that at least two characters with undetected errors are required to cause an undetectable check sum error. Thus a total of four bit errors are required to produce a received frame with a possible undetectable error.

 

1.8.3          Physical configuration

The protocol may be implemented in two physical configurations:

  1. a) A multi-drop (
Go to top