Total 4731 registered members
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

Testiranje performansi IEC 61850 GOOSE poruka

Testiranje performansi IEC 61850 GOOSE poruka

Jedan od čestih zahteva za uređaje relejne zaštite je podrška za IEC 61850 standard. U okviru standarda predviđene su i poruke za brzu razmenu informacija između releja tzv. GOOSE (Generic object-oriented substation event). U pitanju su uglavnom trip, interlocking, breaker failure i slični signali. Vreme transfera ovih signala je kritično, njihovo kašnjenje može prouzrokovati neželjeno isključenje potrošača ili oštećenje opreme.

U ovom radu istražićemo koja softverska arhitektura je najpogodnija da se ostvare tražene performanse. Softver za slanje/prijem GOOSE poruka može se nalaziti u real time (RT) ili user space prostoru operativnog sistema. Razmotrićemo user space i RT implementacije na dve različite mikroprocesorske arhitekture – ARM9 i PowerPC.

Do degradacije performansi može doći iz 2 razloga:

  • Zaštitna funkcija ima najviši prioritet. Najmanje 500 μs tokom svake milisekunde GOOSE task će biti uskraćen za procesorsko vreme.
  • U slučaju čiste user-space implementacije operativni sistem će prekidati GOOSE task na potpuno nedeterministički način.

User Space Test

Za testiranje performansi GOOSE poruka u user space-u razvijeno je okruženje bazirano na ARM7 arhitekturi:

  • ARM7 sa integrisanim Ethernet-om za slanje, prijem i time-stampovanje poruka.
  • PC aplikacija za setovanje parametara i prikupljanje rezultata.
Slika 1. Test konfiguracija za user space test
Slika 1. Test konfiguracija za user space test

Suština testa je sledeća: ARM7 ploča lansira niz poruka i beleži odlazno vreme za svaku poruku. ARM9 i PowerPC ploče su podešene da odmah po prijemu GOOSE poruke odgovore sa identičnom porukom sa istim rednim brojem.

ARM7 ploča registruje odgovor i pomoću rednog broja uparuje poruku sa originalnom porukom i računa proteklo vreme.

Slika 2. Analiza vremena
Slika 2. Analiza vremena

Na gornjoj slici može se videti analiza utrošenog vremena. A i B su zanemarljivi. Zbog prirode testa može se precizno meriti 2C+D ali ne možemo tačno znati koliko iznose C i D pojedinačno. No, u krajnjoj liniji to i nije bitno sa stanovišta standarda. Pogledajmo rezultate testa. ARM7 ploča lansira niz GOOSE poruka u razmaku od 100ms. Rezultati se mere i prikazuju u Excel-u.

Da bi rezultat bio što realniji uključena je prekostrujna zaštita. Na Y osi prikazano je vreme u milisekundama a na X osi redni broj GOOSE poruke.

Slika 3. ARM9 100ms (X osa – redni broj poruke, Y osa vreme transfera)

Slika 3. ARM9 100ms (X osa – redni broj poruke, Y osa vreme transfera)

Vidimo da tokom 20 sekundi vreme odgovora osciluje oko 2 milisekunde. Sledeći korak je bio da se uključi još nekoliko zaštitnih funkcija tako da tokom 1 milisekunde zaštita troši 700 μs. Očekivano je da pri većem opterećenju GOOSE performanse opadnu.

To se zaista i dešava kao što možemo videti na sledećoj slici:

Slika 4. ARM9 100ms, 700μs (X osa – redni broj poruke, Y osa vreme transfera)

Slika 4. ARM9 100ms, 700μs (X osa – redni broj poruke, Y osa vreme transfera)

Vreme sada osciluje oko 7 milisekudi. Iako je očekivano da će performanse opasti, ipak je postignuti rezultat iznad očekivanja. 7 milisekundi je i dalje dovoljno za neke aplikacije. Ovo su rezultati sa ARM9 platformu. PowerPC platforma se pokazala nešto bolje, jer ima skoro 2 puta veću procesorsku snagu. Na sledeće 2 slike vidimo rezultate.

Slika 5. PowerPC 100ms (X osa – redni broj poruke, Y osa vreme transfera)

Slika 5. PowerPC 100ms (X osa – redni broj poruke, Y osa vreme transfera)

Slika 6. PowerPC 100ms, 700μs (X osa – redni broj poruke, Y osa vreme transfera)

Slika 6. PowerPC 100ms, 700μs (X osa – redni broj poruke, Y osa vreme transfera)

Pri manjem opterećenju vreme osciluje oko 0.8 ms a pri većem oko 2.5 ms. Kao što vidimo izmerena vremena se kreću u okvirima koji nude solidan dijapazon primena. Na žalost ova vremena važe samo u slučaju da je GOOSE task jedini aktivni task. U slučaju postojanja drugih taskova – na primer disturbance recorder, event recorder, embedded web server, IEC 61850 MMS server itd… vremena postaju nepredvidiva i mogu ići i do 80ms, što je naravno neprihvatljivo.

Real Time Test

Slika 7. Test konfiguracija za real time test

Slika 7. Test konfiguracija za real time test

Mada je real time GOOSE nešto teži za implementaciju, nudi neke značajne prednosti kako ćemo videti. Test okruženje za real time je značajno drugačije. Za testiranje je korišćen mrežni analizator. Program se može besplatno skinuti sa Interneta (1). Suština testa je sledeća: zaštitni relej je podešen da osluškuje poruke koje emituje laptop računar i da momentalno odgovori sa istom vrednošću dataseta koja je u dolaznoj poruci. Kada analiziramo niz poruka u mrežnom analizatoru doći ćemo do momenta kada relej i laptop emituju identičnu vrednost.

Vreme između momenta kada laptop počinje sa emitovanjem i momenta kada relej počne da emituje istu vrednost kao i laptop je traženo vreme.

Na sledećoj slici možemo videti rezultate prikazane u mrežnom analizatoru.

Slika 8. Ethereal mrežni analizator

Slika 8. Ethereal mrežni analizator

Slika 9. Niz GOOSE poruka sa vremenima prijema, mrežnim adresama i oznakom protokola

Slika 9. Niz GOOSE poruka sa vremenima prijema, mrežnim adresama i oznakom protokola

Poruku broj 42 emituje laptop,a poruku 43 relejna zaštita. Ako oduzmemo vremena prijema: 3,757 – 3,753 = 4msec. Pri ponovljenim merenjima rezultat osciluje oko 4ms. Razlog za to je što su taskovi za slanje i prijem podešeni da se bude na svake 2 milisekunde.

Zaključak

Na prvi pogled real time i user space implementacije operišu u sličnim vremenskim okvirima. Ali, postoji ozbiljna razlika. Kod RT implementacije GOOSE task može da deli procesor sa proizvoljnim brojem ostalih taskova kao što je disturbance recorder i sl. Takva arhitektura u mnogome smanjuje krajnju cenu uređaja i daje korisniku više funkcionalnosti. U suprotnom bi GOOSE softver morao da obitava na zasebnom hardveru.

.

AUTOR STRUČNOG TEKSTA:

Veljko Milisavljević | ABS Control Systems, Srbija

Veljko Milisavljević

Veljko Milisavljević

.

Related articles