V mojom predchádzajúcom blogu „Čo zvláda Raspberry Pi?“ som testoval konfiguráciu, kde bol na Raspberry Pi nainštalovaný systém D2000. Jeho komunikačný proces (D2000 KOM) slúžil ako Modbus TCP Server aj ako Modbus TCP Client. Ukázal som, že Raspberry Pi dokázal odosielať/prijímať hodnoty 100 meraných bodov (jedna zmena každého bodu za sekundu) a uložiť ich do lokálnej databázy PostgreSQL. Potom som vytvoril „rýchlu“ konfiguráciu s použitím iba 10 meraných bodov, ktoré boli dotazované „tak rýchlo, ako sa dá“. Výsledkom bolo 1290 - 1390 hodnôt za sekundu (čas vzorkovania jednotlivých hodnôt každého meraného bodu bol pod 10 ms), ktoré boli opäť uložené v databáze PostgreSQL.

Pred približne rokom som sa zapojil do diskusie na Reddit-e. Istý Reddit užívateľ požadoval zápis niekoľkých meraných bodov do SQL databázy na zmenu hodnoty, s časovou značkou. Hodnota digitálnych signálov sa menila tak, že v stave ON bola cca 100 ms. Písal, že nemôže použiť SCADA systém, ktorý zvyčajne nemá dosť rýchly cyklus čítania.

Pred nedávnom vznikla požiadavka konkrétneho zákazníka nakomunikovať váhy – konkrétne sa jednalo o plošinové váhy Pentimex PREMOVA 60-2-8 a Pentimex PREMOVA 60-3-8 s kapacitou 60 ton slúžiace na váženie nákladných vozidiel. Tieto váhy boli pripojené k ovládaciemu panelu DINI Argeo DFW06, ktorý komunikoval s aplikáciou Cestná váha firmy VTnet na PC cez sériový port. Požiadavkou zákazníka bolo paralelné načítanie dát z váhy do webového rozhrania, ktoré poskytuje naša aplikácia EMS (Energy Management System) postavená na technológii IPESOFT D2000.

Toto je prvý blog zo série úvah o viacerých aspektoch SCADA systémov. Všetky vychádzajú zo skúseností –mojich alebo kolegov. Verím, že získané poučenia môžu byť užitočné aj pre iných – implementátorov ale aj užívateľov SCADA systémov.

Tento blog sa bude zaoberať nákladmi na komunikáciu, ktoré vyplývajú z použitia treťostranných OPC alebo OPC UA serverov.

V prvej časti tohto blogu som sa zaoberal popisom priemyselného robota Fanuc LR-Mate 200iD s kontrolérom R30iBPlus Mate a jeho komunikačnými možnosťami. Tento robot nám zapožičal náš OEM partner, ktorý potreboval navrhnúť optimálny spôsob výmeny údajov s aplikačným serverom reálneho času D2000.

V dnešnej dobe, keď sa pomaly v každom článku skloňuje Industry 4.0 a s ním spojená akcelerácia nástupu robotov (viď napr. februárové alebo marcové číslo odborného časopisu ATP Journal), je čím ďalej tým dôležitejšie nielen vedieť roboty nasadiť, ale ich prevádzku aj monitorovať a diagnostikovať. Roboty sú sofistikované zariadenia, ktoré generujú veľké množstvo informácií použiteľných pre diagnostiku – napríklad informácie o stave pohonov a kĺbov, o potrebe údržby komponentov a iné.

Ak používate viacero systémov D2000, určite ste sa stretli s potrebou prenosu objektov medzi nimi.

Používate v svojich riešeniach redundanciu? Pokiaľ sa jedná o „mission critical“ aplikácie, odpoveď našich zákazníkov je štandardne áno. Redundantné D2000 aplikačné servery, redundantné LAN, redundantné archívy, komunikačné procesy aj komunikačné trasy – podľa povahy aplikácie používajú niektoré alebo aj všetky typy redundancie, ktoré aplikačný server D2000 podporuje.

Zhruba od konca februára som pracoval na implementáci protokolu DNP3 do aplikačného servera reálneho času Ipesoft D2000. Čo teda protokol DNP3 vie, na čo sa dá použiť a aké má výhody a nevýhody?

Pred pár dňami prišiel za mnou kolega. Že či by som mu neporadil: „Potrebujem sumovať, respektíve integrovať spotrebu energie – ale tak, že na začiatku každej pracovnej zmeny sa to číslo vynuluje. Takže graf toho bude pripomínať zuby píly – bude rásť, rásť a potom na hrane pracovnej zmeny pôjde znovu na nulu. Viem to urobiť nejak elegantne – najlepšie priamo v archíve a bez nutnosti počítania niekde v ESL skripte?“.