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
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
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)
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)
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 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
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 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
.
