Ведущий. Согласны ли Вы с заявлением, что стандарты являются некими конституционными правилами построения систем промышленной автоматизации, и языки МЭК в том числе? Если да, то хорошо это или плохо?

И. Петров. В действительности применение стандартов не ограничивает творчество, напротив, благодаря стандартам можно быстро, не ломая голову, решить 90 % типовых проблем и сосредоточиться на творческой части. На самом деле уровень стандартизации недостаточно высок, и изза этого возникает зависимость пользователей от крупных компанийизготовителей ПЛК. Нестандартное оборудование приходится покупать, несмотря на высокие цены. Эти причины привели к созданию CoDeSys Automation Alliance – некоммерческой организации, объединяющей на сегодняшний день 80 компаний, изготавливающих программно совместимое оборудование. Мы гарантированно можем использовать совместно ПЛК Kontron Think IO Premium, обладающие рекордным быстродействием, однокристальные ПЛК Beck IPC@CHIP, новейшие ПЛК Moeller, Mitsubishi, KEB, Fastwel, ОВЕН и других участников Альянса. Все контроллеры легко стыкуются между собой и программируются в единой среде CoDeSys.

С. Соловьёв. Основной целью стандарта МЭК 611313 на момент его введения в 1993 г. было упорядочивание существующего многообразия языков программирования для ПЛК, разработанных различными компаниями, но построенных, тем не менее, на весьма схожих принципах. Подобно стандарту МЭК 611313, большинство других стандартов в области промышленной автоматизации приходит из жизни, а не из науки: техника и технологии развиваются настолько стремительно, что порой бывает проще реализовать новые технические решения на практике, чем систематизировать в виде отраслевого или межгосударственного стандарта. А некоторые стандарты вообще просто переходят из статуса “дефакто” в статус “деюре”. “Взаимоотношение” практики и стандартов двояко: с одной стороны, стандарты призваны служить цели повышения качества и эффективности технических решений, а с другой стороны, практика применения стандартов влияет на их совершенствование и развитие.

С. Гулько. Когда конституция хорошо продумана и, главное, выполняется всеми – это замечательно. Знание законов позволяет получать некоторые выгоды, незнание – порой и жить неплохо, да вот недолго.

Ведущий. Кому применение языков МЭК 61131 приносит наибольшую эффективность: разработчикам контроллеров, системным интеграторам или конечным пользователям?

С. Гулько. Если вы инженер, владеющий МЭК 61113, то проблем с переходом от одной среды разработки к другой не возникнет. Если вы поставщик оборудования, вы можете быть уверены, что на рынке существует спрос именно на соответствующие стандарту решения. Конечный пользователь – владелец компании, руководитель отдела автоматизации, получает своего рода страховку, и если даже разработчик системы контроля и управления исчезнет, всегда можно будет найти специалистов, способных быстро разобраться в созданном на заказ ПО (кто хоть раз оставался один на один с мегабайтом чужого кода на С, тот меня поймет). Может показаться, что больше всех выигрывает системный интегратор – есть и люди, и оборудование, но это не совсем так. МЭК 61113 – союз равных возможностей, где каждый занимает свою нишу. Выгоду получают все, кто играет по одним правилам, и правила эти просты и прозрачны.

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

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

Ведущий. Организацией PLCopen введены три уровня совместимости и переносимости программ:
 

• на уровне подмножеств базовых компонентов, определяемых стандартом (типы переменных, языковые конструкции и т.п.);
• на уровне функций и функциональных блоков между различными системами (для этой цели был введен специальный формат файла обмена);
• на уровне завершенных приложений.

Насколько эффективно на этих уровнях решаются сегодня задачи совместимости и переносимости программ?

С. Гулько. Если идет речь о переносимости программ из одной среды разработки в другую методом прямого импорта/экспорта, то эта задача никем не решается. Мне не приходилось сталкиваться с ситуацией, когда люди, долгое время использующие ISaGRAF или CoDeSys, потом решали портировать задачу в другую систему. Не потому, что это сложно или нет технической возможности, скорее, нет необходимости.

А вот переносимость между различными версиями сред разработки языковая совместимость облегчает очень сильно. Между выходом 3ей и 5ой версиями ISaGRAF прошло порядка 10 лет, однако все старые наработки могут быть очень просто перенесены в новую среду.

Что же касается совместимости на уровне завершенных приложений, то я ее считаю (это мое личное мнение) немного утопичной. Достичь ее можно лишь за счет использования всеми одной и той же ОС либо же применения виртуальной машины, обрабатывающей байткод. По последнему пути пошла компания ICS Triplex ISaGRAF, сделав исполнительное ядро легко переносимым с платформы на платформу. Компилятор ISaGRAF Workbench создает независимый байткод, способный выполняться на любой целевой платформе. Достаточно удобное решение, но это решение одной компании и решение одной технологии.

Есть другое направление, когда код создается под конкретную платформу. Понятно, что о переносимости на уровне приложений речи идти уже не может.

И. Петров. Проще всего переносимость реализуется для текстовых языков. В CoDeSys на базовый уровень сертифицированы языки IL и ST. Переносить программы на этих языках можно с помощью текстовых файлов или через буфер обмена. В CoDeSys можно автоматически конвертировать программные компоненты в разные языки. Экспорт и импорт через текстовый формат PLCopen поддержаны в CoDeSys для всех МЭК языков. Но сохранение информации о графическом представлении элементов в этом формате не предусмотрено. Дополнительная информация о настройках сети, конфигурации задач, оборудования и т.п. тоже остается за бортом. Таким образом, перенести МЭК программы из одной системы в другую реально, но ручной работы при этом остается немало.

Если вы используете компоненты, реализованные внешними средствами с закрытым кодом, то возникает проблема переносимости даже между разными ПЛК в одной среде. В CoDeSys все стандартные библиотеки написаны на МЭК языках и переносимы без адаптации. При переносе проекта на другой ПЛК обычно достаточно только перенастроить конфигурацию входов/выходов.

В целом, не справедливо говорить, что, например, С программы легче переносимы, чем МЭК программы. Совместимости файлов проектов интегрированных компиляторов разных изготовителей нет, кроме того, существует тесная связь кода с аппаратными средствами и интерфейсами ОС.

Безусловно, мы должны стремиться обеспечить прозрачную переносимость МЭК приложений. При инициативном участии 3S PLCopen подготовлен документ, описывающий правила сохранения полной

информации о проекте в XML. Этот формат уже реализован в CoDeSys ENI (интегрированный многопользовательский инструмент управления версиями проекта). Если он будет поддержан в других средах, то это даст возможность говорить не просто о переносимости, но и об одновременной работе с одним проектом из нескольких сред программирования.

С. Соловьёв. Характеристики переносимости и совместимости ПО относятся скорее к реализации средств разработки, чем к самому стандарту МЭК 611313. На идейном уровне совместимость между различными пакетами прослеживается прекрасно, совместимость на уровне языковых средств и функциональных блоков весьма развитая, но говорить об автоматическом экспорте проектов из одного пакета в другой все же не приходится.

Ведущий. Каковы области компетенции стандарта МЭК 61131?

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

Как уже было сказано выше, МЭК системы дают четкое разделение прикладного и системного ПО. Поэтому они все шире применяются не только в ПЛК, но и в разнообразных универсальных приборах, требующих настройки или программирования пользователем.

С. Соловьёв. Область компетенции стандарта МЭК 611313 – технологическое ПО контроллеров систем автоматизации различного масштаба и функционального назначения. Средства разработки, поддерживающие языки стандарта МЭК 611313, позволяют эффективно решать большинство типичных задач, возникающих при создании и сопровождении ПО ПЛК (опрос двоичных, аналоговых и цифровых датчиков, формирование управляющих сигналов по различным законам, обработка и регистрация информации, обмен данными с сопряженными системами и т.п.). Применение средств разработки на базе стандарта МЭК 611313 в таких “стандартных” для них задачах дает сокращение временных затрат на разработку, упрощает сопровождение и модернизацию ПО. В то же время при решении “нестандартных” задач, связанных с необходимостью реализации новой функциональности на уровне системного ПО контроллера, средства стандарта МЭК 611313 могут оказаться недостаточно адекватными. Таким образом, основные достоинства технологии разработки ПО на основе стандарта МЭК 611313 лежат в экономической области, причем эффективность снижается по мере увеличения доли нестандартных задач.

С. Гулько. Если не вдаваться в многословные пассажи, это руководство к действию для разработчиков ПО. Причем не систем управления, а именно систем разработки (таких как ISaGRAF или Unity).

Ведущий. Какие среды разработки и языки программирования по стандарту МЭК 61131 Вы используете наиболее часто?

С. Соловьёв. Наша компания использует пакеты Unity Pro и ISaGRAF, наши языковые предпочтения – ST и SFC. Вопрос выбора средств разработки ПО ПЛК для нас – это вопрос выбора наиболее эффективного варианта по следующим основным критериям: скорость разработки/трудоемкость, технический уровень решения, степень “нестандартности” решаемой задачи для данного средства разработки, возможности сопровождения и развития. На наш взгляд, самое главное правило использования средств разработки на основе языков МЭК – применять их для тех задач, для которых они предназначены. Попытки нарушения этого правила могут привести к неприятным последствиям: от срыва сроков реализации проекта до невозможности реализации требуемой функциональности. Средство от недоразумений и разочарований при применении пакетов, поддерживающих языки стандарта МЭК 611313, – объективная оценка соответствия требованиям решаемой задачи.

С. Гулько. Наша компания является официальным дистрибьютором ICS Triplex ISaGRAF, посему выбор тут однозначный. Отмечу, что это не только политическое, но и практическое решение. Огромная база поддерживаемых контроллеров и различного оборудования делает ISaGRAF действительно удобным инструментом, пригодным для решения широкого круга задач.

Если говорить о языках программирования, то тут предпочтения склоняются к SFC и ST. Из не относящихся к МЭК 61113 могу отметить FC. Постепенно осваиваем новые функциональные блоки стандарта МЭК 61499 (ОО программирование).

По большому счету у каждого языка есть своя ниша, где его синтаксические особенности будут проявляться в наиболее выгодном свете, нужно лишь определиться.

И. Петров. По предыдущему опыту мне близки языки C и С++. Благодаря широкой поддержке типов данных, указателей и оптимизирующему компилятору, в CoDeSys программы на C транслируются в ST, и наоборот, что называется, “в лоб” – строчка в строчку. На графических языках программы часто получаются красивее, но требуют иной методологии программирования и соответственно изменения привычек. При работе в CoDeSys 3.0 сложные неуклюжие функциональные блоки превращаются в компактные изящные объекты. Мы проводили исследование популярности разных МЭК языков среди программистов CoDeSys. Его результаты опубликованы в журнале “Промышленные АСУ и контроллеры”, № 4, 2006.

Ведущий. Какая бизнесмодель продажи средств SoftPLC является на Ваш взгляд наиболее подходящей для России?

И. Петров. В конкурирующих с CoDeSys системах используется бизнесмодель, ориентированная на изготовителей контроллеров. Изготовитель с минимальными усилиями и затратами получает поддержку системы, затем пользователи контроллеров обязаны купить среду программирования. Это удобно изготовителям и выгодно дистрибьюторам системы программирования, но не удобно пользователям ПЛК, которые являются первоисточником финансовых ресурсов. Бизнесмодель 3S ориентирована на пользователей. В CoDeSys изготовитель ПЛК или системный интегратор оптом покупает лицензии у 3S, выполняет адаптацию и решает все технические и организационные проблемы. Многие пользователи CoDeSys годами успешно работают с системой, получая ее бесплатно в комплекте с ПЛК, они и понятия не имеют о том, что это коммерческий продукт. В России эта модель работает хорошо, в то же время у западного пользователя, напротив, бесплатное ПО не вызывает доверия. Однако ничто не мешает изготовителю ПЛК использовать CoDeSys как ядро системы, продаваемой под собственной торговой маркой (Wago – Wago IO Pro, Beckoff – TwinCAT, Moeller – XSoft).

Главной проблемой продаж CoDeSys на российском рынке является отсутствие привычки относиться к ПО, как к товару. Решение о покупке станка за 1 млн. евро принимается гораздо легче, чем программы за 10 тыс., хотя в обоих случаях речь идет о приобретении средств производства, приносящих прибыль многие годы. Почти все изготовители ПЛК, перешедшие на CoDeSys, начинали с идеи самостоятельной разработки. Им нужно было потратить несколько лет и значительные средства, чтобы увидеть, как пользователи уходят, порой предпочитая более слабые изделия конкурентов, но программируемые инструментом с мировым авторитетом. Поддержка CoDeSys не означает прекращения собственных разработок изготовителя ПЛК, напротив, она дает возможность сосредоточиться на них и быстро получить результаты, выраженные в цифрах бухгалтерии.

Еще раз подчеркнем, что бизнесмодель 3S ориентирована на пользователей, и российские пользователи (и наиболее дальновидные изготовители ПЛК) поддерживают эту идею. Популярность CoDeSys в России и Украине растет сейчас достаточно быстрыми темпами, хотя справедливости ради следует отметить, что больше сказываются высокие технические характеристики и позитивные отзывы, чем бизнесмодель.

С. Соловьёв. Наиболее подходящая бизнесмодель продажи средств SoftPLC для нас как для независимой компанииразработчика может быть выражена формулой “качественные средства разработки за меньшие деньги”.

Ведущий. Насколько удобной на Ваш взгляд является циклическая модель работы программ, принятая в ISaGRAF и CoDeSys?

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