На стандартном пути

На “стандартном” пути

Раз ступенька, два ступенька - будет лесенка+

Известная детская песня

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

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

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

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

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

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

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

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

Таблица 1. Примеры инструментальных систем, реализующих МЭК 61131-3

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

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

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

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

Рис. 1. Уровни совместимости 1131-систем

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

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

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

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

Таблица 2. Сертифицированные системы

Компоненты стандарта и терминология

Стандарт МЭК 61131-3, условно говоря, описывает два компонента: так называемые общие элементы и собственно языки программирования.

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

Конфигурация (Configuration) - это аппаратная платформа, на которой определены один или более ресурсов.

Ресурс (Resource) - интегрированный компонент, выполняемый полностью в едином цикле работы контроллера и состоящий из программных единиц, описателей обрабатываемых данных и описателей коммуникационных взаимодействий.

Программная единица (Program Organization Unit, POU) - набор программных инструкций, объединенных в программы, функции и функциональные блоки.

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

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

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

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

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

Рис. 3. Области применения 1131-систем

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

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

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

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

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

1. SFC. Теория конечных автоматов, используемая для формализации состояний сложных процессов управления, опирается на различные графические модели описания состояний. Одну из самых известных моделей предложил К. Петри, она получила название “Сетей Петри”, или диаграммы состояний, и послужила теоретической основой языка последовательных функциональных схем (Sequential Function Charts, или Grafcet, SFC), наиболее важного из всего семейства стандартных языков.

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

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

К основным достоинствам SFC относятся:

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

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

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

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

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

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

4. ST. Язык структурированного текста (Structured Text) относится к классу текстовых языков высокого уровня. Он уходит корнями в такие известные языки программирования, как Ада, Паскаль и Си. На его основе можно создавать гибкие процедуры обработки данных. Язык структурированного текста является основным для программирования последовательных шагов и транзакций языка SFC. Кроме того, он имеет “выходы” во все остальные языки, что делает его универсальным в применении разными категориями пользователей.

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

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

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

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

На российском рынке 1131-систем представлено несколько продуктов, но наибольшую известность имеет CASE-система ISaGRAF фирмы CJ International (Франция). В российских проектах эта система используется уже более семи лет. Под управлением ISaGRAF работают десятки систем автоматизации.

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

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

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

ISaGRAF PRO изнутри

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

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

1. Чтение входных сигналов устройств.

2. Обработка входных сигналов и проверка на границы.

3. Выполнение программных единиц.

4. Формирование значений выходных сигналов.

5. Обновление состояния выходных каналов устройств.

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

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

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

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

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

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

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

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

- коммуникационные функции выполняет модуль диспетчера запросов к ядру и модуль связывания ресурсов между ядрами;

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

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

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

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

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

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

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

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

И в заключение попробуем ответить на поставленные в начале статьи вопросы.

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

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

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

С автором статьи можно связаться по телефону: (095) 742-6828 или по E-mail: lubashin@rtsoft.msk.ru.