Перспективы развития языков МЭК 61131-3 в новом поколении комплекса CoDeSys

Недостатки и необходимость развития языков МЭК 61131-3 обсуждаются специалистами не первый год. Тем не менее, изготовители инструментов программирования не спешат экспериментировать. Предложив неудачное новшество можно серьезно пострадать. Недовольные пользователи постараются перейти на конкурирующие продукты. Выполнить же "откатку" будет гораздо сложнее, чем ввести новшество. В итоге мы наблюдаем множество любопытных новшеств в сервисных и вспомогательных инструментах (конфигураторы сетей, создание распределенных проектов, средства быстрого ввода, библиотеки дополнительных блоков и др.) при весьма консервативном подходе к самим языкам.

Что касается CoDeSys, компания Smart Software Solutions GmbH (3S) тратит очень существенную долю своего бюджета на перспективные исследования. Регулярные конференции пользователей, исследования рынка, изучение проектов выполненных в CoDeSys, поддержка научных проектов, работа комитетах по стандартизации и др. Сейчас популярность CoDeSys в мире такова, что 3S может себе позволить идти на риск и внедрять стратегические новшества. Конечно, огромное число пользователей повышает ответственность. Но с другой стороны, пользователи CoDeSys это весьма высококвалифицированные специалисты во всем мире. Они не просто сказали "да" нововведениям, но и активно включились в творческий процесс. Комплекс непрерывно развивается уже 11 лет (на 2005г).

В текущей версии CoDeSys V2.3 присутствуют несколько хорошо "прижившихся" новшеств. Прежде всего, это упрощенный язык SFC. В стандартном SFC существуют шаги и независимые действия, связанные достаточно сложным образом. Это чрезвычайно мощный и выразительный язык. Однако исследования показали, что только 1 из десяти пользователей использует SFC по причине сложности понимания верного подхода к программированию. В итоге в CoDeSys появился упрощенный SFC (См. рис. ниже). Здесь каждый шаг имеет собственные встроенные действия. Их всего 3: входное - выполняющееся при активации шага, основное - работающее циклически (пока шаг активен) и выходное - выполняющееся при деактивации шага. Идея очень проста и позволяет превратить SFC из сложнейшего языка в простейший. Оба типа SFC можно совмещать. Постепенно приобретая навыки, пользователи "вырастают" до эффективного применения стандартного SFC языка.

Второе новшество это язык CFC. В стандартном FBD CoDeSys выполняет максимум автоматизации: автоматическое размещение, автотрассировка и четкий порядок выполнения диаграмм. Диаграмма разбита на множество цепей неочевидно взаимосвязанных. Это напоминает текстовый язык, в котором вместо строк инструкций нарисовали строки с "картинками". В итоге мы имеем удобный при программировании инструмент, но порой не достаточно выразительный. CFC это FBD без ограничений (См. рис. ниже). Здесь можно свободно размещать элементы, использовать обратные связи, произвольно задавать порядок исполнения и рисовать связные схемы "размером с простыню". Это уже напоминает принципиальную схему электронного устройства на микросхемах. Если программист имеет достаточный опыт и четко понимает, что он действительно делает, язык CFC дает ему соответствующую свободу для быстрого и красивого выражения своих замыслов.

Что раздражает в языках МЭК профессиональных программистов, использовавших ранее язык C, это невозможность прямого доступа к памяти и аппаратным ресурсам. Второй минус это передача параметров функции путем копирования, крайне тормозящая работу с объемными данными. Работа с файлами и реализация коммуникационных драйверов на языках МЭК вообще закрыта глухой стеной. Но мы же привыкли к тому, что если нельзя, но очень надо, то должен быть некий способ. По этим причинам в CoDeSys появились указатели и оператор адреса. Конечно, начинающим пользователям лучше бы об этом не знать.

Следующее новшество носит концептуальный характер. Это функциональные блоки (FB) с действиями. Стандартный FB уже представляет собой данные и код "в одном флаконе". То есть реализует "инкапсуляцию" одну из базовых идей объектно-ориентированного программирования (ООП). Однако крайне скудны средства управления поведением такого объекта. Конечно, можно ввести ряд флагов и указывать FB что мы от него хотим. Хотя это типовой прием, он крайне неэффективен. Решение напрашивается само. Кроме данных нужно встроить в FB и функции (они же действия или методы). Опыт оказался очень удачным. Но он послужил началом пути, по которому хочется пойти дальше.

Все серьезные промышленные компании считают нужным показывать не только идеи сегодняшнего дня, но и концептуальные продукты. Безусловно, концепт продукт нельзя купить, но по нему можно судить о стратегическом потенциале компании, о том насколько далеко вперед смотрят ее разработчики. Для 3S таким продуктом является CoDeSys 3.0. В 2005 году он демонстрируется на всех крупных выставках и обсуждается на конференциях. В него включены более 200 новшеств. Это принципиально новая платформа, а не очередная версия. Мы не будем сейчас углубляться в детали, остановимся только на главном: расширениях языков программирования.

В первую очередь, к этому относится полноценная реализация ООП. Она достигается с помощью ввода нескольких дополнительных ключевых слов. В функциональный блок можно включать пользовательские методы. Кроме того, каждый FB включает 2 метода вызываемых неявно для начальной инициализации и корректного завершения работы (перед сбросом или отключением питания). Например:

Методы можно вызывать во всех МЭК 61131-3 языках:

Класс можно наследовать при помощи ключевого слова EXTENTS. Подобно языку C# в CoDeSys 3.0 реализована концепция интерфейсов (INTERFACE). Интерфейс представляет собой набор методов работающих с одинаковыми параметрами, но разных по реализации. Так мы можем создать наборы методов (ключевое слово IMPLEMETS) поддерживающих работу с приборами одного назначения, но разных конструктивно или учитывающих их индивидуальные особенности. В итоге мы пишем программу, которой даже не известны детали поведения используемого объекта. Какие конкретно методы будут работать, определяется динамически. Так реализуется "полиморфизм" - сильнейшее свойство ООП. Интерфейсы можно использовать как типы данных, объявлять переменные и даже массивы, передавать в качестве параметра:

Мы описали интерфейс Move, содержащий методы Home и Step. Теперь в качестве примера, покажем реализацию интерфейса для пневматического толкателя:

Мы могли бы написать еще несколько реализаций данного интерфейса для других типов толкателей. Это дает возможность писать в своем приложении программные компоненты (POU), применяющие интерфейс, изолированно от подробностей типов толкателей. Нужный интерфейс мы передадим в качестве параметра. Контроллер будет динамически выполнять разный код, без громоздких проверок условных конструкций.

Расширения ООП выполнены опционально в виде надстройки. То есть функциональные блоки можно использовать без методов. Стандарт МЭК требует выполнения описанных им конструкций, что и выполняет CoDeSys 3.0. Конечно, он не просто удовлетворяет действующему стандарту, он делает это "сверху вниз". Тем не менее, 3S достаточно эффективно продвигает включение ООП расширений в стандарт. В настоящее время CoDeSys служит экспериментальной платформой МЭК.

Из множества второстепенных расширений МЭК, которые реализуются в CoDeSys V3.0, весьма интересны следующие:

• Посимвольное обращение к строкам, включая строки в уникоде (b := str1[2]; wstr1[i] := 323;).
• Использование выражений при инициализации переменных (x : INT := fun(y)*2; ax : POINTER TO INT := ADR(x);).
• Пользовательские функции с переменным числом параметров.
• Входы типа ANY_TYPE.
• Директивы условной компиляции.
• Контроль версий компонентов библиотек.
• Типы: объединение UNION, длительность двойной точности LTIME.
• CONTINUE в циклах.
• Метод Exit в функциональных блоках (необходим при замене кода в контроллере, без его остановки).
• Клоны приложений в контроллере.
• Включение параметрических устройств (не программируемых) в проект.

Интересно, что CoDeSys V3.0 реализован не как монолитный инструмент, он строится из компонентов (как платформа), которые можно обновлять независимо. Каждое обновление устанавливается не поверх старого, а в дополнение к нему. Внутри файла прикладного проекта сохраняется профиль системы, в которой он был создан. Это дает возможность открывать и компилировать старые проекты в точности теми инструментами, которые применялись при его создании.

Компонентная платформа CoDeSys 3.0 дает возможность изготовителю оборудования расширять систему самостоятельно. Например, он может включить в CoDeSys собственные редакторы и языки программирования.

Расширения МЭК 61131-3 языков выполненные 3S, открыты сегодня для обсуждения. Благодаря огромной армии пользователей можно гарантировать, что предложенные расширения будут тщательно отработаны и процесс развития CoDeSys на этом не остановится.