С. Соловьёв. Мы не видим необходимости объединения 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, портированием такой системы в целевую платформу или же разработкой/адаптацией собственной системы. Дать однозначный ответ об адекватности того или иного проектного решения в ситуации абстрактного выбора представляется затруднительным – эффективность решения определяется совокупностью технических, организационных и экономических факторов.

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

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

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

Сергей Гулько работает в компании “ХОЛИТ Дэйта Системс” (г. Киев), образованной в 1991 г. группой научных сотрудников Киевского политехнического института – специалистов в области измерительной и микропроцессорной техникой.

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

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

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

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

Сергей Гулько работает в компании “ХОЛИТ Дэйта Системс” (г. Киев), образованной в 1991 г. группой научных сотрудников Киевского политехнического института – специалистов в области измерительной и микропроцессорной техникой.

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