IEC 61850 Standard In Details (part 2)

Continued from first part of article IEC 61850 Standard In Details (1)

Services provided by ACSI include querying object set, getting/setting data values, controlling system objects, report manipulation, log manipulation, and other services like file upload/download. Table 3 gives a list of ACSI services defined in the IEC 61850 standard.

All ACSI services are requested by applications and responded by servers. In order to request a service in a server, an application must first establish a valid two-party application association (TPAA) with the server. The TPAA maintains the session states and provides a virtual view of the server to the application.

A typical interaction procedure between an application A and a server S goes as follows:

1. A establishes a TCP connection with S;
2. A “logs in” to S by requesting the Associate service from S, providing authentication related information as parameters;
3. S validates the information provided by A and creates a TPAA object, which provides a virtual view of S to A;
4. A requests subsequent services while S processes the requests and responses with appropriate responses defined in the IEC 61850 standard;
5. A issues a Release request to S ; 6. S reclaims the TPAA of A and ends the session.

The virtual view of server provided by a TPAA enforces the access control policies set forth by the server. This virtual view defines which objects in the server are visible and accessible to the application and what kinds of service of those objects are accessible from the application. The concept of virtual view is very flexible and the IEC 61850 standard does not place any restriction on the access control policies of the server. One possible and relatively simple access control is the world-group-owner access control for files used in many UNIX systems.

Table 3: ACSI services

Reporting and logging

The IEC 61850 standard provides an efficient mechanism called reporting for applications to track changes to the subscribed system objects. Instead of polling the data attribute values periodically, applications can group the interesting data attributes into a data set, and require the logical node hosting this data set report any changes to the members of this data set. Theoretically a data set can contain data objects/data attributes from different logical nodes, but data sets for reporting usually contain only the data objects/data attributes in the same logical node.

The procedure of report generation and transmission is under the control of an information block called report control block (RCB). A RCB maintains the necessary information to generate a report like which fields should be included in the report, on what events a report should be generated, the sequence number of the current report, whether this RCB is enabled, etc..

A typical report generation and transmission procedure is described as follows:

1. client application creates a data set containing all the data objects and data attributes it concerns;
2. client sets the parameters in a RCB, specifies the aforementioned data set as the source of the reports (this step is called to “subscribe to a data set”) and enables this RCB;
3. on any change to any member of the data set, the logical node tests this change against the event list of the RCB, and issues an internal event if any event in the list gets matched;
4. on receiving the internal event, the RCB stores this event for later sending;
5. if the condition of sending the report is satisfied, the logical node collects necessary data, generates the report and sends it out to the client via the association under the direction of the parameters in the RCB.

Reports can be sent by either two-party application association (TPAA) or multi-party application association (MPAA). TPAA is the association that can serve only one client while MPAA can serve more than one client simultaneously. Reports generated on the request of the Report service is sent by TPAA, whereas other reports are sent by MPAA. Reporting uses a publisher/subscriber mechanism: for every client, the server must assign an individual RCB to handle the report generation and transmission.

Logging is a mechanism to record the device events. Logs are stored in the server and hosted by the corresponding logical device. Unlike reporting, every time a device event is triggered, the logical device merely saves a log entry into the log database for later inquiries.

Generic substation event

Besides reporting, the IEC 61850 standard defines generic substation event (GSE) as another means for applications to monitor changes to the data objects/data attributes. GSE is designed for fast delivering notification of system object changes. There are two kinds of GSE, generic object-oriented substation events (GOOSE) and generic substation state event (GSSE). GOOSE is used to exchange a wide range of common data while GSSE is used to convey state change information. The GSE mechanism shares a lot of similarities with reporting, with the major difference that GSE is designed for fast information exchange inside a substation while reporting is mainly used for sending notification from the server side to remote control centers or browsers.

Since real-time performance is critical for GSE messages, the message format and communication stack for GSE transmission is very different from those for reporting. GSE messages are transmitted in binary format, which provides shorter message body and higher message encoding/decoding speed. In stead of using TCP or UDP as the underlying transport layer, GSSE uses its specific transport layer while GOOSE messages are sent to the Ethernet link layer directly without going through any transport layer or network layer.
GSE also utilizes a publisher/subscriber mechanism to transmit the messages. This mechanism is implemented by the Ethernet multicast feature: the publisher sends the GSE message to a specific multi-cast MAC address and the subscribers pick up messages sent to this address, put them into their local buffer for the local applications to consume.

Communication network

The IEC 61850 standard defines a distributed system consisting of interacting logical nodes, which are connected by logical connections. However, in order for this distributed system to work correctly and intelligently, there must be some intelligent components inside this network. It is not hard to see that applications play this role. An interesting question is how to integrate applications into the interacting logical node network. We try to answer this question by starting from the simple ACSI server-application network.

Figure 5 shows such a server-application network. Clearly, each server may serve several applications and vice versa. The dotted lines in Figure 5 refer to the communication channels for reports and GSE messages. Although there are no restrictions about the relationship between report subscribers and report publishers, it is not true for GSE messages. The design of GSE has physical concerns. GSE messages are sent from one IED to another, thus the subscribers and the publishers should not reside in the same IED.

To make things more clear, let us transform Figure 5 into Figure 6, which shows the communication between applications and logical nodes (we hid the communication to server and logical devices). At this point, we can clearly see that logical connections between logical nodes are actually a mixture of several kinds of connections: when a logical node sends a message to another logical node, it is virtually sending reports/GSE messages to the relevant applications; after necessary processing of the reports/GSE messages, the applications issue relevant requests to the other logical node, and vice versa.

Thus we can deploy the application logic to the relevant logical nodes and get Figure 7 by abstracting away the applications. Being aware of this abstraction is important for both implementation and simulation of the IEC 61850 protocol.

Figure 5: Server-Application network

.

Figure 6: Logical node-application network

.

Figure 7: Logical node network

Simulating the IEC 61850

In this section, we talk about the design and implementation of a simulator of the IEC 61850 standard. Due to the challenges listed in Section 2.1, simulating the entire protocol is very difficult. Since the goal of our simulation is to inspect possible security vulnerabilities in the protocol, we refined the protocol to a version containing only data gathering/setting related ACSI services and reporting services. Furthermore we simplified the data model by abstracting various data attribute types to string and discarding the concept of functional constraint. Currently, features of the IEC 61850 protocol supported by our simulation model include two-party application association, data attribute, data object, data set, logical node, logical device, server, ACSI services, reporting and unbuffered report control block.

Design and implementation of the simulator

In order to inspect the IEC 61850 standard, we need a tool to simulate the protocol. Demo software of the protocol exists [10]. However, they are mostly provided by the IED manufacturer and are not freely available for research purposes. Kostic et al. proposed an implementation of ACSI [6]. The work of Kostic et al. focuses on implementing a set of application programming interface for device and application development, while we would like to build our own simulation tool for further study on the IEC 61850, especially on network security issues.
Our simulator consists of about 3,500 lines of Java code. Its components are divided into three major categories: the data model, internal message representation and the service model. Figure 8 shows the architecture of the simulator.

Figure 8: The IEC 61850 simulator architecture

Data model

The internal data model in the simulator is the same as the one defined in the IEC 61850 standard. All the IEC 61850 objects are instances of the I6Object class and are organized as a tree as shown in Figure 9. I6Object class provides a collection of services to manage the objects.

Figure 9: The IEC 61850 simulator data model

Table 4 lists some frequently used services.

Table 4: Major services of I6Object

The lock and unlock services are necessary because the IEC 61850 standard allows multiple accesses to the same object simultaneously. One would resolve this problem by sequentializing all the received requests, but since reports could be generated at the time when the related data objects are being updated, synchronization mechanism is still needed. One could implement lock as locking the whole object tree, but this would lead to severe performance problems, even dead locks. Our solution is to lock the whole subtree dominated by the locked object and mark all the ancestor nodes of that object as partly locked so that these ancestor nodes cannot be locked by other Associations.

Each kind of the IEC 61850 objects are implemented as a subclass of I6Object.    These subclasses provide templates to define the desired specialized classes. For example, in order to create a specialized logical device class, one just need to derive a subclass from the LDevice class and use the declareLN method to declare the member logical nodes in the configure function.

Using the IEC 61850 data model as the internal data model has two advantages: on the one hand, there is no need to map the internal data representation to the IEC 61850 data model in such an approach; on the other hand, we can deploy the implementation of the ACSI services to the relevant object classes thus achieve a simple object-oriented approach. However, our simulation experience shows such a simple internal data representation might not be a good choice because of the following two reasons:

1. The data model defined by the IEC 61850 is unnecessarily structured as a tree. Functional constraints present another view of data attributes in a logical node, breaking the tree structure maintained by data objects.
2. Some ACSI services are not easy to deploy to the specific object classes. One example is the CreateDataSet service, which should be implemented by the LogicalNode class or the Association class instead of the DataSet class.

To maintain the tree structure, one can implement functional constraints as implicit data sets, and redirect the service requests to the appropriate object class using a dispatcher in the Association class.

Figure 10: Internal message of the simulator

Instead of maintaining an internal representation, we recommend an other approach: using a lightweight database system as the backend storage support. This approach provides several benefits:

1. A database system provides the most flexible and easiest way to maintain the appropriate tables and views. A database system incorporates all the necessary services to operate on the object tables, reducing the complexity of maintaining an internal data representation.
2. A database system supports exclusive object accesses, so the engineer does not need to explicitly perform lock and unlock operations.
3. Database systems are usually optimized for data storage and access, thus the database system approach can give comparable real-time performance against the internal data representation approach.

Message representation

Messages are used in two cases: as internal events and as requests/responses of ACSI services. Although the IEC 61850 standard defines manufacturing message specification (MMS) as its representation format for information exchange, we would like to use another information representation format because on the one hand, MMS is relatively complicated and on the other hand, the details about the MMS standard is not freely available.

Messages in our simulator are represented as attributed trees. There are three kinds of tree nodes (Figure 10): SimpleMsg, ComplexMsg and ListMsg. A SimpleMsg node is a leaf node containing a string value, which is used to represent a value. A ComplexMsg node is a node containing a collection of named attributes, the values of which are also nodes.

Figure 11: Implementation of the ACSI service

A ListMsg node is a node that represents a list, with each member also a node. Our message tree is virtually a simplified version of a XML DOM tree. Using such kind of message representation, we can easily pass the internal events and service parameters/responses among different internal objects.

Service model

Figure 11 shows the internal architecture of the implementation of the ACSI services on the server side. Each active association is equipped with an instance of AssocAPI. AssocAPI provides the basic ACSI interface for an association instance. On receiving the application requests, the association instance invokes relevant services provided by AssocAPI to complete the tasks. AssocAPI is supported both by the underlying kernel services which provides the basic functions to complete the ACSI service requests, and by the communication utilities, which talks to J-Sim [11], a network simulator.

Instead of delivering the reports using multi-party application associations, we deliver them to the applications using the corresponding two-party application associations. The reporting procedure is rather straight-forward: when the value of a data attribute is changed or updated, we check whether this operation satisfies the trigger condition. If the trigger condition is met, the data attribute issues an internal event to all the data sets marking it as a member and those data sets will forward the internal event to the active report control blocks, which generate the reports and send them to the subscribing applications. For the sake of simplification, we assume the members of a data set are all data attributes in our simulation.

.

SOURCE:

• Understanding and Simulating the IEC 61850 Standard by Yingyi Liang & Roy H. Campbell, Department of Computer Science University of Illinois at Urbana-Champaign

.

Related articles

• IEC 61850 Standard In Details (1)
• Benefits Of IEC 61850
• KNX Architecture
• Testing performances of IEC 61850 GOOSE messages
• Testiranje performansi IEC 61850 GOOSE poruka