Are you ready
to provide the framework for interoperable communications within the
substation?
Dennis Holstein, Publisher
March, 2000
Substation communication -- what is the objective?
There have been many attempts over the past 8 years to define a communication
protocol that can be used within a substation to integrate protection,
control and data acquisition on the substation Local Area Network (LAN).
To implement this objective the IEC, CIGRE and IEEE communities have focused
their effort on developing the specifications for peer-to-peer
communication between Intelligent Electronic Devices (IEDs). To
communicate between IEDs built by different vendors, the communication
protocol must be constrained so the IEDs are interoperable.
In this article, we will review and offer an option on what constrains
the selection of the communication protocol, and discuss some of the
issues related to implementing more than one protocol within a substation.
What constrains the selection of protocol?
Selecting a communication protocol requires one to address three basic
sets of requirements: performance, interoperability and maturity.
Performance:
Protection commands over the LAN between IED applications within 4ms is
the most demanding performance requirement. This requirement then defines
both a peer-to-peer communication protocol and either a 100Mbps
shared or 10Mbps switched Ethernet implementation. A framework that
implements a master-slave communication protocol cannot meet the 4ms
requirement between a sending application in one slave IED and the
receiving application in another slave IED. Also, no token-passing protocols
have been identified that can meet the 4ms requirement because of the time required to wait for
the token to pass the data packet.
Action: Therefore, if protection commands over the LAN between IED applications
is required, then the communication protocol must support peer-to-peer
communication between IED applications. Furthermore, either 100Mbps shared
or 10Mbps switched Ethernet should be selected.
Interoperability:
Now consider the case for communication over the substation LAN that is
used for control and monitoring only. If protection is not to be integrated with control and monitoring over
the substation LAN, then the selection of the communication protocol is
not as strongly coupled (much less demanding) to the time required to communicate a message from
the sending IED application to the receiving IED application. Keep in
mind, that multicast is still required for interlocking and other control
functions. Interoperability now becomes the dominant selection criteria.
To achieve interoperability, the information exchanged between IEDs must
be fully understood and unambiguous. This requires a well defined data
model that specifies both the syntax and semantics of the information
exchanged. Specifically, the protocol specification must define the rules
and building blocks for developing extensible objects that will be
communicated between IEDs. If a protocol specification does not include a
well defined data model, it should not be selected!
Action: All future substation automation systems should implement the
interoperability requirements. This is true for new substations as well as
for retrofitted substations. Only a protocol specification that includes a
well defined set of rules for implementing the data model should be
selected. And furthermore, a well formed project notebook should be
imposed on all vendors to ensure that every nuance of the build out of the
data model is understood and documented. It is the project notebook, not
the original protocol specification, that will be the governing document
for defining the "as-built" specification. Future changes to the
substation automation system should then be based on the project notebook.
Maturity:
Maturity is probably the most important criteria that will mitigate
cost and schedule risk for deploying a selected communication
architecture. And the most important input to the maturity analysis is
the clarity of the utility's vision for substation automation.
Maturity should be easily measured by comparing installed user bases
for a candidate protocol. However, be cautious! Technology is rapidly
changing, and each installed user base used in the comparison must be
restricted to one version of protocol specifications. That one version
should include all the
capabilities needed for a specific utility's vision of substation
automation.
Action: Who should the utility select to perform the maturity analysis is
another difficult question. Clearly the utility should not select someone
who has a built-in bias for a particular technology or solution. And, the person selected
should be knowledgeable in the following areas:
WiseOwl™
