Spájanie aplikácií

Už niekoľkokrát nás zákazník oslovil s požiadavkou na spojenie viacerých aplikácií. Ako na to?

Najskôr si ujasnime pojmy. Spojením nemyslím komunikačné prepojenie, ale zlúčenie dvoch či viacerých konfigurácií do jednej SCADA, MES či EMS aplikácie. Táto obsahuje kompletnú funcionalitu pôvodných aplikácií.

Aké môžu byť dôvody?

• Lepšia integrácia aplikácií a ich užívateľov. V minulosti sme u niekoľkých zákazníkov implementovali samostatné aplikácie na vyhodnotenie podporných služieb vo výrobe elektrickej energie. Tieto boli následne zlúčené s MES aplikáciou kvôli dostupnosti dátových zdrojov, zjednoteniu užívateľov a lepšej dostupnosti výsledkov vyhodnotenia MES.

• Zjednodušenie starostlivosti o aplikácie a zníženie nákladov. Je lacnejšie prevádzkovať jednu väčšiu aplikáciu ako niekoľko menších (a každú na vlastnom Windows/Linux serveri).

• Spájanie organizácií. Zažili sme aj prípad, keď po odčlenení energetiky do samostatnej spoločnosti sa EMS systém tiež „zduplikoval“ na dva a po niekoľkých rokoch (po opätovnom zlúčení) sme tieto dva systémy znova spájali.

• Ukončovanie prevádzky. V prípade ukončenia výroby elektrickej energie v konkrétnej výrobni, pričom ale niektoré technológie zostali zachované a bolo potrebné uchovať aj historické dáta, zákazník požadoval zlúčenie viacerých aplikácií do jednej - s tým, že veľká časť technológie a komunikácií už bude odstavená.

Pri zlučovaní aplikácií vždy hrozí jedna nepríjemná vec. A to je menný konflikt – výskyt objektov s rovnakými menami. Konflikt je tým pravdepodobnejší, čím príbuznejšie sú tieto aplikácie. Pokiaľ ich vytváral ten istý dodávateľ, prípadne ten istý tím, pravdepodobne použili rovnaké moduly, skripty, schémy, atď. Následne hrozí, že takéto objekty budú nechtiac „zdieľané“ a ich dáta prepisované z rôznych strán. Ako sa s týmto problémom vieme popasovať v Ipesoft D2000?

Dobrá správa je, že oveľa lepšie ako iné SCADA/MES/IIoT platfomy. Prečo je to tak? Vďaka dvom dôležitým vlastnostiam:

• referenčná integrita

• jednoduché premenovanie objektov

O referenčnej integrite som už písal v samostatnom blogu. Ipesoft D2000 mapuje a stráži väzby medzi D2000 objektami (merané body, počítané body, archívne hodnoty, schémy, grafy ...), takže presne vie, ktorý objekt má vzťah k inému (napr. je ním používaný, alebo je vo vzťahu rodič-potomok). Referenčná integrita je kontrolovaná nielen pri editácii ale aj pri XML importe, takže nie je možné importovať do aplikácie nekonzistentnú skupinu objektov (takú, ktorá by mala väzby mimo importované a existujúce objekty).

Druhá dôležitá vlastnosť je jednoduché premenovanie objektov. Každý D2000 objekt má trojitý identifikátor (aj o ňom som už písal v blogu o SCADA architektúre a DODM):

• Textové meno

• Numerický identifikátor (HOBJ – Handle of Object)

• Unikátny identifikátor (UID)

Vnútorne sa v D2000 používajú numerické identifikátory, ktoré sú najrýchlejšie aj pri vyhľadávaní. Takže pokiaľ užívateľ premenuje D2000 objekt, zmení sa iba jeho textové meno a stačí uložiť jeho novú definíciu. Netreba meniť nič v konfigurácii iných D2000 objektov – včítane skriptov napísaných v jazykoch ESL alebo Java!

Ako pomôže referenčná integrita a jednoduché premenovanie objektov pri zlučovaní aplikácií?

Pred samotným zlučovaním (tj. importom objektov jednej aplikácie do druhej) vykonáme premenovanie objektov. Ideálne je dať im prefix, ktorý odlíši jednotlivé aplikácie. Navyše môžeme nastaviť prefix aj UID – keby niekto aj v budúcnosti premenoval objekt, UID sa nedá zmeniť tak jednoducho ako meno, a bude z neho jasný pôvod objektu.

Prefix UID je najjednoduchšie nastaviť priamo v konfiguračnej databáze pri vypnutej aplikácii. Nastavíme ho pre všetky objekty s výnimkou SYSTEM (0), USER (12) a SYSVAR (22):

update objlist set "UUID" = 'App1.' || "UUID", "VERSION_OF_UUID"= ' App1.' || "VERSION_OF_UUID" where "TYP" not in (0, 12, 22);

Následne premenujeme objekty. Opäť je to možné robiť ručne v D200 CNF, pomocou XML exportu a importu, prípadne komfortnejšie v utilite XML Tool, implementovanej ako D2000 schéma. Alebo priamo v konfiguračnej databáze. Tu je to trochu komplikovanejšie, keďže štandardná menotvorba v D2000 pre niektoré objekty špecifikuje predponu (linka „L.“, stanica „B.“, meraný bod „M.“, schéma „S.“, atď) a pre iné nie (alarm, stavový text, bitová mapa, časový kanál, užívateľ, ...).

Preto je nutné vykonať dve premenovania, podľa typu objektu:

Pre objekty s predponami:

update objlist set "NAME" = SUBSTR("NAME", 1, 2) || App1.' || SUBSTR("NAME", 3, 99) where ("TYP" IN (16, 23, 31)) or ("TYP" > 1 and "TYP" < 8);

Pre objekty bez predpon:

update objlist set "NAME" = App1.' || "NAME" where "TYP" in (11,13, 14, 15, 17, 18, 33, 40, 41, 48, 49, 50, 51);

V prípade objektov typu Proces bolo treba zohľadňovať typ procesu. Procesy typov KOM, CLC, EVH, DBM, ALA, API sme ručne premenovali (napr. SELF.KOM na App1.SELF.KOM), keďže sme chceli oddeliť procesy jednotlivých aplikácií. Procesy SELF.ARC (zabezpečujúce archiváciu) sme naopak ponechali bez zmeny, aby nová aplikácia mala jeden veľký D2000 Archív, v rámci ktorého je možné kombinovať archívne hodnoty pochádzajúce zo všetkých pôvodných aplikácií.

V prípade objektov typu Užívateľ môžu existovať rôzne varianty. Dať predponu podľa aplikácie alebo zjednotiť užívateľov a pokiaľ sa niektorý vyskytoval vo viacerých aplikáciách, tak ponechať jedného z nich a priradiť mu príslušné Skupiny objektov, aby mal prístup ku všetkým potrebným objektom.

Na záver obrázok z D2000 Cnf zlúčenej aplikácie, ktorá obsahuje aj aplikáciu „CS“. Celkový počet objektov zlúčenej aplikácie je vyše 78 tisíc, z toho vyše 35 tisíc objektov bolo importovaných z aplikácie „CS“.

Obrázok 1 - Konfigurácia zlúčenej aplikácie – maska filtruje objekty „CS.“ z aplikácie CS

Okrem spojenia konfigurácie je ešte nutné spojiť archívne databázy – do archívu zlúčenej aplikácie dohrať dáta z archívu aplikácie „CS“. Tu je nutné pre každú archívnu hodnotu spustiť utilitu arcsynchro so špecifikovaním parametra /TID na zápis do tabuľky s príslušným ID (HOBJ) v cieľovej archívnej databáze.

Záver

Spájanie aplikácií je pravdepodobne jedna zo zložitejších operácií – čo môže byť dôvod, prečo sa v praxi spomína zriedkavo. V prípade aplikácií postavených na technológii Ipesoft D2000 je aj táto operácia relatívne ľahká. Vďaka referenčnej integrite a trojitým identifikátorom D2000 objektov je premenovanie objektov ako aj ich import do cieľovej aplikácie pohodlné a bez rizika konfliktov alebo vzniku nekonzistencie. Aj relatívne veľké SCADA aplikácie je tak možné spájať rýchlo a dokonca to zvládnu aj užívatelia, ktorí nemusia byť oboznámení s aplikačnými detailmi. Ako napríklad ja 😉

31.3.2026, Ing. Peter Humaj, www.ipesoft.com

‍

Spájanie aplikácií

Peter Humaj

Spájanie aplikácií

Iné blogy

Komunikácia - Ethernet/IP a práca so štruktúrami

Komunikácia - zabezpečený M-Bus

MQTTS v praxi