Внасяне на обектно-ориентирано мислене в програмирането на PLC-системи

Обектно-ориентираното мислене може да улесни повторното използване, тестването и поддръжката на PLC софтуера, но не представлява универсален набор от функции. Някои среди по IEC 61131-3 поддържат методи, интерфейси, свойства, наследяване и полиморфизъм. Други платформи за контролери предлагат повторно използваеми функционални блокове, допълнителни инструкции, дефинирани от потребителя типове данни или библиотеки, без да прилагат пълния обектно-ориентиран модел. Инженерите трябва да проектират според конкретната платформа и версия.

Практическата цел не е да се имитира корпоративен софтуер. Целта е всеки клапан, двигател, аналогов канал и пакетна инсталация да не се разглеждат като ново упражнение по копиране и поставяне. Добре дефинираният софтуерен компонент осигурява на всяко устройство последователен интерфейс, модел на състоянията, поведение при аларми, път за симулация и диагностичен запис, като същевременно запазва специфичното за машината окабеляване и технологичните ограничения извън повторно използваемото ядро.

Хардуерът е модулен по замисъл; повторно използваемият софтуер трябва да прави интерфейса, състоянието и поведението при отказ на всеки модул също толкова ясни.

Започнете с капсулиране, а не с наследяване

Капсулирането означава свързаните състояния и поведения да бъдат поставени зад дефиниран интерфейс. Компонентът за клапан може да приема команди, разрешаващи условия, обратна връзка, режим и конфигурация. Той може да предоставя състояния като отворен, затворен, в движение, повреден, блокиран и диагностичен. Вътрешният таймер, откриването на преходи, политиката за повторни опити и логиката на алармите остават собственост на компонента.

Това е ценно дори на платформа без наследяване. Функционалният блок или допълнителната инструкция все пак могат да защитават вътрешното състояние, да стандартизират поведението и да намалят дублирания код. Наследяването е полезно само когато съществува истинска връзка „е вид на“ и производният тип може да спазва базовия интерфейс. Дълбоките йерархии на наследяване са трудни за диагностициране онлайн и могат да доведат до това малка промяна в базовия тип да засегне много машини.

Разделяйте дефиницията на типа, данните на инстанцията и картографирането на I/O

Повторно използваемата дефиниция описва поведението. Инстанцията съхранява състоянието на едно физическо или логическо устройство. Картографирането на I/O свързва тази инстанция с реалните сигнали. Смесването на тези отговорности прави библиотечната логика зависима от адресите на модулите и възпрепятства безопасното офлайн тестване.

Поддържайте физическите входни и изходни тагове на границата на интеграцията. Преобразувайте необработените сигнали в ясни булеви стойности или стойности в инженерни единици, извикайте повторно използваемия компонент, след което върнете одобрените заявки за изход към хардуера. Тази подредба поддържа симулация, резервни I/O модули и поетапна миграция. Тя също така показва технологичната цел в програмата от най-високо ниво, вместо многократно манипулиране на адреси.

Контролерите и фамилиите I/O могат да бъдат разгледани в колекцията PLC и PAC системи, но избраната софтуерна архитектура трябва да съответства на поддържаните от контролера езици, модела на паметта, правилата за промени онлайн и сертифицирането за безопасност.

Използвайте интерфейсите като договори за поведение

Когато платформата поддържа интерфейси, дефинирайте операциите, на които извикващият код може да разчита, без да разкривате подробности за реализацията. Например CODESYS описва обектно-ориентирани функционални блокове с методи, интерфейси, свойства, наследяване и извиквания на виртуални методи в своя официален справочник за обектно-ориентирано програмиране. Тази възможност е реална, но не бива да се приема за налична във всяка PLC среда.

Интерфейсът може да позволи на различни реализации на двигатели да предоставят общи команди и състояния. Обикновен пускател, честотен регулатор и серво задвижване могат да поддържат включване, спиране, нулиране, режим, готовност, работа и информация за повреда, като същевременно запазват различна вътрешна диагностика. Така последователността на извикване зависи от договора, а не от всеки специфичен за производителя параметър.

Предпочитайте композицията за машини и пакетни инсталации

Повечето промишлени съоръжения естествено се изграждат чрез композиция. Една помпена инсталация съдържа двигател, спирателни клапани, разрешаващи условия, аналогови измервания и логика на последователността. Една резервоарна система съдържа нивомерни прибори, клапани, помпи, аларми и режими на работа. Изграждайте тези по-големи единици чрез включване на по-малки, тествани компоненти, вместо всяко устройство да се извежда от един универсален базов клас.

Композицията запазва видима отговорността. Последователността на помпата може да управлява двигателя и клапаните, но компонентът на двигателя продължава да отговаря за обратната връзка от пускателя, времето за стартиране и специфичните за двигателя състояния на повреда. Аналоговият компонент отговаря за валидността и мащабирането на сигнала. Пакетната единица ги координира и предоставя кратко състояние към логиката от по-високо ниво.

Композицията отразява йерархията на оборудването, като същевременно позволява на всеки двигател, клапан и измервателен прибор да запази собствената си диагностика.

Проектирайте изричен модел на състоянията

Компонентът трябва да прави работното си състояние видимо. Логиката, изградена само от булеви команди, често създава невъзможни комбинации като работещ и спрян, автоматичен и ръчен или изправен и повреден едновременно. Моделът на състоянията с изброими стойности може да изразява състояния като покой, стартиране, работа, спиране, повреда и техническо обслужване чрез умишлено дефинирани преходи.

Всеки преход се нуждае от условия за влизане, доказателство за завършване, поведение при изтичане на времето и правила за отмяна. Командите трябва да бъдат заявки, а не директни присвоявания на състояние. Нулирането трябва да изчиства запаметена повреда само когато първопричината го позволява. Ръчният режим трябва да определя кои защити остават активни и кой управлява изхода.

Отделяйте конфигурацията от състоянието по време на работа

Конфигурацията включва времеви ограничения, инженерни диапазони, прагове на алармите, опции на оборудването и разрешаване на функции. Състоянието по време на работа включва натрупаните стойности на таймерите, текущия режим, собствеността върху командата, историята на повредите и състоянието на преходите. Разделянето им прави прегледа на промените и управлението на рецептите по-ясни.

Не всяка настройка трябва да може да се записва от HMI. Дефинирайте проверки на диапазона, права според ролята, регистриране на промените и момента, в който новата стойност става активна. Данните, които се запазват, също изискват ясна политика. Компонент, който се възстановява след прекъсване на захранването, не трябва да възстановява опасна команда само защото всички вътрешни променливи са конфигурирани като постоянни.

Тествайте компонентите, преди да умножите инстанциите

Предимството на повторното използване се проявява само когато дефиницията е надеждна. Изградете тестов стенд, който подава нормална обратна връзка, забавена обратна връзка, противоречиви входове, загуба на комуникация, невалидно качество на аналогов сигнал, промени на режима, опити за нулиране, включване и гранични случаи при изтичане на времето. Потвърдете изходите, алармите и преходите между състоянията за всеки случай.

След това тествайте множество инстанции, за да разкриете грешки със споделено състояние. Проверете влиянието върху времето на цикъла и паметта при реалистичен мащаб. Компактното извикване на най-високо ниво не означава, че реализацията не изисква изчислителни ресурси. Промените онлайн, актуализациите на библиотеките и миграцията на данните на инстанциите трябва да бъдат репетирани на целевия контролер преди внедряване.

Управлявайте промените и версиите на библиотеката

Повторно използваемият компонент може да разпространи поправка широко, но може да разпространи широко и дефект. Дайте на всеки публикуван тип версия, документиран интерфейс, запис на тестовете и история на промените. Класифицирайте промените като съвместими или нарушаващи съвместимостта. Не променяйте незабелязано семантиката на алармите, времевите настройки по подразбиране, поведението на изходите или структурата на запазваните данни в утвърдена дефиниция.

Проектите трябва да записват кои версии на библиотеките са компилирани и изтеглени в контролера. Ако платформата вгражда копия на изходния код, определете как одобрените актуализации ще бъдат сравнявани и импортирани. Ако използва управлявана библиотека, планирайте нейната наличност и възстановяването към предишна версия. Графичните екрани за оператори и лицевите панели трябва да се развиват заедно с интерфейса за управление, вместо да приемат, че старите имена на членове винаги ще останат валидни.

Интегрирайте диагностиката със слоя за оператора

Полезният компонент съобщава защо не може да действа: липсващо разрешаващо условие, несъответствие в обратната връзка, изтичане на времето за преход, локална собственост, невалидна конфигурация, лошо качество на входа или активна функция за безопасност. HMI трябва да превежда това структурирано състояние в разбираемо и полезно съобщение, без да заобикаля правомощията на контролера. Подходящ хардуер за оператора може да бъде намерен в раздела HMI и промишлени компютърни системи, но диагностичният договор започва в управляващия код.

Инженерна перспектива

Обектно-ориентираното PLC програмиране е най-ценно като дисциплина на ясните интерфейси, капсулираното състояние, композицията, тестването и контролираното повторно използване. Пълното наследяване и полиморфизмът могат да бъдат полезни на платформи, които ги прилагат, но не са изходното изискване. Започнете с един ограничен тип устройство, докажете поведението му при отказ, документирайте интерфейса му и разширявайте едва след като тестовите доказателства са убедителни. Резултатът трябва да улеснява въвеждането в експлоатация и отстраняването на неизправности от следващия инженер, а не просто да прави изходния код да изглежда по-сложен.