Библиографическое описание:

Ахметов Н. Р., Макаров А. А. Объектно-ориентированные расширения в программировании систем автоматизации // Молодой ученый. — 2015. — №13. — С. 96-100.

В области программирования систем автоматизации на производстве сегодня наблюдаются две тенденции: во-первых, в этой сфере применяются компьютерные информационные технологии (ИТ), во-вторых, при написании прикладных программ с успехом используется модульный принцип.

Оптимизация затрат на проектирование систем автоматизации в производстве, в том числе в машиностроении, а также в мобильных приложениях, автоматизации зданий сегодня является одним из высокоприоритетных вопросов. Программирование прикладных задач составляет значительную часть этих затрат. Неудивительно, что многие ведущие компании, работающие в данной области, всерьез задумываются над тем, какие концепции или парадигмы программирования систем управления им стоит использовать в будущем [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

Рис.1. Определение и вызов простого метода

 

Естественно, вызов метода можно выполнить и в графических языках, как проиллюстрировано на рисунке 2:

2

Рис.2. Определение и вызов простого метода на языке стандарта МЭК 61131–3 FBD

 

Даже если функциональный блок имеет методы, ни что не мешает использовать его обычным образом, как определено в стандарте МЭК 61131–3.

Помимо пользовательских методов и стандартной реализации, функциональный блок включает два предопределенных метода: Init и Exit.

Init — вызывается неявно для всех экземпляров всех функциональных блоков после загрузки кода приложения или холодного рестарта контроллера.

Exit — вызывается перед горячим обновлением кода экземпляра, перед сбросом или управляемым отключением питания ПЛК. Например, его можно применить для корректного завершения работы [3].

Для упрощения, правила видимости заданы требовательно, что представлено в таблице 1.

Таблица 1

Возможности доступа элементов

Тип элемента

Внешний доступ на чтение

Внешний доступ на запись

Внешний отзыв

VAR

-

-

-

VAR_INPUT

-

+

-

VAR_OUTPUT

+

 

-

METHOD

-

-

+

 

Уже существующий класс может быть дополнен с помощью ключевого слова EXTENTS, как проиллюстрировано на рисунке 3.

3

Рис. 3. Наследование в стандарте МЭК 61131–3

 

Однако реальную мощь ООП дает возможность создания интерфейсов. Под интерфейсом понимается набор методов работающих с одинаковыми параметрами, но разными реализациями для разных функциональных блоков. Интерфейс можно передать в качестве параметра и программный компонент (POU) не будет в действительности заботиться о том, какой функциональный блок им применяется [1].

Следующий пример на рисунке 4 иллюстрирует данную технику:

4

Рис. 4. Создание интерфейса

 

Множество функциональных элементов, на которые разбита программа — Program Organization Units (POU), каждый из которых может состоять из функций, функциональных блоков и программ. Любой элемент МЭК — программы может быть сконструирован иерархически из более простых элементов [4];

Теперь напишем несколько функциональных блоков, реализующих интерфейс Drive (привод) с помощью ключевого слова IMPLEMENTS, как проиллюстрировано на рисунке 5.

5

Рис. 5. Наследование от реализованного ранее интерфейса

 

Как можно видеть, все методы интерфейса Drive наполнены специальными реализациями, построенными на CAN сообщениях. Сверх того здесь присутствуют некоторые специфические переменные и методы. В данном случае это метод, устанавливающий CAN Id. Далее можно описать еще один вид привода, например аналоговый (AnalogDrive). В нем можно реализовывать методы совершенно иначе, чем для цифрового привода (CANDrive) [4].

Теперь можно написать функциональный блок, получающий интерфейс в качестве параметра, как проиллюстрировано на рисунке 6.

6

Рис. 6. Вызов метода реализованного интерфейса

 

Данный POU сможет работать с разными типами приводов, причем обратите внимание, что ни какой их дифференциации в нем абсолютно нет, как проиллюстрировано на рисунке 7.

7

Рис. 7. Работа с переопределением переменных

 

Также легко можно применять интерфейсы как обычные типы данных, например, создавать массивы. Это позволяет использовать следующий прием:

8

Рис. 8. Использование интерфейса как тип данных

 

В заключение, сталкиваемся с вопросом: действительно ли программистам ПЛК нужна технология ООП?

Исследования тысяч приложений созданных в CoDeSys показали, что уже сейчас многие программисты пытаются реализовать конструкции ООП в своих проектах. Имея дело с абстрактными приводами, сетями или агрегатами машин, они создают функциональные блоки с управляемым специальными флагами поведением. Это, указывает на растущую необходимость прихода объектного подхода в мир автоматизации. Достаточно многие пользователи 3S пытаются самостоятельно компенсировать отсутствие ООП, прилагая значительные усилия, чтобы иметь возможность автоматически генерировать код для однотипных приложений. Некоторые же открыто взывают к добавлению объектно-ориентированной функциональности.

С одной стороны, программисты, имеющие соответствующее образование и опыт, смогут более эффективно работать в области прикладного программирования контроллеров. Они будут снабжены необходимыми технологиями и инструментарием, хорошо зарекомендовавшим себя в создании программ для персональных компьютеров в области ИТ. В самом деле, многие профессиональные программисты давно ждут таких расширений.

С другой стороны, есть технологи и инженеры, которым хорошо известна функциональность и специфические характеристики их машин и производств. В будущем они смогут сосредоточиться на своих основных задачах и создавать собственные машины, включая полноценные управляющие программы, с помощью модулей, которые разработают для них программисты. И всё это не написав ни единой строчки кода!

 

Литература:

 

1.                  Дитер Хесс. Объектно-ориентированные расширения МЭК 61131–3 // Современные технологии автоматизации. 2006 г. № 2.

2.                  Зюбин В. Е. К пятилетию стандарта IEC 1131–3. Итоги и прогнозы // Приборы и системы управления. 1999 г. № 1.

3.                  Шамгунов Н. Н., Корнеев Г. А., Шалыто А. А. State Machine — расширение языка Java для эффективной реализации автоматов // Санкт-петербургский государственный университет информационных технологий, механики и оптики. Кафедра “Технологии программирования”. 2004

4.                  Шопырин Д. Г., Шалыто А. А. Объектно-ориентированный подход к автоматному программированию. 2003.

Обсуждение

Социальные комментарии Cackle