What is IEEE P1525
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

 

IEEE P1525 goes to ballot

Dennis Holstein, Publisher
January 2001

IEEE P1525 is sponsored by the PES Substations Committee

IEEE P1525 is an approved standards development project (approved on March 19, 1998) sponsored by the Substations Committee. C2TF4 is responsible for developing the standard. C2TF4 conducts their meeting and work sessions at the PES Winter and Summer Power meetings, the annual Substations Committee meeting, and jointly with the Power Systems Relaying Committee (PSRC) in September of each year. Clearly stated in the approved project is the purpose and scope for P1525.

Purpose

Utilities will use this standard as part of a specification to develop new substation automation capability, or to modify existing substation automation capability. Vendors will use this standard to build open system communication interfaces for intelligent electronic devices for substation automation.

Scope

The scope of the project is to define standard communication requirements, specify message delivery time between intelligent electronic devices, and specify Abstract Syntax Notation (ASN.1) data structures of information to be exchanged.

The attack on P1525

Recently, there has been a sustained attack on P1525 by those with a vested interest in using ISO 9506, with UCA 2.0 enhancements, as the single application protocol for substation automation. Their objective is to force the withdrawal of P1525 in favor on IEC 61850. IEC 61850 is a substation automation standard in development by the IEC Technical Committee 57.

The claim by this group is that an agreement was reached between the IEEE and the IEC in the 1998 Tampa meeting to the effect that only one standard should exist, and that standard should be IEC 61850. Joe Koepfinger, chairman of Standards Coordinating Committee (SCC) 36, in a letter dated 3 October 1998, stated the following position relative to an agreement made in Tampa.

 "In an attempt to clarify matters relative to the Tampa meeting, it should be noted that the meeting was called by the US Technical Advisory, Mr. Thorson. He used this meeting to stress the need for cooperation between IEC TC57 and IEEE in the area of Utility Communications. As you will recall, several times during the meeting, I made it very clear that neither myself nor anyone in that room could make any agreement that would place any constraint on the work of IEEE. What had been suggested by the European gentleman formTC57 was that IEEE stop work on UCA once the document was published by IEEE. To agree to that, in my opinion, would have been illegal and I so stated my position on this issue several times. This did not get recorded in Mr. Thorson's notes of the meeting.

There are several reasons for this position:

  1. To make an agreement to partition up standards work has, in the past, been viewed by IEEE council to border on collusion.

(If you recall, I stated at least twice that it would be illegal for me, as the Chair of SCC 36, to agree to this action. That doesn't mean that we would not exchange information on UCA with the IEC, using the proper channels and giving consideration to the intellectual property rights of EPRI and IEEE).

The laws of the United States are very clear in not allowing corporations to engage in acts of collusion. A case in point is the recent charge by the Justice Department against Bill Gates [Microsoft], dealing with the use of Windows 98 by other parties that was discussed in a meeting with them where it is alleged that they were requested to license and use Microsoft software in their computer systems in place of their own software.

  1. The Bylaws of the Institute make it very clear as to who has the authority to interface with bodies outside the IEEE in Standards matters. The following is stated in Clause 309.1 of the IEEE Institute By-laws:

309 Standards Board

1) The Standards Board (STB) is responsible on an Institute-wide basis for encouraging and coordinating the development and revision of IEEE Standards, and for carry out other standards-related activities in fields of interest to the Institute. It shall give final approval to IEEE standards prior to publication. It shall consider and investigate matters relating to standards and units in the fields covered by IEEE. It shall represent IEEE in standards-related matters in dealing with other organizations.

I believe that it is very clear from this statement that only the Standards Board has the authority to negotiate with the IEC in standards matters. To my knowledge, none of us in that room in Tampa had been delegated to negotiate anything with the IEC. Furthermore, I do not believe that the gentlemen from Europe carried any such authority form the IEC, If so, they should have conveyed this information to the IEEE Standards Board.

The Tampa meeting was an attempt by the US TAG to get parties in IEEE and IEC together to encourage mutual development of UCA documents and in particular GOMSFE, CASM and Profiles. This group has no official standing. It was not the USNC TAG to TC57, it was not IEEE SCC36, it was not the IEEE Power Engineering Society, and it was not the Electrical Power Research Institute."

The rest of the letter deals with the operation of SCC36.

The point I'm trying to make is that no official agreement was made between the IEC and IEEE to limit the development of IEEE standards. Keep this in mind when you hear the spin misters claim that there is an agreement, and P1525 should be withdrawn. When you hear this, ask the speaker to show proof or stand down!

Response to the attack on P1525

I want to respond to the one-sided discussion at the Utility Initiative meeting in Austin, TX on January 11 and 12. I know that I'm not going to change your mind, but I would like to express my opinion about several issues. 

In accordance with the IEEE balloting rules, those that ballot on P1525 are expected read the document and vote on the facts, not vote on the basis of listening to someone rant and rave about a subject that they are predisposed to fight. Let me highlight some of the features, and considerations of the C2TF4 task force members, that are contained in P1525:

bullet

P1525 baselines the Internet Protocol suite (stack) because the group wanted an open system specification based on readily available communication components. Many vendors provide TCP/IP and UDP/IP communication in their IEDs. Furthermore, many utilities find it easier to get buy in from their IT department to use the Utility WAN when the substation automation is based on the same Internet Protocol suite.

bullet

P1525 does not enumerate data objects to be exchanged between IEDs, but simply states that if data objects are defined, the one who generates a data object must use ASN.1 to formally define the data object, and the data object must be registered. The intent is to facilitate interoperability by ensuring that all data objects are in the public domain. In this context, data objects defined by vendor agreement in the UCA initiative (GOMSFE) and data objects defined in IEC 61850-7 are acceptable to P1525.

bullet

P1525 requires encoding using ASN.1 Packed Encoding Rules to facilitate efficient use of communication bandwidth for dial-up and wireless communications. To migrate legacy systems, P1525 requires using ASN.1 Encoding Control Notation.

bullet

P1525 does not dictate a specific Application Service Element (ASE) protocol implementation. Pure MMS, or MMS with UCA 2.0 enhancements may be used if they meet the functional and performance requirements for a vendor's selection of the automation market. Other ASEs beside MMS can be used, but again they are subject to the applicable functional and performance requirements. Or, the developer may simply open a socket to establish communications.

We want your opinion

Don't be shy, we want you to express your opinion about this situation. Technical concerns and issues are really appreciated, and will be brought to the attention of C2TF4 for discussion. You can send me an Email by simply filling out the form below, or by sending an Email to holsteindk@aol.com .

Enter you Email address:

What is your opinion:

 

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 .