В предыдущем топике я обещал подробнее описать особенности программирования промышленных PLC, и почему такое программирование все больше напоминает разработку обычного софта. О языке IEC61131-3 ST (промышленном диалекте Паскаля) я уже писал, также хорошим вступлением можно считать вот этот хабратопик. Этот пост — о компиляторах PLC, средах разработки, особенностях программирования и эволюции языка и экосистемы. Есть всего три основных производителя компиляторов IEC61131 — CoDeSys, KW и Siemens. Компилятор от Siemens используется в продуктах Siemens, а почти все остальные вендоры лицензируют компилятор CoDeSys или KW. Таким образом, 3 самых известных компилятора разрабатываются в небольших немецких городках.
У компиляторов малораспространенных языков есть общая проблема — у их производителей нет таких ресурсов, как, например у коммьюнити gcc или команды icc. Поэтому не получается оптимизировать backend под постоянно меняющиеся архитектуры, и использовать новейшие наборы инструкций. Код, скомпилированный таким не очень оптимизирующим компилятором, «спотыкается» сразу же — на фронтенде/декодере процессора. Многочисленные front end stalls хорошо видны в результатах анализа Vtune, вызванные промахами по I-cache (префетчер не справляется, особенно на Nehalem и более ранних) и другими причинами. Также многие экзотические или «молодые» бэкенды компиляторов спотыкаются на известной особенности процессоров Atom. Конечно, наиболее trueъ решением было бы использовать LLVM. Странно, что никто еще до этого не додумался. Однако, похожая по духу идея пришла в голову инженерам KW — они просто компилируют IEC61131 в CLR. Ну а исполнение CLR уже вполне адекватно оптимизировано Microsoft. Ну а где CLR, там и C#. Еще одна фишка KW — возможность смешивать IEC61131 и C#. И разрабатывать все это в Microsoft Visual Studio.
Как еще можно получить производительность программы PLC, сравнимую с производительностью той же программы, написанной на C? Например, можно написать транслятор IEC61131-3 в C, и потом воспользоваться компилятором C. Так делает небольшая канадская команда Geb Automation. С интересом слежу за их прогрессом. Также можно писать критичные по производительности модули на 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. У известного производителя 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 для программ PLC! Так что появилась уникальная возможность забацать популярную игрушку для еще одного магазина. Я не знаю, насколько модель app store'a применима в этой области — пока я в нем насчитал всего 50 приложений трех производителей.
Таким образом, в разработку PLC на экзотическом языке пробираются следующие общеайтишные технологии — Visual Studio, Matlab, линковка с кодом на C, CLR/C#, и даже app store. Конечно, излишним было бы упоминание того, что все описанные выше компиляторы и среды позволяют генерировать код для многих процессорных архитектур, использующихся в автоматизации, в том числе и X86. Как сотрудника Intel меня очень радует, что платформы x86 используются в этой области все чаще и чаще.
