EPRI Guidelines for Implementing Substation Automation Using IEC 61850

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

Technical Report

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

1008688

Final Report, December 2004

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

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.

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.

iii

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-ofthe-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.

v

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)

vi

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

vii

2.5.7

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

3 PROJECT MANAGEMENT FOR SUBSTATION AUTOMATION ........................................ 3-1 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

3.3

3.2.4.1

Objectives and Priorities ............................................................................. 3-4

3.2.4.2

Migration Strategy ...................................................................................... 3-5

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

Team Composition ..................................................................................... 3-8

3.4.1.2

Responsibilities .......................................................................................... 3-8

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

3.5

Project Management Team............................................................................... 3-7

3.4.1.1 3.4.2

viii

Strategic Approaches ....................................................................................... 3-3

Technology Team............................................................................................3-19

3.4.4.1

Technology Team Composition .................................................................3-20

3.4.4.2

Technology Team Responsibilities ............................................................3-20

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

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.6

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

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

ix

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

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

x


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

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.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 IntraSubstation 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 IntraSubstation 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 IntraSubstation 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 4.3.6

Description of the Function – DAC Functional Requirements for SCADA Systems .......................................................................................4-32

Energy Management System Information Requirements in the IntraControl 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

xi

4-23

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

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

xii


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

6 IMPLEMENTING IEC61850 IN EQUIPMENT AND SYSTEMS ............................................ 6-1 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

xiii

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


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

xiv

Key Testing Definitions ....................................................................................7-14

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

xv

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

xvii

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

xviii

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

xix

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

xx

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.

1-1

An Overview of IEC61850 Substation Automation Guidelines

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

1-2

Figure 1-1 Audience for Each Section of the SA Guidelines

1-3



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 objectmodeling 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

1-4


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.

1-5


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.

1-6


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. 1-7


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.

1-8


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

1-9


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

1-10


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.

1-11


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.

1-12

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 2-1


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.

2-2


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) 2 made the following comments : 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.

2-3


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 wellestablished 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. •

2-4

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 processoriented proprietary names and databases because the control center application is processoriented and logical devices of the substation are, therefore, hidden.


•

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 3 Windows 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.

2-5


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. 2-6


– 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 2-7


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.

2-8


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.

2-9


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 2-10


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.

2-11


•

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.”

2-12


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.

2-13


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

2-14


•

•

•

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

2-15


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

2-16


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

2-17


•

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.

2-18


•

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.

2-19

The Vision for Substation Automation 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 mediaspecific 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.

2-20


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

2-21

3 PROJECT MANAGEMENT FOR SUBSTATION AUTOMATION

3.1


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 3-1

Project Management for Substation Automation

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 3-2


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-ofconcept 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 3-3


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.

3-4


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 3-5


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

3-6


•

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.

3-7


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.

3-8


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.

3-9


•

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. 3-10


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:

•

Provide design inputs and critique the system design

•

• •

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

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

•

Ensure that the system design plan is followed during implementation

Protection, SCADA, automation, and communications engineering

•

Implement the system design plan, (purchasing through commissioning)

Departmental personnel who must execute the design

•

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.

3-11


•

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

3-12


•

–

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).

3-13


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.

3-14


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. 3-15


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, nearworst-case scenario must be developed with plausible justification for its choice.

3-16


–

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 3-17


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.

3-18


•

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. 3-19


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.

3-20


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.

3-21


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, 3-22


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.

3-23


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


3.

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


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 3-24


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.

3-25


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-toapple” 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.

3-26


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.

3-27


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).

3-28


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.) 3-29


•

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.

3-30

Project Management for Substation Automation Table 3-3 Risk Mitigation Techniques Project Cycle Initiation

Risk/Uncertainty Lack of information

Mitigation Technique Champion/management buy-in

Difficulty in gaining departmental support Lack of the appropriate staff SA (project) new to the utility Definition/scope project charter

Incomplete analysis

Formal cost/benefit analysis

Mismatch among objectives, budget, implementation plan, and benefits

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

Apply rigid change control

Technical risk

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.

3-31


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.

3-32


•

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-topoint, 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-topeer over the substation LAN to achieve very sophisticated capabilities.

3-33


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.

3-34


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.

3-35


•

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

3-36


•

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.

3-37


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. 3-38


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.

3-39


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

3-40


•

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 timeconsuming. 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).

3-41


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. 3-42


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

3-43


•

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.

3-44


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.

3-45

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

4.1


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.

4-1

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

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.

4-2


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.

4-3

Distribution reactive power support (power factor) in the T&D interface

T&D information exchange

–

–

4-4

Prepare emergency response planning, for example, ice storm, hurricane, local outages, or system-wide blackouts

Transmission voltage management

–

S, P

S, P

S, P

S, P

S, P

Plan automation of transmission system for SCADA, equipment monitoring, and EMS

Prepare long-term contracts with distribution utilities:

S, P

S

Forecast alternatives for generation sources (probable market conditions)

Plan transmission upgrades and additions (for example, participation in ISO/RTO expansion plan)

S

Electric Power Measurements

Long term load forecast

Long-term transmission planning (1–5 years)

Transmission Operation Functions

Substation Automation Information Circuit Breakers S

S

S

S

S

S

Reclosers S

S

S

S

S

S

Load Tap Changers and Transformers S

S

S

S

S

S

Capacitor Controllers S

S

S

S

S

S

Protection S

S

S

S

S

S

Fault Indication and Location S, P

S, P

S, P

S, P

S, P

S, P

SOE and Disturbance Fault Recording S, P

S, P

S, P

S, P

S, P

S, P

Metering S

S

S

S

S

S

S

S

Logging and Archiving A

A

A

B

B

B

Substation Configuration

Codes: B = before real time; I = instantaneous signaling; M = real-time monitoring; C = real-time control or settings; A = after real-time monitoring; S = statistical analysis; P = power flow analysis; L = logging

Table 4-1 Transmission Operation Function Requirements for Transmission Planning

4.2.1 Transmission Planning Functions


Other

A, S

Equipment and line maintenance plans

Circuit Breakers

S

Schedule equipment replacement – based on contingency scenarios

S, P

S, P

S

A

S, P

S

A

S, P

S

A

S, P

S

A

S, P

S

A

S, P

S

A

S, P

S

A

S

A

S

A

B

B

B

S

S

S

A, S

Schedule equipment replacement – predictive, based on data and models

S

A, S

A

S

A, S

L

B

Schedule equipment replacement – based on age of equipment

S

S

A, S

S

S

S

B

B

S

S

A, S

Capacitor Controllers

S

S

Load Tap Changers and Transformers A, S

SOE and Disturbance Fault Recording

Schedule maintenance operations – predictive, based on data and models

S

Reclosers A, S

Fault Indication and Location B

Metering

B

S

A, S

Protection B

Logging and Archiving

Schedule maintenance operations – time-based

S

S

Consider probable generation sources

Calculate system utilization based on forecast load and equipment nameplate ratings

S

S, P


Forecast annual load

Medium-term planning (1 month to 1 year)

Prepare inventory and personnel plans based on such things as neighboring load or tie point capacity

Ensure that copies of all schematics, diagrams, and relay settings are available to field personnel


Substation Automation Information

4-5



Table 4-1 (Cont.) Transmission Operation Function Requirements for Transmission Planning


Other

Circuit Breakers

Contingencies are analyzed

Planners/operators perform load analysis of substation equipment based on data

Operators submit transmission outages and constraints to RTO/ISO

Dynamic equipment capacity – change write-up

Protection engineer to alter relay settings

Meter parameters are updated as per any market contracts

–

–

–

–

–

–

4-6

Operators determine needed transmission outages

–

B, S

B, P

B, P

B, P

B, S

Short-term generation alternatives based on annual maintenance plan and market conditions

Planned outage management:

B, S

Short-term load forecast

Operational planning (1 hour to 1 month)

B, S

B, P

B, P

B, P

S

Reclosers B, S

B, P

B, P

B, P

S

Load Tap Changers and Transformers B, S

B, P

B, P

B, P

S

Capacitor Controllers B, P

B, P

B, P

S

Protection B, C

B, P

B, P

B, P

S

S

Fault Indication and Location

S

C

B, S

B, S

S

L

L

L

L

L

L

L

B

B

B

B

B

B

Electric Power Measurements S


Revise contracts with distribution utilities using actual costs as partial input

Metering

B


Schedule spare parts distribution, ensure sufficient at each site





Table 4-1 (Cont.) Transmission Operation Function Requirements for Transmission Planning


B

Other

Monitor system activity and load (current, voltage, frequency, and energy)

Monitor equipment condition (overheat, overload, battery level, and capacity)

Monitor environmental (fire, smoke, temperature, sump level) and Monitor security (door alarm, intrusion, and cyber attack)

Monitor security records (audio/video recording)

–

–

–

–

Alarms are analyzed by Intelligent Alarm Processing

SCADA announces alarms to operators

Monitor equipment state (open/close/alarm)

–

SCADA system monitors transmission system:

Real-time normal operator actions (using SCADA/EMS)


Substation Automation Information Electric Power Measurements M, P

M

M

M

Circuit Breakers M, P

M

M

M

Reclosers M, P

M

M

M

Load Tap Changers and Transformers M, P

M

M

M

M

Capacitor Controllers M, P

M

M

M

Protection M, P

M

M

M

Fault Indication and Location M, P

M

M

M

SOE and Disturbance Fault Recording M, P

M

M

M

M

Metering M

Logging and Archiving L

L

L

L

L

L

M

4-7



Table 4-2 Transmission Operation Function Requirements for Normal Real-Time Operations

4.2.2 Normal Real-Time Transmission Operation


M

M

Other

Automated work management system

Fault records and SOEs to protection engineers

Info to billing dept. re: possible refunds or reliability contract

External security or emergency response teams

–

–

–

–

4-8

M

Automation applications perform normal load management, for example, for “peak shaving” or alleviating temporary overloaded equipment

M

M

Supervisory control

–

M

A

A

A


Automation applications control voltage, var and power flow based on objectives set by operators, using algorithms, real-time data, and network-linked capacitive and reactive components

Manual switching

–

Operators perform supervisory control of switching operations:

Overloads and replacement issues to maintenance engineer

–

Distribution of alarms to non-operators:


Substation Automation Information Circuit Breakers M, C

M, C

M, C

M

A

A

A

A

Reclosers M, C

M, C

M, C

M

A

A

A

A

Load Tap Changers and Transformers M, C

M, C

M, C

A

A

A

Capacitor Controllers M, C

M, C

M, C

A

A

A

Protection M, C

M, C

A

A

A

A

Fault Indication and Location A

A

A

A

SOE and Disturbance Fault Recording A

A

A

A


L

L

L

L

L

L

L

L

Substation Configuration Metering


Table 4-2 (Cont.) Transmission Operation Function Requirements for Normal Real-Time Operations


Other

Application tuning parameters

Other

–

–

Prepare for transformer clipping (for example, solar wind/solar magnetic disturbance raising ground DC offset)

M

Contingency list

–

Operators prepare for storm conditions based on weather data and history and change alarm thresholds

Manual initiations

–

M

M

Event triggers

–


Operators prepare for storm conditions, based on weather data and history, and change recloser and protection settings

Periodicity of real-time sequence/cold Initiation

–

Operators change setup/options of EMS functions:


Substation Automation Information Circuit Breakers M

M

M

Reclosers M

M, C

M

Load Tap Changers and Transformers M

M, C

M

Capacitor Controllers M

M, C

M

Protection M

M, C

M

Fault Indication and Location M, S

M

SOE and Disturbance Fault Recording S

M, S

M


L

L

L

L

L

L

L

L

4-9





M

M

Other

M

M M M

EMS system performs contingency analysis, recommends preventive and corrective actions, and executes upon operator authorization

EMS system perform real-time voltage stability analysis of network conditions

EMS system performs optimal power flow analysis, recommends optimization actions, and executes upon operator authorization

EMS system perform real-time transient stability analysis of network conditions

4-10

M


EMS system performs real-time sequence of model update, state estimation, and bus load forecast

Power system analysis during normal real-time operations


Substation Automation Information Circuit Breakers M

M

M

M

M

Reclosers M, C

M, C

M, C

M, C

M


M, C

M, C

M, C

M


M, C

M, C

M, C

M

Protection M, C

M, C

M, C

M, C

Fault Indication and Location M

M

M

M

M

SOE and Disturbance Fault Recording M

M

M

M


L

L

L

L





Other

Transmission dynamic limits: stability, thermal, and voltage

Distribution dynamic limits: load stability and emergency voltage quality limits

–

–

Real-time security assessment

Generation and load balance assessment

Inter-area power flow analysis

Power flow optimization

Generation dispatch optimization

Integration with market models

–

–

–

–

–

–

Real-time Fast Simulation and Modeling (FSM):

Generator withstand capabilities for over- and under-frequency conditions

–

Real-time assessment of power system tolerances and margins:

Emergency Control System Emergency/Prevention Operations


Substation Automation Information Electric Power Measurements M

M

M

M

M

M

Circuit Breakers M

M

M

M

M

Reclosers M

M

M

M

M

C

Load Tap Changers and Transformers M

M

M

M

M

Capacitor Controllers M

M

M

M

M

Protection M

M

C

SOE and Disturbance Fault Recording S

S


L

L

L

L

4-11

B




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

4.2.3 Emergency Real-Time Transmission Operation


M

M

M

M

M

M

M

Other

Pre-arming of fast load/generation shedding for different triggers (real-time)

Protection actions for fast load/generation shedding (immediate time)

Secure, adaptive restoration of loads and generation (real-time)

–

–

–

Time synchronization of separation operations

Respecting the time-frequency zone constraints and voltage limits

Load and generation balancing in islands: adaptive underfrequency load shedding, adaptive load restoration, and fast and accurate generation balancing

–

–

–

4-12

Coordination of load-generation balances with generation tolerances

–

Real-time determination of remedial islanding upon insecure transmission operating conditions:

Determination of triggers for fast load/generation shedding (FSM study)

–

Real-time determination of Remedial Action load and generation shedding upon insecure transmission operating conditions:


Substation Automation Information Electric Power Measurements M

M

M

M

B

Circuit Breakers I, M, C

I

M, C

I

Reclosers I, M, C

I

M, C

I

C


M

M, C


M

M, C

Protection I, M, C

I

I

C

Fault Indication and Location I

I

I

SOE and Disturbance Fault Recording I

I, M

M

M

I


L

L

L

L

L

L

M



Table 4-3 (Cont.) Transmission Operation Function Requirements for Emergency Real-Time Operations


M

Other

Determination of synchronization points

Return to normal

–

–

Recovery from voltage or frequency-based load shedding

LTC control/blocking

–

–

M

M

M

Emergency operations performs under/over-voltage load shedding (both from relaying or operator control)

Emergency operations performs conditional localized load shedding in response to the following:

M

Protection actions between substations

–

M

M

M


Emergency operations performs under/over-frequency load/generation shedding (both from relaying or operator control)

Protection actions within a substation

–

Power system protection reacts to power system faults:

Substation protection system emergency operations

Determination of the conditions for restoration

–

Restoration of power system integrity:


Substation Automation Information Circuit Breakers I, M, C

I, M, C

I, M, C

I, M, C

I, M, C

I, M, C

I, M, C

I, M, C

I

I

M, C

M

M

Reclosers

I

I

M, C

M

M

Load Tap Changers and Transformers I, C

M, C

M


M

Protection I

I

I

I

I

I

C

C

M

Fault Indication and Location I

I

I

I

I

I

M

M

M


M

M

M

M

M

M


L

L

L

L

L

L

M

M

4-13

C

M





Other

Series compensation control

System separation detection

Wide area real time instability recovery

–

–

–

M

Operators dispatch field crews for restoration

M

Centralized alarm reduction based on events from multiple substations

–

SCADA system performs disturbance monitoring analysis (including fault location)

4-14

M

Local alarm reduction within substation

–

M

M

SCADA/EMS aids operators in locating fault

SCADA system performs intelligent alarm processing:

M

M

M

M

M


Operators respond manually to emergency alarms

Control center emergency operations

Shunt control

–



M, C

M, C

M, C

M, C

M, C

I, M, C

I, M, C

I, M, C

I, M, C

Reclosers M, C

M, C

M, C

M, C

M, C

M, C

I, M, C

I, M, C

I, M, C

I, M, C


M, C

M, C

M, C

M, C

M, C


M, C

M, C

M, C

M, C

M, C

Protection M

M

M

M

M

M

I

I

I

I


M

M

M

M

M

I

I

I

I


M

M

M

M

M

M

M

M

M


L

L

L

L

L

L

L

L

L





Other

Emergency load re-balancing between T/D substations by feeder reconfiguration

Activation of interruptible/curtailable load

Activation of direct load control

Activation of distributed resources

Activation of other load management functions

–

–

–

–

–

Operators performs system restorations based on system restoration plans prepared (authorized) by operation management

Emergency voltage and var control for providing dispatchable real and/or reactive loads

–

M

M

M

M

M

M

M

M

SCADA/EMS performs pre-arming of fast acting emergency automation

SCADA/EMS generates signals for emergency support by distribution utilities (according to the T&D contracts):

M


SCADA/EMS performs dynamic limit calculations for transformers and breakers based on real time data from equipment monitors



M, C

M, C

M, C

M, C

M, C

M, C

M, C

M, C

Reclosers M, C

M, C

M, C

M, C

M, C

M, C

M, C

M, C

M, C


M, C

M, C

M, C

M, C

M, C

M, C

M, C

M, C


M, C

M, C

M, C

M, C

M, C

M, C

M, C

M, C

Protection M

M

M

M

M

M

M

M

M


M

M

M

M

M

M

M

M


M

M

M

M

M

M

M

M


L

L

L

L

L

L

L

L

4-15





Other


Circuit Breakers

Reclosers

Load Tap Changers and Transformers

S

Capacitor Controllers S

S

S

M

Based on age of equipment

Based on predictive models driven by real-time data

–

–

4-16

Periodic (time-based) maintenance

–

Substation and line maintenance including operation blocking:

Power system equipment maintenance

A

S

S

A

S

A

S

A

S

A

S

A

S

A

S

A

S

A

S

S

A

S

S

L

S

Protection

Meters are read

S


M

S


Engineers and auditors research information from these logs and reports A

Metering

L


All systems archive logs and reports in searchable databases

Post operations



A

S

S



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

4.2.4 Post Real-Time Transmission Operation


Other

Maintenance staff provides information for updating relevant databases

Maintenance staff access substation drawings electronically

–

–

Electric Power Measurements A A

Operators and SCADA/EMS personnel perform periodic training by using the Operator Training Simulator

Operators and SCADA/EMS personnel participate in advanced education programs

Operator and SCADA/EMS personnel training

SCADA/EMS personnel perform diagnostics of the SCADA/EMS systems

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

A

L

L

A

A

4-17

A

A

A

A

Capacitor Controllers A

Protection

SCADA/EMS personnel update interfaces with other systems

A

Load Tap Changers and Transformers A


A

A

M


SCADA/EMS personnel update operator interfaces

A

Reclosers M

Metering

A

A

Circuit Breakers M


SCADA/EMS personnel update EMS applications

SCADA/EMS personnel update SCADA/EMS databases

SCADA/EMS Maintenance

Request that operator block reclosing for maintenance purposes

–

Maintenance staff maintain transmission lines:





Table 4-4 (Cont.) Transmission Operation Functions Requirements for Post Real-time Operations


A

A

A

A

Other

4-18

Construction personnel access substation drawings electronically

Construction personnel provides information for updating relevant databases - from the site / online

Construction managers manage crew assignments

Construction managers plan construction projects

Construction managers manage assets

Construction management

Engineering staff provides information for updating relevant databases - from site / online

A

A

S

Transmission engineers perform transmission line engineering

A

S

Needs data: line/equipment capacity, relay specs, PT/CT ratios, fault records, SOE data, event info (relay 'targets' which element picked up)

–

A


Substation engineers perform substation engineering

Duties: base case, fault studies, relay settings, protection coordination, fault analysis

–

Protection engineers perform protection engineering:

Engineering


Substation Automation Information Circuit Breakers A

A

C

S

S

A

A

Reclosers A

A

C

S

S

A

A

Load Tap Changers and Transformers A

A

C

S

S

A

A

Capacitor Controllers A

A

C

S

S

A

A

Protection A

A

C

S

S

A

A

Fault Indication and Location A

A

C

S

S

A

A

SOE and Disturbance Fault Recording A

A

C

S

S

A

A

Metering A

A

C

S

S

A

A

Logging and Archiving A

A

C

S

S

A

A

A

A

A

C

S

S

A

A





A

A

S

S

A

A

Other

–

To be decided

Black start:



4-19

Substation Configuration Logging and Archiving Metering



Protection

Capacitor Controllers

Load Tap Changers and Transformers

Reclosers

Circuit Breakers





Other


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

4-20


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.

4-21

4-22

Figure 4-2 Data Acquisition and Control for Distribution Operations (UML Use Case)



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.

4-23


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 IntraSubstation 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

4-24


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

4-25


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 IntraSubstation 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.

4-26


4.3.4.2

Environments of the Function – Deterministic Rapid Response IntraSubstation 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.

4-27


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

4-28


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

4-29


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



•

ISO/IEC 18014-1:2002 Time-Stamping Services - Information technology Security Techniques - Part 1: Framework - Quality of Service, Security, Data Management

•


•


•

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

4-30

•

FIPS 197 for Advanced Encryption Standard (AES) - Security

•


•

FIPS 186 Digital Signatures Standard (DSS) - Security

•

Intrusion Detection Technologies - Security, Network Management

•

Intrusion Prevention Systems (IPS) - Security, 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

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

•


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).

4-31


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)

4-32


•

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 IntraControl 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.

4-33


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. 4-34


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-transmissiondistribution-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-

4-35


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.

4-36


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

4-37


•

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

4-38

•

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

•

XSLT - Data Management

•

XQuery - Data Management

•

ANSI/ISO/IEC 9075 - Structured Query Language (SQL) - Data Management



•

ISO/IEC 18014-1:2002 Time-Stamping Services - Information technology Security Techniques - Part 1: Framework - Quality of Service, Security, Data Management

•


•


•

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 •


•

Intrusion Detection Technologies - Security, Network Management

•

Intrusion Prevention Systems (IPS) - Security, 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

•

AGA-12 Cryptographic Protection of SCADA Communications General Recommendations - Security

4-39


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

•


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

4-40


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 nonSCADA 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.

4-41


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

4-42


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.

4-43


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 4-44


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

4-45


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

4-46


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

4-47

5 SPECIFYING FUNCTIONAL REQUIREMENTS AND IEC61850 FOR SUBSTATION AUTOMATION

5.1


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.

5-1

Specifying Functional Requirements and IEC61850 for Substation Automation

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. 5-2


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.

5-3


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.

5-4


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.

5-5


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 nonsoftware 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 5-6


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.

5-7


Figure 5-1 UML Use Case – Implementing Substation Automation

5-8


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.

5-9


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 prespecified 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.

5-10


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 clientserver 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 humanmachine 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. 5-11


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

5-12


•

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.

5-13


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.

5-14


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. 5-15

6 IMPLEMENTING IEC61850 IN EQUIPMENT AND SYSTEMS

6.1


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).

6-1


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.

6-2


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) 6-3


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.

6-4


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.

6-5


•

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.

6-6


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 6-7


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.

6-8


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

6-9


•

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.

6-10


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.

6-11


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.

6-12


Courtesy of George Schimmel of Tamarack Consulting Figure 6-13 GSE Model

•

Select-before-operate control: Implements the safety mechanisms used by most switchrelated 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

6-13


•

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.

6-14


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).

6-15


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 (preconfigured) associations available; and the data that should be logged.

•

Instantiable logical node (LN) type definitions: The logical nodes as defined in IEC618507-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.

6-16


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 6-17


(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 componentbased 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.

6-18


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 threephase measurements might be implemented, one for each side of the switch.

6-19


Voltage transformer – measurement of voltage at the PT

MSQI

MHAN

MHAI

MDIF

MMXN

MMXU

TCTR


TVTR

Table 6-1 Electric Power Measurement Logical Nodes

X

Current transformer – measurement of current at the CT

X

Three-phase electrical measurements – threephase watts, vars, volt-amps, voltage, amps, power factor, impedances, and frequency, by phase-to-phase and phase-to-ground (as appropriate)

X

X

Single-phase electrical measurements – singlephase watts, vars, volt-amps, voltage, amps, power factor, impedances, and frequency, by phase-to-phase and phase-to-ground (as appropriate)

X

X

Amps measured on other side – amps measured on the other side of an open switch or breaker

X

X

Three-phase harmonics measurements – three-phase harmonics

X

X

Single-phase harmonics measurements – single phase harmonics

X

X

Sequence and imbalance measurements – sequence and imbalance measurements across phases

X

X

All three-phase measurements – all three-phase measurements at one location, on both sides of a device

6

6

X

X

X

X X

X

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.

6-20


X

TVTR

SIMG

CILO

RSYN

RBRF

RREC

CSWI

X

TCTR

X

CPOW

Switch with supervisory control – Switches that can be operated through supervisory control.

SPDC

X

SARC

Switch – Switches with no short circuitbreaking capability such as disconnects or grounding switches.

XCBR

Switches, Circuit Breakers, and Reclosers

XSWI

Table 6-2 Switch, Circuit Breaker, and Recloser Logical Nodes

X

X

X

X

X

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

Circuit breaker with alarm monitoring – Arcs, partial discharges, and breaker failures are monitored.

X

X

Circuit breaker with lockout – Lockout prevents or enables switching operation.

X

X

Circuit breaker with point-on-wave tripping capability – The circuit breaker operates only at a specific point on the waveform.

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

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

X

6-21


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.

6-22


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 Automatic load tap changer controller – LTC controller combining many characteristics

ANCR

ARCO

AVCO

ATCC

YEFN

YPSH

YLTC

Transformers and Tap Changers

YPTR

Table 6-3 Transformer and Tap Changer Logical Nodes

X 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: •


•


•

MHAI or MHAN: Harmonics in a three-phase or single phase system

•


•


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.

6-23


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 Capacitor bank control – Capacitor bank with supervisory control capability

CSWI

XSWI

Capacitor Switch

XCAP

Table 6-4 Capacitor Switch Logical Nodes

X 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: •


•


•

MHAI or MHAN: Harmonics in a three-phase or single-phase system

•


•


•

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: •


•

RFLO: Fault locator

•

RDRE, RDRS, RBDR, RADR: Disturbance recording

•

RSYN: Synchronization checking

6-24

PTEF

PZSU PDIS X X X

X

X

PTUC

PTOC

X

Stator thermal overload (49S)

Instantaneous overcurrent or rate of rise (50)

X

X

Rotor thermal overload (49R)

X

PTOV X

X

PTTR

Thermal overload (49)

Phase sequence voltage (47)

Reverse phase or phase balance current (46)

X

X

PSCH

Loss of field/under excitation (40)

X

PDOP X

X

PDUP

Undercurrent/under power (37)

Undervoltage (27)

Volt per Hz (24)

Distance (21)

Zero speed and under speed (14)

Transient earth fault

(IEEE C37.2 Ref)

Protection Functions PVPH

Table 6-5 Protection Functions Logical Nodes PTUV

PIOC X


RPSB

6-25

RDIR X

PZSU

PMSS PMRI

PHAR

PDIR

PDIF

PFRC

PTUF

PTOF

PPAM

PHIZ

PUPF

POPF

PVOC

PDIS

PZSU

PTEF

X X X X

X

Stator earth fault (64S)

Intertum fault (64W)

AC directional overcurrent (67)

Directional earth fault (67N)

DC time overcurrent (76)

6-26

Phase angle or out-ofstep (78)

X

Rotor earth fault (64R)

Earth fault/ground detection (64)

X

PSCH

Voltage or current balance (60)

PVPH

X

PDUP

DC overvoltage (59DC)

PTUC

X

X

PTOC X

PTOV

Time overvoltage (59)

Power factor (55)

Voltage controlled/dependent time overcurrent (51V)

AC time overcurrent (51)

(IEEE C37.2 Ref)

Protection Functions PTUV

Table 6-5 (Cont.) Protection Functions Logical Nodes PDOP


PVOC X

POPF X

PUPF X

PHIZ X

PPAM X

RDIR X

X

X

PZSU

RPSB

PMSS

PMRI

PHAR

PDIR

PDIF

PFRC

PTUF

PTOF

PIOC

PTTR

PTOF PTUF

PDIS

PZSU

PTEF

X

Zero speed or under speed

Power swing detection/blocking

Motor startup (49R, 66,48, 51LR)

X

PSCH

Generator differential (87G)

PDOP

X

PDUP

Motor differential (87M)

PTUC

X

PTOC

Busbar (87B)

PTOV

X

PTTR

Differential transformer (87T)

PIOC

X

PVOC

Restricted earth fault (87N)

POPF

X

PUPF

Differential line (87L)

PHIZ

X

PPAM

Phase comparison (87P)

X

PFRC X

X

PDIF

Differential (87)

Frequency (81)

(IEEE C37.2 Ref)

Protection Functions PVPH

Table 6-5 (Cont.) Protection Functions Logical Nodes PTUV


PDIR X

PHAR X

PMRI X

PMSS X

RPSB RDIR

6-27

X

X

PZSU


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

6-28

Function

Logical Node

Logical Node

24

Volts per hertz

PVPH

27

Phase undervoltage

PTUV

27X

Auxiliary undervoltage

PTUV

50/87

Instantaneous differential overcurrent

PIOC

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

PDIF


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


PTUV

50BF

Breaker failure

PIOC

50DD

Current disturbance detector

PIOC

50G


PIOC

50N


PIOC

50P


PIOC

50_2

Negative sequence instantaneous overcurrent

PIOC

51G


PTOC

51N


PTOC

51P


PTOC

51_2

Negative sequence time overcurrent

PTOC

52

Ac circuit breaker

XCBR

59N

Neutral overvoltage

PTOV

59P

Phase overvoltage

PTOV

59X


PTOV

59_2

Negative sequence overvoltage

PTOV

67N


PTOC

67P


PTOC

67_2

Negative sequence directional overcurrent

PTOC

68

Power swing blocking

RPSB

78

Out-of-step tripping

PPAM

79

Automatic recloser

RREC

6-29


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

6-30

Function

Logical Node

25

Synchrocheck

RSYN

27P

Phase undervoltage

PTUV

27X


PTUV

32

Sensitive directional power

PDOP

50BF

Breaker failure

PIOC

50DD

Current disturbance detector

PIOC

50G


PIOC

50N


PIOC

50P


PIOC

50_2

Negative sequence instantaneous overcurrent

PIOC

51G


PTOC

51N


PTOC

51P


PTOC

51_2

Negative sequence time overcurrent

PTOC

52

Ac circuit breaker

XCBR

59N

Neutral overvoltage

PTOV

59P

Phase overvoltage

PTOV

59X


PTOV

59_2


PTOV

67N


PTOC

67P


PTOC

67_2

Negative sequence directional overcurrent

PTOC

79

Automatic recloser

RREC

81O

Over frequency

PTOF

81U

Under frequency

PTUF

Logical Node

PDUP


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

21P

Phase distance

PDIS

24

Volts per hertz

PVPH

25

Synchrocheck

RSYN

27P

Phase undervoltage

PTUV

27TN

Third harmonic neutral undervoltage

PTUV

27X


PTUV

32


PDOP

40

Loss of excitation

PDUP

46

Generator unbalance

PTOC

50G


PIOC

50N


PIOC

50P


PIOC

50/27

Accidental energization

PIOC

51G


PTOC

51P


PTOC

59N

Neutral overvoltage

PTOV

59P

Phase overvoltage

PTOV

59X


PTOV

59_2


PTOV

64TN

100% stator ground

PTOC

67N


PTOC

67P


PTOC

68

Power swing blocking

RPSB

78

Out-of-Step Tripping

PPAM

81O

Over frequency

PTOF

81U

Under frequency

PTUF

87S

Stator differential

PDIF

Logical Node PSCH

PDUP

PTUV

6-31


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

6-32

Function

Logical Node

27P

Phase undervoltage

PTUV

27X


PTUV

32


PDOP

46

Generator unbalance

PTOC

47

Phase sequence voltage

PTOV

49

Thermal overload

PTTR

50G


PIOC

50P


PIOC

51G


PTOC

59N

Neutral overvoltage

PTOV

59P

Phase overvoltage

PTOV

59X


PTOV

59_2


PTOV

87S

Stator differential

PDIF

Logical Node

PDUP


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.

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 Disturbance recording system – A complete system that includes all of the previously listed capabilities

RDRS

RBDR

RADR

Disturbance Recording

RDRE

Table 6-12 Disturbance Recording Logical Nodes

X

M

M

M

1

6-33


6.3.7 Metering Logical Nodes Metering logical nodes, which handle the reading of meters, are shown in Table 6-13.

Three-phase metering – Calculation of energy in a three-phase system

MSTA

M???

Metering

MMTR

Table 6-13 Metering Logical Nodes

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.

Archiving – Management of archival records. Human machine interface – Management of the HMI. Alarm handling – Individual alarms can be grouped to create group warnings and alarms.

CALH

IHMI

Archiving, HMI, and Alarming

IARC

Table 6-14 Archiving, HMI, and Alarming Logical Nodes

X X 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.

6-34


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. 6-35


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.

6-36


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.

6-37

Implementing IEC61850 in Equipment and Systems Table 6-15 Basic Conformance Statement Client/ Subscriber

Server/ Publish

Value/ Comments

Client-server roles B11

Server side (of TWO-PARTYAPPLICATION-ASSOCIATION)

–

c1

Acts as a server

B12

Client side of (TWO-PARTYAPPLICATION-ASSOCIATION)

c1

–

Acts as a client

SCSMs supported B21

SCSM: IEC61850-8-1 used

MMS client over TCP

B22


Specialized sampled values

B23


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.

6-38


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. 6-39


•

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-byexception 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 highspeed 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.

6-40


•

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.

6-41

Implementing IEC61850 in Equipment and Systems 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


M3

Data

c4

c4


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

O

O

Required if buffered reports

O

O

Required if unbuffered reports

Reporting M7

Buffered report control

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

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

6-42

Implementing IEC61850 in Equipment and Systems Table 6-16 (Cont.) ACSI Models Conformance Statement Client/ Subscriber M8-8

M9

Value/ Comments

GI Logging

O

O

Required if logging

Log control

O

O

Required if logging

O

O

Required if logging

M

M

O

O

Required if GOOSE

O

O

Required if GSSE

M9-1 M10

Server/ Publish

IntgPd Log Controls

M11

Control

If GSE (B31/B32) is supported GOOSE M12-1

entryID

M12-2

DataRefInc

M13

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.

6-43


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.

6-44

Implementing IEC61850 in Equipment and Systems 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

TP

M

M

Logical device (Clause 8)

S5

LogicalDeviceDirectory

Logical node (Clause 9)

S6

LogicalNodeDirectory

TP

M

M

S7

GetAllDataValues

TP

O

M


Data (Clause 10)

S8

GetDataValues

TP

M

M

S9

SetDataValues

TP

O

O


S10

GetDataDirectory

TP

O

M


S11

GetDataDefinition

TP

O

M


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


S15

DeleteDataSet

TP

O

O


S16

GetDataSetDirectory

TP

O

O


TP

M

M

Substitution (Clause 12)

S17

SetDataValues

6-45

Implementing IEC61850 in Equipment and Systems 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


S19

SelectEditSG

TP

O

O


S20

SetSGValues

TP

O

O


S21

ConfirmEditSGValues

TP

O

O


S22

GetSGValues

TP

O

O


S23

GetSGCBValues

TP

O

O


TP

c6

c6

Required if buffered report

Reporting (Clause 14) Buffered report control block (BRCB)

S24

Report

S24-1

data-change (dchg)

S24-2

qchg-change (qchg)

S24-3

data-update (dupd)

S25

GetBRCBValues

TP

c6

C6


S26

SetBRCBValues

TP

c6

C6


6-46


AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

TP

c6

C6

Required if unbuffered Report

Unbuffered report control block (URCB)

S27

Report

S27-1

data-change (dchg)

S27-2

qchg-change (qchg)

S27-3

data-update (dupd)

S28

GetURCBValues

TP

c6

C6


S29

SetURCBValues

TP

c6

C6


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*

S32

QueryLogByTime

TP

c7

M


S33

QueryLogAfter

TP

c7

M

Required if logging*

S34

GetLogStatusValues

TP

M

M

Log

c7 – shall declare support for at least one (QueryLogByTime or QueryLogAfter).

6-47


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


S37

GetGOOSEElementNumber

TP

O

c9


S38

GetGoCBValues

TP

O

O

Recommended if GOOSE*

S39

SetGoCBValues

TP

O

O


GSSE-CONTROL-BLOCK

S40

SendGSSEMessage

MC

c8

c8

Required if GSSE

S41

GetGsReference

TP

O

c9


S42

GetGSSEElementNumber

TP

O

c9


S43

GetGsCBValues

TP

O

O

Recommended if GSSE*

S44

SetGsCBValues

TP

O

O


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


S46

GetMSVCBValues

TP

O

O


S47

SetMSVCBValues

TP

O

O


6-48


AA: TP/MC

Client/ Subscriber

Server/ Publish

Value/Comments

Unicast SVC

S48

SendUSVMessage

TP

C10

c10


S49

GetUSVCBValues

TP

O

O


S50

SetUSVCBValues

TP

O

O


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


S53

Cancel

TP

O

O

Recommended if controls*

S54

Operate

TP

M

M

Required if controls*

S55

Command-Termination

TP

M

O


S56

TimeActivated-Operate

TP

O

O


File transfer (Clause 20)

S57

GetFile

TP

O

M

Required if files*

S58

SetFile

TP

O

O


S59

DeleteFile

TP

O

O

Recommended if files*

S60

GetFileAttributeValues

TP

O

M

Recommended if files*

6-49


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

Supported time-stamp resolution

T3

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.

6-50


•

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 preconfigured 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 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.

ACSI Models

6-51


•

S48 – SendUSVMessage: See M15 – Unicast SVC in Section 6.4.2 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.

6-52

ACSI Models

7 INSTALLING IEC61850 EQUIPMENT AND SYSTEMS IN SUBSTATIONS

7.1


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 7-1


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.

7-2


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.

7-3


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.

7-4


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 7-5


•

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 7-6


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.

7-7

Installing IEC61850 Equipment and Systems in Substations 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

7.5

Summation here

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.

7-8


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 spotchecked at FAT as a reliability check because focus is on special applications. 7-9


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 selfdefining 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.

7-10

Installing IEC61850 Equipment and Systems in Substations Table 7-2 Types of Testing Type

Purpose

When

Who

Unit test

Verify proper code; standalone 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.

7-11


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 industryapproved 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).

7-12


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


Integration test


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

7-13


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 nonIEC61850 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.

7-14


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

7-15


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 Device specific extensions

Performance issues 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.

7-16


•

–

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.

7-17

Installing IEC61850 Equipment and Systems in Substations 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

RspMSG+

NORMAL

7-18

Valid control


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.

7-19

Installing IEC61850 Equipment and Systems in Substations 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

Control

Direct, with delay, by time-or-day, with security

Ctl1-5 SBOes1-7

SBONs1-5

Tm1-2

TimN1-2

Ft1-3

FileN1

Time and time synchronization File transfer

Exchanging file-oriented data

TsvPNs1-2

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.

7-20

Installing IEC61850 Equipment and Systems in Substations 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).

7-21

Installing IEC61850 Equipment and Systems in Substations 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-ofwork, 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.

7-22

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 access point

Category

Definition

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 informationmodeling 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

A-1

Glossary/Acronyms

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 CIM

A-2

General UCA

International Council on Large Electric Systems. Customer information model.

Glossary/Acronyms

Term/Acronym device

Category IEC

Definition 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 FACTS

UCA/IEC General

Device under test. 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.

A-3

Glossary/Acronyms

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 interchangeability

General IEC

Institute of Electrical and Electronic Engineers 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

A-4

Implementation under test. This term represents the entity being tested.

Glossary/Acronyms

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

General

Personal computer

PIC

UCA/IEC

PICOM

IEC

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

General

Programmable logic controller

QoS

General

Quality of Service

RP

General

Research project

SAS

IEC

Substation automation system

SCC

IEEE

Standards Coordinating Committee

SW

General

TC

IEC

TCP/IP

General

Software Technical committee Transmission control protocol/Internet protocol

TISSUES

UCA

Technical issues

TR

IEEE

Technical report

UCA

General

UPFC

UCA

Utility communications architecture (UCA is a trademark of EPRI) Unified power flow controller A-5

Glossary/Acronyms

Term/Acronym WAN

Category General

WG

UCA/IEC

Xml

General

A-6

Definition Wide area network Working group Extended markup language

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

B-1

A Brief History of Utility Industry Standards Development

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 B-2


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 B-3


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.

B-4


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 betterunderstood, 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.

B-5


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.

B-6


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 objectoriented 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).

B-7


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.

B-8

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.

C-1

Listing of Key Information 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.

C-2

Export Control Restrictions Access to and use of EPRI Intellectual Property is granted with the specific understanding and requirement that responsibility for ensuring full compliance with all applicable U.S. and foreign export laws and regulations is being undertaken by you and your company. This includes an obligation to ensure that any individual receiving access hereunder who is not a U.S. citizen or permanent U.S. resident is permitted access under applicable U.S. and foreign export laws and regulations. In the event you are uncertain whether you or your company may lawfully obtain access to this EPRI Intellectual Property, you acknowledge that it is your obligation to consult with your company’s legal counsel to determine whether this access is lawful. Although EPRI may make available on a case by case basis an informal assessment of the applicable U.S. export classification for specific EPRI Intellectual Property, you and your company acknowledge that this assessment is solely for informational purposes and not for reliance purposes. You and your company acknowledge that it is still the obligation of you and your company to make your own assessment of the applicable U.S. export classification and ensure compliance accordingly. You and your company understand and acknowledge your obligations to make a prompt report to EPRI and the appropriate authorities regarding any access to or use of EPRI Intellectual Property hereunder that may be in violation of applicable U.S. or foreign export laws or regulations.

About EPRI EPRI creates science and technology solutions for the global energy and energy services industry. U.S. electric utilities established the Electric Power Research Institute in 1973 as a nonprofit research consortium for the benefit of utility members, their customers, and society. Now known simply as EPRI, the company provides a wide range of innovative products and services to more than 1000 energyrelated organizations in 40 countries. EPRI’s multidisciplinary team of scientists and engineers draws on a worldwide network of technical and business expertise to help solve today’s toughest energy and environmental problems. EPRI. Electrify the World

Program:

1008688

Substations

© 2004 Electric Power Research Institute (EPRI), Inc. All rights reserved. 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. Printed on recycled paper in the United States of America

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

EPRI Guidelines for Implementing Substation Automation Using IEC 61850

Recommend Documents