Total 4731 registered members
Top
Comment
sep
sep
sep
Email It!

Testing performances of IEC 61850 GOOSE messages

5,265 views

Testing performances of IEC 61850 GOOSE messages

Testing performances of IEC 61850 GOOSE messages

One of the frequent requests for relay protection devices is support for the IEC 61850 standard. As part of the standard special messages are also planned for a quick exchange of information between the IEDs – so called  GOOSE (Generic Object-Oriented SubStation Event). These are mainly trip, interlocking, breaker failure and similar signals. Time of transfer of these signals is critical, its delay may cause undesirable blackouts  or damage to equipment.

In this paper we explore which software architecture is most appropriate to achieve the required performance. Software for sending / receiving GOOSE messages can be located in real time (RT) or user space of the operating system. We will consider the RT and user space implementations of two different microprocessor architecture – ARM9 and PowerPC.
Performance degradation can occur from 2 reasons:

  • Protection  function has the highest priority. At least 500 μs during each millisecond GOOSE thread will be deprived of CPU time.
  • In the case of pure user-space implementation, the operating system will interrupt GOOSE task in a completely nondeterministic way.

User Space Test

To test the performance of GOOSE messages in user space, the environment is developed based on the ARM7 architecture:

  • ARM7 with integrated Ethernet for sending, receiving and time-stamping of messages.
  • The PC application for setting parameters and collecting the results.
Figure 1 Test configuration for user space test
Figure 1 Test configuration for user space test

The essence of the test is as follows: ARM7 board launches a series of messages and records the time for each outgoing message. ARM9 and PowerPC boards are set up to immediately respond to received GOOSE messages  with identical message and  with the same serial number.
ARM7 registers  the answer and uses the serial number to match with the original message and calculates the elapsed time.

Figure 2 Analysis time
Figure 2 Analysis time

On the figure above we can see the analysis of time. A and B are negligible. Due to the nature of the test 2C + D  can be accurately measured but we can’t know exactly  the amounts of C and D are respectively. But ultimately this is not important from the point of standards. Let’s look at test results. ARM7 board launches a series of GOOSE messages with pause of 100ms. Results are measured and displayed in Excel.

To make it more realistic result overcurrent protection was turned on.  Y axis shows the time in milliseconds and the X axis shows GOOSE messages.

Figure 3 ARM9 100ms (X axis - number of messages, the Y axis the time of transfer)
Figure 3 ARM9 100ms (X axis – number of messages, the Y axis the time of transfer)

We see that during 20 seconds response time oscillates around 2 milliseconds. The next step was to involve several protection functions. It is expected that the GOOSE performance will drop.

This is actually happening as we see in the following figure:

Figure 4 ARM9 100ms, 700μs (X axis - number of messages, the Y axis the time of transfer)
Figure 4 ARM9 100ms, 700μs (X axis – number of messages, the Y axis the time of transfer)

The time now oscillates about 7 ms. Although it is expected that the performance will decline, it is still above expectations. 7 milliseconds is still enough for some applications. These are the results from the ARM9 platform. PowerPC platform has proved to be something better, because it has almost 2 times more processing power. On the next 2 images we see the results.

Figure 5 PowerPC 100ms (X axis - number of messages, the Y axis the time of transfer)
Figure 5 PowerPC 100ms (X axis – number of messages, the Y axis the time of transfer)

Slika 6. PowerPC 100ms, 700μs (X osa – redni broj poruke, Y osa vreme transfera)
Figure 6 PowerPC 100ms, 700μs (X axis – number of messages, the Y axis the time of transfer)

In a small load time oscillates around 0.8 ms and at most about 2.5 ms. The measured  times are suitable for  a solid range of applications. Unfortunately, these times are only valid if the GOOSE task is only active task. In the case of other tasks – for example, disturbance recorder, event recorder, embedded web server, IEC 61850 MMS server and so on … transfer time become unpredictable and can go up to 80ms, which is of course unacceptable.

Real Time Test

Figure 7 Test configuration for real-time test
Figure 7 Test configuration for real-time test

Although the real time GOOSE is something more difficult to implement, it offers some significant advantages as we shall see. Test environment for real-time is significantly different. The network analyzer was used. The program is available as a free download from the Internet (1). The essence of the test is as follows: protection relays is configured to receive GOOSE messages from a laptop computer and to immediately respond with the same value in the dataset. When analyzing a series of messages network analyzer will come to the moment when the relay and laptops are sending an identical value.
The time between the moment when the laptop starts broadcasting and the moment the relay begins to broadcast the same value as the laptop is the required time.

In the following figure we can see the results displayed in the network analyzer.

Figure 8 Ethereal Network Analyzer
Figure 8 Ethereal Network Analyzer

Figure 9 Goose series with a time of receipt of messages, network addresses and protocol label
Figure 9 Goose series with a time of receipt of messages, network addresses and protocol label

Message number 42 is from a laptop, a message 43 from relay protection. If you subtract the time of receipt: 3.757 to 3.753 = 4msec. When measurements  are repeated result oscillates around 4ms. The reason for this is that the task for sending and receiving is set to be run every 2 milliseconds.

Conclusion

At first glance, real-time and user space implementation operates in a similar timeframe. But there is a substantial difference. GOOSE  RT implementation task may share the processor with an arbitrary number of other task such as the disturbance recorder and others. This architecture greatly reduces the ultimate cost of the device and gives the user more functionality. Otherwise the GOOSE software would have to reside on separate hardware.

.

AUTHOR OF ARTICLE:

Veljko Milisavljević | ABS Control Systems, Serbia

Veljko Milisavljević

Veljko Milisavljević

.

Related articles


Be nice and share this article with others! How to use all these nice buttons?

Del.icio.us Digg Mixx Reddit Technorati Linkedin Email this post Save to Google bookmarks Save to Yahoo Buzz Save to Reddit Save to Technorati
Tell us what you're thinking about article you just read.

Turn Your Thoughts Into Words

Tell us what you're thinking... we care about your opinion!
and oh, not to forget - if you want a picture to show with your comment, go get a free Gravatar!

*



Comments

One Response to “Testing performances of IEC 61850 GOOSE messages”

    Trackbacks

    Check out what others are saying about this post...
    1. [...] REF615 IEC 61850 implementation includes GOOSE messaging for fast horizontal relay-to-relay communication. Applying GOOSE communication to the REF615 relays [...]