Category Archives: SCADA системы

Связь с аппаратурой ввода-вывода Trace Mode

.

Trace Mode поддерживает обмен данными с разными контроллерами. Для PC-контролеров обмен реализуется по собственным протоколам Trace Mode при использовании в них микроМРВ, а для остальных — по их протоколам. Часть этих протоколов встроена в исполнительные модули Trace Mode, а часть поставляется опционально в виде динамически загружаемых библиотек.

Для обмена по встроенным протоколам предусмотрены следующие подтипы каналов:

  • СВЯЗЬ;
  • DCS;
  • MODBUS.

Канал подтипа «СВЯЗЬ» используется мониторами Trace Mode для обмена между собой. Связь с модулями распределенного УСО типа LAGOON, ROBO, ADAM-4000 и ADAM-5000/485, NuDAM-6000, I-7000, RIO-2000 и подобными осуществляется каналами подтипа DCS. Дополнение к подтипу этого канала определяет запрашиваемые или передаваемые данные.

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

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

Каналы подтипа «КОНТР_1» предназначены для обмена данными с контроллерами по последовательному интерфейсу, а «КОНТР_2» используются, когда носитель протокола явно не определен и требуется описать его внешними средствами. Поэтому в первом случае для обмена с контроллером необходим один драйвер, описывающий протокол, а во втором — два. Первый драйвер используется для описания протокола, а второй — для носителя.

Для создания драйвера обмена данными по стандартным последовательным интерфейсам (RS-232, RS-485) в Trace Mode реализована поддержка работы с последовательными портами. В этом случае драйвер только формирует сообщения для посылки по последовательным портам и расшифровывает ответ. Обмен данными с драйверами, использующими встроенную поддержку обмена по последовательным портам, осуществляется с помощью каналов подтипа «КОНТР_1». Если Trace Modeне поддерживает устройства, с которыми необходим обмен данными, то необходимо разработать драйвер.

 

Система паролей и прав доступа Trace Mode

Trace Mode контролирует права до 4 096 пользователей с индивидуальными паролями в рамках одного проекта. Пользователи, имеющие доступ к системе, могут быть разбиты на восемь групп. Максимальное число пользователей – 32 000.

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

При запуске графической консоли МРВ, SUPERVISOR или NetLink Light на экран выводится диалог регистрации пользователя. В этом диалоге надо указать имя и ввести пароль. При этом осуществляется вход в систему с правами, определенными для указанного пользователя.

Если список пользователей пуст, то при нажатии ЛК на кнопку «Вход» без ввода имени и пароля консоль подключается к серверу математической обработки с наивысшими правами. Такой запуск МРВ удобно использовать на стадии разработки проекта.

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

Диалог «Пользователи и права доступа» содержит список пользователей и кнопки его редактирования «Добавить», «Удалить». Чтобы добавить нового пользователя, надо в списке выбрать группу и нажать ЛК на кнопку «Добавить». При этом в список выделенной группы добавляется новый пользователь, имя которого образуется следующим образом: U<число>. После того как пользователь добавлен в список, следует ввести его реальное имя, задать пароль и настроить его права. Пароль не может быть короче четырех символов.

Для ввода имени и текста пароля предназначены специальные поля в диалоге «Пользователи и права доступа».

Для удаления любого пользователя из списка надо выделить  его имя и нажать ЛК на кнопку «Удалить__________».

Права пользователя задаются установкой соответствующих флагов. Существует три раздела для установки прав доступа:

«Права (замрет действий)»; «Права (графика)»; «Запрет на изменение».

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

Установка флагов в разделе «Права (запрет действий)» соответствует следующим ограничениям прав:

одновременный вход — запрет на одновременный вход с разных компьютеров под данным именем;

отключение в 24 часа — отключение пользователя при смене суток;

квитирование — запрет на квитирование сообщений отчета тревог;

квитирование (синх) — запрет на квитирование тех сообщений отчета тревог, время которых отличается от текущего на величину, превышающую 10 минут;

будни — запрет на вход в систему по будням; выходные — запрет на вход в систему по выходным дням; бит 1, бит 2 – запрет на вход в систему, если установленные флаги не полностью соответствуют установленным битам канала подтипа «СИСТЕМНЫЙ» с дополнением «Права».

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

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

Управление доступно при совпадении хотя бы одного из флагов доступа пользователя с соответствующим флагом формы отображения.

При наличии любого флага в разделе «Запрет на изменение» пользователь, подключающийся с соответствующего клиентского модуля, лишается прав на управление значениями каналов.

Для регистрации пользователей в реальном времени надо войти в диалог «Регистрация оператора». Для этого надо нажать клавиши «CTRL»+«ALT»+«SHIFT»+«P».

Далее регистрация выполняется так же, как и при запуске МРВ: надо ввести имя и пароль. Если введен неверный пароль или имя пользователя, то смены прав не происходит и пользователь не регистрируется.

Если МРВ ведет отчет тревог, то при каждой регистрации пользователя в этот архив заносится строка, в поле «Сообщение» которой будет записан следующий текст:

LOGIN <имя><номер>, где <имя> — имя пользователя;

<номер> — числовой идентификатор пользователя.

Далее во все строки отчета тревог, запись которых инициирована действиями этого пользователя, в поле «Икв» будет заноситься числовой идентификатор пользователя. Такими действиями могут быть коррекция значений атрибутов каналов и запись интерактивных сообщений в отчет тревог.

При выходе из работы с монитором любого пользователя в отчет тревог записывается следующее сообщение:

LOGOUT <имя><номер>, где <имя> — имя пользователя;

<номер> — числовой идентификатор пользователя.

 

Монитор реального времени в Trace Mode

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

Структура монитора реального времени (МРВ).

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

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

Для связи сервера математической обработки и графической консоли используется механизм DCOM. Отладочный монитор «ПРОФАЙЛЕР». Вместе с инструментальной системой поставляется специальный отладочный МРВ — профайлер. Этот монитор по своим функциям полностью воспроизводит обычный МРВ. Однако в отличие от него профайлер сохраняет в файле протокол работы, который содержит информацию о запуске, работе в реальном времени и завершении работы.

Этот файл имеет текстовый формат и имя <name>.txt (где <name> — имя файла базы каналов) и всегда создается в директории проекта. При каждом новом запуске профайлера старый файл профайлера стирается и вместо него создается новый.

Информация, заносимая в этот файл, зависит от используемых функций МРВ. Кроме профиля работы МРВ профайлер может сохранять в файле <name>.tnt (где <name> — имя файла базы каналов) дополнительную отладочную информацию.

Запуск графической консоли.

Графическая консоль запускается командной строкой:

PicRT.exe [<prg>.ctm/N:<node>] [/S:<PC>] [/F] [/R],

где <prg> — имя файла конфигурации проекта;

<node> — имя узла;

<РС> — имя компьютера, на котором должен работать сервер математической обработки; отсутствие этого параметра означает, что это локальный компьютер;

/F — выход при старте в полноэкранный режим;

/R — автоматический запуск сервера математической обработки при наличии пользователя с именем default; если его нет, то на экран выводится диалог запроса имени и пароля.

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

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

Сервер математической обработки может быть запущен командной строкой:

DrawServ.exe/P:<path>/F:<node> [/RUN] [/CONSOLE] [/AUTORS] [/IREC=n] [/REC=m] [/DEBUG-h] [/DISABLEJO] [/I:NNNN], где <path> — полный путь к базе каналов;

<node> — имя базы каналов без расширения;

/RUN — запуск пересчета при старте;

/CONSOLE — вывод на экран окна с таблицей каналов;

/AUTORS — этот ключ определен для каналов DCS,

MODBUS, M-Lmk(In,Out);

/LREC=n — число NCB для индивидуального приема

п=0,1,2 (по умолчанию 1);

/REC=m — число NCB для приема, включая IREC;

/DEBUG-h — вывод отладочной информации в файл <name>.tnt, где <name> — имя файла базы каналов. Этот ключ реализуется только для профайлера. Параметр h — это число в шестнадцатеричном формате, каждый бит которого указывает на сохранение определенного вида информации;

/DISABLEJO — замена каналов обмена с платами УСО на внутренние каналы;

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

Настройка DCOM.

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

После регистрации сервера математической обработки следует запустить программу Dcomcnfg.exe из поддиректории SYSTEM32 директории установки Windows NT. При этом на экран будет выведен диалог «Свойства: Настройка DCOM». В этом диалоге надо войти в бланк «Свойства по умолчанию» и настроить свойства DCOM, как показано на рис.1.

Рис.1

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

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

Пересчет базы каналов.

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

Рис.2

рис.3

Переход к новому циклу контролирует канал «Системный» с дополнением «Индекс пересчета». Величина цикла определяет минимальное время реакции системы.

Один пересчет базы каналов включает в себя четыре такта:

  • первый — пересчет всех каналов типа INPUT, кроме каналов подтипов «КАНАЛ» и «ОБЪЕКТ». При этом для каждого пересчитываемого канала последовательно выполняется трансляция входных значений в аппаратные и реальные и процедура «Управление»;
  • второй — пересчет каналов типа INPUT подтипов «КАНАЛ» и «ОБЪЕКТ». Для каждого пересчитываемого канала последовательно выполняется трансляция входных значений в аппаратные и реальные и процедура «Управление». Процедура «Управление» осуществляется для всех каналов, пересчитываемых на этом цикле;
  • третий — вычисление метапрограмм, написанных на ТехноIL;
  • четвертый — пересчет каналов типа OUTPUT (трансляция входных значений в реальные и аппаратные).

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

Модификация проектов в реальном времени. Чтобы подключить в реальном времени к базе каналов новый объект, его надо сохранить в файле и разместить в директории проекта. Кроме того, в базе надо предусмотреть специальные каналы управления загрузкой. Для них надо установить тип OUTPUT, подтип «СИСТЕМНЫЙ» с дополнением «Загрузить». Значение, посылаемое в такой канал, определяет выбор объекта для загрузки. Если оно равно двум, то загружается объект из файла с таким же именем, как у канала. Если значение больше 100, то имя файла определяется следующим образом:

<имя_каналаNN>.соb, где NN = <значение_канала>-100.

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

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

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

 

Обзор технологии OPC

Назначение OPC

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

OPC основана на модели распределенных компонентных объектов Microsoft DCOM и устанавливает требования к классам объектов доступа к данным и их специализированным (custom) интерфейсам для использования разработчиками клиентских и серверных приложений. Для обмена данными с приложениями-клиентами, разработка которых ведется на языках типа MS Visual Basic, а также с популярными приложениями типа Excel, спецификация OPC содержит дополнительные (но необязательные для реализации) требования к интерфейсу OLE-автоматизации (OLE-Automation).

Структура взаимодействия между приложениями-клиентами и серверами OPC различных производителей показана на рисунке:.

Взаимодействия между приложениями-клиентами и OPC-серверами

Взаимодействия между приложениями-клиентами и OPC-серверами

Опираясь на объектную технологию COM/DCOM, стандарт OPC фиксирует определенную модель взаимодействия между клиентом и сервером.

Базовым понятием этой модели является элемент данных (Item). Каждый элемент данных имееет значение, время последнего обновления (timestamp) и признак качества, определяющий степень достоверности значения. Значение может быть практически любого скалярного типа — булево, целое, плавающее с точкой и т.п. — или строкой (так называемый OLEVARIANT). Время представляется со 100-наносекундной точностью (FILETIME Win32 API). Реальная точность измерения времени обычно бывает хуже и, в общем случае, зависит от реализации сервера и аппаратуры. Качество — это код содержащий в себе грубую оценку — UNCERTAIN, GOOD и BAD (не определено, хорошее и плохое), а на случай плохой — еще и расшифровку, например QUAL_SENSOR_FAILURE — неисправность датчика.

Следующим вверх по иерархии является понятие группы элементов (OPC Group). Группа создается OPC-сервером по требованию клиента, который затем может добавлять в группу элементы (Item). Для группы клиентом задается частота обновления данных, и все данные в группе сервер старается обновлять и передавать клиенту с заданной частотой. Отдельно стоящих вне группы элементов быть не может. Клиент может создать для себя на сервере несколько групп, различающихся требуемой частотой обновления. Для каждого клиента всегда создается своя группа (кроме так называемых публичных групп), даже если состав элеметов и частота обновления совпадают. Отсоединение клиента приводит к уничтожению группы.

Элементы в группе, таким образом, — это своего рода клиентские ссылки на некие реальные переменные (тэги), находящиеся на сервере или в физическом устройстве. Понятие тэга спецификацией OPC не определяется, но подразумевается неявно. Элементы в группу клиент добавляет по имени, и эти имена являются именами соответствующих тэгов. Клиент может либо знать нужные имена заранее, либо запросить список имен тэгов у сервера. Для запроса имен тэгов служит интерфейс IOPCBrowseServerAddressSpace, с помощью которого сервер описывает клиенту свое «пространство имен», организованное в общем случае иерархически. Пример полного имени тэга: Устройство1.Модуль5.АналоговыйВход3. При добавлении элемента в группу клиент всегда указывает это полное имя. Заметим, что группы, создаваемые клиентом, не обязаны совпадать (и, как правило, не совпадают) с подразделами пространства имен сервера, элементы в группу добавляются в «разнобой». Единственное, что их объединяет — это общая частота обновления и синхронность отправки клиенту.

Наконец, на верхней ступеньке иерархии понятий находится сам OPC-сервер. Из всех перечисленных (OPC-группа, OPC-элемент) он единственный является COM-объектом, все остальные объекты доступны через его интерфейсы, которые он предоставляет клиенту.

Установление соединения между клиентом и сервером на одном компьютере

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

Установление соединения между клиентом и удаленным сервером

Для работы в сети (клиент и сервер на разных компьютерах) необходимо присутствие в сети хотя бы одной станции с установленной Windows NT (Server или Workstation). Станция с Windows NT используется в качестве сервера авторизации и аутентификации, при этом сам OPC-сервер может располагаться как на ней, так и на другой сетевой станции. Перед установлением соединения между приложением-клиентом и удаленным сервером следует произвести настройку системных компонентов DCOM.

Локальный СПАД в Trace Mode

Этот вид локального архива предусмотрен для сохранения на диске и последующего анализа значений каналов текущего узла. В нем фиксируются изменения реальных значений и невычисляемых атрибутов каналов. В этот архив значения каналов записываются в бинарном формате. Условием записи является изменение значения канала. При этом в архив добавляется одна запись, фиксирующая новое значение и время. Точность фиксации времени составляет 1 мс. СПАД имеет фиксированную длину. При этом глубина архивирования определяется заданным размером и интенсивностью потока данных. При настройке СПАД задается имя файла архива, путь к нему и размер в мегабайтах. Время записи равно базовому времени цикла пересчета базы каналов. Это означает, что при многократном изменении какого-либо архивируемого атрибута в пределах одного цикла пересчета базы в архив попадет значение последнего изменения. Поскольку размер архива ограничен, то увеличение времени хранения достигается сокращением интенсивности потока данных. Для этого вводится апертура по каналам, чтобы не фиксировать малые изменения, а для инерционных параметров увеличивается период опроса. Данные в СПАД обновляются циклически.

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

Сохранение данных в СПАД реализовано в виде потока, работающего параллельно с пересчетом базы каналов, но имеющего более низкий приоритет. МРВ формирует внутреннюю очередь сообщений для записи в СПАД. Поток архивирования берет данные из нее и записывает их в архив. Если размер очереди превышен, то самые ранние по времени сообщения теряются. По умолчанию максимальный размер очереди принимается равным 64 000 сообщений.

Контроль состояния очереди сообщений в СПАД и управление ею осуществляется с помощью канала подтипа «ДИАГНОСТИКА» с дополнением очереди в СПАД.

МРВ, сохраняющий данные в СПАД, инициализирует этот архив при первом запуске. МРВ проверяет наличие свободного места на диске. Если место на диске есть, то создается файл архива. Число записей в архиве определяется его размером, длиной записи и размером заголовка. Величина одной записи составляет 16 байт, а размер заголовка, в котором формируются структуры для индексации данных в архиве, приблизительно 1 Мбайт. Если указанная длина архива меньше размера заголовка и на диске есть свободное место, то файл архива создается. Его размер будет 1,4 Мбайт. Это позволяет хранить 22 770 записей. Если при запуске МРВ уже существует файл архива с тем же именем, то проверяется идентичность его структуры требуемой. При этом сравниваются установленный размер и имя узла. Для контроля и управления архивированием данных в СПАД предусмотрены следующие каналы: подтип «ДИАГНОСТИКА» с дополнениями «СПАД», «Потеря СПАД» и «Очередь СПАД», подтип «Системный» с дополнениями «Архивация» и «СПАД копировать». Канал «Системный» с дополнением «Архивация» управляет сохранением во всех архивах. Значение его нулевого бита управляет разрешением записи в локальный архив, а восьмого — разрешением открытия файла архива: 0-разрешить; 1 — запретить.

Запрет открытия файла используется при записи архива на сменный носитель во время его замены. При этом файл закрывается, а новые данные накапливаются в буфере. После замены носителя значение восьмого бита следует снова установить равным нулю. В результате на новом носителе создается файл архива. В него запишутся данные из буфера, и процесс архивирования продолжится. Принудительное сохранение данных в СПАД реализуется с помощью канала типа OUTPUT подтипа «ДИАГНОСТИКА» с дополнением «Потеря СПАД».МРВ может экспортировать данные из локального архива в файлы текстового формата. Существует возможность экспортировать архивные значения одного канала или всей базы целиком. Для управления экспортом значений из одного архивируемого канала используется канал типа OUTPUT подтипа «КАНАЛ» с дополнением «SetGetCПАД». Он имеет настройки для выбора канала и его атрибута и настройку, задающую диапазон выборки. Значение канала OUTPUT задает смещение базового времени в секундах относительно начала текущих суток. Диапазон выборки отсчитывается назад от полученного базового времени. Положительное значение канала задает смещение назад, а отрицательное — вперед.

Экспортируемые данные сохраняются в текстовом файле, имя которого образуется из имени указанного канала. При каждой операции экспорта новые данные дописываются в конец данного файла. Экспорт всех архивируемых каналов осуществляется в текстовый файл с именем data.txt. Он располагается в директории проекта. При каждой операции экспорта новые данные дописываются в конец файла. Данные в него заносятся в следующем формате:

<имя канала 1>

<дата время> <значение>

…………………………..

<дата время> <значение>

…………………………..

<имя канала n>

<дата время> <значение>

………………………….

<дата время> <значение>

Для управления экспортом данных из СПАД используется канал типа OUTPUT подтипа «Системный» с дополнением «Данные из СПАД». Значение канала определяет временной диапазон выборки и вид представления экспортируемых каналов:

1 — за предыдущие сутки по каналам F;

2 — за предыдущие сутки по каналам Н;

3 — за предыдущий час по каналам F;

4 — за предыдущий час по каналам Н;

5 — за текущий час до текущей минуты по каналам F;

6 — за текущий час до текущей минуты по каналам Н;

7 — за последние 24 часа по каналам F;

8 — за последние 24 часа по каналам Н;

9 — за текущие сутки до текущего часа по каналам F;

10 — за текущие сутки до текущего часа по каналам Н.

Канал типа INPUT контролирует чтение данных из СПАД. Для управления копированием СПАД используется канал подтипа «Системный» с дополнением «СПАД копировать». Посылаемое в этот канал значение определяет путь к копии:

1 — в директорию проекта;

2 — в корневую директорию диска С, где записан проект;

3 — в корневую директорию диска А;

65… 95 — в корневые директории дисков (65 — А; 66 — В и т. д.).

Имя файла копии архива образуется из 8-разрядного шестнадцатеричного числа, кодирующего дату и время (число секунд с 00:00:00 01/01/1970).

Данные, записанные в архив во время его копирования, в копии отсутствуют. Для контроля сохранения данных в локальном СПАД и чтения из него предназначен канал типа INPUT подтипа «ДИАГНОСТИКА» с дополнением «СПАД». Если этот канал имеет тип OUTPUT, то любая его отработка обнуляет признак текущего состояния операций с локальным архивом/

 

Графический интерфейс в SCADA-системе TRACE MODE.

Для разработки средств визуализации состояния технологического процесса и управления им (создания человеко-машинного интерфейса для операторских станций – графических баз для узлов проекта) в SCADA-системе TRACE MODE имеется редактор преставления данных. В него загружается структура проекта, созданная в редакторе базы каналов.

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

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

  • Размер,
  • Цвет фона,
  • Обои,
  • Права доступа,
  • Спецификация окна просмотра отчета тревог.

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

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

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

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

Существует два типа графических объектов: «Объект» и «Блок». Первый из них может ссылаться на 256 каналов, а второй – только на один.

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

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

Для хранения графических объектов используются графические библиотеки. Каждая библиотека имеет имя и список включенных в нее объектов. Чтобы в дальнейшем использовать созданную библиотеку, ее надо сохранить в файле. Для получения доступа к сохраненной ранее библиотеке надо ее загрузить в редактор представления данных.

 

Идеология распределенных комплексов

SCADA-системы имеют мощные средства для создания распределенных АСУТП, включающих в себя до трех уровней иерархии:

  1. Уровень контроллеров – нижний уровень;
  2. уровень операторских станций – верхний уровень;
  3. административный уровень.

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

Уровень контроллеров.

На этом уровне реализуется сбор данных от датчиков и НЦУ. Для создания этого уровня предусмотрены мониторы: Микро МРВ, Микро МРВ Модем+, Микро МРВ GSM+. Первый из них предназначен для запуска в контроллерах, связанных с верхним уровнем по локальной сети или последовательному интерфейсу, второй – при связи по коммутируемым линиям, а третий – по GSM- сети. При использовании выделенных телефонных линий или радиоканалов следует применять первый монитор. Эти мониторы не имеют графического интерфейса. Однако по математическим функциям они идентичны мониторам верхнего уровня, а также имеют ряд функций, необходимых для работы в контроллерах (например, поддержка сторожевого таймера).

Оперативный уровень.

Для верхнего уровня АСУТП предусмотрены такие мониторы, как МРВ, NetLink МРВ, NetLink Light. Они позволяют создавать рабочие станции оперативного управляющего персонала. МРВ может обмениваться данными с другими мониторами SCADA-системы, а также с любыми контроллерами через встроенные протоколы или драйвер. Он запрашивает данные у нижнего уровня и передает ему команды управления. Полученные данные могут отображаться, архивироваться и передаваться другим приложениям WINDOWS по протоколам ODBC, OPC и DDE.

NetLink МРВ – это сетевая рабочая станция. Этот монитор может обмениваться данными с операторскими станциями (по последовательному интерфейсу или локальной сети), а также с Микро МРВ, работающими в PC-based контроллерах. По функциям визуализации, архивирования, связи с базами данных и документирования NetLink МРВ аналогичен МРВ. В отличие от МРВ, в нем блокированы поддержка плат УСО, обмен с драйвером, обмен по встроенным протоколам MODBUS и DCS, а также клиентские функции OPC и DDE.

NetLink Light – это сетевой графический терминал. Он не имеет своего сервера матобработки, а связывается с сервером МРВ или NetLink МРВ, запущенным на другом компьютере.

NetLink Light позволяет создавать дополнительные рабочие места оператора.

Административный уровень.

Задачей данного уровня управления является контроль текущего состояния производственных процессов и анализ функционирования производства по архивным данным. Для решения задач данного уровня предусмотрен монитор SUPERVISOR . Он является специализированной графической консолью, которая может подключаться к серверу матобработки МРВ, NetLink МРВ или ГР. В первых двух случаях просматривается локальный СПАД архив, а в последнем – глобальный архив. Кроме того, SUPЕRVISOR можно переключить в режим реального времени. В этом случае он работает как консоль NetLink Light, и может использоваться для управления процессом.

При работе с архивами SUPЕRVISOR реализует следующие функции:

  • отображение последних изменений значений каналов;
  • просмотр архивов в режиме PLAYBACK;
  • просмотр на заданное
  • архивное время с пошаговым переходом по времени.

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

Мониторы реального времени SCADA-системы могут обмениваться данными по следующим линиям:

  • локальная сеть;
  • последовательный интерфейс RS-232, RS-485, RS-422;
  • радиоканал;
  • выделенная телефонная линия;
  • коммутируемые телефонные линии;
  • сети GSM.

По этим носителям необходимо организовать информационные потоки всех уровней системы управления. При этом могут реализоваться как вертикальные связи (между уровнями), так и горизонтальные (между узлами одного уровня). Например, при задании связи двух каналов разных узлов по RS необходимо создать в узлах компоненты COM-порт, задать для них необходимые параметры и указать для канала-приемника используемый интерфейс связи.

 

Обмен Trace Mode с базами данных через механизмы ODBC.

Для связи с базами данных и бизнес-приложениями в МРВ встроена поддержка интерфейса ODBC [1]. МРВ может запрашивать данные из зарегистрированных источников данных ODBC и записывать в них значения каналов. При этом передача значений каналов может осуществляться как в режиме формирования новых записей в базе (INSERT), так и в режиме обновления существующих (UPDATE).

Чтобы связаться с базами данных (БД) по ODBC в директории проекта, надо создать конфигурационный файл odbc.cfg. Этот файл имеет текстовый формат. В нем описывается база данных, имя пользователя, имеющего доступ к ней, а также элементы запросов на языке SQL для управления обменом данными. При этом с целью обеспечения обмена с любыми ODBC-серверами фрагменты SQL-запросов следует записывать прописными буквами.

Перед тем как создать источник данных, необходимо убедиться в наличии TRACE MODE драйвера ODBC driver, установка которого обычно производится автоматически при инсталляции системы. Если по каким-то причинам он не установлен, необходимо выполнить его установку вручную.

Для взаимодействия с любой базой данных ее надо зарегистрировать как источник с помощью панели управления WINDOWS. Это могут быть популярные программы Microsoft Access или Excel. Так, если проектная документация составлена в виде таблиц программы Microsoft Access и сконфигурирована в файл “Проектная документация.mdb”, то чтобы переписать её в БД необходимо:

1. Создать источник данных ODBC, для чего на диске C следует открыть Панель управления MS Windows. Если это – Win9x или WinNT, то дважды нажать ЛК мыши на иконке “ Источники данных ODBC ” (для Win200 эта иконка расположена в пункте Администрирование). В появившемся диалоговом окне Администратор источников данных ODBC следует выбрать бланк Пользовательский DSN и нажать кнопку ”Добавить”. Затем в окне Создание нового источника данных выбрать из списка пункт Driver do Microsoft Access (*.mdb) и нажать кнопку ”Готово”.

2. В поле Имя источника данных записать имя проекта, например, YPN и нажать кнопку “Выбрать”. Теперь в качестве БД нужно выбрать с диска С файл “Проектная документация.mdb”, нажать “Ок” и закрыть Администратор источников данных ODBC.

Обмен данными в Trace Mode через механизмы OPC.

Одним из самых перспективных стандартов обмена данными между приложениями WINDOWS при создании систем управления является механизм OPC. OPC (OLE for Process Control) – стандартизованные интерфейсы для Microsoft технологии COM, предназначенные для применения в области автоматизации управления технологическими процессами. Стандарт ОРС разработан международным фондом OPC Foundation, который был создан фирмами Fisher Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell и Siemens в 1995 г. В 1996 г. появилась первая версия спецификации ОРС.

ОРС в настоящее время является стандартом, который признан разработчиками, системными интеграторами и пользователями АСУ ТП. Сегодня практически все производители программного и аппаратного обеспечения АСУ ТП разрабатывают продукты, соответствующие этому стандарту.

За последние несколько лет ОРС серверы полностью вытеснили DDE (Dynamic Data Exchange) серверы и специализированные драйверы для аппаратных средств автоматизации. DDE – самый старый (время появления — 1989-1991 гг.) и очень медленный способ динамического обмена данными между Windows приложениями, был со временем заменен (преобразован) в OLE (Object Linking and Embedding). OLE первоначально и до середины 90-х годов использовался исключительно Microsoft для обмена данными между ее офисными приложениями. Во время разработки Windows NT появилась технология DCOM (Distributed Componet Object Model) как продолжение технологии COM. DCOM была разработана для распределенных клиент-серверных приложений. Один клиент мог одновременно использовать несколько серверов, установленных на разных компьютерах в сети и каждый сервер одновременно мог обслуживать несколько клиентов. В настоящее время ОРС базируется практически исключительно на DCOM технологии фирмы Microsoft для распределенных систем. Главным понятием DCOM является понятие интерфейса, посредством которого DCOM-объекты обслуживают клиентов.

Для обмена данными по OPC между мониторами ТРЕЙС МОУД используются каналы подтипа СВЯЗЬ с дополнениями In OPC – прием данных от МРВ по OPC , Out OPC – передача данных МРВ по OPC.

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

Каналы для связи с ОРС-сервером создаются процедурой автопостроения. Чтобы запустить её, следует, находясь в окне объектов настраиваемого узла, выполнить команду “Связать с OPC-сервером” из меню “Узел” или нажать сочетание клавиш “Alt”+”L”. При этом появится экран “Выбор сервера OPC”, на котором имеется тир кнопки: ”Добавить”, ”Удалить”, ”Изменить”. Нажатие кнопки ”Добавить” выводит на экран “Выбор сервера OPC” перечень серверов, зарегистрированных на локальной машине или на любом компьютере, присутствующем в сети.

Указанный сервер добавляется в список предыдущего диалога.

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

Чтобы создать каналы ТРЕЙС МОУД для обмена с выделенным в списке сервером, надо нажать ЛК на кнопке “Выбрать”. В левом окне появившегося экрана следует выбрать каналы OPC-сервера, которые надо контролировать в МРВ, и перенести их в правое окно нажатием ЛК на кнопке “>>”. После выхода из этого диалога в базе каналов появится новый объект, имя которого образовано из идентификатора OPC-сервера. В нем создаются каналы для обмена с указанными каналами сервера.

OPC – серверы фирмы OWEN

Для работы оборудования c широким набором современных SCADA систем необходимы драйверы OPC. Что такое OPC? OLE(object linking and embedding) for Process Control, Объектное связывание и встраивание для контроля процессов – открытый для широкого использования набор спецификаций, разработанный организацией OPC Foundation на основе технологий Microsoft COM/DCOM. Когда упоминают термин  OPC-драйверы  для приборов, чаще всего имеют в виду OPC–сервер, реализующий спецификацию Data Access(DA). OPC DA — широко известная спецификация, которая сейчас уже имеет версию 3.0, другие спецификации доступны только в виде альфа и бета версий. Она позволяет читать и писать данные в прибор, организовывать подписку на данные и получать клиенту уведомление об обновлении данных.

Для работы с OPC-драйверами требуется любая SCADA система, поддерживающая спецификацию OPC DA. Кроме того, прочитать и записать данные может пользовательская программа на языке, полноценно поддерживающем COM технологию Microsoft (Visual Basic, C++, Java, Delphi и т.д.). Получение данных возможно также и из приложений поддерживающих доступ к COM объектам (например, таких как Microsoft Office). Это позволит пользователю получить в таблице Excel набор технологических параметров изменяющихся в реальном масштабе времени.

Протокол ОВЕН.

Драйверы OPC реализованы в виде 2 модулей OWEN-RS232 и OWEN-RS485 – для приборов фирмы ОВЕН, поддерживающих сетевой интерфейс «токовая петля» (для преобразования в сеть RS232 используется адаптер АС2) и для приборов фирмы ОВЕН, поддерживающих сетевой интерфейс RS484 (для преобразования в сеть RS232 или USB можно использовать как сторонние адаптеры, так и фирмы ОВЕН: полуавтоматический преобразователь RS232/RS485 АС3, автоматические преобразователи RS232/RS485 АС3-М, USB/RS485 АС4), соответственно. Перед началом работы пользователь должен задать конфигурацию своих приборов и режим работы порта. К адаптеру AC-2 можно подключить до 8 приборов. К одной сети RS485 подключается до 32-х приборов шлейфом (без применения репитера).

Список приборов, которые можно подключить к серверам:

OWEN-RS232

OWEN-RS485
Задатчик-регулятор МПР51Измеритель ТРМ0 PiC

Измеритель  УКТ38-В

Измеритель  УКТ38-Щ4

Измеритель регулятор ТРМ1 PiC

Измеритель регулятор ТРМ10 PiC

Измеритель регулятор ТРМ12 PiC

Измеритель регулятор ТРМ5 PiC

Многоканальный регулятор ТРМ32

Многоканальный регулятор ТРМ33

Многоканальный регулятор ТРМ34

Многоканальный регулятор ТРМ38

Многоканальный регулятор ТРМ138

Универсальный двухканальный программный ПИД-регулятор ОВЕН ТРМ151

Счетчик импульсов СИ8

Прибор контроля положения ПКП1

Модуль ввода аналоговый ОВЕН МВА8

Модуль вывода управляющий ОВЕН МВУ8

ПИД регулятор с универсальным входом ТРМ101

Измеритель двухканальный с универсальными входами ОВЕН ТРМ200

Измеритель-регулятор одноканальный с универсальным входом ОВЕН ТРМ201

Измеритель-регулятор двухканальный с универсальными входами ОВЕН ТРМ202

Контроллер приточной вентиляции ОВЕН ТРМ133

С версии 1.0.0.5 OPC-сервера OWEN-RS232 добавлен тег, управляющий обменом на внешней шине, проще говоря, флаг активности opc-сервера.

Имя тега “Status/active”, тип BOOL. Запись в этот тег 1 (единицы) разрешает обмен по внешней шине, запись 0 (нуля) запрещает обмен.

Протокол ModBus.

Драйвер OPC реализован в виде модуля OWEN-ModBus для приборов, поддерживающих протокол ModBus-RTU или ModBus-ASCII. Для подключения приборов к ПК могут использоваться как преобразователи интерфейса ОВЕН (полуавтоматический преобразователь RS232/RS485 АС3, автоматические преобразователи RS232/RS485 АС3-М, USB/RS485 АС4), так и преобразователи сторонних производителей. Перед началом работы пользователь должен задать конфигурацию своих приборов и режим работы порта.

В конфигуратор OWEN-ModBus встроена возможность добавления как большинства приборов компании ОВЕН, так  приборов сторонних производителей с 4мя основными функциями чтения и 3мя основными функциями записи.