Программировать ПЛК просто, быстро и эффективно – иллюзия или реальность? (круглый стол)

Промышленные АСУ и контроллеры, 2006 (Соловьев С. "АВИАТЭКС",Петров И. "Пролог",Гулько С."Холит Дэйта Системс")

Программировать ПЛК просто, быстро и эффективно – иллюзия или реальность? (круглый стол)

Круглый стол На вопросы ведущего Круглого стола Александра Александровича Егорова, канд. техн. наук, первого заместителя главного редактора журнала, начальника Научно-учебного центра МАИ “Интеллектуальные системы измерений, контроля и управления в промышленности”, отвечают И.В. Петров, С.Ю. Соловьёв и С.В. Гулько. Представим участников обсуждения.

Игорь Петров – технический директор фирмы “Пролог” (г. Смоленск). С 1989 г. специализируется на языках и инструментах программирования ПЛК. Ему принадлежит большое число статей, посвященных языкам стандарта МЭК 611313, методике программирования, отладки и практического применения. Является автором одной из наиболее популярных книг по МЭКпрограммированию: “Программируемые контроллеры. Стандартные языки и приемы прикладного проектирования” (М.: СОЛОНПресс, 2004 г.). С 1999 г. активно сотрудничает с компанией 3SSmart Software Solutions GmbH в области применения и технического развития программного комплекса CoDeSys.

Сергей Соловьёв – канд. техн. наук, доцент кафедры “Приборы и измерительно-вычислительные комплексы” Московского авиационного института (МАИ), руководитель отдела разработок ООО “Авиатэкс”. Занимается вопросами разработки информационно-измерительных систем и комплексов на основе микроконтроллеров, ПЛК и интеллектуальных измерительных и управляющих устройств, в том числе с использованием средств разработки ISaGRAF, Concept, PL7, Unity. Читает лекции по курсу “Цифровые вычислительные устройства и микропроцессоры приборных комплексов”. Область профессиональных интересов – распределенные автоматизированные системы сбора данных и управления, программно-аппаратные платформы и средства разработки ПО.

Сергей Гулько работает в компании “ХОЛИТ Дэйта Системс” (г. Киев), образованной в 1991 г. группой научных сотрудников Киевского политехнического института – специалистов в области измерительной и микропроцессорной техникой.
Основными направлениями деятельности фирмы являются технический консалтинг, разработка, производство и внедрение инструментальных плат, модулей, преобразователей, контроллеров, промышленных компьютеров и других устройств для компьютерных систем на основе PCплатформы в области измерения, контроля, диагностики, управления и автоматизации технологическими процессами в промышленности. С.В. Гулько – ведущий специалист фирмы в области программирования в среде ISaGRAF, автор таких статей, как “ Обзор стандарта IEC 61499”, “Эволюция технологии ISaGRAF”, “ISaGRAF – это очень просто!”, “Образовательная программа National Instruments” в журнале “ПИКАД” (Промышленные измерения, контроль, автоматизация, диагностика, г. Киев).

Ведущий. Применяете ли Вы в своих разработках системы CoDeSys, ISaGRAF, Unity и др.?

Какие преимущества и недостатки Вы видите у них? На основе каких критериев Вы осуществили свой выбор?

С. Гулько. Люди ищут инструменты, которые позволяли бы облегчить каждодневную работу. Это касается абсолютно всех сфер деятельности человека, не является исключением и разработка программного обеспечения. Можно даже больше сказать – легкость применения зачастую является основополагающим фактором при выборе инструмента. Наша компания не является системным интегратором в обычном понимании этого слова, скорее, мы выступаем в роли консультантов. Мы рекомендуем использовать ISaGRAF для решения большинства задач из области автоматизации. Почему именно ISaGRAF, а не другие среды? По большому счету, для конечного пользователя нет особой разницы, в чем именно писать программу для контроллера, так как с этой точки зрения среды разработки не сильно различаются между собой. Посудите сами – языки одни и те же, концепция аналогична, даже пользовательские интерфейсы не очень отличаются. В такой ситуации выбор обуславливается поддержкой со стороны производителя контроллеров или оборудования – поддерживается ли их архитектура или нет.

Разница ощущается, если вы решили сделать чтото нестандартное. И тут ISaGRAF выгодно отличается от своих “собратьев по цеху”. Добавить поддержку нового оборудования, протокола обмена данными, аппаратной или программной платформы – все это делается очень просто. Именно этим и объясняется большое количество контроллеров, поддерживающих ISaGRAF. Производитель может и вносит изменения в ядро ISaGRAF, модифицируя его под свои нужды, что позволяет строить легкие и гибкие решения.

Гибкость и простота – вот два основных критерия, которые лежат в основе ISaGRAF. Инженеру нужно работать, ему некогда продираться через тысячи меню и десятки конфигурационных диалогов, стоящие перед ним задачи требуют решения уже сейчас (а очень часто – на вчера), и у него нет времени ждать, пока ктото добавит поддержку его платформы в свой компилятор.

И. Петров. Компания “Пролог” (до 1993 г. – Смоленское НПО “Техноприбор”) занимается разработкой и организацией серийного производства ПЛК с 1980 г. Традиционно наши ПЛК программировались посредством мнемонического языка собственной разработки. К середине 90х годов стала очевидной необходимость

разработки новых инструментальных средств программирования, поддерживающих языки стандарта МЭК 611313. Более двух лет ушло на изучение и анализ двух десятков наиболее известных на мировом рынке МЭКсистем программирования ПЛК. На их основе мы начали вынашивать концепции собственной разработки или адаптации готовой системы программирования. Сразу же отпали системы программирования, использующие интерпретацию исходного текста или промежуточного кода (процессоры в наших контроллерах были сравнительно слабыми, упор делался на снижение цены), поэтому нам был необходим компилятор программ в быстрый машинный код. Системы с внешним компилятором были отброшены в силу неудобства отладки. Проведение собственной разработки требовало значительных финансовых и, что не менее важно, временных затрат. Постепенно стало ясно, что наши идеи точно совпадают с тем, что уже реализовано немецкой компанией Smart Software Solutions (3S) в системе программирования CoDeSys. Тем не менее, решение о покупке CoDeSys далось тяжело, продукт был совсем молод, абсолютно неизвестен в России и не столь технически совершенен, как сейчас. Мы начали с применения CoDeSys в своих контроллерах, затем, убедившись в высоком качестве и перспективности продукта, в 2004 г. стали дистрибьютором 3S. На сегодняшний день круг замкнулся, и часть работ по CoDeSys выполняется нами в России. Благодаря сотрудничеству с 3S мы работаем с технологиями, которым только еще предстоит выйти на рынок и стать стандартами. Очень важен тот факт, что основатели компании 3S (Дитер Хесс и Манфред Вернер), разработавшие базовые идеи CoDeSys, сами активно продолжают участвовать во всех разработках. Работая вместе, мы чувствуем себя членами команды, объединенной желанием творчества, а не работниками по найму.

С. Соловьёв. Компания “Авиатэкс” работает в области промышленной автоматизации более 15 лет. За это время нами накоплен богатый опыт применения различных программных и аппаратных средств и технологий разработки. Наиболее масштабные проекты компании как системного интегратора и разработчика ПО связаны с созданием уникальных автоматизированных комплексов испытаний и автоматизированных систем учета энергии.

Изначально компанией был взят курс на максимальное использование современных и перспективных открытых международных стандартов и технологий. К числу таких открытых стандартов, безусловно, относится и стандарт МЭК 611313. Мы использовали средства разработки, поддерживающие этот стандарт, для реализации ряда проектов на базе контроллеров Smart IO компании PEP Modular Computers/Kontron (среда разработки ISaGRAF), Micro компании Schneider Electric (среда разработки PL7), Momentum компании Schneider Electric (среда разработки Concept) и других. Задачи, решаемые контроллерами в этих проектах, весьма типичны – ввод/вывод аналоговых и дискретных сигналов, реализация относительно простых законов управления и последовательные асинхронные коммуникации. Критерии выбора средств разработки – возможность быстрого получения работоспособного ПО, использования стандартных функций и функциональных блоков, а также легкость освоения.

Совсем другая ситуация возникла у нас при попытке использовать эти средства для реализации проектов в области испытательных комплексов и систем учета, имеющих существенные специфические особенности: необходимость реализации режима “жесткого” реального времени; развитой системы коммуникаций по различным интерфейсам с использованием нестандартных протоколов; “быстрой” регистрации результатов измерений; хранения больших объемов данных в контроллере и т.п. Оказалось, что часть из этих требований либо выполняется неэффективно, либо не выполняется совсем. В соответствии с этим для решения подобных задач мы использовали более традиционные средства разработки – Deplhi, C++ Builder, Visual C++, FasTrak C – для операционной системы реального времени OS9.

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

Этими соображениями мы руководствовались при выборе программноаппаратной платформы для разработки устройства сбора и передачи данных для системы коммерческого учета электрической энергии и мощности на базе оборудования и по заказу компании Schneider Electric. Из трех возможных средств разработки для контроллеров Schneider Electric (Concept, PL7, Unity), поддерживающих стандарт IEC 611313, мы остановили свой выбор на пакете Unity Pro XL – наиболее современном и универсальном из перечисленных.

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

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

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

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

В CoDeSys имеется очень удобный высокоуровневый способ обмена данными через сетевые переменные. С помощью специальных библиотек можно организовывать обмен сообщениями в разных сетях. Уникальными для CoDeSys являются переносимые, реализованные на МЭКязыках сетевые библиотеки, поддерживающие протоколы CANopen, ModBus и EtherCAT. Библиотеки опираются на простейший набор аппаратнозависимых низкоуровневых функций, встроенных в систему исполнения. Встроенный инструмент конфигурирования позволяет унифицировать работу в любых сетях, включая нестандартные. Например, при работе в CoDeSys мы можем подключить к ПЛК (master) любые устройства, умеющие работать в CANopen. Их подключение не сложнее, чем подключение модуля ввода/вывода. Кроме того, мы можем превратить наш ПЛК в CANopen slaveустройство, автоматически сгенерировать для него edsфайл.

Если в контроллере есть операционная система, то специальные библиотеки CoDeSys позволяют обращаться к ее функциям напрямую, используя средства взаимодействия (в том числе и сетевые), заложенные в ОС. Дополнительно в CoDeSys реализован интерфейс ARTI, который реализует прямой обмен данными с другими приложениями под WinCE, VxWorks и Linux.

Для стыковки с ПО верхнего уровня и разнородным оборудованием обычно применяется стандарт OPC, бесплатный OPCсервер включен в дистрибутив CoDeSys.

С. Соловьёв. Для обмена данными между приложениями, разработанными с помощью средств стандарта МЭК 611313, могут использоваться стандартные протоколы обмена данными, такие как ModBus, ModBus Plus, Unitelway, Profibus, InterbusS и др., поддерживаемые в конкретной системе. Стандартные протоколы также могут быть использованы и для обмена данными с приложениями, разработанными совершенно другими средствами. При сопряжении ПЛК по стандартным протоколам или подключении к ПЛК устройств со стандартными протоколами в полной мере проявляются достоинства средств разработки на основе стандарта МЭК 611313 – простота и скорость разработки. Однако при необходимости подключения устройств с не поддерживаемыми конкретной системой протоколами могут возникнуть существенные сложности. Например, мы столкнулись с подобной проблемой при подключении счетчиков электрической энергии EuroAlpha и СЭТ4ТМ.02/03 к контроллеру Premium. Протоколы счетчиков для системного ПО контроллера (Unity OS) являются нестандартными, и поэтому мы реализовали их на уровне формирования и приема пакетов определенного формата с их последующей обработкой. В соответствии с принятой идеологией обмен данными со счетчиками производится через программируемый порт Ethernet контроллера Premium с использованием коммуникационных функций протокола TCP/IP, асинхронных по отношению к процессу исполнения программы. При этом в системном ПО контроллера имеется неотключаемый сторожевой таймер, ограничивающий время выполнения одного цикла системы (максимальное значение – 1500 мс). Для решения проблемы были разработаны структура и правила выполнения асинхронных функций, реализованные на основе системы временных и логических соотношений, гарантирующие, что время выполнения одного цикла системы не превысит предельного времени задания сторожевого таймера.

С. Гулько. По сути, стандартного, работающего и удовлетворяющего всех протокола обмена данными нет. Были написаны сотни трудов на эту тему, люди защищали диссертации, но окружающая нас действительность показывает, что подобные решения так и не нашли повсеместного применения. Вы можете лишь добавить поддержку еще одного этого протокола в свое приложение. В случае ISaGRAF это решается достаточно просто – существует масса готовых решений, начиная от ModBus Client/Server через IP или последовательные каналы связи и заканчивая экзотикой типа RMI по Bluetooth. Просто подключите нужный компонент в проект и используйте его. В случае, если такого компонента не существует в природе, можно обратиться к интегратору или дистрибьютору, и они с удовольствием его сделают.

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

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

непосредственно в контроллере, а отображение выполняется “тонким клиентом”. Нарисованные в CoDeSys визуализации можно отображать на любые панели, подключенные к ПЛК или в web, данные при этом аккумулируются в ПЛК. Это дает возможность писать тренды синхронно с реальным изменением данных при любой частоте обработки, не ограничиваемой скоростью и надежностью канала связи с компьютером. В CoDeSys версии 3.0 эта концепция получила развитие. Теперь любые графические элементы можно создавать на МЭКязыках динамически.

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

Среда разработки ISaGRAF позволит вам в online режиме произвести отладку приложения, отслеживая состояние внутренних переменных, отображая ход выполнения программы и состояние устройств ввода/вывода. Важно понимать, что эти функции носят несколько иной характер, нежели отображение информации в SCADAсистеме.

Если вы ищете ошибки, подвергаете систему стресстестированию, – в этом случае встроенные возможности ISaGRAF Workbench просто незаменимы, и никакая SCADA с ним не сравнится. А вот создать красивый пользовательский интерфейс, который можно будет показать заказчику или отдать эксплуатационщикам в Workbench, вам не удастся.

С. Соловьёв. Возможность оперативного отображения данных непосредственно из контроллера в первую очередь определяется возможностями контроллера (VGAвыход, панели оператора, webсервер и т.п.) и только во вторую – поддержкой этой возможности в среде разработки (сложно представить ситуацию, чтобы производитель не обеспечивал программной поддержки своего оборудования!).

“Классический” способ отображения данных непосредственно из контроллера – использование панелей оператора. Так, компания Schneider Electric выпускает широкую гамму панелей оператора Magelis, обеспечивающих визуализацию данных и также управление процессом с помощью клавиш или touchscreen.

Кроме того, компания Schneider Electric в рамках концепции Transparent Factory – “прозрачного” управления производством на основе webтехнологий – одной из первых среди ведущих мировых производителей средств автоматизации разработала интегрированные в ПЛК webсерверы и выбрала в качестве базового протокола своих сетей и полевых шин протокол TCP/IP. Webсервер ПЛК семейств Premium и Quantum поддерживает протоколы DHCP/BOOTP, FTP, HTTP, SNMP, NTP, SMTP, RTPS. Технология Transparent Factory позволяет с помощью webбраузера получить непосредственный доступ к каждому устройству системы автоматизации для мониторинга его состояния, диагностики неисправностей и сбора данных.

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

С. Гулько. У японцев есть такое понятие – кайрецу. Это общее понятие, характеризующее отношения между компаниямипартнерами. Все компании, входящие в кайрецу, выполняют строго оговоренные функции. Да, они могут уметь и больше, но в данном процессе должны выполнять лишь заранее обозначенные роли. Чтобы убедиться в жизненности данной концепции, посмотрите на Японию – их экономика держится на цепочках взаимодействия.

Еще один удачный пример специализации носит название Unixway. Несколько узкоспециализированных утилит способны решить задачу зачастую лучше, чем одна более универсальная. Эта идея прошла проверку временем – Unix уже более 30 лет, и он не собирается сдавать позиции.

Если рассматривать вместо предприятий компоненты систем автоматизации – контроллеры, транспортные узлы, среды программирования, системы сбора и отображения информации и прочие, можно заметить определенное сходство.

До тех пор, пока существует разделение, существует гибкость. Вы можете использовать SoftPLC решение одного производителя, а для отображения использовать SCADAсистему их формальных конкурентов. Здоровая конкуренция всегда была полезна для пользователей.

Разделяя приложения, вы разделяете ответственности. Один участок работы, связанный с программированием контроллеров, выполняет одна команда/отдел, а интерфейс создается уже другими людьми.

Возвращаясь к практике. Сегодня вы используете одну SCADA и одну среду разработки МЭК 61113. В какойто момент у производителя изменилась лицензионная политика, причем не в самую лучшую сторону. В итоге переставший вас удовлетворять компонент может быть практически безболезненно заменен.

С. Соловьёв. Мы не видим необходимости объединения SCADAсистем с языками программирования. Вопервых, хотя ПЛК и SCADAсистемы “делают общее дело”, их функции в системах автоматизации все же относятся к принципиально разным уровням иерархии. Современные SCADAсистемы “умеют” работать с большим количеством контроллеров по различным протоколам, что дает дополнительную свободу выбора поставщика SCADAсистемы. Универсальный механизм соединения ПЛК со SCADAсистемами обеспечивает технология OPC, поддерживаемая всеми ведущими участниками рынка. Благодаря этому, например, с контроллерами компании Schneider Electric можно использовать не только системы Vijeo Look или Monitor Pro, но и другие современные SCADA – PC Vue, Citect, Trace Mode и т.д.

Вовторых, в упрощенном виде системы визуализации процессов, как правило, включены в среду разработки. Так, в системе Unity есть встроенные средства подготовки пользовательских экранов с богатой библиотекой графических элементов.

И. Петров. Благодаря стандарту OPC такой необходимости нет. Кроме того, требования к SCADA и инструментальным системам программирования контроллеров существенно отличаются. Иногда можно сосредоточить всю интеллектуальную обработку на верхнем уровне, а контроллер рассматривать как практически пассивное устройство, в то же время нередко требования совершенно противоположны. Подход 3S достаточно гибок, в CoDeSys реализована идея встраивания простой SCADA в ПЛК (для локальных задач такой универсальный инструмент очень удобен), в то же время бесплатный OPCсервер, включенный в дистрибутив CoDeSys, обеспечивает взаимодействие с мощными SCADA. По моему мнению, иметь набор профессиональных инструментов всегда лучше, чем “дрель с насадками”.

Ведущий. На промышленном контроллере установлена ОС РВ. Какие возможности предоставляет система разработки ПО МЭК 611313 в этом случае пользователям?

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

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

И. Петров. МЭКсреда ориентирована на упрощение программирования технологических задач. В абсолютном большинстве приложений МЭК программиста вообще не интересует тип микропроцессора и ОС. Но благодаря постоянному росту вычислительной мощности ПЛК появляется возможность их применения в нетипичных задачах, например, в системах с числовым программным управлением (ЧПУ). В итоге на один ПЛК возлагаются задачи, выполнявшиеся ранее несколькими десятками микропроцессоров, и возникают проблемы точной синхронизации быстродействующих процессов. В такой ситуации разумно не изобретать велосипед, а использовать в помощь МЭКсистемам готовые средства современных ОС РВ.

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

Система исполнения CoDeSys CSP32F специально спроектирована для работы под ОС РВ. Здесь каждая МЭКзадача выполняется как отдельный поток ОС. МЭКсреда изолирует программиста от тонкостей ОС, повышает переносимость программ, позволяет использовать готовое ПО.

Система исполнения CoDeSys SP RTE имеет собственное ядро жесткого реального времени, функционирующее под Windows XP/NT. Это еще один из новых подходов, позволяющих объединить свойства РВ с широким спектром готового ПО сторонних разработчиков.

С. Соловьёв. Прямой связи между возможностями системы разработки ПО, поддерживающей стандарт МЭК 611313, и наличием на контроллере операционной системы реального времени нет. Основная идея стандарта МЭК 611313 как раз и состоит в том, чтобы абстрагировать разработчика ПО от особенностей программноаппаратной платформы контроллера. И языки стандарта МЭК 611313 эту задачу прекрасно решают. Например, среда Unity может быть использована для разработки ПО для контроллеров семейств Premium и Quantum, имеющих различные аппаратные платформы. Более того, при использовании языков стандарта МЭК 611313 в определенных пределах обеспечивается переносимость ПО из одной среды разработки в другую (естественно, что такая переносимость ограничена использованием нестандартных библиотечных функций и языковых конструкций). Мы на собственном опыте использования систем ISaGRAF, Concept, PL7, Unity убедились, что переход из одной среды в другую не является затруднительным – идеи, положенные в основу различных средств разработки, практически одинаковы.

Для систем автоматизации, которые должны работать в режиме “жесткого” реального времени (например, таких, как система огневых испытаний ЖРД), вопрос выбора программной платформы является нетривиальным: возникает необходимость выбора между готовыми системами на основе МЭК 611313, портированием такой системы в целевую платформу или же разработкой/адаптацией собственной системы. Дать однозначный ответ об адекватности того или иного проектного решения в ситуации абстрактного выбора представляется затруднительным – эффективность решения определяется совокупностью технических, организационных и экономических факторов.

На вопросы ведущего Круглого стола Александра Александровича Егорова, канд. техн. наук, первого заместителя главного редактора журнала, начальника Научно-учебного центра МАИ “Интеллектуальные системы измерений, контроля и управления в промышленности”, отвечают И.В. Петров, С.Ю. Соловьёв и С.В. Гулько. Представим участников обсуждения.

Сергей Соловьёв – канд. техн. наук, доцент кафедры “Приборы и измерительновычислительные комплексы” Московского авиационного института (МАИ), руководитель отдела разработок ООО “Авиатэкс”. Занимается вопросами разработки информационноизмерительных систем и комплексов на основе микроконтроллеров, ПЛК и интеллектуальных измерительных и управляющих устройств, в том числе с использованием средств разработки ISaGRAF, Concept, PL7, Unity. Читает лекции по курсу “Цифровые вычислительные устройства и микропроцессоры приборных комплексов”. Область профессиональных интересов – распределенные автоматизированные системы сбора данных и управления, программноаппаратные платформы и средства разработки ПО.

Основными направлениями деятельности фирмы являются технический консалтинг, разработка, производство и внедрение инструментальных плат, модулей, преобразователей, контроллеров, промышленных компьютеров и других устройств для компьютерных систем на основе PCплатформы в области измерения, контроля, диагностики, управления и автоматизации технологическими процессами в промышленности. С.В. Гулько – ведущий специалист фирмы в области программирования в среде ISaGRAF, автор таких статей, как “Обзор стандарта IEC 61499”, “Эволюция технологии ISaGRAF”, “ISaGRAF – это очень просто!”, “Образовательная программа National Instruments” в журнале “ПИКАД” (Промышленные измерения, контроль, автоматизация, диагностика, г. Киев).

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

С. Соловьев. Режим реального времени предполагает, что существует некое гарантированное время реакции системы на внешние воздействия. В этом смысле любая система автоматизации является системой реального времени; разница заключается лишь в величине времени реакции, которая может измеряться микросекундами для одних объектов (задач) и секундами – для других.

Комплекс технических средств “ПЛК + система исполнения ПО, написанного на языках МЭК”, как правило, обеспечивает время реакции порядка единицдесятков миллисекунд, что вполне достаточно для большинства приложений в промышленной автоматизации, автоматизации зданий и транспорта. При автоматизации экспериментальных исследований новых материалов, физических эффектов, анализа химического состава веществ, процессов испытаний образцов авиационной и космической техники может потребоваться меньшее время реакции, при этом величина этого времени варьируется в достаточно широких пределах: от единиц миллисекунд (например, при автоматизации хроматографических исследований) до единиц и десятков наносекунд (например, при автоматизации исследования характеристик оптоэлектронных элементов). Примером типичной задачи реального времени является автоматизация огневых испытаний ЖРД, которая характеризуется особыми требованиями по надежности и для которой велика “цена” временнóй ошибки – уничтожение двигателя стоимостью более 10 млн. долл., не говоря уже о возможном ущербе жизни людей и окружающей среды. Для эффективного решения такой задачи нужны не столько специальные языки программирования, сколько система исполнения с развитыми средствами приоритетного выполнения задач, межзадачного взаимодействия, быстрого обслуживания процедур обработки прерываний и т.д. Именно по этим причинам в подобных задачах обычно используются ОС РВ в связке с адекватными средствами системного программирования (обычно С/С++).

Эффективность применения языков стандарта МЭК 611313 для задач реального времени, таким образом, определяется не столько их синтаксическими средствами, сколько возможностями платформы – совокупности аппаратных средств и системного ПО (например, ОС РВ).

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

И. Петров. Честно говоря, я не могу вспомнить ни одного проекта на ПЛК, который бы работал не в реальном времени. МЭК языки всегда используются в системах РВ.

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

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

С. Гулько. Для работы с устройствами и протоколами в ISaGRAF применяется протокол IXL. Он определяет строгий интерфейс взаимодействия между внешним миром и исполнительным ядром. Все данные, попадающие в ядро и доступные потом для пользовательских приложений, имеют заранее оговоренный формат. Таким образом, достигается независимость от протоколов передачи данных. Ваше приложение не будет делать различий: каким образом попало это значение в переменную, и какие каналы связи использовались – последовательный порт, Ethernet или USB.

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

И. Петров. Я бы не сказал, что в CoDeSys оно затруднено. Точнее, оно не упрощено в сравнении, например, с языком C. Для SoftPLC на PC есть бесплатные SDK, решающие эту проблему. Изготовители же ПЛК получают систему исполнения в исходных текстах. Поддержка нестандартных протоколов абсолютно открыта, причем обычно они интегрируются со встроенным конфигуратором ПЛК. Обычно изготовитель ПЛК имеет свои исторически сложившиеся нестандартные решения. Благодаря заложенным в CoDeSys механизмам, при переходе от собственной среды разработки к CoDeSys эти решения поддерживаются изготовителем достаточно просто, наравне со стандартными протоколами. Кроме того, в CoDeSys имеются специальные системные библиотеки, например, для работы с RS232, сокетами TCP/IP, файлами и потоками и т.д. Благодаря встроенному компилятору поддержка нужных протоколов реализуется прямо в МЭК языках точно так же, как в С. В CoDeSys пишут даже обработчики аппаратных прерываний. Дополнительно можно писать внешние библиотеки функциональных блоков на С или ассемблере, но на практике это нужно настолько редко, что мы удалили этот раздел из базового описания, чтобы не побуждать пользователей к таким “некрасивым” решениям.

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

Качественное решение задачи подключения устройства с нестандартным протоколом требует большой квалификации и уровня “программистской ответственности”. Специалисты компании “Авиатэкс” имеют богатый опыт подключения устройств со специфическими протоколами к контроллерам различных производителей с использованием разнообразных средств разработки. Например, нами реализованы протоколы счетчиков электрической энергии ЕвроАЛЬФА и СЭТ4ТМ.02/03 в среде разработки Unity Pro XL, причем обмен данными с ними осуществляется через преобразователи интерфейсов RS485 – Ethernet серии NPort компании MOXA. Программирование выполнено с использованием стандартной библиотеки TCP Open Library 2.0 для среды Unity Pro, обеспечивающей работу с сокетами TCP/IP, и утилиты Unity EFB Toolkit, позволяющей описывать пользовательские функции и функциональные блоки на языке С.

Ведущий. Большинство современных промышленных контроллеров поддерживают язык программирования FCL (МЭК 611317) – язык нечеткой логики, например, контроллеры фирм Siemens, Yokogawa, Kontron и др. Как Вы к этому относитесь?

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

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

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

И. Петров. До большинства далеко. Штатно в CoDeSys такой возможности нет, на сегодняшний день мы получали только редкие пожелания общего характера. Поэтому в актуальных планах поддержка МЭК 611317 не стоит. В CoDeSys есть возможность разрабатывать встраиваемые библиотеки, в том числе защищенные лицензией. Если ктолибо ответственно возьмется за разработку и сопровождение библиотеки нечеткой логики или иной специализированной библиотеки для CoDeSys, то мы готовы оказывать в этом не только техническую поддержку, но и предоставить сеть дистрибьюторов 3S во всем мире для их распространения.

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

С. Гулько. Не так давно стандарт сделал большой шаг вперед, получив поддержку объектов. МЭК 61499 является дальнейшим развитием МЭК 61113, полностью наследующим все возможности своего предка, присовокупив к ним парадигму объектноориентированного программирования. ISaGRAF 5 стал первым коммерческим проектом, реализовавшим поддержку нового стандарта. Ситуация чемто напоминает С и С++. Кто знает С, может использовать среду разработки и некоторые возможности нового языка.

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

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

И. Петров. Существующий стандарт не накладывает ограничений на развитие, он лишь требует однозначного выполнения описанных в нем конструкций. Это не означает, что некая система программирования не имеет права поддерживать собственные дополнения. CoDeSys всегда отличался наиболее полной поддержкой стандарта. Например, в стандарте МЭК определен 21 базовый тип данных, соответственно в CoDeSys поддержаны все эти типы, а также указатели. В дополнение к стандартным языкам реализованы упрощенный SFC и функциональные блоки с действиями. Кроме того, в CoDeSys интегрированы компоненты для программирования систем управления движением SoftMotion и специализированные редакторы CAM и CNC.

По мнению опытных МЭК программистов, во всем мире самым злободневным вопросом является поддержка объектноориентированного программирования (ООП). Это очень непростая задача, ее не удалось решить косметическими доработками, и поэтому потребовалась разработка новой среды программирования и системы исполнения. В мае вышел первый релиз CoDeSys 3.0, в котором реализованы идеи ООП 3S. На выставке SPS/IPC/DRIVES пройдут презентации нескольких новых ПЛК с поддержкой CoDeSys 3.0. Можно сказать, что сегодня CoDeSys служит испытательной платформой, на которой обкатываются новые расширения, прежде чем они будут включены в стандарт МЭК.

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

Фактором, стимулирующим развитие конкурирующих технологий, является сближение архитектуры ПЛК с архитектурой ПК, что неизбежно ведет и к сближению технологий разработки ПО. ПЛК с ОС Linux или Windows CE уже давно стали реальностью, а специалистов, для которых C++, Delphi или Java – естественные языки алгоритмического мышления, на рынке труда имеется достаточно.

Выигрывая в частных характеристиках, универсальные средства на сегодняшний день все же проигрывают специализированным по эффективности разработки ПО распределенных систем автоматизации с большим количеством каналов ввода/вывода. Например, в системе Unity Pro есть удобные средства для работы с удаленными устройствами ввода/вывода с использованием большого количества стандартных протоколов, организации обмена данными между контроллерами в рамках единого проекта в единой среде разработки.

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

Ведущий. Необходимы ли, по Вашему мнению, средства визуализации информации из контроллера?

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

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

С. Гулько. Только если это не будет в ущерб всему остальному. Мне кажется, что неплохие системы визуализации можно строить на основе webтехнологий, оснащая контроллер легковесным httpсервером, а сам интерфейс, создавая, предположим, на Java. В такой конфигурации потери производительности будут минимальны, но добавляется определенный фактор удобства. Java appletbased SCADA существуют уже и сейчас, развиваются и через некоторое время вполне могут составить конкуренцию стандартным десктопориентированным решениям.

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

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