В области программирования систем автоматизации на производстве сегодня наблюдаются две тенденции: во-первых, в этой сфере применяются компьютерные информационные технологии (ИТ), во-вторых, при написании прикладных программ с успехом используется модульный принцип.
Оптимизация затрат на проектирование систем автоматизации в производстве, в том числе в машиностроении, а также в мобильных приложениях, автоматизации зданий сегодня является одним из высокоприоритетных вопросов. Программирование прикладных задач составляет значительную часть этих затрат. Неудивительно, что многие ведущие компании, работающие в данной области, всерьез задумываются над тем, какие концепции или парадигмы программирования систем управления им стоит использовать в будущем [2].
Объектно-ориентированное расширение стандарта МЭК 61131–3:
Расширения стандарта должны подчиняться следующим требованиям:
- ООП расширения должны быть не обязательными, а опциональными;
- ООП и не ООП программирование можно совмещать;
- Существующие приложения должны полностью поддерживаться с возможностью их плавной трансформации в ООП по мере целесообразности;
- ООП должно быть применимо во всех языках МЭК 61131–3;
- Программист не должен сталкиваться со сложными определениями.
К основным расширениям до объектно-ориентированного программирования в стандарте МЭК 61131–3 относятся следующие достоинства:
- FUNCTION_BLOCK расширены до классов (как С++ расширил структуры до классов);
- METHOD/END_METHOD добавлены методы;
- Вызов метода: Instance.Method(P1, P2, …);
- EXTENDS — наследование;
- INTERFACE — использование интерфейсов;
- IMPLEMENTS реализация интерфейса внутри функционального блока;
- THIS/SUPER доступ к методам базовых классов.
Основное расширение касается превращения функционального блока (FUNCTION_BLOCK) в класс. Подобным образом структуры выросли в классы в языке C++. Это достигается введением методов. Фактически метод это функция, встроенная в функциональный блок. В реализации функции доступны не только значения ее параметров и локальных переменных, но и данные экземпляра функционального блока. В итоге, вызов метода всегда включает имена экземпляра и метода [1].
Следующий пример, представленный на рисунке 1, показывает определение и вызов простого метода:
Рис.1. Определение и вызов простого метода
Естественно, вызов метода можно выполнить и в графических языках, как проиллюстрировано на рисунке 2:
Рис.2. Определение и вызов простого метода на языке стандарта МЭК 61131–3 FBD
Даже если функциональный блок имеет методы, ни что не мешает использовать его обычным образом, как определено в стандарте МЭК 61131–3.
Помимо пользовательских методов и стандартной реализации, функциональный блок включает два предопределенных метода: Init и Exit.
Init — вызывается неявно для всех экземпляров всех функциональных блоков после загрузки кода приложения или холодного рестарта контроллера.
Exit — вызывается перед горячим обновлением кода экземпляра, перед сбросом или управляемым отключением питания ПЛК. Например, его можно применить для корректного завершения работы [3].
Для упрощения, правила видимости заданы требовательно, что представлено в таблице 1.
Таблица 1
Возможности доступа элементов
|
Тип элемента |
Внешний доступ на чтение |
Внешний доступ на запись |
Внешний отзыв |
|
VAR |
- |
- |
- |
|
VAR_INPUT |
- |
+ |
- |
|
VAR_OUTPUT |
+ |
|
- |
|
METHOD |
- |
- |
+ |
Уже существующий класс может быть дополнен с помощью ключевого слова EXTENTS, как проиллюстрировано на рисунке 3.
Рис. 3. Наследование в стандарте МЭК 61131–3
Однако реальную мощь ООП дает возможность создания интерфейсов. Под интерфейсом понимается набор методов работающих с одинаковыми параметрами, но разными реализациями для разных функциональных блоков. Интерфейс можно передать в качестве параметра и программный компонент (POU) не будет в действительности заботиться о том, какой функциональный блок им применяется [1].
Следующий пример на рисунке 4 иллюстрирует данную технику:
Рис. 4. Создание интерфейса
Множество функциональных элементов, на которые разбита программа — Program Organization Units (POU), каждый из которых может состоять из функций, функциональных блоков и программ. Любой элемент МЭК — программы может быть сконструирован иерархически из более простых элементов [4];
Теперь напишем несколько функциональных блоков, реализующих интерфейс Drive (привод) с помощью ключевого слова IMPLEMENTS, как проиллюстрировано на рисунке 5.
Рис. 5. Наследование от реализованного ранее интерфейса
Как можно видеть, все методы интерфейса Drive наполнены специальными реализациями, построенными на CAN сообщениях. Сверх того здесь присутствуют некоторые специфические переменные и методы. В данном случае это метод, устанавливающий CAN Id. Далее можно описать еще один вид привода, например аналоговый (AnalogDrive). В нем можно реализовывать методы совершенно иначе, чем для цифрового привода (CANDrive) [4].
Теперь можно написать функциональный блок, получающий интерфейс в качестве параметра, как проиллюстрировано на рисунке 6.
Рис. 6. Вызов метода реализованного интерфейса
Данный POU сможет работать с разными типами приводов, причем обратите внимание, что ни какой их дифференциации в нем абсолютно нет, как проиллюстрировано на рисунке 7.
Рис. 7. Работа с переопределением переменных
Также легко можно применять интерфейсы как обычные типы данных, например, создавать массивы. Это позволяет использовать следующий прием:
Рис. 8. Использование интерфейса как тип данных
В заключение, сталкиваемся с вопросом: действительно ли программистам ПЛК нужна технология ООП?
Исследования тысяч приложений созданных в CoDeSys показали, что уже сейчас многие программисты пытаются реализовать конструкции ООП в своих проектах. Имея дело с абстрактными приводами, сетями или агрегатами машин, они создают функциональные блоки с управляемым специальными флагами поведением. Это, указывает на растущую необходимость прихода объектного подхода в мир автоматизации. Достаточно многие пользователи 3S пытаются самостоятельно компенсировать отсутствие ООП, прилагая значительные усилия, чтобы иметь возможность автоматически генерировать код для однотипных приложений. Некоторые же открыто взывают к добавлению объектно-ориентированной функциональности.
С одной стороны, программисты, имеющие соответствующее образование и опыт, смогут более эффективно работать в области прикладного программирования контроллеров. Они будут снабжены необходимыми технологиями и инструментарием, хорошо зарекомендовавшим себя в создании программ для персональных компьютеров в области ИТ. В самом деле, многие профессиональные программисты давно ждут таких расширений.
С другой стороны, есть технологи и инженеры, которым хорошо известна функциональность и специфические характеристики их машин и производств. В будущем они смогут сосредоточиться на своих основных задачах и создавать собственные машины, включая полноценные управляющие программы, с помощью модулей, которые разработают для них программисты. И всё это не написав ни единой строчки кода!
Литература:
1. Дитер Хесс. Объектно-ориентированные расширения МЭК 61131–3 // Современные технологии автоматизации. 2006 г. № 2.
2. Зюбин В. Е. К пятилетию стандарта IEC 1131–3. Итоги и прогнозы // Приборы и системы управления. 1999 г. № 1.
3. Шамгунов Н. Н., Корнеев Г. А., Шалыто А. А. State Machine — расширение языка Java для эффективной реализации автоматов // Санкт-петербургский государственный университет информационных технологий, механики и оптики. Кафедра “Технологии программирования”. 2004
4. Шопырин Д. Г., Шалыто А. А. Объектно-ориентированный подход к автоматному программированию. 2003.
