From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Documents/Quick start and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська

Автор: Роман Савоченко, Максим Лысенко (2010-2012)

Contents

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

По этой причине, и для наглядного представления общей концепции работы в OpenSCADA, создан данный документ. Документ, на реальных примерах в достаточно краткой и наглядной форме, представляет путь от установки и запуска OpenSCADA до создания элементов пользовательского интерфейса. В качестве целевой помощи в конфигурации, реализации и решения типовых задач около OpenSCADA, также могут быть использованы документы "Частые вопросы" и "Как сделать ... (How to ...)".

Документ предназначен для OpenSCADA версии 0.9 и больше. Если-же Вас интересует это документ для ранних версий тогда Вы можете его получить из документации, которая идёт с пакетами той версии OpenSCADA, или из документа старой Wiki.

Документ не содержит детального описания концепции и погружения в детали OpenSCADA, а предоставляет ссылки на документы, содержащие такую информацию, и в первую очередь это "Руководство по программе".

Документ строится синхронно с реализацией примеров на подключении к демонстрационной базе данных (БД) модели "АГЛКС" в роли источника данных — ПЛК. Следовательно, пользователь должен получить дистрибутив OpenSCADA с этой БД, о чём детальнее в разделе "Установка"!

1 Термины, определения и аббревиатуры

1.1 Термины и определения

  • Qt — инструментарий разработки ПО, с помощью которого, в частности, созданы модули QTStarter (пускатель модулей OpenSCADA на библиотеке Qt), QTCfg (графический конфигуратор OpenSCADA) и Vision (редактор и исполнитель рабочих пользовательских интерфейсов СВУ). Может встречаться в виде QT, что является ранней записью, использованной разработчиками OpenSCADA для библиотеки Qt.
  • Блокировка — условная граница технологического параметра по преодолению которой выполняются предусмотренные алгоритмом действия по предотвращению аварии. В некоторых режимах ТП (пуск), в соответствии с регламентом, может быть необходимо отключение блокировки — деблокирование.
  • Виджет СВУ — элемент визуализации СВУ.
  • Деблокирование — процесс отключения блокировки на время работы ТП в режимах для которых в регламенте предусмотрена данная операция. Деблокирование технологических параметров является строго отчётной операцией и должно производится оперативным персоналом в соответствующем порядке!
  • Кадр СВУ — производный элемент визуализации, состоящий из базовых элементов и способный выполнять функции страницы проекта СВУ.
  • Квитация (от quietance) — процесс подтверждения факта того, что оперативный персонал обратил внимание на нарушение в работе ТП. Обычно этот процесс подразумевает принятие мер оператором для устранения нарушения и нажатие соответствующей кнопки прекращения сигнализации.
  • Комплексный параметр-тег или объект-тег сигнала — детализированный сигнал источника данных как исчерпывающий параметр-тег, который для аналогового обычно содержит:
    • значение сигнала в инженерной-реальной единице измерения;
    • имя единицы измерения;
    • шкала-диапазон физического изменения значения сигнала — минимальная и максимальная границы;
    • шкалы границ сигнализации — обычно это верхняя и нижняя границы для предупредительной и аварийной сигнализации;
    • параметры фильтра;
    • параметры особенностей шкалы, определения достоверности, формата представления и другое.
  • Модель данных — организация и структурирование данных технологического процесса (ТП) или другого объекта автоматизации в слое источника данных SCADA, протокола обмена или ПЛК. По умолчанию имеется в ввиду слой источника данных OpenSCADA со структурой "Объект контролера" -> "Параметр, уровень 1" -> ... "Параметр, уровень N" -> "Атрибут значения - сигнал".
  • Проект — данный термин имеет много значений и, в зависимости от контекста, может иметься ввиду:
    • Проект (программа) OpenSCADA — свободное программное обеспечение, документацию которого Вы в данный момент читаете.
    • Определённый набор-каталог с конфигурацией и данными, которые создаются пользователем OpenSCADA, где конфигурация сохраняется в конфигурационном файле (обязательно) и одном или нескольких файлах БД (необязательно и может быть в сети). Например — демонстрационный проект, модель ТП "АГЛКС". Т.е., автором проекта выступает пользователь программы — инженер-разработчик или программист SCADA системы.
    • Проект СВУ — составная среды визуализации и управления (СВУ), которая создаётся в модуле UI.VCAEngine через UI.Vision и которая содержит набор кадров СВУ.
  • Сигнал (относительно источника данных) — элемент источника данных в виде измеренного, или вычисленного, значения технологического параметра или сенсора. Представляет из себе скаляр дискретного, целого или реального типов, который часто кодируется, масштабирование шкалы параметра в размерность целого. Сигнал, для идентификации, часто просто индексируется или кодируется по адресу его значения в карте протоколу обмера, а осмысленное название он получает в модели данных SCADA.
  • Сигнализация — процесс уведомления оперативного персонала о нарушении технологического процесса или работы оборудования автоматизации. Способы сигнализации могут быть различных типов воздействия на органы чувств человека, с целью привлечения внимания. Часто предусматриваются следующие типы сигнализации:
    • Световая сигнализация — обычно осуществляется посредством смены цвета графического объекта (миганием) для возникающих событий и установкой статичных аварийных цветов (красный и жёлтый) для сквитированных-подтверждённых событий.
    • Звуковая — осуществляется выдачей звукового сигнала в момент возникновения события. Тип звукового сигнала может быть как монотонным, так и синтезированным речевым сообщением с информацией о нарушении.
  • Уставка сигнализации — условная граница значения технологического параметра, преодоление которой считается нештатной ситуацией. Обычно предусматриваются следующие границы:
    • Верхняя и нижняя аварийные границы — границы аварийных значений технологического параметра.
    • Верхняя и нижняя предупредительные границы — границы предупреждения, регламентные границы, о выходе технологического параметра за рабочий диапазон.
    • Отказ — признак выхода значения параметра за аппаратные границы технологического оборудования. Обычно характеризует отказ датчика, обрыв канала связи с датчиком или ПЛК.

1.2 Употребляемые сокращения

  • API (англ. Application Programming Interface) — интерфейс программирования приложений (модулей OpenSCADA) или расширений на внутреннем языке OpenSCADA — API пользователя.
  • AWP (англ. Automated Work Place) — см. АРМ.
  • MOD (англ. Matching to Object Device) — см. УСО.
  • DAQ (англ. Data Acquisition) — сбор данных.
  • DB (англ. Data Base) — см. БД.
  • DCON — наименование одного из коммуникационных протоколов, используемых в промышленности.
  • GPL (англ. General Public License) — открытое лицензионное соглашение (лицензия), по условиям которого распространяется и может использоваться OpenSCADA.
  • GUI (англ. Graphical User Interface) — графический интерфейс пользователя.
  • HMI (англ. Human-machine Interface) — человеко-машинный интерфейс.
  • HTTP (англ. HyperText Transfer Protocol — "протокол передачи гипертекста") — протокол прикладного уровня передачи данных, чаще всего в виде гипертекстовых документов.
  • ModBus — Modicon BUS это последовательный коммуникационный протокол, в вариантах RTU и ASCII, исходно опубликованный Modicon в 1979 для использования со своими ПЛК. Позже расширен для работы поверх TCP-IP и этот вариант получил название ModBus/TCP.
  • PLC (англ. Programmable Logic Controller) — см. ПЛК.
  • QT — см. QT в списке терминов, не является сокращением.
  • SCADA (англ. Supervisory Control And Data Acquisition) — диспетчерский контроль и сбор данных.
  • TP (англ. Technological Process) — см. ТП.
  • TUI (англ. Terminal(Text) User Interface) — терминальный (текстовый) интерфейс пользователя.
  • UI (англ. User Interface) — интерфейс пользователя.
  • VCA (англ. Visual Control Area) — см. СВУ.


  • АРМ — Автоматизированное Рабочее Место. Обычно представляет из себя системный блок вычислительной системы, дисплей, манипулятор "мышь" иногда с клавиатурой, и другое периферийное оборудование, которое служит для визуального представления данных технологического процесса, а также выдачи управляющих воздействий на ТП.
  • БД — База Данных.
  • ОС — Операционная Система.
  • ПЛК — Программируемый Логический Контроллер.
  • ПО — Программное Обеспечение.
  • СО — Объект Сигнализации (литеры в аббревиатуре переставлены чтобы не путать с сокращением ОС (см. выше)).
  • СВУ — Среда Визуализации и Управления.
  • ТП — Технологический Процесс. Весь комплекс технологического оборудования производственного процесса.
  • УСО — Устройство Сопряжения с Объектом. Ряд устройств или модулей ПЛК, к которым непосредственно подключаются сигналы с датчиков ТП для последующего преобразования из аналогового в цифровой вид и обратно. Преобразование осуществляется с целю последующей обработки значений технологических параметров в ПЛК.
  • ФС — файловая система.

2 Установка OpenSCADA

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

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

Если у пользователя вызывает затруднение установка не только OpenSCADA, но и дистрибутива Linux, то, на первое время, он может воспользоваться "живым" дистрибутивом Linux с установленной и готовой для работы и изучения демонстрацией и полноценной OpenSCADA. Если его устроит такое окружение быстрой доступности то он может остановить свой выбор на нём и установить. На данный момент доступны "живые" сборки на основе дистрибутива Debian и ALTLinux (устаревшее) в виде гибридных CD/DVD/USB-образов, на странице: http://oscada.org/ru/glavnaja/zagruzit. Детальнее смотрите в документе рецепта (How to ...) "Живой диск (Live CD/DVD/USB)".

2.1 Установка OpenSCADA из готовых пакетов

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

Проверить наличие пакетов OpenSCADA в репозиториях дистрибутивов Linux или OpenSCADA, а также загрузить пакеты OpenSCADA для ручной установки, можно на странице загрузки официального сайта OpenSCADA (http://oscada.org/ru/glavnaja/zagruzit/). Здесь Вы также можете получить конфигурацию для подключения репозиториев пакетов OpenSCADA к пакетному менеджеру вашего дистрибутива Linux.

At.png Загружать пакеты и подключать репозитории пакетов нужно непосредственно для версии используемого дистрибутива иначе, при установке, могут возникнут неразрешимые проблемы с зависимостями.

2.1.1 Добавление репозитория пакетов и установка OpenSCADA из него

Репозитории с пакетами предоставляются самим проектом OpenSCADA, служебная информация которых обычно располагается рядом с самими пакетами и обновляется автоматически при сборке, т.е. эти репозитории являются наиболее свежими и предпочтительными. Хотя пакеты OpenSCADA всё ещё можно встретить в репозиториях таких дистрибутивов ОС Linux: ALTLinux и дистрибутивах, основанных на пакетной базе Fedora, но они там, скорее всего, будут старые, поскольку сборка в репозитории дистрибутивов разработчиками сейчас не практикуется!

Адреса репозиториев и конфигурацию менеджера репозиториев Вы можете получить на той-же странице загрузки OpenSCADA (http://oscada.org/ru/glavnaja/zagruzit/) или в примерах ниже.

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

  • openscada-model-aglks, openscada-model-boiler — проекты динамических моделей технологических процессов, которые по совместительству выполняют функцию демонстрации OpenSCADA;
  • openscada-vis-station — шаблонный проект SCADA станции, обычно — запуск в графическом интерфейсе и без Web;
  • openscada-server — шаблонный проект сервера SCADA, запускаемого в фоновом режиме — режим демона;
  • openscada-plc — шаблонный проект ПЛК, запускаемого в фоновом режиме — режим демона;
  • openscada — типовая-полная установка OpenSCADA.

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

Репозитории пакетов, основанные на менеджере APT (Debian, Ubuntu, ALTLinux) — добавляются помещением загруженного файла "openscada.list" в директорию "/etc/apt/sources.list.d" или редактированием файла /etc/apt/sources.list, вставкой одной строки:
Debian: "deb http://ftp.oscada.org/OpenSCADA/0.9.0/Debian/9 ./"
Debian (рабочая версия): "deb http://ftp.oscada.org/OpenSCADA/Work/Debian/9 ./"
Debian (рабочая версия, модули отдельно): "deb http://ftp.oscada.org/Debian/9/openscada ./"
Ubuntu: "deb http://ftp.oscada.org/OpenSCADA/0.9.0/Ubuntu/16.04 ./"
Ubuntu (рабочая версия): "deb http://ftp.oscada.org/OpenSCADA/Work/Ubuntu/16.04 ./"
Установка:

$ apt-get update
$ apt-get install openscada-model-aglks

ALTLinux: "rpm http://ftp.oscada.org/OpenSCADA/0.9.0/ALTLinux/7 openscada main"
ALTLinux (рабочая версия): "rpm http://ftp.oscada.org/OpenSCADA/Work/ALTLinux/6 openscada main"
ALTLinux (рабочая версия, модули отдельно): "rpm http://ftp.oscada.org/ALTLinux/7 openscada main"
Установка:

$ apt-get update
$ apt-get install openscada-Model.AGLKS

Добавление ключа проверки подписи (подлинности) репозитория и пакетов в нём (необязательно и используется не во всех репозиториях):

 $ wget -O - http://ftp.oscada.org/Misc/pkgSignKey | sudo apt-key add - 

Репозитории пакетов, основанные на менеджере пакетов YUM (RedHat, Fedora, CentOs) — добавляются загрузкой или созданием файла /etc/yum.repos.d/openscada.repo с содержимым:

[openscada]
name=OpenSCADA
#CentoOs
baseurl=http://ftp.oscada.org/OpenSCADA/0.9.0/CentOs/7
#CentoOs (рабочая версия)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/CentOs/6
#Fedora (рабочая версия)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/Fedora/12
enabled=1
gpgcheck=0

Установка:

$ yum install openscada-Model.AGLKS 

Репозитории пакетов SuSE YaST — добавляются командой:

$ zypper ar -f http://ftp.oscada.org/OpenSCADA/0.9.0/SuSE/13 OpenSCADA

Установка:

$ zypper in openscada-Model.AGLKS 

2.1.2 Ручная установка пакетов OpenSCADA

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

Первый набор представлен одиннадцатью пакетами:

  • openscada — пакет со всеми файлами, нужными для запуска OpenSCADA в полном объёме, включая все модули;
  • openscada-server — содержит зависимости, файл сценария и конфигурацию проекта сервера для запуска OpenSCADA в режиме сервиса-демона;
  • openscada-libdb-main — основные библиотеки OpenSCADA для сбора данных и другого, в БД SQLite;
  • openscada-libdb-vca — библиотеки визуальных компонетов, в БД SQLite;
  • openscada-model-aglks — БД и конфигурация динамической модели реального времени "АГЛКС" (Демо: EN,UK,RU);
  • openscada-model-boiler — БД и конфигурация динамической модели реального времени "Котёл" (EN,UK,RU);
  • openscada-doc-en — offline документация OpenSCADA, английский язык;
  • openscada-doc-uk — offline документация OpenSCADA, украинский язык;
  • openscada-doc-ru — offline документация OpenSCADA, российский язык;
  • openscada-dev — пакет разработки, для отдельного создания модулей OpenSCADA;
  • openscada-dbg — пакет отладки, содержит отладочную информацию бинарных файлов для отчёта и поиска ошибок в программе.

Второй набор представлен порядка пятьюдесятью пакетами, с выделением модулей OpenSCADA в отдельные пакеты:

  • openscada-core — содержит ядро OpenSCADA, базовую конфигурацию и запускающие файлы;
  • openscada-db-* — модули подсистемы "БД";
  • openscada-daq-* — модули подсистемы "Сбор данных";
  • openscada-arh-* — модули подсистемы "Архивы-История";
  • openscada-tr-* — модули подсистемы "Транспорты";
  • openscada-prot-* — модули подсистемы "Транспортные протоколы";
  • openscada-ui-* — модули подсистемы "Пользовательские интерфейсы";
  • openscada-spec-* — модули подсистемы "Специальные";
  • openscada — виртуальный пакет, содержащий зависимости для установки типовой конфигурации OpenSCADA;
  • openscada-plc — содержит зависимости, файл сценария, конфигурацию проекта ПЛК для запуска OpenSCADA в режиме сервиса-демона;
  • openscada-server — содержит зависимости, файл сценария и конфигурацию проекта сервера для запуска OpenSCADA в режиме сервиса-демона;
  • openscada-vis-station — виртуальный пакет, содержащий зависимости для установки типовой конфигурации OpenSCADA, как визуальная SCADA-станция.
  • openscada-libdb-main — основные библиотеки OpenSCADA для сбора данных и другого, в БД SQLite;
  • openscada-libdb-vca — библиотеки визуальных компонетов, в БД SQLite;
  • openscada-model-aglks — БД и конфигурация динамической модели реального времени "АГЛКС" (Демо: EN,UK,RU);
  • openscada-model-boiler — БД и конфигурация динамической модели реального времени "Котёл" (EN,UK,RU);
  • openscada-doc-en — offline документация OpenSCADA, английский язык;
  • openscada-doc-uk — offline документация OpenSCADA, украинский язык;
  • openscada-doc-ru — offline документация OpenSCADA, российский язык;
  • openscada-dev — пакет разработки, для отдельного создания модулей OpenSCADA;
  • openscada-dbg — пакет отладки, содержит отладочную информацию бинарных файлов для отчёта и поиска ошибок в программе.

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

Ручную установку DEB-пакетов первого набора можно осуществить командой, предварительно сменив рабочую директорию на директорию с пакетами:

$ dpkg -i openscada-libdb.main_0.9.0-1_all.deb openscada-libdb.vca_0.9.0-1_all.deb openscada-model.aglks_0.9.0-1_all openscada_0.9.0-1_i386.deb 

Ручную установку RPM-пакетов первого набора можно осуществить командой, предварительно сменив рабочую директорию на директорию с пакетами:

$ rpm -i openscada-LibDB.Main-0.9.0-alt1.noarch.rpm openscada-LibDB.VCA-0.9.0-alt1.noarch.rpm openscada-Model.AGLKS-0.9.0-alt1.i586.rpm openscada-0.9.0-alt1.i586.rpm 

At.png В процессе выполнения установки могут возникнуть ошибки, связанные с неудовлетворёнными зависимостями. При ручной установке из пакетов удовлетворять их нужно будет вручную, подобно установке пакетов OpenSCADA, или через менеджер пакетов дистрибутива Linux. Случаи наличия проблем зависимости могут быть даже при установке через пакетный менеджер, если используется репозиторий OpenSCADA, который не соответствует дистрибутиву Linux или его версии, или-же не подключены основные репозитории пакетов самого дистрибутива. В пакетном менеджере APT, для автоматического разрешения проблем внешних зависимостей, которые возникли при ручной установке OpenSCADA, можно использовать команду:

$ apt-get install -f

2.2 Установка-сборка из исходных текстов

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

3 Первичная конфигурация и запуск

Для наших основных задач с OpenSCADA, в рамках этого документа, нужно установить пакет с БД модели "АГЛКС" — openscada-model-aglks, про что можно детально узнать из предыдущего раздела. Конечно, если Вы используете живой диск то у Вас всё нужное уже есть.

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

Установленная БД модели "АГЛКС" не нуждается в предварительной настройке. Если-же нужно выполнить особую настройку, которая отличается от базовой, то воспользуйтесь руководством по программе. В процессе чего Вам может понадобиться информация про типовые учётные записи и пароли OpenSCADA (не имеют отношения к учётным записям ОС), хотя модели и ново-созданные конфигурации запускаются от привилегированного пользователя и Вы можете легко изменить любую из них:

  • Суперпользователь (root), пароль "openscada".
  • Обычный пользователь (user), пароль "user".
  • Пример отдельного пользователя (roman), пароль "roman".

Демонстрация OpenSCADA, на основе БД модели "АГЛКС", это не тоже, что обычно предоставляют коммерческие производители ПО с целью продемонстрировать возможности, но исключить или усложнить нормальную работу, путём ограничения функций. Демонстрация OpenSCADA это полно-функциональная программа, предоставляющая примеры реализации и настройки различных компонентов. На основе БД модели "АГЛКС", и других моделей OpenSCADA, можно легко создавать собственные проекты, используя предоставленные наработки. Полноценность демонстрации OpenSCADA имеет исключение для закрытых платформ и платформ с преобладанием закрытого ПЗ.

At.png Динамическая модель компрессорной станции на 6 газовых компрессоров, которая лежит в основе демонстрационной БД, требует заметных ресурсов, а именно — процессора с частотой более 1 ГГц (x86) и памяти до 200МБ. Данные вычислительные ресурсы требуются непосредственно для динамической модели и не являются общим показателем ресурсоёмкости программы в конечных задачах! Требования к памяти, наоборот, являются типовым показателем для графической станции АРМ похожей сложности.

Общий процесс конфигурации SCADA-системы, для исполнения функций верхнего уровня — АРМ оператора, можно условно разделить на два этапа:

  • Конфигурация источника данных, создание базы данных (БД) параметров этих источников и настройка истории.
  • Формирование визуального представления данных ТП, путём создания интерфейса оператора в виде: мнемосхем, групп графиков, групп контуров, документов и другое.

Итак, нашей конечной целью и целью этого документа является построение полноценной конфигурации локальной SCADA-станции, объединённую с сервером, и с эмуляцией источника данных на основе этой демонстрационной БД (Рис.3).

Рис. 3. Простое объединённое подключение станции и сервера SCADA с источником данных в демонстрационной БД.

По ходу, мы ознакомимся с такими важными ролями OpenSCADA как: сервер сбора, архивации, визуализации; среда исполнения ПЛК и удаленная разработка. Но перед этим мы осмотрим OpenSCADA и её возможности в целом.

3.1 Общий обзор

Запустить локальное исполнение OpenSCADA, с БД модели "АГЛКС", можно из меню окружения рабочего стола в разделе "Графика", пункт "Модель "АГЛКС" на открытой SCADA системе" с характерной иконкой (Рис.3.1.1).

Рис. 3.1.1. Пункт меню окружения рабочего стола для локального запуска демонстрации OpenSCADA.

Локальный запуск также можно осуществить из консоли, командой:

$ openscada_AGLKS 

После запуска мы получим окно графического конфигуратора OpenSCADA — QTCfg (Рис.3.1.2) с открытой корневой страницей. Демонстрационная БД специально настроена так, чтобы первым при запуске появлялось окно конфигуратора. В дальнейшем можно открыть окно разработки графических интерфейсов пользователя, а также запустить проект пользовательского интерфейса на исполнение.

Рис. 3.1.2. Программный конфигуратор OpenSCADA — QTCfg, корневая страница.

Программный конфигуратор OpenSCADA является основным и достаточным средством для конфигурации любого компонента OpenSCADA. Как и многие компоненты OpenSCADA, конфигуратор реализован в виде модуля. Кроме конфигуратора QTCfg доступны и другие конфигураторы, выполняющие те же функции, но реализованные на основе других технологий. Например, таковыми являются Web-конфигураторы: WebCfgD и WebCfg.

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

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

Рис. 3.1.3. Окно разработки пользовательского интерфейса.

Далее можем запустить проект "АГЛКС" на исполнение. Для этого выбираем его в перечне проектов и запускаем путём нажатия на первую слева иконку, на панели инструментов, или в контекстном меню. В результате чего получим окно интерфейса конечного пользователя — оператора (Рис.3.1.4).

Рис. 3.1.4. Окно конечного интерфейса пользователя проекта "AGLKS".

Построение и исполнение пользовательских интерфейсов осуществляется модулем Vision, подсистемы "Пользовательские интерфейсы". Кроме этого модуля ещё доступны иные модули визуализации. Например, OpenSCADA предоставляет модуль WebVision, который позволяет исполнять проекты, ранее разработанные в интерфейсе модуля Vision, посредством Web-технологий и стандартного Web-браузера.

Все действия в дальнейшем мы будем рассматривать только в интерфейсе модуля Vision.

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

At.png Закроем программу через соответствующий пункт меню "Файл", что нужно сделать обязательно, иначе её дальнейший фоновый запуск не сможет открыть портов, занятых уже этой программой.

3.2 Фоновое и удалённое выполнение — сервер, среда исполнения ПЛК и удалённая разработка

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

Для запуска OpenSCADA в фоновом режиме исполнения нам нужно установить пакет openscada-server, как это описано в разделе установки и который уже будет установленный в случае живого диска. После установки этого пакета мы должны, в консоли-терминале (например, программа "konsole" в окружении живого диска через диалог запуска Alt+F2) и от суперпользователя, осуществить следующие действия:

# Подключиться от суперпользователя
$ su -
# ... для живого диска и некоторых других окружений Linux
$ sudo bash
# Остановить исполнение пустой конфигурации сервера
$ service openscada-server stop
# Создать ссылку серверного проекта на "АГЛКС"
$ rm -R /usr/share/openscada/server
$ ln -s AGLKS /usr/share/openscada/server
$ ln -s /etc/oscada_AGLKS.xml /usr/share/openscada/server/oscada.xml
# Запустить сервер уже с демонстрационной БД
$ service openscada-server start

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

Если-же у Вас все-же возникли проблемы при работе с консолью-терминалом или Вы сознательно хотите фонового исполнения в графическом окружении — так называемого "запуска или закрытия в системный лоток", тогда Вы, на этой стадии, можете снова запустить демонстрационную конфигурацию, как описано в начале этого раздела (Рис.3.1.1), установить параметр Сворачивать или запускать в системный лоток, модуля UI.QTStarter, и закрыть окно конфигуратора, чтобы проект модели АГЛКС свернулся в системный лоток.

3.3 Создание собственного проекта

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

$ openscada
Рис. 3.3. Окно менеджера проектов OpenSCADA.

В этом окне мы также можем проверить фоновое исполнение серверной и демонстрационной конфигураций.

А именно, нажмём соответствующую кнопку Создать-обновить проект и введём название нового проекта, например — Start.

3.3.1 Подключение и использование удалённых и фоновых конфигураций

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

На странице транспортов (Рис.3.3.1.1), в режиме Пользовательский и Системный, создадим подключение к нашей фоновой демонстрации "AGLKS", как станции OpenSCADA. Укажем там транспорт Сокеты, адрес TCP:localhost:10005, пользователя root и пароль openscada. После обновления дерева навигации конфигуратора, командой в контекстном меню, мы должны получить новый корневой пункт этого подключения и сможем контролировать удалённую-фоновую станцию с этого конфигуратора.

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

Если всё работает то сохраним эту конфигурацию, нажав вторую иконку слева на панели инструментов наверху, поскольку мы ещё воспользуемся ею для прямого шлюзования параметров сбора данных из демонстрационного проекта, как ПЛК.

Рис. 3.3.1.1. Страница транспортов внешних станций OpenSCADA и обзор дерева OpenSCADA удалённой-фоновой станции.

На странице конфигурации визуализатора UI.Vision (Рис.3.3.1.2) выберем:

  • станцию движка СВУ — AGLKS;
  • пользователя запуска — оставим пустым;
  • пароль пользователя этой удалённой станции — оставим пустым;
  • проект(и) для их автоматического исполнения — также оставим пустым, поскольку мы хотим увидеть возможность удалённой разработки.
Рис. 3.3.1.2. Страница конфигурации визуализатора UI.Vision.

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

Рис. 3.3.1.3. Экран удалённой разработки UI.Vision для сервера визуализации "АГЛКС".
Рис. 3.3.1.4. Экран удалённого исполнения UI.Vision для сервера визуализации "АГЛКС".

At.png Эту конфигурацию удалённого подключения к серверу визуализации сохранять не нужно и поле конфигурации "Станция движка СВУ" (Рис.3.3.1.2) нужно вернуть в Local, а пользователя станции установить в root; только после чого сохранить.

Возможность удалённого подключения и разработки иногда является единственным способом осуществить разработку или корректировку не только для серверных конфигураций исключительно с WEB-интерфейсом, но и для конфигураций с локальною визуализацией, когда само окружение локальной визуализации непригодное или ограниченное для исполнения среды разработки модуля UI.Vision, например, таких как смартфоны, планшеты, и другие мобильные устройства с малым экраном, исключительно сенсорным вводом (Android) или ограничениями, вроде невозможности открытия системной виртуальной клавиатуры (Nokia N9). И эту удалённую разработку в основном можно осуществлять в процессе исполнения проекта — горячая разработка, что особенно актуально для Web-интерфейсов и локальных интерфейсов, которые запускаются только в окне исполнения. Что качается удалённой конфигурации то на один локальный конфигуратор, как центр администрирования, можно собрать все удалённые станции в сети, включая станции в скрытых сетях станций первого уровня, поднять которые можно аргументом "Уровень поднятия" (Рис.3.3.1.1).

3.3.2 Подключение стандартных библиотек OpenSCADA

Ново-созданный проект OpenSCADA не содержит никакой специфической конфигурации, по факту является пустым и предусматривает создание пользователем новой конфигурации в локальном файле БД SQLite "St.db", который располагается в собственном каталоге проекта с таким-же названием. Создавать сложный проект SCADA-системы проще с использованием библиотек функций API объектной модели OpenSCADA и библиотек графических элементов, а также других библиотек OpenSCADA. Для использования библиотек OpenSCADA нужно файлы БД, где они хранятся: подключить — добавить в объекте модуля БД "SQLite" (Рис.3.3.2.1), установить-выбрать адрес и указать кодировку БД в UTF-8 (Рис.3.3.2.2).

Рис. 3.3.2.1. Добавление объекта БД "SQLite".
Рис. 3.3.2.2. Объект БД "SQLite" библиотеки OpenSCADA.

Дистрибутивы OpenSCADA поставляются с рядом библиотек в виде файлов БД "SQLite" (таблица 3.3.2), которые, при запуске-создании пользовательского проекта, помещаются в каталоге "LibsDB/". Согласно этому перечню добавляем их все в объекте модуля БД "SQLite", устанавливаем им флаг "Включать" и сохраняем. Далее, для загрузки содержимого библиотек, можно включить БД и нажать кнопку "Загрузить программу с этой БД", однако, при загрузке ряд новых объектов не включится (команда загрузки), поэтому проще завершить новый проект и запустить его сначала, чем включать всё нужное вручную.

Таблица 3.3.2. Библиотеки OpenSCADA в составе дистрибутива.

ID Имя Адрес Язык/кодировка
OscadaLibs Библиотеки функций LibsDB/OscadaLibs.db EN,UK,RU/UTF-8
vcaBase СВУ: Главные библиотеки LibsDB/vcaBase.db EN,UK,RU/UTF-8
vcaTest СВУ: Тесты LibsDB/vcaTest.db EN,UK,RU/UTF-8
vcaElectroEls СВУ: Библиотека электро-элементов мнемосхем пользовательского интерфейса LibsDB/vcaElectroEls.db EN,UK,RU/UTF-8

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

4 Работа с источниками данных

Основной функцией любой SCADA-системы является работа с источниками данных реального времени, а именно опрос программируемых логических контроллеров (ПЛК) и простых модулей УСО. Детальнее ознакомиться с этим вопросом можно в документе "Сбор данных в OpenSCADA".

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

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

4.1 Сбор данных аппарата ТП

В качестве примера рассмотрим и создадим сбор данных для аппарата воздушного холодильника. Фоновая демонстрационная БД, как ПЛК и источник данных, содержит модель реального времени ТП компрессорной станции из шести компрессоров. Данные для двух аппаратов воздушных холодильников "AT101_1" и "AT101_2" компрессорной станции "KM101" доступны по протоколу ModBus/TCP на порту 10502 (стандартно этот порт 502, при наличии доступа его открыть).

Создадим объект контроллера для сбора по протоколу ModBUS/TCP и получим эти данные. Тем самым фактически реализуем задачу сбора реальных данных, поскольку наша конфигурация будет отличаться от работы с настоящим внешним устройством только его адресом и адресами регистров ModBUS, а также это может быть другой физический интерфейс взаимодействия — вариант протокола ModBus. Это подключение также является ярким примером возможности реализации среды исполнения источника данных (ПЛК) на основе OpenSCADA.

Для сбора данных по протоколу "ModBUS" в OpenSCADA присутствует модуль "ModBus" подсистемы "Сбор данных". Для добавления нового объекта контроллера в конфигураторе откроем страницу модуля "ModBUS" ("Start"->"Сбор данных"->"Модуль"->"ModBus") и в контекстном меню пункта "ModBus" нажмём "Добавить" (риc.4.1.1).

Рис. 4.1.1. Добавление объекта контроллера в модуле "ModBus" подсистемы "Сбор данных".

В результате появится окно диалога (Рис.4.1.2) с предложением ввести идентификатор и имя нового объекта контроллера. Идентификаторы любых объектов в OpenSCADA ограничены размером в 20 символов и их рекомендуется вводить символами английского алфавита и цифрами. Кроме того, начинать идентификатор желательно с буквы, что упростит его использование во внутренних процедурах. Имена объектов OpenSCADA ограничены размером в 50 символов, которые могут быть любыми. Имя обычно используются для отображения и если оно пустое то будет использоваться идентификатор. В последствии, имя мы можем поменять в конфигурации объекта, но идентификатор невозможно изменять прямо; однако объект можно вырезать (Ctrl+X) и затем вставить (Ctrl+V), тем самым переименовав его. Введём, согласно замечаниям ранее, идентификатор "CM101", имя "KM 101" — CM101 (KM 101).

Рис. 4.1.2. Диалог указания идентификатора и имени нового объекта.

После подтверждения у нас появится объект нового контроллера. Выберем его в конфигураторе и ознакомимся с настройками (Рис.4.1.3).

Рис. 4.1.3. Главная вкладка настройки объекта контроллера модуля ModBus.

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

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

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

В разделе "Конфигурация", непосредственно содержится конфигурация объекта контроллера. Установим следующие из них, оставив все остальные без изменения::

  • "Включать" и "Запускать" указывают на то, в какое состояние переводить объект контроллера при запуске программы. Установим оба поля.
  • "Планирование сбора" содержит конфигурацию планировщика для запуска задачи сбора данных. Получить описание формата конфигурации данного поля можно из всплывающей подсказки. Одиночное число указывает на периодичность запуска, в секундах. Укажем одну секунду.
  • "ModBus протокол" указывает на вариант протокола ModBus. Возможны варианты протокола "TCP/IP", "RTU" и "ASCII". На данный момент нас интересует вариант TCP/IP, поэтому оставим как есть. Варианты протоколов "RTU" и "ASCII" нужно устанавливать в случае связи с контроллером посредством последовательных интерфейсов, часто это "RS-485".
  • "Адрес транспорта" указывает на исходящий транспорт подсистемы "Транспорты", который используется для соединения с контроллером. В случае с вариантом "TCP/IP" нам нужен транспорт в модуле Sockets, а в случае вариантов "RTU", "ASCII" и последовательного интерфейса нам нужен транспорт в модуле Serial. На создании исходящего транспорта в "Sockets" и "Serial" детальнее остановимся ниже.
  • "Узел назначения" указывает на узел источника данных или контроллера в сети ModBus. В нашем случае это должно быть 1.
  • "Объединять фрагменты данных" включает объединение несмежных фрагментов регистров в один блок запроса, до указанного ниже количества байтов, вместо генерации отдельных запросов. Позволяет уменьшить общее время сбора. Установим эту опцию.

Сохраним наши изменения в БД, нажав вторую слева иконку на панели инструментов.

Теперь, таким образом как и объект контроллера, создадим выходной транспорт в модуле "Sockets" ("Start"->"Транспорты"->"Сокеты"), посредством контекстного меню (Рис.4.1.4) и назовём транспорт так как и объект контроллер: CM101 (KM 101). Обратите внимание, что в поле "Тип элемента", диалога ввода идентификатора и имени (Рис.4.1.2), нужно выбрать Выходной транспорт!

Рис. 4.1.4. Добавление выходного транспорта в модуле "Sockets" подсистемы "Транспорты".

Страница конфигурации полученного выходного транспорта приведена на рисунке 4.1.5. Эта страница также содержит раздел состояния и оперативного управления. В поле "Статус" содержится текстовое описание текущего состояния транспорта. Мы можем запустить его на исполнение, установив флажок напротив соответствующего поля. Выполняющийся объект транспорта инициирует соединение с внешним узлом. Поле "БД транспорта" указывает на то, в какой БД хранить конфигурацию данного объекта. Нас устроит главное хранилище.

Рис. 4.1.5. Страница конфигурации выходного транспорта модуля "Sockets" подсистемы "Транспорты".

В разделе "Конфигурация" непосредственно содержится конфигурация объекта транспорта. Установим следующие из них, оставив все остальные без изменения:

  • "Адрес" указывает на: тип, адрес и режим соединения с удалённой станцией. Ознакомиться с форматом записи можно из всплывающей подсказки. Установим это поле в значение TCP:localhost:10502.

Транспорты других типов создаются подобно методу, рассмотренному для "Sockets", а конфигурация их отличается обычно только форматом записи адреса и таймаутов. В случае с транспортом модуля "Serial" в адресе указывается: путь к последовательному устройству, скорость и формат. Для конвертеров USB->Serial,Modem этот адрес можно узнать из операционной системы, например, консольной командой $ dmesg, сразу после его подключения.

Сохраним объект транспорта и вернёмся к конфигурационному полю "Адрес транспорта" объекта контроллера, где выберем адрес "Sockets.CM101". На этом настройка объекта контроллера закончена, включим его, установив флаг "Включен". Следующим этапом является конфигурация и выбор тех данных, которые нужно опрашивать из контроллера. Эта настройка производится путём создания параметра контроллера. Параметр позволяет описать перечень данных, получаемых у контролера и передать их в окружение OpenSCADA — модель данных.

Для добавления нового параметра откроем страницу нашего объекта контроллера и, в контекстном меню пункта "KM 101 (CM101)", нажмём "Добавить". Параметр назовём: AT101_1 (AT 101_1).

Страница конфигурации полученного параметра приведена на рисунке 4.1.6. Эта страница содержит раздел состояния и оперативного управления. В поле "Тип" содержится идентификатор типа параметра, в нашем случае это Стандартный (std). Параметр мы включаем, установив флажок напротив соответствующего поля. Включенный параметр участвует в процессе обмена с контроллером.

Рис. 4.1.6. Страница конфигурации параметра контроллера "ModBUS".

В разделе "Конфигурация" непосредственно содержится конфигурация параметра. Установим следующие из них, оставив все остальные без изменения:

  • "Включать" указывает на необходимость перевода объекта в режим "Включен", при запуске программы. Установим это поле.
  • "Перечень атрибутов" содержит конфигурацию атрибутов параметра относительно к регистрами и битами "ModBus". Ознакомиться с форматом записи можно из всплывающей подсказки. Установим содержимое этого текстового поля в:
R:100:r:Ti:T вход
R:101:r:To:T выход
R:102:rw:Cw:Производительность

Таким же образом создадим, или скопируем из AT101_1, второй параметр: "AT101_2 (AT 101_2)". Перечень атрибутов для него установим в:

R:103:r:Ti:T вход
R:104:r:To:T выход
R:105:rw:Cw:Производительность

Сохраним оба параметра. Теперь мы можем запустить наш объект контроллера для осуществления сбора, для чего вернёмся на его страницу и, в разделе "Состояние", установим флажок "Выполняется". Если мы ничего не пропустили то обмен успешно запустится и в поле "Статус" мы получим подобное представленному на рисунке 4.1.7.

Рис. 4.1.7. Страница объекта контроллера при успешном обмене с физическим контроллером.

В случае успешного обмена с физическим контроллером мы также получим описанные данные контроллера в инфраструктуре (модели данных) OpenSCADA. Увидеть эти данные можно во вкладке "Атрибуты" наших параметров AT101_1 (Рис.4.1.8) и AT101_2. Поскольку сбор производится регулярно и с периодичностью в секунду, то мы можем наблюдать их изменение, нажимая кнопку "Обновить текущую страницу" на панели инструментов.

Рис. 4.1.8. Страница описанных атрибутов параметра AT101_1.

На этом конфигурация сбора данных считается законченной.

4.2 Обработка полученных данных ТП

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

Вычисления в подсистеме "Сбор данных", для получения реальных данных, в основном выполняются посредством модуля логического уровня LogicLev и шаблонов параметров подсистемы "Сбор данных". Модуль "ModBus" является тем редким случаем, когда такое вычисление можно сделать прямо в нём, что мы ниже увидим. Детальнее ознакомиться с концепцией "Логического уровня" можно по ссылке.

Для выполнения вычислений в модуле логического уровня нужно предварительно создать библиотеку шаблонов нашего проекта и шаблон параметра подсистемы "Сбор данных" в ней. Для создания библиотеки шаблонов откроем страницу подсистемы "Сбор данных" и, посредством контекстного меню, создадим объект библиотеки шаблонов "start (Запуск)". Страница конфигурации полученного объекта библиотеки шаблона (Рис.4.2.1) содержит раздел состояния и оперативного управления "Состояние" и раздел настроек "Конфигурация" в котором содержатся только типовые поля конфигурации и которые оставим неизменными. В целом мы имеем:

  • Раздел "Состояние":
    • сделать библиотеку доступной, установив флажок напротив соответствующего поля;
    • указать хранилище в поле "БД библиотеки", оставим по умолчанию — основную БД проекта;
    • можем проконтролировать дату последней модификации.
  • Сохранить объект.
Рис. 4.2.1. Страница конфигурации объекта библиотеки шаблонов.

Для создания шаблона откроем страницу ново-созданной библиотеки шаблонов ("Start"->"Сбор данных"->"Библиотека шаблонов"->"Запуск") и, посредством контекстного меню, создадим объект шаблона airCooler (Воздушный холодильник). Страница конфигурации полученного объекта шаблона (Рис.4.2.2) содержит раздел состояния и оперативного управления "Состояние" и раздел настроек "Конфигурация" в котором содержатся только типовые поля конфигурации и которые оставим неизменными. В целом мы имеем:

  • Раздел "Состояние":
    • сделать шаблон доступным, установив флажок напротив соответствующего поля — доступные шаблоны могут подключаться к параметрам сбора данных, а параметры будут выполнять вычисления по этому шаблону;
    • можем проконтролировать число объектов, которые используют данный шаблон для вычисления контекста параметра;
    • можем проконтролировать дату последней модификации.
  • Сохранить объект.
Рис. 4.2.2. Страница конфигурации объекта шаблона.

Основная конфигурация и формирование шаблона параметра сбора данных осуществляется во вкладке "ВВ" (Рис.4.2.3) шаблона. Детальное описание процесса формирования шаблона можно получить по ссылке.

В шаблоне создадим два свойства для входов ("TiCod", "ToCod"), два для выходов результата ("Ti","To") и один прозрачный ("Cw"). Свойствам "TiCod", "ToCod" и "Cw" установим флаг "Конфигурация" в Связь, что позволит подвязывать к ним "сырой" источник. Параметрам "Ti" и "To", флаг "Атрибут" установим в Только чтение, "Cw" в Полный доступ; для формирования трёх атрибутов результирующего параметра сбора данных: два только на чтение и один на полный доступ.

Установим язык программы в JavaLikeCalc.JavaScript, а программу в:

Ti = 150*TiCod/65536;
To = 100*ToCod/65536;
Рис. 4.2.3. Вкладка "ВВ" страницы конфигурации объекта шаблона.

Cохраним полученный шаблон и установим флаг доступности (Рис.4.2.2).

Теперь создадим объект контроллера и параметры в модуле "LogicLev" подсистемы "Сбор данных". Объект контроллера "LogicLev" и его параметры создаются идентично ранее созданным в модуле "ModBus", на странице: "Start"->"Сбор данных"->"Модуль"->"Логический уровень". Назовём их идентично объектам модуля "ModBus".

Объект контроллера модуля "LogicLev" (Рис.4.2.4) не имеет специфических настроек и установленные по умолчанию можно не трогать, кроме поля "Планирование вычисления", которое установим в одну секунду. Перед добавлением параметров нужно включить объект контроллера, установив флаг "Включен".

Рис. 4.2.4. Главная вкладка настройки объекта контроллера модуля "LogicLev".

Параметр объекта контроллера модуля "LogicLev" (Рис.4.2.5) из специфических настроек имеет "Тип", где нужно установить Логический (std), а в поле "Шаблон параметра" выбрать адрес созданного нами шаблона.

Рис. 4.2.5. Страница конфигурации параметра объекта контроллера модуля "LogicLev".

Кроме базовой конфигурации параметра нужно сконфигурировать и подключенный шаблон (Рис.4.2.6). Вкладка конфигурации шаблона появляется в режиме параметра "Включен". Включить параметр можно, включив предварительно объект контроллера. Флаг "Показывать только атрибуты" позволяет устанавливать отдельно каждую связь (Рис.4.2.7). Поскольку мы, в шаблоне, предусмотрительно описали формат связей в виде "Параметр|Ti", то все три связи мы можем установить просто указав адрес к параметру в объекте контроллера "ModBus". Укажем-выберем адрес ModBus.CM101.AT101_1 и ModBus.CM101.AT101_2, в соответствующих параметрах.

Нужно отметить, что все поля ввода адресов объектов в OpenSCADA снабжены механизмом набора адреса. Данный механизм подразумевает поэлементный выбор, в процессе которого происходит движение в глубь. Например, при наборе адреса "ModBus.CM101.AT101_1", вначале мы будем иметь возможность выбора типа источника данных, среди которых будет "ModBus". Выбрав пункт "ModBus", в перечень доступных элементов для выбора добавятся объекты контроллера модуля "ModBus", среди которых будет "ModBus.CM101". Выбор элемента "ModBus.CM101" добавит параметры контроллера, и т.д. до конечного элемента, согласно иерархии объектов. Для возможности возврата на уровни выше, в список выбора вставляются элементы всех вышестоящих уровней от текущего значения адреса.

Рис. 4.2.6. Вкладка "Конфигурация шаблона" страницы параметра контроллера "LogicLev".
Рис. 4.2.7. Вкладка "Конфигурация шаблона" страницы параметра контроллера "LogicLev" с разворотом связей.

Сохраним созданные объекты контроллера и параметров, после чего запустим объект контроллера на исполнение, установив флаг "Выполняется" в разделе "Состояние". Если мы ничего не пропустили, то вычисление успешно запустится и в поле "Статус" мы получим похожее на рисунке 4.2.8.

Рис. 4.2.8. Страница объекта контроллера при успешном его вычислении в модуле "LogicLev".

В случае успешной обработки кода шаблона, в параметрах, мы получим обработанные данные в инфраструктуре (модели данных) OpenSCADA. Увидеть эти данные можно на вкладке "Атрибуты" наших параметров AT101_1 (Рис.4.2.9) и AT101_2.

Рис. 4.2.9. Страница атрибутов параметра AT101_1 модуля "LogicLev".

На этом конфигурацию обработки данных считаем законченной.

4.3 Комплексный объект-тег сигнала

В предыдущих разделах был описан механизм подключения источника данных по объекту аппарата — "Воздушный холодильник", который предусматривает объединение всех сигналов в одном объекте параметра источника данных. Однако более распространённым подходом крупной автоматизации является формирование объекта параметра вокруг отдельного сигнала, например — "Температура на выходе холодильника AT101_1 (TE1314_1)", которые часто называются тегами.

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

Обычно, для формирования параметра на основе шаблона, используется модуль логического уровня LogicLev, как это было описано в предыдущем разделе. Однако ряд модулей, в том числе и ModBus предоставляют возможность сразу создавать логические параметры, на основе шаблона. Добавим новые параметры, открыв в конфигураторе страницу нашего, ранее созданного, объекта контроллера "ModBus" и в контекстном меню пункта "КМ 101 (CM101)" нажмём "Добавить".

Назовём аналоговый параметр TE1314_1 (TE1314_1), (Рис.4.3.1). Тип параметра установим в Логический (logic), шаблон параметра выберем base.anUnif, описание установим в Температура на выходе AT101_1, установим флажки "Включать" и "Включен". Далее, нам нужно настроить:

  • Шаблон параметра, в появившейся вкладке "Конфигурация шаблона" (Рис.4.3.2):
    • поле "Вход" устанавливаем в значение адреса ModBus-регистра этого параметра R:101;
    • поле "Максимум шкалы модуля" устанавливаем в значение 65535, что соответствует 100 °C.
  • Установки вкладки "Атрибуты" (Рис.4.3.3):
    • "Ед. измерения" устанавливаем в град. С;
    • "Шкала:минимум" в 0;
    • "Шкала:максимум" в 100;
    • "Граница верхняя ав." в 40;
    • "Граница верхняя пред." в 30.
  • Сохраним объект.
Рис. 4.3.1. Страница логического параметра "TE1314_1" модуля "ModBus".
Рис. 4.3.2. Вкладка "Конфигурация шаблона" страницы параметра "TE1314_1" модуля "ModBus".
Рис. 4.3.3. Вкладка "Атрибуты" страницы параметра "TE1314_1" модуля "ModBus".

Дискретный параметр назовём: CB102 (КШ102). Тип параметра установим в Логический (logic), шаблон параметра выберем base.digitBlockUnif, установим флажки "Включать" и "Включен". Далее нам нужно настроить:

  • Шаблон параметра, в появившейся вкладке "Конфигурация шаблона" (Рис.4.3.4):
    • поле "Команда 'Открыть'" устанавливаем в значение адреса ModBus-бита этого параметра C:100:rw;
    • поле "Состояние 'Открыт'" устанавливаем в значение адреса ModBus-бита C:101;
    • поле "Состояние 'Закрыт'" устанавливаем в значение адреса ModBus-бита C:102;
    • поле "Время удерж. команды" устанавливаем в 0 поскольку команда не импульсная.
  • Установки вкладки "Атрибуты" (Рис.4.3.5): удостоверяемся в доступности команды и состояний.
  • Сохраним объект.
Рис. 4.3.4. Вкладка "Конфигурация шаблона" страницы параметра "CB102" модуля "ModBus".
Рис. 4.3.5. Вкладка "Атрибуты" страницы параметра "CB102" модуля "ModBus".

4.4 Получение готовых данных OpenSCADA — шлюзование

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

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

OpenSCADA предусматривает возможность такой унификации через добавление родственности с ПЛК. И такую родственность можно обеспечить только для ПЛК, которые являются полностью открытыми, на них установлено открытое-свободное ПО, а соответственно можно установить и OpenSCADA в роли среды исполнения ПЛК. Как среда исполнения, OpenSCADA может предоставлять данные ПЛК и стандартными протоколами, как ModBus, но, для получения этих данных прямо и без осуществления каких либо действий над ними, на стороне SCADA-системы предусмотрен модуль "DAQGate", который, по факту, объединяет модели. Т.е., фактически, программист ПЛК, который по совместительству является программистом SCADA, формирует модель данных ПЛК, а на уровне SCADA-системы она используется уже как готовая, чем полностью убирается стадия и работы с получения, обработки и формирования модели данных SCADA-системы. Более того:

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

С целью демонстрации и ознакомления, создадим тут объект контролера модуля "DAQGate", для шлюзования данных нашего виртуального ПЛК. Создаётся он идентично к ранее созданным объектам контролера в модуле "ModBus" и "LogicLev", на странице: "Start"->"Сбор данных"->"Модуль"->"Шлюз источников данных" и назовём его AGLKS.

Объект контроллера модуля "DAQGate" (Рис.4.4.1) имеет следующие специфические настройки, которые мы должны осуществить:

  • "Перечень удалённых станций" — в поле "Добавление станции" выберем ранее созданное подключение удалённой станции "AGLKS".
  • Включим объект контролера.
  • "Перечень удалённых контроллеров и параметров" — в поле "Дерево параметров" выберем LogicLev.experiment, а затем пункт <<Добавить текущий>> вверху этого списка.
  • Запустим исполнение объекта контроллера.
Рис. 4.4.1. Главная вкладка настройки объекта контроллера модуля "DAQGate".

Если всё сделано правильно то автоматически создадутся параметры выбранного контроллера и мы сможем посмотреть на данные в них на вкладке "Атрибуты" (Рис.4.4.2).

Рис. 4.4.2. Вкладка "Атрибуты" страницы параметра модуля "DAQGate".

4.5 Архивирование-история данных ТП

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

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

Начнём с архивации значений, для которой нужно создать хотя-бы один архиватор для нужного типа хранилища и периодичностью значений. Вообще, OpenSCADA содержит два модуля архивации: на файловую систему "FSArch" и на базу данных "DBArch". Тут мы рассмотрим только модуль архивации на файловую систему, как наиболее универсальный и эффективный. Что касается периодичности значений, для "качественного" архиватора, то её, в основном, нужно выбирать по периодичности значений самого медленного источника данных в нашей системе, который у нас один и периодичность мы ему указали 1 секунда. Для создания архиватора значений откроем страницу модуля архивирования ("Start"->"Архивы-История"->"Модуль"->"Архиватор на файловую систему") и, посредством контекстного меню, создадим объект архиватора значений 1s. Обратите внимание на значение поля "Тип элемента" диалога создания, которое должно быть Архиватор значений! Страница конфигурации полученного объекта архиватора значений (Рис.4.5.1) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:

  • Раздел "Состояние":
    • запустить архиватор на исполнение, установив флажок напротив соответствующего поля — только выполняющийся архиватор осуществляет архивирование; At.png установить в последнюю очередь и после выполнения всего этого списка;
    • можем проконтролировать текущее и максимальное время сеанса архивирования;
    • указать хранилище конфигурации в поле "БД архиватора", оставим основную БД проекта, по умолчанию;
    • можем проконтролировать общий размер файлов архива этого архиватора.
  • Раздел "Конфигурация":
    • установить запуск архиватора при запуске программы, установив флажок напротив соответствующего поля;
    • установить адрес директории с файлами архива в ARCHIVES/VAL/1s, что ставится по умолчанию;
    • установить период значений в 1 секунду;
    • установить период архивирования в 60 секунд, по умолчанию; обычно одинаков для архиваторов с любой периодичностью значений.
  • Сохранить объект.
Рис. 4.5.1. Конфигурация архиватора значений "1s" на файловую систему.

Одного "качественного" архиватора уже достаточно для большинства задач, но если Вы планируете строить графики-тренды значений и отчётные документы на большую глубину (сутки, недели, месяца) то нужно создать ещё пару архиваторов с большей периодичностью значений. Иначе построение графиков и документов будет продолжительным и/или будет обрезаться по лимитам времени исполнения! Обычно, в качестве таких дополнительных архиваторов создаются, и Вы должны их создать идентично инструкции для "качественного" архиватора выше:

  • Минутный: идентификатор 1m, адрес ARCHIVES/VAL/1m и период значений 60 секунд.
  • Часовой: идентификатор 1h, адрес ARCHIVES/VAL/1h и период значений 3600 секунд.

Для включения архивирования атрибутов "Ti" и "To" параметров AT101_1 и AT101_2, в ранее созданном объекте контроллера модуля "LogicLev", достаточно на вкладке "Архивация" страницы параметров выбрать, какие атрибуты архивировать и какими архиваторами (Рис.4.5.2). Выберем архивацию атрибутов "Ti" и "To" ранее созданными архиваторами FSArch.1s, FSArch.1m, FSArch.1h. Тоже самое сделаем для атрибута "var" аналогового параметра "ModBus.CM101.TE1314_1" и "com" дискретного параметра "ModBus.CM101.CB102".

Рис. 4.5.2. Вкладка "Архивация" параметра AT101_1 модуля "LogicLev".

В результате этой операции будут автоматически созданы объекты архивов для выбранных атрибутов. Пример объекта архива, для атрибута "Ti" параметра AT101_1, представлен на рисунке 4.5.3.

Рис. 4.5.3. Страница объекта архива атрибута "Ti" параметра AT101_1.

Обычно, настройки архива менять не нужно, однако, если потребуется особая конфигурация, то её можно сделать на указанной выше странице. Чаще может понадобиться получение информации об архиве. Например, узнать размер архива как по времени, так и на носителе, а также взглянуть на график параметра (Рис.4.5.4).

Рис. 4.5.4. Вкладка "Значения" страницы объекта архива атрибута "Ti" параметра AT101_1.

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

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

Соответственно, создадим архиватор сообщений для архивации нарушений, для чего откроем страницу модуля архивирования ("Start"->"Архивы-История"->"Модуль"->"Архиватор на файловую систему") и, посредством контекстного меню, создадим объект архиватора сообщений alarms (Нарушения). Обратите внимание на значение поля "Тип элемента" диалога создания, которое должно быть Архиватор сообщений! Страница конфигурации полученного объекта архиватора значений (Рис.4.5.5) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:

  • Раздел "Состояние":
    • запустить архиватор на исполнение, установив флажок напротив соответствующего поля — только выполняющийся архиватор осуществляет архивирование; At.png установить в последнюю очередь и после выполнения всего этого списка;
    • указать хранилище конфигурации в поле "БД архиватора", оставим основную БД проекта, по умолчанию;
    • можем проконтролировать время первого и последнего сообщения в архиве этого архиватора;
    • можем проконтролировать общий размер файлов архива этого архиватора;
    • можем проконтролировать текущее и максимальное время сеанса архивирования.
  • Раздел "Конфигурация":
    • установить запуск архиватора при запуске программы, установив флажок напротив соответствующего поля;
    • установить категорию сообщений, которая характеризует нарушения, в al*;
    • установить уровень архивируемых нарушений в Информация (1);
    • установить адрес директории с файлами архива в ARCHIVES/MESS/alarms, что ставится по умолчанию;
  • Сохранить объект.
Рис. 4.5.5. Конфигурация архиватора сообщений "alarms" на файловую систему.

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

5 Формирование визуального представления

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

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

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

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

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

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

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

Скопируем проект "Группы сигнализации (шаблон)", нажав сначала кнопку "Копировать визуальный элемент" на нём, а затем кнопку "Вставить визуальный элемент" (Рис.5.1). В диалоге назовём наш новый проект start (Старт) и в списке проектов получим пункт нашего нового проекта (Рис.5.1).

Рис. 5.1. Копирование шаблонного проекта в новый.

Перед использованием и сохранением нового проекта (Рис.5.3) нужно изменить адрес его хранилища на главную БД *.*.prj_start, что мы можем сделать на главной странице диалога свойств визуального элемента, вызываемого по кнопке "Свойства визуального элемента" (Рис.5.2). После чего сохраним наш новый проект, нажав третью кнопку слева панели инструментов.

Рис. 5.2. Свойства нового проекта на основе шаблонного.

Шаблонный проект (Рис.5.3) содержит две ветви: "Панели управления" и "Корневая страница". Ветвь "Панели управления" содержит набор кадров типовых панелей управления и специализированных кадров. Ветвь "Корневая страница", с корневой страницей в основе, содержит подветви объектов сигнализации "Группа 1", "Группа 2" и отдельную ветвь сводных графиков "Сводные графики". Подветви объектов сигнализации "Группа {n}" имеют цифровой идентификатор и могут расширяться добавлением вплоть до 20. Присутствие подветви "Группа {n}" отражается на активации соответствующей кнопки объекта сигнализации корневой страницы, что позволяет на них переключаться. Каждая подветвь "Группа {n}" содержит контейнеры или шаблоны видов отображения, обычно: "Мнемосхемы", "Группы графиков", "Группы контуров", "Группы обзорных кадров" и "Документы". Наличие страниц в контейнерах отображений включает возможность выбора этого отображения, для соответствующего объекта сигнализации корневой страницы. Детальнее ознакомиться со структурой корневой страницы можно по ссылке.

Рис. 5.3. Шаблонный проект на основе концепции объектов сигнализации.

5.1 Добавление шаблонной страницы и подключение динамики

Рассмотрим задачу первого уровня сложности, когда к уже разработанной концепции интерфейса нужно подключить динамику шаблонной страницы. Понятие "Шаблон страницы" подразумевает страницу, на основе которой, и путём наследования, может создаваться множество конечных страниц визуализации с индивидуальным перечнем динамики. Примером таких страниц являются: "Группа графиков", "Группа контуров", "Группа обзорных кадров" и "Сводные графики". На Рис.5.1.1 представлена шаблонная страница "Группа графиков" в дереве нашего проекта "Старт".

Рис. 5.1.1. Шаблонная страница "Группа графиков".

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

Создадим новую группу графиков в шаблонном контейнере "Группа графиков" первой группы корневой страницы. Для этого, в контекстном меню пункта "Группа графиков", выберем пункт меню "Добавить визуальный элемент" (Рис.5.1.2). Для ввода идентификатора и имени нового визуального элемента появится диалог их ввода (Рис.5.1.3). Введём идентификатор "2" и имя "Графики 2" — 2 (Графики 2).

Рис. 5.1.2. Добавление группы графиков "Графики 2".
Рис. 5.1.3. Диалог ввода идентификатора и имени.

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

Рис. 5.1.4. Диалог редактирования свойств визуального элемента.

После включения страницы можно приступать к установке связей на созданные ранее параметры контроллеров. Для этого, не покидая диалога редактирования свойств только что созданной страницы (Рис.5.1.4), перейдём на вкладку "Связи" (Рис.5.1.5). На этой вкладке мы увидим дерево с элементами "el1" ... "el8". Развернув любой из элементов мы увидим ветвь "Parameter", и именно в ней мы должны указать или выбрать адрес наших атрибутов "Ti" и "To". Итого заполним четыре элемента, но в процессе этого часть свойств нужно указывать как постоянные:

  • "name" — val:AT101_1 Ti.
  • "ed" — val:град.С.
  • "max" — val:150 (для Ti) и val:100 (для To).
  • "min" — val:0.

Если в шаблоне параметра контроллера заранее предусмотреть наличие атрибутов, указанных нами постоянными, то можно будет указывать только параметр, а атрибуты расставятся автоматически. Это мы можем увидеть, привязав созданный нами ранее комплексный объект-тег аналогового сигнала "ModBus.CM101.TE1314_1".

Рис. 5.1.5. Вкладка "Связи" диалога редактирования свойств визуального элемента.

Закончив ввод связей можем проверить, что получилось в результате наших усилий. Для этого закроем окно диалога свойств и запустим наш проект "Старт" на исполнение, про кнопку запуска мы помним из первых глав. Затем, выберем графики и переключимся на вторую страницу. При безошибочной конфигурации мы должны увидеть что-то подобное изображённому на рисунке 5.1.6. Заметьте, что для параметра комплексного объекта-тега, с установленными границами нарушений, выход значения за границы отмечается аварийным цветом. Для того что-бы увидеть выход за границу нарушения Вы можете установить значение производительности вентилятора в 100 (Рис.4.2.9).

Рис. 5.1.6. Группа графиков с подключением четырёх сигналов и одним параметром объекта-тега.

5.2 Создание нового кадра — мнемосхемы

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

Новые кадры, предназначенные впоследствии для помещения в проект, принято создавать и изменять в библиотеке виджетов. Создадим новую библиотеку виджетов, выбрав вертикальную вкладку "Виджет" и в контекстном меню окна библиотек виджетов выберем пункт меню "Новая библиотека" (Рис.5.2.1). В диалоге ввода имени укажем CM101 (KM 101).

Рис. 5.2.1. Добавление новой библиотеки виджетов.

Далее добавляем новый кадр, выбрав пункт меню "Библиотека: originals"->"Группа элементов" (Рис.5.2.2) в контекстном меню созданной библиотеки "KM 101". В диалоге ввода имени укажем AT101 (AT 101). В основе любого кадра и страницы должен лежать элемент "Группа элементов (Box)" поэтому мы его и выбрали.

Рис. 5.2.2. Добавление нового кадра.

Сразу после создания нового кадра нужно установить его базовые свойства, характерные для кадра мнемосхемы. Свойства или атрибуты любого визуального элемента можно указать в панели инструментов "Атрибуты", предварительно выбрав нужный визуальный элемент. Выберем созданный кадр "AT 101" и установим следующие свойства:

  • "Геометрия: ширина" — 900.
  • "Геометрия: высота" — 600.
  • "Страница: группа" — so, для включения кадра в контейнер мнемосхем, при исполнении.
  • "Фон: цвет" — #5A5A5A.
  • "Граница: ширина" — 1.
  • "Граница: цвет" — black.

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

Рис. 5.2.3. Вид нового кадра и установленных атрибутов мнемосхемы.

Теперь, на кадр добавим элементы отображения значения аналогового параметра для наших четырёх сигналов и параметра комплексного объекта-тега "ModBus.CM101.TE1314_1". Для помещения элемента отображения аналогового сигнала на мнемосхему нужно её выбрать, а затем, в меню окна, выбрать пункт меню "Виджет"->"Библиотека: Main"->"Отображение аналогового"; после чего появится курсор с образом этого элемента, который нужно подвести в желаемую область мнемосхемы и нажать левую кнопку мыши. В момент добавления появится диалог с запросом имени нового элемента. Подобным образом добавлять будем пять элементов, которые назовём: A1_Ti, A1_To, A2_Ti, A2_To и TE1314_1.

Таким-же образом добавим элемент крана комплексного объекта-тега дискретного параметра "ModBus.CM101.CB102", для представления которого используем библиотечный элемент "Виджет"->"Библиотека: mnEls"->"Кран шаровый" и назовём его CB102.

Для отображения списка текущих нарушений, на мнемосхему поместим элемент протокола из библиотеки примитивов "Виджет"->"Библиотека: originals"->"Протокол" и назовём его Protocol. В инспекторе атрибутов установим свойства протокола:

  • "Геометрия: ширина" — 500.
  • "Геометрия: высота" — 250.
  • "Показать колонки" — tm;lev;mess.
  • "Уровень" — -1, отображение текущих нарушений любого уровня.
  • "Размер, секунд" — 0, отображать нарушения на любую глубину.
  • "Период слежения, секунд" — 1.

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

После выполнения всех манипуляций у нас должна получиться мнемосхема с видом, похожим на рисунок 5.2.4.

Рис. 5.2.4. Вид мнемосхемы с рядом элементов.

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

Поместим нашу мнемосхему в ветвь "Старт"->"Корневая страница"->"Группа 1"->"Мнемосхемы", путём выбора пункта меню "Библиотека: CM101"->"AT 101", в контекстном меню пункта страницы проекта "Мнемосхемы". Идентификатор новой мнемосхемы установим в "2", при этом поле имени оставим пустым — 2.

Далее нужно произвести уже знакомую нам, по предыдущей главе, операцию, а именно — установку связей на ранее созданные параметры контроллеров. Для этого, откроем вкладку "Связи" (Рис.5.2.5) диалога редактирования свойств мнемосхемы, где мы увидим дерево с элементами "A1_Ti", "A1_To", "A2_Ti" и "A2_To". Развернув любой из элементов мы увидим ветку "Parameter", в которой мы должны указать, или выбрать, адрес значений наших атрибутов "Ti" и "To", соответственно. В процессе заполнении элементов, часть свойств нужно указывать постоянными:

  • "pName" — val:AT101_1 Ti.

Как и в случае с группой графиков в предыдущем разделе, для комплексных параметров объекта-тега "ModBus.CM101.TE1314_1" и "ModBus.CM101.CB102" можно указать только параметр, а атрибуты расставятся автоматически.

Рис. 5.2.5. Вкладка "Связи" диалога редактирования свойств мнемосхемы.

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

Рис. 5.2.6. Мнемосхема с четырьмя подключенными сигналами, комплексными параметрами объекта-тега и протоколом.

Заметьте, что выход значения комплексного параметра объекта-тега за границы нарушений отмечается миганием через аварийный цвет для: параметра, объекта сигнализации и жёлтого кружочка внизу. Кроме мигания, при нарушении осуществляется монотонная сигнализация (часто на бузер) и синтез речи с проговором позиции параметра, указанной в поле связи "spName" (Рис.5.2.5), если доступен соответствующий синтезатор речи. При активации нарушения, справа и справа-внизу активируются кнопки с индикацией типа уведомления, а по нажатию на них осуществляется квитация соответствующего типа уведомления. По нажатию на мигающий жёлтый круг справа-внизу квитируются все уведомления. Факт присутствия нарушения также отображается записью в протоколе, который мы добавили. Чтобы увидеть выход за границу нарушения Вы можете установить значение производительности вентилятора в 100 (Рис.4.2.9). Детальнее про концепцию работы с нарушениями можно почитать в "Как сделать Нарушения, сигнализация и уведомления".

Историю нарушений можем посмотреть в документе "Протокол нарушений", который доступен при выборе вида "Документ" (Рис.5.2.7).

Рис. 5.2.7. Документ "Протокол нарушений".

Дискретный комплексный параметр объекта-тега "ModBus.CM101.CB102", представленный нами в виде шарового крана, является активным. Т.е. его можно выбрать, получив панель управления справа (Рис.5.2.6), а также передать команды (открыть или закрыть). Команды можно передавать с панели управления или через контекстное меню. Все действия оператора, по управляющим воздействиям, протоколируются и документ протокола можно посмотреть при выборе вида "Документ" (Рис.5.2.8).

Рис. 5.2.8. Документ "Протокол вмешательств".

5.3 Создание нового комплексного элемента

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

  • Создание виджета "Воздушный холодильник" на основе примитива "Элементарная фигура".
  • Создание финального-скомпонованного виджета "Холодильник" на основе примитива "Группа элементов".

5.3.1 Создание виджета "Воздушный холодильник" на основе примитива "Элементарная фигура"

Виджет будем создавать в ранее нами созданной библиотеке "КМ 101". Для этого кликаем правой кнопкой манипулятора "мышь" по пункту этой библиотеке и выбираем пункт меню "Библиотека: originals"->"Элементарная фигура", как это показано на рисунке 5.3.1.1, и называем новый елемент air_cooler (Воздушный холодильник).

Рис. 5.3.1.1. Добавление виджета в библиотеку "KM 101" на основе примитива "Элементарная фигура".

После подтверждения появится новый виджет с именем "Воздушный холодильник". Выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования, посредством контекстного меню нового элемента (Рис.5.3.1.2). В инспекторе атрибутов установим свойства:

  • "Геометрия: ширина" — 200.
  • "Геометрия: высота" — 200.
  • "Заполнение: цвет" — lightgrey. Цвет можно задавать, как с помощью названий цветов, так и в формате #RRGGBB (#RRGGBB-AAA).
Рис. 5.3.1.2. Первичная конфигурация виджета.

Теперь изобразим визуальное представление виджета, что можно осуществить двумя способами:

  • Нарисовать желаемое изображение манипулятором "мышь", используя "Линию", "Дугу", "Кривую Безье" и "Заливку". Соответствующая панель ("Панель элементарных фигур") появится после входа в режим редактирования-рисования. Вход в этот режим осуществляется, как показано на рисунке 5.3.1.3, либо двойным нажатием левой кнопки манипулятора "мышь" на теле виджета.
  • Вручную заполнить поле "Список элементов", введя перечень необходимых элементов и координат точек.

Дополнительную информацию о редакторе можно получить здесь.

Рис. 5.3.1.3. Вход в режим рисования виджета, основанного на примитиве "Элементарная фигура".

В нашем примере мы воспользуемся вторым способом. Для этого, в поле "Список элементов" инспектора атрибутов, введем нижеприведенный перечень и нажмем "Ctrl"+"Enter":

line:(20|80):(100|20)
line:(100|20):(180|80)
line:(180|80):(100|140)
line:(100|140):(20|80)
line:(100|20):(100|140)
line:(20|80):(180|80)
line:(50|165):(100|140)
line:(100|140):(150|165)
line:(150|165):(50|165)
fill:(20|80):(100|20):(180|80):(100|140)
fill:(50|165):(100|140):(150|165)

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

Рис. 5.3.1.4. Изображение, соответствующее "Списку элементов" виджета.

Создадим иконку нашего виджета, которая будет видна в дереве виджетов библиотеки "KM 101" (Рис.5.3.1.5).

Рис. 5.3.1.5. Создание иконки виджета.

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

5.3.2 Создание финального-скомпонованного виджета "Холодильник" на основе примитива "Группа элементов"

Финальный виджет будем создавать в библиотеке "KM 101", для чего кликаем правой кнопкой манипулятора "мышь" по этой библиотеке и выбираем примитив "Группа элементов", как это показано на рисунке 5.3.2.1. Назовём новый элемент — elCooler (Холодильник).

Рис. 5.3.2.1. Добавление виджета в библиотеку "KM 101", на основе примитива "Группа элементов".

После подтверждения появится новый виджет с именем "Холодильник". Выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования. В инспекторе атрибутов установим свойства:

  • "Геометрия: ширина" — 250.
  • "Геометрия: высота" — 200.

Возьмём ранее созданный элемент "Воздушный холодильник (air_cooler)" и перетащим его — нажмём на нем левую кнопку манипулятора "мышь" и переместим курсор до области только что созданного виджета, где отпустим кнопку (Рис.5.3.2.2).

Рис. 5.3.2.2. Перетаскивание (Drag&Drop) виджета "air_cooler" в виджет-контейнер "elCooler".

В результате появится окно диалога с предложением ввести идентификатор и имя нового виджета. Идентификатор и имя могут быть заданы произвольно. Мы введём идентификатор air_cooler, а имя оставим пустым и оно унаследуется от родителя — элемента "air_cooler". Таким образом, только что созданный виджет внутри контейнера "elCooler" унаследует элемент "Воздушный холодильник (air_cooler)". После подтверждения ввода идентификатора и имени, виджет "Воздушный холодильник (air_cooler)" добавится в нашем виджете-контейнере "elCooler" (Рис.5.3.2.3). В инспекторе атрибутов установим для него свойства:

  • "Геометрия: x" — 25.
  • "Геометрия: y" — 0.
Рис. 5.3.2.3. Добавление унаследованного виджета "air_cooler".

Далее, развернем пункт меню библиотеки "Элементы мнемосхемы", найдем там элемент "Вентилятор 2 (cooler2)" и перетащим его на виджет-контейнер. Этот элемент будет динамически отображать интенсивность работы воздушного холодильника. Для нового виджета введём идентификатор cooler2 и имя снова оставим пустым, после чего виджет "Вентилятор 2 (cooler2)" добавится в наш виджет-контейнер "elCooler". Таким образом, только что созданный виджет, внутри контейнера "elCooler", унаследует элемент библиотеки "Элементы мнемосхемы" — "Вентилятор 2 (cooler2)". В инспекторе атрибутов установим свойства:

  • "Геометрия: x" — 75.
  • "Геометрия: y" — 30.
  • "Геометрия: z" — 10. Поднять элемент над всеми можно из панели "Функции видимости виджетов".
  • "Цвет1" — #FFFF00-200, добавили альфа канал — прозрачность 200 ("0" - полностью прозрачный, "255" - полностью непрозрачный), рисунок 5.3.2.4.
  • "Цвет2" — #FF0000-200, добавили альфа канал — прозрачность 200.
Рис. 5.3.2.4. Изменение прозрачности цвета заполнения наследованного виджета "cooler2".

Теперь, в виджете-контейнере "elCooler" добавим два текстовых поля, основанных на примитиве "Текст", с целью отображения входной и выходной температур потока. Для этого, выделим виджет "Холодильник" и, на панели визуальных элементов библиотеки "KM 101", выберем пункт меню примитива "Текст", как это показано на рисунке 5.3.2.5. Для первого текстового поля введем идентификатор Ti и, в инспекторе атрибутов, установим свойства:

  • "Геометрия: x" — 5.
  • "Геометрия: y" — 20.
  • "Геометрия: ширина" — 70.
  • "Геометрия: высота" — 35.
  • "Выравнивание" — В центре.
  • "Шрифт" — Arial 14 1. Изменение шрифта можно осуществлять в диалоге, который открывается по нажатию на ключик у поле редактирования, (Рис.5.3.2.7).
  • "Текст" (Рис.5.3.2.8):
%1
град.C
  • "Количество аргументов" — 1 (Рис.5.3.2.9):
    • "Аргумент 0: тип" — Вещественный.
    • "Аргумент 0: значение" — 300.25, задано лишь для наглядности и в режиме исполнения оно будет заменено реальным значением входной температуры.
    • "Аргумент 0: конфигурация" — 3;f;2.
Рис. 5.3.2.5. Добавление нового элемента, основанного на примитиве "Текст".
Рис. 5.3.2.6. Указание геометрии виджета "Ti".
Рис. 5.3.2.7. Изменение размера шрифта для виджета "Ti".
Рис. 5.3.2.8. Изменение поля "Текст" и указание наличия аргумента, для виджета "Ti".
Рис. 5.3.2.9. Конфигурация аргумента виджета "Ti".

Теперь, с целью создания аналогичного виджета для выходной температуры, скопируем виджет "Ti". Вставим скопированный виджет и укажем ему идентификатор To (Рис.5.3.2.10). В инспекторе атрибутов установим свойства:

  • "Геометрия: x" — 175.
  • "Геометрия: y" — 20.
Рис. 5.3.2.10. Виджет "To".

Теперь добавим виджет, основанный на примитиве "Элемент формы" (Рис.5.3.2.11), который будем использовать для выбора заданий производительности холодильника. Укажем идентификатор cw (Рис.5.3.2.12) и, в инспекторе атрибутов, установим свойства:

  • "Активный" — true.
  • "Геометрия: x" — 60.
  • "Геометрия: y" — 158.
  • "Геометрия: ширина" — 60.
  • "Геометрия: высота" — 40.
  • "Геометрия: z" — 10. Поднять элемент над всеми можно из панели "Функции видимости виджетов".
  • "Тип элемента" — Combo Box.
  • "Шрифт" — Arial 14 1.
  • "Значение" — 200.
  • "Конфигурация":
0
50
100
150
200
Рис. 5.3.2.11. Добавление виджета, основанного на примитиве "Элемент формы".
Рис. 5.3.2.12. Заполнение параметров ComboBox "cw".

Для отображения единицы измерения производительности холодильника добавим ещё один виджет, основанный на примитиве "Текст". Делаем ту-же процедуру, что и для виджета "Ti". Укажем идентификатор dimension (Рис.5.3.2.13) и, в инспекторе атрибутов, установим свойства:

  • "Геометрия: x" — 125.
  • "Геометрия: y" — 168.
  • "Геометрия: ширина" — 80.
  • "Геометрия: высота" — 20.
  • "Выравнивание" — В центре.
  • "Шрифт" — Arial 14 1.
  • "Текст" — об./мин..
Рис. 5.3.2.13. Добавление виджета "dimension", основанного на примитиве "Текст", и изменение его параметров.

Для добавления логики обработки виджета "Холодильник (elCooler)", откроем диалог редактирования свойств этого визуального элемента и перейдём на вкладку "Обработка". На этой вкладке мы увидим дерево атрибутов виджета и поле текста программы обработки атрибутов. Для решения нашей задачи нужно добавить три атрибута: Ti, To, Cw (Рис.5.3.2.14); для чего нужно развернуть корневой элемент ".", выбрать любой элемент внутри него и нажать кнопку "Добавить атрибут" внизу.

Далее, включим в обработку атрибут value комбобокса "cw", как это показано на рисунке 5.3.2.15. Аналогично включим в обработку атрибут arg0val для Ti и To, а также атрибут speed элемента "cooler2".

Рис. 5.3.2.14. Добавление трех атрибутов элемента "elCooler" библиотеки "KM 101".
Рис. 5.3.2.15. Включение в обработку атрибута "value" комбобокса "cw".

В завершении, установим язык пользовательского программирования "JavaLikeCalc.JavaScript" и напишем саму эту программу обработки виджета:

Ti_arg0val = Ti;
To_arg0val = To;

for(ev_rez = "", off = 0; (ev_wrk=event.parse(0,"\n",off)).length; )
    if(ev_wrk == "ws_CombChange:/cw") Cw = cw_value;
    else ev_rez += ev_wrk+"\n";
event = ev_rez;

cw_value = Cw;
cooler2_speed = Cw/5;

At.png Помещение или редактирование программы виджета не приводит к непосредственной её компиляции, а значит не будет сообщений об ошибках в программе, если они имеют место быть. Это связано с тем, что непосредственное исполнение программы, а значит и её компиляция, осуществляется в окружении исполнения и в момент запуска проекта визуализации на исполнение. При этом все ошибки, возникшие при компиляции, выводятся в виде сообщений OpenSCADA, а виджеты с ошибками не исполняются. Детальнее, про отладку пользовательских процедур, можно почитать в "Как сделать Отладка проекта OpenSCADA".

Полученная вкладка "Обработка" виджета "elCooler" библиотеки "KM 101" будет иметь вид, показанный на рисунке 5.3.2.16.

Рис. 5.3.2.16. Результирующая вкладка "Обработка" виджета "elCooler" библиотеки "KM 101".

Закроем диалог редактирования свойств визуального элемента, создадим иконку нашего элемента, закроем внутреннее окно редактирования и сохраним это всё.

На этом разработку комплексного элемента можно считать законченной.

5.3.3 Добавление комплексного элемента на мнемосхему

Для проверки работоспособности и оценки результатов наших усилий, добавим созданный виджет на мнемосхему, разработанную в разделе 5.2. Выполним эту операцию для двух холодильников "AT101_1" и "AT101_2".

Для этого откроем кадр мнемосхемы "AT 101" для редактирования. Хватаем "мышью" наш комплексный элемент и тащим на мнемосхему, где отпускаем в нужной позиции. Вводим идентификаторы AT101_1 и AT101_2, соответственно. Добавленные элементы располагаем как нам удобно. После выполнения этих манипуляций у нас должна получиться мнемосхема с видом на рисунке 5.3.3.1.

Рис. 5.3.3.1. Мнемосхема с нашими комплексными элементами.

Сохраним новую мнемосхему и закроем её окно. Далее, перейдём в проект и откроем эту мнемосхему в дереве проекта "Старт"->"Корневая страница"->"Группа 1"->"Мнемосхемы"->"AT 101". Как можно заметить, наши новые элементы появились здесь автоматически и нам осталось только подключить связи к ним. Для этого откроем диалог редактирования свойств мнемосхемы на вкладке "Связи" (рис.5.3.3.2). На этой вкладке мы увидим дерево с элементами "AT101_1" и "AT101_2", развернув любой мы увидим ветвь "Параметр" с атрибутами "Ti", "To" и "Cw". Таким образом, в поле "Параметр" мы можем просто указать адрес параметра prm:/LogicLev/CM101/AT101_1 и prm:/LogicLev/CM101/AT101_2, соответственно, а атрибуты будут расставлены автоматически.

Рис. 5.3.3.2. Вкладка "Связи" диалога редактирования свойств мнемосхемы.

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

Рис. 5.3.3.3. Результирующая мнемосхема.

На этой мнемосхеме, посредством наших комплексных элементов, мы можем не только наблюдать, но и управлять производительностью холодильников, просто меняя значение в комбобоксе. Меняя производительность, мы можем заметить и изменение температуры и срабатывание сигнализации по комплексному аналоговому параметру объекта-тренда. Историю изменения мы можем увидеть и исследовать на группе графиков, созданной нами в разделе 5.1, и документе "Протокол нарушений", о котором упоминалось в разделе 5.2.

6 Вывод

Таким образом, мы получили полноценный типовой интерфейс технологического процесса (ТП) с реальным сбором данных в разный способ, а соответственно, получили представление и навыки работы с OpenSCADA.

При построении интерфейса ТП мы рассмотрели все три уровня сложности, а соответственно и получили представление про нужный квалификационный уровень программиста SCADA.

Сбор и обработку данных мы рассмотрели и осуществили в разные способы, от простого-типового и по отражение модели данных ПЛК, построенного на основе OpenSCADA. Т.е., получено представление про источники данных SCADA-систем и доступ к ним с помощью сетевых интерфейсов и протоколов обмена, поддержку которых реализуют соответствующие модули OpenSCADA.

И конечно, мы рассмотрели методы распространения (дистрибуции) OpenSCADA, способы её установки и получения нужного окружения, таких как: сервера SCADA, ПЛК OpenSCADA и рабочего места оператора.

Информация про OpenSCADA этим документом не ограничивается и, в разрешении специфических вопросов, Вы должны использовать всю доступную документацию и примеры демонстрационных конфигураций-моделей OpenSCADA, пользуясь тем самым преимуществами "открытых исходных текстов (OpenSource)". Отдельно тут нужно ещё раз отметить "Руководство по программе", "Как сделать ..." и "Динамическую модель реального времени АГЛКС", как наиболее полные источники информации про OpenSCADA.

7 Ссылки