Objektumorientált gondolkodás a PLC-programozásban

Az objektumorientált gondolkodás megkönnyítheti a PLC-szoftverek újrafelhasználását, tesztelését és karbantartását, de nem egyetlen univerzális funkciókészletről van szó. Egyes IEC 61131-3-kompatibilis környezetek támogatják a metódusokat, interfészeket, tulajdonságokat, öröklődést és polimorfizmust. Más vezérlőplatformok újrafelhasználható funkcióblokkokat, bővítményutasításokat, felhasználó által definiált adattípusokat vagy könyvtárakat kínálnak a teljes objektumorientált modell megvalósítása nélkül. A mérnököknek mindig az adott platformhoz és verzióhoz kell igazítaniuk a tervezést.

A gyakorlati cél nem a vállalati szoftverek utánzása. Hanem annak elkerülése, hogy minden szelepet, motort, analóg csatornát és komplett egységet újabb másolási-beillesztési feladatként kezeljünk. Egy jól definiált szoftverkomponens egységes interfészt, állapotmodellt, riasztási viselkedést, szimulációs lehetőséget és diagnosztikai rekordot biztosít minden eszközhöz, miközben a gépspecifikus bekötést és a folyamatkorlátokat az újrafelhasználható magon kívül tartja.

A hardver kialakítása eleve moduláris; az újrafelhasználható szoftvernek ugyanilyen egyértelművé kell tennie minden modul interfészét, állapotát és hibaviselkedését.

Kezdje a tokozással, ne az öröklődéssel

A tokozás azt jelenti, hogy az összetartozó állapotot és viselkedést egy meghatározott interfész mögé helyezzük. Egy szelepkomponens parancsokat, engedélyezési feltételeket, visszajelzést, üzemmódot és konfigurációt fogadhat. Kimenetként megadhatja a nyitott, zárt, mozgó, hibás, reteszelt és diagnosztikai állapotokat. A belső időzítő, az átmenetek érzékelése, az újrapróbálkozási szabályzat és a riasztási logika a komponens felelőssége marad.

Ez még olyan platformon is értékes, amely nem támogatja az öröklődést. Egy funkcióblokk vagy bővítményutasítás továbbra is védheti a belső állapotot, szabványosíthatja a viselkedést és csökkentheti a duplikált kód mennyiségét. Az öröklődés csak akkor hasznos, ha valódi „egy” kapcsolat áll fenn, és a származtatott típus képes betartani az alaptípus interfészét. A mély öröklődési hierarchiák online nehezen diagnosztizálhatók, és egy kisebb alaposztály-módosítás sok gépre hatással lehet.

Válassza külön a típusdefiníciót, a példányadatokat és az I/O-leképezést

Az újrafelhasználható definíció a viselkedést írja le. Egy példány egy fizikai vagy logikai eszköz állapotát tárolja. Az I/O-leképezés ezt a példányt a valós jelekhez kapcsolja. E felelősségi körök összekeverése a könyvtári logikát a rackcímektől teszi függővé, és megakadályozza a biztonságos offline tesztelést.

A fizikai bemeneti és kimeneti tageket tartsa az integrációs határon. Alakítsa át a nyers jeleket egyértelmű logikai vagy mérnöki mértékegységű értékekké, hívja meg az újrafelhasználható komponenst, majd a jóváhagyott kimeneti kéréseket képezze vissza a hardverre. Ez az elrendezés támogatja a szimulációt, a cserélhető I/O-t és a fokozatos migrációt. Emellett a felső szintű programban a folyamat szándéka jelenik meg, nem az ismétlődő címkezelés.

A vezérlők és I/O-családok a PLC- és PAC-rendszerek gyűjteményében tekinthetők át, a választott szoftverarchitektúrának azonban követnie kell a vezérlő által támogatott nyelveket, memóriamodellt, online módosítási szabályokat és biztonsági tanúsítási követelményeket.

Használja az interfészeket viselkedési szerződésként

Ha a platform támogatja az interfészeket, definiálja azokat a műveleteket, amelyekre a hívók támaszkodhatnak anélkül, hogy a megvalósítás részleteit fel kellene tárni. A CODESYS például metódusokat, interfészeket, tulajdonságokat, öröklődést és virtuális metódushívásokat is tartalmazó objektumorientált funkcióblokkokat dokumentál hivatalos objektumorientált programozási referenciájában. Ez a lehetőség valóban létezik, de nem szabad minden PLC-környezetre kiterjeszteni.

Egy interfész lehetővé teheti, hogy különböző motorimplementációk közös parancsokat és állapotokat tegyenek elérhetővé. Egy egyszerű indító, egy frekvenciaváltó és egy szervó egyaránt támogathatja az engedélyezést, leállítást, visszaállítást és üzemmódváltást, valamint a kész, működő és hibás állapot jelzését, miközben eltérő belső diagnosztikát használ. A hívási sorrend így a szerződéstől függ, nem az egyes gyártóspecifikus paraméterektől.

Gépeknél és skidrendszereknél részesítse előnyben a kompozíciót

A legtöbb ipari berendezés természeténél fogva összetett. Egy szivattyúegység motort, leválasztószelepeket, engedélyezési feltételeket, analóg méréseket és szekvenciavezérlést tartalmaz. Egy tartályrendszerben szintműszerek, szelepek, szivattyúk, riasztások és üzemmódok találhatók. Ezeket a nagyobb egységeket kisebb, tesztelt komponensek beágyazásával építse fel, ahelyett hogy minden eszközt egyetlen univerzális alaposztályból származtatna.

A kompozíció láthatóvá teszi a felelősségi köröket. A szivattyúszekvencia vezérelheti a motort és a szelepeket, de a motor komponense továbbra is maga kezeli az indító visszajelzését, az indítási időtúllépést és a motorspecifikus hibákat. Az analóg komponens felel a jel érvényességéért és skálázásáért. Az egység összehangolja ezeket, és tömör állapotot jelent a magasabb szintű logikának.

A kompozíció tükrözi a berendezés hierarchiáját, miközben lehetővé teszi, hogy minden motor-, szelep- és műszerkomponens megőrizze saját diagnosztikáját.

Tervezzen egyértelmű állapotmodellt

Egy komponensnek megfigyelhetővé kell tennie az üzemállapotát. A kizárólag logikai parancsokra épülő vezérlés gyakran lehetetlen kombinációkat hoz létre, például egyszerre működő és leállított, automatikus és kézi, illetve egészséges és hibás állapotot. Egy felsorolt állapotmodell tudatos átmenetekkel fejezheti ki a nyugalmi, indítási, működési, leállítási, hibás és karbantartási állapotokat.

Minden átmenethez szükség van belépési feltételekre, a teljesülés bizonyítékára, időtúllépési viselkedésre és megszakítási szabályokra. A parancsok kérések legyenek, ne közvetlen állapot-hozzárendelések. A visszaállítás csak akkor törölje a reteszelt hibát, ha az alapul szolgáló feltétel ezt lehetővé teszi. Kézi üzemmódban meg kell határozni, mely védelmek maradnak aktívak, és ki felel a kimenetért.

Tartsa külön a konfigurációt és a futásidejű állapotot

A konfiguráció magában foglalja az időkorlátokat, a mérnöki tartományokat, a riasztási küszöbértékeket, a berendezésopciókat és a funkcióengedélyezéseket. A futásidejű állapothoz tartoznak az időzítők felhalmozott értékei, az aktuális üzemmód, a parancstulajdonos, a hibatörténet és az átmenet állapota. Ezek szétválasztása egyértelműbbé teszi a módosítások felülvizsgálatát és a receptkezelést.

Nem minden beállításnak kell HMI-ről írhatónak lennie. Határozza meg a tartományellenőrzéseket, a szerepköralapú jogosultságokat, a módosítások naplózását és azt, mikor lép életbe az új érték. A megőrzött adatokhoz is szükség van egyértelmű szabályzatra. Egy komponens, amely áramkimaradás után folytatja a működést, nem állíthat vissza veszélyes parancsot pusztán azért, mert minden belső változó tartós tárolásra van beállítva.

Tesztelje a komponenseket, mielőtt megsokszorozná a példányokat

Az újrafelhasználás előnye csak akkor jelentkezik, ha a definíció megbízható. Építsen tesztkörnyezetet normál visszajelzések, késleltetett visszajelzések, ellentmondó bemenetek, kommunikációs kiesés, hibás analógminőség, üzemmódváltások, visszaállítási kísérletek, bekapcsolás és időtúllépési határértékek vizsgálatára. Minden esetben ellenőrizze a kimeneteket, a riasztásokat és az állapotátmeneteket.

Ezután teszteljen több példányt is, hogy feltárja a megosztottállapot-kezelési hibákat. Ellenőrizze a ciklusidőre és memóriára gyakorolt hatást reális méretben. A felső szinten tömörnek látszó hívás nem jelenti azt, hogy a megvalósítás számításigénye elhanyagolható. Az online módosításokat, a könyvtárfrissítéseket és a példányadatok migrációját telepítés előtt a célvezérlőn kell begyakorolni.

A könyvtári módosítások és verziók kezelése

Egy újrafelhasználható komponens széles körben továbbíthat egy javítást, de ugyanilyen széles körben továbbíthat egy hibát is. Minden kiadott típust lásson el verzióval, dokumentált interfésszel, tesztjegyzőkönyvvel és módosítási előzményekkel. A változásokat kompatibilis vagy törő változásként osztályozza. Egy bevált definícióban ne módosítsa csendben a riasztások jelentését, az alapértelmezett időzítést, a kimenetek viselkedését vagy a megőrzött adatok elrendezését.

A projektekben rögzíteni kell, mely könyvtárverziókat fordították le és töltötték le. Ha a platform forrásmásolatokat ágyaz be, határozza meg, hogyan hasonlítják össze és importálják a jóváhagyott frissítéseket. Ha kezelt könyvtárra hivatkozik, tervezze meg annak elérhetőségét és a visszaállítást. A kezelői grafikákat és képernyőpaneleket a vezérlési interfésszel együtt kell továbbfejleszteni, nem pedig abból kiindulni, hogy a régi tagnevek mindig érvényesek maradnak.

Integrálja a diagnosztikát a kezelői réteggel

Egy hasznos komponens jelzi, miért nem tud végrehajtani egy műveletet: nincs engedélyezési feltétel, eltér a visszajelzés, lejárt az átmeneti idő, helyi vezérlés van érvényben, érvénytelen a konfiguráció, rossz a bemeneti jel minősége, vagy aktív a biztonsági funkció. A HMI-nek ezt a strukturált állapotot cselekvésre ösztönző üzenetté kell alakítania anélkül, hogy megkerülné a vezérlő illetékességét. A releváns kezelői hardver a HMI- és ipari számítástechnikai kategóriában található, a diagnosztikai szerződésnek azonban a vezérlőkódban kell kezdődnie.

Mérnöki szempontból

A PLC-k objektumorientált programozása leginkább az egyértelmű interfészek, a tokozott állapot, a kompozíció, a tesztelés és a szabályozott újrafelhasználás fegyelmeként értékes. A teljes öröklődés és polimorfizmus hasznos lehet az ezeket megvalósító platformokon, de nem ez az alapkövetelmény. Kezdje egy jól körülhatárolt eszköztípussal, bizonyítsa annak hibaviselkedését, dokumentálja az interfészét, és csak akkor bővítse a használatát, ha a teszteredmények meggyőzőek. A végeredmény tegye könnyebbé a következő mérnök számára az üzembe helyezést és a hibaelhárítást, ne csupán kifinomultabbnak mutassa a forráskódot.