- Автор: Роман Савоченко
Максим Лысенко (2010-2012) - Видео-дополнения:
- Официальное дополнение OpenSCADA 0.8.0 LTS (устарелое), Роман Савоченко, 2012
- Видео "Как (How to) ..." от Сергея Карпеша, Сергей Карпеш, 2018
- Изначально создано: в старой Wiki
- Целиком отревизировано: 12.01.7532/11.03.2024
OpenSCADA является предельно модульной, гибкой и многофункциональной SCADA-системой. Как следствие, первое знакомство с OpenSCADA может быть достаточно сложным, по причине малых шансов совпадения предыдущего опыта пользователя, или полного его отсутствия, с подходами работы в OpenSCADA. Однако, в значительной степени, это только первое впечатление, поскольку вся мощь OpenSCADA оказывается в руках пользователя и от изобилия которой пользователь может растеряться, и ему могут понадобиться значительные усилия для отбора функций, нужных в решении его задачи.
По этой причине, и для наглядного представления общей концепции работы в OpenSCADA, создан данный документ. Документ на примерах, и в достаточно краткой и наглядной форме, представляет путь от установки и запуска OpenSCADA до создания элементов пользовательского интерфейса. В качестве целевой помощи в конфигурации, реализации и решения типовых задач около OpenSCADA, также могут быть использованы документы Частые вопросы и "Как (How to) ...".
Документ предназначен для OpenSCADA версии 0.9 и выше. Если-же вас интересует этот документ для ранних версий тогда вы можете его получить из документации, которая идёт с пакетами той версии OpenSCADA, или из этого документа старой Wiki.
Документ не содержит детального описания концепции и погружения в детали OpenSCADA, а предоставляет ссылки на документы, содержащие такую информацию, и в первую очередь это Руководство по программе.
Документ строится синхронно с реализацией примеров на подключении к демонстрационной базе данных (БД) модели "АГЛКС" в роли источника данных — ПЛК. Следовательно, пользователь должен получить дистрибутив OpenSCADA с этой БД, о чём детальнее в разделе Установка!
Contents
- 1 Термины, определения и аббревиатуры
- 2 Установка OpenSCADA
- 3 Первичная конфигурация и запуск
- 4 Работа с источниками данных
- 5 Формирование визуального представления
- 6 Вывод
- 7 Ссылки
1 Термины, определения и аббревиатуры
1.1 Термины и определения
- Qt — инструментарий разработки ПО с помощью которого в частности созданы модули QTStarter (пускатель модулей OpenSCADA на библиотеке Qt), QTCfg (графический конфигуратор OpenSCADA) и Vision (редактор и исполнитель рабочих пользовательских интерфейсов СВУ). Может встречаться в виде QT, что является ранней записью, использованной разработчиками OpenSCADA для библиотеки Qt.
- Блокировка — условная граница технологического параметра по преодолению которой выполняются предусмотренные алгоритмом действия из предотвращению аварии. В некоторых режимах ТП (пуск), в соответствии с регламентом, может быть необходимо отключение блокировки — деблокирование.
- Виджет СВУ — элемент визуализации СВУ.
- Деблокирование — процесс отключения блокировки на время работы ТП в режимах, для которых в регламенте предусмотрена данная операция. Деблокирование технологических параметров является строго отчётной операцией и должно производится оперативным персоналом в соответствующем порядке!
- Кадр СВУ — производный элемент визуализации, состоящий из базовых элементов и способный выполнять функции страницы проекта СВУ.
- Квитация (от quietance) — процесс подтверждения факта того, что оперативный персонал обратил внимание на нарушение в работе ТП. Обычно этот процесс подразумевает принятие мер оператором для устранения нарушения и нажатие соответствующей кнопки прекращения сигнализации.
- Комплексный параметр-тег или объект-тег сигнала — детализированный сигнал источника данных как исчерпывающий параметр-тег, который для аналогового обычно содержит:
- значение сигнала в инженерной-реальной единице измерения;
- название единицы измерения;
- шкала-диапазон физического изменения значения сигнала — минимальная и максимальная границы;
- границы сигнализации — обычно это верхняя и нижняя границы для предупредительной и аварийной сигнализации;
- параметры фильтра;
- параметры особенностей шкалы, определения достоверности, формата представления и другое.
- Модель данных — организация и структурирование данных ТП или другого объекта автоматизации в слое источника данных SCADA, протокола обмена или ПЛК. По умолчанию имеется в ввиду слой источника данных OpenSCADA со структурой "Объект контролера"->"Параметр, уровень 1"->...->"Параметр, уровень N"->"Атрибут значения - сигнал".
- Общее Хранилище — первичное хранилище OpenSCADA (указываемое ранее как "*.*" и после неявно "<gen>"), которое разработано для комбинирования Конфигурационного Файла и рабочей Базы Данных в одно хранилище общих данных OpenSCADA. Где Конфигурационный Файл первичный для уже присутствующих там данных, т.е. их изменения, а всё новое создаётся в Базе Данных.
- Проект — термин имеет много значений и, в зависимости от контекста, может определять:
- Проект (программа) OpenSCADA — свободное программное обеспечение, документацию которого вы в данный момент читаете.
- Определённый набор-каталог с конфигурацией и данными, которые создаются пользователем OpenSCADA, где конфигурация сохраняется в конфигурационном файле (обязательно) и одном или нескольких файлах БД (необязательно и может быть в сети). Например — демонстрационный проект, модель ТП "АГЛКС". Т.е., автором проекта выступает пользователь программы — инженер-разработчик или программист SCADA системы.
- Проект СВУ — составная среды визуализации и управления (СВУ), которая создаётся в модуле UI.VCAEngine через UI.Vision и которая содержит набор кадров СВУ.
- Сигнал (относительно источника данных) — элемент источника данных в виде измеренного или вычисленного значения технологического параметра или датчика-сенсора. Представляет из себе скаляр дискретного, целого или реального типов, который часто кодируется масштабированием шкалы параметра в размерность целого. Сигнал для идентификации часто просто индексируется или кодируется по адресу его значения в карте протоколу обмера и осмысленное название он получает в модели данных SCADA.
- Сигнализация — процесс уведомления оперативного персонала о нарушении технологического процесса или работы оборудования автоматизации. Способы сигнализации могут быть различных типов воздействия на органы чувств человека с целью привлечения внимания. Часто предусматриваются следующие типы сигнализации:
- Световая сигнализация — обычно осуществляется посредством смены цвета графического объекта (миганием) для возникающих событий и установкой статичных аварийных цветов (красный и жёлтый) для сквитированных-подтверждённых событий.
- Звуковая — осуществляется выдачей звукового сигнала в момент возникновения события. Тип звукового сигнала может быть как монотонным, так и синтезированным речевым сообщением с информацией о нарушении.
- Уставка сигнализации — условная граница значения технологического параметра, преодоление которой считается нештатной ситуацией. Обычно предусматриваются следующие границы:
- Верхняя и нижняя аварийные границы — границы аварийных значений технологического параметра.
- Верхняя и нижняя предупредительные границы — границы предупреждения — регламентные границы о выходе технологического параметра за рабочий диапазон.
- Отказ — признак выхода значения параметра за аппаратные границы технологического оборудования. Обычно характеризует отказ датчика, обрыв канала связи с датчиком или ПЛК.
1.2 Used abbreviations
- API — Application Programming Interface of OpenSCADA modules or extensions on internal language of OpenSCADA — User API.
- AWP — Automated Work Place. Usually it is system unit of computer system, display, mouse "manipulator" sometimes with keyboard, and other peripheral equipment, which serves to visualise data of the technological process, as well as issuance of control actions on TP.
- DAQ — Data Acquisition.
- DB — Database.
- DCON — name of one of the communication protocols used in industry.
- EVAL — Error VALue, used in dynamic data and the internal language for specifying a specific value-sign of the data missing or error, which is different one for different value types, but they are transparently converted one to other. As a useful synonym to EVAL in the internal language is currently used null.
- FS — File System.
- GPL — General Public License under the conditions of which OpenSCADA distributed and may be used.
- GUI — Graphical User Interface.
- HMI — Human-Machine Interface.
- HTTP — HyperText Transfer Protocol.
- MOD — Matching to Object Device. Number of devices or PLC modules to whose being directly connected signals from sensors of TP for followed converting from analog to digital form and back. The conversion performs with goal of following processing of the technological parameters in PLC.
- ModBus — Modicon BUS is a serial communications protocol, in the variants RTU and ASCII, originally published by Modicon in 1979 for use with its PLCs. Later it was expanded to work over TCP-IP and this variant was named ModBus/TCP.
- OS — Operation System.
- PLC — Programmable Logic Controller.
- QT — look for QT in the list of terms, it is not an acronym.
- SCADA — Supervisory Control and Data Acquisition.
- SO — Signal Object. Letters in the abbreviation have been rearranged to eliminate confusion with the abbreviation OS (see above)
- TP — Technological Process. Whole complex of technological equipment of the 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. Детальнее смотрите в документе "Как создать Живой диск".
2.1 Установка OpenSCADA из готовых пакетов
Установка из готовых пакетов, в свою очередь, может осуществляться двумя методами. Первый — простейший, когда пакеты OpenSCADA уже присутствуют в собственных репозиториях пакетов OpenSCADA или официальных, дополнительных репозиториях используемого дистрибутива ОС Linux. Установка таких пакетов это вопрос запуска типовой программы управления пакетами дистрибутива с последующим выбором пакетов OpenSCADA. Кроме простой установки, репозитрий пакетов в целом позволяет просто содержать операционную систему обновленной, безопасной и актуальной! Второй способ подразумевает получение пакетов OpenSCADA и установку их вручную.
Проверить наличие пакетов OpenSCADA в репозиториях дистрибутивов Linux или OpenSCADA, а также загрузить пакеты OpenSCADA для ручной установки, можно на странице загрузки официального сайта OpenSCADA. Здесь Вы также можете получить конфигурацию для подключения репозиториев пакетов OpenSCADA к пакетному менеджеру вашего дистрибутива Linux.
Загружать пакеты и подключать репозитории пакетов нужно непосредственно для версии используемого дистрибутива иначе, при установке, могут возникнут неразрешимые проблемы с зависимостями.
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 Дистрибутивом Автоматизации и пакетами версии продолжительной поддержки (LTS), к основному названию пакетов добавляется суффикс "-lts" — "openscada-lts", поскольку репозиторий один и он содержит пакеты обоих ветвей, Рабочей и LTS.
Установка-обновление из репозитория является простым, но специфичным для дистрибутива Linux, оконного менеджера или отдельной программы работы с репозиториями и пакетами, поэтому отошлём читателя к соответствующей документации на дистрибутив или программу, которые он использует. Здесь-же вкратце рассмотрим добавление репозитория и установку OpenSCADA с помощью типовых инструментов командной строки:
Репозитории пакетов, основанные на менеджере APT (Debian, Ubuntu, ALTLinux) — добавляются помещением загруженного файла "openscada.list" в директорию "/etc/apt/sources.list.d" или редактированием файла /etc/apt/sources.list, вставкой одной строки:
Debian (LTS и Work, репозиторий Linux автоматизації): "deb http://ftp.oscada.org/Debian/12/openscada ./"
Ubuntu (LTS): "deb http://ftp.oscada.org/OpenSCADA/LTS/Ubuntu/22.04 ./"
Ubuntu (Work): "deb http://ftp.oscada.org/OpenSCADA/Work/Ubuntu/22.04 ./"
Установка:
apt-get update
apt-get install openscada-model-aglks
ALTLinux (LTS и Work, репозиторий Linux автоматизації): "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 (LTS)
baseurl=http://ftp.oscada.org/OpenSCADA/LTS/CentOs/7
#CentoOs (Work)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/CentOs/6
#Fedora (Work)
#baseurl=http://ftp.oscada.org/OpenSCADA/Work/Fedora/12
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=http://ftp.oscada.org/Misc/pkgSignKey
Установка:
yum install openscada-Model.AGLKS
Репозитории пакетов SuSE YaST — добавляются командой:
zypper ar -f http://ftp.oscada.org/OpenSCADA/LTS/SuSE/15 OpenSCADA
Установка:
zypper in openscada-Model.AGLKS
2.1.2 Ручная установка пакетов OpenSCADA
Для ручной установки пакетов OpenSCADA их нужно загрузить из официального сайта или другого источника. Загрузить обычно можно два набора пакетов.
Первый набор представлен двенадцатью пакетами:
- openscada — пакет со всеми файлами нужными для запуска OpenSCADA в полном объёме, включая все модули;
- openscada-server — содержит зависимости, файл сценария и конфигурацию проекта сервера для запуска OpenSCADA в режиме сервиса-демона;
- openscada-plc — содержит зависимости, файл сценария, конфигурацию проекта ПЛК для запуска 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 mRussian АЗыком;
- 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-server — содержит зависимости, файл сценария и конфигурацию проекта сервера для запуска OpenSCADA в режиме сервиса-демона;
- openscada-plc — содержит зависимости, файл сценария, конфигурацию проекта ПЛК для запуска 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 mRussian АЗыком;
- 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
В процессе выполнения установки могут возникнуть ошибки, связанные с неудовлетворёнными зависимостями. При ручной установке из пакетов удовлетворять их нужно будет вручную, подобно установке пакетов OpenSCADA, или через менеджер пакетов дистрибутива Linux. Случаи наличия проблем зависимости могут быть даже при установке через пакетный менеджер, если используется репозиторий OpenSCADA, который не соответствует дистрибутиву Linux или его версии, или-же не подключены основные репозитории пакетов самого дистрибутива. В пакетном менеджере APT, для автоматического разрешения проблем внешних зависимостей, которые возникли при ручной установке OpenSCADA, можно использовать команду:
apt-get install -f
2.2 Установка-сборка из исходных текстов
Если отсутствует возможность получения готовых пакетов OpenSCADA для выбранного дистрибутива, то остаётся только вариант сборки OpenSCADA из исходных текстов. Этот процесс детально описан в документе "Как собрать из исходных текстов".
3 Первичная конфигурация и запуск
Для наших основных задач с OpenSCADA, в рамках этого документа, нужно установить пакет с БД модели "АГЛКС" — openscada-model-aglks, про что можно детально узнать из предыдущего раздела. Конечно, если вы используете Живой Диск то у вас всё нужное уже есть.
Не рассматривайте тут установку-сборку OpenSCADA из исходных текстов поскольку требование квалификационного уровня пользователя, для этой задачи, значительно выше уровня документа в целом и тут неизбежно будут несоответствия с руководством, ввиду крайне вероятных различий в исходной конфигурации.
Установленная БД модели "АГЛКС" не нуждается в предварительной настройке. Если-же нужно выполнить особую настройку, которая отличается от базовой, то воспользуйтесь руководством по программе. В процессе чего Вам может понадобиться информация про типовые учётные записи и пароли OpenSCADA (не имеют отношения к учётным записям ОС), хотя модели и ново-созданные конфигурации запускаются от привилегированного пользователя и вы можете легко изменить любую из них:
- Суперпользователь (root), пароль — "openscada".
- Пользователь (user), пароль — "user".
- Пример отдельного пользователя (roman), пароль — "roman".
Демонстрация OpenSCADA на основе БД модели "АГЛКС" это не тоже, что обычно предоставляют коммерческие производители ПО с целью продемонстрировать возможности, но исключить или усложнить нормальную работу путём ограничения функций. Демонстрация OpenSCADA, это полно-функциональная программа, предоставляющая примеры реализации и настройки различных компонентов. На основе БД модели "АГЛКС" и других моделей OpenSCADA можно создавать собственные проекты, используя предоставленные наработки. Но после получения определённого опыта лучше новые проекты создавать с чистой конфигурации со стандартными библиотеками OpenSCADA, про что далее будет отмечено; и это чтобы не замусоривать проект ненужными там компонентами чем увеличивая требования к ресурсам и непредсказуемость во время долговременной эксплуатации!
Динамическая модель компрессорной станции на 6 газовых компрессоров, которая лежит в основе демонстрационной БД, требует заметных ресурсов, а именно — процессора с частотой более 1 ГГц (x86) и памяти до 200 МБ. Данные вычислительные ресурсы требуются непосредственно для динамической модели и не являются общим показателем ресурсоёмкости программы в конечных задачах! Требования к памяти, наоборот, являются типовым показателем для графической станции АРМ похожей сложности.
Общий процесс конфигурации SCADA-системы для исполнения функций верхнего уровня — АРМ оператора, можно условно разделить на два этапа:
- Конфигурация источника данных, создание базы данных (БД) параметров этих источников, создание вычислительных логических параметров и настройка истории.
- Формирование визуального представления данных ТП, путём создания интерфейса оператора в виде: мнемосхем, групп графиков, групп контуров, документов и другое.
Итак, нашей конечной целью и целью этого документа является построение полноценной конфигурации локальной SCADA-станции, объединённую с сервером, и с эмуляцией источника данных на основе этой демонстрационной БД (Рис.3).
По ходу, мы ознакомимся с такими важными ролями OpenSCADA как: сервер сбора, архивации, визуализации; среда исполнения ПЛК и удаленная разработка. Но перед этим мы осмотрим OpenSCADA и её возможности в целом.
3.1 Общий обзор
Запустить локальное исполнение OpenSCADA с БД модели "АГЛКС" можно из меню окружения рабочего стола в разделе "Графика", пункт "Модель "АГЛКС" на открытой SCADA системе" с характерной иконкой (Рис.3.1.1).
Локальный запуск также можно осуществить из консоли, командой:
openscada_AGLKS
После запуска мы получим окно графического конфигуратора OpenSCADA — QTCfg (Рис.3.1.2) с открытой корневой страницей. Демонстрационная БД специально настроена так, чтобы первым при запуске появлялось окно конфигуратора. В дальнейшем можно открыть окно разработки графических интерфейсов пользователя, а также запустить проект пользовательского интерфейса на исполнение.
Программный конфигуратор OpenSCADA является основным и достаточным средством для конфигурации любого компонента OpenSCADA. Как и многие компоненты OpenSCADA, конфигуратор реализован в виде модуля. Кроме конфигуратора QTCfg доступны и другие конфигураторы, выполняющие те же функции, но реализованные на основе других технологий. Например, таковыми являются Web-конфигураторы: WebCfgD и WebCfg.
Все действия в дальнейшем мы будем рассматривать только в конфигураторе QTCfg, хотя их можно будет выполнить и в других конфигураторах.
Структуру интерфейса окна конфигуратора можно детально рассмотреть по ссылке. Для нас сейчас более важно рассмотреть все доступные графические интерфейсы OpenSCADA, поэтому нажмём предпоследнюю сверху иконку на панели инструментов, которая откроет окно разработки пользовательского интерфейса (Рис.3.1.3).
Далее можем запустить проект "АГЛКС" на исполнение, для чего выбираем его в перечне проектов и запускаем, нажимая на первую слева иконку на панели инструментов, или в контекстном меню. В результате чего получим окно интерфейса конечного пользователя — оператора (Рис.3.1.4).
Построение и исполнение пользовательских интерфейсов осуществляется модулем Vision подсистемы "Пользовательские интерфейсы". Кроме этого модуля ещё доступны иные модули визуализации, например, OpenSCADA предоставляет модуль WebVision, который позволяет исполнять проекты разработанные в интерфейсе модуля Vision, но посредством Web-технологий и стандартного Web-браузера.
For accessing the Web-interfaces of need host on the Figure 3 you can sequentially try such URL: http://localhost:10002, http://localhost:10003, http://localhost:10004.
Все действия в дальнейшем будем рассматривать только в интерфейсе модуля Vision.
Таким образом мы запустили демонстрацию OpenSCADA и познакомились с основным набором инструментов. В дальнейшем будем их использовать в конфигурации OpenSCADA для выполнения функций верхнего уровня — АРМ оператора и других задач.
Закроем программу через соответствующий пункт меню "Файл", что нужно сделать обязательно иначе её дальнейший фоновый запуск не сможет открыть портов уже занятых этой программой.
3.2 Фоновое и удалённое выполнение — сервер, среда исполнения ПЛК и удалённая разработка
Все консольные операции можете выполнить в консольном терминале, например, программа "konsole" в окружении Живого Диска из диалога запуска по Alt+F2. И каталог "{HOME}" тут это "/home/user".
Организация проекта OpenSCADA в отдельном каталоге делает простым запуск готовых проектов в пространстве сервиса — исполнение в фоне, а также дальнейшее обновление и сопровождение этого проекта без прямого удаленного контроля. Фактически, вы можете разрабатывать проект локально, держа его каталог в пользовательском рабочем каталоге (типично "{HOME}/.openscada"), а для запуска в пространстве сервиса только копировать или паковать, передавать на удалённое рабочее устройство и распаковывать в системный рабочий каталог (типично "/usr/share/openscada").
Сервисное-фоновое исполнение программ в Linux обслуживается соответствующим образом сформированным сценарием-скриптом, который размещается в каталоге "/etc/ini.d" и должен быть отдельным на каждый проект OpenSCADA, который запускается в сервисном пространстве. Для упрощения и исключения необходимости заниматься созданием собственных сценариев, OpenSCADA предоставляет соответствующие для стандартных случаев-профилей и которые обычно поставляются пакетами openscada-server и openscada-plc (openscada-lts-server и openscada-lts-plc для LTS).
Соответственно, для запуска в пространстве сервиса скажем библиотечного проекта "АГЛКС" мы:
- устанавливаем пакет openscada-model-aglks (openscada-lts-model-aglks для LTS) и openscada-server (openscada-lts-server для LTS), если их ещё не установлено и это не окружение Живого Диска или Linux Автоматизации от установки этого Диска;
- запускаем проект "АГЛКС", для получения его каталога в пользовательском рабочем каталоге;
- копируем каталог проекта "АГЛКС" в системный рабочий каталог с переименованием в "server", предварительно остановив фоновое исполнение проекта "server" и удалив его каталог проекта; например следующим образом из консоли:
# Подключиться от суперпользователя
su -
# ... для живого диска и некоторых других окружений Linux
sudo bash
# Остановить исполнение предыдущей конфигурации сервера и удалить его каталог
service openscada-server stop; rm -R /usr/share/openscada/server
# ... для LTS
service openscada-lts-server stop; rm -R /usr/share/openscada/server
# Скопировать проект "АГЛКС" из домашнего каталога пользователя "{HOME}" с переименованием в "server"
cp -R {HOME}/.openscada/AGLKS /usr/share/openscada/server
# Запустить сервер уже с проектом "АГЛКС"
service openscada-server start
# ... для LTS
service openscada-lts-server start
Отметьте, что локально вы можете не копировать каталог проекта целиком, а только установить на него символическую ссылку, но вы получите риск двойного исполнения проекта на общий каталог и данные, что приводит к аварийному завершению одного исполнения или их обоих!
Отличие исполнения проекта в среде сервиса-фона от пользовательской среды рабочего стола собственно одно, естественно кроме отсутствия локального графического интерфейса, это — отсутствие в фоне определения локали, т.е. язык интерфейса там будет Английский. И что можно просто исправить сменой или добавлением конфигурационного параметра <prm id="Lang">ru_RU.UTF-8</prm> в секции-теге "station" файла oscada.xml фонового проекта.
Таким образом вы получите демонстрационную БД (проект "АГЛКС"), которая работает в фоне, что однако мы не увидим пока не попробуем подключиться к этой конфигурации, про что ниже. Теперь, при каждом запуске компьютера, она будет таким образом запускаться и работать в фоне. В целом, именно так осуществляется запуск и выполнение серверных конфигураций, окружений ПЛК и одноплатных ПК вроде RaspberyPi.
Если у вас все-же возникли проблемы при работе с консолью-терминалом или вы сознательно хотите фонового исполнения в графическом окружении — так называемого "запуска или закрытия в системный лоток", тогда на этой стадии вы можете снова запустить демонстрационную конфигурацию, как описано в начале этого раздела (Рис.3.1.1), установить параметр Сворачивать или запускать в системный лоток модуля UI.QTStarter и закрыть окно конфигуратора, чтобы проект модели АГЛКС свернулся в системный лоток.
3.3 Создание собственного проекта
В окне менеджера проектов OpenSCADA (Рис.3.3) создадим наш собственный проект, который можно вызвать из меню окружения рабочего стола в разделе "Графика" общим пунктом "Открытая SCADA-система" с характерной иконкой (Рис.3.1.1) или командой из консоли-терминала:
openscada
В этом окне мы также можем проверить фоновое исполнение серверной и демонстрационной конфигураций.
А именно, нажмём соответствующую кнопку Создать-обновить проект и введём название нового проекта — Start.
When you want to check yourself for some problems or other reasons, you may download backup of the already ready OpenSCADA "Start" project and restore it by context menu in the same window Figure 3.3. You have to place the backup file in directory of OpenSCADA user projects — "~/.openscada/", like to from the console-terminal:
wget http://ftp.oscada.org/OpenSCADA/Projects/Start_QuickStart.backup -P ~/.openscada/
3.3.1 Подключение и использование удалённых и фоновых конфигураций
Теперь мы можем попробовать удалённо подключиться к фоновому демонстрационному проекту, посмотреть на его конфигурацию и запустить демонстрационный проект на локальное исполнение из сервера визуализации.
На странице "Транспорты" (Рис.3.3.1.1) в режиме Пользовательский и Системный создадим подключение к нашей фоновой демонстрации "AGLKS" как станции OpenSCADA. Укажем там транспорт Сокеты, адрес localhost, пользователя root и пароль openscada. После обновления дерева навигации конфигуратора командой контекстного меню мы должны получить новый корневой пункт этого подключения и сможем контролировать удалённую-фоновую станцию с этого конфигуратора.
Если пункт удалённой станции появился, но отображает отсутствие подключения, то вы допустили ошибку в конфигурации выше или удалённая станция не доступна, что, в нашем случае, может означать только то, что она не работает в фоне, а значит вернитесь к соответствующему разделу и повторите операции в нём.
Если всё работает, то сохраним эту конфигурацию, нажав вторую иконку слева на панели инструментов наверху, поскольку мы ещё воспользуемся ею для прямого шлюзования параметров сбора данных из демонстрационного проекта, как ПЛК.
На странице конфигурации визуализатора UI.Vision (Рис.3.3.1.2) выберем:
- станцию движка СВУ — "AGLKS";
- пользователя запуска — оставим пустым;
- пароль пользователя этой удалённой станции — оставим пустым;
- проект(и) автоматического исполнения — также оставим пустым, поскольку мы хотим увидеть возможность удалённой разработки.
Последующий запуск модуля UI.Vision, второй иконкой с конца на панели инструментов наверху, должен привести среду визуальной разработки к установке подключения с сервером визуализации фонового демонстрационного проекта. Где вы можете осуществлять удалённую разработку (Рис.3.3.1.3) и запускать проекты с этого сервера визуализации на исполнение (Рис.3.3.1.4).
Эту конфигурацию удалённого подключения к серверу визуализации сохранять не нужно и поле конфигурации "Станция движка СВУ" (Рис.3.3.1.2) нужно вернуть в "<Локально>", а пользователя станции установить в "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). После чего, или в случае наличия уже записей БД библиотек, необходимые из них нужно активировать, про что читайте далее.
Дистрибутивы OpenSCADA поставляются с рядом библиотек в виде файлов БД "SQLite" (таблица 3.3.2), которые, при запуске-создании пользовательского проекта, помещаются в каталоге "LibsDB/". Согласно этому перечню в объекте модуля БД "SQLite" добавляем или используем готовые записи нужных библиотек, устанавливаем им флаг "Включать" и сохраняем. Далее, для загрузки содержимого библиотек, можно включить БД и нажать кнопку "Загрузить программу с этой БД", однако при загрузке ряд новых объектов не включится, поэтому проще завершить новый проект и запустить его опять.
Таблица 3.3.2. Библиотеки OpenSCADA в составе дистрибутива.
| Идентификатор | Имя | Адрес | Язык/кодировка | Описание |
|---|---|---|---|---|
| OscadaLibs | Библиотеки OpenSCADA | LibsDB/OscadaLibs.db | EN,UK,RU/UTF-8 | Библиотеки источников данных, служб и обработки. |
| vcaBase | СВУ: Главные библиотеки | LibsDB/vcaBase.db | EN,UK,RU/UTF-8 | Библиотеки графических элементов OpenSCADA модуля UI.VCAEngine. |
| 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 или его реализации DAQ-Шаблоном на Логическом Уровне. Общий перечень модулей подсистемы "Сбор данных" и документацию по ним можно получить по ссылке и общий перечень DAQ-Шаблонов можно получить по ссылке.
Данные, полученные из источников, впоследствии обрабатываются, архивируются и используются для визуального представления оператору ТП.
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.2) с предложением ввести идентификатор и название нового объекта контроллера. Идентификаторы объектов OpenSCADA ограничены размером в 20 символов и их рекомендуется вводить символами английского алфавита и цифрами. Кроме того, начинать идентификатор желательно с буквы, что упростит его использование во внутренних процедурах. Названия объектов OpenSCADA ограничены размером в 50 символов и которые могут быть любыми. Название обычно используются для отображения и если оно пустое, то будет использоваться идентификатор. В последствии название мы можем поменять в конфигурации объекта, но идентификатор невозможно изменять прямо; однако объект можно вырезать (Ctrl+X) и затем вставить (Ctrl+V), тем самым переименовав его. Согласно замечаниям ранее введём идентификатор CM101, название "KM 101" — "CM101 (KM 101)".
После подтверждения у нас появится объект нового контроллера. Выберем его в конфигураторе и ознакомимся с настройками (Рис.4.1.3).
Настройки объекта контроллера как правило специфичны для разных типов источников данных и протоколов. Детально ознакомиться с настройками объекта контроллера модуля ModBus можно по ссылке. Мы же рассмотрим общие и ключевые настройки этого модуля.
Перед конфигурацией связи со своим контроллером необходимо из документации на этот контроллер выяснить настройки его сетевых интерфейсов и протоколов, а также, в случае использования ModBus, получить таблицу назначения внешних и внутренних сигналов контроллера на номера регистров ModBus — карту регистров.
С помощью страницы объекта контроллера в разделе "Состояние" можно в первую очередь оценить текущее состояние объекта контроллера и реальное состояние связи с физическим контроллером, а также оперативно их менять. Так, поле "Статус" содержит код ошибки и текстовое описание текущего состояния связи с контроллером. В нашем случае объект контроллера выключен. Мы можем его включить и запустить, установив флажки напротив соответствующих полей. Включенный объект контролера инициализирует параметры, запущенный же ещё запускает задачу сбора (отдельный поток на объект контроллера) и предоставляет возможность передавать данные в контроллер через атрибуты параметров. Поле "Хранилище" указывает в каком хранилище конфигурация данного объекта. Нас устроит хранение в Общем Хранилище, т.е. оставим по умолчанию.
В разделе "Конфигурация" непосредственно содержится конфигурация объекта контроллера. Установим следующие из них, оставив все остальные без изменения:
- "Включать" и "Запускать" указывают в какое состояние переводить объект контроллера при запуске программы — установим оба поля.
- "Планирование сбора" содержит конфигурацию планировщика для запуска задачи сбора данных. Получить описание формата конфигурации данного поля можно из всплывающей подсказки. Одиночное число указывает на периодичность запуска, в секундах — укажем одну секунду.
- "ModBus протокол" указывает на вариант протокола ModBus. Возможны варианты протокола "TCP", "RTU" и "ASCII". На данный момент нас интересует вариант TCP/IP, поэтому оставим как есть. Варианты протоколов "RTU" и "ASCII" нужно устанавливать в случае связи с контроллером посредством последовательных интерфейсов, часто это "RS-485".
- "Адрес транспорта" указывает на исходящий транспорт подсистемы "Транспорты", который используется для соединения с контроллером. В случае с вариантом "TCP" нам нужен транспорт в модуле Sockets, а в случае вариантов "RTU", "ASCII" и последовательного интерфейса нам нужен транспорт в модуле Serial. На создании исходящего транспорта в "Sockets" и "Serial" детальнее остановимся ниже.
- "Узел назначения" указывает на узел источника данных или контроллера в сети ModBus. В нашем случае это должно быть 1.
- "Объединять фрагменты данных" включает объединение несмежных фрагментов регистров в один блок запроса до указанного максимального количества байтов вместо генерации отдельных запросов, чем позволяет уменьшить общее время сбора — установим эту опцию.
Сохраним наши изменения в хранилище, нажав вторую слева иконку на панели инструментов.
Теперь, таким образом как и объект контроллера создадим выходной транспорт в модуле "Sockets" ("Start"->"Транспорты"->"Сокеты") посредством контекстного меню (Рис.4.1.4) и назовём транспорт так, как и объект контроллера "CM101 (KM 101)". Обратите внимание, что в поле "Тип элемента" диалога ввода идентификатора и названия (Рис.4.1.2) нужно выбрать "Выходной транспорт"!
Страница конфигурации полученного выходного транспорта приведена на рисунке 4.1.5. Эта страница также содержит раздел состояния и оперативного управления. В поле "Статус" содержится текстовое описание текущего состояния транспорта. Мы можем подключить его установив флажок напротив соответствующего поля. Поле "Хранилище" указывает в каком хранилище конфигурация объекта — нас устроит "Общее Хранилище".
В разделе "Конфигурация" непосредственно содержится конфигурация объекта транспорта, установим следующие из них:
- "Адрес" указывает на: тип (необязательно), адрес и режим соединения с удалённой станцией. Ознакомиться с форматом записи можно из всплывающей подсказки — установим это поле в значение "TCP:localhost:10502".
Транспорты других типов создаются подобно рассмотренному для "Sockets" методу, а конфигурация их отличается обычно только форматом записи адреса и таймаутов. В случае с транспортом модуля "Serial" в адресе указывается: путь к последовательному устройству, скорость и формат. Для конвертеров USB->Serial,Modem этот адрес можно узнать из операционной системы, например, консольной командой dmesg сразу после его подключения.
Сохраним объект транспорта и вернёмся к конфигурационному полю "Адрес транспорта" объекта контроллера, где выберем адрес "Sockets.CM101". На данный момент OpenSCADA поддерживает, для объектов контроллеров большинства типов источников данных, определение всех параметров непосредственно в поле "Адрес транспорта" и без необходимости отдельного создания объектов транспортов. Т.е. определение в поле "Sockets.CM101:localhost:10502" автоматически создаст CM101 в выходных транспортах Sockets с указаным адресом.
На этом настройка объекта контроллера закончена, включим его, установив флаг "Включен". Следующим этапом является конфигурация и выбор тех данных, которые нужно опрашивать из контроллера. Эта настройка производится путём создания параметра контроллера. Параметр позволяет описать перечень данных, получаемых у контролера и передать их в окружение OpenSCADA — модель данных.
Для добавления нового параметра откроем страницу нашего объекта контроллера и в контекстном меню пункта "KM 101" нажмём "Добавить" — назовём "AT101_1 (AT 101_1)".
Страница конфигурации полученного параметра приведена на рисунке 4.1.6. Эта страница содержит раздел состояния и оперативного управления. В поле "Тип" содержится тип параметра, в нашем случае это "Стандартный". Параметр мы включаем установив флажок напротив соответствующего поля. Включенный параметр участвует в процессе обмена с контроллером.
В разделе "Конфигурация" непосредственно содержится конфигурация параметра. Установим следующие из них, оставив все остальные без изменения:
- "Включать" указывает на необходимость перевода объекта в режим "Включен" при запуске программы — установим это поле.
- "Перечень атрибутов" содержит конфигурацию атрибутов параметра относительно к регистрами и битами 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.
В случае успешного обмена с физическим контроллером мы также получим описанные данные контроллера в инфраструктуре OpenSCADA — модели данных. Увидеть эти данные можно во вкладке "Атрибуты" наших параметров AT101_1 (Рис.4.1.8) и AT101_2. Поскольку сбор производится регулярно и с периодичностью в секунду, то мы можем наблюдать их изменение нажимая кнопку "Обновить текущую страницу" на панели инструментов.
На этом конфигурация сбора данных считается законченной.
4.2 Обработка полученных данных ТП
Часто встречается ситуация, когда исходные данные, полученные из источника данных, являются "сырыми", т.е. неготовыми или неудобными для визуального представления, поэтому необходимо выполнить эту подготовку. В нашем примере мы получили данные, которые поступают в коде от шкалы внутри контроллера и наша задача — выполнить расчёт реальных значений из полученных данных. Обработку данных в OpenSCADA можно делать как непосредственно при визуализации, так и в подсистеме Сбор Данных. Однако смешивание процесса визуализации и обработки входных данных вносит путаницу в конфигурацию, не позволяет вести историю реальных данных, делает полученные образы визуализации мало пригодными для повторного использования и увеличивает нагрузку на поток визуализации, чем уменьшает общую её отзывчивость. Соответственно, выполним подготовку данных в подсистеме Сбор Данных.
Вычисления в подсистеме Сбор Данных для получения реальных данных в основном выполняются посредством модуля логического уровня LogicLev и шаблонов параметров подсистемы Сбор Данных. Модуль ModBus является тем случаем, когда такое вычисление можно сделать прямо в нём, что мы ниже увидим. Детальнее ознакомиться с концепцией Логического Уровня можно по ссылке.
Для выполнения вычислений, в модуле Логического Уровня нужно предварительно создать библиотеку шаблонов нашего проекта и шаблон параметра подсистемы Сбор Данных в ней. Для создания библиотеки шаблонов откроем страницу подсистемы Сбор Данных и, посредством контекстного меню, создадим объект библиотеки шаблонов start (Запуск). Страница конфигурации полученного объекта библиотеки шаблона (Рис.4.2.1) содержит раздел состояния и оперативного управления "Состояние" и раздел настроек "Конфигурация" в котором содержатся только типовые поля конфигурации и которые оставим неизменными. В целом мы имеем:
- Раздел "Состояние":
- сделать библиотеку доступной — установив флажок напротив соответствующего поля;
- указать хранилище — оставим "Общее Хранилище" проекта;
- можем проконтролировать дату последней модификации.
- Сохранить объект.
Для создания шаблона откроем страницу ново-созданной библиотеки шаблонов "Start"->"Сбор Данных"->"Библиотека шаблонов"->"Запуск" и, посредством контекстного меню, создадим объект шаблона airCooler (Воздушный холодильник). Страница конфигурации полученного объекта шаблона (Рис.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;
Cохраним полученный шаблон и установим флаг доступности (Рис.4.2.2).
Теперь создадим объект контроллера и параметры в модуле "LogicLev" подсистемы "Сбор данных". Объект контроллера "LogicLev" и его параметры создаются идентично ранее созданным в модуле "ModBus", на странице "Start"->"Сбор Данных"->"Модуль"->"Логический уровень". Назовём их идентично объектам модуля "ModBus".
Объект контроллера модуля LogicLev (Рис.4.2.4) не имеет специфических настроек и установленные по умолчанию можно не трогать, кроме поля "Планирование вычисления", которое установим в 1 (одну) секунду. Перед добавлением параметров нужно включить объект контроллера — установим флаг "Включен".
Параметр объекта контроллера модуля LogicLev (Рис.4.2.5) из специфических настроек имеет "Тип", где нужно установить "Логический", а в поле "Шаблон параметра" выбрать адрес созданного нами шаблона.
Кроме базовой конфигурации параметра нужно сконфигурировать и подключенный шаблон (Рис.4.2.6). Вкладка конфигурации шаблона появляется в режиме параметра "Включен". Включить параметр можно включив предварительно объект контроллера. Флаг "Показать атрибуты" позволяет устанавливать отдельно каждую связь (Рис.4.2.7). Поскольку в шаблоне мы предусмотрительно описали формат связей в виде "Параметр|Ti", то все три связи мы можем установить просто указав адрес к параметру в объекте контроллера "ModBus". Укажем-выберем адрес ModBus.CM101.AT101_1 и ModBus.CM101.AT101_2 в соответствующих параметрах.
Нужно отметить, что все поля ввода адресов объектов в OpenSCADA снабжены механизмом набора адреса. Данный механизм подразумевает поэлементный выбор, в процессе которого происходит движение в глубь. Например, в начале набора адреса "ModBus.CM101.AT101_1" мы будем иметь возможность выбора типа источника данных, среди которых будет "ModBus". Выбрав который в перечень доступных элементов для выбора добавятся объекты контроллера модуля ModBus где будет "ModBus.CM101"; выбор элемента "ModBus.CM101" добавит параметры контроллера и т.д. до конечного элемента согласно иерархии объектов. Для возможности возврата на уровни выше, список выбора содержит элементы всех вышестоящих уровней от текущего значения адреса.
Сохраним созданные объекты контроллера и параметров, после чего запустим объект контроллера на исполнение, установив флаг "Выполняется" в разделе "Состояние". Если мы ничего не пропустили, то вычисление успешно запустится и в поле "Статус" мы получим похожее на рисунке 4.2.8.
В случае успешной обработки кода шаблона в параметрах мы получим обработанные данные в инфраструктуре (модели данных) OpenSCADA. Увидеть эти данные можно на вкладке "Атрибуты" наших параметров AT101_1 (Рис.4.2.9) и AT101_2.
На этом конфигурацию обработки данных считаем законченной.
4.3 Комплексный объект-тег сигнала
В предыдущих разделах был описан механизм подключения источника данных по объекту аппарата — "Воздушный холодильник", который предусматривает объединение всех сигналов в одном объекте параметра источника данных. Однако, более распространённым подходом крупной автоматизации является формирование объекта параметра вокруг отдельного сигнала, например — "Температура на выходе холодильника AT101_1 (TE1314_1)", которые часто называются тегами.
Создание объекта параметра вокруг сигнала позволяет формализовать его описание до шаблонов аналоговых и дискретных сигналов, включив в них всю необходимую обработку, сигнализацию и другую характерную информацию. Для простой конфигурации типизированных аналоговых и дискретных сигналов, в библиотеках OpenSCADA предусмотрены шаблоны параметров и многие образы визуального представление адаптированны к работе и связыванию с такими параметрами прямо, без детализации по атрибутам.
Moreover, unified templates are provided with the possibility of deep processing of input signals by defining in the field "Input processing procedure" for a procedure on the internal language JavaLikeCalc. And even more, in this procedure it is possible to expand the template data model of the parameter with auxiliary dynamic attributes, actually "hanging" on it the elements of the device object, starting from its main signal; that is without creating additional templates for this. Like this for appending an attribute for setting input manually:
if(ctx.f_start == null) {
ctx.f_start = true;
this.attrAdd("setIn", "Input set", "real");
this.setIn.set(0);
}
in = this.setIn.get();
Обычно, для формирования параметра на основе шаблона, используется модуль логического уровня LogicLev, как это было описано в предыдущем разделе. Однако ряд модулей, в том числе и ModBus, предоставляют возможность сразу создавать логические параметры, на основе шаблона. Добавим новые параметры, открыв в конфигураторе страницу нашего, ранее созданного, объекта контроллера "ModBus" и в контекстном меню пункта "КМ 101" нажмём "Добавить".
Назовём аналоговый параметр TE1314_1 (TE1314_1), (Рис.4.3.1). Тип параметра установим в "Логический", шаблон параметра выберем "base.anUnif", описание установим в "Температура на выходе AT101_1", установим флажки "Включать" и "Включен". Далее нам нужно настроить:
- Шаблон параметра в появившейся вкладке "Конфигурация шаблона" (Рис.4.3.2):
- поле "Вход" устанавливаем в значение адреса ModBus-регистра этого параметра — "R:101";
- поле "Максимум шкалы модуля" устанавливаем в значение — 65535, что соответствует 100 °C.
- Вкладка "Атрибуты" (Рис.4.3.3):
- "Ед. измерения" устанавливаем в — "град. С";
- "Шкала: минимум" в — 0;
- "Шкала: максимум" в — 100;
- "Граница верхняя ав." в — 40;
- "Граница верхняя пред." в — 30.
- Сохраним объект.
Дискретный параметр назовём — CB102 (КШ102). Тип параметра установим в "Логический", шаблон параметра выберем "base.digitBlockUnif", установим флажки "Включать" и "Включен". Далее нам нужно настроить:
- Шаблон параметра в появившейся вкладке "Конфигурация шаблона" (Рис.4.3.4):
- поле "Команда 'Открыть'" устанавливаем в значение адреса ModBus-бита этого параметра — "C:100:rw";
- поле "Состояние 'Открыт'" устанавливаем в значение адреса ModBus-бита — "C:101";
- поле "Состояние 'Закрыт'" устанавливаем в значение адреса ModBus-бита — "C:102";
- поле "Время удерж. команды" устанавливаем в — 0, поскольку команда не импульсная.
- Вкладка "Атрибуты" (Рис.4.3.5) — удостоверяемся в доступности команды и состояний.
- Сохраним объект.
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.gen", а затем пункт "<<Добавить текущий>>" вверху этого списка.
- Запустим исполнение объекта контроллера.
Если всё сделано правильно то автоматически создадутся параметры выбранного контроллера и мы сможем посмотреть на данные в них на вкладке "Атрибуты" (Рис.4.4.2).
4.5 Архивирование-история данных ТП
Полученные выше данные считаются текущими, т.е. таковыми, которые периодически обновляются и характеризуют значение параметра ТП на настоящий момент времени. При этом, ранее считанные значения теряются при перезаписи их текущим, т.е. отсутствует их история. Во многих-же задачах требуется ведение архива-истории прочитанных значений параметров ТП, для чего в OpenSCADA предусмотрена подсистема "Архивы-История" где нам нужно создать архиваторы значений и сообщений, для нарушений, и указать наши параметры для архивирования их значений там.
Если не создать архиваторов и не подключить наших параметров на архивирование ими, то на графиках вы не получите истории более его общей ширины, а также потеряете накопленное при переключении, а в отчётных документах не получите истории вообще.
Начнём с архивации значений, для которой нужно создать хотя-бы один архиватор для нужного типа хранилища и периодичностью значений. Вообще, OpenSCADA содержит два модуля архивации — на файловую систему "FSArch" и на базу данных "DBArch". Тут мы рассмотрим только модуль архивации на файловую систему, как наиболее универсальный и эффективный. Что касается периодичности значений для "качественного" архиватора, то её в основном нужно выбирать по периодичности значений самого медленного источника данных в нашей системе, который у нас один и периодичность мы ему указали 1 секунда. Для создания архиватора значений откроем страницу модуля архивирования "Start"->"Архивы-История"->"Модуль"->"Архиватор на файловую систему" и посредством контекстного меню создадим объект архиватора значений "1s". Обратите внимание на значение поля "Тип элемента" диалога создания, которое должно быть "Архиватор значений"! Страница конфигурации полученного объекта архиватора значений (Рис.4.5.1) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:
- Раздел "Состояние":
- запустить архиватор на исполнение — установим флажок напротив соответствующего поля, только выполняющийся архиватор осуществляет архивирование;
Установить в последнюю очередь и после выполнения всего этого списка.
- можем проконтролировать текущее и максимальное время сеанса архивирования;
- указать хранилище — оставим "Общее Хранилище" проекта;
- можем проконтролировать общий размер файлов архива этого архиватора.
- Раздел "Конфигурация":
- установить запуск архиватора при запуске программы — установим флажок напротив соответствующего поля;
- установить адрес директории с файлами архива — "ARCHIVES/VAL/1s", что ставится по умолчанию;
- установить период значений — 1 (одна) секунда;
- установить период архивирования — 60 секунд, по умолчанию и обычно одинаков для архиваторов с любой периодичностью значений.
- Сохранить объект.
Одного "качественного" архиватора уже достаточно для большинства задач, но если вы планируете строить графики-тренды значений и отчётные документы на большую глубину (сутки, недели, месяца) то нужно создать ещё пару архиваторов с большей периодичностью значений. Иначе построение графиков и документов будет продолжительным и/или будет обрезаться по лимитам времени исполнения! Обычно, в качестве таких дополнительных архиваторов создаются, и вы должны их создать идентично инструкции для "качественного" архиватора выше:
- Минутный — идентификатор "1m", адрес "ARCHIVES/VAL/1m" и период значений 60 секунд.
- Часовой — идентификатор "1h", адрес "ARCHIVES/VAL/1h" и период значений 3600 секунд.
Новосозданные проекты OpenSCADA уже содержат шаблоны таких стандартных архиваторов, поэтому вы можете просто включить нужные.
Для включения архивирования атрибутов "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.
В результате этой операции будут автоматически созданы объекты архивов для выбранных атрибутов. Пример объекта архива для атрибута "Ti" параметра AT101_1 представлен на рисунке 4.5.3.
Обычно настройки архива менять не нужно, однако, если потребуется особая конфигурация, то её можно сделать на указанной выше странице. Чаще может понадобиться получение информации об архиве. Например, узнать размер архива как по времени, так и на носителе, а также взглянуть на график параметра (Рис.4.5.4).
Объекты контроллеров, как и отдельные шаблоны параметров, могут формировать сообщения о нештатных ситуациях, например — шаблоны комплексных сигналов-тегов генерируют сообщения при выходе значения за одну из границ. Сообщения такого характера имеют специфическую категорию и именуются нарушениями.
Сообщения OpenSCADA предварительно попадают в буфер сообщений, который и выступает первичным архивом. Однако буфер имеет ограничение и хранится только в оперативной памяти, т.е. теряется при перезапуске программы. Роль сохранения сообщений на том или ином хранилище выполняют архиваторы сообщений, как архиваторы значений для значений.
Соответственно создадим архиватор сообщений для архивации нарушений, для чего откроем страницу модуля архивирования "Start"->"Архивы-История"->"Модуль"->"Архиватор на файловую систему" и посредством контекстного меню создадим объект архиватора сообщений alarms (Нарушения). Обратите внимание на значение поля "Тип элемента" диалога создания, которое должно быть "Архиватор сообщений"! Страница конфигурации полученного объекта архиватора значений (Рис.4.5.5) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:
- Раздел "Состояние":
- запустить архиватор на исполнение — установим флажок напротив соответствующего поля, только выполняющийся архиватор осуществляет архивирование;
- Установить в последнюю очередь и после выполнения всего этого списка.
- указать хранилище — оставим "Общее Хранилище" проекта;
- можем проконтролировать время первого и последнего сообщения в архиве этого архиватора;
- можем проконтролировать общий размер файлов архива этого архиватора;
- можем проконтролировать текущее и максимальное время сеанса архивирования.
- Раздел "Конфигурация":
- установить запуск архиватора при запуске программы — установим флажок напротив соответствующего поля;
- установить категорию сообщений, которая характеризует нарушения — "al*";
- установить уровень архивируемых нарушений — "Информация (1[X])";
- установить адрес директории с файлами архива — "ARCHIVES/MESS/alarms", что ставится по умолчанию;
- Сохранить объект.
Таким-же образом можно создать архиваторы сообщений другого характера, например — действия оператора. Для чего достаточно определить категорию этих сообщений и сформировать для них шаблон или правило регулярного выражения. Вы можете получить стандартные категории и их шаблоны, или правила регулярного выражения, на странице архивации сообщений или можете изучить реальные сообщения на главной странице подсистемы "Архивы-История", получить оттуда информацию об их категории и настроить шаблон, или правило регулярного выражения. Можно даже создать архиватор для архивирования всех сообщений программы, но делать этого не рекомендуется ввиду получения больших архивов и долгого доступа к ним потом.
Новосозданные проекты OpenSCADA уже содержат шаблоны таких стандартных архиваторов, поэтому вы можете просто включить нужные.
5 Формирование визуального представления
Формирование визуального представления может выполняться на трёх уровнях сложности и пользователь может выбрать любой из них в зависимости от требований задачи, уровня своих знаний и наличия библиотек с готовыми образами и шаблонами.
ПЕРВЫЙ УРОВЕНЬ требует минимальной квалификации пользователя, но подразумевает наличие библиотек шаблонных кадров, нужных для решения его задачи. В рамках первого уровня пользователю достаточно знать, как подключить динамику к страницам шаблонных кадров и как добавить новые страницы шаблонных кадров.
ВТОРОЙ УРОВЕНЬ предусматривает дополнительную способность — создавать новые кадры на основе готовых-комплексных элементов путём простого их размещения в области кадра. Для обеспечения этого квалификационного уровня, пользователю понадобятся библиотеки комплексных элементов, нужных для решения его задачи.
ТРЕТИЙ УРОВЕНЬ предусматривает владение всеми инструментами среды разработки визуальных интерфейсов OpenSCADA, включая создание новых комплексных элементов и разработку интерфейсов пользователя в проекте.
Все действия над интерфейсом визуализации будем выполнять в окружении модуля Vision подсистемы "Пользовательские интерфейсы". Для открытия окна интерфейса Vision нажмём вторую иконку справа панели инструментов конфигуратора. В результате получим окно, ранее представленное на рисунке 3.3.1.3.
Интерфейсы пользователя-оператора в OpenSCADA реализуются проектами визуализации. В библиотеке основных элементов пользовательского интерфейса присутствует шаблон типового проекта визуализации, основанного на концепции объектов сигнализации и видов отображения. Пользователь может начать создавать свою концепцию интерфейса визуализации, в виде нового проекта, а может использовать указанный шаблон.
Для реализации новой концепции проекта визуализации потребуются знания третьего уровня и значительные усилия, что находится за рамками рассмотрения этого документа. Поэтому будем рассматривать создание интерфейса визуализации на основе доступного шаблонного проекта.
Скопируем проект "Группы сигнализации (шаблон)", нажав сначала кнопку "Копировать визуальный элемент" на нём, а затем кнопку "Вставить визуальный элемент" (Рис.5.1). В диалоге назовём наш новый проект start (Старт) и в списке проектов получим пункт нашего нового проекта (Рис.5.1).
Перед использованием и сохранением нового проекта (Рис.5.3) нужно изменить его хранилище на "Общее Хранилище", что мы можем сделать на главной странице диалога свойств визуального элемента, вызываемого по кнопке "Свойства визуального элемента" (Рис.5.2). После чего сохраним наш новый проект нажав третью кнопку слева панели инструментов.
Шаблонный проект (Рис.5.3) содержит две ветви — "Панели управления" и "Корневая страница". Ветвь "Панели управления" содержит набор кадров типовых панелей управления и специализированных кадров. Ветвь "Корневая страница", с корневой страницей в основе, содержит подветви объектов сигнализации "Группа 1", "Группа 2" и отдельную ветвь сводных графиков "Сводные графики". Подветви объектов сигнализации "Группа {n}" имеют цифровой идентификатор и могут расширяться добавлением вплоть до стольких, названия скольких поместятся наверху в два ряда. Присутствие подветви "Группа {n}" отражается на активации соответствующей кнопки объекта сигнализации корневой страницы, что позволяет на них переключаться. Каждая подветвь "Группа {n}" содержит контейнеры или шаблоны видов отображения, обычно: "Мнемосхемы", "Группы графиков", "Группы контуров", "Группы обзорных кадров" и "Документы". Наличие страниц в контейнерах отображений включает возможность выбора этого отображения для соответствующего объекта сигнализации корневой страницы. Детальнее ознакомиться со структурой корневой страницы можно по ссылке.
5.1 Добавление шаблонной страницы и подключение динамики
Рассмотрим задачу первого уровня сложности, когда к уже разработанной концепции интерфейса нужно подключить динамику шаблонной страницы. Понятие "Шаблон страницы" подразумевает страницу, на основе которой и путём наследования может создаваться множество конечных страниц визуализации с индивидуальным перечнем динамики. Примером таких страниц являются: "Группа графиков", "Группа контуров", "Группа обзорных кадров" и "Сводные графики". На Рис.5.1.1 представлена шаблонная страница "Группа графиков" в дереве нашего проекта "Старт".
Шаблонная страница "Группа графиков" предоставляет возможность подключить до восьми сигналов одновременного их отображения на графике. Элементы отображения значения сверху автоматически скрываются для неустановленных связей.
Создадим новую группу графиков в шаблонном контейнере "Группа графиков" первой группы корневой страницы. Для этого в контекстном меню пункта "Группа графиков" выберем пункт меню "Добавить визуальный элемент" (Рис.5.1.2), делее введём идентификатор "2" и название "Графики 2" — 2 (Графики 2).
После подтверждения ввода имени будет создана новая страница, однако для её активации нам понадобится её включить. Включить страницу можно в диалоге редактирования свойств страницы (Рис.5.1.3). Открыть эту страницу можно посредством выбора пункта меню "Свойства визуального элемента" в контекстном меню только что созданной страницы. Создать страницу в логическом контейнере на основе шаблона можно и простым копированием шаблона в самого себя, а также копированием другой страницы этого контейнера, но уже и со связями.
После включения страницы можно приступать к установке связей на созданные ранее параметры контроллеров. Для этого, не покидая диалога редактирования свойств только что созданной страницы (Рис.5.1.3), перейдём на вкладку "Связи" (Рис.5.1.4). На этой вкладке мы увидим дерево с элементами "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. Заметьте, что для параметра комплексного объекта-тега с установленными границами нарушений, выход значения за границы отмечается аварийным цветом. Для того что-бы увидеть выход за границу нарушения можете установить значение производительности вентилятора в 100 (Рис.4.2.9).
5.2 Создание нового кадра — мнемосхемы
Поднимем планку и создадим новый кадр, куда поместим базовые элементы отображения значений параметров наших контроллеров. Такие кадры обычно называются мнемосхемами и кроме отображения динамики, и даже в первую очередь, содержат статическое изображение технологического процесса в мнемоническом представлении. Мы же не будем акцентировать тут внимание на создание статики, а добавим элементы динамики и подключим к ней параметры наших контроллеров. Ну и поместим созданный кадр в дерево нашего проекта.
Новые кадры, предназначенные впоследствии для помещения в проект, принято создавать и изменять в библиотеке виджетов. Создадим новую библиотеку виджетов выбрав вертикальную вкладку "Виджет" и в контекстном меню окна библиотек виджетов выберем пункт меню "Новая библиотека" (Рис.5.2.1). В диалоге ввода имени укажем — CM101 (KM 101).
Далее добавляем новый кадр, выбрав пункт меню "... из Библиотеки"->"Библиотека: originals"->"Группа элементов" (Рис.5.2.2) в контекстном меню созданной библиотеки "KM 101". В диалоге ввода названия укажем AT101 (AT 101). В основе любого кадра и страницы должен лежать элемент "Группа элементов (Box)" поэтому мы его и выбрали.
Сразу после создания нового кадра нужно установить его базовые свойства, характерные для кадра мнемосхемы. Свойства или атрибуты любого визуального элемента можно указать в панели инструментов "Атрибуты", предварительно выбрав нужный визуальный элемент. Выберем созданный кадр "AT 101" и установим следующие свойства:
- "Геометрия: ширина" — 900;
- "Геометрия: высота" — 600;
- "Страница: группа" — "so", для включения кадра в контейнер мнемосхем при исполнении;
- "Фон: цвет" — "#5A5A5A";
- "Граница: ширина" — 1;
- "Граница: цвет" — "black".
В результате получим пустой кадр (Рис.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.
На этом процедуру создания мнемосхемы будем считать законченной. Сохраним новую библиотеку виджетов "KM 101" и приступим к этапу размещения нашей мнемосхемы в дереве проекта "Старт".
Поместим нашу мнемосхему в ветвь "Старт"->"Корневая страница"->"Группа 1"->"Мнемосхемы" путём выбора пункта меню "... из Библиотеки"->"Библиотека: CM101"->"AT 101" в контекстном меню пункта страницы проекта "Мнемосхемы". Идентификатор новой мнемосхемы установим в "2" при этом поле имени оставим пустым — 2.
Далее нужно произвести уже знакомую нам по предыдущей главе операцию, а именно — установку связей на ранее созданные параметры контроллеров. Для этого откроем вкладку "Связи" (Рис.5.2.5) диалога редактирования свойств мнемосхемы, где мы увидим дерево с элементами "A1_Ti", "A1_To", "A2_Ti" и "A2_To". Развернув любой из элементов мы увидим ветку "Parameter" в которой мы должны указать или выбрать адрес значений "pVal" наших атрибутов "Ti" и "To" соответственно. В процессе заполнении элементов часть свойств нужно указывать постоянными:
- "pName" — "val:AT101_1 Ti".
Как и в случае с группой графиков в предыдущем разделе, для комплексных параметров объекта-тега ModBus.CM101.TE1314_1 и ModBus.CM101.CB102 можно указать только параметр и атрибуты расставятся автоматически.
Теперь можем сохранить нашу мнемосхему и поглядеть на результат. Для этого закроем окно диалога свойств и запустим наш проект "Старт" на исполнение. Затем кнопками перелистывания переключимся на нашу мнемосхему и в случае безошибочной конфигурации мы должны увидеть подобное рисунку 5.2.6.
Заметьте, что выход значения комплексного параметра объекта-тега за границы нарушений отмечается миганием через аварийный цвет для: параметра, объекта сигнализации и жёлтого кружочка внизу. Кроме мигания при нарушении осуществляется монотонная сигнализация (часто на бузер) и синтез речи с проговором позиции параметра указанной в поле связи "spName" (Рис.5.2.5) если доступен соответствующий синтезатор речи. При активации нарушения, справа и справа-внизу активируются кнопки с индикацией типа уведомления, а по нажатию на них осуществляется квитация соответствующего типа уведомления. По нажатию на мигающий жёлтый круг справа-внизу "квитируются"-замалчиваются все уведомления. Факт присутствия нарушения также отображается записью в протоколе, который мы добавили. Чтобы увидеть выход за границу нарушения можете установить значение производительности вентилятора в 100 (Рис.4.2.9). Детальнее про концепцию работы с нарушениями можно почитать в документе "Как сформировать нарушения, сигнализацию и уведомления".
Историю нарушений можем посмотреть в документе "Протокол нарушений", который доступен при выборе вида "Документ" (Рис.5.2.7).
Дискретный комплексный параметр объекта-тега ModBus.CM101.CB102, представленный нами в виде шарового крана, является активным. Т.е. его можно выбрать, получив панель управления справа (Рис.5.2.6), а также передать команды (открыть или закрыть). Команды можно передавать с панели управления или через контекстное меню. Все действия оператора по управляющим воздействиям протоколируются и документ протокола можно посмотреть при выборе вида "Документ" (Рис.5.2.8).
5.3 Создание нового комплексного элемента
Приступим к рассмотрению задачи третьего уровня сложности, а именно к созданию комплексного элемента. Создание комплексного элемента, включающего в себя комбинацию различных базовых примитивов, может осуществляться в несколько этапов. В качестве примера рассмотрим задачу, состоящую из двух этапов:
- создание виджета "Воздушный холодильник" на основе примитива "Элементарная фигура";
- создание финального-скомпонованного виджета "Холодильник" на основе примитива "Группа элементов".
5.3.1 Создание виджета "Воздушный холодильник" на основе примитива "Элементарная фигура"
Виджет будем создавать в ранее нами созданной библиотеке "КМ 101". Для этого кликаем правой кнопкой манипулятора "мышь" по пункту этой библиотеке и выбираем пункт меню "... из Библиотеки"->"Библиотека: originals"->"Элементарная фигура" как это показано на рисунке 5.3.1.1 и называем новый елемент air_cooler (Воздушный холодильник).
После подтверждения появится новый виджет с именем "Воздушный холодильник", выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования посредством контекстного меню нового элемента (Рис.5.3.1.2). В инспекторе атрибутов установим свойства:
- "Геометрия: ширина" — 200;
- "Геометрия: высота" — 200;
- "Заполнение: цвет" — "lightgrey", цвет можно задавать как с помощью названий цветов, так и в формате #RRGGBB (#RRGGBB-AAA).
Теперь изобразим визуальное представление виджета, что можно осуществить двумя способами:
- нарисовать желаемое изображение манипулятором "мышь", используя "Линию", "Дугу", "Кривую Безье" и "Заливку"; соответствующая панель "Панель элементарных фигур" появится после входа в режим редактирования-рисования; вход в этот режим осуществляется как показано на рисунке 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.
Создадим иконку нашего виджета, которая будет видна в дереве виджетов библиотеки "KM 101" (Рис.5.3.1.5).
На этом процесс создания первого виджета можно считать завершенным. Перейдем к этапу компоновки и создания результирующего виджета.
5.3.2 Создание финального-скомпонованного виджета "Холодильник" на основе примитива "Группа элементов"
Финальный виджет будем создавать в библиотеке "KM 101" для чего кликаем правой кнопкой манипулятора "мышь" по этой библиотеке и выбираем примитив "Группа элементов" как это показано на рисунке 5.3.2.1. Назовём новый элемент — elCooler (Холодильник).
После подтверждения появится новый виджет с именем "Холодильник". Выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования. В инспекторе атрибутов установим свойства:
- "Геометрия: ширина" — 250;
- "Геометрия: высота" — 200.
Возьмём ранее созданный элемент "Воздушный холодильник" и перетащим его — нажмём на нем левую кнопку манипулятора "мышь" и переместим курсор до области только что созданного виджета, где отпустим кнопку (Рис.5.3.2.2).
В результате появится окно диалога с предложением ввести идентификатор и имя нового виджета. Идентификатор и имя могут быть заданы произвольно, мы введём идентификатор air_cooler, а имя оставим пустым и оно унаследуется от родителя — элемента "Воздушный холодильник". Таким образом, только что созданный виджет внутри контейнера "Холодильник" унаследует элемент "Воздушный холодильник". После подтверждения ввода идентификатора и имени, виджет "Воздушный холодильник" добавится в нашем виджете-контейнере "Холодильник" (Рис.5.3.2.3). В инспекторе атрибутов установим для него свойства:
- "Геометрия: x" — 25;
- "Геометрия: y" — 0.
Далее развернем пункт меню библиотеки "Элементы мнемосхемы", найдем там элемент "Вентилятор 2" и перетащим его на виджет-контейнер. Этот элемент будет динамически отображать интенсивность работы воздушного холодильника. Для нового виджета введём идентификатор cooler2 и имя снова оставим пустым, после чего виджет "Вентилятор 2" добавится в наш виджет-контейнер "Холодильник". Таким образом, только что созданный виджет внутри контейнера "Холодильник" унаследует элемент библиотеки "Элементы мнемосхемы" — "Вентилятор 2". В инспекторе атрибутов установим свойства:
- "Геометрия: x" — 75;
- "Геометрия: y" — 30;
- "Геометрия: z" — 10, поднять элемент над всеми можно из панели "Функции видимости виджетов";
- "Цвет1" — "#FFFF00-200", добавили альфа канал — прозрачность 200 ("0" - полностью прозрачный, "255" - полностью непрозрачный), рисунок 5.3.2.4;
- "Цвет2" — "#FF0000-200", добавили альфа канал — прозрачность 200.
Теперь в виджете-контейнере "Холодильник" добавим два текстовых поля основанных на примитиве "Текст" с целью отображения входной и выходной температур потока. Для этого выделим виджет "Холодильник" и на панели визуальных элементов библиотеки "KM 101" выберем пункт меню примитива "Текст" как это показано на рисунке 5.3.2.5. Для первого текстового поля введем идентификатор Ti и в инспекторе атрибутов установим свойства:
- "Геометрия: x" — 5.
- "Геометрия: y" — 20.
- "Геометрия: ширина" — 70.
- "Геометрия: высота" — 35.
- "Выравнивание" — "В центре".
- "Шрифт" — "Arial 14 1", изменение шрифта можно осуществлять в диалоге, который открывается по нажатию на ключик у поле редактирования (Рис.5.3.2.7).
- Шрифт Arial может отсутствовать в диалоге, поэтому выберете тот, который вам нравится.
- "Текст" (Рис.5.3.2.8):
%1 град.C
- "Количество аргументов" — 1 (Рис.5.3.2.9):
- "Аргумент 0: тип" — "Вещественный";
- "Аргумент 0: значение" — 300.25, задано лишь для наглядности и в режиме исполнения оно будет заменено реальным значением входной температуры;
- "Аргумент 0: конфигурация" — "3;f;2".
Теперь, с целью создания аналогичного виджета для выходной температуры, скопируем виджет "Ti", вставим скопированный виджет и укажем ему идентификатор To (Рис.5.3.2.10). В инспекторе атрибутов установим свойства:
- "Геометрия: x" — 175;
- "Геометрия: y" — 20.
Теперь добавим виджет основанный на примитиве "Элемент формы" (Рис.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
Для отображения единицы измерения производительности холодильника добавим ещё один виджет основанный на примитиве "Текст". Делаем туже процедуру, что и для виджета "Ti". Укажем идентификатор dimension (Рис.5.3.2.13) и в инспекторе атрибутов установим свойства:
- "Геометрия: x" — 125;
- "Геометрия: y" — 168;
- "Геометрия: ширина" — 80;
- "Геометрия: высота" — 20;
- "Выравнивание" — "В центре";
- "Шрифт" — "Arial 14 1";
- "Текст" — "об./мин.".
Для добавления логики обработки виджета "Холодильник", откроем диалог редактирования свойств этого визуального элемента и перейдём на вкладку "Обработка". На этой вкладке мы увидим дерево атрибутов виджета и поле текста программы обработки атрибутов. Для решения нашей задачи нужно добавить три атрибута: Ti, To, Cw (Рис.5.3.2.14); для чего нужно развернуть корневой элемент ".", выбрать любой элемент внутри него и нажать кнопку "Добавить атрибут" внизу.
Далее включим в обработку атрибут value комбобокса "cw" как это показано на рисунке 5.3.2.15. Аналогично включим в обработку атрибут arg0val для Ti и To, а также атрибут speed элемента "cooler2".
В завершении установим язык пользовательского программирования "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;
Помещение или редактирование программы виджета не приводит к непосредственной её компиляции, т.е. не будет сообщений об ошибках в программе если они имеют место быть. Это связано с тем, что непосредственное исполнение программы, а значит и её компиляция, осуществляется в окружении исполнения и в момент запуска проекта визуализации на исполнение. При этом все ошибки, возникшие при компиляции, выводятся в виде сообщений OpenSCADA, а виджеты с ошибками не исполняются. Детальнее про отладку пользовательских процедур можно почитать в документе "Как наладить проект OpenSCADA".
Processing the widget in whole and executing its program performed at any event in the life cycle of the VCA project (specified in the "Period of the calculation" field of the "Project" tab, Figure 5.2) and periodically with the widget processing period (specified in the "Periodic processing" field of the "Widget" tab, Figure 5.1.3). By default, the widget processing period is taken from top widget and it is 1000 ms, so when you want faster updating your widget, you can set "Periodic processing" to 250 ms on the "Widget" tab.
Полученная вкладка "Обработка" виджета "Холодильник" библиотеки "KM 101" будет иметь вид, показанный на рисунке 5.3.2.16.
Закроем диалог редактирования свойств визуального элемента, создадим иконку нашего элемента, закроем внутреннее окно редактирования и сохраним это всё.
На этом разработку комплексного элемента можно считать законченной.
5.3.3 Добавление комплексного элемента на мнемосхему
Для проверки работоспособности и оценки результатов наших усилий, добавим созданный виджет на мнемосхему, разработанную в разделе 5.2. Выполним эту операцию для двух холодильников "AT101_1" и "AT101_2".
Для этого откроем кадр мнемосхемы "AT 101" на редактирование, хватаем "мышью" наш комплексный элемент и тащим на мнемосхему, где отпускаем в нужной позиции — вводим идентификаторы AT101_1 и AT101_2, соответственно. Добавленные элементы располагаем как нам удобно. После выполнения этих манипуляций у нас должна получиться мнемосхема с видом на рисунке 5.3.3.1.
Сохраним новую мнемосхему и закроем её окно. Далее перейдём в проект и откроем эту мнемосхему в дереве проекта "Старт"->"Корневая страница"->"Группа 1"->"Мнемосхемы"->"AT 101". Как можно заметить, наши новые элементы появились здесь автоматически и нам осталось только подключить связи к ним, для этого откроем диалог редактирования свойств мнемосхемы на вкладке "Связи" (рис.5.3.3.2). На этой вкладке мы увидим дерево с элементами "AT101_1" и "AT101_2", развернув любой мы увидим ветвь "Parameter" с атрибутами "Ti", "To" и "Cw". Таким образом, в поле "Parameter" можем просто указать адрес параметра "prm:/LogicLev/CM101/AT101_1" и "prm:/LogicLev/CM101/AT101_2", соответственно, а атрибуты будут расставлены автоматически.
Сохраним нашу мнемосхему и проверим результат, для чего закроем окно диалога свойств, запустим проект "Старт" на исполнение и переключимся на вторую мнемосхему кнопками перелистывания. При безошибочной конфигурации должны увидеть подобное изображённому на рисунке 5.3.3.3.
На этой мнемосхеме, посредством наших комплексных элементов, мы можем не только наблюдать, но и управлять производительностью холодильников просто меняя значение в комбобоксе. Меняя производительность можем заметить и изменение температуры, и срабатывание сигнализации по комплексному аналоговому параметру объекта-тренда. Историю изменения можем увидеть и исследовать на группе графиков, созданной нами в разделе 5.1, и документе "Протокол нарушений", упомянутый в разделе 5.2.
6 Вывод
Таким образом мы получили полноценный типовой интерфейс технологического процесса (ТП) с реальным сбором данных в разный способ и соответственно получили представление и навыки работы с OpenSCADA.
При построении интерфейса ТП мы рассмотрели все три уровня сложности и соответственно получили представление про нужный квалификационный уровень программиста SCADA.
Сбор и обработку данных мы рассмотрели и осуществили в разные способы от простого-типового и по отражение модели данных ПЛК, построенного на основе OpenSCADA. Т.е., получено представление про источники данных SCADA-систем и доступ к ним с помощью сетевых интерфейсов и протоколов обмена, поддержку которых реализуют соответствующие модули OpenSCADA.
И конечно, мы рассмотрели методы распространения (дистрибуции) OpenSCADA, способы её установки и получения нужного окружения таких как: сервера SCADA, ПЛК OpenSCADA и рабочего места оператора (АРМ).
Информация про OpenSCADA этим документом не ограничивается и в разрешении специфических вопросов вы должны использовать всю доступную документацию и примеры демонстрационных конфигураций-моделей OpenSCADA, пользуясь тем самым преимуществами "открытых исходных текстов (OpenSource)". Отдельно тут нужно ещё раз отметить "Руководство по программе", "Как (How to) ..." и "Динамическую модель реального времени АГЛКС", как наиболее полные источники информации про OpenSCADA.