19
IEC/PAS 62559 Edition 1.0 2008-01 PUBLICLY AVAILABLE SPECIFICATION IntelliGrid Methodology for Developing Requirements for Energy Systems INTERNATIONAL ELECTROTECHNICAL COMMISSION XF ICS 29.020 PRICE CODE ISBN 2-8318-9525-1 This is a preview - click here to buy the full publication

PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

  • Upload
    others

  • View
    9

  • Download
    0

Embed Size (px)

Citation preview

Page 1: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

IEC/PAS 62559Edition 1.0 2008-01

PUBLICLY AVAILABLE SPECIFICATION

IntelliGrid Methodology for Developing Requirements for Energy Systems

INTERNATIONAL ELECTROTECHNICAL COMMISSION XFICS 29.020

PRICE CODE

ISBN 2-8318-9525-1

This is a preview - click here to buy the full publication

Page 2: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

CONTENTS

FOREWORD ................................................................................................................................................9

EPRI DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES .............................................11

1. SCOPE AND OBJECTIVES ....................................................................................................................12

1.1 Scope of the Specification ..............................................................................................................12

1.2 Overview of the Methodology .........................................................................................................121.2.1 Concept of System Engineering ........................................................................................121.2.2 IntelliGrid System Engineering Methodology.....................................................................121.2.3 Overview of Phased Approach ..........................................................................................141.2.4 Phase 1: IntelliGrid Methodology for Executives ...............................................................151.2.5 Phase 2: IntelliGrid Methodology for Domain Experts: Modeling User

Requirements with Use Cases...........................................................................................151.2.6 Phase 3: IntelliGrid Methodology for Project Engineers: Developing Detailed

User Requirements ............................................................................................................17

1.3 Objectives of this Specification .......................................................................................................17

1.4 Audience of this Specification .........................................................................................................18

2. NORMATIVE REFERENCES..................................................................................................................19

3. DEFINITIONS AND ABBREVIATIONS ...................................................................................................21

4. GLOSSARY OF TERMS ........................................................................................................................ 21

4.1 Referenced Sources of Glossary Terms........................................................................................ 21

4.2 Terms and Definitions .................................................................................................................... 22

5. INTRODUCTION TO THE INTELLIGRID ARCHITECTURE ................................................................. 23

5.1 History and Rationale..................................................................................................................... 23

5.2 Basic Concepts .............................................................................................................................. 24

5.3 The Pyramid................................................................................................................................... 25

5.4 Business Needs and Functional Requirements............................................................................. 26

5.5 Development Phases..................................................................................................................... 27

5.6 Development Streams.................................................................................................................... 29

5.7 Scope Addressed in this Specification........................................................................................... 30

6. PHASE 1: EXECUTIVES DETERMINE BUSINESS NEEDS AND PLAN PROJECTS ........................ 326.1.1 Determine Business and Regulatory Drivers.................................................................... 326.1.2 Choose Projects................................................................................................................ 326.1.3 Identify Candidate Technologies....................................................................................... 326.1.4 Define a High-Level Business Case ................................................................................. 32

PAS 62559 © IEC:2008(E)– 2 –

This is a preview - click here to buy the full publication

Page 3: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

6.1.5 Refine Process for Your Organization ..............................................................................326.1.6 Identify Stakeholders ........................................................................................................326.1.7 Establish a Project Team ..................................................................................................336.1.8 Select Teams ....................................................................................................................33

7. PHASE 2: STAKEHOLDERS DEFINE USER REQUIREMENTS WITH USE CASES.........................35

7.1 Use Case Methodology..................................................................................................................367.1.1 Use Case Introduction ..................................................................................................... 377.1.2 Use Case Selection...........................................................................................................37

7.2 Use Case Workshops to Develop Requirements ..........................................................................377.2.1 Use Case Workshop Goals...............................................................................................377.2.2 Use Case Workshop Membership ....................................................................................387.2.3 Use Case Workshop Planning ..........................................................................................387.2.4 Use Case Workshop Agendas..........................................................................................387.2.5 Developing Requirements and Business Value................................................................397.2.6 Writing Good Requirements..............................................................................................40

7.3 Use Case Analysis .........................................................................................................................427.3.1 Global Actor List................................................................................................................427.3.2 Activity Diagrams ..............................................................................................................427.3.3 Interface Diagrams............................................................................................................447.3.4 Message Sequence Diagrams..........................................................................................447.3.5 Use Case Interaction Diagrams ........................................................................................457.3.6 Refining Requirements .....................................................................................................457.3.7 Identify Security Risks.......................................................................................................457.3.8 Distill Requirements ..........................................................................................................467.3.9 Evaluate Requirements vs. Business Case......................................................................467.3.10 Publish Requirements.......................................................................................................46

8. PHASES 3-5: TECHNOLOGY SELECTION AND DEPLOYMENT ......................................................47

8.1 Design an Architecture...................................................................................................................488.1.1 Resolve List of Actors .......................................................................................................488.1.2 Identify Messages Exchanged ..........................................................................................498.1.3 Define Interfaces...............................................................................................................498.1.4 Define Security Domains ..................................................................................................498.1.5 Define Security and Network Management Policies.........................................................498.1.6 Break Down Actors into Components ...............................................................................508.1.7 Assess Candidate Technologies.......................................................................................508.1.8 Map Candidate Technologies to Interfaces ......................................................................508.1.9 Define Integration Interfaces.............................................................................................518.1.10 Test Architecture against Use Cases................................................................................51

PAS 62559 © IEC:2008(E) – 3 –

This is a preview - click here to buy the full publication

Page 4: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

8.2 Select Technologies.......................................................................................................................518.2.1 Build Technology Capability Scales..................................................................................518.2.2 Request Proposals............................................................................................................518.2.3 Evaluate Requirements and Proposals.............................................................................538.2.4 Perform Gap Analysis ...................................................................................................... 538.2.5 Trade-Off Requirements ...................................................................................................538.2.6 Identify Missing Standards and Technologies ..................................................................538.2.7 Create Technology Roadmap ...........................................................................................538.2.8 Submit Proposals to Standards Bodies and Industry Groups ..........................................548.2.9 Complete Final Business Case.........................................................................................54

A. ANNEX A: HOW TO DEVELOP USE CASES .......................................................................................55

A.1 What is a Use Case? .....................................................................................................................55

A.2 Purpose of the IntelliGrid PAS Use Case Template ......................................................................55

A.3 IntelliGrid PAS Use Case Template: Setting the Stage .................................................................55A.3.1 Domain Expert(s) Responsible for Use Case ...................................................................55A.3.2 Name of Function..............................................................................................................56A.3.3 Scope and Objectives of Function ....................................................................................56A.3.4 Narrative of Function.........................................................................................................56A.3.5 Actors: People, Systems, Applications, Databases, the Power System, and

Other Stakeholders ...........................................................................................................56A.3.6 Legal Issues: Contracts, Regulations, Safety Rules, and Other Constraints ...................56A.3.7 Preconditions and Assumptions........................................................................................56

A.4 IntelliGrid PAS Use Case Template: A Picture is Worth a Thousand Words ................................56

A.5 IntelliGrid PAS Use Case Template: Step-by-Step Interactions within Function...........................57A.5.1 Steps Describe the Detailed Interactions..........................................................................57A.5.2 Contents of Steps..............................................................................................................57

A.6 IntelliGrid PAS Use Case Template: Characteristics of Steps.......................................................58A.6.1 Characteristics of Steps Capture Constraints and Details of User Requirements ...........58A.6.2 Configuration Issues .........................................................................................................58A.6.3 IntelliGrid Quality of Service (QoS) Issues .......................................................................62A.6.4 IntelliGrid Security Issues .................................................................................................64A.6.5 IntelliGrid Data Management Issues.................................................................................67A.6.6 IntelliGrid Constraints and Other Issues ...........................................................................71

B. ANNEX B: USE CASE TEMPLATE........................................................................................................72

B.1 Description of the User Requirements of a Function .....................................................................72B.1.1 General .............................................................................................................................72B.1.2 Domain Expert(s) ..............................................................................................................72B.1.3 Name of Function..............................................................................................................72

PAS 62559 © IEC:2008(E)– 4 –

This is a preview - click here to buy the full publication

Page 5: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

B.1.4 Scope and Objectives of Function ....................................................................................72B.1.5 Narrative of Function.........................................................................................................73B.1.6 Actors: People, Systems, Applications, Databases, the Power System, and

Other Stakeholders ...........................................................................................................73B.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints .....................................73B.1.8 Preconditions and Assumptions........................................................................................73

B.2 Drawing or Diagram of Function ....................................................................................................75

B.3 Step by Step Analysis of Function .................................................................................................76B.3.1 Steps – Normal Sequence ................................................................................................76B.3.2 Steps – Alternative, Error Management, and/or Maintenance/Backup

Sequences ........................................................................................................................77

C. ANNEX C: EXAMPLE OF TRANSMISSION SYNCHRO-PHASOR USE CASE ...................................79

C.1 Description of the User Requirements of a Function .....................................................................79C.1.1 General .............................................................................................................................79C.1.2 Domain Expert(s) ..............................................................................................................79C.1.3 Name of Function..............................................................................................................79C.1.4 Scope and Objectives of Function ....................................................................................79C.1.5 Narrative of Function.........................................................................................................79C.1.6 Actors: People, Systems, Applications, Databases, the Power System, and

Other Stakeholders ...........................................................................................................82C.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints .....................................83

C.2 Drawing or Diagram of Function ....................................................................................................84

Step by Step Analysis of Function .........................................................................................................85C.2.1 Preconditions and Assumptions........................................................................................85C.2.2 Steps – Normal Sequence ................................................................................................86C.2.3 Steps – Alternative, Error Management, and/or Maintenance/Backup

Sequences ........................................................................................................................89

EXAMPLE OF DISTRIBUTION AUTOMATION USE CASE ......................................................................91

C.3 Description of the User Requirements of a Function .....................................................................91C.3.1 General .............................................................................................................................91C.3.2 Domain Expert(s) ..............................................................................................................91C.3.3 Name of Function..............................................................................................................91C.3.4 Scope and Objectives of Function ....................................................................................91C.3.5 Narrative of Function.........................................................................................................92C.3.6 Actors: People, Systems, Applications, Databases, the Power System, and

Other Stakeholders ...........................................................................................................97C.3.7 Legal Issues: Contracts, Regulations, Policies, and Constraints ...................................100C.3.8 Preconditions and Assumptions......................................................................................101

C.4 Drawing or Diagram of Function ..................................................................................................104

PAS 62559 © IEC:2008(E) – 5 –

This is a preview - click here to buy the full publication

Page 6: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

C.5 Step by Step Analysis of Function ...............................................................................................104C.5.1 Steps – Normal Sequence ..............................................................................................104C.5.2 Steps – Alternative, Error Management, and/or Maintenance/Backup

Sequences ...................................................................................................................... 112

D. EXAMPLE OF CONSUMER USE CASE ............................................................................................. 114

D.1 Description of the User Requirements of a Function ................................................................... 114D.1.1 General ........................................................................................................................... 114D.1.2 Domain Expert(s) ............................................................................................................ 114D.1.3 Name of Function............................................................................................................ 114D.1.4 Scope and Objectives of Function .................................................................................. 114D.1.5 Narrative of Function....................................................................................................... 115D.1.6 Actors: People, Systems, Applications, Databases, the Power System, and

Other Stakeholders ......................................................................................................... 116D.1.7 Legal Issues: Contracts, Regulations, Policies, and Constraints ................................... 118D.1.8 Preconditions and Assumptions...................................................................................... 118

D.2 Step by Step Analysis of Function ............................................................................................... 120D.2.1 Steps – Normal Sequence .............................................................................................. 120D.2.2 Steps – Alternative, Error Management, and/or Maintenance/Backup

Sequences ...................................................................................................................... 125

PAS 62559 © IEC:2008(E)– 6 –

This is a preview - click here to buy the full publication

Page 7: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

Figures

Figure 1: IntelliGrid Methodology for Project Definition ...............................................................................13

Figure 2: IntelliGrid Applications ................................................................................................................ 24

Figure 3: The IntelliGrid Architecture Pyramid............................................................................................ 26

Figure 4: Phases of the IntelliGrid Development Process .......................................................................... 28

Figure 5: Streams of the IntelliGrid Development Process........................................................................ 29

Figure 6: Potential Stakeholders and Requirements Team Structure ....................................................... 33

Figure 7: The Use Case Workshop Requirements Development Process................................................. 36

Figure 8: Example of an Activity Diagram.................................................................................................. 43

Figure 9: Interface Diagram Example ........................................................................................................ 44

Figure 10: Message Sequence Diagram Example .................................................................................... 4 5

Figure 11: Requirements and Systems Architecture Process ................................................................... 47

Figure 12: Technology Selection, Business Case, and Deployment Process........................................... 48

Figure 13: Overview of the Technology Selection Process ....................................................................... 51

Figure 14: Example of a Technology Capability Measurement Scale ....................................................... 52

Figure 15: Illustrative Diagram of a Function Described in a Use Case ..................................................... 57

PAS 62559 © IEC:2008(E) – 7 –

This is a preview - click here to buy the full publication

Page 8: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

Tables

Table 1: Checklist of IntelliGrid Configuration Issues .................................................................................59

Table 2: Checklist of IntelliGrid Quality of Service Issues ..........................................................................63

Table 3: Checklist of IntelliGrid Security Issues..........................................................................................65

Table 4: Checklist of IntelliGrid Data Management Issues .........................................................................67

PAS 62559 © IEC:2008(E)– 8 –

This is a preview - click here to buy the full publication

Page 9: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

INTERNATIONAL ELECTROTECHNICAL COMMISSION ____________

IntelliGrid Methodology for Developing Requirements for Energy Systems

FOREWORD

1) The International Electrotechnical Commission (IEC) is a worldwide organization for standardization comprising all national electrotechnical committees (IEC National Committees). The object of IEC is to promote international co-operation on all questions concerning standardization in the electrical and electronic fields. To this end and in addition to other activities, IEC publishes International Standards, Technical Specifications, Technical Reports, Publicly Available Specifications (PAS) and Guides (hereafter referred to as “IEC Publication(s)”). Their preparation is entrusted to technical committees; any IEC National Committee interested in the subject dealt with may participate in this preparatory work. International, governmental and non-governmental organizations liaising with the IEC also participate in this preparation. IEC collaborates closely with the International Organization for Standardization (ISO) in accordance with conditions determined by agreement between the two organizations.

2) The formal decisions or agreements of IEC on technical matters express, as nearly as possible, an international consensus of opinion on the relevant subjects since each technical committee has representation from all interested IEC National Committees.

3) IEC Publications have the form of recommendations for international use and are accepted by IEC National Committees in that sense. While all reasonable efforts are made to ensure that the technical content of IEC Publications is accurate, IEC cannot be held responsible for the way in which they are used or for any misinterpretation by any end user.

4) In order to promote international uniformity, IEC National Committees undertake to apply IEC Publications transparently to the maximum extent possible in their national and regional publications. Any divergence between any IEC Publication and the corresponding national or regional publication shall be clearly indicated in the latter.

5) IEC provides no marking procedure to indicate its approval and cannot be rendered responsible for any equipment declared to be in conformity with an IEC Publication.

6) All users should ensure that they have the latest edition of this publication. 7) No liability shall attach to IEC or its directors, employees, servants or agents including individual experts and

members of its technical committees and IEC National Committees for any personal injury, property damage or other damage of any nature whatsoever, whether direct or indirect, or for costs (including legal fees) and expenses arising out of the publication, use of, or reliance upon, this IEC Publication or any other IEC Publications.

8) Attention is drawn to the Normative references cited in this publication. Use of the referenced publications is indispensable for the correct application of this publication.

The International Electrotechnical Commission (IEC) draws attention to the fact that it is claimed that compliance with this document may involve the use of a service mark concerning EPRISM.

Electric Power Research Institute and EPRI are registered service marks of the Electric Power Research Institute, Inc. EPRI. ELECTRIFY THE WORLD and EPRI. SHAPING THE FUTURE OF ELECTRICITY are service marks of the Electric Power Research Institute, Inc.

IEC takes no position concerning the evidence, validity and scope of this service mark right.

The holder of these service mark rights has assured the IEC that it is willing to negotiate licences under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of these service mark rights are registered with IEC. Information may be obtained from:

EPRI, 3420 Hillview Avenue, Palo Alto, California 94303 USA

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. IEC shall not be held responsible for identifying any or all such patent rights.

A PAS is a technical specification not fulfilling the requirements for a standard but made available to the public .

supply.

The text of this PAS is based on the following document:

This PAS was approved for publication by the P-members of the committee concerned as indicated in

the following document

Draft PAS Report on voting

8/1233/NP 8/1237/RVN

IEC-PAS 62559 has been processed by technical committee 8: Systems aspects for electrical energy

PAS 62559 © IEC:2008(E) – 9 –

This is a preview - click here to buy the full publication

Page 10: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

– 10 – PAS 62559 © IEC:2008(E)

Following publication of this PAS, the technical committee or subcommittee concerned will transform it into an International Standard.

This PAS shall remain valid for an initial maximum period of 3 years starting from the publication date. The validity may be extended for a single 3-year period, following which it shall be revised to become another type of normative document, or shall be withdrawn.

This is a preview - click here to buy the full publication

Page 11: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

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

PAS 62559 © IEC:2008(E) – 11 –

This is a preview - click here to buy the full publication

Page 12: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

1. Scope and Objectives

This section describes the scope, purpose and objectives of this specification and the architect-ure on which it was based.

1.1 Scope of the Specification

This Publicly Available Specification (PAS) defines a methodology for power system domain experts to determine and describe their user requirements for automation systems, based on their utility business needs. This methodology was originally developed as part of the IntelliGrid Architecture developed by the Electrical Power Research Institute (EPRI), as a means to implement the “IntelliGrid vision” of the automated, self-healing, and efficient power system of the future.

1.2 Overview of the Methodology

1.2.1 Concept of System Engineering

The IntelliGrid methodology is a subset of the science of systems engineering. Systems eng-ineering methodology separates the concepts of “user requirements” from “technical spec-ifications”: user requirements define “what” is needed without reference to any specific designs or technologies, while technical specifications define “how” to implement the automation systems in order to meet the user requirements.

1.2.2 IntelliGrid System Engineering Methodology

The overall IntelliGrid systems engineering methodology is illustrated in Figure 1 and consists of the following types of people and project steps:

Executives or other utility managers review business cases which describe and justify a perceived business need. They then approve specific projects.

Domain experts and project engineers are tasked to develop a project team to undertake the project. As one of the first undertakings of the project team, all power system experts and other stakeholders (users) that could impact or be impacted by the project should be identified and represented (full time, part time, or as applicable) on the project team.

Domain experts review the existing IntelliGrid Use Cases for applicability and ideas. These Use Cases can be found at http://intelligrid.info/IntelliGrid_Architecture/Use_Cases/IECSA_use_cases_overview.htm

Domain experts develop a list of Use Cases (functional descriptions), covering not only the specific business need but other user needs and future possibilities that could impact or might be impacted by the project.

Domain experts, with possible assistance by project engineers who understand the Use Case process, draft the key Use Cases, capturing all of the necessary user require-ments.

Domain experts review and update these Use Cases to ensure their needs are captured correctly and to assess possible misunderstandings, overlaps, holes, and other inconsistencies

IntelliGrid Methodology for Developing Requirements for Energy Systems

PAS 62559 © IEC:2008(E)– 12 –

This is a preview - click here to buy the full publication

Page 13: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

Project engineers assess and coordinate the Use Cases from which they develop a comprehensive and detailed user requirements document. This detailed user require-ments document contains only user requirements.

Information specialists apply the appropriate standards and technologies, based on the user requirements document. The strategic vision of the IntelliGrid Architecture should be used to determine the key standards and technologies.

Design engineers develop the Technical Specifications, which combine the user requirements from the domain experts, the strategic standards and technologies from the information specialists, and the tactical approach to system development recommended by the IntelliGrid Architecture.

Figure 1: IntelliGrid Methodology for Project Definition

The user requirements as elicited by the Use Case process and ultimately described in the detailed user requirements document cover:

Functions from the user perspective, including functional description of processes, user choices, types of input data, types of results, and possibly display appearance

PAS 62559 © IEC:2008(E) – 13 –

This is a preview - click here to buy the full publication

Page 14: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

Configuration issues, such as access to field data, electrically noisy substation environment, control centre LAN, or cross-organizational interactions

Performance requirements, such as availability, response times, latency, precision, frequency of updated results, and other user parameters

Security requirements, such as confidentiality, access restrictions, detection of failures and/or intrusions, failure management, and other safety, security, and failure issues

Data management requirements, such as sizes, numbers of devices, amounts of data, expected growth over time, data access methods, data maintenance, and other data management considerations.

Constraints, such as contractual, legal, regulatory, safety rules, or other issues that could impact the requirements

While a complete systems engineering methodology covers both the identification of user requirements and the development of technical specifications, this PAS addresses only the methodology for determining and documenting the user requirements.

1.2.3 Overview of Phased Approach

Although the IntelliGrid methodology covers the entire process for developing systems, this PAS focuses only on the development of User Requirements, and therefore concentrates on the first 3 phases, although it also addresses the remaining phases as they are applicable to User Requirements.

The IntelliGrid Architecture describes the overall methodology for undertaking projects consisting of the following phases, as illustrated in Figure 2.

Phase 1: Executives use Business Cases to approve projects in order to meet Business Needs. Although this step in the process involves executive decisions based on cost-justification and other non-technical factors, from the IntelliGrid Architecture point of view, the key requirement for these executives in making decisions to approve projects is that they should require all IntelliGrid Strategic Vision issues to be addressed in the Business Cases. Specifically, the Business Cases should explicitly state whether or why not the Strategic Vision issues will be part of the project, including Use Case modeling, use of abstract data models, security issues, network and system management, data management, and integration/interoperability.

Phase 2: Domain Expert Stakeholders describe their User Requirements through the formal Use Case process. Use Cases permit these experts to express their requirements in a formalized manner that can then be coordinated and solidified into more detailed functional and performance requirements in the next phase.

Phase 3: Project Engineers develop the more detailed functional and performance requirements from the Use Cases that were developed by the domain experts.

Phase 4: Project Engineers and IT Specialists assess applicability to the project of the standards, technologies, and best practices identified in the appropriate IntelliGrid Environments.

Phase 5: Design Engineers develop Technical Specifications based on Strategic Vision, Tactical Approach, & Standards

PAS 62559 © IEC:2008(E)– 14 –

This is a preview - click here to buy the full publication

Page 15: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

1.2.4 Phase 1: IntelliGrid Methodology for Executives

1.2.4.1 Step 1: IntelliGrid Recommendations for Executives

As described in the IntelliGrid Architecture report and web site, the following are the general IntelliGrid recommendations for utility executives:

Adopt the IntelliGrid Architecture as the strategic vision for the utility information infrastructure

Ensure that the different users of the IntelliGrid Architecture understand how to utilize the relevant parts of IntelliGrid Architecture products, including the power system functional descriptions and IntelliGrid Architecture Strategic Vision.

Develop a plan for implementing the IntelliGrid Architecture methods and standards-based technologies, based on the utility’s specific business needs, the timeframe appropriate for meeting those needs, and the financial constraints.

Provide feedback to EPRI and Standards Organizations so that the IntelliGrid Architecture can evolve to meet future needs and recommend standards that are created in the future.

Ensure all Business Cases explicitly state how or why not the Strategic Vision issues will be part of the project, including Use Case modeling for functions, abstract data models, security issues, network and system management, data management, and integration/ interoperability.

1.2.4.2 Step 2: Executives and Business Needs

When specific business needs are identified, executives have long used Business Cases as the method for assessing and determining which business needs can and should be met. Business Cases typically describe the business need, provide financial and organizational assessments of potential ways for meeting the business need, and recommend a specific solution with a justification for that recommendation.

As the first phase in the IntelliGrid methodology, executives (or other utility decision-makers) are expected to review the Business Cases and approve those that meet certain justification criteria (often financial payback criteria).

1.2.4.3 Step 3: Establishing a Project Team

Once the executives have approved a project to meet a business need, the first step is to develop a project team. This project team should include representatives from all of the main stakeholders, in order to ensure more useful functional requirements and to help ensure “buy-in” by these ultimate users of the function. Not all stakeholders need to be full-time members of the project team, but should always be included in any discussions that are relevant to their areas of expertise.

1.2.5 Phase 2: IntelliGrid Methodology for Domain Experts: Modeling User Requirements with Use Cases

1.2.5.1 Step 1: Identification of All Potential Stakeholders

One of the very first tasks of the project team should be to identify ALL potential stakeholders,even if some eventually do not directly participate in the project. Often they may have

PAS 62559 © IEC:2008(E) – 15 –

This is a preview - click here to buy the full publication

Page 16: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

requirements that may appear peripheral to the main project but could easily be met if designed in from the beginning.

Once identified, all of these stakeholders should have the project explained (briefly) to them, and then asked if they have any user requirements that could impact (or be impacted by) the project. They should be encouraged to think “out of the box”, to brainstorm future scenarios, and to envision new capabilities, rather than just restating existing functions. Thinking “out of the box” and generating “idealized designs” about what a stakeholder really needs can make profound changes in how businesses operate and how projects are implemented. This process can be difficult because understanding what might be possible under different conditions and technologies is very different from stating what is currently done.

Some of the new user requirements could just piggyback on the project without significant technical or financial impact while others might involve changing the overall user requirements to accommodate the new needs. Other requirements might lead to simple accommodations for future expansion of the systems being implemented so that they could handle these new, but possibly not yet justified, requirements in the future. Some brainstorming discussions might cause other stakeholders to rethink their own needs in a new way.

Although not all new user requirements would be implemented immediately, this brainstorming could lead new ways of thinking and eventually new projects to address those needs.

1.2.5.2 Step 2: Reviewing IntelliGrid Architecture Use Cases

The wheel should not be re-invented too many times. The IntelliGrid Architecture project identified over 400 functions: these could serve as a checklist or initiate new discussions on new types of functions. A few are described in more detail, using the IntelliGrid Architecture Use Case template (from which the IntelliGrid PAS Use Case template was derived). These can be reviewed also as illustrations on how Use Cases can be developed clearly and effectively to describe functions.

1.2.5.3 Step 3: Brainstorming List of Functions (Use Cases) with Stakeholders

A list of functions should be developed by the stakeholders that will capture all user requirements associated with the project area, even if some are “peripheral” to the main purpose of the project. This list of functions will ultimately be described by a set of interconnected Use Cases.

However, applying brainstorming to the Use Case process involves not only discarding old mindsets that inhibit creative thinking, but also learning how to use the Use Case process most effectively. The requirements gathering process should use an iterative and stepwise refinement-based methodology. This approach facilitates the requirements gathering process by stimulating stakeholder interest, collaborating on new ideas, and obtaining stakeholder buy-in.

In some cases, the list of functions may need to be pared down, combined, or prioritized so that the primary functions are identified.

1.2.5.4 Step 4: Drafting Use Cases

The functions identified in the list should then be drafted into a set of Use Cases. These Use Cases should be the product of domain experts, but often these experts are not experienced in Use Case concepts. Therefore, project engineers who are experienced in the Use Case process could help elicit the requirements from the domain experts.

Drafting Use Cases can also be iterative, with some Use Cases expanded and possibly split into multiple Use Cases, while others are amalgamated into one.

PAS 62559 © IEC:2008(E)– 16 –

This is a preview - click here to buy the full publication

Page 17: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

The process of developing Use Cases using the IntelliGrid PAS Use Case template is described in Annex A.

1.2.5.5 Step 5: Reviewing and Updating Use Cases

All domain experts should have a chance to review and comment on Use Cases. Some stakeholders may be more proactive than others, but care should be taken that the requirements of less active stakeholders are not lost.

Some Use Cases may end up being split into multiple Use Cases, while other Use Cases may be combined during this process. Use Cases can be updated multiple times if needed – but the decision when to stop modifying or “tweaking” a Use Case can be more of an art than a science.

1.2.6 Phase 3: IntelliGrid Methodology for Project Engineers: Developing Detailed User Requirements

1.2.6.1 Step 1: Coordinating and Combining Use Cases

Project engineers should coordinate the many Use Cases from the domain experts and possibly combine any common components into “subroutine” Use Cases, while still maintaining the unique components. The results should be reviewed by the domain experts to ensure their requirements did not get left out by accident.

In particular, project engineers should review the characteristics of common components (e.g. types of data, configuration, quality of service, security, and data management), and develop comprehensive and/or coordinated requirements across all Use Cases. For instance, they should identify the most “constraining” requirements, such as the highest level of security needed or the most rapid response requirements, so that either all elements will meet that constraint or the constrained elements are isolated from the other elements.

1.2.6.2 Step 2: Developing User Requirements from the Use Cases

Use Cases are vital to understanding the individual user requirements, but are difficult to view in combination. Therefore, once the individual Use Cases have been finalized by the domain experts and the project engineers, a single (or just a few) Functional Requirements documents should be developed that captures all of the (coordinated) user requirements. Just like the Use Cases themselves, these functional requirements address “what” is needed, but not “how” it is to be provided.

These functional requirements thus form the basis for Technical Specifications which can add additional specific technical requirements.

1.3 Objectives of this Specification

As defined by the IEC, the scope of IEC TC8 is to “prepare and coordinate, in co-operation with other TC/SCs, the development of international standards and other deliverables with emphasis on overall system aspects of electricity supply systems and acceptable balance between cost and quality for the users of electrical energy. Electricity supply system encompasses transmission and distribution networks and connected user installations (generators and loads) with their network interfaces.”

IEC TC8 is therefore developing this PAS to with the following objectives:

To develop a standard methodology for determining and defining user requirements in a consistent and comprehensive manner. Standards often address only the technical issues

PAS 62559 © IEC:2008(E) – 17 –

This is a preview - click here to buy the full publication

Page 18: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

that are included in technical specifications; however, it is just as vital to develop standards to assist users to clearly and comprehensively define their requirements.

To clarify the distinction between “user requirements” (the “what” as needed by power system experts) and “technical specifications” (the “how” as technical descriptions of systems, applications, and information flows to meet the “what”). Currently this distinction is an “invisible line” so that often the “what” and the “how” are mixed together – with technology-oriented project engineers jumping directly to the “how” without fully exploring the “what” with the power system experts.

To emphasize the critical need to determine all user requirements first, before any commitments are made on “how” to meet those requirements. Because automation and control systems are so complex and are becoming increasingly so, if all requirements are not clearly defined first, then the premature design of systems can block or seriously hinder meeting those requirements that were not initially recognized.

To provide a means for testing the systems once implemented to ensure that the user requirements are truly met, regardless of what standards and technologies are ultimately incorporated by the vendors.

1.4 Audience of this Specification

The expected audience of this PAS include:

Executives who are evaluating business needs and need to understand the overall process for implementing solutions to meet those needs.

Power system experts who know their areas of power engineering, but are not familiar with methods for expressing their automation requirements in a manner that project engineers can use.

Project engineers who are familiar with general project management procedures but want to utilize state-of-the-art methodologies to improve the capture of all relevant user requirements, and to minimize the need to make unplanned modifications and replacement of systems and equipment to accommodate unexpected user requirements.

PAS 62559 © IEC:2008(E)– 18 –

This is a preview - click here to buy the full publication

Page 19: PUBLICLY AVAILABLE SPECIFICATION - IEC Webstore

2. Normative References Users can access the IntelliGrid Architecture documents or the IntelliGrid Architecture web site at http://IntelliGrid.info.

PAS 62559 © IEC:2008(E) – 19 –

This is a preview - click here to buy the full publication