Проектирование систем автоматизации. Курс лекций

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

Различают системы реального времени двух типов – системы же- сткого реального времени и системы мягкого реального времени.

Системы жесткого реального времени не допускают никаких за- держек реакции системы ни при каких условиях, так как:

•результаты могут оказаться бесполезными в случае опоздания;

•может произойти катастрофа в случае задержки реакции;

•стоимость опоздания может оказаться бесконечно велика. Примеры систем жесткого реального времени – бортовые системы

управления, системы противоававарийной защиты.

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

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

Также СРВ можно разделить на системы специализированные и универсальные.

1.Специализированной СРВ называется система, где конкрет- ные временные требования априори определены. Такая система должна быть специально спроектирована для удовлетворения этих требований.

2.Универсальная СРВ должна уметь выполнять произвольные (заранее не определенные) временные задачи без применения специ- альной техники. Разработка таких систем, безусловно, является са- мой сложной задачей, хотя обычно, требования, предъявляемые к таким системам, мягче, чем требования для специализированных систем.

41

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

Любая система реального масштаба времени может быть описана как состоящая из трех основных подсистем (рис. 2.1).

Рис. 2.1. Пример организации системы реального времени

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

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

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

42

Аппаратную часть СРВ, на которой исполняется ОСРВ и при- кладное программное обеспечение, принято называть целевой плат- формой. В связи с возможной специфичностью целевой платформы, особенно в случае встраиваемых систем, разработка прикладных программ может проводиться на другой аппаратуре и даже в некото- рых случаях на другой ОС, а отладка конечных программ произво- дится либо удаленно с помощью специальных инструментальных средств, либо с помощью эмуляции работы целевой ОС. Например, программирование большинства используемых в промышленности программируемых логических контроллеров осуществляется при помощи инструментального ПО, работающего под управлением Microsoft Windows, а контроллеры функционируют под управлением коммерческой ОСРВ или ОС, разработанной изготовителем кон- троллера. В контроллерах RX3i, RX7i (семейство PAC) производства

GE Intelligent Platforms (до 2010 г. GE Fanuc) используется коммер- ческая ОСРВ VxWorks корпорации WindRiver Systems (США), в бо-

лее ранних продуктах того же изготовителя применяется ОСРВ соб- ственной разработки.

Наличие в ОСРВ механизмов многозадачности является в настоя- щее время обязательным. Многозадачность реализуется и в ОС обще- го назначения. Но для СРВ к реализации механизмов многозадачно- сти предъявляется ряд дополнительных по сравнению с системами общего назначения требований. Эти требования обусловлены необхо- димостью обеспечить ключевое свойство СРВ – предсказуемость.

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

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

43

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

Поток может находиться в одном из следующих состояний:

•активный поток – поток, выполняемый системой в данный мо-

мент;

•поток в состоянии готовности – поток, который может выпол- няться и ждет своей очереди;

•блокированный поток – поток, который не может выполняться по некоторым причинам (например, ожидание события или освобож- дения нужного ресурса).

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

случае FIFO (First In First Out) – Первый Вошел Первый Вышел – первой выполняется задача, первой вошедшая в очередь, она выпол- няется до завершения или до блокировки в ожидании освобождения некоторого ресурса или события. Затем управление передается сле-

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

При наличии в системе потоков с разными приоритетами для тех потоков, чьи приоритеты совпадают, используется один из вышеука-

44

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

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

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

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

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

Для оценки диспетчерируемости СРВ используется математиче- ский аппарат, называемый «Частотно-монотонный анализ». Его эф- фективность привела к тому, что он был принят в качестве стандарта Министерством обороны США, NASA, Boeing и рядом других органи- заций. Возможность применения частотно-монотонного анализа огра- ничена рядом условий, главным из которых является диспетчеризация потоков методом вытесняющей приоритетной многозадачности.

45

3.РАБОТА С ДАННЫМИ

3.1.SCADA-системы и построение АРМ оператора

Существенной частью функций АС является получение, обработка, хранение и отображение данных о ходе технологического процесса. Центральное место при этом отводится автоматизированным рабочим местам (АРМ) оператора, реализуемым на компьютерах с использова- нием выпускаемого серийно ПО SCADA. SCADA – сокращение от

Supervisory Control And Data Acquisition – это система диспетчерского управления и сбора данных. В настоящее время у данного термина есть два значения – собственно программно-аппаратный комплекс сбора и обработки данных, отличающийся от автоматизированной системы управления тем, что он ориентирован на сбор, передачу, об- работку и предоставление диспетчеру данных, а не на автоматизиро- ванное управление и регулирование. Второе значение – серийно вы- пускаемое («коробочное») ПО, на основе которого реализуются АРМ операторов и при необходимости серверы АСУТП. Две SCADA- системы – InTouch и Sitect – подробно рассмотрены в книге [3.1].

Приложение, реализованное в SCADA-среде, должно осуществ- лять следующие функции:

•сбор данных с управляющих контроллеров;

•отображение параметров процесса и состояния оборудования на мнемосхеме;

•отображение значений параметров на графиках (трендах);

•ввод команд оператора и уставок регуляторов;

•выдачу на экран и печать аварийной и предупредительной сиг- нализации;

•запись параметров и событий в архив с возможностью после- дующего доступа к ним для анализа;

•подготовку и печать сводок и отчетов;

•передачу данных на более высокие уровни управления – MES и

ERP1.

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

–––––––––

1 MES – Manufacturing Execution System – система управления производством, ERP – Enterprise Resource Planning – Система планирования ресурсов предприятия.

46

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

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

Изготовители SCADA-пакетов включают в их состав драйверы для наиболее распространенных контроллеров, поэтому собственно про- токол обмена при реализации АРМ оператора программировать не надо, достаточно сконфигурировать уже реализованный. Подавляю- щее большинство SCADA-программ являются OPC-клиентами, т.е. существует возможность обеспечить их связь с любым контроллером,

имеющим OPC-сервер. OPC – OLE for Process Control – это семейство программных технологий, обеспечивающих унифицированный интерфейс построения систем управления. OPC-сервер является при- ложением, исполняемым на том же компьютере, что и SCADA- приложение (OPC-клиент). Возможно функционирование OPC- сервера и OPC-клиента на разных компьютерах, объединенных в сеть, такой вариант на практике встречается крайне редко. Интерфейс ме- жду OPC-клиентом и OPC-сервером специфицирован международной некоммерческой организацией OPC Foundation, созданной в 1994 году ведущими производителями средств промышленной автоматики. Все индивидуальные особенности реализации канала обмена, присущие конкретной модели оборудования, учитываются при написании для нее OPC-сервера. Написанием OPC-серверов занимаются как изгото- вители контроллеров, так и независимые фирмы.

Мнемосхема для АРМ оператора реализуется при помощи встро- енного в SCADA- пакет графического редактора. Предусматривается импорт растровых и векторных изображений распространенных фор- матов. Отображение параметров, формы для ввода уставок, анимация и т.п. реализуются в диалоговом режиме без написания программного кода. Предусмотрена возможность написания скриптов на языке Visual Basic или его аналоге. Мнемосхема должна быть информативной

47

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

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

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

Алармы конфигурируются в проекте в привязке к переменным (тэгам). Для дискретной переменной аларм может быть назначен на ее значение «0» или «1», а также на переход из одного состояния в другое. Для аналоговой переменной могут быть назначены алармы на превышение верхней границы предупредительной сигнализации (high), превышение верхней границы аварийной сигнализации (high high), аналогично выход за нижнюю границу предупредительной (low) и аварийной (low low) сигнализации, отклонение от нормы свыше заданного (deviation), недопустимый темп изменения (ROC – Rate Of Change). Чтобы избежать частого появления и исчезновения

48

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

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

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

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

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

49

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

Подготовка и печать отчетов требуется для предоставления на бумаге сжатых сводок о ходе процесса за заданный период (смену, сутки, месяц и т.п.). Это может быть информация о количестве про- изведенной продукции, средних и пиковых значениях наиболее акту- альных параметров технологического процесса, срабатывании ава- рийной и предупредительной сигнализации. Несмотря на необходи- мость реализовать функцию подготовки отчетов и сводок в боль- шинстве используемых в промышленности АС, в базовой комплек- тации SCADA-пакетов отсутствуют соответствующие средства. Для подготовки сводок и отчетов приходится приобретать расширения к базовой комплектации SCADA, специализированные программные продукты третьих фирм, писать громоздкие скрипты на встроенных в

SCADA языках.

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

Рис. 3.1. Иерархия уровней управления

50