We agree that creating such a test scenario is not a simple
task, and to date no one or organization has started on the task. Yet the need
exists. It may ultimately be answered by an independent testing service.
In the mean time, there is a ray of hope. If one cannot do
complete system level testing, the next best thing is testing segment by
segment. The segments have now been defined in three different draft standards:
IEC TC57 WG 10's IEC draft Standard 61850-5 "Substation Automation
Systems", in the
IEEE PES Substations Committee WG C2TF4's draft of 1525 "Requirements
Specifications for Substation Integrated Protection, Control, and
Monitoring",
and in IEEE Power System Relaying Committee WG H4's draft of C37.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". Here is an excerpt from the IEC draft:
"The total transmission time includes the complete
transfer time including the handling at both ends, i.e. from the moment the
sender puts the data content on the top of its transmission stack up to the
moment the receiver extracts the data from its transmission stack. The time
requirement is applicable for the complete transmission chain as indicated in
the figure shown below. In physical device #1, a function f1 sends data to another
function f 2, located in physical device #2. The total
time will consist of the individual times of the communications processors and
the network transfer time, including wait times and the time used by routers,
hubs, and other devices that are a part of the complete network."
The now well accepted performance requirement of 4
milliseconds is that a + b + c <= 4 ms. End to end testing to one millisecond
resolution requires that the clocks in both IED #1 and IRD #2 be synchronized to
± 0.1 ms, a difficult task in itself. To obtain
finer resolution in the measurement requires even more precise synchronism.
Let’s look at the three components of the end to end
requirement. Component "a" can be tested entirely within the sending
IED. During the Summer Power Meeting, we were informed that tools now available
to IED developers are capable of measuring the elapsed time from the start of
"a" to the time that a message is transmitted on the LAN (the start of
"b"). In a laboratory test, such a measurement would no doubt be done
with no other traffic on the LAN, so LAN collisions would not be an issue.
Component "c" can also be tested entirely within the receiving IED,
using the same tools. However, component "b" cannot be tested without
the complete definition of the test scenario, as described above.
But all is not lost. Utilities should ask their IED vendors
for performance times "a" and "c". Obviously, if these times
sum to anything close to 4 ms, then there is no possibility of achieving that
figure in the presence of burst LAN traffic. Collisions will occur at the time
of heavy LAN usage, and previous simulation studies have shown their impact on
Ethernet LAN performance. Thus, allowance must be made for such delays.
If your future plans call for the use of a LAN for protection
applications, now is the time to start asking questions. Find out what
performance your IED vendors can provide. The test method is straightforward,
and not dependent on any assumptions of LAN traffic or LAN type (shared or
switched hub).
We look forward to your opinions on this issue. Let us know how you feel about this issue. What should IEEE be doing, if
anything? Where should the work take place? Keep us posted on the performance
data you are able to obtain from your vendors.
WiseOwl™
