Komunikácia – protokol IEC 101, časť 3

V tomto dokončení článku "Komunikácia – protokol IEC 101, časť 2" prejdeme najpoužívanejšíe ASDU definované v IEC 101 (dátové aj príkazové), prejdeme postup nadväzovania spojenia v nebalancovanom aj balancovanom móde a vyžiadanie si všetkých hodnôt príkazmi Interrogation. Spomenieme aj správanie sa na redundantných linkách a špecifiká implementácie v systéme Sinaut Spectrum.

 

Pre laikov platí to isté varovanie ako pre prvý diel :-)

ASDU na prenos binárnych a štvorstavových informácií

ASDU 1, 2 a 30 typu „single-point information“ sa líšia iba použitou časovou značkou (žiadna, 24 alebo 56-bitová).

Identifikátor ASDU obsahuje všetky vyššie definované polia – typ (1, 2 alebo 30), kvalifikátor variabilnej štruktúry (VSQ) udávajúci počet objektov a informáciu, či má každý vlastnú adresu, alebo či je zadaná iba adresa prvého objektu, polia príčina poslania (COT) a adresa ASDU.

 

Ďalej ASDU obsahuje jeden alebo viacero informačných objektov. Každý z nich (alebo iba prvý – podľa VSQ) obsahuje adresu, nasleduje samotná binárna hodnota (bit SPI + príznaky kvality: Invalid, Non topical, Substituted a Blocked definované v IEC 60870-5-4). Nasleduje časová značka – žiadna, 24 alebo 56-bitová, podľa typu ASDU.

 

IEC101_22.png

Obr 22 – ASDU 2 – “single-point information with time tag”

 

ASDU 3, 4 a 31 typu „double-point information“ určené na prenos štvorstavových informácií sú prakticky rovnaké ako ASDU na prenos binárnych informácií. Rozdiel je iba v samotnom bajte popisujúcom štvorstavovú hodnotu. Štvorstav okrem hodnôt ON a OFF (v D2000 označované Q_ON a Q_OFF) dokáže preniesť hodnotu „intermediate“ (v D2000 Q_TRANS) a „indeterminate“ (v D2000 Q_ERR).

 

IEC101_23.png

Obr 23 – formát štvorstavovej hodnoty s príznakmi použitej v ASDU 3, 4 a 31

 

ASDU na prenos celočíselných a reálnych informácií

Na prenos 32-bitových celých čísel je možné použiť buď skupinu ASDU 7, 8 a 33 typu „bitstring of 32 bits“ bez časovej značky, s 24 a 56-bitovou časovou značkou, prípadne skupinu ASDU  15, 16 a 37 typu „integrated totals“. Čím sa tieto dve skupiny líšia? Už z názvu prvej je zrejmé, že 32-bitov tvorí „bitstring“, t.j. sériu binárnych informácií, ktorá má spoločný deskriptor kvality. Pokiaľ sa používajú tieto ASDU v systéme D2000, interpretuje sa bitstring ako celé číslo so znamienkom (signed integer).

 

IEC101_24.png

Obr 24 – ASDU 7 – „bitstring of 32 bits“

 

Druhá skupina – integrated totals – už podľa názvu prenáša hodnoty počítadiel (integrovaných súčtov). 32-bitové číslo je chápané ako celočíselné so znamienkom. Okrem príznaku Invalid sú prenášané príznaky CY (carry overflow – došlo k pretečeniu počítadla) a CA (counter adjusted – došlo k úprave počítadla).

 

IEC101_25.png

Obr 25 – ASDU 16 – „integrated totals with time tag“ a popis jednotlivých polí

 

Medzi týmito dvoma skupinami ASDU existuje ešte jeden rozdiel. Keď primárna stanica po nadviazaní spojenia chce zistiť aktuálne hodnoty všetkých objektov, môže poslať ASDU 100 – „interrogation command“ alebo ASDU 101 – „counter interrogation command“. Odpoveďou na ASDU 100 sú podľa normy ASDU 1-14, 20-21, 30-36. Odpoveďou na counter interrogation sú práve ASDU 15-16 a 37 (integrated totals). Nie každá implementácia toto striktne dodržuje – aj v D2000 je možné parametrom „Interrogation Covers Counters“ nastaviť, že ako odpoveď na ASDU 100 sa pošlú aj hodnoty počítadiel.

Okrem možnosti prenosu 4-bajtových čísel existuje aj skupina ASDU 9, 10 a 35 – „measured value, normalized value“, „measured value, normalized value with time tag“ a „measured value, normalized value with time tag CP56Time2a“ na prenos dvojbajtového celého čísla so znamienkom.

 

Pokiaľ stačí prenášať celé číslo z rozsahu -64 až 63, sú k dispozícii ASDU 5, 6 a 32 – „step position information“, „step position information with time tag“ a „step position information with time tag CP56Time2a“.

 

Na prenos reálnych informácií je určená skupina ASDU 13, 14 a 36 typu „measured value, short floating point value“, opäť bez časovej značky, s krátkou a dlhou časovou značkou. Tieto ASDU prenášajú 32-bitové reálne číslo v štandardnom formáte IEEE STD 754.

 

IEC101_26.png

Obr 26 – ASDU 36 - „measured value, short floating point value with time tag CP56Time2a“

 

Existuje aj skupina ASDU 9, 10 a 34 „measured value, normalized value“ na prenos normalizovanej hodnoty z intervalu <-1, 1>  pomocou šestnásťbitovej hodnoty. Výhodou je opäť úspornosť, v praxi sme tieto ASDU nepoužili.

Príkazové ASDU

Aké ASDU sa používajú v riadiacom smere - od riadiacej stanice k riadenej? Predtým, ako si odpovieme na túto otázku, skúsme si prejsť rozdiely medzi dátovými ASDU (využívanými na prenos monitorovanej informácie v monitorovacom smere) a príkazovými ASDU (využívanými na prenos riadiacej informácie v riadiacom smere):

  • Dátové ASDU nie sú explicitne potvrdzované.
  • Príkazové ASDU sú explicitne potvrdzované: norma hovorí, že príkaz ide s poľom Cause of transmission (COT) nastaveným na hodnotu activation (6), potvrdenie posielané riadenou stanicou je identické, ale s COT=activation confirmation (7) a následne COT=activation termination (10). Keďže niektoré implementácie posielajú iba COT=7, iné COT=10, ďalšie obidve potvrdenia alebo dokonca žiadne potvrdenie, v D2000 je možné nastaviť očakávané potvrdzovanie (ak je D2000 riadiaca stanica ) v parametri „Accept Confirmation Command“ a posielané potvrdzovanie (ak je D2000 riadená stanica ) v parametri „Send Confirmation Command“ . Možné hodnoty parametrov sú žiadne potvrdzovanie, potvrdzovanie s COT=7, potvrdzovanie s COT=10 a potvrdzovanie s COT=7 a následne COT=10.
  • Ako odpoveď na „interrogation command“ chodia iba dátové ASDU, nikdy nie príkazové ASDU. Pokiaľ má byť teda hodnota prenesená po nadviazaní komunikácie, musí byť posielaná ako dátová ASDU. Ak má byť hodnota prenesená iba ako dôsledok nejakej akcie (napr. povel dispečera), musí byť posielaná ako príkazová ASDU.

ASDU na prenos binárnych a štvorstavových príkazov

ASDU 45 a 58 – „single command“ a „single command with time tag CP56Time2a“ slúžia na prenos jednobitového povelu ON/OFF, ktorý je v najnižšom bite (SCS). Päť bitov QU (qualifier of command) slúži na nastaveni e rôznych príznakov (napr. či ide o krátky/dlhý impulz alebo permanentnú zmenu). Najvyšší bit S/E slúži na nastavenie príznaku Select(0)/execute(1). D2000 KOM proces dokáže nastavovať tieto bity pomocou flagov hodnoty FLA .. FLH.

 

IEC101_27.png

Obr 27 – ASDU 45 – „single command“

 

ASDU 46 a 59 – „double command“ a „double command with time tag CP56Time2a“ sú prakticky totožné, líšia sa iba reprezentáciou ON/OFF, ktorá zaberá 2 bity, pričom kombinácie 00 a 11 sú zakázané.

 

IEC101_28.png

Obr 28 – ASDU 46 – „double command“

 

Takmer totožné ako „double command“ ASDU sú 47 a 60 – „regulating step command“ a „regulating step command with time tag CP56Time2a“. Líšia sa iba významom bitov – krok dole a krok hore:

 

IEC101_29.png

Obr 29 – ASDU 47 – „regulating step command“

 

ASDU na prenos celočíselných a reálnych príkazov

ASDU 51 a 64 - „bitstring of 32 bits“ a „bitstring of 32 bits with time tag CP56Time2a“ sa dajú v systéme D2000 použiť na zápis 32-bitového celého čísla so znamienkom. Norma nedefinuje príkazový ekvivalent k dátovému ASDU „integrated totals“ (zrejme preto, lebo sa jedná o počítadlá určené iba na čítanie).

 

IEC101_30.png

Obr 30 – ASDU 51 – „bitstring of 32 bits“

 

Pokiaľ si vystačíme so 16-bitovým číslom so znamienkom, je možné použiť ASDU 49 a 62  - „set point command, scaled value“ a „set point command, scaled value with time tag CP56Time2a“. Bajt QOS obsahuje najvyšší S/E bit rovnako ako ASDU „single/double command“ a zvyšné bity QL sú prakticky vždy rovné nule.

 

IEC101_31.png

Obr 31 – ASDU 49 - „set point command, scaled value“

 

ASDU 50 a 63 – „set-point command, short floating point number“ a „set-point command, short floating point number with time tag CP56Time2a“ umožňujú ako povel preniesť 32-bitové reálne číslo vo štandardnom formáte IEEE STD 754. Súčasťou ASDU je bajt QOS s rovnakým významom ako pri ASDU 49 (viď Obr 31).

 

IEC101_32.png

Obr 32 – ASDU 50 - „set-point command, short floating point number“

 

Podobne ako existujú ASDU na prenos hodnoty z intervalu <-1, 1> pomocou šestnásťbitovej hodnoty, existujú aj ekvivalentné príkazové ASDU 48 a 61 – „set-point command, normalized value“ a „set-point command, normalized value with time tag CP56Time2a“. Aj tieto majú QOS bajt.

 

IEC101_33.png

Obr 33 – ASDU 48 - „set-point command, normalized value“

 

Toto bol prehľad najpoužívanejších ASDU používaných v monitorovacom a riadiacom smere. Teraz si prejdime procedúry na nadväzovanie spojenia na začiatku komunikácie, resp. po detekcii rozpadu spojenia.

 

Nadväzovanie spojenia a interrogation

V nebalancovanej komunikácii vysiela primárna stanica linkovú požiadavku „Request status of link“ – viď Obr 13, funkčný kód 9. Sekundárna stanica odpovedá „Status of link“ – funkčný kód 11. Primárna stanica už vie, že linka je priechodná a pošle požiadavku „Reset of remote link“ – funkčný kód 0. Sekundárna stanica reinicializuje stavové premenné komunikácie a pošle odpoveď „Ack“ – funkčný kód 0 (alebo „Nack“, funkčný kód 1, ak má problémy). Tým je nadväzovanie spojenia skončené.

 

Primárna stanica pokračuje posielaním žiadostí o dáta „Request user data class 1/2", funkčné kódy 10 a 11. Sekundárna stanica ešte voliteľne môže poslať ASDU 70 – „end of initialization“ – v D2000 túto možnosť riadi parameter protokolu „Send EOI“. Odpoveďou na žiadosti „Request user data class 1/2" sú ASDU s hodnotami objektov.

 

Po nadviazaní komunikácie primárna stanica spravidla pošle ASDU 100 resp. 101 – „interrogation command“ resp. „counter interrogation command“, ktorými si vyžiada zaslanie hodnôt všetkých objektov resp. všetkých počítadiel (ASDU 15, 16 a 37). Pokiaľ je D2000 sekundárna stanica, tak parameter protokolu „Interrogation Covers Counters“ umožňuje poslať ako odpoveď na ASDU 100 aj hodnoty počítadiel - bez toho, aby primárna stanica posielala ASDU 101.

 

V balancovanom móde je nadväzovanie spojenia podobné, akurát požiadavky „Request status of link“ a „Reset of remote link“ vysielajú aj potvrdzujú obidve strany (funkčné kódy viď Obr 14). Po nadviazaní spojenia každá stanica môže poslať požiadavky „SND/CONF User data“ na vyžiadanie si zmenených dát.  Každá stanica môže poslať aj ASDU 100 a 101 na vyžiadanie si hodnôt všetkých objektov.

 

V balancovanom móde môže každá stanica poslať požiadavku „Test function for link“, funkčný kód 2, na ktorú očakáva odpoveď „Ack“ alebo „Nack“. Načo je dobrá odpoveď „Nack“, sa dozviete v ďalšej kapitole.

 

Poznámka: niektoré implementácie posielajú ASDU 100 a 101 aj periodicky, na „refresh“ aktuálneho stavu.

 

IEC 101 na redundantných linkách

Samotná norma IEC 101 sa nezaoberá konfiguráciou, v ktorej by existovali redundantné komunikačné trasy (linky) medzi stanicami.

Existuje ale tzv. Nórska konvencia (Norwegian IEC 870-5-101 User Conventions), ktorá definuje chovanie na redundantných linkách. Norma špecifikuje primárnu linku (aktívne používanú) a záložnú. Zároveň hovorí, že v praxi môžu mať linky rôzne komunikačné rýchlosti.

V nebalancovanom móde platia nasledovné pravidlá:

  • Riadiaca stanica rozhoduje o tom, ktorú linku považuje na primárnu.
  • Riadiaca stanica pri štarte komunikácie vyšle požiadavku “Request status of link” na obidvoch linkách.
  • Po prijatí odpovede pošle riadiaca stanica požiadavku „Reset of remote link“ na tej linke, ktorú považuje za primárnu – tým informuje riadenú stanicu, po ktorej linke sa bude komunikovať .
  • Riadiaca stanica môže periodicky posielať “Request status of link” na záložnej linke na zistenie jej stavu.
  • V prípade prerušenia komunikácie na primárnej linke, prípadne z iného dôvodu (napr. na príkaz operátora) môže primárna stanica zmeniť primárnu linku –pošle príkaz „Reset of remote link“ na novú primárnu linku. Následne môže (ale nemusí) poslať „interrogation command“.

 

V balancovanom móde je situácia obdobná:

  • Riadiaca stanica rozhoduje o tom, ktorú linku považuje na primárnu (v D2000 sa konfiguruje, či je stanica riadiaca alebo riadená pomocou parametra protokolu “Physical Transmission Direction”).
  • Riadiaca aj riadená stanica posielajú pri nadväzovaní komunikácie “Request status of link” aj „Reset of remote link“ na obidvoch linkách.
  • Riadiaca stanica pošle „interrogation command“ na linke, ktorú považuje za primárnu.
  • Riadiaca stanica periodicky posiela požiadavku „Test function for link“ na primárnej aj záložnej – riadená stanica odpovedá „Ack“ na primárnej linke a „Nack“ na záložnej (je povolené aj posielanie testovacej požiadavky riadenou stanicou a odpovedanie riadiacou).

 

Dôležité je uvedomiť si, že všetky užívateľské dáta (ASDU) chodia cez primárnu linku – záložná (väčšinou pomalšia) je zaťažovaná iba správami  “Request status of link” pri štarte komunikácie a „Reset of remote link“  resp. „Test function for link” periodicky na zistenie funkčnosti linky.

 

Špecifiká Sinaut na redundantných linkách

Prvá verzia Nórskej konvencie pochádza až z roku 1997 – toto môže byť dôvodom, prečo ju niektoré implementácie nerešpektujú. Menovite implementácia IEC 101 v Siemens produkte Sinaut Spectrum má niekoľko odlišností, ktoré spôsobili vznik parametra protokolu “Sinaut Mode” na prispôsobenie chovania sa D2000 systému Sinaut Spectrum. Sinaut je v komunikácii vždy riadiaca stanica, takže D2000 je riadená.

V nebalancovanom móde má Sinaut tieto odlišnosti:

  • Sinaut posiela „interrogation command“ na oboch linkách a očakáva odpovede na ne.
  • Sinaut posiela žiadosti o dáta „Request user data class 1/2" na oboch linkách, hodnoty prijaté po záložnej linke ignoruje.
  • Sinaut posiela príkazové ASDU cez primárnu linku.

V balancovanom móde má Sinaut tieto odlišnosti:

  • Sinaut posiela nové hodnoty cez obidve linky (nielen cez primárnu).
  • Sinaut posiela „interrogation command“ na linke, ktorú považuje za primárnu.
  • Sinaut spracúva nové hodnoty iba na primárnej linke – hodnoty prijaté po záložnej linke ignoruje.
  • Sinaut ako odpoveď na „Test function for link“ očakáva na oboch linkách „Ack“.
  • Sinaut posiela príkazové ASDU cez primárnu linku

 

V prípade nebalancovaného módu D2000 posiela hodnoty Sinautu cez obidve linky a spracúva všetky príkazové ASDU od Sinautu.

V prípade balancovaného módu sa D2000 chová rovnako. Po prijatí “interrogation command” sa síce dá zistiť, ktorú linku považuje Sinaut za primárnu, ale pokiaľ je na strane D2000 redundantný systém a dôjde k prepnutiu redundancie D2000 – a začne komunikovať nový D2000 KOM proces –tak Sinaut vôbec nemusí zistiť, že k niečomu takémuto došlo (prepnutie redundancie je ‘beznárazové’) a teda nedetekuje ho ako rozpad spojenia a nepošle “interrogation command”. Takže aktívny D2000 KOM nemá ako zistiť, cez ktorú linku má posielať hodnoty, a je jednoduchšie posielať ich cez obe. Pokiaľ Sinaut pošle požiadavku „Test function for link“, D2000 na oboch linkách odpovedá pozitívnym „Ack“.

 

Synchronizácia času

ASDU 103 “clock synchronization command” je určená na synchronizáciu času riadenej stanice. Obsahuje 56 – bitový zložkový čas, ktorý je využívaný aj inými ASDU.

 

IEC101_34.png

Obr 34: ASDU 103 - “clock synchronization command”

 

Záver

Čo dodať na záver? IEC 101 je v sériovej telemetrii často používaný protokol. V rámci slovenskej energetiky postupne nahradzuje proprietárny TG-80x (pôvodne vyvinutý Telegyrom, dnes patriaci Siemensu) a používa sa na telemetriu aj v iných odvetviach.  Nevýhodou IEC 101 protokolu, ktorá obmedzuje jeho použitie na WAN trasách, je limitovaná dátová priepustnosť – jednak v dôsledku používaných bitových rýchlostí, ale najmä v dôsledku latencií – keďže zmeny hodnôt sú posielané na dotaz primárnej stanice, takže z tohto pohľadu sa jedná o protokol typu request/response.

 

Pokiaľ je možné prepojiť komunikačné stanice ethernet sieťou, vhodnejší ako IEC 101 je variant IEC 104, ktorý používa tie isté ASDU ako IEC 101, ale umožnuje spontánne posielanie zmien, ktoré s definovaním veľkosti vysielacieho okna dokáže potlačiť vplyv latencie. Ale to je už téma na iný článok.

 

23,10.2017, Ing. Peter Humaj, www.ipesoft.com

Topics: Napísali sme, D2000

Za IPESOFT pre Vás napísal

Peter Humaj

Peter Humaj

e-mail: humaj.peter@ipesoft.com