Přístup objektově orientovaného myšlení k programování PLC

Objektově orientované uvažování může usnadnit opětovné použití, testování a údržbu softwaru PLC, ale nejde o jednu univerzální sadu funkcí. Některá prostředí IEC 61131-3 podporují metody, rozhraní, vlastnosti, dědičnost a polymorfismus. Jiné platformy řídicích systémů nabízejí opakovaně použitelné funkční bloky, doplňkové instrukce, uživatelsky definované datové typy nebo knihovny, aniž by implementovaly úplný objektově orientovaný model. Inženýři musí navrhovat přesně pro danou platformu a její verzi.

Praktickým cílem není napodobovat podnikový software. Jde o to přestat zacházet s každým ventilem, motorem, analogovým kanálem a technologickou jednotkou jako s novým úkolem typu kopírovat a vložit. Dobře definovaná softwarová komponenta poskytne každému zařízení konzistentní rozhraní, model stavů, chování alarmů, možnost simulace a diagnostický záznam, přičemž zapojení specifické pro konkrétní stroj a procesní limity zůstanou mimo opakovaně použitelné jádro.

Hardware je od základu modulární; opakovaně použitelný software by měl stejně jednoznačně definovat rozhraní, stav a chování při poruše každého modulu.

Začněte zapouzdřením, nikoli dědičností

Zapouzdření znamená umístit související stav a chování za definované rozhraní. Komponenta ventilu může přijímat příkazy, povolení, zpětnou vazbu, režim a konfiguraci. Může zpřístupňovat stavy otevřeno, zavřeno, v pohybu, porucha, blokováno a diagnostika. Interní časovač, detekce přechodů, strategie opakování a logika alarmů zůstávají v kompetenci komponenty.

To je cenné i na platformě bez dědičnosti. Funkční blok nebo doplňková instrukce může stále chránit interní stav, standardizovat chování a omezovat duplicitní kód. Dědičnost je užitečná pouze tehdy, když existuje skutečný vztah „je-a“ a odvozený typ dokáže dodržet rozhraní základního typu. Hluboké stromy dědičnosti se obtížně diagnostikují online a mohou způsobit, že drobná změna základního typu ovlivní mnoho strojů.

Oddělte definici typu, data instance a mapování I/O

Opakovaně použitelná definice popisuje chování. Instance ukládá stav jednoho fyzického nebo logického zařízení. Mapování I/O propojuje tuto instanci se skutečnými signály. Smíchání těchto odpovědností činí logiku knihovny závislou na adresách modulů a znemožňuje bezpečné offline testování.

Fyzické vstupní a výstupní tagy ponechte na integrační hranici. Převeďte surové signály na jednoznačné booleovské hodnoty nebo hodnoty v technických jednotkách, zavolejte opakovaně použitelnou komponentu a poté schválené požadavky na výstupy namapujte zpět na hardware. Toto uspořádání podporuje simulaci, náhradní I/O a postupnou migraci. Program na nejvyšší úrovni také zobrazuje záměr procesu namísto opakované manipulace s adresami.

Řídicí systémy a rodiny I/O lze procházet v kolekci systémy PLC a PAC, zvolená softwarová architektura se však musí řídit podporovanými jazyky řídicího systému, modelem paměti, pravidly online změn a bezpečnostní certifikací.

Používejte rozhraní jako smlouvy o chování

Pokud platforma podporuje rozhraní, definujte operace, na které se mohou volající spolehnout, aniž byste odhalovali podrobnosti implementace. Například CODESYS ve své oficiální příručce objektově orientovaného programování dokumentuje objektově orientované funkční bloky s metodami, rozhraními, vlastnostmi, dědičností a voláním virtuálních metod. Tato schopnost je skutečná, ale neměla by se předpokládat u každého prostředí PLC.

Rozhraní může umožnit různým implementacím motorů poskytovat společné příkazy a stavové informace. Jednoduchý spouštěč, měnič frekvence a servopohon mohou všechny podporovat povolení, zastavení, reset, režim, připravenost, chod a informace o poruše, přičemž si zachovají odlišnou interní diagnostiku. Volající sekvence pak závisí na smlouvě, nikoli na parametrech specifických pro každého výrobce.

U strojů a technologických celků upřednostněte kompozici

Většina průmyslových zařízení je přirozeně složená. Čerpací jednotka obsahuje motor, uzavírací ventily, povolení, analogová měření a sekvenční logiku. Systém nádrže obsahuje hladinová měřidla, ventily, čerpadla, alarmy a provozní režimy. Větší celky vytvářejte složením menších otestovaných komponent namísto odvozování každého zařízení od jedné univerzální základní třídy.

Kompozice udržuje vlastnictví odpovědností přehledné. Sekvence čerpací jednotky může řídit její motor a ventily, ale komponenta motoru stále odpovídá za zpětnou vazbu spouštěče, časový limit spuštění a stavy poruch specifické pro motor. Analogová komponenta odpovídá za platnost signálu a škálování. Jednotka je koordinuje a vyšší logice předává stručný stav.

Kompozice odráží hierarchii zařízení a zároveň umožňuje, aby si každá komponenta motoru, ventilu a přístroje zachovala vlastní diagnostiku.

Navrhněte jednoznačný model stavů

Komponenta by měla zpřístupňovat svůj provozní stav. Samotná logika booleovských příkazů často vytváří nemožné kombinace, například současně běží a stojí, je v automatickém i ručním režimu nebo je současně v pořádku a v poruše. Výčtový model stavů může jednoznačně vyjádřit stavy nečinný, spouštění, v chodu, zastavování, v poruše a údržba i záměrné přechody mezi nimi.

Každý přechod potřebuje podmínky vstupu, důkaz dokončení, chování při překročení časového limitu a pravidla zrušení. Příkazy by měly být požadavky, nikoli přímá přiřazení stavu. Reset by měl zrušit zapamatovanou poruchu pouze tehdy, když to základní podmínka dovoluje. Ruční režim musí určit, které ochrany zůstávají aktivní a kdo řídí výstup.

Oddělte konfiguraci od provozního stavu

Konfigurace zahrnuje časové limity, technické rozsahy, prahové hodnoty alarmů, volby zařízení a povolení funkcí. Provozní stav zahrnuje akumulátory časovačů, aktuální režim, vlastnictví příkazu, historii poruch a stav přechodu. Jejich oddělení zpřehledňuje kontrolu změn a správu receptur.

Ne každé nastavení by mělo být zapisovatelné z HMI. Definujte kontrolu rozsahů, oprávnění rolí, protokolování změn a okamžik, kdy se nová hodnota aktivuje. Retentivní data si rovněž zaslouží jednoznačnou politiku. Komponenta, která se po výpadku napájení obnoví, nesmí obnovit nebezpečný příkaz jen proto, že všechny interní proměnné byly nastaveny jako trvalé.

Testujte komponenty před rozmnožením instancí

Výhoda opětovného použití se projeví pouze tehdy, když je definice spolehlivá. Vytvořte testovací přípravek, který simuluje běžnou zpětnou vazbu, opožděnou zpětnou vazbu, protichůdné vstupy, ztrátu komunikace, nekvalitní analogový signál, změny režimu, pokusy o reset, spuštění po zapnutí a hranice časových limitů. Pro každý případ ověřte výstupy, alarmy a přechody stavů.

Poté otestujte více instancí a odhalte chyby sdíleného stavu. Ověřte dopad na dobu cyklu a paměť při realistickém měřítku. Krátké volání na nejvyšší úrovni neznamená, že implementace je výpočetně beznákladová. Online úpravy, aktualizace knihoven a migraci dat instancí je třeba před nasazením nacvičit na cílovém řídicím systému.

Řiďte změny a verzování knihoven

Opakovaně použitelná komponenta může opravu rozšířit na mnoho míst, ale stejně tak může rozšířit i chybu. Každému vydanému typu přiřaďte verzi, zdokumentované rozhraní, záznam o testování a historii změn. Změny klasifikujte jako kompatibilní nebo narušující kompatibilitu. U zavedené definice potichu neměňte význam alarmů, výchozí časování, chování výstupů ani rozvržení retentivních dat.

Projekty by měly zaznamenávat, které verze knihoven byly zkompilovány a nahrány. Pokud platforma vkládá kopie zdrojového kódu, rozhodněte, jak se budou schválené aktualizace porovnávat a importovat. Pokud odkazuje na spravovanou knihovnu, naplánujte její dostupnost a návrat k předchozí verzi. Grafika operátorských obrazovek a faceplaty se musí vyvíjet společně s řídicím rozhraním a nesmějí předpokládat, že staré názvy členů zůstanou platné.

Integrujte diagnostiku s operátorskou vrstvou

Užitečná komponenta hlásí, proč nemůže provést požadovanou akci: chybějící povolení, neshoda zpětné vazby, překročení časového limitu přechodu, místní vlastnictví, neplatná konfigurace, špatná kvalita vstupu nebo aktivní bezpečnostní funkce. HMI by mělo tento strukturovaný stav převést na srozumitelnou a akční zprávu, aniž by obcházelo autoritu řídicího systému. Příslušný hardware pro operátory najdete v části HMI a průmyslová výpočetní technika, diagnostická smlouva však začíná v řídicím kódu.

Inženýrský pohled

Objektově orientované programování PLC je nejcennější jako disciplína založená na jasných rozhraních, zapouzdřeném stavu, kompozici, testování a řízeném opětovném použití. Úplná dědičnost a polymorfismus mohou pomoci na platformách, které je implementují, nejsou však základním předpokladem. Začněte jedním jasně vymezeným typem zařízení, ověřte jeho chování při poruchách, zdokumentujte jeho rozhraní a rozšiřujte jej teprve poté, co budou výsledky testů přesvědčivé. Výsledkem by mělo být snazší uvádění do provozu a řešení problémů pro dalšího inženýra, nikoli pouze zdánlivě sofistikovanější zdrojový kód.