Angry Birds на PLC?

В предыдущем топике ^[1] я обещал подробнее описать особенности программирования промышленных PLC, и почему такое программирование все больше напоминает разработку обычного софта. О языке IEC61131-3 (промышленном диалекте Паскаля) я уже писал ^[2], также хорошим вступлением можно считать вот этот хабратопик ^[3]. Этот пост — о компиляторах PLC, средах разработки, особенностях программирования и эволюции языка и экосистемы.

Есть всего три основных производителя компиляторов IEC61131 — CoDeSys, KW и Siemens. Компилятор от Siemens используется в продуктах Siemens, а почти все остальные вендоры лицензируют компилятор CoDeSys ^[4] или KW ^[5]. Таким образом, 3 самых известных компилятора разрабатываются в небольших немецких городках.

У компиляторов малораспространенных языков есть общая проблема — у их производителей нет таких ресурсов, как, например у коммьюнити gcc или команды icc. Поэтому не получается оптимизировать backend под постоянно меняющиеся архитектуры, и использовать новейшие наборы инструкций. Код, скомпилированные таким не очень оптимизирующим компилятором, «спотыкается» сразу же — на фронт енде/декодере процессора. Многочисленные front end stalls хорошо видны в результатах анализа Vtune, вызванные промахами по I-cache (префетчер не справляется, особенно на Nehalem и более ранних) и другими причинами. Также многие экзотические или «молодые» бэкенды компиляторов спотыкаются на известной особенности ^[6] процессоров Atom. Конечно, наиболее trueъ решением было бы использовать LLVM. Странно, что никто еще до этого не додумался. Однако, похожая по духу идея пришла в голову инженерам KW — они просто компилируют IEC61131 в CLR. Ну а исполнение CLR уже вполне адекватно оптимизировано Microsoft. Ну а где CLR, там и C#. Еще одна фишка KW — возможность смешивать IEC61131 и C#. И разрабатывать все это в Microsoft Visual Studio.

Как еще можно получить производительность программы PLC, сравнимую с производительностью той же программы, написанной на C? Например, можно написать транслятор IEC61131-3 в C, и потом воспользоваться компилятором C. Так делает небольшая канадская команда Geb Automation ^[7]. С интересом слежу за их прогрессом. Также можно писать критичные по производительности модули на C, и вызывать их из PLC кода. Сделать аналог JNI для IEC61131. Этот подход поддерживают уже почти все — например Siemens, B&R, Beckhoff (остальные, наверное, тоже, но лично я не сталкивался, т.к. фича пока не очень стандартная).

Производителей IDE, приспособленных для разработки PLC, гораздо больше, чем производителей компиляторов. Их список практически совпадает со списком популярных вендоров железа PLC (+ KW и CoDeSys, которые своего железа почти не делают). Свои среды разработки производят Siemens, Rockwell, Phoenix, Omron, Beckhoff, B&R, CoDeSys, KW. Почти все они пишут свои собственные среды с уникальным драг энд дропом, но, как я писал выше, KW использует MS Visual Studio. Beckhoff недавно заменила свою среду, целиком базирующуюся на CoDeSys, на свой собственный плагин к MS Visual Studio. Он позволяет разрабатывать и отлаживать PLC в популярной и развитой среде разработки, но внутри у него компилятор от CoDeSys (который, в отличие от компилятора KW, производит сразу машинный код, а не код CLR).

Одной из интересных особенностей разработки PLC является то, что один и тот же код можно писать и рассматривать с разных сторон — «недоассемблер» IL, «странный паскаль» ST, «блок схемы» FBD, «электрическая логика» LD. Одна из важных возможностей (и вообще raison d'être) IDE для PLC — переход и трансляция между этими формами. Это немного роднит эти IDE с основоположником жанра рисования картинок, которые генерят код, и кода, который перерисовывает картинку прямо в IDE — Delphi. Интересно, что при разработке PLC можно подняться еще на один уровень абстракции, и воспользоваться MathWorks Simulink ^[8]. У известного производителя Matlab'a есть специальный продукт для разработчиков PLC, который позволяет генерить IEC61131-3 ST код из Matlab функций, моделей Simulink и flow диаграм. Вот так примерно выглядит.

Нажимаешь на кнопочку «Generate PLC Code» и графическая модель с картинки преобразуется в «почти Паскаль».

C Angry Birds в названии поста я, конечно, погорячился. Хотя написать ее на PLC можно, и даже с настоящими актуаторами, я пока видел только Mahjong, реализованный на IEC61131-3 ST, который можно запустить на промышленном контроллере с HMI.

Собственно, кроме HMI он ничего не трогает, но это можно исправить. Заглавная картинка — тоже программа на IEC61131, она управляет роботом, который играет против человека в крестики-нолики. Я снял эту картинку в прошлом ноябре у стенда CoDeSys на выставке SPS Drives. С Angry Birds у многих ассоциируются апп сторы — основной канал распространения, сделавший эту игру знаменитой. Недавно появился первый App Store ^[9] дла программ PLC! Так что появилась уникальная возможность забацать популярную игрушку для еще одного магазина. Я не знаю, насколько модель app store'a применима в этой области — пока я в нем насчитал всего 50 приложений трех производителей. Таким образом, в разработку PLC на экзотическом языке пробираются следующие общеайтишные технологии — Visual Studio, Matlab, линковка с кодом на C, CLR/C#, и даже app store.

Конечно, излишним было бы упоминание того, что все описанные выше компиляторы и среды позволяют генерировать код для многих процессорных архитектур, использующихся в автоматизации, в том числе и X86. Как сотрудника Intel меня очень радует, что платформы x86 используются в этой области все чаще и чаще.

Автор: izard

Источник ^[10]