Transcript
Page 1: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Guidelines for Implementing SubstationAutomation Using IEC61850, theInternational Power System InformationModeling Standard

Technical Report

Page 2: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 3: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

EPRI Project Manager L. van der Zel

EPRI • 3412 Hillview Avenue, Palo Alto, California 94304 • PO Box 10412, Palo Alto, California 94303 • USA 800.313.3774 • 650.855.2121 • [email protected] • www.epri.com

Guidelines for Implementing Substation Automation Using IEC61850, the International Power System Information Modeling Standard

1008688

Final Report, December 2004

Page 4: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES

THIS DOCUMENT WAS PREPARED BY THE ORGANIZATION(S) NAMED BELOW AS AN ACCOUNT OF WORK SPONSORED OR COSPONSORED BY THE ELECTRIC POWER RESEARCH INSTITUTE, INC. (EPRI). NEITHER EPRI, ANY MEMBER OF EPRI, ANY COSPONSOR, THE ORGANIZATION(S) BELOW, NOR ANY PERSON ACTING ON BEHALF OF ANY OF THEM:

(A) MAKES ANY WARRANTY OR REPRESENTATION WHATSOEVER, EXPRESS OR IMPLIED, (I) WITH RESPECT TO THE USE OF ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT, INCLUDING MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, OR (II) THAT SUCH USE DOES NOT INFRINGE ON OR INTERFERE WITH PRIVATELY OWNED RIGHTS, INCLUDING ANY PARTY'S INTELLECTUAL PROPERTY, OR (III) THAT THIS DOCUMENT IS SUITABLE TO ANY PARTICULAR USER'S CIRCUMSTANCE; OR

(B) ASSUMES RESPONSIBILITY FOR ANY DAMAGES OR OTHER LIABILITY WHATSOEVER (INCLUDING ANY CONSEQUENTIAL DAMAGES, EVEN IF EPRI OR ANY EPRI REPRESENTATIVE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES) RESULTING FROM YOUR SELECTION OR USE OF THIS DOCUMENT OR ANY INFORMATION, APPARATUS, METHOD, PROCESS, OR SIMILAR ITEM DISCLOSED IN THIS DOCUMENT.

ORGANIZATION(S) THAT PREPARED THIS DOCUMENT

Utility Consulting International (UCI)

ORDERING INFORMATION

Requests for copies of this report should be directed to EPRI Orders and Conferences, 1355 Willow Way, Suite 278, Concord, CA 94520, (800) 313-3774, press 2 or internally x5379, (925) 609-9169, (925) 609-1310 (fax).

Electric Power Research Institute and EPRI are registered service marks of the Electric Power Research Institute, Inc. EPRI. ELECTRIFY THE WORLD is a service mark of the Electric Power Research Institute, Inc.

Copyright © 2004 Electric Power Research Institute, Inc. All rights reserved.

Page 5: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

iii

CITATIONS

This report was prepared by

Utility Consulting International (UCI) 20370 Town Center Lane, Suite 211 Cupertino, CA 95014

Principal Investigators F. Cleveland R. Ehlers

This report describes research sponsored by EPRI.

The report is a corporate document that should be cited in the literature in the following manner:

Guidelines for Implementing Substation Automation Using IEC61850, the International Power System Information Modeling Standard, EPRI, Palo Alto, CA: 2004. 1008688.

Page 6: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 7: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

v

PRODUCT DESCRIPTION

This report provides guidelines for substation planners, project managers, substation engineers, information technologists, and substation integrators on informational issues related to substation automation (SA) when IEC61850 standards are used.

Results and Findings Substation automation is far more than just the automation of substation equipment. It is the first step toward the creation of a highly reliable, self-healing power system that responds rapidly to real-time events with appropriate actions and that supports the planning and asset management necessary for cost-effective operations. Automation does not simply replace manual procedures—it permits the power system to operate in an entirely new way based on accurate information provided in a timely manner to the decision-making applications and field devices.

Substation automation would not have been feasible a few years ago. Communication technologies simply were not available to handle the kinds of demands imposed by the complexity of SA requirements. However, communication standards have now been developed that can address many of these demands. In particular, the international power system information modeling standard IEC61850 provides solutions to automation issues using state-of-the-art object-modeling technologies. IEC6185 also provides the key capabilities needed for the increasingly sophisticated requirements of data management.

Challenges and Objectives This report provides guidelines on the informational issues related to SA in regard to the use of IEC61850 standards. Substation automation is a new challenge for the utility industry. These guidelines provide the overall vision as well as the specific steps that should be taken for successful implementation of this new enabling capability.

The guidelines also build on the work undertaken in E2I’s (one of EPRI’s family of companies) IntelliGrid Architecture project by using specific examples from SA functions to show how these functional requirements drive the need for the capabilities provided by IEC61850.

This guideline is organized by the different stages of SA—planning, specifying, implementing, deploying, and operations/maintenance. It is expected that most readers will begin with the report overview and the vision for substation automation (Sections 1 and 2) as an introduction to the broader issues of power system management, information technologies, and SA. Readers can then refer to those report sections that meet their specific areas of interest. The document, therefore, is designed so that each section can stand alone.

Page 8: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

vi

Applications, Values, and Use It is not easy to understand how the various parts of the IEC61850 documents work together. Therefore, this guideline is designed to help the users of SA automation by describing the IEC61850 standards in more user-friendly terms and by identifying the available options for automation. Even though most users will rely on equipment vendors to implement the actual IEC61850 standards, it is important to have a basic understanding of the options available and of how the various object models work together.

Additional capabilities are being added to the IEC61850 series of standards, including configuration language standards and conformance test planning. When these standards are finalized, they should be included in future updates to these guidelines.

EPRI Perspective Organizations such as the IEC do excellent work in developing international standards. EPRI plays a key role in translating those standards into understandable language and discussing the different options and issues related to the standards.

E2I sponsored the development of the IntelliGrid Architecture, which defines the strategic vision for developing the vital communications and information infrastructure required for reliable, efficient, and secure power system operations. E2I recommends international standards and best practices to meet those requirements. One of the key recommendations is the use of IEC61850 in substation automation.

Approach These guidelines were developed to describe the overall vision of SA to help ensure that the paradigm shift provided by this new enabling technology is appreciated by the utility industry. The guidelines describe the steps required in each phase of implementation with IEC61850.

Keywords IEC61850 IntelliGrid architecture Substation automation Utility communications architecture (UCA)

Page 9: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

vii

CONTENTS

1 AN OVERVIEW OF IEC61850 SUBSTATION AUTOMATION GUIDELINES...................... 1-1 1.1 Identifying the Purpose, Scope, and Audience for IEC61850 Substation

Automation Guidelines.............................................................................................. 1-1 1.1.1 Purpose............................................................................................................ 1-1 1.1.2 Scope ............................................................................................................... 1-1 1.1.3 Audience .......................................................................................................... 1-1

1.2 The Vision for Substation Automation ....................................................................... 1-4 1.3 Project Management for Substation Automation Projects.......................................... 1-5 1.4 Developing Functional Requirements for Substation Automation Equipment,

Systems, and Applications........................................................................................ 1-6 1.5 Specifying Functional Requirements and IEC61850 for Substation Automation ........ 1-7 1.6 Implementing IEC61850 in Equipment and Systems................................................1-10 1.7 Installing IEC61850 Equipment and Systems in Substations....................................1-11 1.8 Key Points................................................................................................................1-11

2 THE VISION FOR SUBSTATION AUTOMATION ............................................................... 2-1 2.1 Purpose and Audience for This Section .................................................................... 2-1 2.2 Thinking Outside the Box – Paradigm Shift of Substation Automation....................... 2-1 2.3 Enabling Information Technologies That Enhance Substation Automation

Capabilities............................................................................................................... 2-3 2.4 The Benefits of Substation Automation for Different Users........................................ 2-5 2.5 Information Technology Requirements That Drive Substation Automation

Designs .................................................................................................................... 2-7 2.5.1 IntelliGrid Architecture Framework Contents..................................................... 2-9 2.5.2 Abstract Modeling............................................................................................2-10 2.5.3 Information Security Planning and Management..............................................2-13 2.5.4 Data Management ...........................................................................................2-15 2.5.5 System and Application Management..............................................................2-17 2.5.6 Network Management......................................................................................2-18

Page 10: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

viii

2.5.7 Telecommunications Management ..................................................................2-20

3 PROJECT MANAGEMENT FOR SUBSTATION AUTOMATION........................................ 3-1 3.1 Purpose and Audience for This Section .................................................................... 3-1

3.1.1 Purpose............................................................................................................ 3-1 3.1.2 Audience .......................................................................................................... 3-1

3.2 The Big Picture ......................................................................................................... 3-1 3.2.1 Why a New Approach Is Necessary.................................................................. 3-1 3.2.2 The Importance of Project Management........................................................... 3-2 3.2.3 Project Scenarios ............................................................................................. 3-2

3.2.3.1 Pilot Projects .............................................................................................. 3-3 3.2.3.2 Production Deployments............................................................................. 3-3

3.2.4 Strategic Approaches ....................................................................................... 3-3 3.2.4.1 Objectives and Priorities ............................................................................. 3-4 3.2.4.2 Migration Strategy ...................................................................................... 3-5

3.3 Project Organization.................................................................................................. 3-5 3.3.1 Identifying a Champion..................................................................................... 3-5 3.3.2 Selecting a Project Manager............................................................................. 3-5 3.3.3 Involving Stakeholders...................................................................................... 3-5 3.3.4 Creating Project Teams.................................................................................... 3-6

3.4 The Project Team...................................................................................................... 3-7 3.4.1 Project Management Team............................................................................... 3-7

3.4.1.1 Team Composition ..................................................................................... 3-8 3.4.1.2 Responsibilities .......................................................................................... 3-8

3.4.2 Functional Requirements Team........................................................................ 3-8 3.4.2.1 Functional Requirements Team Composition ............................................. 3-9 3.4.2.2 Responsibilities of the Functional Requirements Team............................... 3-9

3.4.3 System Design Team ......................................................................................3-10 3.4.3.1 System Design Team Composition............................................................3-11 3.4.3.2 System Design Team Planning Responsibilities ........................................3-11 3.4.3.3 System Design Team Implementation Responsibilities..............................3-15

3.4.4 Technology Team............................................................................................3-19 3.4.4.1 Technology Team Composition .................................................................3-20 3.4.4.2 Technology Team Responsibilities ............................................................3-20

3.5 The Project Management Roadmap.........................................................................3-20

Page 11: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

ix

3.5.1 The Project Charter – Vehicle for Launching the Project..................................3-20 3.5.1.1 Purpose and Objectives.............................................................................3-21 3.5.1.2 Critical Success Factors and Risks............................................................3-21 3.5.1.3 Deployment Sites ......................................................................................3-21 3.5.1.4 Expected Benefits......................................................................................3-21 3.5.1.5 Constraints ................................................................................................3-22

3.5.2 Management Dynamics ...................................................................................3-22 3.5.2.1 Building Teamwork ....................................................................................3-22 3.5.2.2 Delegation .................................................................................................3-23 3.5.2.3 Fostering Good Communication and Problem Solving...............................3-23 3.5.2.4 Maintaining Project Documents .................................................................3-23 3.5.2.5 Training .....................................................................................................3-24 3.5.2.6 Tracking Progress, Budgets, Schedules, and Resources ..........................3-24 3.5.2.7 Evaluating Project Work ............................................................................3-25 3.5.2.8 Arbitration..................................................................................................3-25

3.5.3 Benefit/Cost Analysis.......................................................................................3-26 3.5.4 Risk Assessment and Risk Management.........................................................3-27

3.5.4.1 Risks for a Project in Progress...................................................................3-28 3.5.4.2 Risks After a System Has Been Placed Into Service .................................3-29 3.5.4.3 A Description of the Risk Management Process ........................................3-29 3.5.4.4 Using a Formal Process ............................................................................3-29 3.5.4.5 Risk Mitigation Techniques........................................................................3-30

3.6 The Roadmap to Design the Desired Substation......................................................3-31 3.6.1 Basic Concepts................................................................................................3-32 3.6.2 Business Processes ........................................................................................3-34

3.6.2.1 Describing a Business Process .................................................................3-34 3.6.2.2 Principles for Documenting Business Processes .......................................3-34 3.6.2.3 A Practical Methodology for Documenting Business Processes ................3-35

3.6.3 Substation Functions .......................................................................................3-37 3.6.4 Software Application Modules..........................................................................3-38 3.6.5 Application Functions.......................................................................................3-38 3.6.6 Logical Nodes and Information Flow................................................................3-39

3.7 Project Documents...................................................................................................3-39 3.7.1 Administrative Documents ...............................................................................3-40

Page 12: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

x

3.7.1.1 Project Request.........................................................................................3-40 3.7.1.2 Project Charter ..........................................................................................3-40 3.7.1.3 Statements of Work ...................................................................................3-41 3.7.1.4 Contracts...................................................................................................3-41 3.7.1.5 Budgets .....................................................................................................3-41 3.7.1.6 Schedules..................................................................................................3-41

3.7.2 Working Project Documents – Project Deliverables in Process........................3-42 3.7.2.1 Functional Requirements...........................................................................3-42 3.7.2.2 Design Plans .............................................................................................3-43 3.7.2.3 Design Implementation..............................................................................3-43

3.7.3 Other Documents Related to System Operation ..............................................3-43 3.7.4 Tracking Documents........................................................................................3-44

3.7.4.1 Progress Reports.......................................................................................3-44 3.7.4.2 E-mails and Correspondence ....................................................................3-44 3.7.4.3 Meeting and Teleconference Minutes ........................................................3-44 3.7.4.4 Project Notes.............................................................................................3-44

3.7.5 Vendor Product Material ..................................................................................3-44 3.7.6 Reference Documents.....................................................................................3-45

4 DEVELOPING FUNCTIONAL REQUIREMENTS FOR SUBSTATION AUTOMATION EQUIPMENT, SYSTEMS, AND APPLICATIONS................................................................... 4-1

4.1 Purpose and Audience for This Section .................................................................... 4-1 4.1.1 Purpose............................................................................................................ 4-1 4.1.2 Audience .......................................................................................................... 4-1

4.2 Power System Functions That Drive the Requirements for Substation Automation ............................................................................................................... 4-1

4.2.1 Transmission Planning Functions ..................................................................... 4-4 4.2.2 Normal Real-Time Transmission Operation ...................................................... 4-7 4.2.3 Emergency Real-Time Transmission Operation...............................................4-11 4.2.4 Post Real-Time Transmission Operation .........................................................4-16

4.3 Examples of Key Substation Automation Power System Functions Based on the IntelliGrid Architecture .......................................................................................4-20

4.3.1 Data Acquisition and Control (DAC) Functions Within Substation Automation......................................................................................................4-20

4.3.2 IntelliGrid Environments...................................................................................4-20

Page 13: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xi

4.3.3 Substation High-Speed DAC – Direct Power Equipment Monitoring and Control in the Deterministic, Rapid-Response Intra-Substation Environment....................................................................................................4-23

4.3.3.1 Description of Function – Direct Power Equipment Monitoring and Control ............................................................................................................. 4-23

4.3.3.2 IntelliGrid Environment of the Function – Deterministic Rapid Response Intra-Substation Environment ...................................................4-23

4.3.3.3 Requirements Defining the Deterministic Rapid Response Intra-Substation Environment ............................................................................4-24

4.3.3.4 Recommended Technologies for This Environment...................................4-25 4.3.4 Substation IED Interactions in the Deterministic, Rapid-Response Intra-

Substation Environment and the Critical Intra-Substation Environment...........4-26 4.3.4.1 Description of the Function – Local Interactions Among Intelligent

Electronic Devices.....................................................................................4-26 4.3.4.2 Environments of the Function – Deterministic Rapid Response Intra-

Substation Environment and Critical Operations Intra-Substation Environment..............................................................................................4-27

4.3.4.3 Requirements Defining the Critical Operations Intra-Substation Environment..............................................................................................4-28

4.3.4.4 Recommended Standards and Technologies for the Critical Operations Intra-Substation Environment..................................................4-29

4.3.5 SCADA DAC Functional Requirements in the Critical DAC Environment.........4-32 4.3.5.1 Description of the Function – DAC Functional Requirements for

SCADA Systems.......................................................................................4-32 4.3.6 Energy Management System Information Requirements in the Intra-

Control Center Environment............................................................................4-33 4.3.6.1 Description of the Function – EMS Operations ..........................................4-33

4.3.6.2 IntelliGrid Environment of the Function – Intra-Control Center Environment..............................................................................................4-35

4.3.6.3 Requirements Defining the Intra-Control Center Environment ...................4-36 4.3.6.4 Recommended Standards and Technologies for the Intra-Control

Center Environment ..................................................................................4-37 4.3.7 Protection Engineering Information Requirements in the Critical and

Noncritical Operations DAC Environments......................................................4-40 4.3.7.1 Description of the Function – Protection Engineering ................................4-40 4.3.7.2 IntelliGrid Environment of the Function – Critical Intra-Substation and

Critical Operations DAC Environments......................................................4-41 4.3.7.3 Requirements Defining the Critical Operations DAC Environment .............4-41 4.3.7.4 Recommended Standards and Technologies for the Critical

Operations DAC Environment ...................................................................4-42

Page 14: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xii

4.3.8 Mobile Operations and Maintenance Activity Requirements ............................4-42 4.3.8.1 Description of the Function – Mobile Operations and Maintenance

Activity Requirements................................................................................4-42 4.3.8.2 IntelliGrid Environment of the Function – Field Equipment

Maintenance Environment.........................................................................4-43 4.3.8.3 Requirements Defining the Field Equipment Maintenance

Environment..............................................................................................4-43 4.3.8.4 Recommended Standards and Technologies for the Field Equipment

Maintenance Environment.........................................................................4-44

5 SPECIFYING FUNCTIONAL REQUIREMENTS AND IEC61850 FOR SUBSTATION AUTOMATION........................................................................................................................ 5-1

5.1 Purpose and Audience for This Section .................................................................... 5-1 5.1.1 Purpose............................................................................................................ 5-1 5.1.2 Audience .......................................................................................................... 5-1

5.2 Model-Based Development of Functional Requirements ........................................... 5-2 5.2.1 Problems of Historical Concepts and Technologies .......................................... 5-2 5.2.2 Benefits of Modeling Technologies ................................................................... 5-3

5.3 Use of Abstract Modeling Tools to Develop Requirements........................................ 5-4 5.3.1 Abstract Modeling............................................................................................. 5-4 5.3.2 Information Exchange Interoperability............................................................... 5-4 5.3.3 Interworkability.................................................................................................. 5-4 5.3.4 Interchangeability ............................................................................................. 5-5

5.4 Unified Modeling Language (UML)............................................................................ 5-5 5.4.1 Abstract Modeling in UML................................................................................. 5-5 5.4.2 Use Cases........................................................................................................ 5-6 5.4.3 UML Methodology ............................................................................................ 5-9

5.5 IEC61850 Information Exchange Configurations......................................................5-11 5.6 Procedure for Specifying IEC61850 .........................................................................5-12

5.6.1 Step 1 – Determine Functional Requirements .................................................5-13 5.6.2 Step 2 – Determine IEC61850 Logical Nodes and the Available Data .............5-14 5.6.3 Step 3 – Determine IEC61850 Data Exchanges Within the Substation............5-14 5.6.4 Step 4 – Determine IEC61850 Data Exchanges With External Systems..........5-15 5.6.5 Step 5 – Specify Conformance Testing............................................................5-15 5.6.6 Step 6 – Specify IEC61850 Configuration Tools ..............................................5-15

Page 15: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xiii

6 IMPLEMENTING IEC61850 IN EQUIPMENT AND SYSTEMS............................................ 6-1 6.1 Purpose and Audience for This Section .................................................................... 6-1

6.1.1 Purpose............................................................................................................ 6-1 6.1.2 Audience .......................................................................................................... 6-1

6.2 IEC TC57 Architecture and the Components of the IEC61850 Standard................... 6-1 6.2.1 Outline of the IEC61850 Document .................................................................. 6-3 6.2.2 Object Modeling................................................................................................ 6-4

6.2.2.1 Object Model Structure............................................................................... 6-5 6.2.2.2 Object Model Naming ................................................................................. 6-7

6.2.3 Communication Services Modeling................................................................... 6-8 6.2.3.1 ACSI – Abstract Communication Services Interface ................................... 6-9 6.2.3.2 Implementation Settings and HMI..............................................................6-13

6.2.4 Mapping to Protocol Profiles ............................................................................6-14 6.2.5 Substation Configuration Language Modeling .................................................6-15 6.2.6 Power System Configuration Modeling ............................................................6-16

6.3 Implementing IEC61850 Object Models ...................................................................6-18 6.3.1 Electric Power Measurements .........................................................................6-19 6.3.2 Switches, Circuit Breakers, and Reclosers ......................................................6-20 6.3.3 Transformers and Tap Changers.....................................................................6-22 6.3.4 Capacitor Bank Switch Logical Nodes .............................................................6-23 6.3.5 Protection Logical Nodes.................................................................................6-24

6.3.5.1 Typical Protection Logical Nodes for a Transformer Relay ........................6-28 6.3.5.2 Typical Protection Logical Nodes for a Line Distance Relay ......................6-29 6.3.5.3 Typical Protection for a Feeder Relay........................................................6-30 6.3.5.4 Typical Protection for a Generator Relay ...................................................6-31 6.3.5.5 Typical Protection for a Bus Differential Relay ...........................................6-32 6.3.5.6 Typical Protection for a Motor Relay..........................................................6-32

6.3.6 Disturbance Recording Logical Nodes.............................................................6-33 6.3.7 Metering Logical Nodes...................................................................................6-34 6.3.8 Archiving, HMI, and Alarming Logical Nodes ...................................................6-34 6.3.9 Power Quality ..................................................................................................6-34

6.4 Implementing Communications Service Models in Servers and Clients....................6-35 6.4.1 Basic Conformance Statement ........................................................................6-35

Page 16: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xiv

6.4.2 ACSI Models Conformance Statement ............................................................6-38 6.4.3 ACSI Service Conformance Statement............................................................6-44

7 INSTALLING IEC61850 EQUIPMENT AND SYSTEMS IN SUBSTATIONS........................ 7-1 7.1 Purpose and Audience for This Section .................................................................... 7-1

7.1.1 Purpose............................................................................................................ 7-1 7.1.2 Audience .......................................................................................................... 7-1

7.2 Evaluating and Selecting Equipment and Suppliers .................................................. 7-1 7.2.1 Support for Functional Requirements ............................................................... 7-1

7.2.1.1 General ...................................................................................................... 7-2 7.2.1.2 Application Functionality ............................................................................. 7-3 7.2.1.3 Product Tools ............................................................................................. 7-3

7.2.2 Support for Substation Automation Communication Objectives ........................ 7-3 7.2.2.1 Network Support......................................................................................... 7-4 7.2.2.2 Support for Utility-Specific Object Models................................................... 7-4 7.2.2.3 Support for Utility-Specific Communication Services .................................. 7-4

7.2.3 Support for Collateral Communications ............................................................ 7-4 7.2.4 Technical Support and Commitment................................................................. 7-4

7.3 Monitoring and Managing System Development ....................................................... 7-5 7.3.1 Project Management ........................................................................................ 7-5 7.3.2 Meetings........................................................................................................... 7-6 7.3.3 Change Order Management ............................................................................. 7-6

7.4 Evaluation Process ................................................................................................... 7-7 7.5 Statement of Work .................................................................................................... 7-8 7.6 System Integration and Testing................................................................................. 7-8

7.6.1 Specification ..................................................................................................... 7-9 7.6.2 Vendor Selection .............................................................................................. 7-9 7.6.3 Certification ...................................................................................................... 7-9 7.6.4 Factory Acceptance Test .................................................................................. 7-9 7.6.5 Site Acceptance Test.......................................................................................7-10 7.6.6 What Is Tested and When ...............................................................................7-10 7.6.7 Conformance Testing of OM-SA Products.......................................................7-11 7.6.8 Test Plan Outline .............................................................................................7-13

7.7 IEC61850 Testing ....................................................................................................7-14 7.7.1 Key Testing Definitions ....................................................................................7-14

Page 17: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xv

7.7.2 Conformance Test Process .............................................................................7-15 7.7.3 Standard Test Procedure Groups ....................................................................7-16 7.7.4 Control Test Example ......................................................................................7-16 7.7.5 Sample Test Cases .........................................................................................7-19

7.8 System Maintenance and Support............................................................................7-21

A GLOSSARY/ACRONYMS...................................................................................................A-1

B A BRIEF HISTORY OF UTILITY INDUSTRY STANDARDS DEVELOPMENT ...................B-1

C LISTING OF KEY INFORMATION......................................................................................C-1

Page 18: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 19: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xvii

LIST OF FIGURES

Figure 1-1 Audience for Each Section of the SA Guidelines................................................... 1-3 Figure 1-2 Two Infrastructures Must Be Managed in the Future.............................................. 1-5 Figure 1-3 Organization of Project Teams............................................................................... 1-6 Figure 1-4 IntelliGrid Architecture Framework ......................................................................... 1-7 Figure 1-5 Example of a UML Diagram – Implementing Substation Automation Using

Substation Configuration Language (SCL) ...................................................................... 1-9 Figure 1-6 Suite of Components Within IEC61850 .................................................................1-10 Figure 1-7 Architecture for Open Conformance Test ..............................................................1-11 Figure 2-1 Power System Infrastructure and the Information Infrastructure............................. 2-8 Figure 2-2 IntelliGrid Architecture Framework ........................................................................2-10 Figure 3-1 The Organization of Project Teams........................................................................ 3-7 Figure 4-1 Example of IntelliGrid Environments – Two Environments Within the

Substation, One Environment Between the Substation and the Control Center, and One Environment Within the Control Center...................................................................4-21

Figure 4-2 Data Acquisition and Control for Distribution Operations (UML Use Case)............4-22 Figure 4-3 Integration of EMS Transmission Functions with DMS/ADA Distribution

Functions – A Real-Time Adaptive Decision-Making and Wide Area Control System Is Required to Meet the Objectives of the Self-Healing Grid ...........................................4-35

Figure 5-1 UML Use Case – Implementing Substation Automation......................................... 5-8 Figure 5-2 Basic Communication Services Concept Model ....................................................5-12 Figure 6-1 Current Reference Architecture of IEC TC57 ......................................................... 6-2 Figure 6-2 Suite of Components Within IEC61850 .................................................................. 6-3 Figure 6-3 Object Model Hierarchy.......................................................................................... 6-5 Figure 6-4 Example of the Relationship of Logical Device, Logical Nodes, Data Objects,

and Common Data Classes............................................................................................. 6-7 Figure 6-5 IED Object Naming ................................................................................................ 6-8 Figure 6-6 Setting Group Model .............................................................................................. 6-9 Figure 6-7 Buffered Reporting Model .....................................................................................6-10 Figure 6-8 Unbuffered Reporting Model .................................................................................6-10 Figure 6-9 Log Model .............................................................................................................6-11 Figure 6-10 Substitution Model ..............................................................................................6-11 Figure 6-11 Sampled Values Model .......................................................................................6-12 Figure 6-12 GOOSE Model ....................................................................................................6-12

Page 20: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xviii

Figure 6-13 GSE Model .........................................................................................................6-13 Figure 7-1 Architecture for Open Conformance Test ..............................................................7-12 Figure 7-2 Conformance Test Steps ......................................................................................7-15 Figure 7-3 State Transition Diagram ......................................................................................7-19

Page 21: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xix

LIST OF TABLES

Table 1-1 The Audience for Each Report Section ................................................................... 1-2 Table 2-1 Possible Types of Networks and Systems Management Functions........................2-20 Table 3-1 System Design Team Composition ........................................................................3-11 Table 3-2 Training Topics ......................................................................................................3-24 Table 3-3 Risk Mitigation Techniques ....................................................................................3-31 Table 4-1 Transmission Operation Function Requirements for Transmission Planning ........... 4-4 Table 4-2 Transmission Operation Function Requirements for Normal Real-Time

Operations....................................................................................................................... 4-7 Table 4-3 Transmission Operation Function Requirements for Emergency Real-Time

Operations......................................................................................................................4-11 Table 4-4 Transmission Operation Functions Requirements for Post Real-time

Operations......................................................................................................................4-16 Table 6-1 Electric Power Measurement Logical Nodes ..........................................................6-20 Table 6-2 Switch, Circuit Breaker, and Recloser Logical Nodes.............................................6-21 Table 6-3 Transformer and Tap Changer Logical Nodes........................................................6-23 Table 6-4 Capacitor Switch Logical Nodes.............................................................................6-24 Table 6-5 Protection Functions Logical Nodes .......................................................................6-25 Table 6-6 Typical Protection Logical Nodes for a Transformer Relay .....................................6-28 Table 6-7 Typical Protection Logical Nodes for a Line Distance Relay...................................6-29 Table 6-8 Typical Protection Logical Nodes for a Feeder Relay .............................................6-30 Table 6-9 Typical Protection Logical Nodes for a Generator Relay ........................................6-31 Table 6-10 Typical Protection Logical Nodes for a Bus Differential Relay ..............................6-32 Table 6-11 Typical Protection Logical Nodes for a Motor Relay .............................................6-32 Table 6-12 Disturbance Recording Logical Nodes .................................................................6-33 Table 6-13 Metering Logical Nodes........................................................................................6-34 Table 6-14 Archiving, HMI, and Alarming Logical Nodes........................................................6-34 Table 6-15 Basic Conformance Statement.............................................................................6-38 Table 6-16 ACSI Models Conformance Statement.................................................................6-42 Table 6-17 ACSI Service Conformance Statement ................................................................6-45 Table 7-1 Kepner-Trego Analysis............................................................................................ 7-8 Table 7-2 Types of Testing.....................................................................................................7-11 Table 7-3 General Flow of Automated Conformance Testing .................................................7-12

Page 22: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

xx

Table 7-4 Sample Test Plan Outline.......................................................................................7-13 Table 7-5 Test Procedure Groups..........................................................................................7-16 Table 7-6 State Definitions for Control ...................................................................................7-18 Table 7-7 Events/Message Definitions/Conditions/Actions.....................................................7-18 Table 7-8 State Transition Table for Control...........................................................................7-18 Table 7-9 Test Cases Defined in IEC61850 ...........................................................................7-20 Table 7-10 Conformance Test Report Format........................................................................7-21 Table 7-11 Sample Service Level Agreement Response Times.............................................7-22

Page 23: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

1-1

1 AN OVERVIEW OF IEC61850 SUBSTATION AUTOMATION GUIDELINES

1.1 Identifying the Purpose, Scope, and Audience for IEC61850 Substation Automation Guidelines

1.1.1 Purpose

This report provides guidelines for project managers, substation planners and engineers, project engineers, vendors, and substation integrators on the informational issues related to implementing IEC61850 in substation automation (SA). Substation automation is a new challenge for the utility industry, particularly when the new capabilities of IEC61850 are utilized to the fullest. The full range of new functions that IEC61850 enables are not yet well understood.

These guidelines were developed to describe the overall vision of SA to help ensure that the paradigm shift provided by this new enabling technology is appreciated by the utility industry. The guidelines describe the steps required in each phase of implementing SA with IEC61850.

1.1.2 Scope

These guidelines provide a basic understanding of IEC61850. Issues and methods for specifying and implementing IEC61850 in SA are discussed. The guidelines describe the functional requirements that must drive the design of the information system, the methodology for utilities to determine the functions that are required in their specific situations, and the recommended information standards for meeting those requirements (focusing on IEC61850).

1.1.3 Audience

The intended audiences for these guidelines are utilities who are interested in SA implementation and vendors who sell systems and equipment for SA.

Table 1-1 describes the audience for each of the main sections of this report. This guideline is organized according to the different stages of SA planning and implementation (see Figure 1-1). It is expected that all readers will review the first two sections of this report. Each of the subsequent sections of the report is oriented toward a specific audience.

Page 24: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-2

After reviewing the overview (Section 1), it is expected that most readers will read Section 2, “The Vision for the Future of Substation Automation” as an introduction to the broader issues of the pressures of deregulation on power system management, evolving information technologies, and the drive to automate systems. In all likelihood, readers will determine their specific areas of interest, such as planning or deployment, and move directly to that section of the report. The document, therefore, is designed so that each section can stand alone.

Table 1-1 The Audience for Each Report Section

Section Title Audience

Section 1 “An Overview of IEC61850 Substation Automation Guidelines”

All

Section 2 “The Vision for the Future of Substation Automation” All

Section 3 “Project Management for Substation Automation ” SA project manager and team leads

Section 4 “Developing Functional Requirements for Substation Allocation Equipment, Systems, and Applications”

Substation planners and engineers

Section 5 “Specifying Functional Requirements and IEC61850 for Substation Automation”

Information technology engineers

Section 6 “Implementing IEC61850 in Equipment and Systems” Substation engineers and vendors

Section 7 “Installing IEC61850 Equipment and Systems in Substations”

Substation automation integrators

Page 25: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A

n O

verv

iew

of I

EC

6185

0 Su

bsta

tion

Aut

omat

ion

Gui

deli

nes

1-3

F

igu

re 1

-1

Au

die

nce

fo

r E

ach

Sec

tio

n o

f th

e S

A G

uid

elin

es

Page 26: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-4

1.2 The Vision for Substation Automation

Gunpowder, the printing press, the commercial generation of electricity, the personal computer, and the Internet were all major paradigm shifts. Information has become the driving necessity in power system operations. In an interview1 on August 14th, 2003 (during the east coast blackout), Kurt Yeager, CEO of EPRI, stated “The first, the most important factor that we have to apply to the power system today is to make it a digitally controlled system.”

Substation automation is far more than just the automation of substation equipment. It is one of the first steps toward the creation of a highly reliable, self-healing power system that responds rapidly to real-time events with appropriate actions and that supports the planning and asset management necessary for cost-effective operations. Automation does not simply replace manual procedures. It permits the power system to operate in an entirely new way based on accurate information provided in a timely manner to the decision-making applications and devices.

In the past, utility attention was focused only on managing the power system infrastructure. However, as illustrated in Figure 1-2, that old worldview has changed. There are now two infrastructures that must be managed—the power system infrastructure and the communications information infrastructure.

Substation automation was not feasible a few years ago. Communication technologies simply were not available to handle the kinds of demands put on them by the complexity of substation automation requirements. For instance, one of the main enablers of substation automation was the recognition that the vast bundles of point-to-point wiring between the control house and the equipment in the substation yard could be eliminated through the use of Ethernet networks. Communication standards have now been developed that can address many of these demands. In particular, IEC61850 provides solutions to automation issues using state-of-the-art object-modeling technologies.

The vision for substation automation over the next years is presented in Section 2.

1 http://www.pbs.org/newshour/bb/fedagencies/july-dec03/blackouts_08-25.html

Page 27: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-5

Figure 1-2 Two Infrastructures Must Be Managed in the Future

1.3 Project Management for Substation Automation Projects

The implementation of substation automation requires more effort and different expertise than simply implementing a new substation using the traditional approaches. It is, therefore, very important for a substation engineer to fully appreciate the different steps required, even though these steps must be tailored to each individual situation.

Planning for substation automation requires a different approach than substation planners have typically used in the past. In addition to the design of physical and electrical requirements, SA also requires the design of the information requirements.

These are the basic steps in substation automation:

1. Find a champion who recognizes that substation automation will be cost-effective despite the learning pains, the need for different skills and approaches, and the inevitable glitches.

2. Develop a project team, headed by an effective project manager, with three subteams: a functional team, a system design team, and a technical team (see Figure 1-3).

3. Develop functional requirements by describing what the applications are to do in supporting stakeholder needs. This includes reaching out to stakeholder groups to determine what they need from SA systems.

4. Develop system management requirements that include security, performance, and other functions necessary to effectively manage the equipment and communication networks.

Page 28: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-6

5. Develop technical specifications that truly capture the functional requirements, but that do not over-specify by identifying the specific hardware. The specifications must cover the substation equipment as well as the communication systems, including the object models defined in the IEC61850.

6. Evaluate bidders and select vendors to provide the equipment and systems.

7. Monitor and manage the system development efforts (both in-house and by the vendors).

8. Review and comment on documentation, which is vital to ensure the equipment and systems are developed as specified.

9. Complete factory, field, and acceptance testing.

10. Complete field installation, validation, and commissioning.

11. Conduct planning for future upgrades and extensions.

These implementation steps are discussed in Section 3.

Figure 1-3 Organization of Project Teams

1.4 Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

Planning for SA requires a different approach than substation engineers have typically used in the past to construct new substations. In addition to the design of physical and electrical requirements, SA also requires the design of the information requirements.

Page 29: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-7

The IntelliGrid Architecture (at http://IntelliGrid-Architecture.com), can provide much of this support to substation planners. The IntelliGrid Project was funded by the Consortium of Electric Infrastructure to Support a Digital Society (CEIDS) for E2I, one of EPRI’s family of companies, to provide a framework of communication and information standards to meet the needs of existing and future power system functions. The IntelliGrid Architecture (see Figure 1-4) derived the communication and information requirements of power system functions by first creating a comprehensive list of functions, analyzing the needs of these functions, and refining these needs by in-depth analysis of some of the key functions.

A discussion of the development of functional requirements, and some examples from the IntelliGrid Architecture, are presented in Section 4.

Figure 1-4 IntelliGrid Architecture Framework

1.5 Specifying Functional Requirements and IEC61850 for Substation Automation

Specifying the functional requirements for substation automation requires a different approach than substation engineers have used in the past to construct new substations. The functional requirements must encompass far more than just purchasing equipment—they need to describe the requirements of all stakeholders in taking advantage of the capabilities of SA based on the state-of-the-art technologies of IEC61850. These stakeholders include operations, protection, planning, engineering, maintenance, data management, security, market operations, and corporate.

Page 30: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-8

By definition, functional requirements should focus on what rather than on how. The most effective way to develop these functional requirements is to use modeling techniques. These modeling techniques allow functions to be described with their interactions illustrated through formalized drawings (see Figure 1-5). Using models allows functions to be drawn and redrawn (on paper or on computer screens) so that all stakeholders can review them. The function must be refined as requirements are better understood and finalized into formal functional specifications before actual designs are created and long before any hardware or software is purchased.

Substation automation involves not only equipment, but also the communications infrastructure to monitor and manage the equipment, particularly when all of the IEC61850 capabilities are to be utilized. Therefore, in addition to the design of physical and electrical requirements, substation automation also requires the analysis of information requirements and a determination of the flow of information between equipment and systems. Modeling techniques can also be used to develop the best infrastructure or these communication information requirements.

A brief overview of some key modeling techniques, a discussion of the use of IEC61850 substation configuration language, and the procedure for specifying IEC61850 are presented in Section 5.

Page 31: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-9

Figure 1-5 Example of a UML Diagram – Implementing Substation Automation Using Substation Configuration Language (SCL)

Page 32: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-10

1.6 Implementing IEC61850 in Equipment and Systems

It is not easy to read the IEC61850 documents or to comprehend how the pieces all work together. This section is designed to describe the IEC61850 standards in more user-friendly terms and to identify the available options (see Figure 1-6) for a high-level vision of IEC61850). Section 6 first describes the concepts within IEC61850, which was developed explicitly for substation automation, although it also forms the basis for object model extensions. Section 6 also addresses specific equipment, discussing the existing models that may be relevant and the need for additional models. Finally, Section 6 identifies the conformance tables that must be agreed upon for specific implementations.

When implementing systems as complex and as new as SA, substation engineers will need to work closely together with the vendors of SA equipment and systems. Although the vendors will perform the detailed implementation of the IEC61850 object models and service models, the substation engineers must be able to decide what settings should be established for a particular substation. Therefore, substation engineers should develop a deeper understanding of IEC61850, of the potential benefits of the various features if they can be fully utilized, and of the issues that must be resolved as SA equipment and system are implemented for the utility.

Figure 1-6 Suite of Components Within IEC61850

Page 33: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-11

1.7 Installing IEC61850 Equipment and Systems in Substations

The implementation and testing of a substation automation system involves multiple partners: integrators, substation engineers, utility operations, construction and asset management personnel, information technologists, consultants, and multiple vendors. As discussed in Section 3, strong project management is required to facilitate these interactions. There are some interactions that explicitly involve IEC61850. Therefore, this section focuses on the issues associated with installing and testing IEC61850 equipment and systems in substations (see Figure 1-7).

Section 7 is intended to help the integrators who are involved in developing, implementing, and testing SA systems. These integrators could be utility substation engineers, outside A&E firms, vendors, or a mix of these groups.

The implementation steps are discussed in Section 7.

Figure 1-7 Architecture for Open Conformance Test

1.8 Key Points

Throughout this guide, key information is summarized in key points defined as bold lettered boxes that succinctly restate information covered in detail in the surrounding text, making it easier to locate.

By emphasizing vital information, key points enable personnel to take action for the benefit of their plant. The information included in these key points was selected by EPRI personnel, consultants, and utility personnel who prepared and reviewed this report.

Page 34: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

An Overview of IEC61850 Substation Automation Guidelines

1-12

The key points in this report fall into one major category—key technical points. Each key point has an identifying icon, as shown here, that draws attention to it, making it easy for personnel to quickly locate vital information.

Key Technical Point

Targets information that will lead to improved equipment reliability.

Appendix C contains a listing of all the key points contained in this document. The listing restates each key point and provides reference to its location in the body of the report. By reviewing this listing, users of this guide can determine if they have taken advantage of key information that can benefit their plants.

Page 35: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

2-1

2 THE VISION FOR SUBSTATION AUTOMATION

2.1 Purpose and Audience for This Section

This section discusses the overall vision for substation automation. It should be read by all readers to set the stage for the remaining sections.

2.2 Thinking Outside the Box – Paradigm Shift of Substation Automation

Gunpowder, the printing press, the commercial generation of electricity, the personal computer, and the Internet were all major paradigm shifts. Not surprisingly, they all swept away current practice or modified it significantly (not instantly, but quickly enough to indicate that something rather important had occurred). In each case, there was a present need, a confluence of technologies, and a vision of how to combine technology and need for economic gain and unprecedented advantage. Substation automation is not just the automation of a substation—it is part of a major paradigm shift for all power system operations.

Key Technical Point

Substation automation is not just the automation of a substation—it is part of a major paradigm shift for all power system operations.

Perhaps electric power transmission and distribution networks are ready for such a change. They represent the largest and most capital-intensive system devised by man. Yet, utilities leverage a remarkably small amount of information from this lifeblood of their business. As past and recent events have demonstrated, the urgency to improve this situation is increasing. It is necessary to ensure a secure national grid. As the amount of distributed energy resources (DERs) grows, it will be necessary to accommodate a higher grid complexity. Improved efficiency, better power quality, and deterministic power flow are necessary in support of a more competitive business climate. Technical, legal, and financial models of the power system must reinforce one another to ensure accountability.

Mainstream technologies can already extract a wealth of information from the power delivery system, selectively delivering it to multiple utility departments according to need. This technological infrastructure is shared so that all stakeholders have common access to station data and functionality, subject to security safeguards, regulations, and corporate policy. Modern devices and controllers can easily and cost-effectively provide exhaustive measurements of power system data with all its nuances. They can detect and measure system events and

Page 36: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-2

conditions, and control the flow of power. They support the traditional protection of individual equipment as well as the development of strategies for protection of the system as a whole against contingencies. The first (and most important) effort that must be applied to the power system today is to make it a digitally controlled system.

Key Technical Point

The first and most important effort that must be applied to the power system today is to make it a digitally controlled system.

When this integration of data and functionality is accomplished, the stage will be set for one additional huge benefit—the implementation of local and system-wide automation that delivers economic gains on many fronts. The result will be a reduction of nonproductive effort, the operation of equipment assets at higher power levels (while also monitoring them for operational safety under current operating conditions), and the interactive use of equipment assets to affect voltage and VAr control strategies. There are numerous applications that can be deployed to economic and operational advantage.

Substation automation is far more than just the automation of substation equipment. It is one of the first steps toward the creation of a highly reliable, self-healing power system that responds rapidly to real-time events with appropriate actions and that supports the necessary planning and asset management for cost-effective operations. Automation does not simply replace manual procedures—it permits the power system to operate in an entirely new way, based on accurate information provided in a timely manner to the decision-making applications and devices.

Why should an organization tolerate semi-informed decisions that may eventually cost tremendous time and money, especially when the means are available to tightly justify (or discredit) proposed improvements? These guidelines enable decentralized access to the station resources. This approach enables each department to gain access to those allowed resources that are most valuable for improving its process, cutting its cost, and exploiting new opportunities that open up. It lets each group meet its own responsibilities, applying innovation to the area it knows most intimately. If the corporate staff meets its responsibilities to provide direction and leadership, there is no doubt that the whole utility enterprise can achieve significant advancement. To summarize, these advantages can be used to transform how organizations conduct business.

Page 37: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-3

Information has become the driving necessity in power system operations. In an interview on August 25, 2003 regarding the August 14th east coast blackout, Kurt Yeager (CEO of EPRI) made the following comments2:

The first, the most important factor that we have to apply to the power system today is to make it a digitally controlled system. We have a digital economy and we're still trying to provide power to it through a mechanical design system that was designed over 50 years ago. It’s a marvelous system, but we've been effectively borrowing against the future to pay for the present, and the future has caught up with us; we need to build the system to serve the digital society of the 21st century. So that's the first step.

In so doing we can increase the efficiency and the capacity of the system we have. It will not eliminate the need for some new lines, but certainly we, if we do it technically, capacity expansion, we can reduce the amount of new lines that have to be put in place. So it really fundamentally improves the efficiency.

And it's then the controllability of that system. Once we have those digital controls in, we can instantaneously manage the power system so it is self-healing, that is it can detect instantaneously a difficulty and correct for it locally so that cascading effects can be eliminated and fundamentally improve the reliability of the system so that computers and other sensitive equipment that has come in over the last decade is not upset by power disturbances.

Substation automation basically consists of implementing intelligent electronic devices (IEDs) using microprocessors to monitor and control the physical power system devices. These IEDs can make more data available in digital format. Having a large amount of data (in whatever format) is not particularly good or bad in and of itself. However, these data can be turned into information that is available in the right form, at the right place, and at the right time. It is this information that is the true benefit of substation automation.

2.3 Enabling Information Technologies That Enhance Substation Automation Capabilities

Substation automation would not really have been feasible a few years ago. Communication technologies simply were not available to handle the kinds of demands put on them by the complexity of substation automation requirements.

For example, one of the main enablers of substation automation was the recognition that the vast bundles of point-to-point wiring between the control house and the equipment in the substation yard could be eliminated through the use of Ethernet networks. But Ethernet was only practical after the higher speed switching technologies were developed. When networking became standardized with highly reliable products available from multiple vendors, automation became feasible because data could be collected from multiple devices without the added expense of running new wires.

2 Ibid.

Page 38: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-4

Key Technical Point

Recognition of the fact that vast bundles of point-to-point wiring could be eliminated through the use of Ethernet networks was one of the main enablers of substation automation.

With this basic communications capability in place, other technologies commonly used in other industries could be easily adapted to the substation environment. Rather than just replacing wires with Ethernet networks, the door would open to additional technologies to improve the management of data, the security of information, and the simplification of hardware and software maintenance. The following list contains examples of the state-of-the-art technologies that might then be applied:

• Industry-standard interface technology: Transition Control Protocol/Internet Protocol (TCP/IP) can be used through the Ethernet network to provide full routing capabilities. TCP/IP can also be used for engineering stations providing direct access over logical paths to IEDs in the substation for remote configuration and setting of parameters without the need for separate physical links.

• Security through standards and role-based access control (RBAC): TCP/IP has well-established security mechanisms, and the IEC61850 security technologies are in the process of being standardized. Through RBAC, control centers can assign, monitor, and ensure individual access rights to the information objects of the substation and subscribe to information objects.

• Consolidation of hardware: Conversion of protocols and formats is avoided because the local communications platform within the substation (substation bus) and telecontrol is the same. Instead of a gateway, a proxy can be used within the substation to present the information objects to the control center.

• Object-modeling (Establishing standardized self-describing object names): By using object-modeling technology, IEC61850 established standardized self-describing object names for substation information instead of nondescriptive numerical addresses. This allows each data item to be uniquely identified (similar to a person living at a unique address) and greatly enhances the ability of systems to manage the data.

Key Technical Point

By using object-modeling technology, IEC61850 established standardized self-describing object names for substation information.

• Standardized naming and mapping to proprietary databases in proxy servers: The

device-oriented names of information objects can be mapped in the proxy server to process-oriented proprietary names and databases because the control center application is process-oriented and logical devices of the substation are, therefore, hidden.

Page 39: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-5

• Data management: Data are becoming increasingly difficult to manage as the number of digital components increases within substations and as the amount of data from each component increases exponentially. With self-descriptive unique names, IEC61850 objects permit systems to automatically manage the data without relying on data administrators to laboriously follow a chain of nondescriptive numerical addresses (for example, point 12 on card 5 should be mapped to the third item in column 39 in record 47 in database ABCD).

• Metadata management: Metadata, which is the information about data rather than the dataset itself, can help establish interoperability among systems (just like a Microsoft Windows3 system can detect and automatically install new hardware). This new concept of metadata can be expanded to allow new substation devices to be detected and installed with minimal user support.

• Designing toward a seamless architecture: In general, a seamless architecture leads to potential lower costs for design, configuration, installation, operation, and maintenance combined with higher performance as compared to current solutions. Although much work still needs to be done, the IntelliGrid Architecture has built the foundation for such a seamless architecture.

2.4 The Benefits of Substation Automation for Different Users

Having some information technology available does not necessarily mean that automation is useful or justifiable. Data is not information. Therefore, it is vital to determine the true benefits of substation automation to all stakeholders or users. In fact, not all benefits are cost-justified under all conditions, so each situation must be evaluated individually. Nonetheless, many benefits that were not initially obvious have become increasingly cost-justified, as automation has moved from the simple replacement of existing processes to a more sophisticated interaction among processes. The development of new functions that would have been impossible before automation. For better or worse, automation leads to powerful new capabilities for users, which in turn leads to the need for more automation.

Key Technical Point Automation leads to powerful new capabilities for users, which in turn leads to the need for more automation.

3 Microsoft Windows is a trademark of Microsoft Corporation.

Page 40: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-6

Some examples of the benefits of substation automation to different users are described briefly here:

• Substation automation offers implementation benefits.

– Reduced quantities of equipment: Through the use of shared technology for data sourcing, control, protection, station metering, processing, and communication—all for the benefit of multiple utility departments and other clients.

– Replacement of discrete station wiring with flexible communication networks: To accommodate continual system change and migration.

– Networks implemented with fiber-optic cable: Mutually isolates pieces of connected equipment to limit collateral equipment damage under adverse electrical conditions such as faults and close-proximity lightning strikes.

– Integration of digital information and functionality: In disparate devices that currently operate in separate realms such as fault recorders, protective relays, sequence of event recorders, fault locators, network transducers, regulators, or controllers.

– Gradual displacement of analog devices: Typically less flexible in use, more difficult to diagnose, and more costly to maintain.

– New digital equipment capabilities: Such as distance-to-fault locators and sag detectors can easily be integrated with the other station equipment to provide new functionality and more comprehensive system information.

– Station HMI (human machine interface) consoles: Enables the displacement or replacement of traditional station panels. Station information such as power system data, status of the local electrical network, and the diagnostics status of IEDs can be locally consolidated.

• Substation automation benefits the utility staff.

– Maintenance staff: Can remotely isolate and diagnose problems. This requires fewer trips to the station, saving time and money, resulting in typically shorter outages. This capability is provided by microprocessor-based equipment supporting self-monitoring and self-diagnosis.

– Planners, engineers, and asset management personnel: Can monitor and capture the operational behavior of feeders and line equipment over time, profiling their service characteristics against independent factors such as temperature, season, time of day, and time of week. Statistical analysis can be used to distill useful information for planning.

– Operators and operational planners: Additional real-time information for use in operational planning (within the next hour or so).

– Operators: Additional alarming capabilities and alarm management (how important is each alarm under certain conditions and who should see them); or multiple sources for data and alarms to ensure no critical information is lost or unavailable to operators.

– Protection engineers: Oscillographic information available for capture in real-time during normal operations.

Page 41: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-7

– Protection engineers: Ability to change settings remotely in anticipation of changing conditions

– Operations engineers: Additional information available for contingency analysis and identification of potential problems; management during emergency conditions, emergency recovery, and post-emergency analysis.

– Data administrators: Avoid time-consuming and error-prone tracking of chains of data links each time a change is made in the field.

• Substation automation benefits control center operations.

– SCADA/EMS systems: Additional data are available to be monitored if operators and/or SCADA/EMS applications need them. Alternatively, if the SCADA/EMS system does not need data that are required by another group, then the other group can collect the data directly from the substation master without burdening the SCADA/EMS system.

– Contingency analysis (security analysis): Additional data from multiple sources for redundancy, thus increasing the reliability of the results.

– Intelligent alarm processing: With the additional data, intelligent alarm processing can filter out the less important alarms from the more important ones and can also analyze these data to determine the true issue causing the alarm. These more important alarms can then notify operators, and/or cause additional applications to execute (such as contingency analysis).

– Emergency response: Control commands, whether issued locally or remotely, can respond rapidly to emergency situations in a coordinated manner, not only within a substation, but also between substations and between utilities.

2.5 Information Technology Requirements That Drive Substation Automation Designs

These enabling information technologies can provide the means to enjoy major benefits. However, they also have requirements that must be managed.

Most substation designs also include a secondary system, comprising all components and systems used to monitor, control, protect, and automate the substation. Because this information infrastructure is critical to human safety, equipment safety, and system reliability, it has always been an essential part of substation planning and implementation. Examples of these components include PTs, CTs, transducers, control panels, protection relays, RTUs, serial communications, and HMI. In recent years, we have seen the emergence of intelligent devices (such as IEDs), networked communications, programmable logic, and digital signal processing (DSP) capabilities for extracting a wealth of information from a simple 3-phase power connection.

To date, however, integration of the secondary system has been fragmented, composed of separate subsystems with little commonality. IEC61850 now provides the means to integrate communications, information, and applications into a coherent, flexible, very powerful framework for the secondary system. With its deployment, more information will be exchanged and more applications will be run within the substation. We will see that integrated, accessible

Page 42: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-8

information is truly the enabler of effective and economic substation automation. Power system operations can no longer be viewed as a single infrastructure—in addition to the power system infrastructure, there is now an information infrastructure that overlays the power system.

Figure 2-1 Power System Infrastructure and the Information Infrastructure

The extraordinarily complex power system, sometimes viewed as the largest machine in the world, cannot function without this information infrastructure. Not only is this information infrastructure a tremendous enhancer of power system operations, but it is also a new burden because it too needs to be designed, implemented, and managed.

Key Technical Point

Both the power system and the information infrastructure must be designed and managed.

The information infrastructure must be designed with the main focus of supporting power system operations. Many different information designs have been used to meet this criterion. However, within recent years, information technologies have been evolving so that they are better at supporting power system operations and better at managing their own infrastructure. Although these information technologies are still evolving, it is crucial to use what technologies are available and to plan for incorporating new concepts as they are solidified and standardized.

Page 43: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-9

The IntelliGrid project developed an architecture that addresses these information infrastructure requirements. An overview of the key issues of the IntelliGrid Architecture follows. (More detail can be found at http://IntelliGrid.info.)

2.5.1 IntelliGrid Architecture Framework Contents

The IntelliGrid Architecture Framework was constructed based on the previously mentioned concepts. It is based on an architecture framework bounded by the information infrastructure requirements of the power system industry. The framework includes:

• The business needs of the power system industry, as captured in the power system operations functions and categorized into the IntelliGrid Environments

• Strategic vision based on the high-level concepts of distributed information

• A tactical approach based on technology-independent techniques of common services, information models, and interfaces

• Standard technologies and best practices that can be used in the power industry

• Methodology for automation architects, power system planners, project engineers, information specialists, and other IntelliGrid Architecture users to quickly identify the exact parts of the IntelliGrid Architecture that are directly relevant to them and access the IntelliGrid Architecture recommendations

The IntelliGrid Architecture framework generalizes and extracts the architecturally significant requirements by cross-cutting energy industry requirements involving distributed information, and provides a technology-independent architecture for project engineers to use as they determine solutions for specific implementations. Figure 2-2 depicts the IntelliGrid Architecture Framework and clearly identifies how these concepts fit together.

Page 44: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-10

Figure 2-2 IntelliGrid Architecture Framework

2.5.2 Abstract Modeling

Typically, power system engineers describe a power system function in their own words—this rarely includes the exact information need by the systems engineers who implement the function. In order to more accurately extract the information requirements for a power system function, it is best to ask the power system experts to develop a step-by-step analysis of each part of the system. An information expert can then model this analysis using tools such as the Unified Modeling Language (UML). Power system experts can then review these models to determine if they truly represent the needed functions. When a model is correct, it can more easily and reliably be implemented in software and hardware.

Modeling is one of the most powerful tools available for understanding, documenting, and managing the complexity of the infrastructures required to operate the energy system of the future. It is far less expensive to construct a model to test theories or techniques than to construct an actual entity, only to find out that one crucial technique is wrong and the entire entity must be reconstructed.

Models have been used extensively by many industries as the basis for analyzing and designing complex systems. The telecommunications industries have made extensive use of modeling to develop the diverse communication infrastructure(s) in widespread use today. Physical models are used in many industries, ranging from airplanes and Mars Landers to circuit breakers and transformers. Building architects use paper models (blueprints) to capture the complexity in a

Page 45: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-11

modern high-rise building. Virtual models are increasingly being used to model even more complex concepts such as weather patterns and cosmology, and of particular interest to the IntelliGrid project, to information management.

The following abstract modeling methodologies and concepts were incorporated into the IntelliGrid Architecture:

• Reference model for open distributed processing (RM-ODP) and the Unified Modeling Language (UML): Years of engineering have been invested in defining how enterprise-level architecture should be defined. RM-ODP is an international standard (ISO/IEC 10746) prescribing a methodology for architectural development. The methodology provides guidance on breaking the problem into understandable pieces and helps to ensure that important design details are not forgotten.

By design, RM-ODP provides the methodology, but does not include a recommended notation for documenting an architecture. The most popular standardized notation for system modeling is UML, which provides a standardized way to graphically document the systems and components of an architecture. RM-ODP provides the architectural guidance and UML provides the standardized notation. It should be noted that as this document was being prepared, the standards for applying UML to RM-ODP concepts were under development. As the energy industry moves forward in the development of advanced automation systems, the adoption of these sophisticated methods should be encouraged.

• Object-modeling and information models: These information models define data names and structures. They can be described informally as consisting of nouns. Nouns consist of data names and their structure. A noun can be a simple data point (such as a point called State) that consists of one 8-bit integer, or more complex data points that include the value, the quality of the value, and the description of the point. Nouns can also be complete descriptions of a utility’s power system (for example, ABCPowerSystem) that consist of thousands of components in some well-known structure. There can be millions of nouns in any system.

In the power industry, IEC61850 includes such a model, which is focused on field device characteristics. Another information model is IEC61970 Common Information Model (CIM), which is focused on modeling the information about the power system structure that is to be exchanged among application programs. It has been expanded to model other types of information to be exchanged among application programs. As an information model specifies what information is exchanged, it is part of an RM-ODP information view.

• Abstract service/interface models: A service model describes the functionality that a software application provides. IntelliGrid Architecture’s common services describe the common functionality needed to operate a utility. For example, the common service of Logon specifies the common function of initiating a secure session with a software application.

Page 46: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-12

• Interface model: This model defines the mechanics of how data are passed to get the right information to the right destination at the right time. Interface models can be described informally as consisting of verbs. Verbs are the abstract services used to exchange the nouns, such as request, send, report if changed, or add to log. Although different verbs/services are used in different environments, the number of different types of abstract verbs/services generally ranges from 10–20.

In the power industry, IEC61850 includes such a model, which is focused on field device operation. Another service model is IEC61970 Generic Interface Definition (GID), which is focused on how information about the power system structure is to be exchanged among application programs. An interface model specifies how information is exchanged and is part of an RM ODP computational view.

• Naming and avoiding ambiguity (name collisions): One aspect of information models is the need to uniquely identify all objects within the model. In addition, as the number of names being used proliferates, there is a need to avoid name collisions (that is, the same name used with two different meanings). This is handled by namespace allocation. Namespace allocation is a very simple concept—different groups can have the authority to name their own objects as long as those names are unique within the group’s domain. However, it is not necessary for them to be universally unique. This permits different groups (entire industries, standards organizations, types of products, or departments within a company) to define their own terminology and abstract model names and structure.

Namespace allocation for the electric power industry should be performed in a top-down manner that clearly captures the different arenas. Although some namespaces should be as broad as possible (that is, valid across the entire electric power industry), additional namespaces should be allowed as part of a formal scheme to permit specific utilities, specific vendors, specific functions, and other groups to apply for and register their own namespaces.

Examples of namespaces within the IEC TC 57 are the allocation substations to the IEC61850 namespace and the allocation of transmission power system applications to the IEC61970 namespace.

• Self-description and discovery: Future advanced automation systems must have more capable methods for managing networks, connected equipment, and the applications that run on this equipment. This will require more sophisticated systems to assist system administrators in managing large-scale networks and massively distributed equipment. Concepts such as self-description and discovery will become a necessary part of future systems or maintenance could easily become unwieldy.

Self-description and discovery is a fancy title for describing what happens when a new printer is plugged into a PC: Consider the following example:

– First message: “New hardware detected.”

– Second message: “Driver xxx is being installed.”

– Third message: “Printer is ready for use.”

Page 47: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-13

A SCADA/EMS system performs the following equivalent actions:

– First message: “New circuit breaker IED detected.”

– Second message: “Substation master updated.”

– Third message: “SCADA database updated.”

– Fourth message: “Data acquisition commencing.”

– Fifth message: “Power system model being updated.”

– Sixth message: “Contingency analysis is ready to execute.”

While this may seem impossible or impractical now, it will certainly eventually be commonplace and require less manual intervention.

Self-description and discovery form the basis for plug-and-play technologies. The concept behind self-description and discovery is that data models can be stored electronically in repositories, servers, and other distributed databases, using a language for describing data such as extended markup language (XML) These XML descriptions of the data models are self-describing—they contain the standardized name of the data along with the structure and formatting of the data. Thus, they can be browsed by users who can immediately understand what they are browsing.

In addition, discovery of these data models can be implemented by special applications (which can be called intelligent agents or metadata browsers) that read the name and format of the data in the remote server (for example, New RTU), set up their own local database (SCADA database) to reflect this name and format, and establish links so that the actual information can be read from the remote server and stored in the local database (data acquisition commencing).

• Technology-independent design: Using a technology-independent design is an important concept when developing interoperable systems and equipment. A technology-independent design must focus on the behavior and structure of the components within a system and abstract the implementation details of any particular technology. This key concept allows for different implementations and technologies to exist, yet still allows these components to be used interchangeably. Using technology-independent design enables a coherent architecture to be created independently of deployment specifics. When implemented, the technologies are chosen to meet requirements, but are implemented in a way that complies with the technology-independent design.

2.5.3 Information Security Planning and Management

The public electric power system is now characterized as one of several critical infrastructures that must apply security practices more rigorously. At the same time, not all substations or equipment within substations pose equal security risks. Security solutions must be tailored to meet the true security risks, taking into account the attractiveness of specific targets, the actual vulnerability of different power system equipment to security attacks, and the costs for implementing and maintaining the security measures.

Page 48: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-14

Information or cyber security has become an enormously hot topic over the last few years. Not only are there threats from Internet kiddie-script hackers (which rightly were ignored by substation engineers), but there are now more pertinent threats from sophisticated crackers, industrial espionage, disgruntled employees, well-paid insiders, and terrorists.

Key Technical Point

The public electric power system is now characterized as one of several critical infrastructures that must apply security practices more rigorously. Security by obscurity is no longer a safe bet.

The purpose of information security planning is to meet the security requirements of the user community, network, data, and applications, including security policies, security technologies, and security management such as the following:

• A security requirements assessment (including techniques for determining the types and levels of security required by each asset, prevention techniques, vulnerability assessment, and interdependency analysis) that accomplishes the following tasks:

– Systematically identify critical assets

– For each asset, conduct assessments on attractiveness to attackers, impact of successful attack, and vulnerability to attacks

– Carry out critical consequence analyses and evaluate the public health and safety, economic, and social impacts of infrastructure disruptions

– Manage security policies including the development of security policies, the establishment of policies for corrective action when vulnerability is discovered, the establishment of policies for granting and revoking authority, the security training of employees, the security monitoring of employees, the repercussions for employees for not following security policies, and the assessment of information exposure to ensure compliance with security policies and procedures

– Periodically reassess security requirements

• Security policies and techniques for determining requirements and implementing physical security countermeasures that include the following measures:

– Surveillance systems for buildings, substations, and other facilities, including motion detection cameras, video cameras, digital video recording equipment, matrix switching and control, and remote video transmission

– Alarm system (sensors and control panels)

– Access control and staff identification, including locks, guards, fences, guard dogs, lights, biometrics, smart card, radio-frequency identification (RFID), electronic keys and locking devices, fiber-optic vibration sensor, motion sensor and others

– Backup and alternate paths, including backup control center, backup systems and bunker sites, backup data at physically different sites, alternate communication paths, alternate communications media, and alternate communications interfaces

Page 49: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-15

• Security policies and techniques for determining requirements and implementing information security countermeasures that include the following measures:

– Assessment of possible countermeasures for each type and level of security vulnerability

– Assessment of most cost-effective techniques across groups of assets

– Handling of legacy systems and applications in implementing security

– Data authentication, integrity, and confidentiality

– Supervisory computer security and firewalls

– Key management and certification

– Secure communication architectures and protocols

– Secure internet (SSL, IPsec)

• Intrusion detection, mitigation, and recovery plan and techniques that include the following measures:

– Intrusion detection methodologies

– Integrate and analyze data and information from different sensors, detectors, and other sources to make rapid determinations of the magnitude of an emergency (either physical or cyber) and implement contingency plans to reduce the impacts of disruptions on the grid

– Spare parts database management

– Development and execution of methods for distributed denial of service attacks (DDOS)

– Recovery plans

– Security management techniques to mitigate impacts during a security attack, including detection of intrusion, detection of attack, methods for countering attacks in progress, and methods for ameliorating the impact of a security breach

– Security managers respond and mitigate the physical and cyber disruptions

– Security management techniques after a security attack including an assessment of damage, the assessment and correction of security vulnerabilities, and a determination of legal and financial processes against attackers

– Security techniques to collect and distribute threat information

• Investigation and prosecution of a security attack including the following measures:

– Logging, recording, and audit trails

– Security issues for legal procedures

2.5.4 Data Management

The purpose of data management is to meet the power system operational requirements for data quality (integrity, accuracy), flexibility, scalability, and availability, while also providing the

Page 50: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-16

information infrastructure for managing this data. This task includes the management of many large databases with data exchanges across organizational boundaries, requiring frequent and timely access and updates.

Key Technical Point

In automation systems, data management is vital to ensuring that the right information is available in the right place at the right time.

The following list describes the tasks related to data management:

• Management of databases: Includes functions such as capacity planning, tablespace management, permissions, access control and quotas

• Data design and modeling: Includes functions such as indexing, development and use of object-modeling techniques, data modeling for typical data objects, data modeling for non standard data such as geographical information system maps, images, video, and oscillographic data

• Data recovery: Includes the development and use of automated and manual techniques for data replication, management of alternate sources of data, logging and archiving, backup, offline storage, and disaster recovery

• Data integrity: Includes the development and use of data management techniques for data synchronization across interfaced systems, consistency checking, validation and data correction, handling logs and auditing, data cleansing, data anonymity, and data purging

• Management of database operations: Includes the development and use of techniques for data editing and updating policies and procedures, database population, report generation and data collection forms, handling data across organizational boundaries (consistency and integrity), data transformation and mapping, database mediation and integration, development of forms and schedules for providing raw data by other departments (for example, planners, engineering, maintenance, and construction), discovery and automated interfacing with non-utility data objects (such as the methodology proposed by ebXML, storage, retrieval and streaming of video and audio data, two stage commit, and rollback)

• Data mining and retrieval: Includes the development and use of techniques for on-line transaction processing (OLTP), which involves real-time processing and retrieval of data that may extend databases across organizational boundaries, on-line analytical processing (OLAP), which involves retrieval and processing and presentation of data from different points of view, sorting/selecting, and retrieving large amounts of historical data, data warehouse, data mining, ad hoc querying, knowledge management, and document management

• Data object modeling: Includes developing object models, instantiating object models, mapping of instantiated object models, data self-discovery, object browsing capabilities, automated data discovery, developing data exchange models, and validating object models and instantiations

Page 51: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-17

2.5.5 System and Application Management

The purpose of system and application management is to provide the technological infrastructure and managerial policies that are designed to support the availability, reliability, performance, scalability, and economics required by applications and systems. These include applications and systems within the substations, the control center, engineering and planning departments, the corporate departments, and, as much as possible, across to external entities.

Key Technical Point Systems, applications, and communications networks must be actively monitored, controlled, and managed in a manner similar to the power system.

The following items should be considered:

• End system and application requirements development. Collect and analyze computation, storage, and management requirements.

• End system technology and architecture/platform planning. Specify appropriate computing and system management technologies, architectures for applications, middleware, operating systems, and hardware. The task includes establishment and use of IT standards for the following applications:

– Interapplication interfacing and communication technologies such as message brokers and RPC oriented infrastructures

– System implementation, validation, and certification

– Maintenance of systems

– Monitoring systems and applications

• Installation, deployment, and certification of systems and applications.

• System integration.

– Application integration (internal).

– Integration with eCommerce interfaces (external).

• Real-time system and application monitoring and management for applications, middleware, operating systems, and hardware. This includes the development and use of techniques for the following applications:

– Monitoring the status of systems and applications

– Detection and recovery from failures and performance problems

– Disaster recovery and business continuity

– Logging and recording of status and problems

Page 52: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-18

• End system/application maintenance (planned and emergency).

– Testing and diagnosis

– Technician scheduling and repair

– Report generation

• Customer care, help desk, and user support.

• Business object management. This includes management of SW constructs associated with real world objects such as a circuit breakers or purchase order. The following tasks are important:

– The design and development of business objects and management systems

– Monitoring and reporting on the status of business objects

• Workflow management. This includes design and development of workflow management systems as well as execution of management functions: monitoring, diagnosis, and reporting.

2.5.6 Network Management

The purpose of network management is to meet the requirements for communications network accessibility, reliability, availability, resiliency, performance, manageability, and economics. Communications networks must also be actively managed in order to provide the required information system reliability and, therefore, the required power system reliability.

Key Technical Point

Communications networks must also be actively managed in order to provide the required information system reliability and, therefore, the required power system reliability.

The following points should be considered:

• User/business network requirement (quality of service [QoS], availability, backup, bandwidth, and response time) development.

• Network technology and architecture/platform planning. This involves the establishment and use of new technologies for network architecture, network management, network signaling and control, data/payload delivery mechanisms, implementation, validation, and certification of networks.

• Network design and configuration. The task is to specify the logical network design and configuration that meet the architecture specifications and forecasted network demand growth.

• Installation, deployment, and certification of networks.

Page 53: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-19

• Real-time network monitoring and management. This includes establishment and use of IT techniques for monitoring the status of networks, responding to failures, performance problems, logging and recording status and problems, collecting and analyzing measurements for network reengineering, and capacity planning.

• Network element management, including performance management, fault management and recovery, maintenance (planned and emergency), including testing/diagnostics, technician scheduling, repair, report generation, and process management, and disaster recovery/business continuity.

• Network engineering, including addressing and routing, policy management, configuration management, traffic and QoS engineering.

• Customer care and user support.

The IEC is currently working to develop network management objects for power system operations. In addition, the networking and telecommunications industries are working toward more sophisticated system administration infrastructures. Examples of possible types of network and systems management functions and objects for energy industry related IEDs are shown in Table 2-1.

Page 54: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-20

Table 2-1 Possible Types of Networks and Systems Management Functions

Possible Types of Network and System Functions Possible Responses or Actions

Numbers and times of all stops and starts of systems, controllers, and applications Start or stop reporting

The status of each application and/or software module such as stopped, suspended, running, not responding, inadequate or inconsistent input, errors in outputs, and error state

Restart IED

The status of all network connections to an IED, including numbers and times of temporary and permanent failures

Kill and/or restart the application

The status of any keep-alive heartbeats, including any missed heartbeats Reestablish the connection to another IED

The status of backup or failover mechanisms, such as numbers and times when these mechanisms were unavailable

Shut down another IED

The status of data reporting such as normal, not able to keep up with requests, or missing data

Provide an event log of information events

The status of access such as numbers, times, and types of unauthorized attempts to access data or issue controls

Change password

Anomalies in data access (for example, individual requests when normally reported periodically) Change backup or failover options

2.5.7 Telecommunications Management

The purpose of telecommunications management is to meet the requirements demanded by power system operations for the telecommunications infrastructure. Telecommunications media must be actively managed in order to provide the required reliability.

In this discussion, the term telecommunications refers to both the physical media and the media-specific protocols. The media includes leased lines, fiber-optic systems, microwave systems, spread spectrum radio systems, power line carrier, wire cables, use of cellular and wireless service providers, Internet and Internet service providers, telecommunication service providers, and data service providers.

Key Technical Point Telecommunications media must be actively managed in order to provide the required reliability.

Page 55: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

The Vision for Substation Automation

2-21

The management of telecommunications involves the configuration and networking of different media, accessibility to telecommunication channels, the reliability of the media channels, the availability of the networks, the resiliency of the infrastructure to planned and unplanned telecommunications outages, performance parameters, the manageability of maintenance and changes, and the economics of maintenance and upgrades.

Telecommunications management can be categorized in the following ways:

• User/business telecommunications and data networking requirement development, including the development of service level agreements and overseeing externally provided telecommunications and networking facilities

• Telecommunications infrastructure technology and architecture planning, including the establishment and use of standards for designing, purchasing, installing, and implementing different media

• Real-time monitoring and management techniques for monitoring the status of the telecommunications network infrastructure, providing resiliency, and recovering from failures or performance problems

• Telecommunications infrastructure management, including monitoring and measurement for capacity planning, performance management, fault management and recovery, inventory/asset and order management, maintenance (planned and emergency), and disaster recovery/business continuity

Page 56: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 57: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

3-1

3 PROJECT MANAGEMENT FOR SUBSTATION AUTOMATION

3.1 Purpose and Audience for This Section

3.1.1 Purpose

In the past, utilities have started and executed substation projects frequently. However, the latest technologies, concepts, methodologies, and products are substantially different from past practice. It is necessary for project management to organize and lead the effort to translate new technologies into practice. In the broadest sense, that involves defining substation requirements from the ground up, planning system design that is responsive to those requirements, and implementing that design.

The issues in this section are just as valid when responsibility for project execution has been delegated to an outside party as they are when the utility is handling that responsibility internally. In both cases, the utility needs to verify that these issues and processes are being pursued appropriately.

3.1.2 Audience

Project managers, team leaders, and other project team members whose responsibilities involve project management will benefit from the information in Section 3. This section presents a project management model designed for conducting substation automation (SA) projects centered around networked communications using the IEC61850 standard and related technologies.

3.2 The Big Picture

3.2.1 Why a New Approach Is Necessary

The recommendation that substation requirements be defined from the ground up may raise some questions. After all, the typical utility has spent decades refining current practices. While this is true, the odds are that yesterday’s good practice has become today’s rut. Ongoing practice tends to create a cultural mindset and organizational inertia that inhibits the practice from changing. The positive side of this fact is that an organization as a whole develops a common understanding about how certain problems are solved. The danger, however, occurs when people

Page 58: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-2

view future changes in terms of the existing technical framework rather than in terms of organizational needs. Because current practice has evolved from a much earlier time when constraints were much different, long-held assumptions may no longer be valid. Because old technology has worked for a long time and people feel comfortable with it, numerous things may be taken for granted. Along the way, certain desirable capabilities may have been dismissed as infeasible because the means to support them were nonexistent, immature, or too expensive. This baggage often has to be swept away, allowing a fresh assessment of what is needed and what is now feasible.

3.2.2 The Importance of Project Management

The excellence of the solutions we create is affected by two principal factors. One is how we view the problem to be solved. The other involves the application of the resources (for example, technologies, products, tools, or skills) that we have available. This is why a utility’s first “smart substation” project is such a watershed event—it offers a real opportunity to reassess these two interrelated areas. If this opportunity is ignored, a utility may seriously deprive itself of potential benefits. This loss will not only affect what is accomplished immediately, but can cripple the utility’s capability to effectively build on this work when adding advanced automation later.

It is important to recognize that smart substations are a relatively new, technically advanced, and substantially pervasive approach to substation practice. Although the design and layout of the primary system (that is, the electrical infrastructure) may not be greatly affected, the effects on the secondary system will likely be breathtaking. From a skills perspective, smart substations enable more effective, less costly approaches to substation construction, engineering, installation, testing, and commissioning. From an operational perspective, smart substations enable more capable, flexible, open, and less costly approaches to system monitoring, control, protection, and automation. The smart substation concept is a credible, pragmatic approach for realizing all aspects of SA. It enables a utility to integrate a commonly shared technology infrastructure, supporting business objectives and the underlying functional requirements of demanding technical applications.

When a utility first initiates a smart substation project, there may be many unknowns and little experience with the new technologies. By necessity, project management will have expanded responsibilities in guiding initial smart substation projects to completion.

3.2.3 Project Scenarios

It is important to differentiate projects and programs as they apply to the substation arena. A project has a definite set of objectives—an implementation plan, a schedule, a budget, and a life that ends when the objectives are met. A program begins with an initial project that either starts from the beginning or is applied to an existing system. However, a program continues past the initial project, encompassing an ongoing life cycle of upgrades and expansions, typically realized through a succession of related projects.

A program will typically embody a migration strategy, shaped around the utility’s strategic and tactical priorities and cognizant of its limited resources. A migration strategy is a creative

Page 59: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-3

endeavor, weighing prior investment, obsolescence issues, and available resources against the costs and benefits of proposed changes over time. As a utility develops its agendas for progression over time, these efforts will likely be managed as a succession of projects within a substation automation program.

The projects that comprise a substation automation program fall into two areas—pilot projects and production deployments. They are characteristically different, as the following subsections explain. This information on pilot projects and production deployments is provided to meet the intention of these guidelines to enable a pragmatic course that is helpful to those who are not extremely familiar with this technology.

3.2.3.1 Pilot Projects

SA pilot projects, also known as proof-of-concept projects, are usually initiated as part of a utility’s introduction to the new SA technologies, methodologies, products, and practices. Because there is a lack of experience, the project goal is primarily to discover what is involved, map the minefields, identify the risks, get a handle on how to deal with discrepancies, and determine the real cost-benefits. In such a project, there may be midcourse corrections, minor pullbacks, and reassessments. In these cases, it is important to keep the logistics and project scale relatively small, so that these activities do not result in unacceptable, logistical cost overruns. Just as important is the fact that such projects allow a utility to really assess prospective equipment and supplier support before larger commitments are made.

3.2.3.2 Production Deployments

SA production deployments, also known as full-scale implementation projects, are intended to change the utility’s substation practices in a significant way. They assume that the proof-of-concept work has already been done, and that the risks are understood and manageable. There is more confidence in equipment and supplier support, because there has already been at least one round of experience. Because a project plan can be developed that confidently manages technical and process risks, project scope and logistics can be larger. Nevertheless, the project manager should never expect everything to go according to the project plan, because many utility personnel will still be on a learning curve, and scaling up from pilot projects often raises its own issues. Some schedule and budget slack should be reserved, so that inevitable problems do not destroy the project plan. Otherwise, the project manager should expect to keep the project close to its original schedule and budget commitments.

3.2.4 Strategic Approaches

Utilities have different management missions defined by their unique business opportunities, strengths and weaknesses, and positioning within the larger utility market environment. Each utility needs to determine how substation automation fits into its own big picture and to adopt an appropriate strategy. One size does not fit all.

A key factor in studying the benefits and costs of any new system is determining the baseline costs of the present approach, and then determining the net value of feasible alternatives. This

Page 60: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-4

can be accomplished by evaluating the benefits and costs of these alternatives with respect to the baseline costs. For example, present worth analysis methods can be used to equalize costs over different time scales. Alternate strategies may include not only assessing different SA functionality, but also different implementation scenarios. The following list provides examples of alternate implementation strategies:

• Do nothing: This baseline strategy represents a continuation of the status quo. It includes the benefits and costs of not implementing any form of substation automation that is not currently within the baseline.

• Life-cycle strategy: This strategy involves replacing equipment and systems only when their life-cycle indicates replacement and upgrades are timely. New equipment is added only as the new systems are eventually upgraded. Purely applied, this approach ignores synergies available through coordinated changes.

• Upgrade strategy: This strategy involves upgrading existing systems rather than replacing them, even though not all benefits may be realized by using this approach. Depending on circumstances and the benefits that may be realized, upgrades may offer less value than replacements, even though they may be less costly to implement.

• Realize benefits rapidly: This attempt to realize benefits involves replacing systems quickly. However, caution should be exercised because some benefits may be realized only if changes to utility practices or other systems are appropriately coordinated with these replacements.

• Phased implementation: Phased implementation involve adding substation automation first at locations that can benefit the most.

Hybrids of these strategies can also be assessed. For example, the SCADA system could be upgraded with SA functionality, even though its anticipated life cycle has not expired. Combining this with phased implementation could stretch costs over a number of years, avoiding high capital expenditures during a shorter interval.

3.2.4.1 Objectives and Priorities

Adopting technology for its own sake is a bad idea. Every potential change to an existing system should be viewed as a business proposition. A utility must be clear about the expectations and costs of changing to a new system.

Until the past decade, most improvements to substations were viewed in technical terms. It was a mentality born of a regulated industry. System reliability was the most critical interest. That philosophy has changed dramatically. Now, improvements must be viewed in business terms—benefits and costs must be used to make hard economic choices. Only in this way can a utility achieve the most valuable gains in the shortest possible time, given its resources. Even system reliability and its related technical issues can be honestly characterized in business terms.

Page 61: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-5

3.2.4.2 Migration Strategy

A migration strategy is an approach that considers a utility’s management priorities (tactical and strategic), its existing systems and assets, and its anticipated resources over time (for example, manpower availability, cash, and borrowing). Identifying where a utility wants to be in the next few years, and developing a plan to get there, are critical elements of a migration strategy. A well-considered plan is more likely to be successful over the long haul than reactive improvisation. Once such a plan is in place, it can be periodically reviewed to ensure that prior assumptions still hold. Otherwise, mid-course corrections can be made.

3.3 Project Organization

3.3.1 Identifying a Champion

A champion is someone who is committed to the outcome of an initiative and believes strongly, often passionately, in the value of a project. A champion may be the initiator of the project request. This person typically adopts the role of project visionary and missionary. The champion is fully committed, willing to commit time, has the authority or connections to secure approval of funds and allocations of people to the team, has political power within the utility, and has the management skills to carry the project forward. The champion is not necessarily the project manager, but may be a vice president or manager of the utility department who realizes the potential benefit from the completed project.

3.3.2 Selecting a Project Manager

Senior management should select the individual who leads the project management team. The project manager’s should have the following qualifications:

• In-depth experience in substation construction, operations, protection, and maintenance, as well as an understanding of the substation’s support role for other utility activities. An appreciation for process and technology, as it relates to success, is a plus.

• A personal belief that the smart substation philosophy is critical for moving substation objectives forward and essential for the success of the utility. Like the champion, the project manager must be personally committed to accomplishing the project mission.

• The budgetary and political support of senior and middle management to carry the project through to completion.

• Management and people skills to recruit competent, motivated team leaders and members with appropriate experience, and to manage/oversee the coordinated activities so that the project stays on track and moves forward to meet expectations in a timely manner.

3.3.3 Involving Stakeholders

Involving the stakeholders and ultimate users of a system from the beginning is key to the success of a project. For a substation automation project, it is critical to include all major

Page 62: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-6

departments and key individuals, including planning, engineering, operations, and maintenance. Success can only be possible if the project objectives are well defined, meet utility goals, and all possible stakeholders, users, maintenance, and operations staff have a say in the work and are fully supportive. Without this full cooperation, it is likely that critical requirements will be missed, project execution will be weakened, and acceptance of the final product will be critically impaired. In fact, some stakeholders may find just cause to complain at a later time and/or may be reluctant to use the final product.

Stakeholders include all organizations and individuals who have a vested interest in a successful project, as well as any others required for critical support. It is important to make an effort to identify a vested interest to engage all parties. It is the responsibility of project leadership and management to convince or supplant those who are not on board.

For a substation automation project, the following utility departments frequently have stakeholder roles. These are the parties who may be affected during implementation of the project or after it has been successfully commissioned:

• Planning (transmission, distribution, facility planning, communications, and asset management)

• Operations (transmission, distribution, and substations)

• Engineering (planning, design, standards, and operation and maintenance [O&M])

• Protective relaying

• Metering

• Purchasing

• Accounting, auditors, and historians

• Corporate users

• Market operations

Project team members are utility staff and stakeholders who are asked to dedicate time and effort during the life of the project. Core team members will likely be involved for the duration of the project. Others may only be involved in specific activities or if certain issues need resolution. All team members need to understand the project objectives, the organization, the relevant project requirements and plans as they unfold, and the project roles that they are expected to fulfill. Tools for facilitating these objectives are provided in this document.

3.3.4 Creating Project Teams

It is recommended that a smart substation project be organized around the four teams listed here (see Figure 3-1):

• Project management team

• Functional requirements team

Page 63: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-7

• System design team (planning and implementation)

• Technology team

The project management team is expected to guide the formation and composition of the other three teams.

One tenet should be rigorously observed, because failure to do so will jeopardize the success of the project—project team members need appropriate relief from their normal responsibilities to ensure that they have the time to effectively perform their project roles. They also need reassurance that their performance evaluations will include their project contributions. Otherwise, there may be a natural tendency to put in effort where it will be rewarded. These policy concerns are a responsibility of senior management, as they transcend the scope of responsibilities that belong to the project management team.

A utility is certainly free to modify these specific recommendations, as long as it believes the resulting process and structure will achieve its goals.

Figure 3-1 The Organization of Project Teams

3.4 The Project Team

3.4.1 Project Management Team

The project management team’s primary role is to ensure the successful completion of the project. That includes overseeing the project’s direction, timeline, resource utilization, and risk/success issues. If a serious problem develops, the team needs to address it. Otherwise, execution and management of project tasks should be appropriately delegated to the other teams.

Page 64: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-8

3.4.1.1 Team Composition

The project manager (who may or may not be the project champion) leads the project team. It is recommended that the project team should include the leaders of the other teams and a member of senior management (who serves as an advisor and a corporate liaison).

Business specialists having expertise with benefit/cost analysis, risk assessment, and project management tools are excellent resources for helping the project management team, and consequently the other teams, to make good project decisions.

3.4.1.2 Responsibilities

The project management team’s primary responsibilities include the following:

• Shepherding the adoption and approval of a project charter. This document lays out formative, high-level project goals, critical success factors, deployment sites, expected benefits, and constraints.

• Forming the other teams, including the recruitment of team leaders and other key personnel.

• Ensuring that a process is in place for project leadership to make timely and informed decisions based on reasonably researched recommendations from the team, so that the project can move forward smoothly.

• Overseeing budgets, schedules, and execution.

3.4.2 Functional Requirements Team

The role of the functional requirements team is to capture and document the substation’s functional requirements. These in turn will be used to guide substation design planning and implementation.

The charter for this team is a critical element that transcends customary substation design scope. This is true because the project intends to introduce new technologies and methodologies in ways that serve the utility’s interests best. If the utility intends to apply the results of this project to other substations (new construction or refurbishment projects), the quality of the planning is extremely important.

The consideration of functional requirements begins with the substation’s broad business objectives, which are subsequently broken down into component business processes. Next, common substation functions should be identified. By definition, these are common, stand-alone functional capabilities (for example, TRIP a specific breaker) within the substation, which can be reused by multiple business processes. Monitoring, control, protection, and automation application requirements are also part of this matrix, which derived to delineate the business process requirements. It is important that the requirements take into account such things as capabilities, consistency, flexibility, performance and timing, system openness, and security.

Page 65: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-9

This overall requirements framework must strive not only to accommodate current needs, but also to anticipate how the utility at large may want to have substation capabilities migrate in the future.

3.4.2.1 Functional Requirements Team Composition

Every substation stakeholder with a substantive interest in substation planning or the resulting capabilities must be directly represented. Otherwise, the project’s acceptance and credibility will be at risk, possibly after the project is completed. Personnel from the following areas are candidates for the functional requirements team (although undoubtedly, there may be others):

• SCADA engineering

• Protection engineering

• Automation engineering

• HMI engineering

• Substation O&M

• Installation

• Relay configuration and testing

• Control center (SCADA and other apps)

• Departments desiring automation capabilities

• Departments desiring access to substation data and functionality

The technology team works in liaison with the functional requirements team, helping to establish a reasonable requirements framework that can be adequately supported by available technologies and methodologies.

3.4.2.2 Responsibilities of the Functional Requirements Team

The responsibilities are laid out in the following process for capturing and documenting functional requirements. This process assumes that the team is starting from the beginning. An abbreviated or modified list may be more suitable, depending on circumstances.

• Review the primary system

Review and critique the primary system plans for the selected project site(s). Include the switchyard layout, bus configuration, power components, security provisions, and available interfaces for controlling, monitoring, and protecting the equipment. This will provide an initial frame of reference for the substation’s construction and equipment needs. As the task of formulating functional requirements progresses, continually review whether potential changes to the primary system might simplify requirements for the overall system.

Page 66: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-10

• Capture and document business processes

Capture and document the business processes that must be supported by the substation. These guidelines recommend an approach that stratifies the description of business processes at five levels: substation objectives, activities, capabilities, substation functions, and substation entities. Refer to Section 1.6.1 for a detailed description. Where applicable, specify timing constraints and/or performance requirements.

• Capture and document client access requirements

Clients include everyone who needs access to substation information or functionality to do their jobs. They include software applications, external systems, dispatchers, maintenance personnel, corporate users, and other utility departments.

A spreadsheet matrix of clients versus accessible data and functions will enable the system design effort to determine appropriate role-based access mechanisms. Where applicable, timing constraints and/or performance requirements should be specified.

• Capture and document contingency requirements for network communications and processing

Determine what critical secondary system scenarios may develop and what contingency requirements are needed to counter them. A good starting point may be to consider what situations could develop that might inhibit critical protection, control, monitoring, or automation functions. This takes some imagination. The functional requirements team should specify requirements for remedial design measures.

• Capture and document O&M requirements

Determine the O&M capabilities needed to maintain and operate the substation in various situations. As a guide, procedures that have been used traditionally should be reviewed to identify what they have been able to determine how to get better results in a networked, communications-based system.

It is important to consider system management functions. These include information about the health and operational status of the technology used to implement the secondary system. This information is useful for managing, securing, and administering that system. It can be delivered to associated applications for evaluation and status reporting via the communications network.

• Capture and document security requirements

Define substation security objectives (that is, what the utility wants to protect against). These should be stated in high-level, nontechnical terms.

3.4.3 System Design Team

The system design team is responsible for two sequential phases of activity—system planning and system implementation. Keeping these two activities separate allows the project management team to set up a gated approval process between planning and implementation. This lends more integrity to the design process, which is especially important when current practices are being challenged by new ones. It allows responsible parties to consider all relevant aspects of the proposed, new landscape before implementation is moved forward.

Page 67: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-11

3.4.3.1 System Design Team Composition

Table 3-1 identifies various stakeholders who can involved in the system design team. Stakeholders can include any utility representative with a substantive interest in substation design planning, design implementation, system use, or realized capabilities.

Table 3-1 System Design Team Composition

Members System Planning Roles

Protection, SCADA, automation, and communications engineering

• Plan the system design to meet the functional requirements

Departmental personnel who must execute the design

• Provide design inputs and critique the system design; ensure that the system design can be satisfactorily implemented

Departmental personnel who must live with the completed system (that is, the system clients) who can include the following:

• Principal suppliers (that is, devices or subsystems having communications, monitoring, control, protection, and/or automation capabilities)

• Protection, SCADA, automation, and communications engineering

• Departmental personnel who must execute the design

• Provide design inputs and critique the system design

• Provide guidance regarding product capabilities, configuration, installation, test, and use

• Ensure that the system design plan is followed during implementation

• Implement the system design plan, (purchasing through commissioning)

• Ensure that the planned and implemented system meets their anticipated needs

The technology team works in liaison with the system design team during both phases, providing guidance for planning, use, and integration of technology.

3.4.3.2 System Design Team Planning Responsibilities

The following subsections discuss the primary planning responsibilities of the system design team.

• Review primary system design plans

Review the primary system plans and layout for the selected project site(s). Include the switchyard layout, control house, bus configuration, power components, security provisions, and available interfaces for controlling, monitoring, and protecting the equipment. This will provide an initial frame of reference for the substation’s construction and equipment needs.

Page 68: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-12

• Review functional requirements

Review and critique the functional requirements documents provided for the project by the functional requirements team. The secondary system design plans must be directed toward satisfying these requirements in the most appropriate way.

The only preexisting substation design assumption is the use of a networked communication system based on an Ethernet LAN and the IEC61850 communications standard. All other system design decisions should leverage use of these assets in the most appropriate way.

• Propose design plans: Identify generic devices, their applications, and their system roles

Responding to the functional requirements, the system design team should use its experience, system knowledge, and imagination to create a straw-man secondary system. Generic (that is, placeholder) devices and applications for fulfilling the functional requirements submitted by the functional requirements team should be identified. In the team’s mind, these placeholders must represent items that it thinks can typically be purchased in the marketplace.

Distribute the working set of substation functions and software application modules (SAMs) among the placeholder devices, arranging these to best satisfy requirements and design instincts. Evaluate how each business process would operate with that arrangement. Review the functional requirements to determine what works well and what does not.

To resolve problems, redefine placeholder devices and/or the distribution of substation functions and software application modules, so as to better satisfy functional requirements and design criteria. Several iterations may be required before the design process begins to crystallize. The things that do not work in the first attempt provide strong clues about the adjustments required in the next attempt. Note that programmable logic offers flexibility in how applications are partitioned into modules for distribution among devices. Stand-alone and bundled software applications may be less flexible.

Other factors may influence how placeholder devices are selected, equipped, and used. In particular, refer to the following information regarding designing for contingency requirements.

At some point, the system design team will settle on a plan that it believes best satisfies functional requirements and design criteria, both technical and nontechnical. At this point, the placeholder devices and applications should be informally documented with description of their functionality, placement, attributes, and system roles.

The following list provides examples of generic placeholder devices, although the system design team may decide to identify some more narrowly:

– Protection relays (of various types)

– Metering device

– Phasor measurement units

– Power quality devices

– Digital fault recorders

– Automation controllers

– Proxy server/substation computer

Page 69: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-13

– Communications equipment

– HMI

• Address contingency requirements for network communications and processing

A networked communications system can be leveraged to support rather sophisticated capabilities, such as the ability of a system to continue operation in spite of failures. Consider the following issues and questions in light of the contingency requirements submitted by the functional requirements team:

– If there are multiple components of the same kind (for example, line breakers) in the primary infrastructure, it may be desirable to assign multiple secondary system devices (for example, overcurrent relays) in a one-for-one manner. The reasons may include use of the identical software, identical hardware, and the convenience of physical proximity.

– What happens when any specific placeholder device fails? Is a contingency mode of operation feasible, whereby substation operation can continue, even with acceptable degradation? What would this require in terms of placeholder devices and their responsibilities?

– If any specific placeholder device fails, what are the consequences? Are too many critical resources associated with the same placeholder device? Distributing them among several devices may be the right approach.

– Can critical functionality be replicated in two devices, so that it is still available if one of the devices fails? This would require that devices and their applications be able to tell when other devices fail (for example, through interlocks) that they be able to redirect messaging to non-failed devices with the same capabilities. There are certainly numerous opportunities for devices to cooperate when abnormal conditions occur (for example, device failure, device in test mode, and device off-line).

• Identify IEC61850 logical nodes for each substation function, each application module, and each IED

After a straw-man system configuration has been selected for the secondary system, there is one remaining loose end. The set of IEC-61850 logical nodes (LNs) associated with each device, each application module, and each substation function must be documented. Only then will there be a firm basis for specifying IEC61850 communications. Logical nodes are the source and destination of all IEC61850 substation communications. Once the available LNs are known and documented, the communications system can be evaluated to determine which modes for information flow are most appropriate (for example, polling, reports, or multicasting).

• Prepare design and procurement specifications

Prepare design and procurement specifications that capture the project design plans and design philosophy. To improve the reusability of these specifications, document different aspects of the overall design separately. Where applicable, include IEC61850 communications support (for example, required logical nodes, required services, network interface provisions).

Page 70: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-14

This may be done using the following tools:

– IEDs (a separate specification for each type)

– Applications (a separate specification for each; include performance and timing requirements)

– Communications equipment (for example, routers, network switches and hubs, network cabling and media converters, and power converters)

– Special computer-based systems (for example, HMI, engineering workstations, and test systems)

Address traditional specification issues if they are important to the project. Examples are size limitations, mounting requirements, power consumption, configuration and maintenance tools, documentation, display capabilities, training, and warranties.

• Qualify and select available products

When the system design team has settled on what it believes to be the best plan, the true test is the qualification of products. In other words, the team must be able to fully implement the plan. One or more suitable products must be qualified for each placeholder device and software application module (SAM). The team is encouraged to stay mainstream, not relying on special features that cannot be easily replicated in another product. The selected devices and SAMs must fulfill the requirements assigned to each placeholder device, and the team must ensure that each product can be configured or programmed for its assigned substation functions (SFs).

Make sure that the fit is comfortable at both the specification and gut level. If there is a problem, the team must reconsider its definition of placeholder devices, SAMs, and/or its distribution of substation functions. With additional work, it is assumed that the system design team can arrive at a satisfactory design.

Depending on the levels of IEC61850 communications support offered by the selected products, the substation configuration language (SCL) feature of the IEC61850 standard may be used in the project. If not, it can be brought into play at an appropriate future time. SCL is an important concept for reducing data management costs in these systems and for allowing convenient reuse of prior implementations (or variations of them).

Even if this design process turns out to be taxing, the system design team should realize that they are creating a set of best practices that can be adopted for other substation projects and gradually improved.

• Critique control house and primary system layouts

As a stable system design plan emerges, the system design team should critique the control house and primary system layouts for improvements that would improve overall system design. Even if the targeted layout features are already set in concrete, documenting these recommendations will position them for consideration in the next substation project.

Page 71: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-15

3.4.3.3 System Design Team Implementation Responsibilities

These tasks are focused on the implementation responsibilities and activities of the system design team. The topics listed below represent a proposed segmentation of their overall assignment.

• Purchasing

Qualified substation devices for use in the secondary system must be purchased for both bench testing and for installation at the project site(s). Two points should be noted:

– Attempting to use a common group of equipment for both purposes can lead to scheduling problems. It may be necessary to install devices at the substation at the same time that continued bench testing is required.

– Without the full complement of devices to be installed at the substation, it is very difficult for bench testing to fully simulate the operational scenarios that occur in the field. Even a full complement of devices falls short, because the full substation environment (for example, external connections, auxiliary equipment, primary system) cannot be replicated in a laboratory setting. Nevertheless, bench testing is a good way to wring out basic system and equipment problems.

• Configuration

Each piece of equipment in the secondary system will have its own configuration requirements. At present, configuration is generally accomplished via proprietary means, although eventual adoption of IEC61850’s substation configuration language (SCL) by suppliers should lead to use of open means.

The configuration of each piece of equipment in the secondary system needs to be documented for system design and maintenance purposes. This includes equipment used to implement the communications system.

Configuration documentation should generally cover the following items:

– Hardwired I/O

– Hardwired jumpers

– Power connections

– Communications port and network port connections

– Configuration files that govern use of the communications system (for example, IP addresses)

– Configuration files or parameters for application software

– Data management files (for example, objects enabled for use) for both devices and applications, governing their use of IEC61850 communications

• Bench testing

While not effective for fully simulating operational substation scenarios, bench testing can be an effective tool for finding basic problems in secondary system devices, applications, configuration tools, and testing tools. The following discussion identifies areas where bench testing should be applied. System testing is addressed more comprehensively in Section 6.

Page 72: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-16

Like other forms of testing outside the actual deployment site, bench testing has certain limitations. First, the actual system being monitored and controlled is not present, so system responses must be simulated to the extent that such an approach is useful and feasible. Second, the number of networked devices available for bench testing is often limited to a fraction of the total number to be used in the system. This limits the completeness of the testing, but it still enables basic problems to be wrung out of the system implementation.

This approach is also consistent with the need to scale-up testing in projects that include large numbers of field devices. It is much easier to resolve issues with 10 devices than with 2000 devices. A technique that has worked well in the past is to scale up the projects by initially installing perhaps 10 devices, and resolving any issues that appear before expanding the scale of the installation. In this example, the next step should be limited to 200 devices, and following that, the full number. This approach typically enables faster testing and debugging, as basic problems are resolved in a less-complex setting, and the setting becoming progressively more reliable as it is scaled up.

Testing needs to be supported with appropriate test plans and procedures. The following list identifies various types and uses of tests:

– IEC61850 conformance testing

This testing applies to the individual substation devices, systems, and stand-alone applications that communicate using IEC61850. The testing must verify that the following items conform to both IEC61850 specifications and project requirements:

o Communication objects (structure and content)

o Communication services

o Communication profiles (stack structure and operation, including constituent protocols)

o Even if independent conformance testing is performed on the products using IEC61850, the utility may require extensions to communication objects that will must be verified.

– Verifying network operation

The following network operations must be verified:

o That individual devices, subsystems, and applications within the secondary system operate over the substation LAN with adequate throughputs, acceptable latencies, consistency, and support for an adequate number of concurrent network connections. The quantitative specifications for these requirements will be developed during the course of the project, before final project commitments are made for specific devices, systems, or applications.

o Testing also has to confirm that devices (1) only respond to their configured IP addresses in connection-oriented mode, and (2) are able to receive and interpret multicast messages properly in connectionless mode.

o That overall system traffic doesn’t exceed a 20% of network bandwidth under the near-worst-case conditions expected during actual system operation. A testable, near-worst-case scenario must be developed with plausible justification for its choice.

Page 73: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-17

– Verifying electromechanical interfaces

Electromechanical interfaces include RS-232, RS-485, modem, ST fiber-optic, and other standard or proprietary interfaces used to interconnect equipment and communication facilities. Testing must verify that these interfaces operate properly, including any optional capabilities being used by the project.

– Verifying logical connections

Logical connections are used to represent connection-oriented communication links between software application modules (SAMs) located on different system platforms. Using the IEC61850, seven-layer Ethernet profile, these links are handled by communications services that manage make, break, or abort associations between applications. The requirement here is verification that all logical connections, provisioned by the overall system configuration, do in fact work. The ability of each logical connection to consistently transfer information via network messaging is sufficient to verify the lot.

– Verifying functional interfaces

Functional interfaces use structured mechanisms to convey status between and among software application modules in different substation devices and/or subsystems. Two mechanisms can be used, as described below, although the second one is preferred:

o Hardwired contacts: This relies on a physical, hardwired contact to convey the value of a single binary status point. This traditional mechanism has been used in almost all cases to date to interlock cooperating protection relays. The disadvantage is that it requires point-to-point wiring between every pair of interlocked relays, which increases installation costs and limiting flexibility.

o Virtual connections: This mechanism uses IEC61850 multicast messaging over the network to deliver multiple status values to peer devices. Recipient devices read these messages for the particular status (that is, virtual connections) they have been configured to monitor.

Each functional interface has to be verified for proper operation. This goes beyond verification of external connections, requiring that the information transferred from one device to another is properly interpreted, is conveyed to the proper software application module, and causes the expected action. All possible scenarios have to be tested.

– Verifying application behavior

One can typically model software application modules (SAMs) as an assemblage of interacting functions, supported by a set of configuration parameters, a set of inputs, and a set of outputs. The configuration parameters and inputs determine how the application program behaves, and the outputs are generated according to the designed purpose of the application. The outputs affect the external environment in a purposeful way.

When an application is confined to running on a single platform, the interworkings of its functions are generally hidden because it behaves like a black box. But when an application (that is, its function set) is broken into several pieces and distributed among different platforms, functional interfaces must be exposed. The kinds of functional interfaces to be used in this project were discussed previously (verifying functional interfaces). Where a communications interface is used, it means that some available

Page 74: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-18

communications service is used to transparently convey information from the sending application function to the receiving application function. Certain types of IEC61850 peer-to-peer services have been designed exactly for this purpose.

It is not unusual for substation applications (especially protection applications) to be split up among platforms this way. Protection applications often work throughout a physically extended portion of the facility. Therefore, there is an intrinsic advantage to having such an application distributed among different protection relays so that those relays can cooperatively operate to fulfill the application objectives. In recognition of this, many smart protection relays support programmed logic. If protection departments implement this capability wisely, they can derive a set of reusable program modules that supports feeder protection, another set that supports bus protection, yet another that supports breaker failure protection, and so on. Through a clever configuration strategy, a set of program modules may even support several protection applications.

The bottom line is that there must be a methodology for verifying that distributed (and nondistributed) applications behave as intended. In the case of distributed applications, this verification must apply to each distributed module. The methodology may use predetermined sets of inputs and configuration parameters while monitoring application outputs through the communications interface. Undoubtedly there are other effective approaches.

– Verifying operational performance requirements

Testing must be performed to ensure that communications, devices, and applications satisfy the performance requirements and timing constraints specified by the functional requirements team.

– Verifying contingency modes of operation

Contingency modes are designed into the system to allow it to continue operating (perhaps in a degraded manner) when a device fails or is otherwise unavailable (for example, undergoing maintenance). These contingency modes must be verified to ensure that they work as intended.

• Factory acceptance testing

This is another utility option for screening and testing purchased systems and system components. Like bench testing, it is difficult to assemble a viable representation of the system at one vendor’s test site. Basic problems can be revealed, but such opportunities offer limited time for testing. Bench testing has some advantages, as tests can be run for a more extended time, and usually with more flexible configurability. Site testing is obviously more effective, but it generally has the disadvantage of being a less convenient venue. Testing must be supported with appropriate test plans and procedures.

• Site installation

The system design team must outline a plan for installation of the secondary system at the substation site.

• Site integration

The system design team must prepare a plan for integration of the installed secondary system.

Page 75: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-19

• Site testing

A site acceptance test is recommended for verifying that the installed, integrated system satisfies the requirements prepared by the functional requirements team and satisfies the system design plan. Testing must be supported with appropriate test plans and procedures.

• Maintenance

After the system has been placed in service, maintenance tools and procedures are needed to maintain the project site during the integration, testing, and commissioning phases, and on through normal O&M activities. In a break from the past, these tools and procedures are expected to be network-based.

• Commissioning

A site-commissioning plan is recommended for integrating and checking the system with the following client systems (others may be added):

– Local HMI

– Operational Control Centers

• Other issues: IEC61850-related

There are other IEC61850-related topics that must be discussed initially by the technology team, and later with the other teams. Other issues will be added as they are discovered.

– Requirements for device test data, generated while a networked device is in test mode

– Device requirements for providing system management information (for example, status, reports, and/or journals regarding device health, operating mode, connectivity status, local view of system status, and statistics)

– Self-description for components of the communications object models

• Other issues: Traditional

In addition to the new, strategic planning and implementation issues discussed in the body of this document, there are a number of traditional, tactical issues that must be addressed by the system design team (to the extent that they are applicable). Some of them are listed here; others will undoubtedly must be added as their absence becomes apparent:

– Time synchronization

– Hardwired I/O connections to the primary system

– Hardwired I/O connections among secondary system devices (where allowed)

– Power supply requirements

– Use of serial communication ports for local device access

3.4.4 Technology Team

The technology team’s role is to ensure that the project appropriately applies the IEC61850 communications standard and related technologies in its development of system requirements, design plans, and design implementations.

Page 76: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-20

3.4.4.1 Technology Team Composition

The technology team should ideally have three or four members, led by an individual with exceptional engineering experience in the planning and implementation of substation secondary systems. This leader should be familiar with traditional integration practices, especially with those involving communications, and with the basic tenets of smart substation practice. This individual should be a longer-term employee of the utility, who understands the substation’s existing and pending relationships with other departments and systems. A second member must have expertise concerning IEC61850 and its practical application, as well as related technologies involved with smart substation planning and implementation. This member should also have a strong background in substation secondary systems. A qualified consultant may be considered for this position. The other members may have expertise and experience in related areas (for example, protection planning and implementation, telecommunications, or RTU integration), but all members should be primarily focused on realizing integration goals.

3.4.4.2 Technology Team Responsibilities

The technology team is responsible for the appropriate application of IEC61850 and related technologies to system planning and implementation efforts. It is also responsible for the overall integration integrity of the project. In this sense, the technology team performs a high-level, technical management function, ensuring that all project efforts coalesce to produce an effective, unified, satisfactory result.

The technology team accomplishes these goals by providing guidance to the other teams regarding organizational process, tools, methodologies, implementation approaches, and any other disciplines necessary to achieve success. It relies on the utility expertise of the other teams to properly identify requirements and responsive design goals.

3.5 The Project Management Roadmap

Project management is a multi-disciplined art that requires exceptional skills, vigilance, balance, and judgment. The project management team is responsible for ensuring that the flow and progress of the project is in keeping with a successful conclusion. The term process is used here to address the various activities that must be coordinated during the course of the project. Several of these are addressed in the following subsections.

3.5.1 The Project Charter – Vehicle for Launching the Project

When a project is initiated, one of the first steps should be the preparation of a project charter. An approved Charter provides goals, direction, and constraints for the project and authorizes it to begin. Senior management typically approves the project charter. The exact content depends on a utility’s normal practice, but the following topics are recommended.

Page 77: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-21

3.5.1.1 Purpose and Objectives

The purpose and objectives reflect high-level, realistic expectations about what the project will achieve. Statements about how the expectations will be achieved should be avoided, unless those elements are core assumptions and mandated. For example, a premise of networked communications based on IEC61850 is probably appropriate, although some qualifying context for applicability may be required.

3.5.1.2 Critical Success Factors and Risks

Critical success factors are things that must meet stated expectations as the project progresses. For example, they may include achieving certain functional or performance goals or completing certain tasks by specified dates. They are all tied to recognized risks, and are a means to evaluate, at certain junctures, whether the project can still be successfully completed. Project personnel must understand these factors early in the project, so that the risks can be cooperatively managed as well as the situation permits. If a success factor falls into jeopardy during the course of the project, it becomes a trigger for the project management team to reevaluate assumptions, direction, and alternatives. For this reason, gratuitous content and truisms are seriously discouraged; if a factor does not carry critical weight, it should be omitted.

Critical success factors are a prominent part of the project charter, so that they may be continually referenced at each stage of the project and when making decisions. They are touchstones for project guidance and vital to the success of the project.

3.5.1.3 Deployment Sites

The choice of deployment site(s) is part of the planning process. The decision is often less obvious for pilot projects than for production deployments. A suitable location needs to be appropriate for the project work to be done. Other considerations include the traveling distances involved for key personnel and the site’s proximity to other company facilities.

For pilot projects, the decision process will often consider potential line projects that can serve as a host. If a pilot project can be dovetailed with a line project, overall costs may be reduced and project benefits can be more tightly integrated with existing utility practices. It is important to guard against project implementation that ends up being isolated from everyday utility practice and the people who perform it, because it will be more difficult to prove the project’s worth to departmental line groups.

3.5.1.4 Expected Benefits

These may include new capabilities and/or improvements to existing ones. They may include cost reduction or better value, based on presented assumptions, calculations, and a supportive rationale. In these cases, quantified expectations should be stated.

Page 78: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-22

If a pilot project is being initiated, the benefits may include gaining experience with new technologies and determining how best apply them. The benefits may also include solving some key problem that currently prevents a line group from achieving a business process breakthrough.

3.5.1.5 Constraints

Constraints almost always relate to the real world issues of time and money. Closely related is manpower—identifying the resources that will be made available to support the proposed project. The project charter should characterize the business priority, emphasis, visibility, and resources to be afforded the project. The more specific this is, the more useful it will be to project management as it deals with competing priorities. Depending on the stakes involved, the project’s priority may lie anywhere between low and critical.

In any case, the charter needs to include a schedule and a budget. If these are designated as preliminary, the charter needs to identify how and when they are to be solidified. This may depend on the results of preliminary tasks, designed to narrow alternatives and/or acquire information sought for making final planning decisions. These decisions may determine if and how the project will continue to move forward.

3.5.2 Management Dynamics

Management dynamics is a term that expresses the collective people skills, vigilance, and judgment required to manage a project that has a plan, but that is operating in largely unexplored territory. Even if the project activities have been performed in other places, the individuals involved in the project often do not have direct experience in the tasks they are handling. These are the qualities that differentiate projects with a firm foundation of experience from the those described in his report. Naturally, these are challenges that make the project management’s job more exciting. Some aspects of these management dynamics are described in the following subsections.

3.5.2.1 Building Teamwork

Building a project team that works effectively is a very challenging task. The project team is responsible for completing the project using resources within the utility as well as outside resources such as consultants and the vendors who provide the SA equipment and systems. When outside resources and individuals from multiple internal departments are combined on a team, fostering commitment and shared goals is crucial to building an effective team that can produce the expected results. All team members must understand the objectives, have their management’s commitment with regard to time and resources, and have the skill sets to complete their assigned tasks.

Building an effective team starts with good communication and a clear, mutually accepted vision of the project as expressed in the project charter. Team members should be chosen for their ability to work successfully as part of a team, their expertise in their assigned project tasks, and,

Page 79: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-23

equally important, their availability to put in the time and effort needed by the project. Good candidates have a bias for action, are in a position to get things done, and are individuals who have influence in their respective departments. Ultimately, the project manager and the utility champion who have the responsibility to build effective project teams and to monitor project progress, must have the authority to enforce team commitments.

3.5.2.2 Delegation

To the extent possible, the project manager should delegate appropriate project management responsibilities to other members of the project management team, especially the other team leaders. The same approach should be used regarding planning and implementation responsibilities. Delegating allows other responsible parties to accept project ownership and helps to ensure that one individual is not overwhelmed with project responsibilities. By delegating effectively, the project manager should be able to stay above the trenches, spend time maintaining a good perspective on the project’s progress, and ensuring that the project proceeds successfully. To accomplish this, of course, good communication is absolutely important.

3.5.2.3 Fostering Good Communication and Problem Solving

Effective communication is critical to a successful project. Effective communication is timely and reaches the right people, sharing the necessary information to meet project objectives and keep participants engaged.

To facilitate this, the project management team must ensure that there is a communications process for sharing project documents and information. People affiliated with the project must know what project documents and information are available (or planned) and how to gain access to them. Communication must be designed and organized for the target audience.

Good communication can also provide utility-wide visibility, publicize achievements, plow ground for a follow-on project, and ensure that other parts of the utility do not initiate efforts that work at cross purposes to the current one. No project exists in a vacuum. It is important to make the project’s goals, work, and achievements visible to the rest of the utility. Those who can potentially benefit from the project, but who are not directly associated with it, must be brought along and included in regular communications. In the long run, if others continually see the project being conducted in an open way, with the effort to solve the problems that affect them, they will likely develop a favorable impression of the project and support its work.

3.5.2.4 Maintaining Project Documents

As soon as a project is conceived, a project file should be started to maintain the documents discussed in Section 3-7. The process of keeping, organizing, and maintaining project documentation should not be viewed as a chore without rewards. Frequently, it is the only resource that allows project management to keep its sanity in a complex, information-rich environment where there is no autopilot option.

Page 80: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-24

3.5.2.5 Training

There is probably no more effective step toward ensuring the success of the project than providing appropriate training to the project team members. The training not only equips members to deal with what might otherwise be an intimidating venture, but it enables them to assume ownership of the project and their roles within it.

Potential training topics are listed in Table 3-2. Skills-related training should be selectively provided prior to the time that those team members will need to apply it. An introductory orientation course (Item 1 in Table 3-2) should be made widely available to team members at the earliest feasible time to create an appropriate sense of mission.

Table 3-2 Training Topics

Item Training Topic Provided by

1. Using Network-Based, IEC61850-Based Substation Communications: Introduction

A knowledgeable utility employee or consultant

2. Using Network-Based, IEC61850-Based Substation Communications: Planning And Implementation

A knowledgeable utility employee or consultant

3. Using Network-Based, IEC61850-Based Substation Communications: Integration, Testing, And Documentation

A knowledgeable utility employee or consultant

4. Equipment Capabilities, Configuration, and Support for IEC61850 Communications

Equipment suppliers

5. Equipment Installation, Setup, Validation, and Troubleshooting

Equipment suppliers

6. Stand-Alone Software Applications: Functional Capabilities and Support for IEC61850 Communications

A knowledgeable utility employee or appropriate provider

7. Programmable Logic Modules: Functions, Interfaces, and Linkages to IEC61850 Communications

The PLC-based equipment supplier

8. HMI: Functional Capabilities and Support for IEC61850 Communications

A knowledgeable utility employee or HMI provider

3.5.2.6 Tracking Progress, Budgets, Schedules, and Resources

Using progress reports and open communication with project teams, project management must keep track of what is happening. Activities and developments must be tracked against the working budget and schedule expectations. The results must be regularly communicated to the team, especially if corrective actions are necessary. Priorities or assignments may have to be adjusted, perhaps only for the interval needed to get project coordination back on track. Chronic problems require a harder look at leadership, resources, or goals.

The project teams and their members must be acutely aware of scheduled start times, durations, and interdependencies among their tasks. While there is usually no need to make temporary problems more widely visible, team leaders and members should be sensitive to the

Page 81: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-25

consequences of holding up other aspects of the project. In those cases, warnings should be provided in time to allow adjustments in lieu of disruptions.

On the utility side of the project, cost forms and time sheets typically provide a mechanism for cost and budget accounting. For outside services, monthly reports can provide these inputs. The project manager should ensure that project costs are correctly allocated.

An integrated package, such as Microsoft Project, may be used to document the overall plan, tasks, schedule, and resource budgets. Commercially, there are more than 50 different packages available to accomplish this. Utilities often have standard established practices regarding the packages that are accepted by management. Such tools often provide templates for entering information, and provide report formats for monitoring progress, monitoring resources and expenditures, presenting schedules, and identifying problems. If accounting information can be directly entered into the tool, it saves time while reducing errors. For the simplest projects, a spreadsheet may the easiest and best tool to use.

3.5.2.7 Evaluating Project Work

As project tasks move forward and teams complete their milestones, it is useful to hold project reviews to examine and critique the results. These reviews allow the teams to present their progress, problems, solutions, and rationale. Project management, stakeholders, and members of other teams can ask questions and probe. Not infrequently, these reviews identify weaknesses and provide opportunities to correspondingly tweak the solutions. The other teams get a better idea of how their efforts need to coordinate with those presented.

The criteria for evaluating technical project work should include emphasis on the following (as appropriate): reliability, effectiveness, flexibility, reusability, maintainability, relative simplicity, scalability, acceptable risk, alignment with current or emerging industry practices, and synergy with other parts of the project effort. There are undoubtedly other important qualities that the project management team will want to add.

3.5.2.8 Arbitration

During the course of the project, differences of opinion may arise concerning technical issues or decisions about how to proceed in some aspect of the project. The individual team leaders should be encouraged to resolve these issues within their own teams and between teams. Occasionally, however, occasionally a difference of views may arise between certain groups (for example, the functional requirements team and the system design team). The requirement team may believe that a certain capability is necessary, but the design team may find that the corresponding design planning aspects are onerous. In such cases, the project manager or a member of the management team may consider acting as a neutral arbiter to help resolve the impasse in the best interests of the project.

Page 82: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-26

3.5.3 Benefit/Cost Analysis

Benefit/cost analysis is a mainstream management technique for deciding project and program priorities. The results help determine what gets high visibility and support and what gets put on the back burner (or in the trash). Simply put, for a proposal to be considered worthwhile, it must demonstrate attractive benefits relative to its cost.

In the course of performing a benefit/cost analysis for a proposed project, the same technique can be applied to alternate approaches for structuring and conducting the project, because this affects its evaluated cost.

The technical aspects of a benefit/cost analysis take into account the different costs, benefits, risks, and schedules associated with the proposal. Methods must be used that allow “apple-to-apple” comparisons. Benefits must be quantified, even though is often difficult to quantify qualitative benefits. Present worth costing, using a utility’s financial discount percentage, can be used to align future costs with this year’s dollar, while risks can be converted to percentages multiplied by the associated benefit or cost. After these numbers are calculated, the benefit-cost ratio is determined by dividing benefits by costs. Any result greater than 1 has a net benefit. This benefit-cost analysis process allows alternate proposals and alternate approaches to be weighed to determine which one is best under the prevailing circumstances. Sometimes the most favorable approach is to do nothing.

Benefit/cost analyses can be performed by consultants who have the tools and generic expertise to evaluate substation automation. Nevertheless, they will need specific information from the utility regarding its power system configurations, strategic management missions, baseline costs, needs, and so on. Anything that significantly contributes to costs and benefits for the proposal under consideration is necessary for reaching a valid conclusion. Such studies can also be carried out in-house with the use of an economic analysis program (EAP) to calculate values. EAP programs enable the utility to accomplish four tasks:

1. To organize relevant system cost data and criteria (for example, staff costs, schedules, recurring communication costs, recurring maintenance costs, cost of money, inflation rates).

2. To identify potential benefits and losses associated with any specific proposal, as well as those associated with prevailing circumstances.

3. To calculate an annualized, present-worth value for any specific proposal (including the status quo), while allowing schedules, functional groupings, and other predetermined constraints to be varied to alter the proposal.

4. To conduct deterministic and probabilistic sensitivity and risk analyses of the results. The following input parameters can typically be varied during a sensitivity analysis: inflation rate, load growth rate, utility discount rate, application benefits, current system availability degradation, current system maintenance escalation, procurement costs, implementation schedule, and implementation risk.

Page 83: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-27

The real value of benefit/cost analysis is that the project management team can use it in the interval leading up to the project, during preparation of the project charter, or during the course of the project. In the latter case, prevailing project cost data can be used and more may be known about anticipated benefits.

When focusing on alternate strategies, the team can focus on important concepts without worrying about the mechanics of many different approaches. The EAP programs not only show the difference between the benefits and costs for any particular approach, but also determine which factors are the most sensitive in each approach. The output of the EAP programs may be used in conjunction with a decision analysis technique to produce a combined evaluation of the quantitative and qualitative attributes of each system approach. By incorporating a rigorous and comprehensive treatment of the system benefits and cost, the programs can produce effective guidance for deciding budget, schedule, and resource issues.

It is important to note that the application of IEC61850 and related technologies to substations will likely result in a major benefit associated with integration flexibility and improved maintainability. This benefit may be assigned an economic value. This new integration flexibility will facilitate major application changes over time without the traditional fork-lift replacement costs. Most of these savings can be attributed to reductions in labor-intensive trenching, rewiring, reconfiguration, and the like. Similarly, with good network management and application management tools, a flexible network approach will be much less expensive to maintain over the operational phase of the system life cycle. This can be attributed to fewer protocols, simpler databases, self-defining devices, and new capabilities to diagnose and correct problems.

After benefit/cost analysis has been used to plan an SA project (that is, a project charter), the project can begin in earnest. To ensure that the system continues to meet the utility’s operating needs, the analysis should be conducted again every three to five years to provide ongoing guidance.

3.5.4 Risk Assessment and Risk Management

Managing risk is critical to project success and meeting the objectives in the project charter. Risk assessment and management must accompany the initiation of the project and continue throughout the life of the project.

Page 84: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-28

3.5.4.1 Risks for a Project in Progress

The following items are among the highest general risks faced by a project in progress. There are additional risks that are specific to the project being undertaken. Note that many of the following problems are nontechnical in nature:

• Gradual expansion of project scope, if the project is allowed to proceed without formal adjustment of the budget, schedule, and project plans, can do great harm to a project.

• Poorly written project design and procurement specifications. If a specification is too loose or incomplete, the resulting ambiguity may affect procured products, system integration, testing, and seriously threaten the successful completion of the project. In the best case, it will disrupt the budget and schedule.

• If an SA project is being hosted by a line project with a firm schedule, schedule slippage in the SA project may jeopardize its continuation.

• If vendors fail to meet their development or delivery schedules, the project may suffer a disruption of project team activities or perhaps a major project schedule disruption.

• If delivered products do not perform as intended (for whatever reason), it creates a serious imposition on the project teams to discover why. The project schedule and budget will suffer as well.

• Some staff may have competing responsibilities in their normal jobs. If employees do not have sufficient relief from their normal responsibilities to cover their project roles, or if they believe they are being evaluated solely on the basis of their normal responsibilities, they will focus on the work that they believe will be rewarded.

• Some staff may leave or be reassigned. For a project of multiyear duration, the risk of this is higher.

• Requirements may change as stakeholders become more familiar with the project or as environmental, legislative, financial, or utility policies change.

• The senior manager in charge of the project may change. The replacement may have different priorities.

Pilot projects may run into unanticipated difficulties, leaving the promised project benefits in doubt. The best defenses against these ills are diligent project management, good judgment, checks and balances (for example, peer reviews), a comprehensive and clear project charter, team training, a scope-change process, and a high-morale project environment.

The scope-change process must never allow a change without reviewing its impact on resources, benefits, schedule, budget, and objectives. If the impact is negative on resources, schedule, or budget, senior management would need to approve changes to keep the project in balance (assuming that they support the change).

Page 85: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-29

3.5.4.2 Risks After a System Has Been Placed Into Service

Risks that occur after a system has been placed into service can include device failures that can potentially bring substation communications or processing down. Similar concerns may involve maintenance operations, whereby a device is temporarily unavailable to the network. With respect to these issues, contingency requirements for network communications and processing have been included as responsibilities for the functional requirements team (Section 3.4.2) and the system design team (Section 3.4.3).

3.5.4.3 A Description of the Risk Management Process

The following list shows the steps in the risk management process:

• Identify the risks and select those that will be managed: Determine the likelihood that each risk will occur and assess its impact on the system. Focus on critical success factors, such as key SA applications and/or critical data and information. Critical success factors are one of the recommended components of the project charter.

• For each risk to be managed, determine an appropriate mitigation strategy. Initial risk levels may be low, medium, high, or critical, and implementing the mitigation strategy should significantly reduce that risk. Note that the mitigation strategy cannot ensure that the risk will not materialize.

The acceptability of a mitigation strategy and its associated implementation cost is determined by the anticipated cost exposure (that is, the cost of taking a hit should the risk actually materialize). Once the available options are known, project management can adopt the most attractive one(s).

Two examples of mitigation strategies are:

– Having backup individuals participate can mitigate the project staffing risk.

– Reviewing objectives and conducting design reviews to examine prior expectations in light of actual findings can minimize a technical risk.

• Provide backup paths. For example, retain current SA systems for paralleled operation in those areas involving critical substations or provide for data backup. Be ready for a complete cutover to a manual operation in case communications are lost or some critical feature is lost. If a piece of hardware could kill the project if delivered late, consider an alternate source for procurement and be ready to activate the backup contract.

3.5.4.4 Using a Formal Process

The following questions lie at the base of a more formal process for specifying inputs and outputs used by risk analysis/mitigation tools:

• What could happen? How severe is it? How often? Possible cause? (Provide a severity number and a probability.)

• How could it be prevented? Controls? How will we find out about this? (Assign a priority to correct this problem.)

Page 86: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-30

• Recommended actions? By whom? When? Schedule? Will this correct the problem?

• Results output. New severity code? New priority code? New probability code? Impact on schedule, cost, resources, lost benefits?

A formal process capability to analyze risk and mitigation options is available in off-the-shelf packages. One approach is to obtain an add-on package to the benefit/cost analysis tool described earlier. With a risk analysis add-on, probabilities and their distributions are determined for selected spreadsheet parameters. Then simulations are run using the inputs and distributions, and new schedules, benefits, and costs are output with probabilities and graphs to show meaningful results. With such a package, many what-if scenarios may be run in a very short time and decisions can be based on the best method to reduce risk and achieve the desired project objectives.

For simpler projects, a spreadsheet may be used. The formal tools may be more appropriate for system deployment projects than for pilot projects.

3.5.4.5 Risk Mitigation Techniques

A formal risk analysis and mitigation plan must be in place from the start. It would be a part of the charter or could be a separate document. There are different risks and mitigation strategies depending on the phase of the project. Table 3-3 covers this from a high-level view.

Page 87: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-31

Table 3-3 Risk Mitigation Techniques

Project Cycle Risk/Uncertainty Mitigation Technique

Initiation Lack of information

Difficulty in gaining departmental support

Lack of the appropriate staff

SA (project) new to the utility

Champion/management buy-in

Definition/scope project charter

Incomplete analysis

Mismatch among objectives, budget, implementation plan, and benefits

Formal cost/benefit analysis

Formal sign-off on charter

Establishing controls

Creation of a process for continual risk analysis and mitigation planning

Project start/SA implementation

Vendor selection based on ability to successfully complete the project

Formal selection process with a focus on key performance factors

Implementation Scope creep

Technical risk

Apply rigid change control

Test results early

Review against current cost/benefit projections

Operation Poor system performance Users lack understanding of how to use the SA applications

Involve users early

Train early

Test as soon as possible

Practice rigid change control

3.6 The Roadmap to Design the Desired Substation

The objectives of this section are to provide a process that achieves the following objectives:

• Helps the functional requirements team formulate the project requirements

• Helps the system design team plan and implement an advanced secondary system that meets those project requirements

For the functional requirements team, the process involves progressively figuring out (1) what people want the system to do, (2) what the consequent system requirements are, and (3) how to represent those requirements so that they can be easily and correctly interpreted by the system design team. In everything that follows this, the functional requirements team is engaged in specifying the criteria for successful design. This is the business described in Section 3.6.2 and Section 3.6.3.

Page 88: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-32

For the system design team, the process involves responding to the functional requirements in a way that achieves the desired results in the most advantageous way. This is where experience, common sense, good design practice, and familiarity with available products must come together to produce good decisions. Information and application aspects of the design process are discussed in Sections 3.6.4 through 3.6.6.

3.6.1 Basic Concepts

This section provides a process for developing a project plan that really takes advantage of the new technologies to reinvent the substation. It does not define what the project objectives should be, but it will provide project teams with a plan for attaining their objectives. The following discussion overviews some basic concepts.

• Interoperability

The main goal of the IEC61850 communications standard is interoperability among smart devices and subsystems within a substation. This means that they have the capability to exchange and use information cooperatively, according to a planned system design. The way that they actually do this depends on the design goals selected by the functional requirements team and the design plans developed by the system design team.

When the project team understands the rudimentary concepts for applying these technologies, all they will need to get the job done is their utility knowledge, professional disciplines, imaginations, and common sense.

• The primary system

The traditional approach to substation design is naturally centered on the power system: buses, lines, transformers, LTCs, switches, breakers, capacitor banks, and reactors. This collective electrical infrastructure, which handles electrical power delivery, is called the primary system.

• The secondary system

The primary system is complemented by a secondary system, comprising all components and systems used to monitor, control, protect, and automate the substation. Because this information infrastructure is critical to human safety, equipment safety, and system reliability, it has always been an essential part of substation planning and implementation. PTs, CTs, transducers, control panels, protection relays, RTUs, serial communications, and HMI are all examples of secondary systems.

In recent years, we have seen the emergence of intelligent devices (for example, IEDs), networked communications, programmable logic, and digital signal processing (DSP) capabilities for extracting a wealth of information from a simple 3-phase power connection. But to date, integration of the secondary system has been fragmented, composed of separate subsystems (for example, SCADA and protection) with little commonality.

IEC61850 now provides the means to integrate communications, information, and applications into one coherent, flexible, very powerful framework for the secondary system. With its deployment, more information can be exchanged and more applications can run within the substation. We shall see that integrated, accessible information is truly the enabler of effective and economic substation automation.

Page 89: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-33

• The substation LAN

The IEC61850 standard enables information exchanges to be communicated over a substation Ethernet network (the substation LAN) in a timely, secure, and flexible way. The LAN is connected to all IEC61850-savvy devices and subsystems in the substation.

Devices that do not have this capability are connected through a gateway, which must accommodate the communications limitations of such devices. Ideally, all communications among substation devices and subsystems is channeled through the substation LAN, eliminating the need for serial communication links and discrete field wiring, except where short, local interconnections are required (for example, within a breaker enclosure). This allows the secondary system to be implemented in a standardized way, independent of the specific information being exchanged and the specific applications being run. IEC61850 incorporates a variety of communication services and information models, the latter broadly representing data and functionality found in various pieces of substation equipment.

• Substation automation

Substation automation (SA) includes monitoring, control, protection, and automation applications. (Protection is really a of specialized automation application and, therefore, is identified separately.)

Those who use DNP or some other telecontrol protocol may wonder why the IEC61850 communications standard is necessary. The fact is that telecontrol protocols were strictly designed to support SCADA and nothing more. When demanding, higher performance applications are involved or when systems become complicated, telecontrol protocols do not provide the communication services required to support substation automation. IEC61850 also greatly simplifies system integration, data management, maintenance, and system validation.

• Distributed applications

We can even leverage this new technology to partition certain applications into cooperative modules, distributing them among different physical resources (for example, IEDs, controllers, and other platforms). This provides unprecedented flexibility to manage the substation’s information and automation environment.

Protection relays provide a good example of how distributed applications work. Protective relays protect equipment in the substation (or connected to it) from scenarios that could cause damage or system instability. In recent years, many relay products have appeared with programmable logic capabilities, allowing protection programs to be distributed across several relays, thus physically spanning areas of the facility that need to participate. But to date, interlocking status exchanged between relays continues to be signaled through point-to-point, hardwired contacts. IEC61850 networked communications, providing numerous virtual connections, can now be used to convey these interlocks. In like manner, all sorts of smart controllers, IEDs, and intelligent subsystems can cooperatively communicate peer-to-peer over the substation LAN to achieve very sophisticated capabilities.

Page 90: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-34

3.6.2 Business Processes

To determine the functional requirements for the secondary system, we need to understand the business processes to be supported by the substation. This document defines business processes as activities that are deemed necessary for operational or administrative management of the power system. They may be mission-critical, mission-important, or mission-supportive. Business processes process may support the specific business responsibilities of a single department or they may provide a general benefit to several groups (for example, access to power system measurements and status). Business processes must comply with regulatory law and the utility’s corporate rules. They must also respect the utility’s corporate culture, as defined by current practice. Change leading to improvement is always desirable, but it needs to be coordinated among affected parties to produce acceptance and the anticipated benefits.

These business processes will determine the responsibilities and capabilities of the secondary system, which exists for no other purpose than to monitor, control, protect, and automate the substation in the manner that the utility wants it done.

The capture and documentation of business processes to be supported by the substation is the responsibility of the functional requirements team.

3.6.2.1 Describing a Business Process

A business process can technically be described as a sequence of actions and decisions designed to accomplish some tactical business goal. These actions and decisions may be performed by a combination of people, programs, and devices (actors). Decisions are made on the basis of observed conditions, constraints, and objectives. A business process is fully automated if it does not require any actions or decisions to be made by people. Some business processes may run continuously, while others run only under specified conditions. A flow diagram is one way to document a business process, but other tools are described in Section 5.

3.6.2.2 Principles for Documenting Business Processes

The following four principles are offered for documenting a business process:

1. Describe what the process must do or accomplish (that is, the requirements for fulfilling the intent of the process).

Outline a process sequence (for example, a flow diagram), showing the actions and decisions required of participating actors. The functional requirements team can simply identify each actor as either a person or automation (that is, program or device), because at this stage we are not interested in how the secondary system is implemented. People are usually identified by their roles in the process.

Use the process sequence to identify any inputs needed, any outputs produced, and any coordinated sequences of action necessary to specify the required behavior.

Page 91: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-35

Describe all constraints (for example, interlocks) and other related issues necessary to fully and unambiguously specify correct behavior. Note, for example, that if interlocking conditions were neglected in describing functional requirements, they would not be considered during system design.

2. When possible, describe a process in terms of its interaction with the power infrastructure of the primary system, not in terms of its interaction with the secondary system.

More specifically, relate the process to appropriate pieces of the power system infrastructure (for example, breakers or LTCs), power flow attributes (for example, voltage, current, or PF), and generic utility practice (for example, use of TRIP breaker control).

If a process does intrinsically relate to the secondary system (for example, acquisition of relay targets), make appropriate, nonspecific references to the interacting secondary system equipment (for example, all IEDs, all protective relays, or all protective relays involved with line protection).

In this way, no presumptions will be made regarding how the secondary system will be implemented. This again keeps requirements separate from system design, and makes it easier to perform iterative design passes without affecting the content and integrity of the requirements document.

3. Avoid any statements that restrict, describe, infer, or assume how the secondary system is to be designed, unless they are the unavoidable consequences of business process requirements.

4. Be careful not to fall into ruts.

A process that has been used in the past may not be best process you want to use going forward. The team experts have to figure out what they really want. If a stated process does not reflect the real objectives, everything that follows will go down the wrong path.

3.6.2.3 A Practical Methodology for Documenting Business Processes

The following is offered as a pragmatic approach for documenting business processes. It simplifies the effort by stratifying it at five levels: substation objectives, activities, functional capabilities, substation functions, and affected entities. Each level drills down in more detail, so that each business process is described in a hierarchical way.

The functional requirements team may find it useful to make iterative passes at this, so that it initially gets a feel for the process and how it works before it goes back to fill in the holes.

• Level 1: List substation objectives in terms of managing the power system, meeting the utility’s mission-critical, mission-important, and mission-supportive goals, and supporting any other utility aspirations.

These descriptions should be management-level, strategic statements that (1) have some real substance and (2) can be used for review and guidance when working at Level 2. Consider including objectives that may have been considered impractical in the past, if the new secondary system environment makes them appear more attractive.

Page 92: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-36

• Level 2: Describe the general and specific activities, which the substation is expected to support, that enable the collective substation objectives listed in Level 1 to be realized. Activities are a way to classify different substation pursuits. Each activity has its own agenda, which operates more or less independently of the others. Some activities may serve specific needs while others provide general services. Note that one or more activities may be required to support each substation objective.

Examples of several general activities follow, although they are simply named and not described in detail:

– Supervisory control for operations

– Capabilities to perform selective data collection or reporting

– Protection

– HMI support

– Capacitor bank switching, coordinated with temperature, load, power factor, or time of day

– Substation maintenance support

• Level 3: For each activity (Level 2), describe the specific functional capabilities to be supported. First, describe what they do using prose. Next, describe them with flow diagrams or the UML tools discussed in Section 5. These descriptions will be more precise and will be good props for debating how the capabilities and activities are defined. For comparison, the team may decide to use the same methods to describe how things have traditionally been done.

This is a creative exercise, where the team members have a fair degree of latitude. The team members are defining each problem as they see it and shaping the qualities of each solution. A premium should be placed on achieving order, simplicity, consistency, and elegance within the descriptions, while being mindful of the utility’s culture (that is, how it does things and organizationally thinks). This may take some practice.

The following are examples of capabilities for a specific activity—protection:

– Line protection

– Bus-differential protection

– Breaker failure protection

– Transformer-differential protection

• Level 4: For each capability (Level 3), list the specific substation functions (SFs) used by the capability. SFs are defined in the next subsection. Individual SFs may be used by more than one process, or they may be used in several places within the same process. For this reason, we say SFs are reusable.

Examples of SFs that may be used for line protection are as follows:

– TRIP breaker

– LOCKOUT breaker

– DISABLE recloser

Page 93: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-37

• Level 5: For each capability (Level 3), list the specific substation entities to which the capability applies.

The following are examples of entities to which the capability line protection may be applied:

– Feeder 924

– Feeder 934

– Feeder 944

Finally, the five levels described here offer the additional advantage of simplifying the capture of repetitive structure and content. An electronic spreadsheet is a good vehicle for recording, editing, and sharing this information.

In closing, note that the functional requirements team is engaged in describing how things need to behave in order to meet objectives. This is represented abstractly. In a very real sense, the functional requirements team has the power to bend the eventual design to its point of view. It can bias everything about the design with its requirements. If done properly, these requirements will reflect what is truly needed.

3.6.3 Substation Functions

Level 5, described in Section 3.6.2.3, involves defining a reusable set of substation functions (SFs). The intent here is to rise above the myriad application functions used to design the individual products and to describe the basic operational functions of the substation. Substation functions represent a way of viewing how the substation works, independent of the technology and products that are used to make it work that way. They are typically used to represent substation-oriented actions (for example, CLOSE breaker). Collectively, they are similar, if not identical, to the functions described within IEC61850 logical nodes (refer to Section 3.6.6). This is not surprising because the IEC61850 communications standard is very substation-oriented.

In some ways, SFs are similar to business processes, because both can be represented by a flow diagram. But there are two principal differences. First, SFs represent a way to accomplish something that is narrowly focused, substation-oriented, and technical in nature. They may coordinate technical resources and issues (for example, interlocking conditions) in a sequenced way, but they are not used to represent something broader like a business process. SFs are typically the actions performed within the flow diagram of a business process. These actions are performed by actors (for example, people, programs, or devices) as described previously. Secondly, SFs are typically defined so that they are reusable, while business processes are almost always unique and broader in scope.

It is the responsibility of the functional requirements team to identify and document substation functions.

Page 94: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-38

3.6.4 Software Application Modules

Note: Within this section, any reference to software application modules (SAMs) includes only those that must support the IEC61850 communications standard.

Each SAM typically has one of three origins:

1. It is purchased as a stand-alone software application for use on a separately purchased platform (for example, desktop PC).

2. It is a bundled part of a purchased piece of equipment (for example, IED) and is integral to the capabilities provided by that equipment.

3. It is implemented by utility engineers (or their representatives) using programmable logic capabilities provided with a purchased piece of equipment (for example, a protection relay).

What is common among these three scenarios is that they must all support the IEC61850 communications standard. The supplying manufacturers should transparently accomplish this for scenarios 1 and 2. Aside from configuration options, the way in which these applications and equipment are packaged and run is outside the scope of the utility’s control. Scenario 3 requires the equipment manufacturer to make configurable linkages available between programmable logic modules (designed by utility personnel) and equipment capabilities that support IEC61850. These linkages are generally accomplished by proprietary means, but the IEC61850 communication services and the object models that they enable are open and interoperable.

The system design team is responsible for the selection, design, and documentation of software application modules.

3.6.5 Application Functions

Functions typically begin life as abstractions, used by engineers to model different pieces of capability in their designs. Each function has describable behavior, an interface to the world beyond, and intended uses in the scheme of things. At the next step, they are made real through the interactive behavior of software structures, electrical signals, and perhaps physical elements. If properly exploited, functions can be used to introduce simplicity, elegance, order, consistency, sophistication, and reusability into design. Because the concept is so universal, it is found in almost all aspects of engineering design. In this project, we find them used to implement communications, devices, and software applications.

In particular, application functions (AFs) are very useful for representing the way software application modules (SAMs) are implemented, especially those implemented from programmable logic. They exist to provide a higher-level perspective for both designers and users. Unlike substation functions (SFs), AFs are not explicitly tied to the utility world. They exist as a basis for organizing the behavior of software programs. Because programs and devices were identified earlier as the two automated actors for initiating SFs, it can be seen that AFs are often combined within SAMs to implement substation functions and to control how they are used.

Page 95: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-39

In scenarios 1 and 2 (Section 3.6.4), AFs are usually not exposed by the manufacturer, unless for training purposes. In scenario 3, however, the utility uses programmable logic to accomplish its objectives. In this case, it is very useful to initially abstract the design at a higher level using AFs so that the program logic is more easily understood and maintained. This also helps to implement and document the IEC61850 communication linkages with fewer errors. It will especially help later in time, should programmable logic modules must be revised to meet changing needs.

System design team members who create programmable logic modules for the project are responsible for the design and documentation of AFs.

3.6.6 Logical Nodes and Information Flow

In IEC61850 language, logical nodes (LNs) are the smallest parts of an application function that can exchange data over the network. IEC61850 has created a variety of these LNs (more than 70), each with its own specialized role for communicating information related to substation data and functionality. Consider the following examples:

• MMXU provides real-time power system data.

• XCBR represents breaker status and control.

• RREC represents recloser relay status and control.

• There are also a fairly large number LNs for protection.

From the perspective of the communications network, each LN represents an application function and performs some operation(s) for that function. In summary, if something is to be communicated, there must be an LN to represent it.

An LN is an object defined by its data and methods. The data part represents some specific substation data or functionality related to the type of LN that it is. The methods represent functional capabilities that can be accessed via communication services. LNs are responsible for all information exchanges and are, therefore, the foundation for IEC61850 communications interoperability.

The system design team is responsible for the availability and distribution of LNs within the system to support communication requirements.

3.7 Project Documents

For the various documents listed here, a mechanism and process are required to support project team updates and access. Currently, the use of the Internet is probably most practical, because updates and access can be accomplished quickly, eliminating delays in the circulation of paper, which inevitably slows project decisions and execution.

Page 96: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-40

FTP-accessible archives are very handy for posting and accessing documents. Separate areas may be established for work-in-progress, accessible by only task leaders or vendors, for management reporting and for generally available documents. Passwords and user names are frequently used to control the access to information.

E-mail list-servers (sometimes referred to as exploders) can be used to send documents, meeting notices, minutes, and other information to team members and to the FTP archives. E-mails themselves can also be archived and chronologically accessed later within specific communication threads.

Electronic distribution of information provides a simple, fast, error free, and timely method to exchange information, keeping all parties up to date on current efforts and progress. These mechanisms require some human maintenance, but it is nothing like the difficulty of past alternatives. The project manager and his team should decide which specific mechanisms are to be used.

3.7.1 Administrative Documents

Administrative documents include the project request, project charter, project authorization, statements of work, contracts, agreements, and memoranda of understanding.

Progress reports are typically periodic, reviewing project highlights, tasks completed, tasks planned, risks/problems encountered (with foreseen impact), or budget and schedule status.

3.7.1.1 Project Request

This is the project request initially submitted to senior management. It provides a summary description of what is envisioned and why it would be valuable. At this point there is little to offer regarding economic specifics. This is essentially a request for authorization to expend some effort to generate a formal project charter.

3.7.1.2 Project Charter

The project charter is the single most important project document because it serves two important, related purposes. It provides critical guidance for direction at the beginning of a project, and it serves as a means to evaluate whether the project has successfully met its goals when the project ends. Management approval authorizes the project to begin. The charter can be amended with management approval if the project later requires a change of scope.

To serve its purpose, a charter must clearly and unambiguously address the following issues, which are described in more detail in Section 3.5.1:

• Project purpose and objectives

• Critical success factors and risks

Page 97: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-41

• Deployment sites

• Expected benefits

• Constraints (including the budget, schedule, and resource issues)

3.7.1.3 Statements of Work

Statements of work are used to provide a detailed description of the work to be performed under a contract. The content and wording are negotiated by the contracting parties, generally before a contract is signed.

3.7.1.4 Contracts

These are binding legal documents between parties that formalize an agreement to provide goods and/or services in exchange for payments under prescribed conditions. Contracts generally include commercial terms and conditions.

3.7.1.5 Budgets

Budgets represent an approved allocation of money and/or other resources for use in a project. The budget is generally broken down into categories and time intervals (for example, by fiscal year or quarters) to establish more control over expenditures.

3.7.1.6 Schedules

A typical schedule outlines project tasks against a time line, showing start and end dates. It becomes more valuable if it shows the interaction of tasks, schedule conflicts, resource conflicts, and relationships with other projects. A schedule of milestones is also useful for the project teams. Managed manually, keeping all this information up to date would be quite time-consuming.

A project management tool like Microsoft Project can save time and make things much easier. It potentially improves team collaboration related to the preparation and maintenance of schedules, the monitoring of progress, and the discovery of conflicts. As input, such tools accept tasks, start and end dates, expected durations, team and individual responsibilities, and task relationships or dependencies.

In addition to standard Gantt charts (where a horizontal bar indicates the start/stop and duration of each task), project schedules should also include CPM (Critical Path Method) charts and/or PERT (Program Evaluation and Review Technique) charts. Additional useful charts include CPM Network Diagrams (showing the relationships of tasks, events and milestones) and Conflict Reports (showing resource constraints, overloads, and possible problems).

Page 98: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-42

Events can also be included in the project schedule, such as meetings, decision points, and milestones. The scheduling process considers the following for possible impact:

• Recognition of other projects competing for resources

• Recognition of special constraints (for example, summer or winter peaks)

• Availability of qualified personnel and other resources

• Staging successive phases

The important thing is to find a balance, using those features that make life easier and accommodate project needs without becoming a slave to project management technology.

3.7.2 Working Project Documents – Project Deliverables in Process

The following items are working project documents:

• Requirements documents, such as those produced by the functional requirements team (Refer to Section 1.4.2.2 for the activities that generate the content of this document.)

• Planning documents, such as those produced by the system design team (Refer to Section 1.4.3.2 for the activities that generate the content of this document.)

• Implementation documents, such as those produced by the system design team (Refer to Section 1.4.3.3 for the activities that generate the content of this document.)

During the project these may change continually, although hopefully less frequently, until the end of the project. We refer to these as working documents. At the end of the project, however, it is extremely important to bring them completely up-to-date, reflecting the as-installed system. At that point, they should be released with the as-installed status. This is the only way to capture the end design so that it can be reused on another project or used as the starting point for continued work in another venue.

3.7.2.1 Functional Requirements

Functional specifications describe what a system, hardware component, or application must be able to do in support of its system role (that is, the capabilities, features, and other qualities it must have). Aside from stating these requirements, functional specifications should not state what form the eventual design should adopt.

Functional requirements are needed for system interfaces (that is, the necessary relationships among conceptual parts of the system), application roles, equipment roles, the communications system, and anything else that supports system functionality. Functional specifications should be supplemented with information flow diagrams.

Note that the communications system is an exception to these rules, because there is a preexisting assumption that it will be based on an Ethernet network and use the IEC61850 communications standard.

Page 99: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-43

Functional requirements portray one or more abstract views of the system to be planned and implemented. Aside from communications, they must not portray an implementation of the system. But they do provide a constrained roadmap for the design team to delineate the form to best advantage. Documents for expressing functional requirements need to take these thoughts into consideration. They need to provide clear and unambiguous direction where necessary without binding the eventual design in areas that need not be constrained.

3.7.2.2 Design Plans

Design plans include all documents involved with interpreting functional requirements and laying out plans for a conformant design. These documents generally take the form of design specifications and procurement specifications, adopting a black box approach to the specification process. That is, if the specified entity behaves correctly, conforms to the required external interface(s), and has the required external attributes (for example, size, form, and power consumption limits), it probably qualifies. The internal design details are largely irrelevant. Obviously, commercial issues such as warranty also apply.

Design specifications apply to equipment, applications, system software, and any other facet of system implementation.

3.7.2.3 Design Implementation

Design implementation documents should capture the overall system design philosophy, system level designs, product evaluations, and designs produced by utility personnel (for example, programmable logic modules). System level drawings should include block diagrams that show and identify system components, interfaces, and cabling. Installation, integration, configuration, and testing documents should included. In summary, anything that enables one to understand how the system was designed, put together, and validated in its released form is important.

This documentation should convey a high-level of understanding and should reveal all necessary detail. It must be clear and unambiguous. As cost is always a collateral issue, project management will have to interpret these recommendations and set specific documentation guidelines to be applied within the project.

3.7.3 Other Documents Related to System Operation

Other documents related to system operation are configuration issues related to available system data, exchanged information, exchange privileges, and mandated restrictions on such exchanges. These configurations will change frequently over time and are intrinsic to the system’s ongoing data management process. The following are examples of other related documents:

• Lists of capabilities, applications, and subscribers

• Lists of the station data and functionality to be supported

• Lists of access privileges and reasons

Page 100: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-44

• Lists of mandated access restrictions to accomplish the following objectives:

– Comply with government regulations

– Comply with utility policy

– Mitigate risk

3.7.4 Tracking Documents

3.7.4.1 Progress Reports

These are usually periodic (for example, bi-weekly or monthly) reports on the status of the project. These should be submitted by each project team to the project manager. They should cover technical achievements, problems, and status, as well as nontechnical issues (for example, organizational status).

These reports are critically important to the project manager for maintaining an ongoing assessment of the project’s progress and health. They can also provide a historical perspective over a longer period. It is up to the project manager to state the kinds of information he wants to see delivered in these reports.

3.7.4.2 E-mails and Correspondence

Because all team members will undoubtedly be sending and receiving e-mails, it is the project management’s responsibility to set policy about who is to be included or copied on various pieces of correspondence.

3.7.4.3 Meeting and Teleconference Minutes

Meetings and teleconferences must be summarized and published appropriately at the direction of the project manager and the team leaders.

3.7.4.4 Project Notes

Project notes include informal information prepared by the team leaders, members, or the champion that are not otherwise captured in formal documents.

3.7.5 Vendor Product Material

Vendors may provide marketing overviews, data sheets, installation manuals, configuration guides, user guides, and similar product material.

Page 101: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Project Management for Substation Automation

3-45

3.7.6 Reference Documents

Reference documents can include standards, specifications, relevant articles, studies, and similar documents. The project team typically does not reference documents—they are adopted for project use or reference.

Page 102: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 103: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

4-1

4 DEVELOPING FUNCTIONAL REQUIREMENTS FOR SUBSTATION AUTOMATION EQUIPMENT, SYSTEMS, AND APPLICATIONS

4.1 Purpose and Audience for This Section

4.1.1 Purpose

The purpose of this section is to identify and analyze the current and potential future power system functions that drive the requirements for substation automation capabilities. These requirements lead to some new ways of thinking and to the use of new technologies designed to meet some of these requirements. Not all utilities will implement all of the power system functions, nor will they need all of the capabilities described here. In addition, the future may hold many functions not yet identified. Nonetheless, it is critical for planners to review the possible functions and to understand the requirements that must be met by SA capabilities as well as their impacts on SA designs.

4.1.2 Audience

The primary audience for this section is substation planners and engineers, protection engineers, system operators, maintenance engineers, and information engineers.

4.2 Power System Functions That Drive the Requirements for Substation Automation

The automation of substations must be based on clearly defined utility requirements. Otherwise, the automation is not necessary. Therefore, utility requirements drive the need for substation automation. This understanding is vital to the design and implementation of substation automation in any utility.

The requirements for SA must reflect all of the utility requirements, not just protective relaying or SCADA monitoring. Therefore, in the future, it is crucial that utility engineers design substations to accommodate power system functions that have not been part of their focus in the past.

Page 104: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-2

Key Technical Point

In the future, it is crucial that utility engineers design substations to accommodate power system functions that have not been part of their focus in the past.

The IntelliGrid Architecture project sponsored by E2I (see IntelliGrid-Architecture.com) developed a comprehensive list of power system functions required for transmission operations (additional lists of functions were developed for other domains). Most of these functions would benefit from the access to information, the response to events, and the ability for dynamic management of power system settings that are provided by substation automation.

Clearly not all functions will require information within the same time frames. For instance, protective relaying will need instantaneous data (within 4 ms), while control center operations rely on real-time interactions on the order of a few seconds. Many of the planning functions will need statistical information derived from the raw data over various time periods and under various circumstances. Other post-operational functions, such as reading the revenue meters, require the information only over long periods.

Some functions listed do not exist today in utilities to any significant degree. For instance, the setting of protection and recloser parameters is usually performed off-line by protection engineers, and then either manually entered or remotely downloaded. In the future, settings could be dynamically determined and automatically downloaded, or even dynamically set within the substation based on actual conditions.

Tables 4-1 through 4-4 list the key transmission operation functions and illustrate their interactions with substation equipment. The purpose of the tables is to show just how varied the uses of the substation information will be within transmission operations. It should not be viewed as the only mapping of functions to substation information. The key idea to gain from these tables is that SA impacts far more than the substation—it impacts planning, protection engineering, daily operations, emergency responses, market operations, maintenance, and even the work of the executives.

Key Technical Point

Substation automation impacts far more than the substation—it impacts planning, protection engineering, daily operations, emergency responses, market operations, maintenance, and even the work of the executives.

Page 105: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-3

The following list defines the codes for the entries in Tables 4-1 through 4-4:

B = Before real time: The information can be gathered at any time for future use.

I = Instantaneous signaling: Monitoring and control signals are transmitted on the order of 4 ms. This signaling is within and between substations.

M = Real-time monitoring: The information is gathered in real-time—defined here as being on the order of 1–10 seconds by the control center as well as by substation equipment.

C = Real-time control or settings: Control commands are issued from the control center or from a substation master, either as direct commands or as setpoint changes for immediate or future actions.

A = After real-time monitoring: The information is gathered on past conditions and behavior. Although this could be seen as identical to the code B (both are gathered at some noncritical time), the implication is that these data will be used for capturing explicit past behavior, rather than for analyzing data for future use.

S = Statistical analysis: The individual data is not important except as input to specific statistical calculations performed under different scenarios (for example, max and min voltage during each 24-hour period, average power factor.)

P = Power flow analysis (or another sophisticated analysis): More sophisticated analysis is performed on the data, such as power system flows, state estimation, or contingency analysis.

L = Logging: The actions and data are logged and archived for future auditing, planning, and analysis.

Page 106: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-4

4.2.

1 T

ran

smis

sio

n P

lan

nin

g F

un

ctio

ns

Tab

le 4

-1

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

Req

uir

emen

ts f

or

Tra

nsm

issi

on

Pla

nn

ing

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Lo

ng

-ter

m t

ran

smis

sio

n p

lan

nin

g (

1–5

year

s)

Long

term

load

fore

cast

S

S

For

ecas

t alte

rnat

ives

for

gene

ratio

n so

urce

s (p

roba

ble

mar

ket

cond

ition

s)

S

S

Pla

n tr

ansm

issi

on u

pgra

des

and

addi

tions

(fo

r ex

ampl

e,

part

icip

atio

n in

ISO

/RT

O e

xpan

sion

pla

n)

S, P

S

S

S

S

S

S

, P

S, P

S

A

B

Pla

n au

tom

atio

n of

tran

smis

sion

sys

tem

for

SC

AD

A,

equi

pmen

t mon

itorin

g, a

nd E

MS

S

, P

S

S

S

S

S

S, P

S

, P

S

A

B

Pre

pare

long

-ter

m c

ontr

acts

with

dis

trib

utio

n ut

ilitie

s:

– T

rans

mis

sion

vol

tage

man

agem

ent

S, P

S

S

S

S

S

S

, P

S, P

S

– D

istr

ibut

ion

reac

tive

pow

er s

uppo

rt (

pow

er fa

ctor

) in

the

T&

D in

terf

ace

S, P

S

S

S

S

S

S

, P

S, P

S

– T

&D

info

rmat

ion

exch

ange

S

, P

S

S

S

S

S

S, P

S

, P

S

Pre

pare

em

erge

ncy

resp

onse

pla

nnin

g, fo

r ex

ampl

e, ic

e st

orm

, hur

rican

e, lo

cal o

utag

es, o

r sy

stem

-wid

e bl

acko

uts

S, P

S

S

S

S

S

S

, P

S, P

S

A

B

Page 107: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-5

Tab

le 4

-1 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r T

ran

smis

sio

n P

lan

nin

g

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Ens

ure

that

cop

ies

of a

ll sc

hem

atic

s, d

iagr

ams,

and

rel

ay

setti

ngs

are

avai

labl

e to

fiel

d pe

rson

nel

B

B

B

Pre

pare

inve

ntor

y an

d pe

rson

nel p

lans

bas

ed o

n su

ch th

ings

as

nei

ghbo

ring

load

or

tie p

oint

cap

acity

S

, P

S

B

Med

ium

-ter

m p

lan

nin

g (

1 m

on

th t

o 1

yea

r)

For

ecas

t ann

ual l

oad

S

S

L

Con

side

r pr

obab

le g

ener

atio

n so

urce

s S

S

Equ

ipm

ent a

nd li

ne m

aint

enan

ce p

lans

A

, S

A, S

A

, S

A, S

A

, S

A, S

A

, S

A, S

A

, S

A

B

Cal

cula

te s

yste

m u

tiliz

atio

n ba

sed

on fo

reca

st lo

ad a

nd

equi

pmen

t nam

epla

te r

atin

gs

S

S

S

S

S

S

Sch

edul

e m

aint

enan

ce o

pera

tions

– ti

me-

base

d

B

Sch

edul

e m

aint

enan

ce o

pera

tions

– p

redi

ctiv

e, b

ased

on

data

an

d m

odel

s S

S

S

S

S

S

S

S

S

B

Sch

edul

e eq

uipm

ent r

epla

cem

ent –

bas

ed o

n ag

e of

eq

uipm

ent

A

A

A

A

A

A

A

A

A

Sch

edul

e eq

uipm

ent r

epla

cem

ent –

pre

dict

ive,

bas

ed o

n da

ta

and

mod

els

S

S

S

S

S

S

S

S

S

B

Sch

edul

e eq

uipm

ent r

epla

cem

ent –

bas

ed o

n co

ntin

genc

y sc

enar

ios

S, P

S

, P

S, P

S

, P

S, P

S

, P

S, P

S

, P

B

Page 108: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-6

Tab

le 4

-1 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r T

ran

smis

sio

n P

lan

nin

g

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Sch

edul

e sp

are

part

s di

strib

utio

n, e

nsur

e su

ffici

ent a

t eac

h si

te

B

Rev

ise

cont

ract

s w

ith d

istr

ibut

ion

utili

ties

usin

g ac

tual

cos

ts a

s pa

rtia

l inp

ut

S

S

S

S

S

S

S

S

S

B

Op

erat

ion

al p

lan

nin

g (

1 h

ou

r to

1 m

on

th)

Sho

rt-t

erm

load

fore

cast

B

, S

B

, S

L B

Sho

rt-t

erm

gen

erat

ion

alte

rnat

ives

bas

ed o

n an

nual

m

aint

enan

ce p

lan

and

mar

ket c

ondi

tions

B

, S

B

, S

Pla

nned

out

age

man

agem

ent:

– O

pera

tors

det

erm

ine

need

ed tr

ansm

issi

on o

utag

es

L

B

B

– C

ontin

genc

ies

are

anal

yzed

B

, P

B, P

B

, P

B, P

B

, P

B, P

L B

– P

lann

ers/

oper

ator

s pe

rfor

m lo

ad a

naly

sis

of s

ubst

atio

n eq

uipm

ent b

ased

on

data

B

, P

B, P

B

, P

B, P

B

, P

B, P

L B

– O

pera

tors

sub

mit

tran

smis

sion

out

ages

and

con

stra

ints

to

RT

O/IS

O

B, P

B

, P

B, P

B

, P

B, P

B

, P

L

B

– D

ynam

ic e

quip

men

t cap

acity

– c

hang

e w

rite-

up

L

– P

rote

ctio

n en

gine

er to

alte

r re

lay

setti

ngs

B, S

B

, S

B, S

B

, S

B

, C

L

– M

eter

par

amet

ers

are

upda

ted

as p

er a

ny m

arke

t con

trac

ts

C

Page 109: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-7

4.2.

2 N

orm

al R

eal-

Tim

e T

ran

smis

sio

n O

per

atio

n

Tab

le 4

-2

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

Req

uir

emen

ts f

or

No

rmal

Rea

l-T

ime

Op

erat

ion

s

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Rea

l-ti

me

no

rmal

op

erat

or

acti

on

s (u

sin

g S

CA

DA

/EM

S)

SC

AD

A s

yste

m m

onito

rs tr

ansm

issi

on s

yste

m:

– M

onito

r eq

uipm

ent s

tate

(op

en/c

lose

/ala

rm)

M

M

M

M

M

M

M

L

– M

onito

r sy

stem

act

ivity

and

load

(cu

rren

t, vo

ltage

, fre

quen

cy,

and

ener

gy)

M

M

M

L

– M

onito

r eq

uipm

ent c

ondi

tion

(ove

rhea

t, ov

erlo

ad, b

atte

ry

leve

l, an

d ca

paci

ty)

M

M

M

M

M

M

M

M

M

L

– M

onito

r en

viro

nmen

tal (

fire,

sm

oke,

tem

pera

ture

, sum

p le

vel)

and

Mon

itor

secu

rity

(doo

r al

arm

, int

rusi

on, a

nd c

yber

atta

ck)

L

M

M

– M

onito

r se

curit

y re

cord

s (a

udio

/vid

eo r

ecor

ding

)

M

SC

AD

A a

nnou

nces

ala

rms

to o

pera

tors

M

M

M

M

M

M

M

M

L

Ala

rms

are

anal

yzed

by

Inte

llige

nt A

larm

Pro

cess

ing

M

, P

M, P

M

, P

M, P

M

, P

M, P

M

, P

M, P

L

Page 110: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-8

Tab

le 4

-2 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r N

orm

al R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Dis

trib

utio

n of

ala

rms

to n

on-o

pera

tors

:

– O

verlo

ads

and

repl

acem

ent i

ssue

s to

mai

nten

ance

eng

inee

r A

A

A

A

A

A

A

A

L

– A

utom

ated

wor

k m

anag

emen

t sys

tem

A

A

A

A

A

A

A

A

L

– F

ault

reco

rds

and

SO

Es

to p

rote

ctio

n en

gine

ers

A

A

A

A

A

L

– In

fo to

bill

ing

dept

. re:

pos

sibl

e re

fund

s or

rel

iabi

lity

cont

ract

A

A

A

A

A

A

A

A

L

– E

xter

nal s

ecur

ity o

r em

erge

ncy

resp

onse

team

s M

M

M

L

Ope

rato

rs p

erfo

rm s

uper

viso

ry c

ontr

ol o

f sw

itchi

ng o

pera

tions

:

– M

anua

l sw

itchi

ng

L

– S

uper

viso

ry c

ontr

ol

M

M, C

M

, C

M, C

M

, C

L

Aut

omat

ion

appl

icat

ions

con

trol

vol

tage

, var

and

pow

er fl

ow b

ased

on

obj

ectiv

es s

et b

y op

erat

ors,

usi

ng a

lgor

ithm

s, r

eal-t

ime

data

, an

d ne

twor

k-lin

ked

capa

citiv

e an

d re

activ

e co

mpo

nent

s M

M

, C

M, C

M

, C

M, C

M

, C

L

Aut

omat

ion

appl

icat

ions

per

form

nor

mal

load

man

agem

ent,

for

exam

ple,

for

“pea

k sh

avin

g” o

r al

levi

atin

g te

mpo

rary

ove

rload

ed

equi

pmen

t M

M

, C

M, C

M

, C

M, C

M

, C

L

Page 111: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-9

Tab

le 4

-2 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r N

orm

al R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Ope

rato

rs c

hang

e se

tup/

optio

ns o

f EM

S fu

nctio

ns:

M

– P

erio

dici

ty o

f rea

l-tim

e se

quen

ce/c

old

Initi

atio

n

L

– E

vent

trig

gers

M

M

M

M

M

M

M

M

L

– M

anua

l ini

tiatio

ns

L

– C

ontin

genc

y lis

t

M

, S

M, S

L

– A

pplic

atio

n tu

ning

par

amet

ers

L

– O

ther

L

Ope

rato

rs p

repa

re fo

r st

orm

con

ditio

ns, b

ased

on

wea

ther

dat

a an

d hi

stor

y, a

nd c

hang

e re

clos

er a

nd p

rote

ctio

n se

tting

s M

M

M

, C

M, C

M

, C

M, C

S

L

M

Ope

rato

rs p

repa

re fo

r st

orm

con

ditio

ns b

ased

on

wea

ther

dat

a an

d hi

stor

y an

d ch

ange

ala

rm th

resh

olds

M

M

M

M

M

M

L

Pre

pare

for

tran

sfor

mer

clip

ping

(fo

r ex

ampl

e, s

olar

win

d/so

lar

mag

netic

dis

turb

ance

rai

sing

gro

und

DC

offs

et)

L

Page 112: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-10

Tab

le 4

-2 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r N

orm

al R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

Su

bst

atio

n A

uto

mat

ion

Info

rmat

ion

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Po

wer

sys

tem

an

alys

is d

uri

ng

no

rmal

rea

l-ti

me

op

erat

ion

s

EM

S s

yste

m p

erfo

rms

real

-tim

e se

quen

ce o

f mod

el u

pdat

e, s

tate

es

timat

ion,

and

bus

load

fore

cast

M

M

M

M

M

M

L

EM

S s

yste

m p

erfo

rms

cont

inge

ncy

anal

ysis

, rec

omm

ends

pr

even

tive

and

corr

ectiv

e ac

tions

, and

exe

cute

s up

on o

pera

tor

auth

oriz

atio

n M

M

M

, C

M, C

M

, C

M, C

M

M

L

EM

S s

yste

m p

erfo

rm r

eal-t

ime

volta

ge s

tabi

lity

anal

ysis

of n

etw

ork

cond

ition

s M

M

M

, C

M, C

M

, C

M, C

M

M

L

EM

S s

yste

m p

erfo

rms

optim

al p

ower

flow

ana

lysi

s, r

ecom

men

ds

optim

izat

ion

actio

ns, a

nd e

xecu

tes

upon

ope

rato

r au

thor

izat

ion

M

M

M, C

M

, C

M, C

M

, C

M

M

L

EM

S s

yste

m p

erfo

rm r

eal-t

ime

tran

sien

t sta

bilit

y an

alys

is o

f ne

twor

k co

nditi

ons

M

M

M, C

M

, C

M, C

M

, C

M

M

L

Page 113: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-11

4.2.

3 E

mer

gen

cy R

eal-

Tim

e T

ran

smis

sio

n O

per

atio

n

Tab

le 4

-3

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

Req

uir

emen

ts f

or

Em

erg

ency

Rea

l-T

ime

Op

erat

ion

s

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Em

erg

ency

Co

ntr

ol S

yste

m E

mer

gen

cy/P

reve

nti

on

Op

erat

ion

s

Rea

l-tim

e as

sess

men

t of p

ower

sys

tem

tole

ranc

es a

nd m

argi

ns:

– G

ener

ator

with

stan

d ca

pabi

litie

s fo

r ov

er-

and

unde

r-fr

eque

ncy

cond

ition

s M

C

C

M

– T

rans

mis

sion

dyn

amic

lim

its: s

tabi

lity,

ther

mal

, and

vol

tage

M

M

M

M

M

M

S

L

– D

istr

ibut

ion

dyna

mic

lim

its: l

oad

stab

ility

and

em

erge

ncy

volta

ge

qual

ity li

mits

M

M

M

M

M

M

S

L

M

Rea

l-tim

e F

ast S

imul

atio

n an

d M

odel

ing

(FS

M):

– R

eal-t

ime

secu

rity

asse

ssm

ent

M

M

M

M

M

L

M

– G

ener

atio

n an

d lo

ad b

alan

ce a

sses

smen

t M

M

M

M

M

L

M

– In

ter-

area

pow

er fl

ow a

naly

sis

M

M

M

M

M

L

M

– P

ower

flow

opt

imiz

atio

n

B

– G

ener

atio

n di

spat

ch o

ptim

izat

ion

M

– In

tegr

atio

n w

ith m

arke

t mod

els

M

Page 114: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-12

Tab

le 4

-3 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r E

mer

gen

cy R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Rea

l-tim

e de

term

inat

ion

of R

emed

ial A

ctio

n lo

ad a

nd g

ener

atio

n sh

eddi

ng u

pon

inse

cure

tran

smis

sion

ope

ratin

g co

nditi

ons:

– D

eter

min

atio

n of

trig

gers

for

fast

load

/gen

erat

ion

shed

ding

(F

SM

stu

dy)

B

L M

M

– P

re-a

rmin

g of

fast

load

/gen

erat

ion

shed

ding

for

diffe

rent

tr

igge

rs (

real

-tim

e)

C

C

L

– P

rote

ctio

n ac

tions

for

fast

load

/gen

erat

ion

shed

ding

(im

med

iate

tim

e)

I

I

I

I I

L

– S

ecur

e, a

dapt

ive

rest

orat

ion

of lo

ads

and

gene

ratio

n (r

eal-t

ime)

M

M

, C

M, C

M

, C

M, C

M

L

Rea

l-tim

e de

term

inat

ion

of r

emed

ial i

slan

ding

upo

n in

secu

re

tran

smis

sion

ope

ratin

g co

nditi

ons:

– C

oord

inat

ion

of lo

ad-g

ener

atio

n ba

lanc

es w

ith g

ener

atio

n to

lera

nces

M

M

L

– T

ime

sync

hron

izat

ion

of s

epar

atio

n op

erat

ions

I I

I I

I, M

L

– R

espe

ctin

g th

e tim

e-fr

eque

ncy

zone

con

stra

ints

and

vol

tage

lim

its

M

M

M

– Lo

ad a

nd g

ener

atio

n ba

lanc

ing

in is

land

s: a

dapt

ive

unde

r-fr

eque

ncy

load

she

ddin

g, a

dapt

ive

load

res

tora

tion,

and

fast

an

d ac

cura

te g

ener

atio

n ba

lanc

ing

M

I, M

, C

I,

M,

C

M, C

M

, C

I, M

, C

I

I

L

Page 115: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-13

Tab

le 4

-3 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r E

mer

gen

cy R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Res

tora

tion

of p

ower

sys

tem

inte

grity

:

– D

eter

min

atio

n of

the

cond

ition

s fo

r re

stor

atio

n M

M

M

M

M

M

M

M

M

M

– D

eter

min

atio

n of

syn

chro

niza

tion

poin

ts

M

M

M

C

M

M

M

– R

etur

n to

nor

mal

M

M

, C

M, C

M

, C

M, C

C

M

M

L C

Su

bst

atio

n p

rote

ctio

n s

yste

m e

mer

gen

cy o

per

atio

ns

Pow

er s

yste

m p

rote

ctio

n re

acts

to p

ower

sys

tem

faul

ts:

– P

rote

ctio

n ac

tions

with

in a

sub

stat

ion

I

I

I

I

L

– P

rote

ctio

n ac

tions

bet

wee

n su

bsta

tions

I I

I I

L

Em

erge

ncy

oper

atio

ns p

erfo

rms

unde

r/ov

er-f

requ

ency

lo

ad/g

ener

atio

n sh

eddi

ng (

both

from

rel

ayin

g or

ope

rato

r co

ntro

l) M

I,

M,

C

I, M

, C

I

I M

L

Em

erge

ncy

oper

atio

ns p

erfo

rms

unde

r/ov

er-v

olta

ge lo

ad s

hedd

ing

(bot

h fr

om r

elay

ing

or o

pera

tor

cont

rol)

M

I, M

, C

I,

M,

C

I I

M

L

Em

erge

ncy

oper

atio

ns p

erfo

rms

cond

ition

al lo

caliz

ed lo

ad s

hedd

ing

in r

espo

nse

to th

e fo

llow

ing:

– R

ecov

ery

from

vol

tage

or

freq

uenc

y-ba

sed

load

she

ddin

g M

I,

M,

C

I, M

, C

I

I M

L

– LT

C c

ontr

ol/b

lock

ing

M

I, M

, C

I,

M,

C

I, C

I I

M

L

Page 116: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-14

Tab

le 4

-3 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r E

mer

gen

cy R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

– S

hunt

con

trol

M

I,

M,

C

I, M

, C

I

I M

L

– S

erie

s co

mpe

nsat

ion

cont

rol

M

I, M

, C

I,

M,

C

I I

M

L

– S

yste

m s

epar

atio

n de

tect

ion

M

I, M

, C

I,

M,

C

I I

M

L

– W

ide

area

rea

l tim

e in

stab

ility

rec

over

y M

I,

M,

C

I, M

, C

I

I M

L

Co

ntr

ol c

ente

r em

erg

ency

op

erat

ion

s

Ope

rato

rs r

espo

nd m

anua

lly to

em

erge

ncy

alar

ms

M

M, C

M

, C

M, C

M

, C

M

M

M

L

SC

AD

A/E

MS

aid

s op

erat

ors

in lo

catin

g fa

ult

M

M, C

M

, C

M, C

M

, C

M

M

M

L

Ope

rato

rs d

ispa

tch

field

cre

ws

for

rest

orat

ion

M

M, C

M

, C

M, C

M

, C

M

M

M

L

SC

AD

A s

yste

m p

erfo

rms

inte

llige

nt a

larm

pro

cess

ing:

– Lo

cal a

larm

red

uctio

n w

ithin

sub

stat

ion

M

M, C

M

, C

M, C

M

, C

M

M

M

L

– C

entr

aliz

ed a

larm

red

uctio

n ba

sed

on e

vent

s fr

om m

ultip

le

subs

tatio

ns

M

M, C

M

, C

M, C

M

, C

M

M

M

L

SC

AD

A s

yste

m p

erfo

rms

dist

urba

nce

mon

itorin

g an

alys

is (

incl

udin

g fa

ult l

ocat

ion)

M

M

, C

M, C

M

, C

M, C

M

M

M

L

Page 117: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-15

Tab

le 4

-3 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

n R

equ

irem

ents

fo

r E

mer

gen

cy R

eal-

Tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

SC

AD

A/E

MS

per

form

s dy

nam

ic li

mit

calc

ulat

ions

for

tran

sfor

mer

s an

d br

eake

rs b

ased

on

real

tim

e da

ta fr

om e

quip

men

t mon

itors

M

M

, C

M, C

M

, C

M, C

M

M

M

L

SC

AD

A/E

MS

per

form

s pr

e-ar

min

g of

fast

act

ing

emer

genc

y au

tom

atio

n

M

M, C

M

, C

M, C

M

, C

M

M

M

L

SC

AD

A/E

MS

gen

erat

es s

igna

ls fo

r em

erge

ncy

supp

ort b

y di

strib

utio

n ut

ilitie

s (a

ccor

ding

to th

e T

&D

con

trac

ts):

– E

mer

genc

y vo

ltage

and

var

con

trol

for

prov

idin

g di

spat

chab

le

real

and

/or

reac

tive

load

s M

M

, C

M, C

M

, C

M, C

M

M

M

L

– E

mer

genc

y lo

ad r

e-ba

lanc

ing

betw

een

T/D

sub

stat

ions

by

feed

er r

econ

figur

atio

n M

M

, C

M, C

M

, C

M, C

M

M

M

L

– A

ctiv

atio

n of

inte

rrup

tible

/cur

taila

ble

load

M

M

, C

M, C

M

, C

M, C

M

M

M

L

– A

ctiv

atio

n of

dire

ct lo

ad c

ontr

ol

M

M, C

M

, C

M, C

M

, C

M

M

M

L

– A

ctiv

atio

n of

dis

trib

uted

res

ourc

es

M

M, C

M

, C

M, C

M

, C

M

M

M

L

– A

ctiv

atio

n of

oth

er lo

ad m

anag

emen

t fun

ctio

ns

M

M, C

M

, C

M, C

M

, C

M

M

M

L

Ope

rato

rs p

erfo

rms

syst

em r

esto

ratio

ns b

ased

on

syst

em

rest

orat

ion

plan

s pr

epar

ed (

auth

oriz

ed)

by o

pera

tion

man

agem

ent

M

M, C

M

, C

M, C

M

, C

M

M

M

L

Page 118: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-16

4.2.

4 P

ost

Rea

l-T

ime

Tra

nsm

issi

on

Op

erat

ion

Tab

le 4

-4

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s R

equ

irem

ents

fo

r P

ost

Rea

l-ti

me

Op

erat

ion

s

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Po

st o

per

atio

ns

All

syst

ems

arch

ive

logs

and

rep

orts

in s

earc

habl

e da

taba

ses

L

Eng

inee

rs a

nd a

udito

rs r

esea

rch

info

rmat

ion

from

thes

e lo

gs a

nd

repo

rts

M

Met

ers

are

read

A

M

L

Po

wer

sys

tem

eq

uip

men

t m

ain

ten

ance

Sub

stat

ion

and

line

mai

nten

ance

incl

udin

g op

erat

ion

bloc

king

:

– P

erio

dic

(tim

e-ba

sed)

mai

nten

ance

S

S

S

S

S

S

S

S

S

S

S

– B

ased

on

age

of e

quip

men

t S

S

S

S

S

S

S

S

S

S

S

– B

ased

on

pred

ictiv

e m

odel

s dr

iven

by

real

-tim

e da

ta

A

A

A

A

A

A

A

A

A

A

A

Page 119: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-17

Tab

le 4

-4 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

ns

Req

uir

emen

ts f

or

Po

st R

eal-

tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Mai

nten

ance

sta

ff m

aint

ain

tran

smis

sion

line

s:

– R

eque

st th

at o

pera

tor

bloc

k re

clos

ing

for

mai

nten

ance

pu

rpos

es

M

M

M

L

– M

aint

enan

ce s

taff

prov

ides

info

rmat

ion

for

upda

ting

rele

vant

da

taba

ses

L

– M

aint

enan

ce s

taff

acce

ss s

ubst

atio

n dr

awin

gs e

lect

roni

cally

A

SC

AD

A/E

MS

Mai

nte

nan

ce

SC

AD

A/E

MS

per

sonn

el u

pdat

e S

CA

DA

/EM

S d

atab

ases

A

A

A

A

A

A

A

A

A

A

A

SC

AD

A/E

MS

per

sonn

el u

pdat

e E

MS

app

licat

ions

A

SC

AD

A/E

MS

per

sonn

el u

pdat

e op

erat

or in

terf

aces

A

SC

AD

A/E

MS

per

sonn

el u

pdat

e in

terf

aces

with

oth

er s

yste

ms

A

A

SC

AD

A/E

MS

per

sonn

el p

erfo

rm d

iagn

ostic

s of

the

SC

AD

A/E

MS

sy

stem

s

A

Op

erat

or

and

SC

AD

A/E

MS

per

son

nel

tra

inin

g

Ope

rato

rs a

nd S

CA

DA

/EM

S p

erso

nnel

per

form

per

iodi

c tr

aini

ng b

y us

ing

the

Ope

rato

r T

rain

ing

Sim

ulat

or

A

A

A

A

A

A

A

A

A

A

A

A

Ope

rato

rs a

nd S

CA

DA

/EM

S p

erso

nnel

par

ticip

ate

in a

dvan

ced

educ

atio

n pr

ogra

ms

A

A

A

A

A

A

A

A

A

A

A

A

Page 120: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-18

Tab

le 4

-4 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

ns

Req

uir

emen

ts f

or

Po

st R

eal-

tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

En

gin

eeri

ng

Pro

tect

ion

engi

neer

s pe

rfor

m p

rote

ctio

n en

gine

erin

g:

– D

utie

s: b

ase

case

, fau

lt st

udie

s, r

elay

set

tings

, pro

tect

ion

coor

dina

tion,

faul

t ana

lysi

s A

A

A

A

A

A

A

A

A

A

A

A

– N

eeds

dat

a: li

ne/e

quip

men

t cap

acity

, rel

ay s

pecs

, PT

/CT

ra

tios,

faul

t rec

ords

, SO

E d

ata,

eve

nt in

fo (

rela

y 'ta

rget

s' -

w

hich

ele

men

t pic

ked

up)

A

A

A

A

A

A

A

A

A

A

A

A

Sub

stat

ion

engi

neer

s pe

rfor

m s

ubst

atio

n en

gine

erin

g S

S

S

S

S

S

S

S

S

S

S

S

Tra

nsm

issi

on e

ngin

eers

per

form

tran

smis

sion

line

eng

inee

ring

S

S

S

S

S

S

S

S

S

S

S

S

Eng

inee

ring

staf

f pro

vide

s in

form

atio

n fo

r up

datin

g re

leva

nt

data

base

s -

from

site

/ on

line

C

C

C

C

C

C

C

C

C

C

Co

nst

ruct

ion

man

agem

ent

Con

stru

ctio

n m

anag

ers

man

age

asse

ts

A

A

A

A

A

A

A

A

A

A

A

Con

stru

ctio

n m

anag

ers

plan

con

stru

ctio

n pr

ojec

ts

A

Con

stru

ctio

n m

anag

ers

man

age

crew

ass

ignm

ents

A

Con

stru

ctio

n pe

rson

nel p

rovi

des

info

rmat

ion

for

upda

ting

rele

vant

da

taba

ses

- fr

om th

e si

te /

onlin

e A

A

A

A

A

A

A

A

A

A

A

Con

stru

ctio

n pe

rson

nel a

cces

s su

bsta

tion

draw

ings

ele

ctro

nica

lly

A

Page 121: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

D

evel

opin

g F

unct

iona

l Req

uire

men

ts fo

r Su

bsta

tion

Aut

omat

ion

Equ

ipm

ent,

Syst

ems,

and

App

lica

tion

s

4-19

Tab

le 4

-4 (

Co

nt.

) T

ran

smis

sio

n O

per

atio

n F

un

ctio

ns

Req

uir

emen

ts f

or

Po

st R

eal-

tim

e O

per

atio

ns

Co

des

: B =

bef

ore

real

tim

e; I

= in

stan

tane

ous

sign

alin

g; M

= r

eal-t

ime

mon

itorin

g; C

= r

eal-t

ime

cont

rol o

r se

tting

s; A

= a

fter

real

-tim

e m

onito

ring;

S

= s

tatis

tical

ana

lysi

s; P

= p

ower

flow

ana

lysi

s; L

= lo

ggin

g

S

ub

stat

ion

Au

tom

atio

n In

form

atio

n

Tra

nsm

issi

on

Op

erat

ion

Fu

nct

ion

s

Electric Power Measurements

Circuit Breakers

Reclosers

Load Tap Changers and Transformers

Capacitor Controllers

Protection

Fault Indication and Location

SOE and Disturbance Fault Recording

Metering

Logging and Archiving

Substation Configuration

Other

Bla

ck s

tart

:

– T

o be

dec

ided

Page 122: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-20

4.3 Examples of Key Substation Automation Power System Functions Based on the IntelliGrid Architecture

The IntelliGrid Project4 identified over 400 major existing and future power system functions, of which at least 130 are directly related to substation automation, transmission, and distribution operations. The list of existing and future transmission operations functions can be found in Appendix A, or on www.IntelliGrid-Architecture.com.

4.3.1 Data Acquisition and Control (DAC) Functions Within Substation Automation

Power system real-time data are the source of most information required for power system operations. Control over the power system equipment can be achieved by issuing control commands and setting parameters. Data acquisition and control (DAC) functions are the means for computer applications to have access to this information and to be able to issue control commands to power system equipment.

The DAC functions in substation automation form the basis of most real-time transmission and distribution operations. The DAC functions provide real-time data, statistical data, and other calculated and informational data from the power system to systems and applications that use the data. The DAC functions also supports the issuing of control commands to power system equipment and the setting of parameters in IEDs and other field systems.

The DAC functions comprise multiple types of mechanisms for data retrieval and issuing of control commands to power system equipment. They can range from the simple to the very sophisticated. These mechanisms are often used in conjunction with each other to provide the full range of DAC interactions. In turn, the DAC functions are used by other functions, such as the SCADA systems, EMS, protection engineering Systems, advanced distribution automation (ADA), and maintenance personnel, as the primary means for their interactions with the power system equipment.

Within a substation, DAC functions are spread out throughout many devices and usually involve a hierarchy of controllers, IEDs, data concentrators, substation master systems, and other computerized systems. In a control center, DAC functions include the monitoring and control actions of the SCADA systems, as well as the passing of key data to the EMS, protection engineering systems, maintenance systems, and even to executives.

4.3.2 IntelliGrid Environments

The IntelliGrid Architecture (IntelliGrid-Architecture.com) uses the concept of IntelliGrid Environments as a means for linking power system functions with the standards and

4 The Integrated Energy and Communications Systems Architecture, E2I/EPRI IntelliGrid Project Report: September, 2004. IntelliGrid web site at IntelliGrid-Architecture.com

Page 123: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-21

technologies that can best meet their communication and information requirements. An IntelliGrid Architecture Environment is defined as a communication/information environment where the configuration, quality of service, security, and data management requirements of functions are the same or very similar.

Twenty (20) IntelliGrid Environments were identified. Figure 4-1 illustrates four IntelliGrid Environments: the two main IntelliGrid Environments within a substation, one environment between a substation and the control center, and one environment within a control center.

Figure 4-1 Example of IntelliGrid Environments – Two Environments Within the Substation, One Environment Between the Substation and the Control Center, and One Environment Within the Control Center

Some of the key DAC functions are shown in Figure 4-2 and are discussed in the following sections.

Page 124: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Dev

elop

ing

Fun

ctio

nal R

equi

rem

ents

for

Subs

tati

on A

utom

atio

n E

quip

men

t, Sy

stem

s, a

nd A

ppli

cati

ons

4-22

F

igu

re 4

-2

Dat

a A

cqu

isit

ion

an

d C

on

tro

l fo

r D

istr

ibu

tio

n O

per

atio

ns

(UM

L U

se C

ase)

Page 125: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-23

4.3.3 Substation High-Speed DAC – Direct Power Equipment Monitoring and Control in the Deterministic, Rapid-Response Intra-Substation Environment

4.3.3.1 Description of Function – Direct Power Equipment Monitoring and Control

Direct power equipment monitoring and control is performed by an Intelligent Electronic Device (IED), a Remote Terminal Unit (RTU), or another microprocessor-based controller, sometimes based on internally generated control commands and sometimes based on externally requested control commands. These controllers monitor sensors for data about the power system and their associated power equipment (the actual equipment connected to the power system). The communications links are often very short (a few meters), but can also entail multi-mile links. The communications media typically are copper wires or optical fibers, but they can include power line carrier, radio-based media, and possibly other media. They either use internal applications or are instructed by other entities to issue control signals to associated power system equipment. Consider the following examples:

• A Load Tap Changer IED raises and lowers the transformer tap position according to preset algorithms based on voltage levels sensed by Potential Transformers (PTs).

• A circuit breaker IED issues an electromechanical or solid-state-based trip signal to a circuit breaker.

• A DER IED controller senses status and measurements of a DER generator and its prime mover and then issues start and stop signals.

4.3.3.2 IntelliGrid Environment of the Function – Deterministic Rapid Response Intra-Substation Environment

As determined in the IntelliGrid Architecture, direct power equipment monitoring and control is within the deterministic rapid response intra-substation environment, which is described in the IntelliGrid Architecture5 in the following manner:

The two Deterministic Rapid Response environments carry data exchanges that were previously considered too fast, too high volume, or too deterministic to carry on a generalized network. These data exchanges traditionally took place either within a single device or on dedicated lines.

5 Ibid.

Page 126: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-24

Typical applications: Advances in technology have now made it possible to exchange data over LANs and WANs:

• Between protective relays to coordinate protection schemes

• Between those devices sampling measurements (for example, smart current or voltage transformers) and those processing the data

• Between multiple devices that are distributing other real-time processes that previously took place on a single device, for example, process control. Another name that has been used for Deterministic Rapid Response Intra-Substation is “process bus.”

Characteristics: The Deterministic Rapid Response environments require extremely high-speed, high volume, or both, with timing requirements measured in milliseconds or lower. Violation of these requirements might cause equipment damage or safety issues.

Similar Environments: The Deterministic Rapid Response Intra-Substation environment is limited within the physical boundaries of the substation. Its security requirements can therefore be somewhat lower, and its timing requirements somewhat stricter, than Deterministic Rapid Response Inter-Site. Data management is not a major concern because of its limited scope.

4.3.3.3 Requirements Defining the Deterministic Rapid Response Intra-Substation Environment

The requirements that define the deterministic rapid response intra-substation environment are applicable to the direct monitoring and control of power equipment within a substation. The requirements for defining this high-speed deterministic, rapid response intra-substation environment are listed here:

1. Configuration requirements

a. Provide point-to-point interactions between two entities

b. Support interactions within a contained environment (for example, substation or control center)

2. Quality of service requirements

a. Provide ultra high-speed messaging (short latency) of less than 4 ms

b. Support extremely high availability of information flows of 99.999+ (~5 minutes)

c. Support high precision of data (< 0.5 variance)

d. Support time synchronization of data for age and time-skew information

Page 127: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-25

3. Security requirements

a. Provide authorization service for access control (resolving a policy-based access control decision to ensure that authorized entities have appropriate access rights and authorized access is not denied)

b. Provide security policy service (concerned with the management of security policies)

4. Data management requirements

a. Support keeping data consistent and synchronized across systems and/or databases

b. Support specific standardized or de facto object models of data

4.3.3.4 Recommended Technologies for This Environment

Based on these requirements, the recommended standards, technologies, and best practices for all information exchanges within this environment are:

1. Energy Industry-Specific Technologies

a. Utility Field Device Related Data Exchange Technologies

• IEC61850 Part 7-2 - GSE (GOOSE and GSSE - Configuration, Quality of Service

• IEC61850 Part 7-2 - SMV (Sampled Measured Values) - Configuration

• IEC61850 Parts 7-3 and 7-4 - Substation Object Modeling - Quality of Service, Data Management

• IEEE C37.94 - Standard for N x 64 kbps Optical Fiber Interfaces between - Quality of Service

2. Communications Industry Technologies

a. Link layer and physical technologies

• Ethernet - Quality of Service

• Bridges/Switches - Configuration

• Asynchronous Transfer Mode (ATM) - Configuration, Quality of Service

b. Wireless Technologies

• Global Positioning System (GPS) - Quality of Service, Data Management

Page 128: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-26

3. Security Technologies

a. Policy and Framework Related Technologies

• ISO/IEC 10164-8:1993 Security Audit Trail Function - Information technology - Open Systems Interconnection - Systems Management - Security

• ISO/IEC 10181-7:1996 Security Audit and Alarms Framework - Information technology - Open Systems Interconnection -- Security Frameworks for Open Systems - Security

• FIPS PUB 112 Password Usage - Security

b. General Security Technologies

• Role-Based Access Control - Security

• Service Level Agreements (SLA) - Security

c. Application layer security technologies

• IEC 62351-6 Security for IEC 61850 GOOSE, GSSE, and SMV Profiles - Security

4. Network and Enterprise Management Technologies

a. Network management technologies

• IEC 62351-7 Objects for Network Management - Quality of Service, Data Management

4.3.4 Substation IED Interactions in the Deterministic, Rapid-Response Intra-Substation Environment and the Critical Intra-Substation Environment

4.3.4.1 Description of the Function – Local Interactions Among Intelligent Electronic Devices

Local interactions among IEDs are undertaken to respond to a relatively local situation. The communications media are typically LANs, point-to-point cables, and point-to-multi-point radio channels. Protection actions require very deterministic rapid response communication channels, with response timeframes of 1– 4 ms. Consider the following examples:

• A protection IED issues a trip command over a deterministic rapid response LAN to a circuit breaker IED within a substation, based on its detection of different power system measurements, such as low frequency or current overload.

• Multiple automated switch IEDs, using point-to-multi-point spread spectrum radio communications media, respond to a fault condition on a feeder segment by opening and closing switches to isolate the fault and restore power to unaffected feeder segments.

Page 129: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-27

4.3.4.2 Environments of the Function – Deterministic Rapid Response Intra-Substation Environment and Critical Operations Intra-Substation Environment

This function can involve two of the IntelliGrid Environments:

• Deterministic rapid response intra-substation environment (for protective relaying)

• Critical operations intra-substation environment (for IED interactions not requiring the ultra high speed of protective relaying)

The requirements for the deterministic rapid response intra-substation environment were described in the previous section.

The second IntelliGrid Environment is the critical operations intra-substation environment. It is described in the IntelliGrid Architecture6 as follows:

This environment encompasses the set of requirements traditionally known as “substation automation” and involve information exchanges within a substation that are critical to legal, safe, and reliable power system operations. Devices within the substation coordinate with each other to ensure that the safety of equipment and personnel while optimizing the operation of the network and permitting operators to respond to emergencies.

Typical applications: Uses of this environment may include voltage/VAR control, interlocking, removing equipment for maintenance, updating configurations and settings, responding to faults, load shedding, and manually or automatically restoring service. These tasks were traditionally performed by individual devices but are now are commonly distributed over local area networks.

Characteristics: This environment requires a high level of security because outages, equipment damage, or safety concerns can result from misoperated controls, either manually or automatically generated. Similarly, maintenance of equipment by unauthorized personnel could be disastrous.

Similar Environments: Quality of service requirements are not as strict as with the Rapid Deterministic environments, but response generally must be better than human reaction time.

This environment differs from Critical Operations DAC because it is limited to the substation. Some utilities may find physical security adequate within the substation, while electronic security is vital outside the substation. Quality of service requirements may also be less vital between substation and control center than within the substation itself, since the substation automates many critical functions locally.

6 Ibid.

Page 130: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-28

4.3.4.3 Requirements Defining the Critical Operations Intra-Substation Environment

The requirements that define the critical operations intra-substation environment are applicable to local IED interactions. These requirements are listed here:

1. Configuration Requirements

a. Provide point-to-point interactions between two entities

b. Support peer to peer interactions

c. Support interactions within a contained environment (for example, substation or control center)

2. Quality of Service Requirements

a. Provide high-speed messaging of less than 1 second

b. Support very high availability of information flows of 99.99+ (~1 hour)

c. Support time synchronization of data for age and time-skew information

3. Security Requirements

a. Provide authorization service for access control (resolving a policy-based access control decision to ensure that authorized entities have appropriate access rights and authorized access is not denied)

b. Provide information integrity service (data have not been subject to unauthorized changes or these unauthorized changes are detected)

c. Provide audit service (responsible for producing records that track security relevant events)

d. Provide credential renewal service (notify users prior to expiration of their credentials)

e. Provide security policy service (concerned with the management of security policies)

f. Provide single sign-on service (relieve an entity having successfully completed the act of authentication once from the need to participate in reauthentications upon subsequent accesses to managed resources for some reasonable period of time)

g. Provide security discovery (the ability to determine what security services are available for use)

4. Network and System Management Requirements

a. Provide network management (management of media, transport, and communication nodes)

b. Provide system management (management of end devices and applications)

5. Data Management Requirements

a. Support the management of large volumes of data flows

b. Support keeping the data up-to-date

Page 131: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-29

c. Support extensive data validation procedures

d. Support specific standardized or de facto object models of data

e. Provide discovery service (discovering available services and their characteristics)

f. Provide conversion and protocol mapping

4.3.4.4 Recommended Standards and Technologies for the Critical Operations Intra-Substation Environment

Based on these requirements, the recommended standards, technologies, and best practices for all information exchanges within this environment are listed here:

1. Energy Industry-Specific Technologies

a. Utility Field Device Related Data Exchange Technologies

• ISO 9506 MMS - Manufacturing Messaging Specification - Configuration, Quality of Service

• IEC61850 - Substation Automation Communications - Configuration

• IEC61850 Part 7-2 - GSE (GOOSE and GSSE) - Configuration, Quality of Service

• IEC61850 Part 7-2 - SMV (Sampled Measured Values) - Configuration

• IEC61850 Part 7-2 - Abstract Common Services Interface (ACSI) - Configuration, Quality of Service, Data Management

• IEC61850 Parts 7-3 and 7-4 - Substation Object Modeling - Network Management, Data Management

• IEC61850 Part 6 - Substation Configuration Language - Network Management, Data Management

• IEC61850 Power Quality Object Models - Data Management

• IEC62350 - Object Models for Distributed Energy Resources (DER) - Network Management, Data Management

• IEC62349 - Hydro Power Plant Object Models - Network Management, Data Management

• IEC61400-25 for Wind Power Object Models - Network Management, Data Management

2. Communications industry Technologies

a. Networking Technologies

• Internet Protocol Version V4 (IPV4) - Configuration

b. IP-based Transport Protocols

• Transmission Control Protocol (TCP) - Configuration

Page 132: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-30

c. Application Layer Protocols

• SNTP (Network Time Protocol) - Quality of Service

d. Link Layer and Physical Technologies

• IEEE 802 MAC Addresses - Configuration

• Ethernet - Configuration

• Bridges/Switches - Configuration

• Asynchronous Transfer Mode (ATM) - Configuration

e. Wireless Technologies

• Global Positioning System (GPS) - Quality of Service

3. Security Technologies

a. Policy and Framework Related Technologies

• ISO/IEC 10164-8:1993 Security Audit Trail Function - Information technology - Open Systems Interconnection - Systems Management - Security

• ISO/IEC 18014-1:2002 Time-Stamping Services - Information technology - Security Techniques - Part 1: Framework - Quality of Service, Security, Data Management

• ISO/IEC 10181-7:1996 Security Audit and Alarms Framework - Information technology - Open Systems Interconnection -- Security Frameworks for Open Systems - Security

• FIPS PUB 112 Password Usage - Security

• FIPS PUB 113 Computer Data Authentication - Security

• RFC 2196 Site Security Handbook - Security

• RFC 2401 Security Architecture for the Internet Protocol - Security

• RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework - Security

b. General Security Technologies

• FIPS 197 for Advanced Encryption Standard (AES) - Security

• Role-Based Access Control - Security

• FIPS 186 Digital Signatures Standard (DSS) - Security

• Intrusion Detection Technologies - Security, Network Management

• Intrusion Prevention Systems (IPS) - Security, Network Management

• Service Level Agreements (SLA) - Security

Page 133: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-31

c. Media and Network Layer Technologies

• Secure IP Architecture (IPSec) - Security

• IEEE 802.11i Security for Wireless Networks - Security

• Remote Authentication Dial In User Service (RADIUS) - Security

• ATM Security - Security

• AGA-12 Cryptographic Protection of SCADA Communications General Recommendations - Security

d. Transport Layer Security Technologies

• Transport Layer Security (TLS)/Secure Sockets Layer (SSL) - Security

e. Application Layer Security Technologies

• SNMP Security - Security, Network Management

• RFC 1305 Network Time Protocol (Version 3) Specification, Implementation - Quality of Service, Security

• IEC 62351-3 Security for Profiles including TCP/IP - Security

• IEC 62351-4 Security for Profiles including MMS (ISO-9506) - Security

• IEC 62351-5 Security for IEC 60870-5 and Derivatives - Security

• IEC 62351-6 Security for IEC 61850 GOOSE, GSSE, and SMV Profiles - Security

f. XML Related Technologies

• OASIS Security Assertion Markup Language (SAML) - Security

• Secure XML - Security

4. Network and Enterprise Management Technologies

a. Network Management Technologies

• Simple Network Management Protocol (SNMP) - Network Management

• IEC 62351-7 Objects for Network Management - Quality of Service, Network Management, Data Management

The IntelliGrid Architecture describes additional services and alternate technologies. These can be seen in on the IntelliGrid web site IntelliGrid-Architecture.com).

Page 134: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-32

4.3.5 SCADA DAC Functional Requirements in the Critical DAC Environment

4.3.5.1 Description of the Function – DAC Functional Requirements for SCADA Systems

SCADA systems perform remote monitoring and control of field equipment and IEDs. The term SCADA is used to imply any centralized system, which retrieves data from remote sites and may issue control commands when authorized. These SCADA systems are typically located in a utility control center. However, they may include an engineering SCADA system, which retrieves protection data or disturbance data, or a maintenance SCADA system, which monitors the health of both power system and communications equipment.

SCADA system monitoring can use communication channels directly to IEDs, via remote terminal units (RTUs), through a data concentrator, through a substation master, or through a DER management system. The communications media can be of virtually any type, as long as s response times of one second can be accommodated. Although typically seen as used for only real-time distribution operations, the data acquired by the SCADA system can be used by many different systems, applications, and personnel in the control center. This function is limited to the monitoring and control function by SCADA systems. Other functions (such as the ADA function) describe their interactions with the SCADA systems.

Consider the following examples of SCADA system monitoring and control:

• Power system operations – SCADA system receives real-time data from power system equipment via the following methods:

– RTUs

– IEDs inside substations

– IEDs along feeders

– Substation masters

– DER (or other generation) management systems

– Other control centers

– Manual entry

• Power system operations – SCADA system issues control commands to power system equipment in real-time via the following methods:

– RTUs

– IEDs inside substations

– IEDs along feeders

– Substation masters

– DER (or other generation) management systems

– Other control centers (if authorized)

Page 135: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-33

• Power system operations – SCADA system receives metering information.

• Data management – SCADA system receives power equipment configuration data from devices. It may have its own communication channels to the remote sites, or it may acquire these data through the distribution operations SCADA system.

• Engineering SCADA system receives sequence of events data, oscillographic data (special handling required), historical data, and statistical data. It may have its own communication channels to the remote sites, or it may acquire these data through the distribution operations SCADA system.

• Μaintenance SCADA system receives data related to the health of power system equipment and communications equipment. It may have its own communication channels to the remote sites, or it may acquire these data through the distribution operations SCADA system.

• Planning SCADA system receives data that can be used for statistical analysis of power system measurements: maximums, minimums, averages, trends, profiles, and power quality metrics, needed for short-term and long-term planning.

4.3.6 Energy Management System Information Requirements in the Intra-Control Center Environment

4.3.6.1 Description of the Function – EMS Operations

Energy Management System (EMS) operations describe all of the applications that use the substation information and the additional data from various other applications and databases to assist in the operation of the distribution power system. Some of these applications include:

1. SCADA functions such as the user interface, alarm management, disturbance analysis, and other basic capabilities

2. Generation management functions such as load forecast, automatic generation control, economic and/or merit dispatch, generation monitoring, generation/energy schedules, ancillary services (balancing market stack, and other generation management functions related to the energy market and to system reliability requirements.

3. Network analysis functions, such as state estimation, dispatcher power flow, contingency analysis, optimal power flow, flowgate analysis, and other transmission system management functions.

4. Self-healing grid (SHG) applications, whose objective is to evaluate power system behavior in real-time, prepare the power system for withstanding credible combinations of contingencies, prevent wide-area blackouts, and accommodate fast recovery from emergency state to normal state.

The SHG function is a new concept that has not been fully implemented in any system. Therefore, it is described here in more detail.

Page 136: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-34

The SHG function comprises a set of computing applications for information gathering, modeling, decision-making, and controlling actions. These applications reside in central and/or widely distributed systems such as relay protection, remedial automation schemes (RAS), local controllers, and other distributed intelligence systems. All these applications and system components operate in a coordinated manner and are adaptive to the actual situations.

The conventional methodology for emergency control is based on off-line studies for selection of the local emergency automation schemes, their locations, and their settings. Such off-line studies are usually performed for selected operating conditions based on typical cases and on previous emergencies. However, the design of remedial actions and emergency automation schemes based on previous emergencies may be ineffective for the future emergencies. In reality, the emergency situations often occur under conditions that are quite different from the study cases. With the advent of deregulation, the energy schedules are derived from financial considerations rather than strictly power operations considerations. Therefore, the types of possible contingencies increase substantially, and it would be very difficult to study with purely off-line analyses. Not only are there increased pressures from deregulation, there are new challenges imposed by the involvement of distribution systems and customers in preventing and responding to power system emergencies. For instance, with the increased number of distributed energy resource (DER) devices connected to the distribution system, distribution operations have to expand to monitor and manage (if not actually control) these DER devices. The advances of Distribution Management Systems (DMS) and ADA make these systems available for real-time coordination of transmission and distribution operations in normal, emergency, and restorative states of the power systems.

The SHG will be supported by fast data acquisition systems (wide area measurement systems and SCADA) and will include fast simulation and decision-making applications observing wide power system areas. These wide-area applications will coordinate the behavior of distributed control systems (regional EMS, DMS, Plant EMS, RAS, and relay protection). These distributed systems and actuators will perform adequately fast under emergency and later under restorative conditions following the rules and settings preset by the upper level simulation and decision-making applications. The coordination of different systems and actuators will be accomplished in a hierarchical manner. Some directive from the upper level, for example, from the ISO/RTO EMS will be transmitted to the regional EMS, and some commands and settings will be downloaded directly to the actuators. The regional EMS will transmit some directives to the DMS and plant EMS and some commands and settings will be directly downloaded to the actuators, which are in the corresponding areas of responsibility. Some local actuators will be integrated into distributed intelligence schemes and will communicate among themselves in a peer-to-peer manner. The rules of behavior of the distributed intelligence schemes can be preset by the upper control system. (See Figure 4-3).

The power system operators will be the persons in charge (PIC) for the performance of the entire SHG and will participate in the system setup and decision-making processes, which allow sufficient time for the operators to perform an educated action. Under emergency conditions, when fast and complex actions should be performed, the pre-armed and adaptive local and distributed applications and automatic schemes should be the main executors for the protection of equipment and prevention of blackouts.

Page 137: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-35

The future control system for the self-healing grid will differ from the current approaches by implementing significantly more automated controls instead of supervisory controls by the operators and by aiming at preservation of adequate integrity of the generation-transmission-distribution-customer system instead of self-protection of equipment only.

Figure 4-3 Integration of EMS Transmission Functions with DMS/ADA Distribution Functions – A Real-Time Adaptive Decision-Making and Wide Area Control System Is Required to Meet the Objectives of the Self-Healing Grid

4.3.6.2 IntelliGrid Environment of the Function – Intra-Control Center Environment

All of these applications require extensive, flexible, and highly reliable information exchanges, taking place primarily within a control center environment with some inter-

Page 138: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-36

control center actions. Both of these environments are described in the IntelliGrid Architecture. The following description covers only the IntelliGrid Intra-Control Center Environment7:

This environment represents communications between modules of a single control center, typically over a local area network within a single physical building.

Typical Applications: Updating databases and human-machine interfaces with data gathered from the “front-end processors” within Energy Management Systems (EMSs) or Distribution Management Systems (DMSs).

Characteristics: Located in a very secure and reliable physical environment, but with a huge amount of data to manage and distribute between a variety of platforms and database technologies. Updates must happen in at least human response times for some data.

Similar Environments: This environment carries All of the data brought in via High Security DAC or Low Security DAC, but need not be transmitted in as reliable a format. Carries similar types of data as when the control center communicates with other businesses (CC/ESP, CC/Customer Equipment, or CC/corporations). However, the real-time requirements are tighter, security is nowhere near as important, and data formats tend to be proprietary for performance reasons.

4.3.6.3 Requirements Defining the Intra-Control Center Environment

The requirements that define the Intra-Control Center Environment are applicable to the function—Energy Management System (EMS) operations. The requirements for this function include are listed here:

1. Configuration Requirements

a. Support peer-to-peer interactions

b. Support interactions within a contained environment (for example, substation or control center)

2. Quality of Service Requirements

a. Support high availability of information flows of 99.9+ (~9 hours)

b. Support time synchronization of data for age and time-skew information

3. Security Requirements

a. Provide authorization service for access control (resolving a policy-based access control decision to ensure that authorized entities have appropriate access rights and authorized access is not denied)

b. Provide audit service(responsible for producing records, which track security relevant events)

7 Ibid.

Page 139: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-37

c. Provide security policy service (concerned with the management of security policies)

d. Provide user profile and user management (combination of several other security services)

4. Network and System Management Requirements

a. Provide network management (management of media, transport, and communication nodes)

b. Provide system management (management of end devices and applications)

5. Data Management Requirements

a. Support the management of large volumes of data flows

b. Support keeping the data up-to-date

c. Support extensive data validation procedures

d. Support keeping data consistent and synchronized across systems and/or databases

e. Support timely access to data by multiple different users

f. Support frequent changes in types of data exchanged

g. Support management of data whose types can vary significantly in different implementations

h. Support specific standardized or de facto object models of data

i. Support the exchange of unstructured or special-format data (for example, text, documents, oscillographic data)

j. Provide discovery service (discovering available services and their characteristics)

k. Provide conversion and protocol mapping

4.3.6.4 Recommended Standards and Technologies for the Intra-Control Center Environment

Based on these requirements, the following standards, technologies, and best practices for all information exchanges within this environment are recommended:

1. Energy Industry-Specific Technologies

a. Utility Field Device Related Data Exchange Technologies

• IEC61850 Part 6 - Substation Configuration Language - Network Management, Data Management

b. Utility Control Center Related Data Management Technologies

• IEC 60870-6 (ICCP) - Configuration

• IEC 61970 Part 3 - Common Information Model (CIM) - Data Management

• CIM Extensions for Market Operations - Data Management

Page 140: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-38

• IEC 61970 Part 4 - Generic Interface Definition (GID) - Configuration, Quality of Service, Data Management

• IEC61968 SIDM System Interfaces for Distribution Management - Data Management

• OPEN GIS - Data Management

2. Communications Industry Technologies

a. Access Technologies

• Private Intranet - Configuration

b. Networking Technologies

• Internet Protocol Version V4 (IPV4) - Configuration

c. IP-based Transport Protocols

• Transmission Control Protocol (TCP) - Configuration

d. Application Layer Protocols

• SNTP (Network Time Protocol) - Quality of Service, Data Management

e. Link Layer and Physical Technologies

• IEEE 802 MAC Addresses - Configuration

• Asynchronous Transfer Mode (ATM) - Configuration

f. Wireless Technologies

• Global Positioning System (GPS) - Quality of Service, Data Management

g. Computer Systems Related Technologies

• CORBA and CORBA Services - Data Management

• Web Services - Data Management

• Universal Description, Discovery, and Integration (UDDI) - Data Management

• XML Protocol/Simple Object Access Protocol (SOAP) - Data Management

• Enterprise Java Beans (EJB) - Data Management

• IEEE 1588 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems - Quality of Service

• GUID - Data Management

h. General Internet and De Facto Data Management Technologies

• ANSI/ISO/IEC 8632-1, 2, 3, 4 - Computer Graphics Metafile (CGM) - Data Management

• ISO/IEC 11179 Parts 1 - 6 Metadata Registries - Data Management

• Meta Object Facility (MOF) - Data Management

Page 141: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-39

• XML Metadata Interchange (XMI) - Data Management

• eXtensible Markup Language (XML) - Data Management

• XML Schema (xls) - Data Management

• XSLT - Data Management

• XQuery - Data Management

• ANSI/ISO/IEC 9075 - Structured Query Language (SQL) - Data Management

3. Security Technologies

a. Policy and Framework Related Technologies

• ISO/IEC 10164-8:1993 Security Audit Trail Function - Information technology - Open Systems Interconnection - Systems Management - Security

• ISO/IEC 18014-1:2002 Time-Stamping Services - Information technology - Security Techniques - Part 1: Framework - Quality of Service, Security, Data Management

• ISO/IEC 10181-7:1996 Security Audit and Alarms Framework - Information technology - Open Systems Interconnection -- Security Frameworks for Open Systems - Security

• FIPS PUB 112 Password Usage - Security

• FIPS PUB 113 Computer Data Authentication - Security

• RFC 2196 Site Security Handbook - Security

• RFC 2401 Security Architecture for the Internet Protocol - Security

• RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework - Security

b. General Security Technologies

• Role-Based Access Control - Security

• Intrusion Detection Technologies - Security, Network Management

• Intrusion Prevention Systems (IPS) - Security, Network Management

• Service Level Agreements (SLA) - Security

c. Media and Network Layer Technologies

• Secure IP Architecture (IPSec) - Security

• IEEE 802.11i Security for Wireless Networks - Security

• Remote Authentication Dial In User Service (RADIUS) - Security

• AGA-12 Cryptographic Protection of SCADA Communications General Recommendations - Security

Page 142: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-40

d. Transport Layer Security Technologies

• Transport Layer Security (TLS)/Secure Sockets Layer (SSL) - Security

e. Application Layer Security Technologies

• SNMP Security - Security, Network Management

• RFC 1305 Network Time Protocol (Version 3) Specification, Implementation - Quality of Service, Security, Data Management

• IEC 62351-4 Security for Profiles including MMS (ISO-9506) - Security

• IEC 62351-5 Security for IEC 60870-5 and Derivatives - Security

• IEC 62351-6 Security for IEC 61850 GOOSE, GSSE, and SMV Profiles - Security

f. XML Related Technologies

• OASIS Security Assertion Markup Language (SAML) - Security

• Secure XML - Security

4. Network and Enterprise Management Technologies

a. Network Management Technologies

• Simple Network Management Protocol (SNMP) - Network Management

b. Web-Based Network Management

• Web-Based Enterprise Management (WBEM) - Network Management

4.3.7 Protection Engineering Information Requirements in the Critical and Noncritical Operations DAC Environments

4.3.7.1 Description of the Function – Protection Engineering

This function has not yet been explicitly described in the IntelliGrid Architecture, but has the following basic requirements for protection engineers:

1. Monitoring

a. Access to the log of protection device actions

b. Access to the settings of protection devices

c. Access to fault recorder oscilloscopic and other types of data

d. Access to substation configuration information

2. Control

a. Ability to change protection device settings

b. Ability to change fault recorder settings

Page 143: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-41

4.3.7.2 IntelliGrid Environment of the Function – Critical Intra-Substation and Critical Operations DAC Environments

All of these applications require extensive, flexible, and highly reliable information exchanges between substations and the protection engineering systems. With respect to the IntelliGrid Environments, these applications must typically involve two of the environments—the critical intra-substation environment and the critical operations DAC environment. Both of these have been discussed in previous sections, but additional descriptions are necessary to extend the second environment to include access by non-SCADA systems to substation equipment. These extensions are shown in bold8:

Critical Operations-related Data Acquisition and Control is the environment most resembling what has been traditionally called Supervisory Control and Data Acquisition (SCADA). It represents those messages between a substation and control center that are critical to legal, safe, and reliable power system operations. In addition it captures the requirements for passing data between field sites and operations-related departments within a utility, such as planning departments, engineering departments, and maintenance/construction departments.

Typical applications: For SCADA interactions: Include monitoring and control of substation devices, pole-top devices, and generation plants or distributed energy resources. These are the functions performed by operators in the daily operation or emergency recovery of the power system. For non-SCADA interactions: power system planning for transmission, distribution, generation, and customers. Power system engineering for responding to power quality issues, reliability issues, protection issues, power system configuration issues, etc. Remote access requirements by construction and maintenance departments for new power system facilities, repair of existing facilities, and other remote activities.

Characteristics: It is vital that these message exchanges not be tampered, monitored, or interfered with by unauthorized persons. Quality of service requirements are based around human reaction times. Configuration of the network changes often, and may vary widely. Could also include transfer of data that are high-volume and critical, such as configuration files or fault recordings.

Similar Environments: Critical Operations Data Acquisition and Control is very similar to Critical Operations Intra-Substation except that these exchanges take place between control centers and field equipment, rather than between substations.

4.3.7.3 Requirements Defining the Critical Operations DAC Environment

The requirements defining the critical operations DAC environment were described in Section 4 of this report.

8 Ibid.

Page 144: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-42

4.3.7.4 Recommended Standards and Technologies for the Critical Operations DAC Environment

The recommended standards and technologies for the critical operations DAC environment were described in Section 4.

4.3.8 Mobile Operations and Maintenance Activity Requirements

4.3.8.1 Description of the Function – Mobile Operations and Maintenance Activity Requirements

This function has not yet been explicitly described in the IntelliGrid Architecture. Mobile operations and maintenance activities typically involve field crews who perform O&M activities in substations and in other power system facilities. They often communicate verbally with system operators and other personnel, but more frequently they need access to data about the power system and the ability to respond electronically while undertaking their work. Examples of the data and response capabilities are provided in the following list:

• Work orders

• Written switching orders, with confirmation of actions

• Execution of equipment diagnostics and tests

• Ability to record

• Status of equipment, including real-time queries

• Real-time measurements

• Control of equipment, either through field actions and/or through requests to the system operators

• Alarm and event logs, including sorting and searching capabilities

• Maintenance records of equipment

• Ability to update maintenance records in the field

• Drawings of equipment and configurations

• Updating drawings and configurations

• Maps of equipment locations

• Equipment specifications

• Historical records

• Email

• Time cards and other management issues

Page 145: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-43

4.3.8.2 IntelliGrid Environment of the Function – Field Equipment Maintenance Environment

The mobile operations and maintenance activities are predominantly contained within the field equipment maintenance environment. This environment is described as follows in the IntelliGrid Architecture9:

This environment represents all communications with field crews.

Typical Applications: Asset management, primary equipment monitoring and maintenance, planned outages, statistics gathering, testing, diagnostics, protection engineering, trouble call management, updating of schematics and drawings, emergency (fire, earthquake, flood) response.

Characteristics: Extremely mobile workforce and frequent configuration changes makes wireless communications, ease of use and self-discovery a necessity. Response times in seconds are required due to human reaction times. Data are critical to safe and reliable operation of the grid, and must be keyed to role-based access, that is, only certain employees have access to certain data.

Similar Environments: Similar to both Critical Operations DAC and Noncritical Operations DAC, but with an emphasis on mobile access.

4.3.8.3 Requirements Defining the Field Equipment Maintenance Environment

The requirements defining the critical operations DAC environment were described in a previous section.

1. Configuration Requirements

a. Support interactions between a few clients and many servers

b. Support interactions across widely distributed sites

c. Support mandatory mobile communications

2. Quality of Service Requirements

a. Provide medium speed messaging on the order of 10 seconds

b. Support medium availability of information flows of 99.0+ (~3.5 days)

3. Security Requirements

a. Provide identity establishment service

b. Provide authorization service for access control (resolving a policy-based access control decision to ensure that authorized entities have appropriate access rights and authorized access is not denied)

9 Ibid.

Page 146: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-44

c. Provide information integrity service (data have not been subject to unauthorized changes or these unauthorized changes are detected)

d. Provide firewall transversal

e. Provide user profile and user management (combination of several other security services)

f. Provide security discovery (the ability to determine what security services are available for use)

4. Network and System Management Requirements

a. Provide network management (management of media, transport, and communication nodes)

b. Provide system management (management of end devices and applications)

5. Data Management Requirements

a. Support extensive data validation procedures

b. Support frequent changes in types of data exchanged

c. Support management of data whose types can vary significantly in different implementations

d. Support specific standardized or de facto object models of data

e. Support the exchange of unstructured or special-format data (for example, text, documents, oscillographic data)

f. Support transaction integrity (consistency and rollback capability)

g. Provide discovery service (discovering available services and their characteristics)

h. Provide conversion and protocol mapping

4.3.8.4 Recommended Standards and Technologies for the Field Equipment Maintenance Environment

1. Energy Industry-Specific Technologies a. Utility Field Device Related Data Exchange Technologies

• IEC61850 Parts 7-3 and 7-4 - Substation Object Modeling - Network Management, Data Management

• IEC61850 Part 6 - Substation Configuration Language - Network Management, Data Management

• IEC61850 Power Quality Object Models - Data Management • IEC62350 - Object Models for Distributed Energy Resources (DER) - Network

Management, Data Management • IEC62349 - Hydro Power Plant Object Models - Network Management, Data

Management • IEC61400-25 for Wind Power Object Models - Network Management, Data

Management

Page 147: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-45

b. Utility Control Center Related Data Management Technologies • IEC 61970 Part 3 - Common Information Model (CIM) - Data Management • CIM Extensions for Market Operations - Data Management • IEC 61970 Part 4 - Generic Interface Definition (GID) - Configuration, Quality of

Service, Data Management • IEC61968 SIDM System Interfaces for Distribution Management - Data

Management • OPEN GIS - Data Management

c. Customer Interface Data Management Technologies • IEC62056 - Data Exchange for Meter Reading, Tariff, and Load Control - Data

Management • ANSI C12.19 (Meter Tables) - Data Management • AEIC Guidelines - Data Management

2. Communications Industry Technologies a. Access Technologies

• Public Internet - Configuration • Private Intranet - Configuration

b. Networking Technologies • Internet Protocol Version V4 (IPV4) - Configuration

c. IP-based Transport Protocols • Transmission Control Protocol (TCP) - Configuration

d. Link Layer and Physical Technologies • LAN/MAN Technologies - Configuration • IEEE 802 MAC Addresses - Configuration • Ethernet - Configuration • Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy

(SDH) - Configuration • Asynchronous Transfer Mode (ATM) - Configuration

e. Wireless Technologies • Global System for Mobile Communication (GSM) - Configuration

f. Computer Systems Related Technologies • Web Services - Data Management • Universal Description, Discovery, and Integration (UDDI) - Data Management • XML Protocol/Simple Object Access Protocol (SOAP) - Data Management • Enterprise Java Beans (EJB) - Data Management • GUID - Data Management

Page 148: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-46

g. General Internet and De Facto Data Management Technologies • ANSI/ISO/IEC 8632-1, 2, 3, 4 - Computer Graphics Metafile (CGM) - Data

Management • ISO/IEC 11179 Parts 1 - 6 Metadata Registries - Data Management • Meta Object Facility (MOF) - Data Management • XML Metadata Interchange (XMI) - Data Management • eXtensible Markup Language (XML) - Data Management • XML Schema (xls) - Data Management • ANSI/ISO/IEC 9075 - Structured Query Language (SQL) - Data Management

3. Security Technologies a. Policy and Framework Related Technologies

• ISO/IEC 10164-8:1993 Security Audit Trail Function - Information technology - Open Systems Interconnection - Systems Management - Security

• ISO/IEC 18014-1:2002 Time-Stamping Services - Information technology - Security Techniques - Part 1: Framework - Data Management

• ISO/IEC 10181-7:1996 Security Audit and Alarms Framework - Information technology - Open Systems Interconnection -- Security Frameworks for Open Systems - Security

• FIPS PUB 112 Password Usage - Security • FIPS PUB 113 Computer Data Authentication - Security • RFC 2196 Site Security Handbook - Security • RFC 2401 Security Architecture for the Internet Protocol - Security • RFC 2527 Internet X.509 Public Key Infrastructure Certificate Policy and

Certification Practices Framework - Security b. General Security Technologies

• FIPS 197 for Advanced Encryption Standard (AES) - Security • FIPS 186 Digital Signatures Standard (DSS) - Security • Intrusion Detection Technologies - Network Management • Intrusion Prevention Systems (IPS) - Network Management

c. Media and Network Layer Technologies • Secure IP Architecture (IPSec) - Security • IEEE 802.11i Security for Wireless Networks - Security • Remote Authentication Dial In User Service (RADIUS) - Security • ATM Security - Security • AGA-12 Cryptographic Protection of SCADA Communications General

Recommendations - Security

Page 149: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Developing Functional Requirements for Substation Automation Equipment, Systems, and Applications

4-47

d. Application Layer Security Technologies • RFC 2228 FTP Security Extensions - Security • Internet Mail Extensions - Security • RFC 2086 IMAP4 ACL extension - Security • SNMP Security - Security, Network Management • RFC 1305 Network Time Protocol (Version 3) Specification, Implementation -

Security • IEC 62351-4 Security for Profiles including MMS (ISO-9506) - Security • IEC 62351-5 Security for IEC 60870-5 and Derivatives - Security • IEC 62351-6 Security for IEC 61850 GOOSE, GSSE, and SMV Profiles -

Security e. XML Related Technologies

• OASIS Security Assertion Markup Language (SAML) - Security 4. Network and Enterprise Management Technologies

a. Network Management Technologies • Simple Network Management Protocol (SNMP) - Network Management • IEC 62351-7 Objects for Network Management - Quality of Service, Network

Management, Data Management b. Web-Based Network Management

• Web-Based Enterprise Management (WBEM) - Network Management

Page 150: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 151: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

5-1

5 SPECIFYING FUNCTIONAL REQUIREMENTS AND IEC61850 FOR SUBSTATION AUTOMATION

5.1 Purpose and Audience for This Section

5.1.1 Purpose

Specifying the functional requirements for substation automation requires a different approach than substation engineers have typically used in the past to construct new substations. The functional requirements will need to encompass far more than just purchasing equipment. They must describe the requirements for all stakeholders to take advantage of the capabilities of substation automation based on the state-of-the-art technologies of IEC61850. These stakeholders include, operations, protection, planning, engineering, maintenance, data management, security, market operations, and corporate.

By definition, functional requirements should focus on what rather than how. The most effective way to develop the functional requirements is to use modeling techniques, which describe functions and illustrate their interactions through formal drawings. Using models allows functions to be drawn (and redrawn) on paper (or on computer screens) so that they can be reviewed by all stakeholders, refined as requirements are better understood, and finalized into formal functional specifications before the actual designs are created or any hardware or software is purchased.

Substation automation involves equipment as well as the communications infrastructure to monitor and manage the equipment, particularly when the full range of IEC61850 capabilities are to be utilized. Therefore, in addition to the design of physical and electrical requirements, substation automation also requires the analysis of information requirements and the determination of information flows between equipment and systems. These communication information requirements can also use modeling techniques to develop the best infrastructure.

5.1.2 Audience

The audience for this section is the project engineers who are tasked with incorporating the requirements of all stakeholders in the development of the functional requirements for substation automation.

Page 152: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-2

5.2 Model-Based Development of Functional Requirements

One of the most powerful technologies that has taken a leading role in the information industry is abstract modeling. Abstract modeling allows the designs of complex systems to be separated into their individual simple components in an organized manner, with methodologies to help capture all requirements (including contractual issues, human idiosyncrasies, performance, and the increasingly time-consuming maintenance issues). When all of these components are identified, the system can be created from them.

Key Technical Point

Abstract modeling allows the designs of complex systems to be separated into their individual simple components in an organized manner.

Multitudes of applications, scattered throughout distributed computers and tied together by meshes of networks, would be hopeless to design, operate, and manage without modeling.

5.2.1 Problems of Historical Concepts and Technologies

As can be seen from the discussions in the previous sections, the automation of substations provides many benefits to utility operations. However, not all information technologies provide the same benefits toward supporting substation automation.

Key Technical Point

Historically, the polyglot of different communication protocols has created a terrible management problem.

If different vendor proprietary protocols are used within a single substation and possibly between the substation and the control center, the exchange of information becomes difficult and limited. This polyglot of communication languages means that translators (gateways and protocol converters) must be scattered throughout the substation so that the different devices can understand each other—a complex and costly proposition.

Even if one communications protocol is selected, many difficulties still arise if that protocol is not object-oriented. For example, many substation automation projects try to use DNP 3 or Modbus as their single communications protocol. These protocols use plain hard-wired data descriptions. The voltage at a bus could be “analog point 39 on I/O card 5.” This cryptic identification is difficult to validate when first installed. However, after some data maintenance or modification to the substation, this same data point could become “analog point 198 on I/O card 3 in RTU ABC.” If this change in identity is multiplied by the frequency of data maintenance activities, substation modifications and expansions, and multiple utilities monitoring the same data point, it can be seen that ensuring the validity of data information can become a nightmare.

Page 153: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-3

Finally, different information is needed by different entities (humans, applications, and systems) for different purposes at different times. The traditional approach has been to require the SCADA system in the control center to acquire all data that might be needed by anyone—except for the data it cannot handle (such as oscillographic data) or for the times the SCADA system is too limited to handle the many new requirements for data (particularly from automated substations). In these cases, improvised solutions are applied, which only add to the chaos of the information infrastructure.

5.2.2 Benefits of Modeling Technologies

IEC61850 provides the most advanced standardized capabilities of all of the substation automation technologies. It’s superiority stems from its object-oriented approach to data design and management, the use of modeling not only for objects but also for services, and the fact that it is now an international standard that is, or will shortly be, supported by most major vendors.

Key Technical Point

IEC61850 is an international standard based on object-modeling technologies that are crucial to achieving true interoperability.

First, all key parts of IEC61850 are international standards. This means that all substation devices will support IEC61850 in the near future, even if they do not already do so. As both users and vendors demand the use of standards, proprietary protocols and data designs will become obsolete. Users are becoming more cognizant of the problems with proprietary protocols as they struggle to interface them once the vendors have left. At the same time, vendors are anxious to support and maintain as few different protocols as possible over many years.

Secondly, IEC61850 defines standard object models for all substation devices, thus giving every data point a unique and permanent name. The voltage on the bus would always have the same standard name, regardless of how it was physically connected or who was reading its information. This one fact alone improves the accuracy of initial installations and can simplify the on-going maintenance by orders of magnitude. These standardized object models provide the stability of source data that permits the rigorous management, yet flexible use, of these data by different users and systems.

Thirdly, because it is object-oriented, IEC61850 does not require that all data be collected by a SCADA system. Certainly some of the substation data are needed for SCADA operations, but other applications and systems could access this self-defining data directly (or indirectly through a secure gateway server) without overloading the SCADA system by collecting non-SCADA data. This capability off-loads the SCADA system and frees it to manage only the data that are necessary for real-time operations.

Page 154: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-4

5.3 Use of Abstract Modeling Tools to Develop Requirements

Information technology concepts have taken many leaps during the last few years (which is one of the major reasons that it took a long time to design these IEC61850 models). The following subsections present key conceptual requirements that drove the design of IEC61850 object models.

5.3.1 Abstract Modeling

Organizing information abstractly allows it to be understood more completely before it is turned into a physical (or cyber) form. These abstract models are capable of modeling data (like a circuit breaker status), services, or actions (such as “send status upon change”). Once information is modeled abstractly, it can be mapped (or instantiated) into a specific cyber item, format, or protocol. Thus an abstract model of a circuit breaker gives it a name and a structure, that then be mapped into any format, while the abstract models of services can be mapped to communications protocol, including MMS, DNP, XML, or even less sophisticated communication methods.

5.3.2 Information Exchange Interoperability

Interoperability in a substation is the ability of two or more IEDs from the same vendor, or different vendors, to exchange information and use that information for correct cooperation. Vital as it is, this level of interoperability does not guarantee that the business content (for example, the usefulness of the exchanged information) is understood by both entities.

5.3.3 Interworkability

At a higher level, applications interworkability is defined as the ability to have functions work together over a distributed system. Thus, in addition to having information exchange interoperability, the applications must understand the information that is exchanged and be able to complete their functions. Interoperability involves technologies above the communications system layers. It involves not just the hard coding of what data mean and where they are stored, but the ability of applications (using standardized names and procedures) to seek out the information they need. A very common example of this is the ability of Microsoft Windows operating systems to detect new hardware, query the hardware (actually firmware) to determine what it is, then automatically load the appropriate drivers. This concept could (eventually) be facilitated in substation automation through the use of the substation (or system) configuration Language (SCL), using the concepts promulgated by the ebXML methodologies. For example, if new equipment is installed in a substation (or a new substation is commissioned), the EMS network analysis functions could use SCL to determine what equipment has been installed and automatically add it to the power flow topology data.

Page 155: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-5

5.3.4 Interchangeability

Interchangeability is defined by the IEC as the ability to replace a device from the same or different vendors, utilizing the same communications interface, with the same functionality, and with no impact on the rest of the system. Interchangeability moves from the partially manual implementations of interworkability to completely automated implementations. Using the previous Microsoft Windows example, very often the hardware detection process requires manual intervention to find the driver, to install upgrade patches, and to otherwise tweak the operating system and the new hardware to truly work together. Eventually, the systems and interface standards should become so robust that they determine exactly what is needed, possibly find the drivers and patches automatically on the Internet, and install the systems automatically.

5.4 Unified Modeling Language (UML)

The Unified Modeling Language (UML) was developed to provide the abstract modeling needed to ensure top-down understanding of the entire system, as well as to provide mechanisms for translating those abstract models into actual computer code. A more complete description of the UML constructs can be found in Appendix B.

5.4.1 Abstract Modeling in UML

Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating. Modeling is the process of abstracting from a morass of information to develop a coherent, multifaceted vision. Because of this, the following points are important:

• Every complex system is best approached through a small set of nearly independent views of a model. No single view is sufficient.

• Every model may be expressed at different levels, ranging from highly abstract to concrete.

• The best models are connected to reality.

Key Technical Point

Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating. Modeling is a method of visualizing that abstraction.

The generally accepted methodology for software modeling is UML, which has been endorsed by the Object Management Group (OMG), the leading industry standard for distributed object programming. UML is the standard language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. It can be used with all processes, throughout the development life cycle, and across different implementation technologies. UML combines the best of the best from data modeling concepts (entity relationship diagrams), business modeling (work flow), object modeling, and component modeling.

Page 156: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-6

Vendors of computer-aided software engineering products are now supporting UML. Almost every maker of software development products, including IBM and Microsoft (for its Visual Basic environment) have endorsed by UML. The UML methodology is a standard notation for the modeling of real-world objects as a first step in developing an object-oriented design methodology. It is used as the language for specifying, visualizing, constructing, and documenting the artifacts of software systems, as well as for business modeling and other non-software systems. UML represents a collection of the best engineering practices that have proven successful in the modeling of large and complex systems.

Key Technical Point The key benefit of using unified modeling language (UML) is that it provides structured methods for visualizing complex interactions that must be implemented in an invisible cyber world.

The UML modeling methodology is very powerful in that it can be used from the highest overview levels to actual implementation code, and from the largest global project to a small enhancement project. The key benefit of using UML is that it provides methodologies for visualizing the complex interactions that must be implemented in an invisible cyber world. It consists primarily of structured diagrams that are designed to illustrate different aspects of cyber behavior. A number of case tools exist for developing these UML models as well-structured diagrams. The different UML modeling concepts and types of diagrams are described in the following section.

5.4.2 Use Cases

Use cases are modeling constructs which focus on the interactions between functions and actors from a user’s point of view. A use case is usually the first (and often the only) description of a function, because it draws a picture of the interrelationships of the key elements at the highest levels. The basic idea for a use case is to capture the requirements of these actors in relationship to the function. Actors are defined as the ultimate sources or users of information for a particular use case scenario—they are not necessarily human. For instance, the power system can be seen as an actor when it provides the source data for a SCADA system, while a billing system can be the user of metering data from an automatic meter reading system.

Key Technical Point

A use case is usually the first (and often the only) description of a function, because it draws a picture of the interrelationships of the key elements at the highest levels.

Use cases are layered or iterative in concept. For instance, in a use case diagram, a function is defined as a use case itself (which sometimes leads to confusion, but does emphasize the layered nature of use cases). As an example, in one use case diagram, the function Substation

Page 157: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-7

Automation Functions could be defined as a single entity within distribution operations, while this same function could be expanded into its own use case, showing the individual functions as separate entities.

Therefore, the scope of a particular use case is entirely a function of what needs to be defined. In a broad picture use case, distribution system operations can be one function within utility operations. In a detailed picture use case, the Substation Automation Volt/Var Optimization application can be the primary function. Therefore, often use cases are used first to define the overall Business Processes, and then are utilized to take each function within a Business Process and drill down to more detailed levels.

Modeling implies diagrams. Use case diagrams consist of Actors (often represented as little stick people) and use cases (ovals) linked by lines that indicate relationships, such as “is associated with”, “is an aggregation of”, or “is a generalization of.” An association, which is represented as a line with one or two arrows, provides a pathway for communication. The communication can be between use cases, actors, classes, or interfaces. Associations are the most general of all relationships and, consequentially, the most semantically weak. If two objects are usually considered independently, the relationship is an association. Other relationships include “generalization” and “dependency.”

An example of a use case for the function “Commissioning Substation Automation Using the Substation Configuration Language (SCL)” is shown in Figure 5-1.

Page 158: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-8

Figure 5-1 UML Use Case – Implementing Substation Automation

Page 159: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-9

The following list presents the benefits of use cases:

• Use cases provide a means of visualizing processes and interactions which otherwise might be obscure or lost in the complexity of a system.

• They capture requirements from a user’s perspective.

• Users are not only involved in providing requirements, but can actually understand and validate what is being designed.

• Use cases are a good way to start identifying information, which will be exchanged among the functions and actors.

• They provide one way of estimating the percentage of requirements captured.

• They assist with categorizing functions and determining which function impact the others, particularly if a phased delivery implementation is planned.

• They provide a better way of estimating the percentage of requirements completed during development.

• A test plan can be immediately generated based on use cases.

• They help technical writers to structure the overall work on the user’s manuals at an early stage.

• They enhance traceability throughout the system development process.

• The quality of the software is improved by identifying the exception scenarios earlier in the development process.

5.4.3 UML Methodology

The methodology for using UML can be summarized as follows:

1. Develop business processes using use cases.

a. Pick a business process (for example, day-ahead submittal of energy schedules by scheduling coordinators).

b. Determine all of the actors (for example, the scheduling coordinator and time line manager).

c. Determine the use case functions or systems involved (for example, market interface web server, format validation procedures, database of energy schedules, and congestion management function). Because business processes are usually at a higher and broader level than individual functions, these use cases are do not focus on a single function to show basically its inputs and outputs, but rather show the bigger picture.

Page 160: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-10

d. Describe all performance requirements, pre- and post-condition stipulations, and other assumptions (for example, responses to submittals will be within 5 seconds or at pre-specified times, scheduling coordinators are all registered, the schedule is accepted or rejected).

e. Draw and describe the interactions between the actors and use cases, including sequences of steps and decisions affecting information flows (for example, sequences for error checking or ability of scheduling coordinator to withdraw schedule). These can be documented in activity diagrams, sequence diagrams, collaboration diagrams, and state diagrams, along with text to clarify the interactions.

2. Develop data and/or messages contents, using class diagrams.

a. Identify the data or message type for each interaction in the business process—message type consists of a noun (the data) and a verb (how/when/under what conditions is the message sent).

• Use many nouns (for example, new energy schedule or update to an existing energy schedule).

• Use very few verbs (for example, send, request, acknowledge response, error response).

b. Organize and list all elements required by each data or message type

• Organize means identify specific parts of a message that are probably reusable for other messages (for example, message header, scheduling coordinator information, RTO information, e-tagging information (so that format can be used), time and date information, or other)

• Indicate if there is a one-to-one or a many-to-one correspondence between a part and the message (for example, only one scheduling coordinator, but one or more schedules)

• List all elements for each part (for example, scheduling coordinator corporate name, scheduling coordinator ID, or individual sending schedule)

3. Translate the classes into component models.

a. Convert the classes into document type definitions (DTD), using IDL or, as is becoming more common, using XML-DTD.

b. Translate these components into actual software code if so desired.

c. Register these DTDs so that all users of the information can access them. XML registries can be public (for example, ebXML uses OASIS XML registry) or can be private. This step is not actually part of UML, but is becoming a powerful means to publish, maintain, and update information exchange templates among large groups of users.

Page 161: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-11

5.5 IEC61850 Information Exchange Configurations

The IEC61850 concept of the information exchange configuration for substation automation consists, in its basic form, of the following parts:

• Substation logical devices: Provide data and respond to commands (act as servers in client-server terminology). These servers contain one or more logical nodes for the devices being accessed. They can be simple electronic controllers each linked to a single device, more capable IEDs (each managing a single device, but providing additional functionality), or local servers (which manage multiple devices and support many additional functions). Examples of the latter include substation automation masters and DER management systems.

• Ultra-high-speed network: Interconnects logical devices requiring the ultra high-speed exchange of information (on the order of 4 ms), in particular the protection relays. These high-speed networks can be physically separate, point-to-point media links, or logical channels within a network. For protection logical devices, the communication protocol used would be GSE or GOOSE to ensure that performance requirements are met.

• Substation network: Interconnects logical devices not requiring the ultra high speeds of protection relays. These networks are physically within a substation, thus requiring a design to avoid electromagnetic interference noise, but possibly needing less protection against information security threats due to their isolation and the physical boundary of the substation (although this is an on-going debate).

• Substation automation master: Acts as a gateway between the substation and the external users of the substation information. This substation master can also store logs and archives, collect maintenance information, perform statistical calculations, provide a local human-machine interface, coordinate activities between substation logical devices, and other functions.

• SCADA communications network: Provides external access to the substation logical devices (possibly directly, but more likely through the substation automation master). It may also include security measures in the form of firewalls, encryption devices, key management, or role-based access measures. In addition it may include network management capabilities.

• Data acquisition and control (DAC) subsystem: Acts as a client to the logical devices and/or substation automation master, and acts as a server to SCADA systems at control centers and to other users. Specifically, these DAC subsystems can provide mapping between IEC61850 objects and internal representations of this data (such as to a SCADA real-time database). These DAC subsystems can also provide the security and network management capabilities.

• Multiple users: Need to access the information in the logical device servers and, as authorized, issue data updates and control commands to the logical device servers. These users can be systems, applications, databases, and/or humans (including power system operators, protection engineers, maintenance personnel, database administrators, planners, or executives). Most users will access the logical device servers via the DAC subsystem, but some may be IEC61850 users with direct access to the logical devices. These IEC61850 users could be vendors, communication technicians, or systems of the future, which do not require data object mapping. Appropriate role-based access security measures would be required for all users.

Page 162: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-12

Figure 5-2 shows a basic communications services concept model.

Figure 5-2 Basic Communication Services Concept Model

5.6 Procedure for Specifying IEC61850

The general procedures for specifying substation automation are described in Section 1. This section addresses only the procedure for specifying IEC61850, which consists of the following steps:

• Step 1 – Determine functional requirements

• Step 2 – Determine IEC61850 logical nodes and the data available within the LN

• Step 3 – Develop IEC61850 data exchanges within the substation

• Step 4 – Develop IEC61850 data exchanges with external systems

Page 163: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-13

• Step 5 – Specify conformance testing

• Step 6 – Specify IEC61850 configuration tools

5.6.1 Step 1 – Determine Functional Requirements

Determining the functional requirements, which must be performed by utility substation engineers, is the most critical step. Following this step, the results may be passed to vendors or integrators to do the detail work (including the implementation of the IEC61850 technologies). These functional requirements should indeed be functional and not oriented toward a specific vendor’s product (even if the vendor’s product is a foregone conclusion). The detailed process for developing functional requirements is discussed in greater detail in Section 1. However, they are covered briefly here as the necessary first step before the IEC61850 requirements can be determined. The requirements include:

• Layout of the substation from an electrical point of view.

• Identification of the types of equipment – CTs, PTs, circuit breakers, capacitor banks, transformers, and tap changers.

• Identification of what data are available or necessary.

• Consideration of protection schemes – Identify what events will cause what actions by what equipment.

• Identify SCADA requirements – Identify what information will be needed in real time by the substation master and/or the control center SCADA system, and what control/setpoint/parameter capabilities will be needed.

• Determine information flow requirements – Identify what information is required from each substation device and what information should be sent to each substation device. This includes information exchanges within the substation and between the substation and the rest of the utility. Specifically, the information in the transmission operations tables in Section 4 should be reviewed to determine what data could be needed.

• Determine information security requirements – Identify the data assets and what level of security is required.

• Consider system and network management requirements – Identify what capabilities are needed for monitoring, alarming, controlling, automating, diagnosing, maintaining, repairing, and auditing the information infrastructure.

Page 164: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-14

5.6.2 Step 2 – Determine IEC61850 Logical Nodes and the Available Data

The utility substation engineers can perform this step by following this guideline. However, vendors or system integrators can also perform this step as long as the utility substation engineers verify that the results conform to the functional requirements. The logical node determination includes:

• Based on the functional requirements, determine which logical nodes are needed for which devices. Although vendors and/or integrators may choose to instantiate (turn into actual data) different logical nodes in different controllers or IEDs, the list of logical nodes should be the same for meeting the same functional requirements.

• Select which optional data items must be instantiated in the logical nodes, again based on the functional requirements.

5.6.3 Step 3 – Determine IEC61850 Data Exchanges Within the Substation

The data to be exchanged between devices in the substation must be defined, particularly between the protection devices and the circuit breakers, but also between other closed-loop automated functions within the substation, as well as monitoring, alarming, reporting, and logging of information to the substation master.

This step should most likely be performed jointly between the utility substation engineers and the vendors/implementers of the substation equipment. The functional requirements in Step 1 describe the types of data to be exchanged. This step defines explicitly what IEC61850 data items are sent, where, and under what conditions within the substation.

In IEC61850 terminology, these data exchange definitions are PICOMs (pieces of information for communication). Annex A of the IEC61850-5 document lists the most common PICOM source and sink logical nodes. In Annex B of IEC61850-5, these PICOMs are also categorized by the most common performance requirements. The PICOM descriptions are not normative, however, meaning that they are there for convenience and as examples. Therefore, it is important to ensure that the actual data exchanges are clearly defined as to the average and maximum transfer times, the average and maximum response times, the average and maximum size of messages, security, availability, backup and/or redundancy, and other performance criteria.

Page 165: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Specifying Functional Requirements and IEC61850 for Substation Automation

5-15

5.6.4 Step 4 – Determine IEC61850 Data Exchanges With External Systems

As discussed in previous sections, the use of modeling techniques can help tremendously in determining complex interactions among different systems. These techniques can be used in particular with the data exchanges involving IEC61850 objects. Specifically, the following issues and questions should be addressed:

• Monitored data

– Which users (humans, systems, or applications) need what data?

– What are the sources of these data? Can substitute data be provided if the primary source is unavailable?

– When are these data required (continuously, upon change, or upon user request)?

– How critical are the data? Must they be rigorously protected against unauthorized changes? Should all changes be logged for audit purposes?

– How secure should the data be? Available to anyone? Restricted to certain groups?

– What should occur if the data are not available or invalid (cause an alarm, be recorded in a log, be ignored, cause an application to execute, cause equipment to revert to local mode, cause a system to shut down, failover, or restart)?

– What should occur if the data indicate a power system problem?

• Controls and parameter settings

– Who should be allowed to issue controls or change settings of what devices?

– When should these controls or setting changes be permitted (at any time, only during maintenance, only if certain equipment is tagged, only if other data indicate that they are allowed such as in remote control mode)?

– How critical are these controls or setting changes? Must full individual authentication be used? Is role-based access through a common password adequate? Are passwords not necessary?

– What should occur if the control action fails (cause an alarm, be recorded in a log, be ignored, cause an application to execute, cause equipment to revert to local mode, cause a system to shut down, failover, or restart)?

5.6.5 Step 5 – Specify Conformance Testing

Requiring that a vendor pass an IEC61850 conformance test is vital to ensuring interoperability. The conformance test procedures were standardized in 2004 as IEC61860 Part 10.

5.6.6 Step 6 – Specify IEC61850 Configuration Tools

It is vital that the vendor provide tools for managing the object models, communication services, protocols, and information services such as network management and security.

Page 166: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 167: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

6-1

6 IMPLEMENTING IEC61850 IN EQUIPMENT AND SYSTEMS

6.1 Purpose and Audience for This Section

6.1.1 Purpose

The purpose of this section is to provide guidelines for implementing IEC61850 in equipment and systems that will be used in substation automation. The section first describes the concepts within IEC61850, which was developed explicitly for substation automation (although it also forms the basis for object model extensions). The section secondly addresses specific equipment, covering the existing models that are possibly relevant for that equipment and the need for additional models. Finally the section identifies the conformance tables that must be agreed upon for specific implementations.

6.1.2 Audience

The primary audience for this section is substation engineers, working closely with the vendors of substation automation equipment and systems. Although the vendors will have performed the detailed implementation of the IEC61850 object models and service models, the substation engineers must be able to decide what settings should be established for a particular substation. Therefore, they need to develop a deeper understanding of IEC61850, the potential benefits of features if they can be fully utilized, and the issues that must be resolved as they implement equipment and systems for the utility.

6.2 IEC TC57 Architecture and the Components of the IEC61850 Standard

IEC61850 has now become an excellent standard for communications with substation automation equipment that is accepted worldwide. Vendors are integrating it into their products and utilities are increasingly specifying it for their systems. It is a part of a larger architecture of international standards developed by the IEC TC57 working groups, which include the Common Information Model (CIM), IEC60870-5 from which DNP was derived, as well as security and network management enhancements for all of these protocols.

Figure 6-1 provides a diagram of the larger architecture of IEC TC57, with the IEC61850 standard shown in the middle of the diagram (appearing as a light green in color pictures).

Page 168: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-2

Note: Solid colors correlate different parts of the protocols within the architecture. Non-solid patterns represent areas that are future work, work in progress, or related work provided by another IEC TC.

Figure 6-1 Current Reference Architecture of IEC TC57

Figure 6-1 expands the IEC61850 portion of the IEC TC57 architecture to show the components of the IEC61850 and their relationship (through SCL) with CIM. In addition, security and network management standards (in progress) enhance all the other standards. These components are discussed in more detail in the following sections.

Page 169: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-3

Figure 6-2 Suite of Components Within IEC61850

6.2.1 Outline of the IEC61850 Document

The following is an outline of the IEC61850 document. The various parts are often referenced during discussions of the different areas.

1. System aspects

• Part 1 – Introduction and overview

• Part 2 – Glossary

• Part 3 – General requirements

• Part 4 – Systems and project management

• Part 5 – Communication requirements for functions and device models

2. Configuration

• Part 6 – Configuration language for electrical substation IEDs

3. Abstract communication services

• Part 7-1 – Principles and models: basic communication structure

• Part 7-2 – Abstract communication services (ACSI)

Page 170: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-4

4. Data models (Basic communication structure for substations and feeder equipment)

• Part 7-3 – Common data classes

• Part 7-4 – Compatible logical node classes and data classes

5. Mapping to real communication networks

• Part 8-1 – Mapping to MMS and to ISO/IEC 8802.3

• Part 9-1 – Serial unidirectional multi-drop point-to-point link

• Part 9-2 – Mapping on an IEEE 802.3-based process bus

6. Testing

• Part 10 – Conformance testing

6.2.2 Object Modeling

Object models are nouns with predefined names and data structures. Objects are the data that are exchanged among different devices and systems. There are typically hundreds to thousands of different objects, each with a unique name within its domain so that it can be uniquely identified.

Figure 6-3 illustrates object modeling (OM), showing the object hierarchy used for developing OM-SA object models. As can be seen from this diagram, one horizontal component is labeled OM for object model and one vertical component is labeled SA for substation automation. The cross between these two components represents the substation automation object models defined in IEC61850-7-3 and 7-4.

Key Technical Point

Object models are nouns with predefined names and data structures. They are the models of the data that will be exchanged. OM-SA defines the object models for substation automation.

Page 171: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-5

Figure 6-3 Object Model Hierarchy

6.2.2.1 Object Model Structure

The OM structure from the bottom up (as shown in Figure 6-3) is described here:

• Standard data types: Common digital formats such as Boolean, integer, and floating point.

• Common attributes: Predefined common attributes that can be reused by many different objects, such as the quality attribute. These common attributes are defined in IEC61850-7-3 clause 6.

• Common data classes (CDCs): Predefined groupings building on the standard data types and predefined common attributes, such as the single point status (SPS), the measured value (MV), and the controllable double point (DPC). In essence, these CDCs are used to define the type or format of data objects. These CDCs are defined in IEC61850-7-3 clause 7.

• Data objects (DO): Predefined names of objects associated with one or more logical nodes. Their type or format is defined by one of the CDCs. They are listed only within the logical nodes. An example of a DO is “Auto” defined as CDC type SPS. It can be found in a number of logical nodes. Another example of a DO is “RHz” defined as an SPC (controllable single point), which is found only in the RSYN logical node.

Page 172: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-6

• Logical nodes (LN): Predefined groupings of Data Objects that serve specific functions and can be used to build the complete device. Examples of LNs include MMXU, which provides all electrical measurements in three-phase systems (voltage, current, watts, vars, or power factor), PTUV for the model of the voltage portion of under voltage protection, and XCBR for the short circuit breaking capability of a circuit breaker. These LNs are described in IEC61850-7-4 clause 5.

• Logical devices (LD): The device model composed of the relevant logical nodes. For instance, a circuit breaker could be composed of the logical nodes XCBR, XSWI, CPOW, CSWI, and SMIG. Logical devices are not directly defined in any of the documents, because different products and different implementations can use different combinations of logical nodes for the same logical device. However, many examples are given in IEC61850-5.

IEC61850 logical device servers (a server is a hardware device such as a computer) contain logical device models within them (a model is defined as software and database constructs which act as if they were the physical device they are modeling). These logical device models consist of one or more physical device models, along with some general information about device identity and global capabilities.

Physical device models, in turn, are constructed of multiple functional modules called logical nodes (LNs). Logical nodes are standard groupings of data objects that have been organized to serve a specific function. Therefore, a logical device server can be diagrammed as shown in Figure 6-4.

Page 173: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-7

Figure 6-4 Example of the Relationship of Logical Device, Logical Nodes, Data Objects, and Common Data Classes

6.2.2.2 Object Model Naming

A critical aspect of IEC61850 is that every object has a unique name that is built from the object’s meaning, its type, its logical location, and its physical location. This uniqueness means that it is always clear exactly what an object is and where its value came from. It is similar to the concept of people having mailing addresses that indicate their name, their apartment number, their street address, their city, their state, and their country.

As illustrated in Figure 6-5, the IEC61850 object model names are built from some of the constructs described previously:

• Logical device (which also includes the name of the substation or other code for its physical location)

• Logical node

• Functional constraint (type of object)

• Common data class

Page 174: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-8

Figure 6-5 IED Object Naming

6.2.3 Communication Services Modeling

As was shown in Figure 6-2, the OM component rests at the top of the services model (SM) component.

Communication services are the verbs. They provide the actions, such as sending and receiving data, reporting data when some event occurs, logging data, and other actions. In SA, there are two types of communication services—abstract communication services, which must be mapped to a particular protocol (such as MMS or OPS), and PICOM, which is a unique set of services for protection relaying.

Key Technical Point Communication services are verbs. They provide the actions that actually perform the exchange of data.

Page 175: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-9

6.2.3.1 ACSI – Abstract Communication Services Interface

IEC61850-7-2 defines a set of abstract communication services that address the basic requirements for the process of exchanging information. The following list describes these services:

• Association services: A logical connection is made between two entities, such as a substation master with a new IED. In addition, multicast associations are also handled. This group of services handles establishing connections, deliberate breaking connections, aborting connections (usually due to some error condition), and managing unexpected broken connections.

• Datasets: Data values are grouped into sets for efficient transmittal. Datasets can be manually created or automatically created and deleted.

• Get: Requests information to be sent, including Get Logical Device Directory, Get Logical Node Directory, Get Data Values, Get Data Values Directory, and others. This service is used to monitor information.

• Set: Sends information to be used or stored, including Set Data Values. This service is used for control commands, setting parameters, and writing descriptions. The settings can be made into a group when necessary to avoid temporary inconsistencies. A setting group is a set of parameters used to control an IED’s behavior (for example, a relay setting group). Some IEDs can accommodate multiple setting groups, representing the same set of parameters, but with a different set of parameter values chosen. The setting groups are designed for use in different circumstances; only one version can be activated at a time. The settings group model enables these alternate setting groups to be maintained (that is, edited) and switched (that is, to activate the appropriate group at any given time). Specifically, as can be seen from Figure 6-6, exactly one group can be selected for active use by the process and exactly one group can be selected for editing.

Figure 6-6 Setting Group Model

Page 176: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-10

• Report control: Manages the reporting of datasets upon request, at a particular periodicity (for example, integrity scan), and upon the occurrence of pre-specified events, such as data change (for example, closed to tripped status), quality change (for example, a problem causes data to be invalid), data update (for example, an accumulator value is frozen periodically), or integrity scan mismatch (for example, the integrity scan indicates a different status value from the value that was last reported). Probably the most powerful capability is the buffered reporting, in which data are reported by exception with buffering provided to ensure that they can be sent again if a problem occurs. A buffered reporting model is shown in Figure 6-7.

Another mode is unbuffered reporting, as shown in Figure 6-8, which is used when buffering is not necessary (such as 2-second periodic reporting).

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-7 Buffered Reporting Model

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-8 Unbuffered Reporting Model

• Log control: Manages the logging and journaling of information, such as sequence of events. This service is particularly important for audit trails of events. It can be used for both power system events and information system events (such as logging the username of all entities that issue control commands, or invalid attempts to access the IED). This service is shown in Figure 6-9.

Page 177: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-11

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-9 Log Model

• Substitution values: Manages the substitution of values if that capability is indicated in the data object classes. This capability is not only for status and analog values, but also for data quality flags. Specifically, this service provides the ability of IEDs to determine whether to report a secondary value if local conditions indicate a problem with the primary value, thus alleviating the SCADA systems from managing this substitution in many instances. This service is illustrated in Figure 6-10.

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-10 Substitution Model

• Sampled values: Are used at the process level to retrieve synchronized samples, typically from digital CTs and PTs. This service is also used at the bay/unit level for Synchrocheck actions. Samples can also be multicast on a local network segment, so that many IEDs can receive the data. In addition, samples can be directed across network segments to other IEDs that are enrolled to receive them. These capabilities are shown in Figure 6-11.

Page 178: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-12

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-11 Sampled Values Model

• Generic object-oriented system-wide event (GOOSE): Provides fast and reliable distribution of data that can be sent to multiple subscribed peers. GOOSE also provides interrogation services for datasets. It is designed primarily for protective relay IEDs to exchange event data and, when called for, issuing trip operations to the appropriate equipment. This service is shown in Figure 6-12.

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-12 GOOSE Model

• Generic substation event (GSE) messages: Are similar to GOOSE messages, but are slightly more limited in capabilities. GSE sends a fixed set of status outputs, as well as fast, reliable, and multicast outputs. This service is shown in Figure 6-13.

Page 179: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-13

Courtesy of George Schimmel of Tamarack Consulting

Figure 6-13 GSE Model

• Select-before-operate control: Implements the safety mechanisms used by most switch-related control commands. This procedure basically consists of an originator of the control command first issuing a select of the control point, the receiver then performing a select and reporting the results back to the originator, and the originator then issuing an execute command (which the receiver performs only if it receives the execute command from the originator within a pre-specified time).

• Time management: Handles the synchronization of time across all interconnected nodes.

• File transfer: Handles the transfer of files between entities without treating them as data objects. This capability supports the uploading of new applications into the IEDs and other servers.

6.2.3.2 Implementation Settings and HMI

Vendors of the substation equipment controllers and IEDs must implement these services as appropriate. However, each of these services relies on the appropriate parameters being set correctly for the specific implementation. In particular, the datasets that are to be used by the different services must be identified and defined by a combined effort by vendors and substation engineers. Although basic datasets are predefined (each logical node has an associated dataset of all its data), these may not be appropriate for all users. Therefore, the substation engineer should help define the data groupings, based on substation requirements as well as other user and software application requirements.

Although initial datasets must be clearly defined, they can be changed at any time. Therefore, one of the requirements from the vendors must be an HMI tool that permits the easy definition and modification of these datasets. In addition, the HMI should support some diagnostic and maintenance functions. Although the actual HMI capabilities will need to fit the actual equipment functionality, the following are suggested as part of a basic set of capabilities:

• Access to association information

• The ability to initiate, abort, and cancel an association

Page 180: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-14

• Read access to all data objects including logs, showing the IEC61850 name, the value, the quality flag, the timestamp, and other attributes, in an appropriate order (for example, alphabetic)

• Write (set and control) access to all settable and controllable data objects

• The ability to interface (view status, change modes, start, stop, abort, suspend) with applications running in the IEDs and controllers as appropriate for the types of operations that they will perform

• The ability to initiate diagnostic functions, including monitoring the reporting of data, the setting of parameters, and the protocol validity

• The ability to provide different views (that is, different sets or types of data to be viewed by different users)

• The ability to set security parameters, such as passwords

6.2.4 Mapping to Protocol Profiles

The abstract objects and communication services described in the previous two sections must be mapped to real-world bits and bytes—in other words, to actual communication protocols (CPs).

IEC61850 currently has two protocol mappings specified—the GSE protocol for transmissions between very high-speed devices (such as protection relays) and MMS over the TCP/IP suite of protocols. However, the OM-SA object models can also be transmitted using some other mappings to protocol profiles, although some protocols can manage objects better than others. For instance, MMS and XML (over any lower layer network protocols) can utilize the object models completely. However, XML does not specify the communication services (such as when to send or triggered by what). So an underlying service capability must be added, most of which do not handle some of the more powerful services like datasets.

Key Technical Point Abstract objects and services must be mapped to real-world bits and bytes—in other words, into actual communication protocols.

Page 181: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-15

6.2.5 Substation Configuration Language Modeling

Abstract configuration languages provide a mechanism for describing how real-world components are actually connected to each other. Two such configuration languages have been defined to date in the utility industry:

1. Substation configuration language (SCL) for the configuration of equipment within substations

2. Common information model (CIM) for the overall configuration of the power system, from corporate ownership through the lines, substations, and feeders and to the customer sites.

Key Technical Point

Abstract configuration languages provide a mechanism for describing how real-world components are actually connected to each other. Two such configuration languages have been defined to date in the utility industry—SCL and CIM.

The concept of a configuration language is that the power system configuration of the substation can be modeled electronically using object models for use by engineers in planning, design, and maintenance. This power system model of the substation configuration allows engineering tools and other applications to learn how all of the devices within a substation are actually interconnected both electrically and from an information point of view.

The SCL configuration language for substation automation is described in IEC61850-6. It provides the standardized mechanisms to describe the following:

1. A system specification in terms of the single-line diagram, and the allocation of logical nodes (LN) to the parts and equipment of the single line to indicate the needed functionality.

2. Pre-configured IEDs with a fixed number of logical nodes (LNs), but with no binding to a specific process—may only be related to a very general process function part.

3. Pre-configured IEDs with a pre-configured semantic for a process part of a certain structure (for example, a double busbar GIS line feeder).

4. Complete process configuration with all IEDs bound to individual process functions and primary equipment, enhanced by the access control object definitions (access allowances) for all possible clients.

5. As defined in item 4, but additionally with all predefined associations and client server connections between logical nodes on data level. This is needed if an IED is not capable of dynamically building associations or reporting connections (either on the client or on the server side).

Page 182: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-16

Specifically, the SCL describes a model of the following areas:

• The primary (power) system structure: Includes the primary apparatus functions that are used and how the apparatus are connected. This results in a designation of all covered switchgear as substation automation functions, structured according to IEC 61346-1.

• The communication system: Includes how IEDs are connected to sub-networks and networks and what communication access points (communication ports) are used.

• The application level communication: Includes how data are grouped into datasets for sending, how IEDs trigger the sending, which service they choose, and the input data that are needed from other IEDs.

• Each IED: Includes the logical devices configured on the IED, the logical nodes with class and type belonging to each logical device, the reports and their data contents, the (pre-configured) associations available; and the data that should be logged.

• Instantiable logical node (LN) type definitions: The logical nodes as defined in IEC61850-7-x have mandatory, optional, and user-defined data (here abbreviated DO) as well as optional services and are, therefore, not instantiable. In this document, instantiable LNTypes and DOTypes are defined as templates, which contain the implemented DOs and services.

• The relationships: Includes the relationships between instantiated logical nodes and their hosting IEDs on one side and the switchyard (function) parts on the other side.

The SCL is also being harmonized with the common information model (CIM) standard. The work to do this is also still under development through the IEC. However, when it is completed, it may become very important in future, more sophisticated functions that would benefit from having substation configuration information available and updated electronically.

Even if this configuration language is not immediately used within a utility’s operations, it should be required from the appropriate substation automation vendor (probably the vendor of the substation master).

6.2.6 Power System Configuration Modeling

The common information model (CIM)is an abstract model that represents all the major power system objects in an electric utility enterprise, focusing on power system connectivity, but including some organizational and ownership aspects as well. The instantiation of a CIM power system model (conversion from an abstract model into a specific configuration of a specific utility’s power system) provides the information that is typically needed by power flow topology models used by multiple applications, such as the EMS and DMS Network Analysis applications. This model includes public classes and attributes for these objects, as well as the relationships between them.

Page 183: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-17

Key Technical Point

The common information model (CIM) is an abstract model that represents all the major power system objects in an electric utility enterprise, focusing on power system connectivity, but including some organizational and ownership aspects as well.

The CIM was initially developed under the sponsorship of EPRI as the Control Center API (CCAPI) research project (RP-3654-1) project. It is currently undergoing standardization through the IEC TC57 WG13, as the document IEC 61970. The following descriptions of the CCAPI concepts are derived from excerpts from the introduction to the IEC document and other submissions to the IEC.

The principle objectives of the EPRI CCAPI project were to:

• Reduce the cost and time needed to add new applications to an EMS

• Protect the investment in existing applications that are working effectively in an EMS

• Provide an integration framework for interfacing existing systems to an EMS

The principal task of the EMSAPI project (to develop and standardize IEC 61970) is to develop a set of guidelines and standards to facilitate the integration of applications developed by different suppliers in the control center environment (similar to a plug-in application). A plug-in application is defined as a piece of software that may be installed on a system with minimal effort and no modification of source code (that is, the way software packages are installed on a desktop computer). The EMSAPI project goal is to at least approach that ideal by reducing the significant efforts currently required to install third-party applications in an EMS.

The scope of these specifications includes other transmission systems as well as distribution and generation systems external to the control center that need to exchange real-time operational data with the control center. Therefore, another related goal of these standards is to enable the integration of existing legacy systems as well as new systems built to conform to these standards in these domains of application.

The complete set of standard documents includes the following parts:

• Part 1– Guidelines and General Requirements

• Part 2 – Glossary

• Part 3 – Common Information Model (CIM)

• Part 4 – Component Interface Specification (CIS), Level 1

• Part 5 – CIS, Level 2 (the CIM defined as XML, using RDF)

The goal of the CCAPI standards is to encourage the independent development of reusable software components and to facilitate their integration in the construction of control center systems through the development of component interface standards. The software industry

Page 184: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-18

(including the major EMS vendors and suppliers of application software for an EMS) has undergone an evolution from basing software engineering concepts on top-down modular software design, to object-oriented approaches, and to the latest refinement using component-based architectures. The component models embraced by the Common Object Request Broker Architecture (CORBA), Enterprise Java Beans (EJB), and Distributed Common Object Modeling (DCOM) best exemplify this trend.

One of the primary on-going efforts is the development of Application Program Interfaces (APIs) for interfacing between the CIM and applications. These component-based approaches facilitate the integration of software from various sources. The goal is not to develop standard interfaces for middleware. In fact, the goal is just the opposite—to be independent of any particular set of middleware services. This allows integrators to select the right type and scale of infrastructure for each system. It allows service designs to evolve and innovate, and it simplifies component development as well. The selected protocol is the Generic Interface Definition (GID).

The following two examples illustrate this independence of components:

• CORBA components specifically do not require the use of CORBA Notification (or any particular service) as the event system.

• COM+ components are written exactly the same way whether they are deployed in an environment with or without Distributed Transaction Coordinator (DTC) and/or a Microsoft Message Queue (MSMQ).

The CIM model is defined using UML tools. It has been exported into XML for use in implementations.

6.3 Implementing IEC61850 Object Models

IEC61850-7-4 clause 5 lists logical nodes in alphabetic order within type of LN. For those experts who have been involved in the development of the standard and who are extremely familiar with LN names, this organization makes sense because they can quickly find the details about the LN they need. But this organization does not help those people who are not as familiar with LNs. IEC61850-5 clauses 12-2 and 12-3 provide a few examples, but no definitive descriptions of how to model a circuit breaker or a load tap changer for different requirements. This guideline is intended to help the users of substation automation understand implementation options, even if it is ultimately the IEC experts who implement the LNs into their products.

The following sections discuss the optional implementations of the different logical nodes for various substation equipment. Generally, no single option is better than another—each option is designed for capabilities and requirements. Different vendors may also choose to implement functions using somewhat a different arrangement of LNs depending upon their products. The issues described in his section, along with the tables of functions described in Section 4-2, can assist substation engineers and planners in determining the range and functionality of the required substation equipment.

Page 185: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-19

6.3.1 Electric Power Measurements

Electric power measurements can be captured by many controllers and in many locations in substations, often in conjunction with equipment for which these measurements are not particularly relevant. For instance, the primary purpose of a circuit breaker controller is to respond to the trip command from protective relaying devices or the supervisory control command from a control center. It may need frequency measurements to perform point-on-wave switching. However, it often also captures electric power measurements just because it is convenient to include this capability in the controller. Therefore, electric power measurement logical nodes are often included in many different logical devices. The electric power measurement requirements for the location that is connected to the controller should determine the appropriate LNs to include in a logical device.

Table 6-1 describes the different electric power measurement logical nodes. The first rows describe the basic contents of each LN, while the last row shows a typical implementation of logical nodes for one device, such as a switch. The numbers indicate how many logical nodes might be implemented. For instance, if the device is a switch, then two of the MMXU three-phase measurements might be implemented, one for each side of the switch.

Page 186: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-20

Table 6-1 Electric Power Measurement Logical Nodes

Electric Power Measurements

TV

TR

TC

TR

MM

XU

MM

XN

MD

IF

MH

AI

MH

AN

MS

QI

Voltage transformer – measurement of voltage at the PT X

Current transformer – measurement of current at the CT

X

Three-phase electrical measurements – three-phase watts, vars, volt-amps, voltage, amps, power factor, impedances, and frequency, by phase-to-phase and phase-to-ground (as appropriate)

X X X

Single-phase electrical measurements – single-phase watts, vars, volt-amps, voltage, amps, power factor, impedances, and frequency, by phase-to-phase and phase-to-ground (as appropriate)

X X X

Amps measured on other side – amps measured on the other side of an open switch or breaker

X X X

Three-phase harmonics measurements – three-phase harmonics

X X X

Single-phase harmonics measurements – single phase harmonics X X X

Sequence and imbalance measurements – sequence and imbalance measurements across phases

X X X

All three-phase measurements – all three-phase measurements at one location, on both sides of a device

6 6 2 1 1 2

6.3.2 Switches, Circuit Breakers, and Reclosers

Different types of switches are built from the different logical nodes, based on the requirements and capabilities of the equipment. The logical nodes used in some of the more common switch and circuit breaker-related capabilities are shown in Table 6-2.

Page 187: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-21

Table 6-2 Switch, Circuit Breaker, and Recloser Logical Nodes

Switches, Circuit Breakers, and Reclosers

XS

WI

XC

BR

CS

WI

RR

EC

RB

RF

RS

YN

CIL

O

SIM

G

SA

RC

SP

DC

CP

OW

TC

TR

TVTR

Switch – Switches with no short circuit-breaking capability such as disconnects or grounding switches.

X

Switch with supervisory control – Switches that can be operated through supervisory control.

X X

Circuit breaker with no supervisory control – The circuit breaker can be tripped and reset only by protection devices.

X

Circuit breaker with supervisory control – The circuit breaker can be tripped by protection devices and can also be opened and closed by supervisory control commands.

X X

Circuit breaker with SF6 gas – Insulating gas is monitored.

X X X

Circuit breaker with alarm monitoring – Arcs, partial discharges, and breaker failures are monitored.

X X X X X

Circuit breaker with lockout – Lockout prevents or enables switching operation.

X X X

Circuit breaker with point-on-wave tripping capability – The circuit breaker operates only at a specific point on the waveform.

X X X X X

Circuit breaker with synchronization checking – Circuit breaker operation is enabled only if voltage phasor difference across the open switch is within specified limits.

X X X

Recloser – Circuit breaker with multicycle auto recloser capability.

X X X

Circuit breaker with all capabilities –Circuit breakers can include all capabilities.

X X X X X X X X X X X X

Page 188: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-22

In addition to these circuit breaker LNs, the IED controller for a circuit breaker could also include other LNs, because the current transducer (CT) and power transducer (PT) sensors are usually located at the breaker site. Therefore, the following additional LNs could be included in the circuit breaker IED:

• MMXU or MMXN: three-phase or single-phase electric measurements

• MDIF: Amps on the other side of the breaker

• MHAI or MHAN: Harmonics in a three-phase or single-phase system

• MSQI: Sequence and imbalance measurements

• CALH: Grouping of alarms

• RFLO: Fault locator

6.3.3 Transformers and Tap Changers

Transformers and their tap changing controllers are modeled by multiple logical nodes, which can be combined to form different capabilities to meet the various different requirements.

The logical nodes used in some of the more common transformer and load tap changer-related capabilities are shown in Table 6-3.

Page 189: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-23

Table 6-3 Transformer and Tap Changer Logical Nodes

Transformers and Tap Changers

YP

TR

YL

TC

YP

SH

YE

FN

AT

CC

AV

CO

AR

CO

AN

CR

Power transformer – The characteristics of the transformer X

Load tap changer – Status and measurements of the load tap changer

X

Power shunt – Controller for controlling the power shunt X

Earth fault neutralizer – Controller for the earth fault neutralizer coil X

Automatic tap changer controller – Controller for the automatic control of tap changers

X

Voltage controller – Control characteristics based on voltage X

Reactive power controller – Control characteristics based on reactive power

X

Neutral current regulator – Regulator for the neutral current X

Automatic load tap changer controller – LTC controller combining many characteristics

X X X X X X

In addition to these tap changer LNs, the IED controller for tap changer could also include other LNs, because the current transducer (CT) and power transducer (PT) sensors are usually located at the breaker site. So, additional LNs that could be included in the tap changer IED are:

• MMXU or MMXN: three-phase or single-phase electric measurements

• MDIF: Amps on the other side of the breaker

• MHAI or MHAN: Harmonics in a three-phase or single phase system

• MSQI: Sequence and imbalance measurements

• CALH: Grouping of alarms

6.3.4 Capacitor Bank Switch Logical Nodes

Capacitor bank switch controllers are modeled by a few logical nodes used together. The switches can be manually operated or controlled through supervisory control actions.

The logical nodes used for the capacitor bank switch are shown in Table 6-4.

Page 190: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-24

Table 6-4 Capacitor Switch Logical Nodes

Capacitor Switch

XC

AP

XS

WI

CS

WI

Capacitor bank – The characteristics of the capacitor bank X

Capacitor switch – Status and control over the capacitor switch

X

Switch controller – Switch with supervisory control capability X

Capacitor bank control – Capacitor bank with supervisory control capability

X X X

In addition to these capacitor switch LNs, the IED controller for a capacitor switch could also include other LNs, because the current transducer (CT) and power transducer (PT) sensors are usually located at the breaker site. Therefore, the following additional LNs could be included in the capacitor switch IED:

• MMXU or MMXN: three-phase or single-phase electric measurements

• MDIF: Amps on the other side of the breaker

• MHAI or MHAN: Harmonics in a three-phase or single-phase system

• MSQI: Sequence and imbalance measurements

• CALH: Grouping of alarms

• RFLO: Fault locator

6.3.5 Protection Logical Nodes

Protection functions are probably the most complex and extensive of the logical nodes in IEC61850. Table 6-5 shows the logical nodes associated with specific protection functions. Tables 6-6 through 6-11 show typical combinations of these protection functions for common purposes.

In addition to the specific protection logical nodes, relays can also include other logical nodes, such as those in the following list:

• CALH: Grouping of alarms

• RFLO: Fault locator

• RDRE, RDRS, RBDR, RADR: Disturbance recording

• RSYN: Synchronization checking

Page 191: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Im

plem

enti

ng I

EC

6185

0 in

Equ

ipm

ent a

nd S

yste

ms

6-25

Tab

le 6

-5

Pro

tect

ion

Fu

nct

ion

s L

og

ical

No

des

Pro

tect

ion

Fu

nct

ion

s

(IE

EE

C37

.2 R

ef)

PTEF

PZSU

PDIS

PSCH

PVPH

PTUV

PDOP

PDUP

PTUC

PTOC

PTOV

PTTR

PIOC

PVOC

POPF

PUPF

PHIZ

PPAM

PTOF

PTUF

PFRC

PDIF

PDIR

PHAR

PMRI

PMSS

RDIR

RPSB

PZSU

Tra

nsie

nt e

arth

faul

t X

Zer

o sp

eed

and

unde

r sp

eed

(14)

X

Dis

tanc

e (2

1)

X

X

X

Vol

t per

Hz

(24)

X

Und

ervo

ltage

(27

)

X

X

X

Und

ercu

rren

t/und

er

pow

er (

37)

X

X

Loss

of f

ield

/und

er

exci

tatio

n (4

0)

X

Rev

erse

pha

se o

r ph

ase

bala

nce

curr

ent

(46)

X

Pha

se s

eque

nce

volta

ge (

47)

X

The

rmal

ove

rload

(49

)

X

Rot

or th

erm

al o

verlo

ad

(49R

)

X

Sta

tor

ther

mal

ov

erlo

ad (

49S

)

X

Inst

anta

neou

s ov

ercu

rren

t or

rate

of

rise

(50)

X

Page 192: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Impl

emen

ting

IE

C61

850

in E

quip

men

t and

Sys

tem

s

6-26

Tab

le 6

-5 (

Co

nt.

) P

rote

ctio

n F

un

ctio

ns

Lo

gic

al N

od

es

Pro

tect

ion

Fu

nct

ion

s

(IE

EE

C37

.2 R

ef)

PTEF

PZSU

PDIS

PSCH

PVPH

PTUV

PDOP

PDUP

PTUC

PTOC

PTOV

PTTR

PIOC

PVOC

POPF

PUPF

PHIZ

PPAM

PTOF

PTUF

PFRC

PDIF

PDIR

PHAR

PMRI

PMSS

RDIR

RPSB

PZSU

AC

tim

e ov

ercu

rren

t (5

1)

X

Vol

tage

co

ntro

lled/

depe

nden

t tim

e ov

ercu

rren

t (51

V)

X

Pow

er fa

ctor

(55

)

X

X

Tim

e ov

ervo

ltage

(59

)

X

DC

ove

rvol

tage

(5

9DC

)

X

Vol

tage

or

curr

ent

bala

nce

(60)

X

X

Ear

th fa

ult/g

roun

d de

tect

ion

(64)

X

Rot

or e

arth

faul

t (64

R)

X

Sta

tor

eart

h fa

ult (

64S

)

X

Inte

rtum

faul

t (64

W)

X

AC

dire

ctio

nal

over

curr

ent (

67)

X

X

Dire

ctio

nal e

arth

faul

t (6

7N)

X

X

DC

tim

e ov

ercu

rren

t (7

6)

X

X

Pha

se a

ngle

or

out-

of-

step

(78

)

X

Page 193: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Im

plem

enti

ng I

EC

6185

0 in

Equ

ipm

ent a

nd S

yste

ms

6-27

Tab

le 6

-5 (

Co

nt.

) P

rote

ctio

n F

un

ctio

ns

Lo

gic

al N

od

es

Pro

tect

ion

Fu

nct

ion

s

(IE

EE

C37

.2 R

ef)

PTEF

PZSU

PDIS

PSCH

PVPH

PTUV

PDOP

PDUP

PTUC

PTOC

PTOV

PTTR

PIOC

PVOC

POPF

PUPF

PHIZ

PPAM

PTOF

PTUF

PFRC

PDIF

PDIR

PHAR

PMRI

PMSS

RDIR

RPSB

PZSU

Fre

quen

cy (

81)

X

X

X

Diff

eren

tial (

87)

X

Pha

se c

ompa

rison

(8

7P)

X

Diff

eren

tial l

ine

(87L

)

X

Res

tric

ted

eart

h fa

ult

(87N

)

X

Diff

eren

tial t

rans

form

er

(87T

)

X

X

Bus

bar

(87B

)

X

X

Mot

or d

iffer

entia

l (87

M)

X

Gen

erat

or d

iffer

entia

l (8

7G)

X

Mot

or s

tart

up (

49R

, 66

,48,

51L

R)

X

X

Pow

er s

win

g de

tect

ion/

bloc

king

X

Zer

o sp

eed

or u

nder

sp

eed

X

Page 194: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-28

6.3.5.1 Typical Protection Logical Nodes for a Transformer Relay

Table 6-6 shows a typical set of logical nodes used in transformer relays. There can be multiple instances of the same logical node used for different purposes.

Table 6-6 Typical Protection Logical Nodes for a Transformer Relay

IEEE Function Logical Node Logical Node

24 Volts per hertz PVPH

27 Phase undervoltage PTUV

27X Auxiliary undervoltage PTUV

50/87 Instantaneous differential overcurrent PIOC PDIF

50G Ground instantaneous overcurrent PIOC

50N Neutral instantaneous overcurrent PIOC

50P Phase instantaneous overcurrent PIOC

51G Ground time overcurrent PTOC

51N Neutral time overcurrent PTOC

51P Phase time overcurrent PTOC

59N Neutral overvoltage PTOV

59P Phase overvoltage PTOV

59X Auxiliary overvoltage PTOV

67N Neutral directional overcurrent PTOC

67P Phase directional overcurrent PTOC

81O Overfrequency PTOF PFRC

81U Underfrequency PTUF PFRC

87G Restricted ground fault PDIF

87T Transformer differential PDIF

Page 195: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-29

6.3.5.2 Typical Protection Logical Nodes for a Line Distance Relay

Table 6-7 shows a typical set of logical nodes used in line distance relays.

Table 6-7 Typical Protection Logical Nodes for a Line Distance Relay

IEEE Function Logical Node Logical Node

21G Ground distance PDIS PSCH

21P Phase distance PDIS PSCH

25 Synchrocheck RSYN

27P Phase undervoltage PTUV

27X Auxiliary undervoltage PTUV

50BF Breaker failure PIOC

50DD Current disturbance detector PIOC

50G Ground instantaneous overcurrent PIOC

50N Neutral instantaneous overcurrent PIOC

50P Phase instantaneous overcurrent PIOC

50_2 Negative sequence instantaneous overcurrent PIOC

51G Ground time overcurrent PTOC

51N Neutral time overcurrent PTOC

51P Phase time overcurrent PTOC

51_2 Negative sequence time overcurrent PTOC

52 Ac circuit breaker XCBR

59N Neutral overvoltage PTOV

59P Phase overvoltage PTOV

59X Auxiliary overvoltage PTOV

59_2 Negative sequence overvoltage PTOV

67N Neutral directional overcurrent PTOC

67P Phase directional overcurrent PTOC

67_2 Negative sequence directional overcurrent PTOC

68 Power swing blocking RPSB

78 Out-of-step tripping PPAM

79 Automatic recloser RREC

Page 196: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-30

6.3.5.3 Typical Protection for a Feeder Relay

Table 6-8 shows a typical set of logical nodes used in feeder relays.

Table 6-8 Typical Protection Logical Nodes for a Feeder Relay

IEEE Function Logical Node Logical Node

25 Synchrocheck RSYN

27P Phase undervoltage PTUV

27X Auxiliary undervoltage PTUV

32 Sensitive directional power PDOP PDUP

50BF Breaker failure PIOC

50DD Current disturbance detector PIOC

50G Ground instantaneous overcurrent PIOC

50N Neutral instantaneous overcurrent PIOC

50P Phase instantaneous overcurrent PIOC

50_2 Negative sequence instantaneous overcurrent PIOC

51G Ground time overcurrent PTOC

51N Neutral time overcurrent PTOC

51P Phase time overcurrent PTOC

51_2 Negative sequence time overcurrent PTOC

52 Ac circuit breaker XCBR

59N Neutral overvoltage PTOV

59P Phase overvoltage PTOV

59X Auxiliary overvoltage PTOV

59_2 Negative sequence overvoltage PTOV

67N Neutral directional overcurrent PTOC

67P Phase directional overcurrent PTOC

67_2 Negative sequence directional overcurrent PTOC

79 Automatic recloser RREC

81O Over frequency PTOF

81U Under frequency PTUF

Page 197: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-31

6.3.5.4 Typical Protection for a Generator Relay

Table 6-9 shows a typical set of logical nodes used in generator relays.

Table 6-9 Typical Protection Logical Nodes for a Generator Relay

IEEE Function Logical Node Logical Node

21P Phase distance PDIS PSCH

24 Volts per hertz PVPH

25 Synchrocheck RSYN

27P Phase undervoltage PTUV

27TN Third harmonic neutral undervoltage PTUV

27X Auxiliary undervoltage PTUV

32 Sensitive directional power PDOP PDUP

40 Loss of excitation PDUP

46 Generator unbalance PTOC

50G Ground instantaneous overcurrent PIOC

50N Neutral instantaneous overcurrent PIOC

50P Phase instantaneous overcurrent PIOC

50/27 Accidental energization PIOC PTUV

51G Ground time overcurrent PTOC

51P Phase time overcurrent PTOC

59N Neutral overvoltage PTOV

59P Phase overvoltage PTOV

59X Auxiliary overvoltage PTOV

59_2 Negative sequence overvoltage PTOV

64TN 100% stator ground PTOC

67N Neutral directional overcurrent PTOC

67P Phase directional overcurrent PTOC

68 Power swing blocking RPSB

78 Out-of-Step Tripping PPAM

81O Over frequency PTOF

81U Under frequency PTUF

87S Stator differential PDIF

Page 198: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-32

6.3.5.5 Typical Protection for a Bus Differential Relay

Table 6-10 shows a typical set of logical nodes used in bus differential relays.

Table 6-10 Typical Protection Logical Nodes for a Bus Differential Relay

IEEE Function Logical Node Logical Node

27 Undervoltage PTUV

50 Instantaneous overcurrent PIOC

50/74 CT trouble PIOC CALH

50/87 Unrestrained bus differential PIOC PDIF

50BF Breaker failure PIOC

51 Time overcurrent PTOC

6.3.5.6 Typical Protection for a Motor Relay

Table 6-11 shows a typical set of logical nodes used in motor relays.

Table 6-11 Typical Protection Logical Nodes for a Motor Relay

IEEE Function Logical Node Logical Node

27P Phase undervoltage PTUV

27X Auxiliary undervoltage PTUV

32 Sensitive directional power PDOP PDUP

46 Generator unbalance PTOC

47 Phase sequence voltage PTOV

49 Thermal overload PTTR

50G Ground instantaneous overcurrent

PIOC

50P Phase instantaneous overcurrent PIOC

51G Ground time overcurrent PTOC

59N Neutral overvoltage PTOV

59P Phase overvoltage PTOV

59X Auxiliary overvoltage PTOV

59_2 Negative sequence overvoltage PTOV

87S Stator differential PDIF

Page 199: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-33

6.3.6 Disturbance Recording Logical Nodes

Disturbance recording logical nodes handle the collection and storage of analog and status changes during disturbances. These logical nodes may be part of other devices, because they capture information from the same CT and PT sensors that are used by the other functions.

These are shown in Table 6-12. The code M stands for multiple instances in different devices.

Table 6-12 Disturbance Recording Logical Nodes

Disturbance Recording

RD

RE

RA

DR

RB

DR

RD

RS

Disturbance Recorder Source Management – Manages the triggers, timing of triggers, memory for recording, and other aspects of disturbance handling at the source

X

Disturbance recorder analog data – Handles the input of analog data in COMTRADE format

X

Disturbance recorder binary data – Handles the input of binary data in COMTRADE format

X

Disturbance record candling – Handles the storage of records at another location such as the substation master

X

Disturbance recording system – A complete system that includes all of the previously listed capabilities

M M M 1

Page 200: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-34

6.3.7 Metering Logical Nodes

Metering logical nodes, which handle the reading of meters, are shown in Table 6-13.

Table 6-13 Metering Logical Nodes

Metering

MM

TR

M?

??

MS

TA

Three-phase metering – Calculation of energy in a three-phase system

X

Single-phase metering – Calculation of energy in a single-phase system (Note: This LN has not yet been defined, but will be defined in the near future.)

X

Metering statistics – Statistical information derived from metered values

X

6.3.8 Archiving, HMI, and Alarming Logical Nodes

Archiving, HMI, and alarming logical nodes handle user interface issues. These LNs are shown in Table 6-14.

Table 6-14 Archiving, HMI, and Alarming Logical Nodes

Archiving, HMI, and Alarming

IAR

C

IHM

I

CA

LH

Archiving – Management of archival records. X

Human machine interface – Management of the HMI.

X

Alarm handling – Individual alarms can be grouped to create group warnings and alarms.

X

6.3.9 Power Quality

There are currently no power quality object models in IEC61850, but there is on-going work to modify the GOMSFE objects into 61850 objects.

Page 201: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-35

6.4 Implementing Communications Service Models in Servers and Clients

As described previously, the SM communications service model defines communication services (for example, get data, send command, and report by exception) using abstract terminology. These services (or action verbs) were developed to cover the requirements for communication activities of an extremely wide range of devices, including those used for substation automation. However, these abstract services must be converted to real-world services before they can be actually implemented. This section describes the process and provides guidelines regarding which abstract services must supported for substation automation.

IEC61850 Part 7-2 defines a set of communications services—Abstract Communications Service Interface (ACSI)—that may be implemented within a device to allow access and management of the object models through the network. When these abstract services are to be converted to implementable services, the IEC61850 standard directs vendors to report the implementation choices using a Protocol Implementation Conformance Statement (PICS).

The PICS comprises a set of tables included in the standard that identify features within the protocol that may or may not be implemented. Some of the conformance features may be required of all systems and some may be conditionally required (that is, the inclusion of one feature requires the implementation of others, and still others may be strictly optional). The PICS mechanism is the most straightforward format for specifying the detailed communications requirements of IEC61850 systems. Each table contains two columns specifying conformance: one for client/subscribers and the other for server/publisher.

Within a SA facility, there will be a variety of IEC61850 devices, each with somewhat different requirements. In addition, the various clients systems will likely have to communicate with a range of servers, and so must support a superset of features. It may, therefore, be necessary to develop several sets of PICS tables, each specifying slightly different collection of requirements.

The tables included in this section can be viewed as templates for specifying requirements. Simply extract the tables, change the items marked optional (O) to mandatory (M) if those features are required by the applications, and include the tables in the project documentation. The value/comment column of each table has been annotated to help give some guidance. In many cases the comments include “depends on application.” These items are clarified in the discussion that follows each table.

The following section explains the specific items within the IEC61850 abstract service PICS (from Part 7-2) along with some discussion regarding the circumstances that may cause the feature to become a requirement.

6.4.1 Basic Conformance Statement

The first step in defining the communications requirements (services and protocol mappings) for IEC61850 products is the selection of the type of communications capabilities required. These decisions should be driven by the functional requirements specified by the utility engineers, as well as by product-based decisions made by the vendors.

Page 202: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-36

The following table is used to declare the highest level of conformance for the system component under consideration. The following this describes the basic items that can be selected here:

• Two-party client/server: Two-party application associations are client/server associations that allow for high-level operations like self-description, read/write, reporting, and logging. within these associations, a client system connects with a server system and makes service requests. The client may enable control blocks (if supported by a server) to instruct the server to perform reporting and logging. The client may also write settings and controls, and directly read values. This type of association is required for typical browser operation, and is commonly used for SCADA and many distributed applications. Within the IEC61850 framework, applications using these services are said to be operating on the station bus. (This terminology stems from the substation orientation of IEC61850, although this client/server capability is equally applicable to non-substation applications).

• SCSM mapping: The Specific Communication Service Mapping (SCSM) defines the underlying protocol used to implement the abstract services that are declared for the device (that is, the communication protocol mappings—CP). At the present time, there are only three standardized SCSMs for IEC61850 (see the following list):

– 8-1: MMS over TCP/IP over Ethernet. This protocol mapping is used for most client/server interactions.

– 9-1: Point-to-point Ethernet (in which the Ethernet network is structured so that only two devices appear to be on any one channel) used strictly for transmission of sampled values (for example, process bus communication with CTs or VTs). This configuration ensures transmit times for ultra-high-speed communications.

– 9-2: Multicast Ethernet used strictly for transmission of sampled values (for example, process bus communication with CTs or VTs). This configuration permits one device to send information to multiple other devices simultaneously.

• GOOSE/GSE subscriber/publisher: The GOOSE and GSE services are used for fast multicast communication between a publisher and one or more subscribers. The abstract services are used for operations such as protection event notification. The most important abstract services (SendGOOSEMessage) in this group map onto short, connectionless stacks, although some of the administrative services (such as querying about dataset definitions) use full two-party associations.

• SVC subscriber/publisher: Sampled value control services are used to manage streams of high-speed, sampled data from devices such as CTs and VTs. Within the IEC61850 standards, these applications are known as process bus applications. The transmission of samples may use multicast or unicast mechanisms.

Page 203: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-37

In a typical SA setting, there are basically three questions at this level that must be decided:

• Is full MMS/TCP/IP connectivity required? If browsing, SCADA access, or remote settings or controls are to be used, then this is a requirement, and B11 and/or B12 (client and/or server) and B21 are required. We refer to this in the following sections as model access.

• Are GOOSE/GSE services required? There are a variety of applications that have been or are being developed that make use of these services. If these services are to be used, then B31 and/or B32 (publisher and/or subscriber) and B21 are required. This is referred to in the following sections as GOOSE Access.

• Are sampled value control services required? If high-speed sampling is to be used by the device, it will either use this scheme or some proprietary point-to-point scheme. If these services are to be used, then B41 and/or B42 (publisher and/or subscriber) and B22 or B23 (point-to-point or multicast) are required. This is referred to as in the following sections as Sample Access.

Table 6-15 was taken from IEC61850 part 7-2 and was annotated with comments in the right column regarding the applicability of each item. The client/subscriber and server/publish columns (along with the associated notes) are taken directly from the IEC standard and denote the overall requirements for basic conformance to the standard. Specific utility application requirements should still include all items marked mandatory (M) in the base standard, but optional (O) entries may be changed to mandatory. The value added in this document apply only of there is an optional component, implying that a decision is to be made by the utility/consultant/integrator.

Page 204: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-38

Table 6-15 Basic Conformance Statement

Client/ Subscriber

Server/ Publish

Value/ Comments

Client-server roles

B11 Server side (of TWO-PARTY-APPLICATION-ASSOCIATION)

– c1 Acts as a server

B12 Client side of (TWO-PARTY-APPLICATION-ASSOCIATION)

c1 – Acts as a client

SCSMs supported

B21 SCSM: IEC61850-8-1 used MMS client over TCP

B22 SCSM: IEC61850-9-1 used Specialized sampled values

B23 SCSM: IEC61850-9-2 used Normal sampled values

B24 SCSM: other Not currently used

Generic substation event model (GSE)

B31 Publisher side – O Sends GOOSE/GSSE

B32 Subscriber side O – Receives GOOSE/GSSE

Transmission of sampled value model (SVC)

B41 Publisher side – O Sends CT/VT samples

B42 Subscriber side O – Receives CT/VT samples

c1 – shall be ‘M’ if support for LOGICAL-DEVICE model has been declared

O – Optional

M – Mandatory

6.4.2 ACSI Models Conformance Statement

The second step in specifying the IEC61850 communications requirements is in the selection of the ACSI models that must be supported in the clients, servers, publishers, and subscribers. These decisions should be driven by the functional requirements specified by the utility engineers, as well as by the product-based decisions of the vendors.

Page 205: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-39

Table 6-16 is used to detail the next level of conformance, given the high-level selection defined in the previous section. The items being selected here are the service models, each of which may contain several optional services and data structures. The choices here depend on the how the device is to be used by applications/browsers. The broad categories used in this document are defined here:

• Basic Access: As the name suggests, this covers the most fundamental ACSI models and allows the client to explicitly initiate the reading and/or writing of specific data items in the server. With basic access models, the system can support basic two-party connections (such as MMS/TCP/IP). The system should support the basic self-description services and the standardized IEC61850 models. The basic access may be read-only, or may allow read/write access to controls, settings, and settings groups. Basic access is required for remote access by field engineers and maintenance.

• Reporting: Reporting is required for more advanced applications that need up-to-date values because this mechanism is usually used for report-by-exception (in which pre-specified data are transmitted immediately upon the occurrence of pre-defined events). The use of reporting is highly recommended, as periodic polling of data is usually far less efficient. The IEC61850 reporting scheme allows for unsolicited report-by-exception of data items included in datasets. The datasets may be fixed, configurable, or dynamically defined using the (optional) service CreateDataSet.

There are two forms of IEC61850 reporting: unbuffered and buffered. When the unbuffered form is used, the server determines when data should be sent (either due to data changes, quality changes, or freeze evens) and attempts to transmit it to any clients that have enrolled for the data. If it is unable to send the data, it is simply lost. This form of low-cost reporting is appropriate for some devices, in that the response to events is not critical, or responses are meaningless after a short period of time.

When the buffered form of reporting is used, the server must buffer change-events for as long as possible (there will always be some limit). This buffered data may be sent to the client at the earliest possible time. Buffering may span connections and, when clients reconnect, they can specify where to restart in the sequence of reports.

Buffered reporting is likely a requirement for most critical SCADA applications. Unbuffered reporting (or reporting upon demand) may be adequate for some SA devices that are not particularly time-critical.

• Logging: The logging mechanism allows for the retrieval of historical data from the end server device. (This should not be confused with the logging of reported data that is performed at the client side.) The IEC61850 logging mechanism resembles the reporting model in that it uses the same event definitions (such as data and quality changes). It is as if the reports are simply buffered and never directly transmitted. Several forms of query services are used to retrieve sets of reports selected and/or sorted on time or sequence. The use of logging depends on local applications.

• Substitution: The IEC61850 substitution model allows the client to request that the server force an input to a fixed value. This may be required in SCADA applications, particularly if the specific data element is being served to many clients. Each logical node identifies those data items that can have substitute values.

Page 206: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-40

• Controls: The controls model includes a number of options for how control commands are issued to devices, such as select-before-operate (ensure that the correct control point is selected before issuing the command), interlock checking (prevent close commands to be issued if a breaker lockout has occurred), and acknowledgements (report whether or not the control command was successfully executed). The style of control may vary across controls within a particular device (the trip of a breaker is handled differently than closing a breaker). It is important that clients support a reasonable range of control styles. The specific requirement of servers depends on the functional requirements specified by the utility engineers (see Section 5).

• Settings Groups: Most devices have settings that can be made visible through the network. Settings may include such things as high and low alarm limits for initiating report-by-exception actions, trigger-point settings for initiating protective relay actions, and ranges for local actions (such as the high and low voltage levels for a load tap changer to stay between).

Most settings can be performed independently of each other. However, sometimes settings must remain consistent with each other at all times—in these cases, setting groups are used. Settings groups permit a number of settings to take effect simultaneously, even if a finite amount of time is required for the client to send all of the new settings to the server. The server makes a window into a bank of setting groups and then allows the client to select one setting group for editing. Only when all of the editing on this group is complete are the settings actually put into effect in the server. A similar process is used by applications running in the server that need to select one of many settings groups as the one current in effect for the device. Settings groups are commonly used in protection devices as well as voltage control devices.

• Generic substation event (GSE): The GSE model allows a publisher to send a multicast message to subscribers as a notification of an event. There are two variations within the GSE model: the GOOSE services allow the message to contain the values of an arbitrary dataset, while the GSSE services restrict the data to a set of double-bit status points. Either mechanism may be used in an implementation, but the GSSE version is compatible with older versions of UCA1. The specific requirement of publishers and subscribers depends on the functional requirements specified by the utility engineers.

• Samples: The IEC61850 sampled values control model is used to manage streams of high-speed synchronous sampling data. As the sampling is performed on the members of a specified dataset, the publisher issues blocks of these time-stamped samples. Obviously, the sampling process must be in synch with the publishing process, so that the resulting sampled data are consistent.

The messages containing the data are transmitted over Ethernet channels that are configured either as point-to-point (IEC61850-9-1) or multicast (IEC61850-9-2) configurations. The point-to-point configuration permits only one subscriber to receive the samples, while the multicast configuration permits more than one subscriber to receive the samples.

1 UCA is a trademark of EPRI.

Page 207: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-41

• Files: The IEC61850 documents include a capability for accessing remote files from devices. In this case, files can be defined as batches of data that are not in object model format). This file access mechanism is independent of other standard file access mechanisms such as FTP, NFS, or other remote sharing protocols. The IEC61850 file access mechanism is primarily used for the retrieval of objects such as COMTRADE event logs and archival telemetry. Any requirement on file services is strictly application dependent.

Table 6-16 has been taken from IEC61850 part 7-2, and annotated with comments in the right column as to the applicability of each item. The client/subscriber and server/publish columns (along with the associated notes) are taken directly from the IEC standard and denote the overall requirements for basic conformance to the standard. Specific utility application requirements should still include all items marked mandatory (M) in the base standard, but based on the functional requirements specified by the utility engineers or due to product-based decisions by vendors, some optional (O) entries may be changed to mandatory. The value/comments added in this document apply only of there is an optional component, implying that a decision is to be made by the utility/consultant/integrator. An asterisk (*) indicates that discussion notes are included in the text following the table.

Page 208: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-42

Table 6-16 ACSI Models Conformance Statement

Client/ Subscriber

Server/ Publish

Value/ Comments

If Server side (B11) supported

M1 Logical device c2 c2 Required if basic access

M2 Logical node c3 c3 Required if basic access

M3 Data c4 c4 Required if basic access

M4 Dataset c5 c5 Recommended if basic access*

M5 Substitution O O Required if substitution

M6 Setting group control O O Required if setting group

Reporting

M7 Buffered report control O O Required if buffered reports

M7-1 sequence-number

M7-2 Report-time-stamp

M7-3 reason-for-inclusion

M7-4 data-set-name

M7-5 data-reference

M7-6 buffer-overflow

M7-7 EntryID

M7-8 BufTm

M7-9 IntgPd

M7-10 GI

M8 Unbuffered report control O O Required if unbuffered reports

M8-1 sequence-number

M8-2 report-time-stamp

M8-3 Reason-for-inclusion

M8-4 data-set-name

M8-5 data-reference

M8-6 BufTm

M8-7 IntgPd

Page 209: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-43

Table 6-16 (Cont.) ACSI Models Conformance Statement

Client/ Subscriber

Server/ Publish

Value/ Comments

M8-8 GI

Logging O O Required if logging

M9 Log control O O Required if logging

M9-1 IntgPd

M10 Log O O Required if logging

Controls

M11 Control M M

If GSE (B31/B32) is supported

GOOSE O O Required if GOOSE

M12-1 entryID

M12-2 DataRefInc

M13 GSSE O O Required if GSSE

If SVC (B41/B42) is supported

M14 Multicast SVC O O Recommended if sample access

M15 Unicast SVC O O Depends on application*

M16 Time M M

M17 File Transfer O O Required if files

c2 – shall be ‘M’ if support for LOGICAL-NODE model has been declared. c3 – shall be ‘M’ if support for DATA model has been declared. c4 – shall be ‘M’ if support for DATA-SET, Substitution, Report, Log Control, or Time model has been declared. c5 – shall be ‘M’ if support for Report, GSE, or SV models has been declared.

M – Mandatory.

O – Optional.

* – See the discussion notes in the following text.

Page 210: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-44

The following discussion notes explain the comments with an asterisk (*) in Table 6-16:

• M4 – Dataset: The dataset abstract service model is very powerful and is supported by most implementations of IEC61850. Therefore, although it appears to be optional, the functional requirements developed by utility engineers are almost certainly going to make datasets mandatory. The implementation of datasets is required to support reporting, logging, and GOOSE. It is theoretically possible to devise an implementation that only allows simple browsing but does not support datasets.

• M15 – Unicast SVC: The multicast scheme (transmission of samples to multiple subscribers) is assumed to be the more common approach used. The unicast scheme is to be used when a particular operation must monitor the stream of samples for some limited period of time (for example, managing point-on-wave switching). The unicast stream is thus temporary. The enabling of the unicast streams could cause network loading and contention problems, so that systems using this feature must be carefully designed.

6.4.3 ACSI Service Conformance Statement

The third step in detailing the IEC61850 conformance requirements is to define which of the optional services within the selected ACSI models are required. It is crucial to define which types of ACSI services are to be implemented as well as the alternatives within each of these services. These decisions should be driven by the functional requirements specified by the utility engineers, as well as by the product-based decisions of the vendors.

Table 6-17 was taken from IEC61850 part 7-2, and annotated with comments in the right column as to the applicability of each item. The client/subscription and server/publish columns (along with the associated notes) are taken directly from the IEC standard and denote the overall requirements for basic conformance to the standard. Specific utility application requirements should still include all items marked mandatory (M) in the base standard, but may change optional (O) entries to mandatory. the value/comments added in this document apply only of there is an optional component, implying that a decision is to be made by the utility/consultant/integrator. Asterisks indicate discussion notes at the end of the table.

The column heading AA: TP/MC defines the application association type. TP specifies two-party (the normal TCP/IP type of association), while MC specifies multicast association. The Multicast association type is used strictly for GOOSE/GSSE communication and does not make use of the TCP/IP stack. These protocols send messages directly on the Ethernet link layer.

Page 211: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-45

Table 6-17 ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Server (Clause 6)

S1 ServerDirectory TP M

Application association (Clause 7)

S2 Associate M M

S3 Abort M M

S4 Release M M

Logical device (Clause 8)

S5 LogicalDeviceDirectory TP M M

Logical node (Clause 9)

S6 LogicalNodeDirectory TP M M

S7 GetAllDataValues TP O M Required if basic access

Data (Clause 10)

S8 GetDataValues TP M M

S9 SetDataValues TP O O Required if basic access

S10 GetDataDirectory TP O M Required if basic access

S11 GetDataDefinition TP O M Required if basic access

Dataset (Clause 11)

S12 GetDataSetValues TP O M Recommended if basic access

S13 SetDataSetValues TP O O Recommended if basic access

S14 CreateDataSet TP O O Depends on application*

S15 DeleteDataSet TP O O Depends on application*

S16 GetDataSetDirectory TP O O Required if basic access

Substitution (Clause 12)

S17 SetDataValues TP M M

Page 212: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-46

Table 6-17 (Cont.) ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Setting group control (Clause 13)

S18 SelectActiveSG TP O O Required if substitution

S19 SelectEditSG TP O O Required if substitution

S20 SetSGValues TP O O Required if substitution

S21 ConfirmEditSGValues TP O O Required if substitution

S22 GetSGValues TP O O Required if substitution

S23 GetSGCBValues TP O O Required if substitution

Reporting (Clause 14)

Buffered report control block (BRCB)

S24 Report TP c6 c6 Required if buffered report

S24-1 data-change (dchg)

S24-2 qchg-change (qchg)

S24-3 data-update (dupd)

S25 GetBRCBValues TP c6 C6 Required if buffered report

S26 SetBRCBValues TP c6 C6 Required if buffered report

Page 213: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-47

Table 6-17 (Cont.) ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Unbuffered report control block (URCB)

S27 Report TP c6 C6 Required if unbuffered Report

S27-1 data-change (dchg)

S27-2 qchg-change (qchg)

S27-3 data-update (dupd)

S28 GetURCBValues TP c6 C6 Required if unbuffered Report

S29 SetURCBValues TP c6 C6 Required if unbuffered Report

c6 – shall declare support for at least one (BRCB or URCB).

Logging (Clause 14)

Log control block

S30 GetLCBValues TP M M

S31 SetLCBValues TP O M Recommended if logging*

Log

S32 QueryLogByTime TP c7 M Depends on application*

S33 QueryLogAfter TP c7 M Required if logging*

S34 GetLogStatusValues TP M M

c7 – shall declare support for at least one (QueryLogByTime or QueryLogAfter).

Page 214: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-48

Table 6-17 (Cont.) ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Generic substation event model (GSE) (14.3.5.3.4)

GOOSE-CONTROL-BLOCK

S35 SendGOOSEMessage MC c8 c8 Required if GOOSE

S36 GetGoReference TP O c9 Depends on application*

S37 GetGOOSEElementNumber TP O c9 Depends on application*

S38 GetGoCBValues TP O O Recommended if GOOSE*

S39 SetGoCBValues TP O O Depends on application*

GSSE-CONTROL-BLOCK

S40 SendGSSEMessage MC c8 c8 Required if GSSE

S41 GetGsReference TP O c9 Depends on application*

S42 GetGSSEElementNumber TP O c9 Depends on application*

S43 GetGsCBValues TP O O Recommended if GSSE*

S44 SetGsCBValues TP O O Depends on application*

c8 – shall declare support for at least one (SendGOOSEMessage or SendGSSEMessage). c9 – shall declare support if TP association is available.

Transmission of sampled value model (SVC) (Clause 16)

Multicast SVC

S45 SendMSVMessage MC C10 c10 Depends on application*

S46 GetMSVCBValues TP O O Depends on application*

S47 SetMSVCBValues TP O O Depends on application*

Page 215: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-49

Table 6-17 (Cont.) ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Unicast SVC

S48 SendUSVMessage TP C10 c10 Depends on application*

S49 GetUSVCBValues TP O O Depends on application*

S50 SetUSVCBValues TP O O Depends on application*

c10 – shall declare support for at least one (SendMSVMessage or SendUSVMessage).

Control (17.5.1)

S51 Select M O Recommended if controls*

S52 SelectWithValue TP M O Depends on application*

S53 Cancel TP O O Recommended if controls*

S54 Operate TP M M Required if controls*

S55 Command-Termination TP M O Depends on application*

S56 TimeActivated-Operate TP O O Depends on application*

File transfer (Clause 20)

S57 GetFile TP O M Required if files*

S58 SetFile TP O O Depends on application*

S59 DeleteFile TP O O Recommended if files*

S60 GetFileAttributeValues TP O M Recommended if files*

Page 216: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-50

Table 6-17 (Cont.) ACSI Service Conformance Statement

Services AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Time (5.5)

T1 Time resolution of internal clock Nearest negative power of 2 in seconds

T2 Time accuracy of internal clock T0

T1

T2

T3

T4

T5

T3 Supported time-stamp resolution Nearest value of 2**-n in seconds according to 5.5.3.7.3.3

* = See the discussion notes in the following text. ** = To the power of n in mathematical terms.

The following discussion notes explain the comments with an asterisk (*) in Table 6-17:

• S14 – CreateDataSet: Most devices support some form of datasets for use with reporting, logging, and GOOSE services. In some devices, the datasets may be fixed, in that they are hard-coded into the device based on the device models. For example, a device may have a fixed dataset consisting of all measurements maintained by a specific function. More advanced devices will support a boot-time dataset definition, in that the datasets are defined as part of the device configuration. The CreateDataSet service is yet a third scheme—datasets are defined through the network at the request of specific clients. This type of operation may cause some difficulty in the field, however, due to the following considerations:

– Datasets may or may not be preserved across reboots, meaning that clients may have to verify the existence and membership of previously created datasets when they connect.

– The creation of dynamic datasets consumes resources on the server. Therefore, at any given time the creation may fail, leaving the application potentially stopped.

– If not deleted by the client that requested them, datasets created through the CreateDataSet service may be left and forgotten, indefinitely consuming resources of the server.

In the future, the dynamic creation of datasets may become increasingly beneficial and powerful for some of the more sophisticated devices because different implementations require different datasets not only initially, but also dynamically as changing needs drive the data exchange requirements.

Page 217: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-51

• S31 – SetLCBValues: The log control block (LCB) is used by clients to configure which datasets to log, and under what circumstances to generate log entries. Some servers may only support pre-configured or fixed LCB values, in which case any writes to the LCBs may fail. This implies that the logging done by the device cannot be changed at run time, which still may satisfy most application requirements.

• S32, S33 – QueryLogByTime and QueryLogAfter: The use of these services depends on how the log is to be used. If the requirement is to simply get archival data to investigate a particular event, QueryLogByTime is the correct service to use. If the objective is to be able to retrieve all log entries (periodically retrieving log entries and storing them elsewhere), the QueryLogAfter service is much more useful.

• S36, S37 – GetGoReference and GetGOOSEElementNumber: The GOOSE service model is used transmit dataset values from a publisher to one or more subscribers using a fast, low-level protocol. The GOOSE messages do not contain any dataset member identification, so there is a potential problem with misconfiguration if the publishers and subscribers are configured for different members in the dataset being transmitted. These services are optional, but allow subscribers to interrogate the publisher about the dataset definition. The support for these services is not required, but is strongly recommended.

• S38, S39 – GetGoCBValues, SetGoCBValues: Clients use the GOOSE control block (GoCB) to configure the datasets to transmit and the various parameters used to manage the communication. If the publisher does not support two-party associations (TP), neither of these services will be available. In this case, the GoCB values are simply configurable and not available through the network at run time. Some publishers may only support pre-configured or fixed GoCB values, in which case reads of the GoCBs may succeed, but writes to the GoCBs may fail. The use of the GoCB services, therefore, depends on the functional requirements specified by the utility engineers and on the local operational procedures within the utility.

• S41, S42 – GetGsReference and GetGSSEElementNumber: This is the same as S36, S37: GetGoReference and GetGOOSEElementNumber.

• S43, S44 – GetGoCBValues, SetGoCBValues: This is the same as S38, S39: GetGoCBValues, SetGoCBValues.

• S45 – SendMSVMessage: See M15 – Unicast SVC in Section 6.4.2 ACSI Models Conformance Statement.

• S46, S47 – GetMSVCBValues, SetMSVCBValues: The multicast sampled values control block (MSVCB) is used by clients to configure which datasets to transmit and the various parameters used to manage the communication. If the publisher does not support two-party associations (TP), neither of these services will be available. T MSVCB values are simply configurable and not available through the network at run time. Some publishers may only support pre-configured or fixed MSVCB values, in which case reads of the MSVCBs may succeed, but writes to the MSVCBs may fail. The use of the MSVCB services, therefore, depends on the local application requirements and on the local operational procedures within the utility.

Page 218: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Implementing IEC61850 in Equipment and Systems

6-52

• S48 – SendUSVMessage: See M15 – Unicast SVC in Section 6.4.2 ACSI Models Conformance Statement.

• S49, S50 – GetUSVCBValues and SetUSVCBValues: The unicast sampled values control block (USVCB) is used by clients to configure which datasets to transmit and to define the various parameters used to manage the communication interface. If the publisher must support two-party associations (TP), and if S48 is required, then S49 and S50 should also be mandatory.

• S51, S52, and S53 – Select, SelectWithValue, and Cancel: These services provide the capability to perform select before operate (SBO) procedures on controls. The select service simply selects a control, and is used to provide a simple two-step operation. If the service is available for a specific control, a client must request the select service before an operate service can be requested. The SelectWithValue service works the same way, except that the select request includes the actual data from the operate service (along with some other authentication parameters), which must be validated by the server before granting the select. It should be noted that support for these services by a server does not necessarily mean that any particular control will make use of it. This must be separately specified for each control object that requires it.

• S54 – Operate: The operate service must be supported if any of the standardized controls are to be used.

• S55 – Command-Termination: The command termination service is actually an indication at the end of a control sequence in which the server notifies the client that the physical operation is completed. Its use depends on the application.

• S56 – TimeActivated-Operate: The TimeActivatedOperate service allows a client to request that a server execute an operate service at some time in the future. Its use depends on the application.

• S57 – GetFile: The GetFile service is used to retrieve a file’s content from a server. Its use depends on the application.

• S58 – SetFile: The SetFile service is used to create a file and store its content on a server. Its use depends on the application.

• S59 – DeleteFile: The DeleteFile service is used to remove a file from the server. Its use depends on the application.

• S60 – GetFileAttributeValues: The GetFileAttributes service is used to retrieve a file’s time stamp and size. Its use depends on the application.

Page 219: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

7-1

7 INSTALLING IEC61850 EQUIPMENT AND SYSTEMS IN SUBSTATIONS

7.1 Purpose and Audience for This Section

7.1.1 Purpose

The development, implementation, and testing of a substation automation (SA) system is a dance among multiple partners: utility engineers, utility operations, utility construction and asset management, utility information technologists, consultants, and multiple vendors. As discussed in Section 3, some of these interactions require strong project management. However, there are some interactions that explicitly involve IEC61850. This section focuses on those issues associated with installing IEC61850 equipment and systems in substations.

7.1.2 Audience

The audience of this section is the integrator of the substation automation system who is involved in developing, implementing, and testing SA systems. These integrators could be utility substation engineers, outside A&E firms, vendors, or a mix of these groups.

7.2 Evaluating and Selecting Equipment and Suppliers

During the planning stage of the substation automation project, the utility will have identified all of the SA applications desired and should have quantified the expected benefits. Based on the desired SA applications and communications needs, a procurement specification is written to select vendors to supply the equipment. Early on, the utility may qualify a limited set of possible suppliers who will bid to the specifications. Some utilities may be constrained by procurement policies to open bids to all comers. In this latter case, the bid evaluation process should include minimum requirements for SA experience (such as having delivered a number of systems or having been in business for seven years) so that the selection is not just determined by the low bid. It is wise not be the first, last, or only customer of a product.

7.2.1 Support for Functional Requirements

The purpose of the procurement specification is to solicit bids for the SA equipment, communications, and SA applications. A secondary purpose is to define, as much as possible, the system applications, maintenance tools, support, and deliverables for the SA systems. More

Page 220: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-2

importantly, the procurement specification must provide the objectives for the SA system and how it fits with the utility’s view of their future operation. If there is a research aspect for some of the SA applications, it will not be possible for the utility to completely specify all details for hardware and interfaces. The bid process itself and the return of information will more completely define the SA system, the responsibilities of the vendors (hardware, software, communications, and integration), and the final network configuration.

The procurement specification should include the following items to ensure a complete return of information.

• An overview of current operation at the utility.

• The desired SA applications.

• Commercial terms and conditions (including such things as pay milestones and warranty requirements).

• Documentation of the requirements.

• Maintenance expectations (outlining what the utility maintains versus what maintenance is contracted).

• Information requirements (what devices, objects, response requirement, frequency of exchange, and where the information must flow). This is a functional specification and should be independent of media.

• Diagnostics.

• Product tools.

• Experience requirements (to qualify the vendor).

• The bid definition (detailing all of the return of information expected from the bidders such as response to a questionnaire, forms to quote the costs, forms to indicate compliance, forms to fill in experience, and reference lists).

• Information on how the utility will evaluate the vendor (see next Section 7.4).

7.2.1.1 General

In general, the procurement specifications should request suppliers to provide comprehensive documentation (for example, data sheets, user guides, drawings, and application guides) in the areas of interest. This information is commonly available on CDs or websites, which provide a convenient way to manage redistribution of and access to such information within the utility organization.

Page 221: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-3

In addition, it is important to consider the suppliers’ needs and issues as one real factor in establishing a harmonious working relationship. The following issues should be considered:

• Expect the principal suppliers to take time to understand the project requirements.

• Expect suppliers to provide personalized application guidance and review concerning use of their products within the project.

• In response to the bid specification, invite suppliers to submit alternatives that they believe offer cost or functional benefits for the project.

• Be considerate of the suppliers’ time, realizing that they are generally compensated only on the products that are actually purchased.

7.2.1.2 Application Functionality

The procurement specification will have outlined in detail what the utility is expecting from each of the SA software applications. This includes all functionality related to supporting utility applications in support of the electric power system. As an example, the interaction with remote metering, load management, or volt var dispatch (including scheduling and how control algorithms work) would be described in detail. Potential suppliers will then describe how their systems work and how they comply, differ, or improve upon what was requested.

7.2.1.3 Product Tools

Suppliers will have software and hardware tools for working with their products, including client programs (as applicable) for the following purposes:

• Creating logic governing product behavior

• Configuring the product

• Downloading/uploading programs, configuration files, and data files

• Testing communication capabilities

• Diagnostic and maintenance aids

The supplier is expected to explain, demonstrate, and offer training on the product tools.

7.2.2 Support for Substation Automation Communication Objectives

The procurement specification should request a protocol implementation conformance specification (PICS) document for IEC61850. This describes the specific functional support that is provided within the product.

Page 222: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-4

7.2.2.1 Network Support

The following types of network support must be provided:

• Support for TCP/IP through the Ethernet

• Support for connection-oriented clients

• Support for multicast/connectionless messaging (that is, GOOSE and GSSE messages), if applicable

7.2.2.2 Support for Utility-Specific Object Models

Utility specific object models are specified in IEC61850 Parts 7-3 and 7-4. These object models are used to specify the functionality included in end-use devices. A model implementation conformance specification (MICS) document should be requested for each field device. This document describes the specific device functionality that is included in the product.

7.2.2.3 Support for Utility-Specific Communication Services

The SA system implementation must include and comply with the communications services specified in part 7-2 of IEC61850. As a minimum, support for mandatory services must be included.

7.2.3 Support for Collateral Communications

Concurrent network support is necessary for other protocols (for example, Modbus, DNP, or FTP) as required, over the same network connection used by SA, but using other logical port numbers. The system will also require support for other protocols over serial ports, using IEEE interface standards (for example, RS-232 or RS-485.) The vendor should be requested to provide a PICS document for the protocols of interest. This document describes the specific functional support that is provided within the product.

7.2.4 Technical Support and Commitment

Suppliers that claim compliance with IEC61850 specifications for a product must adhere to the prevailing specifications and undergo compliance testing to ensure interoperability with other equipment.

A product may legitimately support only a subset of total IEC61850 functionality and features. Even within that scope, they are only obligated to implement the mandatory portions, not the optional ones. For better or worse, what a supplier elects to include represents their marketing judgment.

Page 223: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-5

The project specifications need to spell out the expectations. If the implementation requires functionality and features beyond the anticipated project requirements, the number of candidate products may be artificially limited.

Suppliers may implement extensions to the content found in IEC61850 specifications, as long as those extensions do not contradict or replicate the standard content.

7.3 Monitoring and Managing System Development

As the systems and subsystems are being developed, it is essential to work closely with the primary vendor responsible for integration and the subcontractors to keep the project on track, to gain feedback to ensure that all understand the SA objectives, and to make sure that all are on schedule and within budget.

7.3.1 Project Management

During development, the team project leader at the utility will continue to use the project management tools put in place during planning. The following two activities are very important:

• The team leader will need to monitor the utility staff as training, design walk through and change, or contract review take place. The statement of work identifies the utility tasks such as providing timely information for SA object and database definition, interface control documents, information on utility communication systems, and response to document reviews. The utility must make sure that nothing stands in the way of the vendor effort.

• The team leader, or a single point of contact at the utility, must monitor progress at each of the vendors. This is important to ensure that mistakes or schedule and budget overruns are not occurring. However, there is also a training aspect to working closely with the vendors and providing feedback early during the design and build stages. This ensures that the utility has the best understanding of the SA applications and how they will be used to meet the utility’s critical success factors.

The integrated project management tools discussed previously provide the best method to manage the project during development. The tools in use at the utility may be used to develop the reports internal to the utility for management reporting, budget and schedule control, and staff meeting participation and travel. The vendors may provide input to the utility project management tool or provide separate reports.

The vendors and primary system integrator should provide a monthly progress to the utility team leader. The progress report becomes the primary vehicle for tracking the project and monitoring for schedule or budget overruns. It also provides a summary of work completed and work anticipated for the next reporting period.

The monthly progress report should include the following sections:

• Project highlights and summary

• Activities completed

Page 224: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-6

• Activities planned (focus on interactions expected with the utility such as meetings and design reviews)

• The status of action items

• Problems and risk assessment updates

• Staff changes

• Schedule updates

7.3.2 Meetings

Meetings should follow the guidelines given in Section 3 on good meeting practices. Additionally, working with the vendors places additional constraints (for example, travel is often required and a limited subset from the utility team may be able to travel). A core subteam that represents all of the stakeholders and key users should be identified early in the project and scheduled depending on the meeting purpose. The meeting plan would be included in the integrated planning tool by the utility team leader. Extended periods for training at the vendor sites may be a good way to work closely with the vendor team. Teleconferencing is currently a well-accepted practice that would easily accommodate the goals of most meetings (such as status reviews).

Attendance at the meetings depends on the meeting purpose. For status meetings, only the utility project leader and one or two key people need to attend. For design reviews, the SA application staff should attend. For testing, the utility team members may all have to be present.

7.3.3 Change Order Management

The statement of work defines in detail the technical work that will be done, all of the deliverables, the responsibilities of all participants, documents, maintenance agreements, and testing. It provides a PERT network diagram with a schedule, and key milestones, interaction points, and interdependencies. A separate legal document would provide terms and conditions, costs, pay milestones, and commercial agreements.

Controlling and monitoring for possible changes and problems becomes more important during the implementation stages. This is due to the fact that multiple vendors may be involved and the impact of a change could be more costly because designs may have to be modified, communications systems upgraded, or applications and programs rewritten. Regression testing is also necessary (and costly) to ensure that problem fixes do not uncover other problems in existing codes. Object-oriented design and software provide some level of protection and should be encouraged for the adaptability and flexibility of such practices. IEC61850 is object-oriented and media-independent. It provides the flexibility to change to new objects with minimal impact. New events can be added easily using the GOOSE capability.

The utility should be proactive in monitoring change, identifying the impact to critical factors, and ensuring that the right corrective action is taken. (See Section 3 for further details on change control.) The utility should put a change control subcommittee in place with the formal

Page 225: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-7

responsibility of working with the team leader to ensure that users and stakeholders at the utility are aware of the impacts and are satisfied with the corrective actions. This will significantly help to ensure a satisfactory SA system when operation commences.

7.4 Evaluation Process

Proposal evaluation takes place over several months. For SA systems of the complexity covered by this guide, six months may not be too long. If the schedule calls for some type of fast track, the usual specification, bid, selection, and contract negotiation process must be shortened. In this case, a fast-track process that has worked well is to issue a short request for information (RFI), and then negotiate with the most qualified vendors who can meet schedule and cost constraints. Compared to the usual evaluation process, this approach can save as much as one year.

The following list describes the typical stages of the evaluation process:

1. Develop the specifications, bid documents, and qualified bidder lists.

2. In parallel, prepare the evaluation documents and agree on how the selection will be made (for example, the lowest bidder meeting the major requirements, the bidder providing the best system within the budget, or the bidder providing the best value). It is important for the utility project team and management to understand how the bidders will be selected before the proposals arrive.

3. Contact the vendor customers and fill in the experience forms.

4. Visit the vendor sites for presentations and to view systems and support capability.

5. Plan to have the vendors visit the utility sites to meet with the evaluation team and to clarify proposals.

6. Fill in the evaluation forms and make the final selection.

7. Meet with the utility team to prepare the recommendations.

The recommendations will include a set of suggested changes that must be negotiated with the final bidder. The process of final selection and negotiation will result in a letter of agreement. A contract must be negotiated and a statement of work written by the vendor, which are reviewed and approved by the utility team.

A form for an evaluation worksheet is given in Table 7-1 (which depicts a Kepner-Trego analysis). There should be a form for every bidder in the evaluation process. The form, evaluation category, weights (importance of the item), and score assignments should be documented before the evaluation. Criteria for scoring each requirement, desired feature, and the vendor’s performance during the site visits and demonstrations should all become part of the evaluation score to make the selection as objective as possible. The “must have” items should be included in the bid request so vendors know that they will be eliminated if they do not satisfy these requirements.

Page 226: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-8

Table 7-1 Kepner-Trego Analysis

A: Evaluation Category B: Weight C: Score Must Have Weighted Score

Experience: List number of installations, years, SA background, or other evaluation criteria. (Score on each item of the list.)

1–10 (Gives the importance ranking for the category /item)

1–10 Identifies those areas that are must haves for selection

B × C (or eliminated based on must have result)

References: Score here based on responses.

Requirements: List all of the key requirements here.

Desirable features: List all of the important features here. (Weights may be low or this may be for information only.)

Site visit: Score here.

Demonstration: Score here.

Total score Summation here

7.5 Statement of Work

The statement of work defines in detail the technical work that will be done, all of the deliverables, the responsibilities of all participants, documents, maintenance agreements, and testing. It provides a PERT network diagram with a schedule, key milestones, interaction points, and interdependencies. A separate legal document provides terms and conditions, costs, pay milestones, and commercial agreements.

7.6 System Integration and Testing

Testing of a procured system is critical to ensuring that all requirements are met. Requirements are never satisfied by accident. If a requirement is not tested for compliance, it is highly unlikely that it will be satisfied. A corollary to this is that requirements that are not testable are not requirements.

Some requirements would be tested by a form of verification (for example, good, solid, and usable documentation is essential for the users to understand and maintain their system), so the delivered documentation must be tested. This is be done by reviewing the documents and checking them against the equipment or software that they are intended to describe.

Page 227: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-9

Test documentation, including plans, procedures, and test results, should conform to the guidelines given in ISO 9000 specifications. (See Section 7.7). The following paragraphs cover the steps that a utility might take in procuring OM-SA products with IEC61850 devices and following a rigorous testing process.

7.6.1 Specification

Specifications must be written for the desired device. These should include communication requirements and desired testing. Payment milestones should be tied to completed tests and certification. Use the reference specification to procure communications.

7.6.2 Vendor Selection

Follow normal procurement procedures and contract vendor selection. This enables the purchaser to make sure the vendor supplies certified products. Include the requirement for early testing and certification of communication products.

7.6.3 Certification

During the development of the specific device, the vendor runs unit and IEC61850 certification tests to verify that the device meets communication requirements for the protocol with the desired features. The test declaration identifies the device, the operating system, and IEC61850 PICS showing the features and options (such as object models, basic read/write, select before operate, events, automatic reports, and time sync) that were certified.

Certification means that approved procedures have been completed to test a device in a formal environment with results documented in a test declaration. Some of the tests may be done remotely using the Internet. Other tests, such as performance/response, may be required to be done on the same local area network. It should be noted that, if a test report/certification is going to be generated, it must be done on a per product basis because the PICs/PIXIT combination will change (otherwise there would be no product differentiation. The IEC61850 certification tests should focus on the communication protocols at all layers of the OSI model, common application service model (the IEC61850 Services at the top), and the object models (such as IEC61850 Part 7-4). Test/certification procedures are a work in progress for the UCA International Users Group.

7.6.4 Factory Acceptance Test

Traditionally, factory acceptance testing (FAT) is a complete test of an integrated system at the vendor facility with application functions, database, HMI, displays, and logs unique to the purchasing utility’s system. These applications are the added value that the given vendor can bring to the market. The certification process creates a high level of confidence that IEC61850 communication conformance and interoperability with other conforming devices has been met. Those tests of IEC61850 communications that were part of certification need only be spot-checked at FAT as a reliability check because focus is on special applications.

Page 228: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-10

7.6.5 Site Acceptance Test

Upon the completion of FAT for traditional systems, delivery is made to the utility. At this point, a site acceptance test (SAT) is run to verify that the system will operate properly in the field. For a device, the SAT would likely be divided into parts, with a lab-staging and acceptance test run (LAT) first (where the device is connected in a controlled environment to check IEEE SWC, environmental conditions, and operation with other delivered IEDs for performance and sizing). After this step, the field test (FT) is started with hookup in the substation (or to other utilities if ICCP/Tase-2 is included). The FT may involve a fairly long period while the device is connected to end devices, other utility equipment, other vendor IEDs, and the utility LAN and WAN. Reliability of the device to run without failure and maintenance procedures would be checked. The FT is done in stages and the utility may disable controls or protection features of the device while an end-to-end check of the database, alarms, and events is done to preclude any false operations. (Note that an external lab could conduct the LAT, but the FT must be at the utility site with the real devices.)

After a satisfactory period where the device operates correctly, cutover to full operational status is done. Upgrades and changes may be made to the devices in the field by remote connection to the vendor. The ability to have the upgrades tested through certification is a definite plus. It adds to the ease of maintenance and lower lifetime costs of IEC61850 conformant devices with self-defining capability.

7.6.6 What Is Tested and When

There are different types of tests depending on the project phases. Testing should be started as early in the development cycle as possible. This helps to uncover trouble while resources are available to make the corrections at minimal cost. The Government Accounting Office estimates that problems uncovered late in a project (at system operation time) are 200 times more costly to correct than those uncovered during the design. This is a strong incentive to test early and completely.

Unit testing is the earliest testing that is done. This takes place as soon as initial codes are complete. Black box testing (testing that exercises each module based only on knowledge of inputs and outputs) and White Box testing (testing with an understanding of the internal logic) should be done. Stress, boundary, overload, recovery from failures, backup capability, and performance can be tested with simulation. These tests may uncover problems that might only take place once every several years in the field under normal conditions. The impact of such a failure could be costly to the utility, so the expended time and resources to complete the stress tests are justified.

The utility user should plan to witness the early tests as soon as the SA applications human interface can be observed along with SA algorithms. The utility understands the logic and the use of the outputs and can check on how easy the applications are to use.

Table 7-2 presents the details of various types of testing.

Page 229: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-11

Table 7-2 Types of Testing

Type Purpose When Who

Unit test Verify proper code; stand-alone execution

As modules are completed

Programmer/QA

System Functional modules System build Developers/QA integrators/users

Integration Verify that all vendor systems play together

System integration Developers/QA integrators/users

Stress/bench test Test performance and boundary conditions (may require simulation)

All phases Programmer/ QA/developers/users

Acceptance Customer acceptance At factory and at site Vendors/users

As noted previously, acceptance testing goes through several phases. The factory acceptance test for SA takes place at the primary vendor or integrator location and ensures that the systems are fairly solid before they are shipped. The site acceptance test phase starts with a start-up test that runs through major functions before the systems are connected to devices and communications and put on line.

7.6.7 Conformance Testing of OM-SA Products

For the communications protocols, certification and/or some type of conformance testing would be done early on. The communication protocols, such as IEC61850, would be conformance tested for all services and basic data objects against a reference system that is recognized by the industry (that is, qualified by an independent party such as the UCA International Users Group).

Conformance testing (with open testing procedures and approved test scripts) provides considerable benefit for the industry and the utilities developing substation automation systems. Much of the work will have been done by the independent agencies (IEC and UCA). This eliminates duplication of effort and ensures that test cases are available that are proven against IEC61850 standards. Further, the vendors would understand what protocol tests will be run (as noted previously, this certification requirement is given in the procurement specifications) and can run in-house tests based on the approved test scripts to uncover errors in design or protocol interpretation at system build time when the cost to make corrections is low. A possible architecture for conformance testing based on an open, approved process is shown in Figure 7-1.

Page 230: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-12

Figure 7-1 Architecture for Open Conformance Test

The general flow of the automated conformance testing is shown in Table 7-3.

Table 7-3 General Flow of Automated Conformance Testing

Step Process

1 A PICS, MICS, and device configuration input forms configure and define the IED’s services, objects, and IEC61850 and SA communications configuration for the device under test (DUT).

2 The test driver (depending on the test vendor) uses standard software to configure and execute tests based on test scripts (*.tst files).

3 The test scripts parse the testinfo.xml file to determine the number of repetitions, test topology (LAN/WAN), and other information, and builds detailed test transactions.

4 The test scripts determine the status (for example, PASS or FAIL) of each test case. The test scripts contain information on the expected results and exercise the DUT according to industry-approved test cases (such as those included in Part 10 of IEC61850).

5 The test case transactions invoke an IEC61850/stack to communicate with the DUT.

6 Upon the determination of PASS/FAIL, an extensible markup language file (XML) holding the test results (or some other open standard format) is updated. (Some of the test cases require manual execution or observation. For these tests, a manual update of the testresult.xml file might be required.)

7 After a review of the results, modifications can be made and the device resubmitted by looping back to Step 1.

8 Test results and reports are generated in standard format. A Certificate is manually issued on DUT PASS of all specified conforming features (IEC61850 objects and services).

Page 231: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-13

7.6.8 Test Plan Outline

The test plan is the responsibility of the primary contractor or the integrator. It includes all of the information on responsibilities of the parties, what will be run and when, and how the parts of the SA system fit together and are integrated for conducting the tests. It would include a reference section on what protocols are required for each interface (that is, the interface control documents and references to the standards and implementation agreements or errata sheets) and what qualifications are required before each test type (that is, protocol certification at unit test time and data object checkout). Table 7-4 presents a sample test plan outline.

Table 7-4 Sample Test Plan Outline

Section Contents

Introduction Identifies the audience and purpose of the plan

Executive summary Provides a management overview of plans and major steps

Approval/revision levels

Provides sign-off by participating organizations

References Includes standards, applicable errata, test scripts/procedures for certification, exceptions in SA specifications for communication requirements, performance/ sizing/configurations for SA, ICDs

Qualification tables Lists the entry qualifications required before each test level (such as certification by agency, database verification, dry run of test procedures, or test notification for staff participation)

Unit test Covers participants, schedules, locations, environment, test cases, pass criteria, assumptions, and problem handling

System test Covers participants, schedules, locations, environment, test cases, pass criteria, assumptions, and problem handling

Integration test Covers participants, schedules, locations, environment, test cases, pass criteria, assumptions, and problem handling

Stress test/bench test/security

Describes simulation/destructive testing to ensure security, failure recovery, boundary and overload conditions, and fail-soft under all conditions

Factory acceptance test

Reviews major acceptance and pay milestone— covers participants, schedules, locations, environment, test cases, pass criteria, assumptions, and problem handling

Site test Describes initial delivery test before commissioning (partial rerun of FAT)

Availability test/ field test

For SA, may be a one-year test with availability and long-term performance verified— includes agreement on how results are reported and who is responsible, spare parts and maintenance agreements, and corrective action

Page 232: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-14

7.7 IEC61850 Testing

The process of testing conformance of SA devices based on the recommendations of the IEC in IEC61850 Part 10 is covered in some detail in the following subsection. (As noted earlier, IEC61850 is the International Standard for IED and substation communications.)

7.7.1 Key Testing Definitions

The following list provides some key definitions:

• Positive test: A positive test is a test to ensure the correct implementation of the system capabilities as defined by the supplier. A positive test has a described and defined response.

• Negative test: A negative test is run to check proper response to an incorrect input. It is a test to verify the correct response of a device or a system for IEC61850 conformant information and services which are not implemented in the device or system under test or on non-IEC61850 conformant information and services sent to the device or system under test.

• Protocol implementation conformance statement (PICS): The PICS is a summary of the capabilities of the system to be tested.

• Protocol implementation extra information for testing (PIXIT): The PIXIT document contains system specific information regarding the capabilities of the system to be tested and that are outside the scope of the 61850 standard. The PIXIT is not subject to standardization.

• Model implementation conformance statement (MICS): The MICS details the standard data object model elements supported by the system or device.

• Static conformance requirements: The static conformance requirements define the requirements that the implementation will.

• Dynamic conformance requirements: The dynamic conformance requirements define the requirements that arise from the protocol used for a certain implementation.

• Abstract communications service interface (ACSI): The ACSI is a set of services that provides for the establishment of connections, the exchange of information, and related support for communications.

• Object: An object is an entity with a well-defined boundary and identity that encapsulates state and behavior. State is represented by attributes; behavior is represented by services and state machines. An object is an instance of a class.

• State machine: A state machine is a behavior that specifies the sequences of states that an object or an interaction goes through during its life in response to services, together with its responses and actions.

Page 233: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-15

7.7.2 Conformance Test Process

The conclusion, and designation of a successful test, always requires a person to review and approve that the results are valid. Thus, the test results are only approved when the customer (or the individual ordering the test) signs-off and agrees with the results. The conformance test process and related steps (based on Part 10 of ICE61850) are illustrated in Figure 7-2.

Figure 7-2 Conformance Test Steps

Page 234: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-16

7.7.3 Standard Test Procedure Groups

Part 10 of IEC61850 defines test cases for both normal functions and anomaly testing (or negative) tests. The test cases are divided into groups depending on function. The main groups are shown in Table 7-5.

Table 7-5 Test Procedure Groups

Test Procedure Group Specification Reference

Notes

Documentation and version control IEC61850-4 Visual inspection

Device configuration and standardized syntax IEC61850-6 Formats and device setup

Device configuration and device objects IEC61850-7-3 IEC61850-7-4

Verification of correct objects and data structure

Stack implementation specific mapping IEC61850-8, IEC61850-9

To MMS/Ethernet or IEC serial links

Implemented abstract services IEC61850-7-2 Communication services

Communication functions Performance issues

Device specific extensions IEC61850 Vendor additions follow IEC rules.

7.7.4 Control Test Example

As discussed previously, the conformance tests cover all aspects of IEC61850. The following example illustrates one of the test cases from Part 10 (both positive and negative tests are shown):

• Positive

– Force and check each path in the control state machine for several control objects with control modes (compare to state control diagram in IEC61850 Part 10).

– Direct-operate with normal security.

– SBO-control with normal security (operate once/many).

– Direct-operate with enhanced security.

– SBO-control with enhanced security (operate once/many).

– With test mode set, verify that no operations to the process are performed.

– Verify that ctlVal and operTime are effective.

– Select all SBO control objects and cancel them in opposite order.

• Negative

– Operate (without select) for an SBO control object and verify the response – AddCause.

– Select twice (second select should fail and verify the response) – AddCause.

Page 235: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-17

– Operate value is the same as the actual value (On-On, or Off-Off). Verify the response – AddCause.

– Select the same control object from two different clients, verify the response –AddCause.

– Verify situations to set specific other applicable AddCause values.

– Select/operate an unknown control object and verify the response –AddCause.

• Performance

– Measure the select/operate command response time.

– Measure the control reaction time.

Testing and protocol definition rely heavily on the use of state transition diagrams. These provide a simple, elegant shorthand method for describing the complex and transaction-oriented series of actions in communications or control systems. They are used extensively in protocol definitions and are useful in documenting test scenarios.

There are three parts to the state transition diagrams as listed here:

• Definition of the states

• Diagram of the transitions

• Definition of the transitions (initial state/events/conditions/actions/next state)

As an example, consider a transition for part of an operation in an electric utility control system. The original state of a device is NOT SELECTED. The transition to an authorized SELECTED state is defined. The device is selected based on the Event of receipt of a Select Message. The Conditions for moving to SELECTED are verification of the correct Select Message—no other SELECT pending, the device is controllable (not tagged or locked in any way), and the sender is verified and authorized to do the control. The actions are the following: A Select Verify Message is returned to the sender, a Select Timer is set, and the state of the device is SELECTED.

This is an example of a correct transition. One benefit of using state transition diagrams is the ease of documenting all possible events, conditions, and actions including anomaly conditions. Using this example, there are more ways that a device moves to the NOT SELECTED state then to the SELECTED state. For example, the device may be tagged, an invalid message may be received, it may be RESET, or the select timer may expire

State transitions are defined according to the following transition flow: Initial State/Events/Conditions/Actions/Next State. Examples of the application of these transitions are shown in Tables 7-6 though 7-8.

Page 236: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-18

Table 7-6 State Definitions for Control

NORMAL Device is not selected and available for commands.

SELECTED Device has been selected via a valid selection message.

CONTROLLING Device has been selected and received a valid control message.

Table 7-7 Events/Message Definitions/Conditions/Actions

SelMSG Select message

CtlMSG Control message: content gives direction and control parameters

SetTmr Set cancel select timer

ExpTmr Timer expires

Tag Device is tagged

InvMSG Invalid, unknown, incorrect or undefined message

CnlMSG Cancel previous request

RspMSG+ Acknowledge or positive response

RspMSG- Negative response to incorrect message or error condition

Table 7-8 State Transition Table for Control

State Events Conditions Actions Next State

NORMAL SelMSG Valid message, not tagged

SetTmr/RspMSG+ SELECTED

SELECTED CtlMSG Valid message ResetTmr/RspMSG+ CONTROLLING

SELECTED InvMSG Wrong message Resets All Conditions NORMAL

NORMAL SelMSG Valid message, tagged RspMSG- NORMAL

NORMAL InvMSG Wrong message No Action (For Security Reasons, No Message Response is Returned)

NORMAL

All States CnlMSG Authorized Reset All Conditions/RspMSG+

NORMAL

SELECTED ExpTmr Reset All Conditions/RspMSG+

NORMAL

CONTROLLING Completes Valid control RspMSG+ NORMAL

Page 237: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-19

State transition diagrams (see Figure 7-3) are graphic flow charts that would show the transitions between states with the events/conditions/actions shown along the flow lines.

Figure 7-3 State Transition Diagram

While the diagrams show the flow and direction in a manner that is intuitive and easy to see, they can quickly become cluttered if too much information is covered. In the example in Figure 7-3, only correct transitions are shown. For an exhaustive treatment of all cases, the transition tables may be used to supplement the diagrams. In the previous state transition table, the invalid messages (InvMSG), which may be shown on a single line of a diagram, could be broken down further—unauthorized source, correct device but wrong command, right command but wrong device, security violation, and format or field errors. The transition tables are useful for defining the error and anomaly conditions that are tested.

7.7.5 Sample Test Cases

As noted earlier, IEC61850 provides definitions of test cases. Much of the work has been completed for testing conformance definition and users may use Part 10 of IEC61850 to specify the tests they require for acceptance by referencing the test case ID. The test case identifiers have the form: “ABC”Nn. The “ABC” is short for the service group. The “N” identifies negative tests, and the “n” is the number of the test case subset. Therefore, in the Table 7-9 there are three test cases for files with positive results: FT1, 2, and 3. There is one negative test: FileN1.

Table 7-9 lists most of the test cases defined in IEC61850.

Page 238: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-20

Table 7-9 Test Cases Defined in IEC61850

Service Levels Function Positive Negative

Association Establish connections Ass1-4 AssN1-5

Server and logical device Basic definitions and structure Srv1-8 SrvN1-4

Dataset Defining groups of information DsetP1-10 DsetN1-11

Substitution Data substitution Sub1-2 SubN1

Reporting Periodic or event reports Rpt1-11 RptN1-9

Logging Storing and accessing historical data

Log1-11 LogN1-9

Substation events GOOSE or GSSE exchanging events with status or data

GOO1-13 GsePS1-2

GseNP1-6 GseNs1-2

Transmission of sampled values

Subscribe and publish Sv1-2 TsvPp1-6

TsvNs1-2

TsvPNs1-2

Control Direct, with delay, by time-or-day, with security

Ctl1-5 SBOes1-7

SBONs1-5

Time and time synchronization Tm1-2 TimN1-2

File transfer Exchanging file-oriented data Ft1-3 FileN1

There are presently a total of 167 test cases defined in Part 10 of IEC61850.

It is important for the user to understand that the test cases are a summary of what may be tested. Detail is not provided about how the tests are to be conducted. Test procedures must be prepared and, if the tests are run by some type of automatic test case generator (as discussed previously) the test cases must be read-in and translated to test driver instructions. The Users Group is developing a Test Quality Assurance Program that will include writing test procedures based on IEC61850 Part 10.

Part 10 provides guidelines for reporting test results. The conformance test report is formatted according to Table 7-10.

Page 239: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-21

Table 7-10 Conformance Test Report Format

Section Content

Report ID Include the date.

References List all relevant documents including requirements, PICS, MICS, and PIXIT.

Test configuration

Include test system, setup parameters, simulation, and input. (This is a summary and may point to the references.)

Test vendor Identify who will conduct the test.

Test owner Identify who will order the test and control the results (typically a vendor gaining certification or a user).

Test facility Identify the location of the test and support.

Device tested Include the definition of the device under test, PICS, PIXIT, constraints, hardware and software release information. This is a summary and may point to references.

Tests conducted

List by IEC test cases ID.

Tests result List by IEC test case ID and indicate Pass/Fail/Incomplete. Include designation of mandatory, conditional, optional requirements. Include any important observations to help with result and/or correction determination.

Signature block

Include approval signatures for all key parties.

7.8 System Maintenance and Support

Proper attention to maintenance requirements, support, and training is critical to the proper operation of the SA system. It is important to recognize that most of the life-cycle costs and the impact on resources during a project’s lifetime is in the operation phase for maintenance (80% by most estimates).

Maintenance may be divided into several categories, which include the following: routine maintenance of equipment and software, maintenance of the substation automation functions, enhancements and upgrades, and support. Support provides the utility user with on-call assistance, help-desk assistance, or other resources to assist the maintenance staff (hardware, communications, or operating system) in completing their work. Support also includes keeping the utility informed about changes such as revisions to the communications.

To be effective, the maintenance contractor is expected to meet service agreement levels as outlined in the Table 7-11. (This table would be expanded for all major subsystems).

Page 240: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Installing IEC61850 Equipment and Systems in Substations

7-22

Table 7-11 Sample Service Level Agreement Response Times

Function Severity Resolution Time Action

Critical communications A 1 Hour To meet 99.9% availability (or as specified)

Critical SA functions A 1 Hour As specified

Backup systems B 8 Hours As determined by the availability calculations

Routine hardware C 24 Hours

As part of the original project plan, the high-level requirements such as annual availability, list of critical functions, and back-up levels is provided for the communications and all of the SA functions based on benefits and possible loses on failure. As part of the contractor statement-of-work, maintenance agreements are written to define the contractor role in working with the utility and the responsibility of all participants. For example, the utility may need to keep an inventory of spare parts on hand or may need to meet certain training levels for hardware and software staff to satisfy the maintenance requirements. The high availability of critical functions for SA is a systems function that includes not only equipment, but also the staff who are responsible for operations and maintenance.

As part of an ongoing operation process for SA, the users of the SA systems and the staff responsible for maintenance should review how well they are satisfied with the tools, support, and contractor activities. There should be a monthly maintenance report on satisfaction and problems encountered. The maintenance contracts should tie the vendor support into payment incentives. As noted earlier, the major cost for SA is in these phases. Also, the usability of the SA system, acceptance by operators, and the derived benefits are highly correlated to how well the systems work and how easy they are to maintain.

Page 241: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A-1

A GLOSSARY/ACRONYMS

The terms included in this appendix are listed in alphabetical order. A category and definition are provided for each term or acronym.

Term/Acronym Category Definition

access point IEC A communication access point to an IED. This may be a serial port, an Ethernet connection, or a client or server address dependent of the stack being used. Each access point of an IED to a communication bus is uniquely identified. Each server has only one logical, access point.

IEC61850-6

ACSI IEC Abstract communication service interface. A virtual interface to an IED providing abstract information-modeling methods for logical-devices, logical-nodes, data, data attributes, and communication services (for example, connection, variable access, unsolicited data transfer, device control and file transfer services independent of the actual communication stack and profiles used).

IEC61850-1

application layer IEC The top layer (layer 7) in the OSI reference model for open-system interconnection comprising the interface between the OSI environment and the IED’s/user’s application.

ISO 7498-1

association IEC A conveyance path established between a client and a server for the exchange of messages.

IEC61850-7-1

Page 242: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Glossary/Acronyms

A-2

Term/Acronym Category Definition

CASM UCA Common application service models (matches the IEC definition for ACSI).

class IEC The description of a set of objects that share the same attributes, services, and semantics.

IEC61850-7-1

client IEC An entity that requests a service from a server or that receives unsolicited data from a server.

IEC61850-7-1

communication connection

IEC A connection that utilizes the communication mapping function of one or more resources for the conveyance of information.

IEC61850-10

communication stack

IEC A multi-layer stack. In the 7-layer OSI reference model for open system interconnection, each layer performs a specific functional role in open system interconnection communication.

ISO 7498-1

configuration (of a system or device)

IEC A step in system design (for example, selecting functional units, assigning their locations and defining their interconnections).

IEC 60050-351

CD IEC Committee draft.

CDV IEC Committee draft for vote.

CIGRE General International Council on Large Electric Systems.

CIM UCA Customer information model.

Page 243: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Glossary/Acronyms

A-3

Term/Acronym Category Definition

device IEC An element or assembly of elements performing a required function. (Note: A device may form part of a larger device).

(IEV 151)

A mechanism or piece of equipment designed to serve a purpose or to perform a function (IEEE Standard 100–1996, IEEE dictionary of electrical and electronic terms) such as a circuit breaker, relay, or substation computer.

IEC61850-1

In the context of a switchyard, a device is a physical plant item (for example, a transformer or a circuit breaker). In the context of substation, an automation device is an IED.

IEC61850-6

DUT UCA/IEC Device under test.

FACTS General Flexible AC transmission system.

GOMSFE UCA Generic object models for substation and feeder equipment.

GOOSE UCA Generic object-oriented substation event.

HMI General Human machine interface.

IEC General International Electrotechnical Commission.

IED General Intelligent electronic device.

Page 244: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Glossary/Acronyms

A-4

Term/Acronym Category Definition

IED parameter set IEC All of the parameter values needed for the definition of the behavior of the IED and its adaptation to the substation conditions. Where the IED must operate autonomously, the IED parameter set can be generated without system parameters using an IED-specific parameterization tool. Where the IED is a part of the substation, the IED parameter set may include system parameters, which must be coordinated by a general parameterization tool at the SAS level.

IEC61850-4

IEEE General Institute of Electrical and Electronic Engineers

interchangeability IEC The ability to replace a device supplied by one manufacturer with a device supplied by another manufacturer without making changes to the other elements in the system.

IEC61850-1

interoperability IEC The ability of two or more IEDs from the same vendor, or from different vendors, to exchange information and to use that information for correct execution of specified functions.

IEC61850-1

IP IEC Internet protocol. The TCP/IP standard protocol defines the datagram that provides the basis of connectionless packet delivery. It includes control and error message protocol providing the equivalent functions to network services (layer 3 of the OSI ).

IEC61850-3

IRIG General Interrange Instrumentation Group serial time code format standards.

ISO General International Standards Organization

IUT UCA/IEC Implementation under test. This term represents the entity being tested.

Page 245: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Glossary/Acronyms

A-5

Term/Acronym Category Definition

LAN General Local area network

MB General Megabyte

Mbps General Megabits per second

MMS General Manufacturing message specification

OSI General Open system interconnection

PC

PIC

PICOM

General

UCA/IEC

IEC

Personal computer

Protocol implementation conformance

Pieces of Information for Communication

PICS UCA/IEC Protocol implementation conformance statement

PIXIT UCA/IEC PIC exceptions for the test system

PLC

QoS

General

General

Programmable logic controller

Quality of Service

RP General Research project

SAS IEC Substation automation system

SCC IEEE Standards Coordinating Committee

SW General Software

TC IEC Technical committee

TCP/IP General Transmission control protocol/Internet protocol

TISSUES UCA Technical issues

TR IEEE Technical report

UCA General Utility communications architecture (UCA is a trademark of EPRI)

UPFC UCA Unified power flow controller

Page 246: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Glossary/Acronyms

A-6

Term/Acronym Category Definition

WAN General Wide area network

WG UCA/IEC Working group

Xml General Extended markup language

Page 247: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

B-1

B A BRIEF HISTORY OF UTILITY INDUSTRY STANDARDS DEVELOPMENT

Background of Utility Communications Architecture (UCA)

History of UCA and IEC61850

The following subsections on the history of UCA have been extracted from Introduction to UCA Version 2.

UCA Version 1.0

Advancements in computer and communications technology have been successfully applied by utilities in the development of information systems. Many of these systems are dedicated to meeting the specific needs of particular utility functions. These systems, however, have evolved based on the proprietary and/or utility-developed communications protocols. As a result, this process has created “islands of information” optimized for various vendor-specific platforms only. These islands make communications difficult between them and within, as well as complex, and costly - or impossible due to lack of available specifications and experts. The problems associated with integrating these platforms are becoming more acute as the need for communications systems within a utility grows.

In order to promote and facilitate interoperability between computer systems supplied to the utility industry, EPRI initiated the Integrated Utility Communication (IUC) program. The Utility Communications Architecture (UCA) project began in November 1988 as the first of a series of projects under this program. The project, conducted in conjunction with Pacific Gas and Electric (PG&E) and Houston Light and Power (HL&P), resulted in the development of a standard communications architecture, the UCA Version 1.0, to meet the communications needs of the electric utility industry. The UCA Version 1.0 was based on information exchange requirements identified during interviews with representatives from 14 electric utility companies, including approximately 100 utility personnel from PG&E and HL&P. A number of deliverables were created to help develop and support UCA.

As part of the UCA Version 1.0 effort, a detailed information exchange requirements analysis was performed based on extensive interviews with utility representatives. Based on the results of the requirements definition, a standards assessment was performed to review relevant international standards, from which a suite of protocols was selected, and a set of profiles was

Page 248: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-2

defined. For most real time data acquisition and control applications, the standard ISO 9506 - Manufacturing Message Specification (MMS) was adopted.

While the UCA Version 1.0 profiles supplied a great deal of functionality, industry adoption was limited. One of the most significant barriers to adoption was in the lack of detailed specification of how the protocols would actually be used in utility field devices. The rich functionality and broad generality of MMS in particular meant that without further specification, field devices could implement utility applications using a variety of services and procedures, resulting in a continued lack of interoperability.

UCA Version 2.0 for Real-Time Database Exchange

While the adoption of UCA Version 1.0 was limited, the needs for improved standardization within the utility industry became more acute. In particular, the moves toward a deregulated utility environment have significantly increased the requirements for communications standards both within and between utilities.

The first major move to address these heightened requirements was in the area of communications between control centers. Three primary standards were in use for inter-control center communications:

• Western States Coordinating Council (WSCC), used in the western North America,

• Inter-Utility Data Exchange Consortium (IDEC), used in eastern North America, and

• Elcom 83 and Elcom 90, used throughout Europe

As the need for a unified standard became clear, the International Electrotechnical Commission (IEC) solicited member bodies for contributions to be considered for international standardization. The lack of a consensus standard in the US, as well as the perceived limitations of all of the existing candidate protocols, led to the formation of a utility/vendor task force sponsored by EPRI, WSCC, IDEC, and a number of utilities. This task force led the development of the Inter-Control Center Communications Protocol (ICCP). The name was later changed to Telecontrol Application Service Element 2 (TASE.2) to conform to IEC TC57 WG07 taxonomy.

The TASE.2 specification defines a standardized use of MMS in UCA Version 2.0 compliant networks for real-time exchange of data within and between control centers, power plants, and SCADA masters. TASE.2 is being standardized as IEC 870-6-503: TASE.2 Services and Protocol, IEC 870-6-802: TASE.2 Object Models, and IEC 870-6-702: TASE.2 Application Profile. The documents are published independently of the rest of UCA, but included by reference in UCA Version 2.0. Each of these documents have been defined in close coordination with the UCA working groups, been balloted as IEC Committee Drafts (CD), revised, and are currently being circulated as Draft International Standards (DIS). TASE.2 has considerable global vendor support, and is currently either deployed or is being deployed in a number of utilities and power pools throughout the world.

TASE.2 is focused on the exchange of real-time data between EMS and SCADA databases, as well as power plant DCS, and large-scale substation hosts (perhaps even RTU level system). The

Page 249: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-3

object models supported by TASE.2 include SCADA points (such as status, analog, accumulator, and control), generation and exchange schedules, availability and forecast reports, accounting information, power plant curves, and general message and file data. TASE.2 does not (as currently defined) directly include formal field device models; data are instead represented in the traditional form of points lists of each of the various point types, independent of the actual physical device at which the data originated. This representation is consistent with standard practice within most systems within and between control centers. Often in such data exchange arrangements, the details of how data are acquired (including the type and physical interconnection of field devices) are not known to the receiving party, particularly in data exchange between utilities.

UCA Version 2.0 for Field Devices

The direct data acquisition and control of field devices (either substation, feeder, customer interface, and power plant controls) is an area that has been undergoing significant transition. Traditionally, the end field devices were directly connected to Remote Terminal Units (RTUs), which provided a network interface and performed initial processing of the acquired data. The introduction of microprocessor technology has led to the development of intelligent electronic devices (IEDs), effectively allowing for the direct network access to the devices, as well as more processing being performed at the end device. As the end devices have become more complex, the cost of integrating the devices has increased. Within the UCA framework, the definition of the data and control functions made available by the device, along with the associated algorithms and capabilities, is known as the device object model.

As part of the EPRI sponsored activities leading up to the publication of UCA Version 2.0, a number of efforts were initiated to develop detailed object models of common field devices, including definitions of their associated algorithms and communications behavior visible through the communication system. Most notable of these efforts are the EPRI sponsored MMS Forum Working Groups, the Substation Integrated Protection, Control, and Data Acquisition (RP3599) project, and the Substation Automation Pilot Project (DAPP) for City Public Service of San Antonio. The results of these efforts are contained in the Generic Object Models for Substation and Feeder Equipment (GOMSFE). Agreement has been reached for a number of basic field devices. Examples include basic RTU, Switch, Voltage Regulator/Tap Changer, Recloser, and Capacitor Bank Controllers. The development of models for other substation and feeder automation field devices will be ongoing.

Modeling efforts within the customer interface area are in progress. These efforts include metering and interfaces to residential and commercial customer devices. There has been active industry participation in the customer interface modeling efforts. Significant work has been accomplished as part of several UCA pilot projects, and preliminary results are available in draft form. The development of models of power plant devices is underway.

The device models developed within the UCA 2.0 effort make use of a common set of services to describe the communications behavior of the devices. A standard mapping of these services onto the UCA application layer protocol (MMS), when used in conjunction with the device models, completely specifies the detailed interoperable structure for utility field devices. The services and mapping to MMS are defined in UCA Common Application Service Models (CASM). The use of

Page 250: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-4

the CASM services within all UCA device models simplifies the integration efforts across functional areas of the utility. An added benefit is that CASM allows device models to be specified independent of the underlying protocol. This protocol independence has encouraged active participation of groups outside the UCA activities, and will simplify migration through the construction of gateways to older existing protocols. In addition, it may allow for the future expansion of the UCA protocol suite to other application protocols such as CORBA.

Finally, the UCA Profiles have been revised to meet the requirements of a number of new operating environments. The new profiles include a fully detailed reduced stack (3-layer) for use with low bandwidth and/or very small field devices, as well as additional profiles for operating in a TCP/IP network environment. The revised UCA Profiles are defined in UCA Profile Specification, Version 2.0.

Benefits of Developing UCA Device Object Models

The following discussion describes the role of object models within communication protocols. The design of a new communication protocol can be viewed as reflecting four aspects:

1. The communications network configurations and media characteristics form the physical basis of the communications system (referred to in communication terminology as Layer 1 of the OSI reference model – see UCA documents listed in Section 1.3 for a discussion of the OSI reference model), and determine the fundamental capabilities that the communication protocol must have, such as routing ability, traffic management, speed ranges, and sizes of data blocks. The configuration basically defines where one can go.

From an analogous point of view, this can be seen as equivalent to the network of turnpikes, freeways, highways, roads, streets, alleyways, dirt roads, railways, waterways, and hiking trails that make up the United States transportation system. The characteristics of these roads determine what type of traffic they will bear: tractor-trailers should not typically use alleyways and dirt roads; backpackers and cowboys on horses should avoid freeways.

2. The transport protocol profile determines the means for getting data from one location to another. In communication terminology, the transport profile defines which of the protocols in Layers 2 through 4 of the OSI reference model will be used. The transport profile basically answers the question of how to get from one place to another.

As an analogy, the transport profile can be seen as the vehicle (car, truck, boat, train, horse) for getting from one location to another. A parcel delivery service could establish a combination of truck and train for getting overnight parcels delivered between two major cities.

3. The application protocol profile determines the characteristics for when the data will go and in what form the data will be in. In communication terminology, the application profile defines which of the protocols in Layers 5 through 7 of the OSI reference model will be used.

As an analogy, the application profile can be seen as decisions by a manufacturer to send a product on Tuesday morning, packaged in wooden crates, for overnight delivery by a parcel delivery service.

Page 251: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-5

4. The object definitions determine the meaning of the data being sent. Object definitions basically answer the question of what the data means. Object models are groups of objects used to define all relevant aspects of the entity that is being modeled. These object models are not defined in the OSI reference model, and can therefore be viewed not as strictly part of communication protocols but more as part of data protocols.

As an analogy, object definitions can be seen as the information on the product sent by the manufacturer: what the product is used for, its size and weight, its version number, its default factory settings, the associated manuals, etc. The object model is the entire group of objects describing the product.

Object models are a relatively new concept in the field of communication protocols, and, in fact, go beyond the typical understanding of what a communication protocol covers. In the past, only the bits and bytes necessary for transmitting data between locations were standardized; no one considered standardizing the meanings of the data. Essentially, it was too complex an undertaking to develop models of devices before even the communications protocol infrastructures were developed. Therefore, until recently, most of the effort in developing communication protocols has focused on the first three aspects: namely the infrastructure and basic mechanisms for sending data between systems; very little effort went into defining what the data represented: after all, if you can’t get the data there in the first place, it doesn’t matter what it means.

But now, many communication protocol standards do exist for the transport and application profiles, which can handle most network configurations. New profiles are usually just variations on existing profiles to handle specific situations. Therefore, the standardization efforts are increasingly on developing methods for determining what the data means – that is, developing the data protocols.

In the utility SCADA world, traditionally, data were separated into status points, analog point, and control commands, but no attempt was made to standardize the meaning of the data. However, during the development of UCA, the developers realized that it was equally, if not more, important to define the meaning of the data being exchanged, so that systems could start communicating without lengthy and often error-prone manual entry of data meanings on each side of a communications link.

In the mean time, object-oriented technology has evolved to the point that it is now better-understood, more efficient, and very effective for describing data. Therefore, the developers of UCA expanded from the original scope of defining only the UCA communications profiles, to defining an object-modeling scheme for devices.

Page 252: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-6

Some of the key benefits of object-oriented device modeling include:

1. Self-Defining Capability – In traditional SCADA systems, the SCADA subsystem that is responsible for data acquisition and control (DAC subsystem), expects to retrieve groups of undefined status and analog points from remote devices, and therefore expects to define the data itself, and map it to the SCADA real-time database. However, in the UCA model, UCA devices are self-describing. Each device, and each item of data within a device, has a standardized, “well-known”, unique name, thus making it understandable by any DAC subsystem. This self-defining capability leads to the following potential benefits:

a. Rapid Installation – When a new device is connected to the communications network, the DAC subsystem can immediately establish connection, ask the device who it is, download the list of names of objects, and set up all reporting parameters – without human intervention.

b. Minimize Manual Intervention and Transcription Errors – Because the devices are self-describing, no manual effort is needed to copy names or link database entries to data points in the field.

c. Minimize Maintenance Efforts – The SCADA database can use the same names as in the remote devices, therefore eliminating the need for a Data Administrator to laboriously map all of the data items.

d. Plug and Play Installation – When a new type of device is connected, the DAC subsystem can automatically run a “Wizard” (a program supplied with the device to aid in installation) to request any device-type specific data – or even download it from the device.

1. Interoperability – The use of UCA as a standard communication protocol permits:

a. Integration of Different Vendor Equipment – Different equipment from different vendors to be integrated over the same mainstream communications network.

b. Second Sourcing – Similar products from different vendors to be installed, thus assuring utilities of second sources.

2. Distributed Processing – Multiple DAC subsystems can access the UCA devices over the communications network, thus permitting:

a. Direct Access by (Authorized) Applications – Other systems and applications can establish their own direct communications with field devices, without having to go through the administrative and technical hassles of requesting data from the SCADA system.

b. Off-loading of SCADA systems – The SCADA system can remain dedicated to its task of monitoring and controlling the power system, and not be tied up with passing data to other systems and applications.

c. Security – UCA provides security, so no unauthorized applications can access information or issue controls.

Page 253: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-7

3. Enterprise-wide Integration – Because UCA is object oriented, device objects can be exchanged through-out the enterprise:

a. Conformance with Object Oriented Technology – UCA objects can be exchanged among control center systems, and other enterprise systems, using state-of-the-art object-oriented technologies, including conformance with the Common Information Model (CIM).

b. Conformance with Data Exchange Messaging Technology – UCA conforms to the publish-subscribe concepts of integration bus technologies, such as CORBA, Enterprise Java Beans, and Microsoft’s COM.

c. Conformance with Communication Standards – UCA utilizes standard communication profiles, thus ensuring long term support by utility and telecommunications vendors.

UCA International, The UCA Users Group

EPRI funded the startup of an industry based organization that has superseded the historical UCA /MMS forum and provides a process for the completion and maintenance of UCA based concepts and testing and certification capability for devices conformant to IEC61850. The Users Group was incorporated as a not-for-profit organization in March 2001. The name of the group is: UCA International (The UCA Users Group).

The primary objective of the User Group is: To facilitate and assist users and vendors in the commercialization of products that conform to the IEC61850 Communication Architecture. Focus is on coordination of open technical issues from several on-going projects, liaison with the IEC on 61850 documents and testing plans, liaison with the IEEE SCC 36, finalization of the draft international standards, technology transfer, the setup of test procedures for testing of devices, preparation of user oriented guideline documents and on-going maintenance of the documents and protocols. Membership in UCA International is recommended for vendors and utilities that are developing and implementing utility automation systems and desire to be at the forefront of standard communications for utility automation

Information on UCA International including tutorial material, the group charter, draft testing documents, minutes of meetings, membership lists and an invitation to join may be viewed on the Web site: www.ucainternational.org or www.ucausersgroup.org.

IntelliGrid Architecture

The IntelliGrid Architecture is the update and expansion of the original Utility Communications Architecture. The IntelliGrid Project (formerly known as IECSA) was sponsored by the Electricity Innovation Institute (E2I), a member of the Electric Power Research Institute (EPRI) family members. The IntelliGrid Project was funded by the Consortium of Electric Infrastructure to Support a Digital Society (CEIDS).

Page 254: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

A Brief History of Utility Industry Standards Development

B-8

The IntelliGrid Project has two objectives:

• Power System Functions - determining the Business Needs of power system operations requirements for the power system of today and in the future, including self-healing grid concepts.

• IntelliGrid Architecture - using these requirements as the basis for the information requirements necessary to support the envisioned power system of the future, building toward a Strategic Vision, using a Tactical Approach with migration paths and technology independent techniques, based on Standards and Best Practices. Recommendations are focused on the different users of the IntelliGrid Architecture so that they can understand and pursue their appropriate goals.

These two objectives validate that the future energy system is really an architected blend of two infrastructures: an energy delivery infrastructure and a supporting distributed computing infrastructure. This vision of two blended infrastructures maintains the view that progress is necessary within both of these infrastructures to effectively create the envisioned future energy system.

The IntelliGrid Architecture can be found at http://IntelliGrid-Architecture.com.

Page 255: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

C-1

C LISTING OF KEY INFORMATION

The following list provides the location of Key Point information in this report.

Key Technical Point

Targets information that will lead to improved equipment reliability.

Referenced Section

Page Number Key Point

2.2 2-1 Substation automation is not just the automation of a substation—it is part of a major paradigm shift for all power system operations

2.2 2-1 The first and most important effort that must be applied to the power system today is to make it a digitally controlled system.

2.3 2-4 Recognition of the fact that vast bundles of point-to-point wiring could be eliminated through the use of Ethernet networks was one of the main enablers of substation automation.

2.3 2-4 By using object-modeling technology, IEC61850 established standardized self-describing object names for substation information.

2.4 2-5 Automation leads to powerful new capabilities for users, which in turn leads to the need for more automation.

2.5 2-8 Both the power system and the information infrastructure must be designed and managed.

2.5.3 2-14 The public electric power system is now characterized as one of several critical infrastructures that must apply security practices more rigorously. Security by obscurity is no longer a safe bet.

2.5.4 2-16 In automation systems, data management is vital to ensuring that the right information is available in the right place at the right time.

2.5.5 2-17 Systems, applications, and communication networks must be actively monitored, controlled, and managed in a manner similar to the power system.

2.5.6 2-18 Communications networks also must be actively managed in order to provide the required information system reliability and, therefore, the required power system reliability.

2.5.7 2-20 Telecommunications media must be actively managed in order to provide the required reliability.

Page 256: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Listing of Key Information

C-2

Referenced Section

Page Number Key Point

4.2 4-2 In the future, it is crucial that utility engineers design substations to accommodate power system functions that have not been part of their focus in the past.

4.2 4-2 Substation automation impacts far more than the substation—it impacts planning, protection engineering, daily operations, emergency responses, market operations, maintenance, and even the work of the executives.

5.2 5-2 Abstract modeling allows the designs of complex systems to be separated into their individual simple components in an organized manner.

5.2.1 5-2 Historically, the polyglot of different communication protocols has created a terrible management problem.

5.2.2 5-3 IEC61850 is an international standard based on object-modeling technologies that are crucial to achieving true interoperability.

5.4.1 5-5 Abstraction, the focus on relevant details while ignoring others, is a key to learning and communicating. Modeling is a method of visualizing that abstraction.

5.4.1 5-6 The key benefit of using unified modeling language (UML) is that it provides structured methods for visualizing complex interactions that must be implemented in an invisible cyber world.

5.4.2 5-6 A use case is usually the first (and often the only) description of a function, because it draws a picture of the interrelationships of the key elements at the highest levels.

6.2.2 6-4 Object models are nouns with predefined names and data structures. They are the models of the data that will be exchanged. OM-SA defines the object models for substation automation.

6.2.3 6-8 Communication services are verbs. They provide the actions that actually perform the exchange of data.

6.2.4 6-14 Abstract objects and services must be mapped to real-world bits and bytes—in other words, into actual communication protocols.

6.2.5 6-15 Abstract configuration languages provide a mechanism for describing how real-world components are actually connected to each other. Two such configuration languages have been defined to date in the utility industry—SCL and CIM.

6.2.6 6-17 The common information model (CIM) is an abstract model that represents all of the major power system objects in an electric utility enterprise, focusing on power system connectivity, but including some organizational and ownership aspects as well.

Page 257: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850
Page 258: SAS EPRI Guidelines for Implementing Substation Automation Using IEC 61850

EPRI • 3412 Hillview Avenue, Palo Alto, California 94304 • PO Box 10412, Palo Alto, California 94303 • USA800.313.3774 • 650.855.2121 • [email protected] • www.epri.com

© 2004 Electric Power Research Institute (EPRI), Inc.All rights reserved. Electric Power ResearchInstitute and EPRI are registered service marks of the Electric Power Research Institute, Inc.EPRI. ELECTRIFY THE WORLD is a service mark of the Electric Power Research Institute, Inc.

Printed on recycled paper in the United States of America

Program: 1008688

Substations

About EPRI

EPRI creates science and technology solutions forthe global energy and energy services industry.U.S. electric utilities established the Electric PowerResearch Institute in 1973 as a nonprofit researchconsortium for the benefit of utility members, theircustomers, and society. Now known simply as EPRI,the company provides a wide range of innovativeproducts and services to more than 1000 energy-related organizations in 40 countries. EPRI’smultidisciplinary team of scientists and engineersdraws on a worldwide network of technical andbusiness expertise to help solve today’s toughestenergy and environmental problems.

EPRI. Electrify the World

Export Control RestrictionsAccess to and use of EPRI Intellectual Property is grantedwith the specific understanding and requirement thatresponsibility for ensuring full compliance with all applicableU.S. and foreign export laws and regulations is beingundertaken by you and your company. This includes anobligation to ensure that any individual receiving accesshereunder who is not a U.S. citizen or permanent U.S.resident is permitted access under applicable U.S. and foreignexport laws and regulations. In the event you are uncertainwhether you or your company may lawfully obtain access tothis EPRI Intellectual Property, you acknowledge that it isyour obligation to consult with your company’s legal counselto determine whether this access is lawful. Although EPRImay make available on a case by case basis an informalassessment of the applicable U.S. export classification forspecific EPRI Intellectual Property, you and your companyacknowledge that this assessment is solely for informationalpurposes and not for reliance purposes. You and yourcompany acknowledge that it is still the obligation of you andyour company to make your own assessment of theapplicable U.S. export classification and ensure complianceaccordingly. You and your company understand andacknowledge your obligations to make a prompt report toEPRI and the appropriate authorities regarding any access toor use of EPRI Intellectual Property hereunder that may bein violation of applicable U.S. or foreign export laws orregulations.


Top Related