Sauter EY2400

http://www.2p.cz/cs/sauter_ey2400

EY2400 je měřící a regulační systém, jehož počátek je datován do poloviny 80.let. Prodej byl ukončen v roce 2002 a podpora systému od mateřské firmy skončila v roce 2010. Systém byl v Česku a na Slovensku poměrně rozšířen mj. i proto, že byl licenčně vyráběn ve Zbrojovce Vyškov. Nynější podpora systému od firmy Sauter je nulová, zákazník je tlačen do vyhození systému do popelnice a zakoupení “moderního” systému, nyní Modulo 5. Tyto systémy jsou navíc založeny na Ethernetové kabeláži (BACNet), takže se cena navyšuje i o novou kabeláž. Překvapivě není možné získat ke starému systému ani žádnou dokumentaci, jelikož vše bylo už údajně zkartováno. Bohužel kupodivu nepomůže ani Google neboť v 90.letech dokumenty asi nebyly veřejně přístupné. Servis a prodej dílů zajišťuje např. http://www.dzb.cz/.

Komunikace se stanicemi je zajištěna pomocí nízkorychlostní digitální DL sběrnice, kde stanice jsou umístěna za sebou bez odboček. Odbočení je možné pomocí datového multiplexeru (EYS 3A 318B). Maximální délka sběrníce s 99 stanicemi je 4km. Na fyzické vrstvě se nejedná o nějaký standard jako např. RS485 ale o proprietární protokol. Sběrnici tvoří dva vodiče a-b, napětí v klidu Vab od 22V (do 40V) a vodič a je vždy kladnější. Druhá úroveň je indikována “spojením” obou vodičů. Linková vrstva je sériový protokol 1200baud, 7 bitů, sudá parita. Síťová vrstva používá jednoduché rámce s udaným typem (P..dotaz z centra, U..odpověď ze stanice), síťovou adresou (000-999), jemnou (MFA) adresou v rámci stanice a případnými daty. Základní komunikace je dotaz/odpověď (telegramy) iniciovaná z datového centra (DC) nebo spontánní hlášení ze stanic jako odpověď na neadresnou výzvu na data podle hlásné kategorie, kde je nějak nutné řešit konflikty při souběžném vysílání odpovědí. Spontánní hlášení DC zapíše do stanice přijatou hodnotu, podle které stanice pozná, že byla přijata. Stanice totiž posílá změny aktuální hodnoty proti poslední odeslané a potvrzené s podporou případné hystereze u analogových hodnot. Hlásná priorita nabývá hodnot 0..3, kde nižší číslo znamená závažnější události.

Vlastnosti systému

Stanice je řízena speciálním MCU. Na desce jsou také paměť EPROM a RAM, která je zálohovaná baterií a obsahuje aktuální data, historická data (HDB) a většinou i vlastní regulační program. Ten může být i naprogramován programátorem do EPROM ale to nebývá pravidlem. Důležité je tedy nepřerušené zálohování RAM, při jeho výpadku se vymaže ihned regulační program i data. V paměti RAM jsou 4kB přístupné přes sběrnici. Programování, čtení, zápis hodnot i konfigurace tedy spočívá v čtení/zápisu dat z tohoto bloku. Jednotlivá adresa je tvořena číslem 0-71 a znakem (např. `, A,a,w). Adresovaná buňka je 16-ti bitové slovo (DW). Stanice má 32 slotů, které mohou být přiřazeny sw modulu nebo fyzické kartě. Vlastní program nazývaný “moves” nezná skoky, podmínky apod. ale jde více méně o přesuny mezi adresami (bit, byte, word) s podporou bitový logických operací. SW moduly pak zajišťují vyšší funkce jako je PID, sčítání, časovače, hraniční spínače apod. Celé je to z mého pohledu příliš kryptické a neprůhledné.

Pro programování RAM je určený program RSPARA.EXE. Jedná se o program napsaný ještě pro DOS ale je funkční i ve Windows XP. Pouze pokud je potřeba z něj tisknout pro tisk je nutno ho spustit z DOSového emulátoru, např. DOSbox zkompilovaný s podporou zachytávání LPT do souboru. RSPARA.EXE podporuje parametrizaci, “kompilaci” a disassemblování regulačního programu, časové programy, manuální dotazy na stanice atd. Umí také komunikovat s programátorem EPROM (nezkoušel jsem). Jde s ním udělat vše potřebné za podmínky, že podporuje konkrétní typ stanice. Pokud nepodporuje je možné použít pro přenos obsahu RAM utilitu RSDude, se kterou lze provádět různá kouzla. Pro vytváření regulačního programu s použitím grafických bloků byl určen originálně FUPLAN. Ten je údajně možné oficiálně získat s licencí současných CASE Suite nástrojů od firmy Sauter. Cena je ovšem vysoká.

Existují regulační stanice rsz, rsp, které jsou tvořeny rackem, do kterého se zasouvají karty. První karta A slouží k zálohování chodu stanice v případě výpadku napájení. Jsou na ní velkokapacitní olověné akumulátory 12V/5Ah. Druhá karta B je napájecí a jsou zde i nabíjecí NiCd články pro zálohování RAM a reálného času, která je na třetí procesorové kartě C, kde jsou také analogové převodníky. Pokud se tedy vytáhne karta B nebo C dojde k vymazání obsahu RAM. Na kartě B je 5 (rsp) nebo 7 (rsz) kolíkový DIN konektor pro přímé připojení do RS232 v PC. Takto lze programovat stanici přímo i bez připojení na DL sběrnici. V racku je 9 pozic na zásuvné karty (K1..K9), každé kartě jsou vyhrazeny 4 MFA adresy. Jelikož je 32 adres, mají karty v pozicích K8 a K9 pouze po dvou adresách. Pozice K8-9 jsou většinou použity pro karty binárních vstupů, které mají podporu pouze dvou adres. Karty K2-5 pro měřící karty a K6-7 pro povelové karty. Další věcí, kterou je nutné brát do úvahy je ukládání hodnot do HDB, kdy se neukládají hodnoty z MFA adres 0-3, tj. z karty na pozici K1 a interval ukládání zbývajících závisí podle kartové pozice (např. měření vs. digitální vstupy). Na každé kartě je 16 svorek, pro připojení vodičů. Povelové karty mohou podporovat zpětnovazební signál, který potvrzuje sepnutí (např. zpětná vazba ze stykače).  Na jednotlivé kartě jsou implementovány základní funkce jako binární vstupy, analogové vstupy, teplotní vstupy (Ni1000, Pt1000, …), digitální bezpotenciálové výstupy (relé), měření spotřeby, analogové výstupy 0-10V atd.

Další stanice, jako např. ECOS regulace místností používají stejnou logiku ale žádné fyzické karty tam zasunuty nejsou. Tyto jednotky nemají programovací konektor ale je možné je naprogramovat přes DL. Záloha RAM je řešena pomocí nedobíjitelného lithiového akumulátoru.

Olověné a NiCd akumulátory mají omezenou životnost, je nutné je sledovat a provést včas jejich výměnu. Zejména při použití v prostorech se zvýšenou teplotou, jako je kotelna, může být stárnutí urychleno. Lithiové akumulátory se mohou vybít ale z praxe 17-letý článek je stále funkční.

Jelikož je přítomen zálohovaný obvod reálného času, je podporováno na každé stanici až 128 povelů závislých na aktuálním času s minutovým rozlišením a dni v týdnu. V daný okamžik dojde k zapsání hodnoty na určenou adresu. Regulační program pak podle hodnoty může například provést povel. S tím souvisí priorita hodnoty, zda brát do úvahy časový povel nebo manuálně nastavenou hodnotu. Toto je poměrně neprůhledné a může vést k “nepochopitelnému” chování. Jelikož v průběhu roku jsou dny volna, je podporována definice až 16 dní podle data, kdy se bude stanice chovat jako o víkendu. Vysvětlení nastavení chování v sekvenci předchozích a následujících dní je ale pro mne velmi neprůhledné a nelogické. Dále je podporována změna letního/zimního času.

Oblast paměti rozlišuje hw oblast (MFA 0-31, zásuvné karty), servisní oblast (MFA 40-44, např.aktuální datum, čas, atd.) a oblast sw adres (MFA 45-55, oblast pro komunikaci s DC, příznaky použitelné v regulačním programu atd.). S použitím sw adres ve vizualizaci souvisí termín kartový kód (např. A@). Slouží k nastavení, jak se má zacházet se zapisovanou/čtenou hodnotou z DC, ale nevidím to jako průhlednou vlastnost.

Při předávání binárních hodnot na sw adresách mezi datovým centrem se používají lokace  `, b na straně stanice a H na straně DC. Hodnota posílaná z DC se tedy zapíše do H, např. 50H3, ve stanici se přečte z ` jako X50`3. Pokud je třeba změnu posílat do DC tak se ve stanici zapíše do lokace b, např. Y50b3 a čte poté na DC z H jako 50H3. Situaci znepřehledňují dále časové programy, kdy příkaz  ČP způsobí změnu hodnoty v registru ` (např. příkaz 1 ovládá bit `3 = 0x8, příkaz 0 bit `0 = 0x4, AUT bit `1 = 0x1). Propagace registru ` do b tedy umožní zjistit vždy aktuální hodnoty.

Vizualizace

V době instalací se používal systém Provi. Komunikace se stanicemi je velmi pomalá, což je zejména zřejmé po startu vizualizace při větším počtu stanic, kdy je nutno ze stanic načíst aktuální hodnoty. Jelikož je určen pro Windows95 a je napsán blokujícím způsobem, počítač pak dlouhé desítky minut může být blokován. V původním systému se používá v DC ISA karta (EYS3 A680) s externím napájením a ochranou (EYZ3 A681). Přes tuto kartu komunikuje software Provi se stanicemi. Jelikož se jedná o proprietární kartu je potřeba driver pro konkrétní OS. Jako obecné řešení lze použít originální převodník DL sběrnice na V.24 (RS232) (Sauter EYZ 485 nebo EYZ 3A 384).

Pro revitalizaci systému bych doporučil tedy zejména migraci původní vizualizace na nový systém. Jako základní podmínku při výběru se nutné hledat podporu protokolu EY2400. Jelikož specifikace protokolu z velké části zřejmá z dostupných materiálů, existují SCADA programy třetích stran, které protokol podporují. Zároveň modulárně podporují i jiné protokoly, takže pozdější přechod nebo zaimplementování jiného protokolu BACNet, Modbus by neznamenalo nákup jiného software.

Pozn: Protokol pro následující systém EY3600 nebyl zveřejněn a pro připojení jiných řešení je třeba použít OPC server.

Do úvahy přicházejí tyto systémy s nativní podporou Sauter EY2400: novaPro od firmy Sauter, Reliance od pardubické firmy GeoVAP a Tirs od hradecké firmy Coral. Všechny systémy poskytují podporu více protokolům, visuální komponenty, alarmy, grafy, napojení na databáze, API (DCOM), cenové modely založeny na počtu datových bodů, OS Windows, vizualizace před prohlížeč atd. Licence je také závislá na počtu současně přihlášených operátorů (tj. pravděpodobně připojených vzdáleně přes web nebo desktop aplikaci). Je ale možné používat vzdálenou plochu pro spouštění desktop aplikace na serveru.

Alternativně by šlo použít nějaké open-source GNU řešení, např. http://www.proview.se/ nebo http://www.openapc.com/ a naimplementovat driver pro EY2400. Zásadní výhoda by byla možnost použít Linux a s tím spojené menší nároky na hardware, administraci atd.

Reliance 4 (v.4.7.1)

Systém rozlišuje mezi vývojářskými a runtime moduly, které potřebují k běhu buď SW nebo HW USB klíč. Systém je napsán v Delphi, z něhož převzal i koncept uživatelského rozhraní. Spuštění projektu z IDE velmi je jednoduché. Projekt je uložený částečně v proprietárním binárním formátu (.RDT..Reliance Data Table?) a částečně jako XML. Editor RTD souborů je přiložen. RDT/XML bohužel omezuje sledování provedených změn při použití verzovacích systémů (GIT apod.). IDE podporuje kontextovou nápovědu, což značně zjednodušuje dohledávání dokumentace.

Historická data možno ukládat do souborových databází dBase, Paradox nebo do SQL (MySQL/MariaSQL, PgSQL a MSSQL). Podporováno je také ukládání do souborů RDT.

Systém podporuje definice datových struktur, které je možno používat vnořeně. Lze takto nadefinovat opakující se struktury, ke kterým se v definici stanice přiřadí adresování jednotlivých prvků. Bohužel jsou podporovány pouze obecné vlastnosti datového bodu a nikoliv ty, které závisí na konkrétním driveru. Datové struktury jsou také použity v šablonách, které definují opakovaně použitelné grafické bloky. Při použití šablony v kontejneru se přiřadí i příslušná datová struktura. Šablony lze také používat vnořeně. Ve verzi 4.7.2 je možno dynamicky přiřadit název instance datové struktury, která bude použita v šabloně okna, což zjednodušuje visualizaci masy totožných objektů.

V rámci projektu lze definovat skripty (ActiveScript), které se mají spouštět na základě různých událostí. Proměnné umožňují zase měnit vybrané vlastnosti komponent nebo chování programu. Bohužel není možno ze skriptu ovládat dynamické chování oken, jak bych jako vývojář očekával. ActiveScript je možno krokovat pomocí externího Just-In-Time debuggeru.

Komponenta podporuje editaci časových programů stanic Sauter s možností definování uživatelských názvů datových bodů a povelů.

Projekt je možno exportovat pro použití tenkým klientem, kterým je buď WebClient využívající kontroverzní Javu nebo SmartClient, kde se používá HTML5.

Jako datové body pro výpočet licence se nepočítají systémové body mimo vlastní stanice. Při použití polí se počet datových bodů vypočítává jako velikost pole děleno pěti. Pozor tedy na nárůst datových bodů při použití větších větších polí, což je v případě Sauter EY2400 pole (128 prvků) časových programů. Pokud se používá mnoho stanic, může potřeba datových bodů značně narůst. Zde je na zvážení, zda raději neomezit maximální počet časových programů ve stanici např. na 14 (= 2 datové body).

V balíčku se nacházejí příklady aplikací, podle kterých lze vypozorovat řešení konkrétních problémů. Na druhou stranu nejsou obecně zaměřené videotutoriály neboť ty jsou obsahem placených školení.

TIRS.NET 6

Na cílovém stroji je instalován development i runtime, což má výhodu, že není nutno případně kupovat separátní licenci pro vývoj, pokud vývojář obhospodařuje více systémů na serverech zákazníků. Vývojář může dokonce získat zdarma systém, pokud vyvíjí pro cílové zákazníky.

Spouštění projektu z IDE mi přijde poněkud komplikovaný. Bohužel dokumentace existuje jen v PDF, takže dohledávání problémů není jednoduché. Bohužel nějaké pokročilé klíčové funkce (jako šablonování pomocí prefixu) nebyly zdokumentovány vůbec. Visuální editor oken působil syrovým dojmem, problémy byly např. s velikostí komponent. IDE je napsáno s využitím Windows Ribbon Framework, tj. dynamicky se měnící nástrojová lišta.

Pro ukládání historických dat a alarmů podporuje pouze MSSQL. Používá .NET Framework 4.0, tj. lze používat i Windows XP. Webový modul pro řízení přes HTML5 požaduje .NET Framework 4.5, který ale požaduje minimálně Windows 7.

Formát uložení projektu je XML ale s interně strukturovanými daty v CDATA. Objevují se i přidružené binární soubory pro uložení oken.

Licencování je založeno na nákupu base modulu, pro potřebný počet datových bodů a potřebných modulů oceněných jako procentem z ceny base modulu. Což nemusí být vždy výhodné pokud je potřeba kombinovat více protokolů ve velkém systému.

Bohužel nejsou k dispozici žádné pokročilejší demo aplikace, které by ukázaly, jak řešit určité problémy. Na druhou stranu je snad možné absolvovat bezplatné školení.

Pro Sauter je nutno definovat drivery jednak pro příkazy a jednak pro spontánní odpovědi. Což mi přijde poněkud neprůhledné.

Závěr

Zásadní pro volbu systému je efektivita s jakou je možno vytvořit/migrovat a poté udržovat vlastní projekt. V případě velkého množství datových bodů půjde o podporu hromadného importu. V případě opakovaného používání stejných stanic (např. regulace místností) je důležitým kritériem možnost šablon aby se zabránilo copy&paste vývoji, kdy jakékoliv pozdější úpravy znamenají opravovat v každé rozkopírované instanci.

Oba systémy podporují modulární dynamické používání driverů pro různé protokoly (MODBUS, Sauter EY2400, m-bus, OPC atd.), autentizace operátora, přístupová práva.

U obou systémů vidím problém v nepoužívání už jednou definovaných údajů pro zobrazovaní v komponentách, např. že jednou definovaný název datového bodu nelze použít pro zobrazení štítku nebo popisu v okně. Je nutná masivní copy&paste metoda.