Главная Пресс-центр Статьи и публикации На стандартном пути /ISaGRAF-PRO - мощный инструмент разработчика, "PC Week", N 15, 2000

На стандартном пути /ISaGRAF-PRO - мощный инструмент разработчика, "PC Week", N 15, 2000

Любашин А. Н., ЗАО «РТСофт», Москва

Очевидно ли, что введение и использование стандартов не ущемляет интересы большинства, ибо стандарты разрабатываются и принимаются меньшинством?

Очевидно ли, что самое хорошее решение должно строиться на стандартных компонентах?

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

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

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

Стандартные языки программирования

Для мира промышленной автоматизации стандарты являются некими конституционными правилами построения систем. Стандарт — это магическое слово и для того, кто создает ту или иную систему, и для того , может быть, прежде всего), кто за это платит. Организациями по стандартизации выпущены тысячи нормативных документов, и только небольшая их часть действительно имеет историческое значение, влияя на направления дальнейшего развития. Примером такого стандарта является стандарт, определяющий такое понятие, как «Программируемые контроллеры» (МЭК 61131). Этот международный стандарт был опубликован в 1993 году и с тех пор широко используется разработчиками, производителями и пользователями во всем мире.

Рынок средств и систем автоматизации наводнен промышленными контроллерами самых различных изготовителей. Что, казалось бы, может быть общего между изделиями таких известных фирм, как ABB, Allen Bradley, Honeywell, Omron, Moore Products, PEP Modular Computers и многих других. Общим для контроллеров этих фирм выступает «язык общения»: программное обеспечение для них разрабатывается в соответствии со стандартом на языковые конструкции (языки программирования PLC), определенные в части 3 стандарта МЭК 61131. По разным оценкам до 80% PLC-рынка обслуживается программными продуктами, реализующими в той или иной мере этот стандарт. «В вагон IEC вскочили все основные разработчики инструментальных программных систем для промышленной автоматики», — отметил Ян ван Беккум (Jan van Bekkum Ассоциация PLCopen). Список инструментальных программных систем, реализующих стандарт IEC 1131-3, превышает два десятка (Табл.1).

PLCopen и уровни совместимости

Общую координацию деятельности производителей и пользователей «1131»-систем (инструментальные системы, реализующие стандарт МЭК 1131-3 на пять языков программирования контроллеров) осуществляет независимая международная Ассоциация PLCopen. Она занимается популяризацией и информационной поддержкой стандарта МЭК 61131-3 с целью его использования в промышленных системах контроля и управления.

В задачи PLCopen не входит поддержка разработки универсального инструмента программирования для любого типа контроллеров. Основное направление деятельности ассоциации — поддержка некоторого множества языков программирования, использование которых позволит пользователям различных контроллеров обмениваться своими наработками.

Одна из важнейших задач PLCopen — выработка системы и принципов сертификации программных продуктов на предмет их соответствия стандарту МЭК 61131-3. PLCopen определяет три уровня совместимости инструментальных систем (Рис.1):

Базовый уровень (Base Level)
Уровень переносимости функций (Portability Level)
Уровень переносимости приложений (Application Level)

Базовый уровень предполагает, что системы должны быть совместимы на некотором подмножестве базовых компонентов, определяемых стандартом (типы переменных, языковые конструкции и т. п.). Это первый этап, который должны пройти разработчики контроллеров с возможностями подключения к «1131»-системе.

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

Последний, третий уровень определяет степень совместимости и переносимости на уровне завершенных приложений.

Хорошо проработаны и ведутся процедуры сертификации инструментальных «1131»-систем по первым двум уровням (Табл.2). Спецификация по третьему уровню совместимости это мечта любого системного интегратора) пока разрабатывается.

Рис.1: Уровни совместимости «1131» — систем

Рис.2: Программная модель взаимодействия общих компонентов

Вторая часть стандарта посвящена описанию мнемоники стандартных языков программирования контроллеров: SFC, FBD, LD, ST и IL.

Области компетенции «1131»-систем

Основное предназначение этого класса систем заключается в обеспечении пользователя (системного интегратора) стандартным инструментом в виде языков программирования для реализации алгоритмов работы программируемых контроллеров (PLC). Устройства этого класса либо непосредственно, либо через систему датчиков и исполнительных механизмов воздействуют на технологический процесс (Рис.3). Особенностью таких устройств является прежде всего то, что их огромное множество, и именно поэтому так необходимо было появление совместимых между собой инструментальных средств.

На уровне цеха представлены вычислительные комплексы на базе промышленных компьютеров, или интеллектуальных контроллеров. В распределенной системе на их «плечи» могут быть возложены задачи коммуникационных серверов, сетевых шлюзов, серверов баз данных «реального времени», регистраторов событий, оперативного регулирования и т.д. Отдельные «1131»-системы, в полной мере используя возможности операционных систем конкретных аппаратных платформ, действительно позволяют решить эти задачи с помощью встроенных средств или за счет функций расширения.

В последние 3-4 года реализации стандарта МЭК61131-3 в виде дополнительных компонентов появились и в ряде SCADA-систем (Factory Suite/InControl, FIX/Paradym-31, WinCC/WinAC, TraceMode и др.). Насколько оправдана такая интеграция для систем, предназначенных в первую очередь для организации человеко-машинного интерфейса, не очень понятно. Но сам факт говорит о том, что все разработчики программных инструментальных средств для задач автоматизации однозначно осознали важность самого стандарта и его безусловную перспективность.

Рис.3: Область применения «1131» — систем

Языковое многообразие

Стандарт МЭК-1131 в целом посвящен программируемым логическим контроллерам. Но наиболее известна и популярна часть 3 этого стандарта, определяющая мнемонику языков программирования.

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

SFC

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

Язык последовательных функциональных схем (Sequential Function Charts, или Grafcet) позволяет формулировать логику программы на основе чередующихся процедурных шагов и транзакций (условных переходов), а также описывать последовательно-параллельные задачи в понятной и наглядной форме.

Строго говоря, SFC не является языком программирования. Это средство проектирования прикладного программного обеспечения, которое всегда является комплексом большого числа программных единиц: программ, функциональных блоков, функций. Обеспечение параллельности выполнения программ, установление и контроль состояния порожденных процессов, обеспечение синхронизации по приему и обработке данных, описание однозначно понимаемых и заказчиком, и исполнителем состояний автоматизируемого процесса — все это возможно при использовании «языка программирования» SFC.

Основные достоинства SFC можно определить следующим образом.

Высокая выразительность. Язык SFC имеет те же возможности, что и диаграммы состояний, и является наиболее подходящим средством для описания динамических моделей.

Графическое представление. Благодаря графической мнемонике SFC максимально прост в использовании и изучении. Вместе с тем, он является наглядным средством представления логики на разных уровнях детализации.


Предварительное проектирование ПО. Использование языка SFC на ранних этапах проектирования прикладного ПО позволяет снять многочисленные непонимания между заказчиком, проектировщиком ПО и программистом.

FBD

Язык функциональных блоков (Function Block Diagrams) позволяет создать программную единицу практически любой сложности на основе стандартных кирпичиков (арифметические, тригонометрические, логические блоки, PID-регуляторы, блоки, описывающие некоторые законы управления, мультиплексоры и т.д.). Это языковое средство использует технологию инкапсуляции алгоритмов обработки данных и законов регулирования. Все программирование сводится к «склеиванию» готовых компонентов. В результате получается максимально наглядная и хорошо контролируемая программная единица.

LD

Язык релейных диаграмм, или релейной логики (Ladder Diagrams) применяется для описания логических выражений различного уровня сложности и использует в качестве базовых элементов программирования графические элементы «контакты» (contacts) и «катушки» (coils), связанные с входными и выходными каналами соответственно.

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

ST

Язык структурированного текста (Structured Text) относится к классу текстовых языков высокого уровня. Этот язык уходит корнями в такие известные языки программирования, как Ada, Pascal и C. На его основе можно создавать гибкие процедуры обработки данных. Язык структурированного текста является основным для программирования последовательных шагов и транзакций языка SFC. Кроме этого, он имеет «выходы» во все остальные языки, что делает его универсальным в применении разными категориями пользователей.

IL

В «достандартные» времена (до 1993 года) практически каждый программируемый контроллер сопровождался своим Ассемблером. Выросли целые поколения программистов, ориентированных на определенные кланы микропроцессоров. Освоение новой техники сталкивалось с проблемой освоения очередного языка программирования под новый кристалл. Отдельные мнемонические конструкции Ассемблеров были похожи, но о каком-либо стандарте не было и речи.

Появление Языка инструкций (Instruction List) в наборе стандартных языков — это унификация интерфейса языка программирования низкого уровня, неориентированного на какую-либо микропроцессорную архитектуру. У языка IL есть очень важное качество: на его основе можно создавать оптимальные по быстродействию программные единицы.

В многих инструментальных «1131»-системах существует возможность «смешивать» программы/процедуры, написанные на разных языках, а также вставлять кодовые последовательности из одного языка в коды, написанные на другом языке. Любое функциональное расширение возможно за счет поддержки СИ-интерфейса, которая считается сегодня обязательной.

ISaGRAF PRO как пример «1131»-системы

На российском рынке «1131»-систем представлено несколько продуктов, но наибольшую известность имеет CASE-система ISaGRAF (CJ International, Франция). В российских проектах эта система используется уже более 7 лет. Под управлением ISaGRAF работают десятки систем автоматизации. История ISaGRAF началась вместе с появлением языка программирования контроллеров GRAFCET (конец 70-х годов), получившего статус французского национального стандарта. Впоследствии этот язык послужил основой для разработки в рамках МЭК единого стандарта на языки программирования контроллеров (МЭК 61131-3).

Рис.4: Методология разработки прикладного ПО

ISaGRAF, а точнее, его модификация ISaGRAF PRO полностью соответствует программной модели взаимодействия компонентов, определенной стандартом МЭК 61131-3, и позволяет пользователю работать в терминах распределенной системы с распределенными ресурсами. А это уже совершенно другой подход к передаче и обработке данных, которые представляют собой теперь общую распределенную базу данных. Появляется схема, когда есть единственная система разработки, а все программируемые устройства представляются как набор виртуальных машин с общей распределенной базой данных (рис.4). В предельном случае все виртуальные машины могут работать в одном физическом микрокомпьютере (встроенной системе).

ISaGRAF PRO изнутри

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

Ядро (виртуальная машина) выполняет прикладной программный код циклически, проходя при этом следующие этапы:

Чтение входных сигналов устройств;
Обработка входных сигналов и проверка на границы;
Выполнение программных единиц;
Формирование значений выходных сигналов;
Обновление состояния выходных каналов устройств.

Ядро по отношению к процессу работает в синхронном режиме: «все, что предписано к выполнению — выполнится». При этом общая продолжительность цикла «виртуальной машины» зависит от сложности программного кода, числа и размерности программ, общего числа переменных и числа каналов ввода/вывода. Когда заданное значение времени цикла работы виртуальной машины превосходит ее реальные временные потребности это нормальный случай), то появляется этап ожидания перехода к следующему циклу. В это время виртуальная машина переходит в состояние ожидания следующего цикла и предоставляет свободные вычислительные ресурсы для выполнения других задач.

Механизм связывания ресурсов

Ресурсы ISaGRAF PRO могут обмениваться данными с использованием механизма связывания ресурсов (Resource Binding). Он задаёт модель взаимодействия как между ресурсами одной целевой машины (контроллера), так и между ресурсами нескольких целевых машин, и определяет принимаемые и обрабатываемые данные, коммуникационные взаимодействия и каналы связи между переменными, каждая из которых описана в рамках своего ресурса. Существуют понятия «переменная источника» ( «producer variable») и «переменная приемника» ( «consumer variable») (рис.5).

Рис.5: Механиз связывания ресурсов

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

Основные модули системы исполнения

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

Управление PLC-цикла осуществляется так называемой виртуальной машиной, или ядром ISaGRAF (ISaVM).

Коммуникационные функции обеспечиваются модулем диспетчера запросов к ядру и модулем связывания ресурсов между ядрами.

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

В общем виде компонентный состав системы исполнения (ядра) ISaGRAF PRO представлен на рисунке 6.

Рис.6: Компоненты системы исполнения (ISaGRAF-target)

Стандарт как источник развития

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

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

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

Поправки и изменения были рассмотрены в первой половине 1998 года специальной международной комиссией по IEC 1131-3. Как разработка стандарт всесторонне исследовался до марта 1999 года. Сегодня он готовится к выпуску в качестве нового издания.

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

Очевидно ли, что самое хорошее решение должно строиться на стандартных компонентах? В жизни так не бывает — в любой конкретный момент всегда существует решение, не охваченное какими-либо спецификациями. Важно, чтобы закладываемые решения были «современными» и соответствовали основным направлениям развития.

На последний вопрос можно ответить и «да», и «нет». Любой стандарт — это, прежде всего констатация определенного уровня технического развития. Безусловно, стандарт всегда отстает от жизни, но если не закрепиться на взятых рубежах, то и движение вперед окажется невозможным. Шаг за шагом, ступенька за ступенькой.

19.04.2014