1

A FUNCTIONAL REFERENCE MODEL FOR ASSET MANAGEMENT APPLICATIONS BASED ON IEC 61968-1

Per Närman, Magnus Gammelgård and Lars Nordström Dept. of Industrial Information and Control Systems, Royal Institute of Technology, KTH

pern@ics.kth.se, magnusg@ics.kth.se, larsn@ics.kth.se

ABSTRACT Distribution utilities that upgrade or implement new asset management applications very soon arrive at a stage where the business value of different system options needs to be assessed and compared One obvious, aspect that must be considered in the respective options is their functional fit, i.e. the degree to which their functionality suits the business needs of the utility. At the same time it is inherently difficult to objectively measure the functional fit of a proposed system solution. One way to evaluate the functional fit is to develop a functional reference model and then compare the functionality of the proposed system, or systems with the reference model. In order for the reference model to be of any value it needs to be based on business requirements rather than existing system functionality and it needs to be complete in the sense that it encompasses all possible functions in the evaluated functional area. This paper describes the development of a reference model for asset management applications in the area of electricity distribution and generation. The functional reference model is based on an existing functional breakdown presented in the IEC-61968 standard developed for interapplication integration at electrical utilities. Also incorporated into the model are functions from various vendors of asset management applications. Having merged these sources together, the model has been validated by means of an extensive case study at a large Nordic power company.

INTRODUCTION This paper describes the development of a functional reference model for asset management information systems, specifically for electricity distribution networks. In addition, the work has included input from similar areas within hydropower generation. A functional reference model is a database detailing what functions are needed for a functional area within for instance a utility. The reference model created in the study described herein is based primarily on the IEC 61968-1 standard [1] for inter-application integration of Distribution Management Systems. Specifically it is based on the Interface Reference Model (IRM) which forms the basis on which the IEC 61968 standard series are created. In addition to the IEC-standard, functional breakdowns from asset management system vendors have been incorporated into the model. The development and refinement of the functional reference model was concluded with a comprehensive field study at a large Nordic utility, were the IRM-based reference model was validated. The overall purpose with the study was to create a reference model, useful for evaluating software packages from different asset management system vendors. Additionally, as a secondary result, the study provided validation and ideas for refinement of the IRM.

2

Asset management Asset management is perhaps the core-activity of distribution utilities. Embracing a very wide definition of asset management as in [2], asset management can be said to involve all aspects related to the owned assets of an enterprise, including the maintenance, operation and investments of new assets. In this case, the scope of the functional reference model was narrowed to exclude the operations-aspect of asset management and to focus on the planning and execution of maintenance and investment activities. The deregulation of the electricity markets forces utilities to abandon the old asset management approach, which was focused solely on reliability, in favour of incorporating cost-benefit analyses into consideration. This has led to a trend where more and more sophisticated diagnostic and planning methods are introduced. An example of this is the introduction of the Reliability Centred Maintenance- strategy at some power companies; see for example [3] or [4]. It is natural that under these new circumstances a utility will focus on improving its power system maintenance processes, the goal being to prolong the life-time of equipment, thereby providing better return on employed capital. Equally obvious is that the utilities will strive to make their maintenance processes cost efficient and to a large degree automated so as not to become dependant on single individual employees. The answer to both these requirements is increased use and integration of information systems in support of the maintenance processes. For examples of this development see [5] or [6].

Background of the project: IT Investment analyses When faced with the decision of which IT-investment scenario to choose, i.e. which system or systems that should be bought, decision makers have traditionally been given two options: to pick a solution based on little or no formal analysis, or to first go through the painstaking requirements engineering process followed by an equally rigorous procurement process. The former process specified all functional requirements in great detail, and the latter thoroughly evaluated systems from a few vendors. Thus far, no cheap, easy-to-use method has been available for strategic management decisions regarding which solution to buy. To fill the void between having no decision support, and too much decision support, researchers at KTH have developed the IT Investment Evaluation Method (ITIEM), which is a method to compare off-the-shelf software systems from different vendors with regard to the business value the systems provide. The ITIEM-method is intended to be a fast and low-cost and to be used before, and as a complement to, traditional requirements engineering methods. The functional reference model was developed as a part of the ITIEM [7]. The concept of using the IEC standards as a starting point for creating a reference model is based on previous work reported in [8] and [9].

Scope of the Study This study encompassed creating a functional reference model appropriate for identifying functional differences between asset management systems from different vendors for electrical utilities involved in generation (hydropower) and distribution. The purpose was not to create an entire functional requirements specification, and consequently the model describes the systems on rather a high level of abstraction. Furthermore, to limit the scope of the reference model to be developed, the area of Asset Management was viewed as maintenance, investment and work management. The reason for narrowing the scope in this manner was to adjust the model to currently available asset management applications. To

3

develop a functional reference model with too wide a functional scope compared to the systems which will be evaluated serves no purpose.

Contribution of the paper The paper describes an alternative use of the Interface Reference Model of the IEC 61968-1 standard. In the study, the IRM has been used as a basis for creating a functional reference model. This functional reference model has then been used in evaluation of asset management software packages. In addition to providing an example of alternate use of the 61968 standard the study also provides interesting empirical validation of the applicability of the IRM as such. The paper, combined with the actual functional reference model (available from the authors) can serve as a starting point for further refinement of the IRM by adding descriptions to the previously undefined functions of the IRM, as well as more details added to the IRM.

Outline of the paper Following this introduction a chapter is devoted to describing standardization within the framework of IEC’s Technical Committee 57 responsible, among other things for the development of the standard used in this study. Thereafter follows a description of how the functional reference model was created, starting with the scoping of the model and the merging of the model with functions from vendor functional ontologies. The validation of the functional reference model is described in the chapters to follow. The evaluation criteria used in the validation are described as well as a brief description of the methods used for data collection and analysis. The paper is concluded by an overview of the results of the study; the functional reference model itself.

STANDARD DEVELOPMENT WITHIN THE IEC TC 57 Technical committee 57 (TC 57) of the International Electrotechnical Commission (IEC) is concerned with issues related to Power Systems Management and Associated Information Exchange. TC 57 consists of several Working Groups (WG), each responsible for development of a specific standard addressing a specific issue in power system communication and control. Much of the work within TC 57 is focused on creating standards facilitating interoperability of communications and control systems used for power system control and operation. Interoperable systems are easy to integrate and integrated systems facilitates the seamless exchange of data across the utility, providing decision makers with better decision support, as well as improving the efficiency of day-to-day operations. [13] Here follows a short description of some of the Working Groups within TC 57 with focus on WG 14 which develops the standard used in when developing the functional reference model. Working Group 3 develops a standard, the IEC 60870, standardizing communications protocols between SCADA-applications and Remote Terminal Units (RTUs). Also part of the technical committee 57 is WG 10, responsible for the creation of the IEC 61850, aimed at developing a standard for the architecture and interfaces of substation.. Spin-offs of the IEC 61850 standard are the standards IEC 62344 and 62350. IEC 62344 developed by WG 18 deal with the communications for hydropower plants and IEC 62350 developed by WG 17 has focused on communication systems related to distributed energy resources, as for instance distributed heat generation. [17]

4

WG 15 is developing the IEC 62351 standards for data and communications security relevant to all the activities within TC 57. WG 16 develops a standard called IEC 62325, creating a framework for communications in a deregulated electricity market. Lastly, WG 19 is taking into consideration the long-term interoperability of all the systems considered by TC 57. [16] WG 13 and 14 are defining the so called Common Information Model (CIM) [14] At the core, CIM is essentially a big library of all the data objects that are used by EMS (Energy Management Systems) which is standardized in 61970-301. This library, or meta-model, is also being extended to cover DMS (Distribution Management Systems) applications of an electric utility, this latter work is the responsibility of WG 14. The purpose of having a common data model is to be able to define standardized application interfaces, thereby allowing data and services to be exchanged between applications from different vendors. This approach makes it possible to integrate legacy systems with more Commercial-Off-The-Shelf (COTS) systems. The integration is done by means of an integration bus which is connected to the applications with interface adapters, i.e. software translating the data models used by the applications to the standard-compliant data models as specified by the CIM. See Figure 1 below. The work within Working Group 13 is focused on the EMS-applications comprising functionality related to the operation of transmission and generation systems. EMS includes for instance functions for state estimation, contingency analyses, real-time SCADA-functionality as well as generation management and functions for energy trading. The data exchange and integration is mainly focused on the exchange between system operators. The data objects defining the physical network, loads, transformers, lines etc., have been defined in the standard IEC 61970-301. Working Group 14 has focused their attention on the development of a standard series, IEC 61968, for DMS-application integration within a utility or system operator. Distribution management is less focused on the real-time calculations considered important in EMS, and more emphasis is put on everyday operations where the complexity lie in the sheer number of activities that needs to be managed, rather than the activities being complex in themselves. Examples include network planning outage management, customer relations, asset management etc. [1]

5

IEC 61968 Compliant Middleware Services

(NE)Network

ExtensionPlanning

(CS)CustomerSupport

(MR)Meter

Reading &Control

(AM) Records &

AssetManagement

(MC)Maintenance

& Construction

InterfaceStandard: Part 4

InterfaceStandard: Part 6

InterfaceStandard: Part 7

InterfaceStandard: Part 8

InterfaceStandard: Part 9

(ACT)CustomerAccount

Management

(FIN)Financial

(PRM)Premises

(HR)Human

Resources

(EMS)Energy

Management & Energy Trading

(RET)Retail

InterfaceStandard: Part 10

(SC)Supply

Chain and Logistics

(NO)Network

Operation

InterfaceStandard: Part 3

(OP)OperationalPlanning &

Optimization

InterfaceStandard: Part 5

InterfaceStandard: Part 10

InterfaceStandard: Part 10

InterfaceStandard: Part 10

InterfaceStandard: Part 10

InterfaceStandard: Part 10

InterfaceStandard: Part 10

Electric Distribution NetworkPlanning, Constructing,

Maintaining, and Operating

Generation and Transmission Management, Enterprise Resource Planning, Supply Chain, and

General Corporate Services

Business Functions External To Distribution

Management

Distribution ManagementBusiness Functions

Figure 1: Enterprise Application Integration using the IEC 61968 standard. Separated applications are integrated by a standard compliant middleware, and application interfaces convert the data of the applications to data models compliant with CIM. The boxes are the business functions that according to the IEC WG 14 constitute the area of DMS.[1]

IEC 61968 – the Interface Reference Model The output from WG 13 and 14 is similar in the respect that they both produce standardized meta-models. The angle of attack when creating these data models differs in the respect that WG 14 has chosen to define all possible ways to utilize IT-systems for distribution management in their so called Interface Reference Model (IRM), which defines the functional scope of DMS. The data objects defined in the IEC 61968 are based on the functions specified in the IRM. The content of the Interface Reference Model is divided into 14 Business Functions. A business function roughly comprises the activities or functions, normally performed within a specific organizational unit at a power company. The business functions are broken down into smaller entities called business sub-functions, and these in turn contain smaller components, called abstract components. The business functions of the IEC 61968-1 are shown in Figure 1 above. The internal structure of the IRM with its three levels is shown in Figure 2 below.

Figure 2: The structure of the Interface Reference Model of the IEC 61968 standard contains three levels; business function, business sub-function and abstract component level. [1]

6

Initially it was assumed that asset management applications for power distribution is a subset of DMS, and that asset management applications for power generation, functionally speaking, is a subset of those for power distribution. Hence it was deemed appropriate to use the IRM, or at least a subset of it, as starting point in the development of the functional reference model. The scoping of this subset is described in the next chapter.

SCOPING OF THE FUNCTIONAL REFERENCE MODEL The scoping was made together with professionals from a large Nordic utility, knowledgeable in the area of asset management in power distribution and generation. The remaining business functions are shown in Figure 3 below. The business functions still present are

• Maintenance and Construction, • Records and Asset Management, • Operational Planning and Optimization, • Customer Support, Supply Chain and Logistics, • Premises.

The last three business functions were included as they contain functions that are at least related to asset management issues. Customer support for instance is an important aspect in asset management, as often the only way to monitor the status of a distribution network is through customer contacts, it is therefore important that customer support applications are integrated with the maintenance process.

Figure 3: A demarcation of DMS was made in order to extract business functions relevant to asset management. The striped boxes were excluded from the functional reference model. In the IEC-standard, the functions in the IRM are not described, apart from their names, and this lack of descriptions gives room for a wide range of interpretations of what the functions actually mean. To overcome this, every component on the abstract component-level was given descriptions which were refined later during the field study.

7

VENDOR ONTOLOGIES The functions selected from the IRM were augmented with functions contained in vendor ontologies. This to ensure that the rapid development in the area of asset management applications however, did not render the IRM obsolete; there could be vendors offering applications not present in the IRM. Material from three vendors were used, viz. SAP, Oracle and Powel. Powel is a small vendor of a Network Information Systems (NIS) called NetBas, i.e. GIS-systems with the ability to display the electrical network in the terrain. Oracle is, among other things, a big supplier of Asset management applications [11], as is SAP. [12]. The total list of vendor functions included about 600 functions. These were then merged with the IRM to extend the IRM both in depth and width. See Figure 4 below.

Vendor-specific are added onabstract component level

IEC-functions (row)

Field Communication

Collect InspectionReadings

Determine optimum route of inspection

Inspection

Phase-outEquipment

Phase-in EquipmentMaintenance

ProcesstegProcess

WorkOrder Closing

Workorder Status Tracking

Asset FailureHistory

ManageInspectionReadings

MaintenanceProgram Management

Abstract Com-ponent

Maintenance& Inspection

Business Sub-function

Maintenance& Construction

Business function

Equivalent are placed belowabstract components

Functions fr. Vendors(Column)

Vendor-specific are added onabstract component level

IEC-functions (row)

Field Communication

Collect InspectionReadings

Determine optimum route of inspection

Inspection

Phase-outEquipment

Phase-in EquipmentMaintenance

ProcesstegProcess

WorkOrder Closing

Workorder Status Tracking

Asset FailureHistory

ManageInspectionReadings

MaintenanceProgram Management

Abstract Com-ponent

Maintenance& Inspection

Business Sub-function

Maintenance& Construction

Business function

Equivalent are placed belowabstract components

Functions fr. Vendors(Column)

Figure 4: the merging of functions from vendors, with those of the IRM. Vendor functions to the left, IRM on top. The extension in depth added a fourth level to the model. See Figure 5. This level is called the “measurement point”-level”, the functions in this level are used to measure the functional fulfillment of the investigated asset management application.

Field Recording & Design

Maintenance & Inspection

(MAI)

Construction & Design (CON)

Work Scheduling

(SCHD)

Field Recording &

Design (FRD)

Work Dispatch (DSP)

Field Inspection

Results

Crew Time Entry

Actual MaterialsField Design

Business Sub-Function Level

Abstract Component Level

Business Function level

Actual Equipment

Importing work order feedback from field crews

(results, comments)

Function to display data from asset repository in the field, either by being online or by

storing it.

Function to display an electronic

checklist of the agreed delivery

Function to connect the

"delivered"-status of the material to payment of the

delivery

Added function on the abstract component level

Examples of added measurment points to abstract components

Figure 5: A fourth level was added to the original three of the IRM. Functional names are exemplary.

8

VALIDATION & REFINEMENT The steps of scoping and merging the IRM with vendor functions proved insufficient if the model was to be of any use. The model needed to be validated and refined, and this was accomplished by means of a field study. To accommodate the functional differences between generation and distribution asset management, two separate models were created. The generation functional reference model contained, as mentioned above, a subset of the functions present in the distribution model.

Method of validation The method of validation considered three aspects; the data sources needed for validation of different parts of the model; the evaluation criteria for the model and the analysis of the answers provided during validation.

The evaluation criteria An effort was made to operationalize the concept of “validation” by defining four criteria; viz. correctness, completeness, granularity and measurability.

• Correctness means that the model accurately describes the functions in the model. “Accurate” in this context means that the definitions given in the model are roughly the lexical definitions, i.e. they correspond to the common usages of the terms by industry professionals.

• Completeness means that the model spans the subject matter. A complete model describes what it is intended to describe, encompassing the relevant information and contains all vital parts in the description.

• Granularity means the level of detail in the model. Level of detail refers to how deep the description of an asset management application is.

• Measurability is the ability to use the functional reference model to conduct a measurement of functional fulfillment of an information system.

A framework for choosing experts for interviews A framework was developed for classifying experts with regard to three dimensions; relation to the evaluated information systems; nature of knowledge and level of detail of knowledge. See Figure 6 below. Depending on the relation to the application the expert might have, the perspective, and therefore the answers, differs. An expert involved in developing a new application has a different perspective compared to that of a user of the same application or the consultants in charge of implementing the application at the users company. The relation dimension is therefore classified into three categories, supplier, user and implementer. The experts might have very different nature of knowledge, i.e. different areas of expertise. For the purpose of this validation, a very coarse categorization was made were experts were said to have knowledge in either the IT-domain, or the business-domain (i.e. the running of a power company) or a mix of both.

9

The level of detail of knowledge was divided into categories suitable for the investigated organization. In this case the level of detail was broken down into four different levels; enterprise, business unit, process manager and process performer.

Enterprise levell

Business unit level

Process manager

Process performer

Both

IT and Business know

ledge

Prim

arilybusiness know

ledge

Prim

arilyIT-know

ledge

Supplier (vendor)

User (Utility)

Detail of knowledge

Relation

Nature of knowledgeImplementer

(consultant)

Figure 6: The three dimensions used to categorize the type of knowledge required in the validation process. The vertical axis is granularity of knowledge, the horizontal IT/business; the third axis separates user/supplier/implementer. The validation process was broken down into four separate phases, which differed somewhat with respect to the criteria investigated, the level of detail in the model that was validated, and the type of experts that were needed. Depending on criteria investigated, and part of the model investigated, the experts were then mapped to the framework and showed to the contact persons at the investigated power company, who were then able to select the most appropriate expert to interview. See Figure 7 for an overview of this entire process.

Type of validation Classification of expert Organization

Gives a Is matched with

Gives

Type of validation Classification of expert Organization

Gives a Is matched with

Gives

Figure 7: The processes of finding experts began by considering which type of validation was needed, followed by the categorizing of the needed expert according to the framework presented above, and given the expert-category find a suitable expert in the organization.

10

Data collection Having chosen experts to interview in total 20 interviews and workshops were carried out. During these sessions a number of suggestions of changes in the original IEC-based model were made. The majority of these suggestions consisted of additions of more measurement points, i.e. the fourth and lowest level of the functional reference model. Some of changes were also suggested concerning additions or exclusion of functions primarily at the abstract component level.

Analysis of suggested changes All data was recorded in a database and all suggested changes to the original model were analyzed according to how well they fit to the rest of the model. In total 25 major changes were made to the original model, as well as a large number of smaller changes involving primarily the adding or excluding of measurement points.

RESULTS: A FUNCTIONAL REFERENCE MODEL Due to space-constraints, the functional reference model cannot be presented in its entirety here. As was noted above two separate models were developed, one for generation and one for distribution. The generation model is smaller and does not contain functions related to the business sub-functions Trouble Call Management and Work Dispatch. It also lacked some abstract components present in other parts of the distribution model, but was otherwise almost identical. This paper will not dwell further on these differences, but will focus instead on the functional reference model for distribution. See Figure 8 below.

Figure 8: The business functions and business sub-functions of the functional reference model. Going through the business functions and business sub-functions presented in Figure 8 above from left to right, we start with the business function entitled External to DMS. This business function contains functions exclusively utilized in DMS-applications but of a general, less business-domain specific nature. Three business sub-functions from this business function were included in the model. These are the Supply Chain and logistics sub-function dealing with supply of among other things spare parts and containing functions to manage warehouses and materials, the Premises sub-function dealing with some aspects of customer and company-owned property issues and the Document Management business sub-function dealing with distributing and modifying business critical documents of various kinds.

11

The Records and Asset Management business function is, together with Maintenance and Construction (see below) one of the most important for asset management. There are three business sub- functions within it. The first is Substation and Network Inventory which contains functions for storing and displaying relevant data from the asset repository database. The Geographical Inventory business sub-function contains functions for displaying the electrical network on geographical maps. The Asset Investment Planning sub-function contains functions necessary for doing long-term planning of investment in new assets. This includes doing LCC-analyses and some measure of network calculations. The Maintenance and Construction business function contains five business sub-functions. The Maintenance and Inspection sub-function contains functions for the efficient execution of the routine preventive and corrective maintenance and inspection activities performed at an electric utility. The Construction and Design sub-function deals with the issues related to building various kinds of facilities, primarily the work-related issues. Work Scheduling is a sub-function used for detailed planning of work activities. Field Recording and Design is a sub-function dealing with providing field crews with applications that are designed for out-of-office use. This entails real-time communications, the ability to access the asset repository from a remote location and so on. Work Dispatch is a business sub-function intended for centralized supervision of dispatched field crews. The business function Customer Support with its only sub-function Trouble Call Management was included in the functional reference model, as the contact with customers has some bearing on maintenance activities. Especially the corrective maintenance associated with customer outages. The present lack of sensors in low-voltage distribution networks makes customer reports critical for assessments of network status, and consequently provides maintenance planners with relevant information. The last business function Operational Planning and Optimization and its sub-function Switch Action Scheduling/Work Scheduling, contains functions for the co-ordination of the de-energization of electrical equipment and planned maintenance activities.

CONCLUSIONS The study shows that the IEC 61968 standard for inter-application integration can be used as a foundation for a functional definition of the area of asset management. In this study, the IRM has been validated, and refined and then used to evaluate asset management software packages. Additionally, the study has provided valuable input to extensions of modifications of the IRM as such. The benefits of using the standard are, besides it being highly credible, are that it is politically unbiased and that it represents cutting-edge knowledge of current and future developments within Distribution Management Systems. All of these conclusions were verified empirically in the research leading up to this paper. The empirical data was quite extensive involving input from 20 experts in the field, and the quality of the data is reasonably high which is guaranteed by the meticulous methods employed in the validation process.

12

REFERENCES [1] International Electrotechnical Commission, “IEC 61968-1 Application integration at electric utilities – System Interfaces for

distribution management Part 1: Interface Architecture and General Requirements”, IEC Reference number IEC 61968-1:2003(E). [2] Shahidehpour, M., Ferrero, R. (2005), “Time Management for Assets” Chronological Strategies for Power System Asset Management”

In IEEE Power & Energy Magazine May/June 2005. [3] Bertling, L., Allan, R., Eriksson, R. (2005), “A Reliability-Centered Asset Maintenance Method for Assessing the Impact of

Maintenance in Power Distribution Systems” IEEE Transactions on Power Systems, Vol. 20, No. 1, February 2005. [4] Goodfellow, J.W., “Applying Reliability Centered Maintenance (RCM) to Overhead Electric Utility Distribution Systems” In

proceedings of Power Engineering Society Sum-mer Meeting, 2000, 16-20 July 2000. [5] Brown, R.E., Humphrey, B.G (2005), ”Asset Management for Transmission and Distribu-tion” IEEE Power & Energy Vol 3 No: 3

May/June 2005. [6] Kuhn, R, Where's Energy IT Now? http://www.energypulse.net/centers/article/article_print.cfm?a_id=808, access 9th December 2004. [7] Gammelgård M., Närman P., Ekstedt M., Nordström L., Business Value Evaluation of IT Systems: Developing a Functional Reference

Model In Proceedings at the Conference on Systems Engineering Research April 2006. [8] L. Nordström, T. Cegrell “Extended UML Modeling for Risk Management of Utility In-formation System Integration” In Proceedings

of the IEEE Power Engineering Society’s General Meeting, San Francisco, USA, June 12-17, 2005. [9] L. Nordström, T. Cegrell “Analyzing Utility Information Systems Architecture using the Common Information Model” In Proceedings

of 2nd CIGRE / IEEE PES International Symposium on Congestion Management in a Market Environment, San Antonio, USA, October 5-7, 2005.

[10] International Electrotechnical Commission, “IEC 61970-301 Energy management system application program interface Part 301: Common Information Model (CIM) Base”, IEC Reference number IEC 61970-301:2003(E).

[11] Oracle White Paper, Oracle Enterprise Asset Management 11i, 2005 [12] SAP AG, “Industry-Specific SAP Business Maps – Utility”. http://www.sap.com/industries/utilities/businessmaps.epx, April 2006. [13] Becker, D. et al., “Standards-Based Approach Integrates Utilities Applications”, Computer Applications in Power, IEEE, October 2000 [14] International Electrotechnical Commission Technical Committee 57, “IEC/TR 62357: Power System Control and Associated

Communications – Reference Architecture for Object Models, Services and Protocols”, 2003 [15] International Electrotechnical Commission Technical Committee 57, Working Group 13, “IEC 61970-301:2003, Energy Management

System Application Program Interface – Part 301: Common Information Model”, 2003 [16] International Electrotechnical Committee, Technical Committee 57, “CIM User Site”, www.cimuser.org, May 2006. [17] Schwarz Consulting Company, “Entry point for the members of important IEC projects

that define the standard IEC 61850 and other standards based on IEC 61850”, http://www.scc-online.de/std/index.html, May 2006