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