Professional Documents
Culture Documents
Understanding and Simulating The IEC 61850 Standard: Article
Understanding and Simulating The IEC 61850 Standard: Article
Understanding and Simulating The IEC 61850 Standard: Article
net/publication/32964907
CITATIONS READS
38 13,252
2 authors, including:
Roy Campbell
University of Illinois, Urbana-Champaign
616 PUBLICATIONS 15,954 CITATIONS
SEE PROFILE
Some of the authors of this publication are also working on these related projects:
Trustworthy Infrastructure for the Power Grid (TCIP) Information Trust Institute Illinois View project
All content following this page was uploaded by Roy Campbell on 11 November 2015.
2
Part Title
1 Introduction and Overview
2 Glossary
3 General Requirements
4 System and Project Management
5 Communication Requirements for Functions and Device Models
6 Configuration Description Language for Communication in Electronic Substations Related to IEDs
7 Basic Communication Structure for Substation and Feeder Equipment
8 Specific Communication Service Mapping (to MMS and to Ethernet)
9 Specific Communication Service Mapping (from Sampled Values)
10 Conformance Testing
3
ing with other servers like FTP server etc.. Each server
has one or more access points, which are the logical rep-
resentation of a NIC. When a client is to access data or
SMV GOOSE GSSE TimeSync ACSI service of the server, it should connect to an access point
Application
Domain
4
SERVER LOGICAL-DEVICE LOGICAL-NODE DATA OBJECT
LOGICAL-DEVICE LOGICAL-NODE DATA OBJECT DATA ATTRIBUTE
BasicType
2.6 Service model
Services provided by ACSI include querying object set, Figure 4: The data model of the IEC 61850
getting/setting data values, controlling system objects,
report manipulation, log manipulation, and other ser-
vices like file upload/download. Table 3 gives a list of 3. S validates the information provided by A and cre-
ACSI services defined in the IEC 61850 standard. ates a TPAA object, which provides a virtual view
All ACSI services are requested by applications and of S to A;
responded by servers. In order to request a service in 4. A requests subsequent services while S processes
a server, an application must first establish a valid two- the requests and responses with appropriate re-
party application association (TPAA) with the server. sponses defined in the IEC 61850 standard;
The TPAA maintains the session states and provides a
virtual view of the server to the application. A typical 5. A issues a Release request to S;
interaction procedure between an application A and a
6. S reclaims the TPAA of A and ends the session.
server S goes as follows:
The virtual view of server provided by a TPAA en-
1. A establishes a TCP connection with S; forces the access control policies set forth by the server.
This virtual view defines which objects in the server are
2. A “logs in” to S by requesting the Associate ser- visible and accessible to the application and what kinds
vice from S, providing authentication related infor- of service of those objects are accessible from the appli-
mation as parameters; cation. The concept of virtual view is very flexible and
5
SERVER: LOG-CONTROL-BLOCK:
GetServerDirectory GetLCBValues
ASSOCIATION: SetLCBValues
Associate QueryLogByTime
Abort QueryLogAfter
Release GetLogStatusValues
LOGICAL-DEVICE: GOOSE:
GetLogicalDeviceDirectory SendGOOSEMessage
LOGICAL-NODE: GetGoReference
GetLogicalNodeDirectory GetGOOSEElementNumber
GetAllDataValues GetGoCBValues
DATA: SetGoCBValues
GetDataValues GSSE:
SetDataValues SendGSSEMessage
GetDataDirectory GetGsReference
GetDataDefinition GetGSSEDataOffset
DATA-SET: GetGsCBValues
GetDataSetValues SetGsCBValues
SetDataSetValues MULTICAST-SAMPLE-VALUE-CONTROL-BLOCK:
CreateDataSet SendMSVMessage
DeleteDataSet GetMSVCBValues
GetDataSetDirectory SetMSVCBValues
Substitution: UNICAST-SAMPLE-VALUE-CONTROL-BLOCK:
SetDataValues SendUSVMessage
GetDataValues GetUSVCBValues
SETTING-GROUP-CONTROL-BLOCK: SetUSVCBValues
SelectActiveSG Control:
SelectEditSG Select
SetSGValues SelectWithValue
ConfirmEditSGValues Cancel
GetSGValues Operate
GetSGCBValues CommandTermination
BUFFERED-REPORT-CONTROL-BLOCK: TimeActivatedOperate
Report Time synchronization:
GetBRCBValues TimeSynchronization
SetBRCBValues FILE transfer:
UNBUFFERED-REPORT-CONTROL-BLOCK: GetFile
Report SetFile
GetURCBValues DeleteFile
SetURCBValues GetFileAttributeValues
the IEC 61850 standard does not place any restriction on choice for the internal implementation.
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 sys- 2.7 Reporting and logging
tems. The IEC 61850 standard provides an efficient mechanism
The ACSI interface defines an object-oriented inter- called reporting for applications to track changes to the
face for the applications but it does not require the inter- subscribed system objects. Instead of polling the data
nal implementation to be object-oriented. In actual fact, attribute values periodically, applications can group the
according to our experience on simulating the IEC 61850 interesting data attributes into a data set, and require the
protocol, object-oriented approach might not be a wise logical node hosting this data set report any changes to
6
the members of this data set. Theoretically a data set can plications to monitor changes to the data objects/data at-
contain data objects/data attributes from different logical tributes. GSE is designed for fast delivering notification
nodes, but data sets for reporting usually contain only of system object changes. There are two kinds of GSE,
the data objects/data attributes in the same logical node. generic object-oriented substation events (GOOSE) and
The procedure of report generation and transmission is generic substation state event (GSSE). GOOSE is used
under the control of an information block called report to exchange a wide range of common data while GSSE
control block (RCB). A RCB maintains the necessary in- is used to convey state change information. The GSE
formation to generate a report like which fields should mechanism shares a lot of similarities with reporting,
be included in the report, on what events a report should with the major difference that GSE is designed for fast
be generated, the sequence number of the current report, information exchange inside a substation while reporting
whether this RCB is enabled, etc.. is mainly used for sending notification from the server
A typical report generation and transmission proce- side to remote control centers or browsers.
dure is described as follows: Since real-time performance is critical for GSE mes-
sages, the message format and communication stack for
1. client application creates a data set containing all GSE transmission is very different from those for report-
the data objects and data attributes it concerns; ing. GSE messages are transmitted in binary format,
which provides shorter message body and higher mes-
2. client sets the parameters in a RCB, specifies the
sage encoding/decoding speed. In stead of using TCP
aforementioned data set as the source of the reports
or UDP as the underlying transport layer, GSSE uses its
(this step is called to “subscribe to a data set”) and
specific transport layer while GOOSE messages are sent
enables this RCB;
to the Ethernet link layer directly without going through
3. on any change to any member of the data set, the any transport layer or network layer.
logical node tests this change against the event list GSE also utilizes a publisher/subscriber mechanism to
of the RCB, and issues an internal event if any event transmit the messages. This mechanism is implemented
in the list gets matched; by the Ethernet multicast feature: the publisher sends the
GSE message to a specific multi-cast MAC address and
4. on receiving the internal event, the RCB stores this the subscribers pick up messages sent to this address, put
event for later sending; them into their local buffer for the local applications to
consume.
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 associ- 2.9 Communication network
ation under the direction of the parameters in the
RCB. The IEC 61850 standard defines a distributed system
consisting of interacting logical nodes, which are con-
Reports can be sent by either two-party application as- nected by logical connections. However, in order for this
sociation (TPAA) or multi-party application association distributed system to work correctly and intelligently,
(MPAA). TPAA is the association that can serve only one there must be some intelligent components inside this
client while MPAA can serve more than one client si- network. It is not hard to see that applications play this
multaneously. Reports generated on the request of the role. An interesting question is how to integrate appli-
Report service is sent by TPAA, whereas other reports cations into the interacting logical node network. We try
are sent by MPAA. Reporting uses a publisher/subscriber to answer this question by starting from the simple ACSI
mechanism: for every client, the server must assign an server-application network.
individual RCB to handle the report generation and trans- Figure 5 shows such a server-application network.
mission. Clearly, each server may serve several applications and
Logging is a mechanism to record the device events. vice versa. The dotted lines in Figure 5 refer to the com-
Logs are stored in the server and hosted by the corre- munication channels for reports and GSE messages. Al-
sponding logical device. Unlike reporting, every time a though there are no restrictions about the relationship be-
device event is triggered, the logical device merely saves tween report subscribers and report publishers, it is not
a log entry into the log database for later inquiries. true for GSE messages. The design of GSE has physical
concerns. GSE messages are sent from one IED to an-
other, thus the subscribers and the publishers should not
2.8 Generic substation event
reside in the same IED.
Besides reporting, the IEC 61850 standard defines To make things more clear, let us transform Figure 5
generic substation event (GSE) as another means for ap- into Figure 6, which shows the communication between
7
applications and logical nodes (we hid the communica-
App1 tion 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 connec-
tions: when a logical node sends a message to another
Server1
App2 logical node, it is virtually sending reports/GSE mes-
sages to the relevant applications; after necessary pro-
cessing of the reports/GSE messages, the applications is-
sue relevant requests to the other logical node, and vice
App3 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
Server2 important for both implementation and simulation of the
App4 IEC 61850 protocol.
LN11
tion is to inspect possible security vulnerabilities in the
App1
protocol, we refined the protocol to a version contain-
LN12 ing only data gathering/setting related ACSI services and
reporting services. Furthermore we simplified the data
App2
model by abstracting various data attribute types to string
Server2
and discarding the concept of functional constraint. Cur-
LN21
App3
rently, features of the IEC 61850 protocol supported by
LN22 our simulation model include two-party application asso-
ciation, data attribute, data object, data set, logical node,
App4
logical device, server, ACSI services, reporting and un-
Server3
buffered report control block.
LN31
LN32 App5
8
Server Application
The lock and unlock services are necessary be- To maintain the tree structure, one can implement
cause the IEC 61850 standard allows multiple accesses functional constraints as implicit data sets, and redirect
9
SimpleMsg Association Service API
+getValue()
+setValue()
J-Sim Communication
Msg Kernel Service API
Interface
+createSimple()
ComplexMsg
+createComplex()
+createList() +getAttribute()
+getType() +setAttribute()
+toXML() Figure 11: Implementation of the ACSI service
+parseXML()
ListMsg
+appendItem() ListMsg node is a node that represents a list, with each
+listItems()
member also a node. Our message tree is virtually a sim-
plified version of a XML DOM tree. Using such kind of
Figure 10: Internal message of the simulator message representation, we can easily pass the internal
events and service parameters/responses among different
internal objects.
the service requests to the appropriate object class us-
ing a dispatcher in the Association class. Instead of
maintaining an internal representation, we recommend 3.1.3 Service model
an other approach: using a lightweight database system
Figure 11 shows the internal architecture of the im-
as the backend storage support. This approach provides
plementation of the ACSI services on the server side.
several benefits:
Each active association is equipped with an instance of
1. A database system provides the most flexible and AssocAPI. AssocAPI provides the basic ACSI inter-
easiest way to maintain the appropriate tables and face for an association instance. On receiving the appli-
views. A database system incorporates all the nec- cation requests, the association instance invokes relevant
essary services to operate on the object tables, re- services provided by AssocAPI to complete the tasks.
ducing the complexity of maintaining an internal AssocAPI is supported both by the underlying kernel
data representation. services which provides the basic functions to complete
the ACSI service requests, and by the communication
2. A database system supports exclusive object ac- utilities, which talks to J-Sim [11], a network simulator.
cesses, so the engineer does not need to explicitly Instead of delivering the reports using multi-party ap-
perform lock and unlock operations. plication associations, we deliver them to the applica-
tions using the corresponding two-party application as-
3. Database systems are usually optimized for data sociations. The reporting procedure is rather straight-
storage and access, thus the database system ap- forward: when the value of a data attribute is changed
proach can give comparable real-time performance or updated, we check whether this operation satisfies the
against the internal data representation approach. trigger condition. If the trigger condition is met, the data
attribute issues an internal event to all the data sets mark-
3.1.2 Message representation ing it as a member and those data sets will forward the
internal event to the active report control blocks, which
Messages are used in two cases: as internal events and as
generate the reports and send them to the subscribing ap-
requests/responses of ACSI services. Although the IEC
plications. For the sake of simplification, we assume the
61850 standard defines manufacturing message specifi-
members of a data set are all data attributes in our simu-
cation (MMS) as its representation format for informa-
lation.
tion 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 3.2 Running the simulator
about the MMS standard is not freely available.
One can follow the following steps to create a simulation
Messages in our simulator are represented as at-
scenario and run a simulation:
tributed trees. There are three kinds of tree nodes (Fig-
ure 10): SimpleMsg, ComplexMsg and ListMsg. Step 1 create specialized classes based on the tem-
A SimpleMsg node is a leaf node containing a plate classes.
string value, which is used to represent a value. A The simulation package provides the necessary
ComplexMsg node is a node containing a collection of template classes from Server to DataAttr.
named attributes, the values of which are also nodes. A Users just need to derive a specialized class from
10
the appropriate template class and configure this -and h1/tpaa1/down@
class in the configure method as follows:
cp [$server createTPAA] h2/tpaa2
class DemoRelay connect -c h2/tcp/up@
extends LDevice { -and h2/tpaa2/down@
...
protected void configure() { Step 6 start J-Sim simulation.
declareLN(new DemoXCBR(‘‘XCBR0’’)); Finally, we can start the simulation of the IEC
declareLN(new DemoMMXU(‘‘MMXU0’’)); 61850 standard:
}
} set sim [attach_simulator .]
# start the association instances
Step 2 create applications based on the run h1-2
Application class. # then the application instances
Similar to the previous step, one needs to define run h3-4
his own specialized Application class:
11
[8] M C D ONALD , J. Substation automation. ied integration and avail-
ability of information. Power and Energy Magazine, IEEE 1, 2
(March and April 2003), 22–31.
[9] M ODBUS -IDA. Modbus application protocol specification
v1.1b, December 2006. http://www.modbus-ida.org/.
[10] S YSTEMS I NTEGRATION S PECIALISTS C OMPANY,
I. IEC 61850 evaluation kit CD-ROM. Software.
http://www.nettedautomation.com/solutions/
uca/evalkit/index.html.
[11] T YAN , H. Y., AND H OU , C. J. Javasim: A component-based
compositional network simulation environment. In Proceed-
ings of the Western Simulation Multiconference – Communica-
tion Networks And Distributed Systems Modeling And Simulation
(January 2001).
[12] UCA I NTERNATIONAL U SERS G ROUP, I. Introduction to
UCAversion
R 2.0. Tech. rep., Institute of Electrical and Elec-
tronics Engineerings, Inc., November 1999.
[13] U DREN , E., K UNSMAN , S., AND D OLEZILEK , D. Significant
substation communication standardization developments. In 2nd
Annual Western Power Delivery Automation Conference (WP-
DAC) Proceedings (April 2000).
12