26.3.2024

Komunikácia – protokol IEC 104

Komunikačný protokol IEC 104 je určený na zber telemetrických dát a riadenie v energetike. Používa sa na komunikáciu medzi dvoma systémami prepojenými TCP/IP sieťou. V podstate ide o sieľovú variantu IEC 101 vylepšenú o mechanizmy využívajúce výhody TCP oproti sériovej linke - vyššie prenosové rýchlosti, garantovaný a bezchybný prenos dátového toku - na zvýšenie rýchlosti prenosu a potlačenie vplyvu latencie. Pred prečítaním tohto článku je preto vhodné byť oboznámený s  protokolom IEC 101.

IEC 104 používa na prenos dát v monitorovacom smere tie isté ASDU-čka (Application Service Data Units) ako IEC 101 – v skutočnosti sa pri definícii priamo odvoláva na IEC 101 v zhode s modularitou štandardov IEC 60870-5, medzi ktoré patrí (keďže jeho plné meno je IEC 60870-5-104).

 

IEC104_01.png

Obr 1 – ASDU v monitorovacom smere sú prebraté z IEC 101

 

V riadiacom smere k ním pridáva  príkazové ASDU 58-64 (varianty s 56-bitovou časovou značkou), ktoré sme spomenuli už v článku o IEC 101 – keďže D2000 KOM ich podporuje aj v IEC 101 protokole.

 

IEC104_02.png

Obr 2 – ASDU v riadiacom smere sú prebraté z IEC 101 a rozšírené o varianty s časovou značkou

 

Čím sa teda IEC 104 líši od IEC 101 a ako dosahuje výhody spomínané vyššie?

Formát paketov

Jednotlivé pakety protokolu IEC 104 začínajú START bajtom (0x68), nasleduje bajt s dĺžkou dát, štvorbajtové riadiace pole (control field) a samotná ASDU.  Pre porovnanie, rámec IEC 101 s variabilnou dĺžkou začína START, nasleduje dvakrát dĺžka a znovu START. Keďže TCP (na rozdiel od sériovej linky) zaručuje bezchybný prenos dátového toku, nie je nutné START ani dĺžku zdvojovať.

 

IEC104_03.png

Obr 3 – formát dátových paketov obsahujúcich ASDU

 

Existuje aj krátky formát paketov bez ASDU (vtedy má pole dĺžka hodnotu 4 bajty).

 

IEC104_04.png

Obr 4 – formát paketov bez dátovej časti

 

Na čo sa takéto pakety používajú? Na riadiace účely (začiatok/koniec dátového prenosu), na posielanie testovacích rámcov a potvrdzovanie správ. Na vysvetlenie detailov sa musíme bližšie pozrieť na štruktúru štvorbajtového riadiaceho poľa.

IEC 104 definuje tri formáty riadiaceho poľa:

  • I- formát (information) sa používa pre rámce obsahujúce ASDU (I-rámce alebo I-frames). Obsahuje 15-bitové SSN (Send Sequence Number) a RSN (Receive Sequence Number). Každá strana zvyšuje pri poslaní I-rámca svoje SSN a zároveň nastavuje RSN na hodnotu o jednu vyššiu ako posledné prijaté SSN. RSN slúži na potvrdzovanie prijatia rámcov. Pokiaľ teda stanica chce poslať ASDU, v rámci posielaných dát vie potvrdiť prijaté dáta (technika, ktorá sa v komunikácii nazýva piggybacking).
IEC104_05.png

Obr 5 – I-formát riadiaceho poľa pre rámce s ASDU

  • S-formát (supervisory) sa používa na potvrdzovanie I-rámcov. Stanica posiela S-rámec na potvrdenie prijatia I-rámcov, ktorých SSN je menšie ako RSN uvedené v S-rámci. Tento rámec posiela stanica v prípade, že nemá žiadne dáta, ktoré by chcela poslať I-rámcom (typicky  IEC 104 klient, ktorý väčšinou iba prijíma dáta od IEC 104 servera a iba občas pošle príkaz).
IEC104_06.png

Obr 6 – S-formát riadiaceho poľa pre rámce potvrdzujúce príjem ASDU

  • U-formát (unnumbered) neobsahuje SSN ani RSN a používa sa v 3 špeciálnych prípadoch:
  • StartDT activation/confirmation –žiadosť o posielanie dát cez vytvorené spojenie a jej potvrdenie (žiadosť posiela klient, potvrdenie server).
  • StopDT activation/confirmation – žiadosť o ukončenie posielania dát a jej potvrdenie (žiadosť posiela klient, potvrdenie server).
  • TestFR activation/confirmation – poslanie testovacieho rámca a odpovede naň. Testovacie rámce môžu byť posielané obidvoma stranami na overenie funkčnosti TCP kanála, pokiaľ dlhšiu dobu neprišiel iný rámec. Norma definuje dobu nečinnosti ako timeout t3 s prednastavenou hodnotou 20 sekúnd a v parametroch protokolu v D2000 je možné ju zmeniť (parameter Wait Timeout T3).
IEC104_07.png

Obr 7 – U-formát riadiaceho poľa

 

Nadväzovanie spojenia

Riadená stanica v IEC 104 protokole funguje ako TCP server (prijíma klientov). Riadiaca stanica je TCP klient (pripája sa k serveru). Závisí od konkrétnej implementácie, či IEC 104 server podporuje iba obsluhu jedného klienta (single server) alebo viacerých (multiserver). Protokol „IEC 104 Server“ implementovaný v D2000 je schopný paralelne obslúžiť viacerých klientov, pričom pre každého klienta vytvára samostatné obslužné tasky na čítanie a zápis.

 

IEC 104 server počúva na definovanom porte (štandardne TCP port 2404 pridelený IANA). Po pripojení klient štandardne pošle ako prvý U-rámec StartDT activation a server mu odpovie U-rámcom StartDT confirmation. Následne server môže posielať klientovi dátové ASDU so zmenami hodnôt a klient môže posielať príkazové ASDU s príkazmi.

 

Pokiaľ klient nepošle U-rámec StartDT activation, cez takéto spojenie nesmú byť posielané dátové ASDU (v I-rámcoch) ale iba U-rámce TestFR activation/confirmation na overenie, že TCP spojenie je funkčné. Táto možnosť je užitočná, pokiaľ  klient vytvára viacero spojení na server (napr. cez redundantné siete A a B). Aby nezaťažoval server, komunikuje cez sieť A a až v prípade výpadku siete A aktivuje posielanie dát cez spojenie sieťou B. Podobne, pokiaľ sa takýto klient rozhodne zmeniť aktívne spojenie aj bez rozpadu spojenia A a začať komunikovať cez spojenie B, pošle StartDT activation cez spojenie B a StopDT activation cez spojenie A.

Potvrdzovanie dátových rámcov s ASDU

Ako bolo už spomenuté vyššie, na potvrdzovanie slúžia SSN a RSN. Nasledujúci obrázok ukazuje posielanie I-rámcov (v zátvorkách je SSN a RSN) a ilustruje ich potvrdzovanie. Stanica A po prijatí rámca s SSN=2 pošle rámec s RSN=3 (ktorý potvrdí príjem SSN 0, 1 a 2). Stania B po prijatí rámca s SSN=1 pošle rámec s RSN=2 (ktorý potvrdí príjem SSN 0 a 1).

 

IEC104_08.png

Obr 8 – vymena I-rámcov s potvrdzovaním

 

Pokiaľ stanica A nechce posielať I-rámce, norma definuje timeout t2, po uplynutí ktorého musí stanica potvrdiť príjem S-rámcom. V D2000 je tento  parameter označený ako Wait Timeout T2 a prednastavená hodnota je v zhode s normou 10 sekúnd.

IEC104_09.png

Obr 9 – potvrdzovanie S-rámcom

 

Pokiaľ hociktorá stanica do timeoutu t1 (15 sekúnd) neobdrží potvrdenie poslaného I-frame alebo odpoveď na poslaný U-frame (t.j. na StartDT, StopDT alebo TestFR activation), spojenie považuje za nefunkčné a zruší ho. Situáciu ukazuje nasledujúci obrázok, na ktorom stanica B dostala potvrdenie rámca s SSN=0, ale nie ďalšieho zaslaného s SSN=1 a preto po čase t1 od poslania tohto rámca spojenie zatvorila.

 

IEC104_10.png

Obr 10 – zatvorenie spojenia po vypršaní t1

 

Ďalej norma definuje parameter k udávajúci maximálny počet poslaných a nepotvrdených ASDU. Pokiaľ stanica poslala k ASDU (prednastavená hodnota 12), nepošle ďalšie a čaká na príjem potvrdzujúceho S alebo I rámca.

Zároveň definuje parameter w udávajúci počet ASDU, po prijatí ktorých musí stanica poslať S-frame (prípadne I-frame). Prednastavená hodnota parametra w je 8.

 

IEC104_11.png

Obr 11 – prednastavené hodnoty parametrov k a w

 

Rozdiel hodnôt parametrov k-w (štandardne 4) udáva počet ASDU „na ceste“, t.j. poslaných jednou stanicou a ešte nespracovaných druhou. V konkrétnych prípadoch (WAN spojenia s vyššou latenciou) sa osvedčilo v praxi zvýšiť hodnoty parametrov k a w (až desaťnásobne, tj. k=120, w=80) na elimináciu vplyvu latencií (latencie siete a prípadne latencie prijímacej stanice spôsobenej napr. zaťažením CPU) na zabezpečenie vysokej priepustnosti spojenia a na zabránenie „zadrhávaniu sa“ z dôvodu čakania na potvrdenie po poslaní k rámcov.

 

Zvýšenie hodnôt parametrov teda dokáže eliminovať aj vplyv latencie na úrovni stoviek milisekúnd, pre ktorú by bol sériový IEC 101 protokol pre väčšie množstvá zmien už prakticky nepoužiteľný (cyklus dotaz-odpoveď by trval tak dlho, že by sa hromadili neposlané hodnoty). 

 

V druhej časti článku si popíšeme fungovanie interrogation, rozdiely medzi nebalancovaným a balancovaným módom a synchronizáciu času. Ako bonus spomenieme zvláštnosti niektorých implementácií IEC 104 a vlastnosti "nad rámec normy", ktoré sa dajú použiť D2000.

 

13,11.2017, Ing. Peter Humaj, www.ipesoft.com

Iné blogy