Companion STDs
Home Up About OPUS Search Take a Tutorial News Services Registration Subscribers Calendar of Events Newsletter Hot Links

WiseOwl™
                                        The Secure Automation Developer's Resource

 

There is a faster way to develop standards

Dennis Holstein, Publisher
September 2000

IEEE is using dot-extensions (".") and companion standards to speed up the standards development process. The idea is to develop the basic framework in a standard, and then to use either dot-extension of that standard to extend the standard before the 5 year revision cycle, or to use companion standards to extend the standard and add the detail needed for a specific use. This sure beats the time line to develop a standard that is "perfect" and "all inclusive".

Within the Power Engineering Society we have an excellent example of putting this practice to use. The Substations Committee and the Power Systems Relaying Committee is currently working together to develop a series of standards for substation automation communications. This is how it works!

P1525 provides the paradigm for companion standards

Stay focused on the target

The Substations Committee of the IEEE Power Engineering Society is sponsoring the development of a standard for Integrated Protection, Control, and Data Acquisition Communications. Within the Substations Committee C2TF4 is managing the project, designated P1525, which when it becomes a standard will be designated IEEE 1525. The first draft of P1525 will go to ballot in late 2000.

The future plans are to build out IEEE 1525 in a series of companion standards and extensions based on the framework provided in the parent document. The current and proposed set of these standards is shown below.

What is P1525?

Our baseline 

P1525 is based on the work first initiated by the Electrical Power Research Institute under Research Project 3599. P1525 establishes the communication requirements with the emphasis on peer-to-peer communications and high speed communications over the substation Local Area Network (LAN) for integrated protection. The communication protocol is based on Internet specification for TCP/IP and UDP/IP. P1525 provides the specifications for:
bulletCommunication services, protocols, and performance requirements
bulletRequirements for deploying multicast in the substation
bulletRequirements for deploying network security in the substation
bulletSubstation data model with emphasis on object registration for interoperability
bulletCommunication capabilities required
bulletSystem requirements

Three normative annexes are included:

bulletA Power system model describing the relationship between substation devices. The power system model defines a reference object model, called PSOM, which is used to establish the requirements for exchanging data objects.
bulletA Client-Server model describing the communication relationship between substation devices. The client-server model defines a reference object model, called CSOM, which is used to establish the requirements for communication transaction sequences.
bulletASN.1 is used to define data objects and to describe the syntax of the data used in PSOM and CSOM.

P1525 plans to extend the baseline protocol suite

A subtask force within C2TF4 is currently working on the first extension of P1525, which will specify in a normative annex an Open System Interconnect (OSI) protocol suite that provides equivalent services defined by the baseline document. This is not planned as a companion standard, but as a ".1" release version of 1525.

Some IEEE standards, like those produced by the Computer Society (802.1), are already using the dot-extension. Keep in mind, the dot-revision can be issued at any time and does not need to wait for the normal revision cycle of 5 years.

The Substations Committee has not done this in the past, but it is appropriate here. Chalk up another first in the Substations Committee!

What is a companion standard?

Experts from the focus group

The purpose of the companion standard is to provide a formal mechanism for a user group to select functionality and requirements from the parent document (1525), and to expand the functionality and performance for a specific purpose. A companion standard may be a full standard, a recommended practice, or an application guide. In either form, the authors may choose to issue it as a trial use standard. P1525 provides the framework in terms of:
bulletA shopping list of functionality and performance
bulletSpecific requirements for a focused build-out

This approach is illustrated by two different types of companion standards: 

bulletA functional specification that extends the functionality of P1525: Two examples are the standard test method and the substation configuration management projects.
bulletBuild-out of the data model specified in P1525: Two examples are developed by user groups for DNP 3 and GOMSFE. DNP 3 is a popular and widely deployed communication protocol with a very strong user group, supported by a well defined technical committee. GOMSFE is the product of the Utility Initiative started by AEP, which includes plans for UCA™ intelligent electronic devices.

Power System Relaying Committee  is developing a standard test method

PSRC Work-in-Progress

The Power System Relaying Committee is sponsoring the development of  PC37.115, " Standard Test Method for Use in the Evaluation of Message Communications between Intelligent Electronic Devices in an Integrated Substation Protection, Control, and Data Acquisition System."  PC37.115 is a companion standard to P1525, and should go to ballot near the end of 2001.

PSRC Working Group H4 is developing the standard with input from Working Group H5. Working Group H5 is producing a report describing about 25 applications that could take advantage of information exchange between IEDs over the Substation's Local Area Network or Utility's Wide Area Network. Working Group H4 uses the scenarios developed by H5 to build-out the transaction sequences for exchanging data between IEDs. These transaction sequences are described in the informative annexes to PC37.115.  

Working Group H4 operates under a PAR (Project Authorization Request) approved by the IEEE Standards Board in 1998. The purpose and scope stated in the PAR are:

Purpose

There are currently no coherent communication modeling, terminology and communication test scenarios for the evaluation of one or more implementation concepts for communication between substation IEDs within a substation or between a substation and remote IEDs. Utilities and vendors will use this standard to evaluate, on a common basis, one or more implementation solutions.

Scope

This standard defines standard communication modeling, terminology, evaluation criteria and performance measures for communication test scenarios, which specify messages to be exchanged between electrical power substation intelligent electronic devices (IEDs). These scenarios define message transactions between applications within the substation, and between substation IEDs and remotely located applications. The scenarios do not specify the communication protocol required to implement the transactions.

Substations Committee is in the beginning stage of developing a Substation Configuration Management standard

The next companion standard

OPUS Publishing sent a letter to the Substations Committee C0 chairman requesting consideration for sponsoring a companion standard to P1525 that would address the requirements for Substation Configuration Management. There was considerable support for this initiative and a study group was formed to develop a recommendation for the initiative. These recommendations were reported to the members and discussed at the meetings during the July Summer Power Meeting in Seattle WA. A draft PAR has been prepared and will be discussed at the meetings in Andover MA in September. If accepted, and if resources are available, the task force will be formed to develop the companion standard.

The draft PAR includes the following purpose and scope:

Purpose

The purpose of this standard is to describe the requirements and build-to specifications for substation configuration management using the enterprise communication network and communication networks within the substation. Utilities will use this standard to procure new software, enhancement software, or software maintenance for their computer-based substation configuration management system. This capability will provide the utility engineer the means to create an electronic version of the substation configuration stored in a database, and manage that database during operations.

Scope

This standard will define a database schema and operator interface for substation configuration management. The Extensible Markup Language (XML), specifically XML-Data, under development by the World Wide Web Consortium will be used as a basis for defining the data format for information exchange. Requirements for processing the XML-Data will also be specified. The substation configuration management requirements will be specified to store configuration documents in a substation configuration distributed database (or repository) that can be used by all authorized subscribers. Operator interface requirements will be specified in terms of basic principles that provide for human friendly interaction with the XML-Data schema and data management.

Substations Committee is waiting for GOMSFE to stabilize, and will then consider starting a project to develop a GOMSFE standard

GOMSFE Project Team

EPRI initiated a project to develop a database of enumerated UCA™ data objects (called GOMSFE - Generic Object Model for Substation and Feeder Equipment) needed for two projects. The first project was the demonstration of UCA™ IEDs by the City Public Service - San Antonio. The second project is the Utility Initiative which includes several demonstrations by teams of utilities and vendors. The Utility Initiative is still very actively developing and refining the data object specifications. And each project is developing a project workbook to add the data object modification and extensions they require.

IEC TC57 is also integrating GOMSFE into IEC 61850, Part 7. This latest version of Part 7-4 containing the GOMSFE objects will be published as a Committee Draft (CD) in September 2000. The CD will be distributed to the National Committees for comment, and these comments will be worked in late 2000 and early 2001.

The plan is to update the latest version of GOMSFE (version .91) based on the revisions required for IEC61850-7-4. The new version should be available by the end of 2000 for use by the Utility Initiative. However, the cycle may repeat in 2001 if comments to the CD require changes that affect GOMSFE.

Several C2TF4 members are also members of the TC57 working groups developing IEC 61850, and are active participants in the Utility Initiative. They of course have first hand knowledge of the maturity of GOMSFE and IEC 61850. Two options are available to C2TF4:

bulletIf all goes well, and IEC 61850-7 becomes an international standard, then a future release of IEEE 1525 will include IEC 61840-7 as a normative reference. This is the best option!
bulletIf IEC 61850-7 does not become an international standard, or it is taking too long to become a standard, then C2TF4 could consider building a companion standard based on the latest version of GOMSFE plus the modifications and extensions developed by the Utility Initiative project teams. Stay tuned!

Substations Committee C2TF4 members have expressed an interest in developing a DNP companion standard

C2TF4 members have expressed an interest in developing a DNP (Distributed Network Protocol) companion standard. The idea is currently being discussed in the DNP User Group's Technical Committee to determine if they want to go forward with the initiative. If so, the DNP Technical Committee would provide the experts to form the task force and prepare the PAR. A DNP project would be the first to select the functionality and requirements from the options specified in P1525. Primarily, the work will be focused on building out the specifications for P1525's reporting model, and developing the parameter specification for the "holes" defined in P1525's data model.

DNP Technical Committee experts will define the data structures,  parameter value defaults and range, and error conditions and codes. ASN.1 experts are available to formalize this requirements in ASN.1 format.

An example is described next to better understand the "holes" defined in P1525's Annex E. All "hole" fields are identified by the "&" that precedes the parameter name. For this example specific "holes" are highlight to illustrate how the components interact and  fit together. Following the example is an explanation of some other features illustrated by this example.

First, an Error information class is specified as

ERROR ::= CLASS
{
&errorCode                          CHOICE {local INTEGER,
                                                                 global OBJECT IDENTIFIER}
                                               UNIQUE,
&ParameterType                 OPTIONAL
}

Next, an OperatingParameters information class is specified as

 Operation ::= CLASS
{
&OperatingParameters         CHOICE {local UTF8String,
                                                  global OBJECT IDENTIFIER}
                                                  UNIQUE,
&ArgumentType,
&ResultType,
&Errors                          ERROR OPTIONAL
}

Last, the MeasurementUnit and Measurement objects are specified as

MeasurementUnit ::= SEQUENCE
{
measurementUnitID: UTF8String,
unknown-power-system-connection ::=
   {&powerSystemConnection ASN-type power-system-connection-details},
unknown-configuration-parameters ::=
   {&configurationParameters ASN-type configuration-parameters-details},
unknown-operating-parameters ::=
   {&operatingParameters ASN-type operating-parameters-details},
Measurement ::= SEQUENCE
   {
    measurementID: UTF8String,
    measurementDescription: UTF8String,
    measurementTime: CHOICE
        {NominalTimeStamp, SynchCheckTimeStamp, PrecisionTimeStamp},
    unknown-measurement-value ::=
        {&measurementValue ASN-type-measurement-value-details}
    ...}
...}

The first step defined an Error information class, created the holes for the &errorCode and &ParameterType. These fields must be defined in detail in the companion standard.

In the second step the OperatingParameters information class was defined with holes for &OperatingParameters, &ArgumentType, &ResultType, and &Errors. These fields must be defined in detail in the companion standard. Note, the field &Errors also refers back to the Error information class.

The last step in the example defined the MeasurementUnit and Measurement based on the PSOM model described in P1525, Annex B.  All the "unknown" specifications must be defined in detail in the companion standard. Again note, the field &operatingParameters refers back to the OperatingParameters information class.

One last point of interest is the notation "...". This is the ASN.1 version control delimiter, and should be used in the companion standard to identify the baseline specification, and after each "..." extensions to the baseline should be specified. This is best illustrated in the following figure.

IED A sends  data in a message to IED B, which in turn, and potentially with some modification, sends the data in a message to IED C. IEDs A and C implement the baseline (version 1) functionality and the extensions defined as version 2. The delimiter "..." specified in the ASN.1 build out of the object model is used to distinguish version 1data  from version 2 data. IED B only implements the baseline - version 1, and will not understand the semantics of the data object extension specified as version 2.

The data flow shows that data sent from IED A, containing both version 1 and version 2 data, to IED B. IED B only understands and operates on version 1 data, that data specified prior to the delimiter "...", and ignores the version 2 data. IED may, or may not, modify the version 1 data that it understands. After IED B completes its application, it sends all data to IED C with the changes (if any were made in version 1 data) and the version 2 version 2 data, which is unchanged.

IED C has the is capable of reading and understanding version 1 data, which may have been changed by IED B, and version 2 data originally sent by IED A. Thus we have interoperability between all three IEDs!

Those interested in developing a P1525 companion standard need to do the following:

Don't be shy -- get

The first task is to prepare a proposal to a sponsoring committee; e.g., Substations Committee or PSRC. The proposal should include:
bulletTitle of the proposed companion standard
bulletScope of work
bulletIdentification of resources to perform the work

The second task is to meet with the chairman of the sub-committee and members of the subcommittee to discuss the proposal, and to answer questions from the sponsor.

The last task is to form the task force or working group and begin work. One of the first orders of business is to write a PAR, and submit it for approval.

Need help -- Give us a call

We are interested in your opinion, so please take some time to send me an EMAIL at holsteindk@aol.com with your contribution. We will continue to report on the development that flows from each standardization venue in Que Pasa, which is only available to OPUS Subscription Service subscribers.

Where do you want to go now?

Back Up Next

 

Send mail to postmaster@opusss.com with questions or comments about this web site.
OPUS Publishing and OPUS Subscription Service are trademarks of OPUS Publishing. All other products mentioned are registered trademarks or trademarks of their respective companies.
Copyright © 2001 OPUS Publishing. All rights reserved.
Last modified: Sunday August 01, 2004 .