 |
Вопросы развития стандарта МЭК 61131-3 обсуждаются сегодня практически на всех конференциях специалистов промышленной автоматизации во всем мире. Не раз эта тема вызывала горячие дискуссии и на страницах Интернет форума нашего журнала. Тем не менее, абсолютное большинство изготовителей систем программирования по-прежнему сосредотачивают свои усилия на развитии сервисных средств, избегая коренных усовершенствований самих языков. Помимо высокой сложности, подобные эксперименты могут катастрофически сказаться на коммерческом успехе продукта. Чтобы решиться на такой шаг нужно иметь значимый авторитет и уверенность, подтвержденную серьезными исследованиями.
Сегодня мы представляем вам статью основателя и директора компании Smart Software Solutions GmbH Дитера Хесса. Ему принадлежит ряд идей, которые уже вошли в стандарты либо активно обсуждаются в рабочих группах МЭК. В очередной раз он предоставляет CoDeSys в качестве рабочей платформы для практического исследования передовых новшеств. |
Цели
В то время как в сфере компьютерных приложений объектно-ориентированное программирование (ООП) давно стало составной частью всех ведущих языков, в сфере контроллерных приложений оно применяется крайне редко. Говорят, что это происходит в силу некоторой консервативности свойственной программистам контроллеров (ПЛК). Отчасти это действительно так. Но все же в более значительной степени здесь сказываются ограниченные возможности инструментов программирования. Конечно, почти все современные контроллерные платформы дают возможность, так или иначе, использовать C++ (за дополнительные деньги). Однако компилятор обеспечивает только лишь аспекты чистого программирования. Функции отладки и ввода в эксплуатацию этих систем практически непригодны для контроллерных приложений. Даже для элементарного мониторинга значений входов-выходов приходиться писать вызовы библиотечных функций. О таких приемах как «горячая» замена кода прикладной программы без остановки контроллера вообще нужно забыть. Помимо этого автоматы и задачи с битовыми операциями реализуются в C++ достаточно сложно.
Требования
В результате, компанией 3S-Smart Software Solutions было принято решение расширить нормы стандарта МЭК 61131-3, введя поддержку ООП в новое поколение системы программирования CoDeSys. Расширения стандарта должны подчиняться следующим требованиям:
Расширения
Основное расширение МЭК 61131-3 касается превращения функционального блока (FUNCTION_BLOCK) в класс. Подобным образом структуры выросли в классы в языке C++. Это достигается введением методов. Фактически метод это функция, встроенная в функциональный блок. В реализации функции доступны не только значения ее параметров и локальных переменных, но и данные экземпляра функционального блока. В итоге, вызов метода всегда включает имена экземпляра и метода.
Следующий пример показывает определение и вызов простого метода:
Естественно, вызов метода можно выполнить и в графических языках:
Даже если функциональный блок имеет методы, ни что не мешает использовать его обычным образом, как определено в стандарте МЭК 61131-3.
Помимо пользовательских методов и стандартной реализации, функциональный блок включает два предопределенных метода: Init и Exit.
Init вызывается неявно для всех экземпляров всех функциональных блоков после загрузки кода приложения или холодного рестарта контроллера.
Exit вызывается перед горячим обновлением кода экземпляра, перед сбросом или управляемым отключением питания ПЛК. Например, его можно применить для корректного завершения работы.
Для упрощения, правила видимости заданы жестко:
| Тип элемента | Внешний доступ на чтение | Внешний доступ на запись | Внешний вызов |
| VAR | - | - | - |
| VAR_INPUT | - | + | - |
| VAR_OUTPUT | + | - | - |
| METHOD | - | - | + |
Уже существующий класс может быть дополнен с помощью ключевого слова EXTENTS.
Однако реальную мощь ООП дает возможность создания интерфейсов. Под интерфейсом понимается набор методов работающих с одинаковыми параметрами, но разными реализациями для разных функциональных блоков. Интерфейс можно передать в качестве параметра и программный компонент (POU) не будет в действительности заботиться о том, какой функциональный блок им применяется.
Следующий пример иллюстрирует данную технику:
Теперь мы можем написать несколько функциональных блоков, реализующих интерфейс Drive (привод) с помощью ключевого слова IMPLEMENTS.
Как можно видеть, все методы интерфейса Drive наполнены специальными реализациями, построенными на CAN сообщениях. Сверх того здесь присутствуют некоторые специфические переменные и методы. В данном случае это метод, устанавливающий CAN Id. Далее мы могли бы описать еще один вид привода, например аналоговый (AnalogDrive). В нем можно реализовывать методы совершенно иначе, чем для цифрового привода (CANDrive).
Теперь можно написать функциональный блок, получающий интерфейс в качестве параметра:
Данный POU сможет работать с разными типами приводов, причем обратите внимание, что ни какой их дифференциации в нем абсолютно нет.
Также легко можно применять интерфейсы как обычные типы данных, например, создавать массивы. Это позволяет использовать следующий прием:
Заключение
Может возникнуть вопрос: насколько целесообразны или даже допустимы описанные расширения действующего стандарта МЭК 61131-3?
Факт в том, что главное требование стандарта состоит выполнении однозначно описанных в нем конструкций, без каких либо отклонений. Это полностью применимо к функциональным блокам, которые полностью сохраняют все свойства «нормальных» функциональных блоков, не смотря на все нововведения.
Вы могли заметить, что описанные расширения языков программирования МЭК 61131-3 уже есть в других современных языках, таких как Java или C#. Однако инструментов созданных на их основе специально для решения задач автоматизации нет. Кроме того, переход на эти языки не соответствует практическим требованиям прикладных программистов.
В заключение, мы сталкиваемся с вопросом: действительно ли программистам ПЛК нужна технология ООП? Наши исследования тысяч приложений созданных в CoDeSys показали, что уже сейчас многие программисты пытаются реализовать конструкции ООП в своих проектах. Имея дело с абстрактными приводами, сетями или агрегатами машин, они создают функциональные блоки с управляемым специальными флагами поведением. Это, указывает на растущую необходимость прихода объектного подхода в мир автоматизации. Достаточно многие пользователи 3S пытаются самостоятельно компенсировать отсутствие ООП, прилагая значительные усилия, чтобы иметь возможность автоматически генерировать код для однотипных приложений. Некоторые же открыто взывают нас к добавлению объектно-ориентированной функциональности.
Мир PC прошел тот же позитивный путь развития. Так популярность языка Basic, предназначенного для самого широкого круга программистов, значительно возросла после добавления в него ООП расширений.
Популярность CoDeSys в области промышленной автоматизации такова, что можно гарантировать непрерывную доработку и развитие новых функций. Кроме того, 3S будет продвигать включение объектно-ориентированных расширений в стандарт МЭК 61131-3.