MasterSCADA

Программное обеспечение

В настоящее время наиболее распространенными отечественными универсальными SCADA являются MasterSCADA (ИнСАТ, www.masterscada.ru), Trace Mode (AdAstrA Research Group, Ltd, www.adastra.ru), Круг-2000 (НПФ "КРУГ", www.krug2000.ru) и САРГОН (НВТ-Автоматика, nvt.msk.ru). Все системы удовлетворяют основным требованиям к SCADA, описанным выше, и успешно конкурируют с зарубежными аналогами. Ниже мы рассмотрим отличительные особенности двух наиболее известных пакетов: MasterSCADA и Trace Mode.

Система MasterSCADA фирмы ИнСАТ предназначена для создания полномасштабных систем автоматизации в различных отраслях промышленности. Основной ее особенностью является объектный подход, использованный на уровне описания системы при ее настройке на конкретный объект автоматизации. Например, цех, участок, технологический блок и физическое устройство при создании проекта с помощью MasterSCADA рассматриваются как отдельные объекты. Для каждого объекта создается свое описание на технологическом языке программирования. Описание включает в себя свойства объекта и документы объекта. Свойствами могут быть период опроса, способ линеаризации датчика, диапазон входных сигналов. Документами объекта являются его изображение, мнемосхема, график изменения переменных и т.п. Любой документ в системе относится к некоторому объекту. Такой подход позволяет легко размножать один раз созданные объекты, что повышает скорость настройки SCADA на задачу пользователя.

К признакам объектного подхода относится также возможность наследования всех настроек от "родительских" объектов. Это означает, что в MasterSCADA нет необходимости вводить настройки для каждого типа объектов "с нуля". Можно использовать наследование этих настроек от родительского объекта, изменив в них только те параметры, которые отличают родителя от потомка.

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

Как мы уже отметили выше, в MasterSCADA, как впрочем и во всех без исключения SCADA (в отличие от HMI) системах, параметр и сообщения можно архивировать. Однако только MasterSCADA обладает огромной гибкостью в настройке этого процесса, места и формата хранения и т.п. В рамках темы данной статьи отметим только, что мы можем организовать периодическое архивирование или архивирование по изменению значения (с учетом зоны нечувствительности), линейное или послойное архивирование (например, мгновенные значения температуры воздуха в течение суток, среднечасовые в течение месяца, среднесуточные в течение срока наблюдения). Переменные MasterSCADA автоматически начинают архивироваться, если они используются в приложениях, которым нужны архивы тренды, функции доступа к архиву и т.п. Наряду с этим признак архивирования можно задать и "вручную". Для этого необходимо на странице свойств параметра "Общие" установить флаг "Архивировать". Если большинство переменных объекта должны попадать в архив, то в этом случае проще воспользоваться возможностью наследования настроек от родительского к дочернему элементу, и соответствующий флаг установить на уровне объекта, которому принадлежит данный параметр.

MasterSCADA может опрашивать внешние архивы как на уровне контроллера, так и напрямую со стороны диспетчерской. В первом случае используются драйверы контроллера, которые опрашивают архив счетчика и записывают его во внутренний архив контроллера с «родными» метками времени. Разумеется, если счетчик это позволяет, время в нем синхронизируется с временем MasterSCADA. «Подъем» архивов контроллера производится во все подключенные к нему серверы ввода данных MasterSCADA, а при необходимости и в OPC-сервер MasterPLC OPC, обеспечивающий передачу данных во внешние системы, например в местный «Энергосбыт».

Опрос архивов счетчиков со стороны диспетчерской производится с помощью OPC HDA cерверов, предназначенных для чтения архивов. Наиболее «продвинутые» производители счетчиков такими серверами уже обзавелись. «Отстающие» предлагают, как правило, использовать OPC DA сервер, который, по сути, рассчитан только на передачу мгновенных значений. Передача через этот сервер архивов счетчика (например, каждое среднечасовое значение в виде отдельной переменной) приводит к расходу переменных из числа лицензируемых, а также к необходимости трудоемкой обработки этих значений в проекте с целью их записи в архив SCADA.

Архивирование и документирование. Система архивов MasterSCADA. Работа с архивами проекта. Просмотр архивных данных. Создание отчетов Экспорт данных из архивов MasterSCADA в приложения WINDOWS. Обмен данными с приложениями WINDOWS.

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

1. Ведение всех или части архивов во внешнем SQL-сервере (в собственной структуре базы данных);

2. Экспорт всех или части архивов во внешний SQL-сервер (в собственную структуру базы данных);

3. Двусторонний обмен данными с базой данных во внешнем SQL-сервере (произвольная структура базы данных);

4. Экспорт всех или части архивов в Access (mdb-файлы);

5. HDA-сервер, который может опрашиваться внешними клиентами;

6. Экспорт данных в 1С (по запросу).

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

1. С помощью формул (в контроллере или компьютере диспетчерской);

2. С помощью схем функциональных блоков;

3. С помощью специализированных блоков типа «Подготовка периодического отчета», «Вычисление расхода пара» и т.п.;

4. С помощью вычислений в модуле отчета;

5. С использованием внешних средств — например, внутри SQL-сервера.

Поскольку MasterSCADA имеет возможность оперировать переменными типа «время», а также использовать в формулах извлеченные из архивов значения, такие вычисления особых затруднений не вызывают.

Собственно сами отчеты в MasterSCADA можно делать двумя способами.

Простые одностраничные отчеты — с использованием Microsoft Excel (переменные или специальные функциональные блоки перетаскиваются в поле листа Excel, которое открывается внутри среды MasterSCADA).

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

Для удобства просмотра отчетов на экране есть возможность создавать отчеты с навигацией — оглавлением, закладками, гиперссылками. Созданный в MasterReport отчет может быть отредактирован оператором (при наличии прав доступа) перед печатью или сохранением. Перед формированием отчета оператор может ввести дополнительные данные в форму запроса, подготовленную разработчиком проекта. Отчеты могут быть автоматически сохранены практически в любом формате, включая защищенный PDF, Excel, Word, HTML, XML и др. Готовые отчеты могут быть отправлены по заранее определенному списку Email-адресов.

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

Структура монитора реального времени (МРВ) и особенности запуска в реальном времени. Приоритеты выполнения задач. Временные характеристики системы и ее настройка.

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

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

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

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

Каждая «задача», представляющая собой отдельную подпрограмму, выполняется циклически. При этом надо придерживаться следующих правил: 1. Подпрограммы не должны содержать циклов ожидания в стиле while (TRUE) {

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

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

Можно отметить следующие преимущества циклического алгоритма.

1. Простота использования и прозрачность для понимания.

2. Если исключить из рассмотрения прерывания, система полностью детерминирована. Задачи всегда вызываются в одной и той же последовательности, что позволяет достаточно просто произвести анализ «наихудшего случая» и вычислить максимальную задержку.

3. Минимальные размеры кода и данных. Кроме того, в отличие от алгоритмов с вытеснением, для всех задач необходим только один стек.

4. Отсутствуют ошибки, обусловленные «гонками».

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

Перейдем теперь к другому широко используемому алгоритму планирования. Речь пойдет о режиме разделения времени. Существуют различные реализации в рамках этого алгоритма, и некоторые западные специалисты даже различают такие в общем-то идентичные для нас понятия, как time-slicing и time-sharing. Как правило, алгоритм реализуется следующим образом: каждой задаче отводится определенное количество квантов времени (обычно кратно 1 мс), в течение которых задача может монопольно занимать процессорное время. После того как заданный интервал времени истекает, управление передается следующей готовой к выполнению задаче, имеющей наивысший приоритет. Та, в свою очередь, выполняется в течение отведенного для нее промежутка времени, после чего все повторяется в стиле round robin. Легко заметить, что такой алгоритм работы может привести к определенным проблемам. Представим, что в системе работают 7 задач, 3 из которых имеют высокий приоритет, а 4 - низкий. Низкоприоритетные задачи могут никогда не получить управление, так как три высокоприоритетные задачи будут делить все процессорное время между собой. Единственную возможность для низкоприоритетных задач получить управление предоставляет ситуация, когда все высокоприоритетные задачи находятся в блокированном состоянии.

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

Кооперативная многозадачность - это еще один алгоритм переключения задач, с которым широкие массы компьютерной общественности знакомы по операционной системе Windows 3.x. Задача, получившая управление, выполняется до тех пор, пока она сама по своей инициативе не передаст управление другой задаче. По сути это продолжение идеологии round robin, и нет нужды объяснять, почему алгоритм кооперативной многозадачности в чистом виде мало применяется в системах реального времени.

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

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

В общем случае алгоритмы планирования должны соответствовать критериям оптимальности функционирования системы. Однако, если для систем «жесткого» реального времени такой критерий очевиден-. «ВСЕГДА и ВСЁ делать вовремя», то для систем «мягкого» реального времени это может быть, например, минимальное «максимальное запаздывание» или средневзвешенная своевременность завершения операций. В зависимости от критериев оптимальности могут применяться алгоритмы планирования задач, отличные от рассмотренных. Например, может оказаться, что планировщик должен анализировать момент выдачи критичных по времени управляющих воздействий и запускать на выполнение ту задачу, которая отвечает за ближайшие из них (алгоритм earliest deadline first, EDF).

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

Не стоит особо увлекаться приоритетами. Если система нормально работает, когда все задачи имеют одинаковый приоритет, то и слава Богу. Если нет, то можно присвоить высокий приоритет «критической» задаче, и низкий приоритет всем остальным. Если у вас больше одной «критической» задачи, при недостаточном быстродействии системы имеет смысл рассмотреть многопроцессорную конфигурацию или, отказавшись от ПО РВ, перейти к простому циклическому алгоритму.

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

Дата добавления: 2014-01-20