OpenSCADA является предельно модульной, гибкой и многофункциональной SCADA-системой. Как следствие, первое знакомство с OpenSCADA может быть достаточно сложным, по причине малых шансов совпадения предыдущего опыта пользователя, или полного его отсутствия, с подходами работы в OpenSCADA. Однако, в значительной степени, это только первое впечатление, поскольку вся мощь OpenSCADA оказывается в руках пользователя и от изобилия которой пользователь может растеряться, и ему могут понадобиться значительные усилия для отбора функций, нужных в решении его задачи.
По этой причине, и для наглядного представления общей концепции работы в OpenSCADA, создан данный документ. Документ, на реальных примерах в достаточно краткой и наглядной форме, представляет путь от установки и запуска OpenSCADA до создания элементов пользовательского интерфейса. В качестве целевой помощи в конфигурации, реализации и решения типовых задач около OpenSCADA, также могут быть использованы документы "Частые вопросы" и "Как сделать ... (How to ...)".
Документ предназначен для OpenSCADA версии 0.9 и выше. Если-же вас интересует этот документ для ранних версий тогда вы можете его получить из документации, которая идёт с пакетами той версии OpenSCADA, или из этого документа старой Wiki.
Документ не содержит детального описания концепции и погружения в детали OpenSCADA, а предоставляет ссылки на документы, содержащие такую информацию, и в первую очередь это "Руководство по программе".
Документ строится синхронно с реализацией примеров на подключении к демонстрационной базе данных (БД) модели "АГЛКС" в роли источника данных — ПЛК. Следовательно, пользователь должен получить дистрибутив OpenSCADA с этой БД, о чём детальнее в разделе "Установка"!
Установку OpenSCADA, в целом, можно осуществить двумя способами. Первый и простой способ — это получить готовые пакеты для используемого дистрибутива ОС Linux. Второй — собрать OpenSCADA из исходных текстов.
Процедура установки сильно зависит от используемого дистрибутива Linux и исчерпывающе её описать в данном руководстве не представляется возможным. Поэтому может понадобиться глубокое знакомство с механизмами установки ПО выбранного дистрибутива Linux из его документации. В случае отсутствия у пользователя таких знаний, умений и предпочтений к какому либо дистрибутиву Linux, настоятельно рекомендуется выбирать его по критерию наличия для него пакетов OpenSCADA и даже репозитория пакетов, что обеспечит простейшую и беспроблемную установку.
Если у пользователя вызывает затруднение установка не только OpenSCADA, но и дистрибутива Linux, то, на первое время, он может воспользоваться "живым" дистрибутивом Linux с установленной и готовой для работы и изучения демонстрацией и полноценной OpenSCADA. Если его устроит такое окружение быстрой доступности то он может остановить свой выбор на нём и установить. На данный момент доступны "живые" сборки на основе дистрибутива Debian и ALTLinux (устаревшее) в виде гибридных CD/DVD/USB-образов, на странице: http://oscada.org/ru/glavnaja/zagruzit. Детальнее смотрите в документе рецепта (How to ...) "Живой диск (Live CD/DVD/USB)".
Установка из готовых пакетов, в свою очередь, может осуществляться двумя методами. Первый — простейший, когда пакеты OpenSCADA уже присутствуют в собственных репозиториях пакетов OpenSCADA или официальных, дополнительных репозиториях используемого дистрибутива ОС Linux. Установка таких пакетов это вопрос запуска типовой программы управления пакетами дистрибутива с последующим выбором пакетов OpenSCADA. Кроме простой установки, репозитрий пакетов в целом позволяет просто содержать операционную систему обновленной, безопасной и актуальной! Второй способ подразумевает получение пакетов OpenSCADA и установку их вручную.
Проверить наличие пакетов OpenSCADA в репозиториях дистрибутивов Linux или OpenSCADA, а также загрузить пакеты OpenSCADA для ручной установки, можно на странице загрузки официального сайта OpenSCADA. Здесь Вы также можете получить конфигурацию для подключения репозиториев пакетов OpenSCADA к пакетному менеджеру вашего дистрибутива Linux.
Загружать пакеты и подключать репозитории пакетов нужно непосредственно для версии используемого дистрибутива иначе, при установке, могут возникнут неразрешимые проблемы с зависимостями.
Репозитории с пакетами предоставляются самим проектом OpenSCADA, служебная информация которых обычно располагается рядом с самими пакетами и обновляется автоматически при сборке, т.е. эти репозитории являются наиболее свежими и предпочтительными. Хотя пакеты OpenSCADA всё ещё можно встретить в репозиториях таких дистрибутивов ОС Linux: ALTLinux и дистрибутивах, основанных на пакетной базе Fedora, но они там, скорее всего, будут старые, поскольку сборка в репозитории дистрибутивов разработчиками сейчас не практикуется!
Адреса репозиториев и конфигурацию менеджера репозиториев Вы можете получить на той-же странице загрузки OpenSCADA (http://oscada.org/ru/glavnaja/zagruzit/) или в примерах ниже.
При установке из репозитория выбираем только пакет с конфигурацией проекта 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/9/openscada ./"
Ubuntu (LTS): "deb http://ftp.oscada.org/OpenSCADA/LTS/Ubuntu/18.04 ./"
Ubuntu (Work): "deb http://ftp.oscada.org/OpenSCADA/Work/Ubuntu/18.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
Для ручной установки пакетов OpenSCADA их нужно загрузить из официального сайта или другого источника. Загрузить обычно можно два набора пакетов.
Первый набор представлен одиннадцатью пакетами:
Второй набор представлен порядка пятьюдесятью пакетами, с выделением модулей OpenSCADA в отдельные пакеты:
Первый набор пакетов больше предназначен для простой-ручной установки, поскольку содержит только одинадцять пакетов. Второй набор предназначен для помещения в репозиторий дистрибутива 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
Если нет возможности получить готовые пакеты OpenSCADA для выбранного дистрибутива, то остаётся только вариант сборки OpenSCADA из исходных текстов. Этот процесс детально описан в руководстве по сборке OpenSCADA из исходных текстов.
Для наших основных задач с OpenSCADA, в рамках этого документа, нужно установить пакет с БД модели "АГЛКС" — openscada-model-aglks, про что можно детально узнать из предыдущего раздела. Конечно, если вы используете Живой Диск то у вас всё нужное уже есть.
Не рассматривайте тут установку-сборку OpenSCADA из исходных текстов поскольку требование квалификационного уровня пользователя, для этой задачи, значительно выше уровня документа в целом и тут неизбежно будут несоответствия с руководством, ввиду крайне вероятных различий в исходной конфигурации.
Установленная БД модели "АГЛКС" не нуждается в предварительной настройке. Если-же нужно выполнить особую настройку, которая отличается от базовой, то воспользуйтесь руководством по программе. В процессе чего Вам может понадобиться информация про типовые учётные записи и пароли OpenSCADA (не имеют отношения к учётным записям ОС), хотя модели и ново-созданные конфигурации запускаются от привилегированного пользователя и Вы можете легко изменить любую из них:
Демонстрация OpenSCADA, на основе БД модели "АГЛКС", это не тоже, что обычно предоставляют коммерческие производители ПО с целью продемонстрировать возможности, но исключить или усложнить нормальную работу, путём ограничения функций. Демонстрация OpenSCADA это полно-функциональная программа, предоставляющая примеры реализации и настройки различных компонентов. На основе БД модели "АГЛКС", и других моделей OpenSCADA, можно легко создавать собственные проекты, используя предоставленные наработки. Полноценность демонстрации OpenSCADA имеет исключение для закрытых платформ и платформ с преобладанием закрытого ПЗ.
Динамическая модель компрессорной станции на 6 газовых компрессоров, которая лежит в основе демонстрационной БД, требует заметных ресурсов, а именно — процессора с частотой более 1 ГГц (x86) и памяти до 200МБ. Данные вычислительные ресурсы требуются непосредственно для динамической модели и не являются общим показателем ресурсоёмкости программы в конечных задачах! Требования к памяти, наоборот, являются типовым показателем для графической станции АРМ похожей сложности.
Общий процесс конфигурации SCADA-системы, для исполнения функций верхнего уровня — АРМ оператора, можно условно разделить на два этапа:
Итак, нашей конечной целью и целью этого документа является построение полноценной конфигурации локальной SCADA-станции, объединённую с сервером, и с эмуляцией источника данных на основе этой демонстрационной БД (Рис.3).
По ходу, мы ознакомимся с такими важными ролями OpenSCADA как: сервер сбора, архивации, визуализации; среда исполнения ПЛК и удаленная разработка. Но перед этим мы осмотрим OpenSCADA и её возможности в целом.
Запустить локальное исполнение 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-браузера.
Все действия в дальнейшем мы будем рассматривать только в интерфейсе модуля Vision.
Таким образом мы запустили демонстрацию OpenSCADA и познакомились с основным набором инструментов. В дальнейшем будем их использовать в конфигурации OpenSCADA для выполнения функций верхнего уровня — АРМ оператора, и других задач.
Закроем программу через соответствующий пункт меню "Файл", что нужно сделать обязательно, иначе её дальнейший фоновый запуск не сможет открыть портов, занятых уже этой программой.
Все консольные операции можете выполнить в консольном терминале, например, программа "konsole" в окружении Живого Диска из диалога запуска по Alt+F2. И каталог "{HOME}" тут это "/home/user".
Организация проекта OpenSCADA в отдельном каталоге делает простым запуск готовых проектов в пространстве сервиса — исполнение в фоне, а также дальнейшее обновление и сопровождение этого проекта без прямого удаленного контроля. Фактически, вы можете разрабатывать проект локально, держа его каталог в пользовательском рабочем каталоге (типично "{HOME}/.openscada"), а для запуска в пространстве сервиса только копировать или паковать, передавать на удалённое рабочее устройство и распаковывать в системный рабочий каталог (типично "/usr/share/openscada").
Сервисное-фоновое исполнение программ в Linux обслуживается соответствующим образом сформированным сценарием-скриптом, который размещается в каталоге "/etc/ini.d" и должен быть отдельным на каждый проект OpenSCADA, который запускается в сервисном пространстве. Для упрощения и исключения необходимости заниматься созданием собственных сценариев, OpenSCADA предоставляет соответствующие для стандартных случаев-профилей и которые обычно поставляются пакетами openscada-server и openscada-plc.
Соответственно, для запуска в пространстве сервиса скажем библиотечного проекта "АГЛКС" мы:
# Подключиться от суперпользователя
$ su -
# ... для живого диска и некоторых других окружений Linux
$ sudo bash
# Остановить исполнение предыдущей конфигурации сервера и удалить его каталог
$ service openscada-server stop; rm -R /usr/share/openscada/server
# Скопировать проект "АГЛКС" из домашнего каталога пользователя "{HOME}" с переименованием в "server"
$ cp -R {HOME}/.openscada/AGLKS /usr/share/openscada/server
# Запустить сервер уже с проектом "АГЛКС"
$ service openscada-server start
Отметьте, что локально вы можете не копировать каталог проекта целком, а только сделать на него символическую ссылку, но вы получите риск двойного исполнения проекта на общий каталог и данные, что приводит к аварийному завершению одного исполнения или их обоих!
Отличие исполнения проекта в среде сервиса-фона от пользовательской среды рабочего стола собственно одно, естественно кроме отсутствия локального графического интерфейса, это — отсутствие в фоне определения локали, т.е. язык интерфейса там будет Английский. И что можно просто исправить сменой или добавлением конфигурационного параметра <prm id="Lang">ru_RU.UTF-8</prm> в секции-теге "station" файла oscada.xml фонового проекта.
Таким образом Вы получите демонстрационную БД (проект "АГЛКС") которая работает в фоне, что однако мы не увидим пока не попробуем подключиться к этой конфигурации, про что ниже. Теперь, при каждом запуске компьютера, она будет таким образом запускаться и работать в фоне. В целом, именно так осуществляется запуск и выполнение серверных конфигураций, окружений ПЛК и одноплатных ПК вроде RaspberyPi.
Если-же у Вас все-же возникли проблемы при работе с консолью-терминалом или Вы сознательно хотите фонового исполнения в графическом окружении — так называемого "запуска или закрытия в системный лоток", тогда Вы, на этой стадии, можете снова запустить демонстрационную конфигурацию, как описано в начале этого раздела (Рис.3.1.1), установить параметр Сворачивать или запускать в системный лоток, модуля UI.QTStarter, и закрыть окно конфигуратора, чтобы проект модели АГЛКС свернулся в системный лоток.
В окне менеджера проектов OpenSCADA (Рис.3.3) создадим наш собственный проект, который можно вызвать из меню окружения рабочего стола в разделе "Графика", общим пунктом "Открытая SCADA-система" с характерной иконкой (Рис.3.1.1), или командой из консоли-терминала:
$ openscada
В этом окне мы также можем проверить фоновое исполнение серверной и демонстрационной конфигураций.
А именно, нажмём соответствующую кнопку Создать-обновить проект и введём название нового проекта, например — Start.
Теперь мы можем попробовать удалённо подключиться к фоновому демонстрационному проекту, посмотреть на его конфигурацию и запустить демонстрационный проект на локальное исполнение из сервера визуализации.
На странице транспортов (Рис.3.3.1.1), в режиме Пользовательский и Системный, создадим подключение к нашей фоновой демонстрации "AGLKS", как станции OpenSCADA. Укажем там транспорт Сокеты, адрес TCP:localhost:10005, пользователя root и пароль openscada. После обновления дерева навигации конфигуратора, командой в контекстном меню, мы должны получить новый корневой пункт этого подключения и сможем контролировать удалённую-фоновую станцию с этого конфигуратора.
Если пункт удалённой станции появился, но отображает отсутствие подключения, то Вы допустили ошибку в конфигурации выше, или удалённая станция не доступна, что, в нашем случае, может означать только то, что она не работает в фоне, а значит вернитесь к соответствующему разделу и повторите операции в нём.
Если всё работает то сохраним эту конфигурацию, нажав вторую иконку слева на панели инструментов наверху, поскольку мы ещё воспользуемся ею для прямого шлюзования параметров сбора данных из демонстрационного проекта, как ПЛК.
На странице конфигурации визуализатора UI.Vision (Рис.3.3.1.2) выберем:
Следующий запуск модуля UI.Vision, второй иконкой с конца на панели инструментов наверху, должен привести среду визуальной разработки к установке подключения с сервером визуализации фонового демонстрационного проекта. Где Вы можете осуществлять удалённую разработку (Рис.3.3.1.3) и запускать проекты с этого сервера визуализации на исполнение (Рис.3.3.1.4).
Эту конфигурацию удалённого подключения к серверу визуализации сохранять не нужно и поле конфигурации "Станция движка СВУ" (Рис.3.3.1.2) нужно вернуть в Local, а пользователя станции установить в root; только после чого сохранить.
Возможность удалённого подключения и разработки иногда является единственным способом осуществить разработку или корректировку не только для серверных конфигураций исключительно с WEB-интерфейсом, но и для конфигураций с локальною визуализацией, когда само окружение локальной визуализации непригодное или ограниченное для исполнения среды разработки модуля UI.Vision, например, таких как смартфоны, планшеты, и другие мобильные устройства с малым экраном, исключительно сенсорным вводом (Android) или ограничениями, вроде невозможности открытия системной виртуальной клавиатуры (Nokia N9). И эту удалённую разработку в основном можно осуществлять в процессе исполнения проекта — горячая разработка, что особенно актуально для Web-интерфейсов и локальных интерфейсов, которые запускаются только в окне исполнения. Что качается удалённой конфигурации то на один локальный конфигуратор, как центр администрирования, можно собрать все удалённые станции в сети, включая станции в скрытых сетях станций первого уровня, поднять которые можно аргументом "Уровень поднятия" (Рис.3.3.1.1).
Ново-созданный проект 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-системы.
Основной функцией любой SCADA-системы является работа с источниками данных реального времени, а именно опрос программируемых логических контроллеров (ПЛК) и простых модулей УСО. Детальнее ознакомиться с этим вопросом можно в документе "Сбор данных в OpenSCADA".
Поддержка того или иного источника данных зависит от протокола или API, по которому источник предоставляет свои данные, и наличия для протокола-API модуля подсистемы "Сбор данных" в OpenSCADA. Общий перечень модулей подсистемы "Сбор данных" и документацию по ним можно получить по ссылке, в соответствующей части таблицы.
Данные, полученные из источников, впоследствии обрабатываются, архивируются и используются для визуального представления оператору ТП.
В качестве примера рассмотрим и создадим сбор данных для аппарата воздушного холодильника. Фоновая демонстрационная БД, как ПЛК и источник данных, содержит модель реального времени ТП компрессорной станции из шести компрессоров. Данные для двух аппаратов воздушных холодильников "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" — карту регистров.
С помощью страницы объекта контроллера, в разделе "Состояние", можно, в первую очередь, оценить текущее состояние объекта контроллера и реальное состояние связи с физическим контроллером, а также оперативно их менять. Так, поле "Статус" содержит код ошибки и текстовое описание текущего состояния связи с контроллером. В нашем случае объект контроллера выключен. Мы можем его включить и запустить, установив флажки напротив соответствующих полей. Включенный объект контролера инициализирует параметры, запущенный же ещё запускает задачу сбора (отдельный поток на объект контроллера) и предоставляет возможность передавать данные в контроллер, через атрибуты параметров. Поле "БД контроллера" указывает на то, в какой БД хранится конфигурация данного объекта. Нас устроит хранение в главной БД, т.е. оставим по умолчанию.
В разделе "Конфигурация", непосредственно содержится конфигурация объекта контроллера. Установим следующие из них, оставив все остальные без изменения::
Сохраним наши изменения в БД, нажав вторую слева иконку на панели инструментов.
Теперь, таким образом как и объект контроллера, создадим выходной транспорт в модуле "Sockets" ("Start"->"Транспорты"->"Сокеты"), посредством контекстного меню (Рис.4.1.4) и назовём транспорт так как и объект контроллер: CM101 (KM 101). Обратите внимание, что в поле "Тип элемента", диалога ввода идентификатора и имени (Рис.4.1.2), нужно выбрать Выходной транспорт!
Страница конфигурации полученного выходного транспорта приведена на рисунке 4.1.5. Эта страница также содержит раздел состояния и оперативного управления. В поле "Статус" содержится текстовое описание текущего состояния транспорта. Мы можем запустить его на исполнение, установив флажок напротив соответствующего поля. Выполняющийся объект транспорта инициирует соединение с внешним узлом. Поле "БД транспорта" указывает на то, в какой БД хранить конфигурацию данного объекта. Нас устроит главное хранилище.
В разделе "Конфигурация" непосредственно содержится конфигурация объекта транспорта. Установим следующие из них, оставив все остальные без изменения:
Транспорты других типов создаются подобно методу, рассмотренному для "Sockets", а конфигурация их отличается обычно только форматом записи адреса и таймаутов. В случае с транспортом модуля "Serial" в адресе указывается: путь к последовательному устройству, скорость и формат. Для конвертеров USB->Serial,Modem этот адрес можно узнать из операционной системы, например, консольной командой $ dmesg, сразу после его подключения.
Сохраним объект транспорта и вернёмся к конфигурационному полю "Адрес транспорта" объекта контроллера, где выберем адрес "Sockets.CM101". На этом настройка объекта контроллера закончена, включим его, установив флаг "Включен". Следующим этапом является конфигурация и выбор тех данных, которые нужно опрашивать из контроллера. Эта настройка производится путём создания параметра контроллера. Параметр позволяет описать перечень данных, получаемых у контролера и передать их в окружение OpenSCADA — модель данных.
Для добавления нового параметра откроем страницу нашего объекта контроллера и, в контекстном меню пункта "KM 101 (CM101)", нажмём "Добавить". Параметр назовём: AT101_1 (AT 101_1).
Страница конфигурации полученного параметра приведена на рисунке 4.1.6. Эта страница содержит раздел состояния и оперативного управления. В поле "Тип" содержится идентификатор типа параметра, в нашем случае это Стандартный (std). Параметр мы включаем, установив флажок напротив соответствующего поля. Включенный параметр участвует в процессе обмена с контроллером.
В разделе "Конфигурация" непосредственно содержится конфигурация параметра. Установим следующие из них, оставив все остальные без изменения:
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. Поскольку сбор производится регулярно и с периодичностью в секунду, то мы можем наблюдать их изменение, нажимая кнопку "Обновить текущую страницу" на панели инструментов.
На этом конфигурация сбора данных считается законченной.
Часто встречается ситуация, когда исходные данные, полученные из источника данных, являются "сырыми", т.е. неготовыми или неудобными для визуального представления, поэтому необходимо выполнить эту подготовку. В нашем примере мы получили данные, которые поступают в коде от шкалы внутри контроллера и наша задача — выполнить расчёт реальных значений из полученных данных. Обработку данных в 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) не имеет специфических настроек и установленные по умолчанию можно не трогать, кроме поля "Планирование вычисления", которое установим в одну секунду. Перед добавлением параметров нужно включить объект контроллера, установив флаг "Включен".
Параметр объекта контроллера модуля "LogicLev" (Рис.4.2.5) из специфических настроек имеет "Тип", где нужно установить Логический (std), а в поле "Шаблон параметра" выбрать адрес созданного нами шаблона.
Кроме базовой конфигурации параметра нужно сконфигурировать и подключенный шаблон (Рис.4.2.6). Вкладка конфигурации шаблона появляется в режиме параметра "Включен". Включить параметр можно, включив предварительно объект контроллера. Флаг "Показывать только атрибуты" позволяет устанавливать отдельно каждую связь (Рис.4.2.7). Поскольку мы, в шаблоне, предусмотрительно описали формат связей в виде "Параметр|Ti", то все три связи мы можем установить просто указав адрес к параметру в объекте контроллера "ModBus". Укажем-выберем адрес ModBus.CM101.AT101_1 и ModBus.CM101.AT101_2, в соответствующих параметрах.
Нужно отметить, что все поля ввода адресов объектов в OpenSCADA снабжены механизмом набора адреса. Данный механизм подразумевает поэлементный выбор, в процессе которого происходит движение в глубь. Например, при наборе адреса "ModBus.CM101.AT101_1", вначале мы будем иметь возможность выбора типа источника данных, среди которых будет "ModBus". Выбрав пункт "ModBus", в перечень доступных элементов для выбора добавятся объекты контроллера модуля "ModBus", среди которых будет "ModBus.CM101". Выбор элемента "ModBus.CM101" добавит параметры контроллера, и т.д. до конечного элемента, согласно иерархии объектов. Для возможности возврата на уровни выше, в список выбора вставляются элементы всех вышестоящих уровней от текущего значения адреса.
Сохраним созданные объекты контроллера и параметров, после чего запустим объект контроллера на исполнение, установив флаг "Выполняется" в разделе "Состояние". Если мы ничего не пропустили, то вычисление успешно запустится и в поле "Статус" мы получим похожее на рисунке 4.2.8.
В случае успешной обработки кода шаблона, в параметрах, мы получим обработанные данные в инфраструктуре (модели данных) OpenSCADA. Увидеть эти данные можно на вкладке "Атрибуты" наших параметров AT101_1 (Рис.4.2.9) и AT101_2.
На этом конфигурацию обработки данных считаем законченной.
В предыдущих разделах был описан механизм подключения источника данных по объекту аппарата — "Воздушный холодильник", который предусматривает объединение всех сигналов в одном объекте параметра источника данных. Однако более распространённым подходом крупной автоматизации является формирование объекта параметра вокруг отдельного сигнала, например — "Температура на выходе холодильника AT101_1 (TE1314_1)", которые часто называются тегами.
Создание объекта параметра вокруг сигнала позволяет формализовать его описание до шаблонов аналоговых и дискретных сигналов, включив в них всю необходимую обработку, сигнализацию и другую характерную информацию. Для простой конфигурации типизированных аналоговых и дискретных сигналов в библиотеках OpenSCADA предусмотрены шаблоны параметров, а многие образы визуального представление адаптированны к работе и связыванию с такими параметрами прямо, без детализации по атрибутам.
Обычно, для формирования параметра на основе шаблона, используется модуль логического уровня LogicLev, как это было описано в предыдущем разделе. Однако ряд модулей, в том числе и ModBus предоставляют возможность сразу создавать логические параметры, на основе шаблона. Добавим новые параметры, открыв в конфигураторе страницу нашего, ранее созданного, объекта контроллера "ModBus" и в контекстном меню пункта "КМ 101 (CM101)" нажмём "Добавить".
Назовём аналоговый параметр TE1314_1 (TE1314_1), (Рис.4.3.1). Тип параметра установим в Логический (logic), шаблон параметра выберем base.anUnif, описание установим в Температура на выходе AT101_1, установим флажки "Включать" и "Включен". Далее, нам нужно настроить:
Дискретный параметр назовём: CB102 (КШ102). Тип параметра установим в Логический (logic), шаблон параметра выберем base.digitBlockUnif, установим флажки "Включать" и "Включен". Далее нам нужно настроить:
Ознакомившись с типовыми механизмами получения данных, описанными в предыдущих разделах, Вы должны уже представлять общий объём работ с их получения и обработки, т.е. — формализацию и получение этих данных в модели данных SCADA-системы. Если сюда добавить задачу формирования этих данных на уровне ПЛК — модель данных ПЛК свободно программируемых ПЛК, и преобразование их в модель данных протокола обмена, то Вы должны заметить тут тройное преобразование данных. Что касается преобразования в модель данных протокола — сериализация, то это определяется физическими свойствами каналов связи и осуществляется автоматически, а вот формирование модели данных ПЛК и модели данных SCADA-системы осуществляется программистом ПЛК и SCADA-системы, соответственно. Причём, эта работа имеет много общего, особенно если осуществляется одним человеком или организацией, и соответственно должны быть механизмы её унификации.
В случае разного происхождения ПЛК и SCADA, большей унификации чем слой протокола обмена достичь сложно. С другой стороны, глубокую унификацию моделей данных ПЛК и SCADA можно встретить у производителей одновременно ПЛК и SCADA, что однако только укрепляет их монопольное положение и фактически нивелирует преимущества унификации через общую стоимость решения.
OpenSCADA предусматривает возможность такой унификации через добавление родственности с ПЛК. И такую родственность можно обеспечить только для ПЛК, которые являются полностью открытыми, на них установлено открытое-свободное ПО, а соответственно можно установить и OpenSCADA в роли среды исполнения ПЛК. Как среда исполнения, OpenSCADA может предоставлять данные ПЛК и стандартными протоколами, как ModBus, но, для получения этих данных прямо и без осуществления каких либо действий над ними, на стороне SCADA-системы предусмотрен модуль "DAQGate", который, по факту, объединяет модели. Т.е., фактически, программист ПЛК, который по совместительству является программистом SCADA, формирует модель данных ПЛК, а на уровне SCADA-системы она используется уже как готовая, чем полностью убирается стадия и работы с получения, обработки и формирования модели данных SCADA-системы. Более того:
С целью демонстрации и ознакомления, создадим тут объект контролера модуля "DAQGate", для шлюзования данных нашего виртуального ПЛК. Создаётся он идентично к ранее созданным объектам контролера в модуле "ModBus" и "LogicLev", на странице: "Start"->"Сбор данных"->"Модуль"->"Шлюз источников данных" и назовём его AGLKS.
Объект контроллера модуля "DAQGate" (Рис.4.4.1) имеет следующие специфические настройки, которые мы должны осуществить:
Если всё сделано правильно то автоматически создадутся параметры выбранного контроллера и мы сможем посмотреть на данные в них на вкладке "Атрибуты" (Рис.4.4.2).
Полученные выше данные считаются текущими, т.е. таковыми, которые периодически обновляются и характеризуют значение параметра ТП на настоящий момент времени. При этом, ранее считанные значения теряются при перезаписи их текущим, т.е. отсутствует их история. Во многих-же задачах требуется ведение архива-истории прочитанных значений параметров ТП, для чего в OpenSCADA предусмотрена подсистема "Архивы-История" где нам нужно создать архиваторы значений и сообщений, для нарушений, и указать наши параметры для архивирования их значений там.
Если не создать архиваторов и не подключить наших параметров на архивирование ими то на графиках Вы не получите истории более его общей ширины, а также потеряете накопленное при переключении, а в отчётных документах не получите истории вообще.
Начнём с архивации значений, для которой нужно создать хотя-бы один архиватор для нужного типа хранилища и периодичностью значений. Вообще, OpenSCADA содержит два модуля архивации: на файловую систему "FSArch" и на базу данных "DBArch". Тут мы рассмотрим только модуль архивации на файловую систему, как наиболее универсальный и эффективный. Что касается периодичности значений, для "качественного" архиватора, то её, в основном, нужно выбирать по периодичности значений самого медленного источника данных в нашей системе, который у нас один и периодичность мы ему указали 1 секунда. Для создания архиватора значений откроем страницу модуля архивирования ("Start"->"Архивы-История"->"Модуль"->"Архиватор на файловую систему") и, посредством контекстного меню, создадим объект архиватора значений 1s. Обратите внимание на значение поля "Тип элемента" диалога создания, которое должно быть Архиватор значений! Страница конфигурации полученного объекта архиватора значений (Рис.4.5.1) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:
установить в последнюю очередь и после выполнения всего этого списка;
Одного "качественного" архиватора уже достаточно для большинства задач, но если Вы планируете строить графики-тренды значений и отчётные документы на большую глубину (сутки, недели, месяца) то нужно создать ещё пару архиваторов с большей периодичностью значений. Иначе построение графиков и документов будет продолжительным и/или будет обрезаться по лимитам времени исполнения! Обычно, в качестве таких дополнительных архиваторов создаются, и Вы должны их создать идентично инструкции для "качественного" архиватора выше:
Для включения архивирования атрибутов "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) содержит раздел состояния и оперативного управления "Состояние", раздел настроек "Конфигурация" и раздел специфических настроек архиватора этого модуля "Дополнительные опции". В целом мы имеем:
установить в последнюю очередь и после выполнения всего этого списка;
Таким-же образом можно создать архиваторы сообщений другого характера, например, действия оператора, для чего достаточно определить категорию этих сообщений и сформировать для них шаблон или правило регулярного выражения. Изучить сообщения, получить информацию об их категории и настроить шаблон, или правило регулярного выражения, можно на главной странице подсистемы "Архивы-История". Можно даже создать архиватор для архивирования всех сообщений программы, но делать этого не рекомендуется ввиду получения больших архивов и долгого доступа к ним потом.
Формирование визуального представления может выполняться на трёх уровнях сложности и пользователь может выбрать любой из них, в зависимости от требований задачи, уровня своих знаний и наличия библиотек с готовыми образами и шаблонами.
Первый уровень требует минимальной квалификации пользователя, но подразумевает наличие библиотек шаблонных кадров, нужных для решения его задачи. В рамках первого уровня пользователю достаточно знать, как подключить динамику к страницам шаблонных кадров и как добавить новые страницы шаблонных кадров.
Второй уровень предусматривает дополнительную способность — создавать новые кадры на основе готовых-комплексных элементов, путём простого их размещения в области кадра. Для обеспечения этого квалификационного уровня, пользователю понадобятся библиотеки комплексных элементов, нужных для решения его задач.
И, третий уровень предусматривает владение всеми инструментами среды разработки визуальных интерфейсов OpenSCADA, включая создание новых комплексных элементов и разработку интерфейсов пользователя в проекте.
Все работы над интерфейсом визуализации будем выполнять в окружении модуля "Vision" подсистемы "Пользовательские интерфейсы". Для открытия окна интерфейса "Vision" нажмём вторую иконку справа панели инструментов конфигуратора. В результате получим окно, ранее представленное на рисунке 3.3.1.3.
Интерфейсы пользователя-оператора в OpenSCADA реализуются проектами визуализации. В библиотеке основных элементов пользовательского интерфейса присутствует шаблон типового проекта визуализации, основанного на концепции объектов сигнализации и видов отображения. Пользователь может начать создавать свою концепцию интерфейса визуализации, в виде нового проекта, а может использовать указанный шаблон.
Для реализации новой концепции проекта визуализации потребуются знания третьего уровня и значительные усилия, что находится за рамками рассмотрения этого документа. Поэтому будем рассматривать создание интерфейса визуализации на основе доступного шаблонного проекта.
Скопируем проект "Группы сигнализации (шаблон)", нажав сначала кнопку "Копировать визуальный элемент" на нём, а затем кнопку "Вставить визуальный элемент" (Рис.5.1). В диалоге назовём наш новый проект start (Старт) и в списке проектов получим пункт нашего нового проекта (Рис.5.1).
Перед использованием и сохранением нового проекта (Рис.5.3) нужно изменить адрес его хранилища на главную БД *.*.prj_start, что мы можем сделать на главной странице диалога свойств визуального элемента, вызываемого по кнопке "Свойства визуального элемента" (Рис.5.2). После чего сохраним наш новый проект, нажав третью кнопку слева панели инструментов.
Шаблонный проект (Рис.5.3) содержит две ветви: "Панели управления" и "Корневая страница". Ветвь "Панели управления" содержит набор кадров типовых панелей управления и специализированных кадров. Ветвь "Корневая страница", с корневой страницей в основе, содержит подветви объектов сигнализации "Группа 1", "Группа 2" и отдельную ветвь сводных графиков "Сводные графики". Подветви объектов сигнализации "Группа {n}" имеют цифровой идентификатор и могут расширяться добавлением вплоть до 20. Присутствие подветви "Группа {n}" отражается на активации соответствующей кнопки объекта сигнализации корневой страницы, что позволяет на них переключаться. Каждая подветвь "Группа {n}" содержит контейнеры или шаблоны видов отображения, обычно: "Мнемосхемы", "Группы графиков", "Группы контуров", "Группы обзорных кадров" и "Документы". Наличие страниц в контейнерах отображений включает возможность выбора этого отображения, для соответствующего объекта сигнализации корневой страницы. Детальнее ознакомиться со структурой корневой страницы можно по ссылке.
Рассмотрим задачу первого уровня сложности, когда к уже разработанной концепции интерфейса нужно подключить динамику шаблонной страницы. Понятие "Шаблон страницы" подразумевает страницу, на основе которой, и путём наследования, может создаваться множество конечных страниц визуализации с индивидуальным перечнем динамики. Примером таких страниц являются: "Группа графиков", "Группа контуров", "Группа обзорных кадров" и "Сводные графики". На Рис.5.1.1 представлена шаблонная страница "Группа графиков" в дереве нашего проекта "Старт".
Шаблонная страница "Группа графиков" предоставляет возможность подключить до восьми сигналов одновременного их отображения на графике. Элементы отображения значения сверху автоматически скрываются для неустановленных связей.
Создадим новую группу графиков в шаблонном контейнере "Группа графиков" первой группы корневой страницы. Для этого, в контекстном меню пункта "Группа графиков", выберем пункт меню "Добавить визуальный элемент" (Рис.5.1.2). Для ввода идентификатора и имени нового визуального элемента появится диалог их ввода (Рис.5.1.3). Введём идентификатор "2" и имя "Графики 2" — 2 (Графики 2).
После подтверждения ввода имени будет создана новая страница. Однако, для её активации, нам понадобится её включить. Включить страницу можно в диалоге редактирования свойств страницы (Рис.5.1.4). Открыть эту страницу можно посредством выбора пункта меню "Свойства визуального элемента" в контекстном меню только что созданной страницы. Создать страницу в логическом контейнере на основе шаблона можно и простым копированием шаблона в самого себя, а также копированием другой страницы этого контейнера, но уже и со связями.
После включения страницы можно приступать к установке связей на созданные ранее параметры контроллеров. Для этого, не покидая диалога редактирования свойств только что созданной страницы (Рис.5.1.4), перейдём на вкладку "Связи" (Рис.5.1.5). На этой вкладке мы увидим дерево с элементами "el1" ... "el8". Развернув любой из элементов мы увидим ветвь "Parameter", и именно в ней мы должны указать или выбрать адрес наших атрибутов "Ti" и "To". Итого заполним четыре элемента, но в процессе этого часть свойств нужно указывать как постоянные:
Если в шаблоне параметра контроллера заранее предусмотреть наличие атрибутов, указанных нами постоянными, то можно будет указывать только параметр, а атрибуты расставятся автоматически. Это мы можем увидеть, привязав созданный нами ранее комплексный объект-тег аналогового сигнала "ModBus.CM101.TE1314_1".
Закончив ввод связей можем проверить, что получилось в результате наших усилий. Для этого закроем окно диалога свойств и запустим наш проект "Старт" на исполнение, про кнопку запуска мы помним из первых глав. Затем, выберем графики и переключимся на вторую страницу. При безошибочной конфигурации мы должны увидеть что-то подобное изображённому на рисунке 5.1.6. Заметьте, что для параметра комплексного объекта-тега, с установленными границами нарушений, выход значения за границы отмечается аварийным цветом. Для того что-бы увидеть выход за границу нарушения Вы можете установить значение производительности вентилятора в 100 (Рис.4.2.9).
Поднимем планку и создадим новый кадр, куда поместим базовые элементы отображения значений параметров наших контроллеров. Такие кадры обычно называются мнемосхемами и кроме отображения динамики, и даже в первую очередь, содержат статическое изображение технологического процесса в мнемоническом представлении. Мы же не будем акцентировать тут внимание на создание статики, а добавим элементы динамики и подключим к ней параметры наших контроллеров. Ну и поместим созданный кадр в дерево нашего проекта.
Новые кадры, предназначенные впоследствии для помещения в проект, принято создавать и изменять в библиотеке виджетов. Создадим новую библиотеку виджетов, выбрав вертикальную вкладку "Виджет" и в контекстном меню окна библиотек виджетов выберем пункт меню "Новая библиотека" (Рис.5.2.1). В диалоге ввода имени укажем CM101 (KM 101).
Далее добавляем новый кадр, выбрав пункт меню "Библиотека: originals"->"Группа элементов" (Рис.5.2.2) в контекстном меню созданной библиотеки "KM 101". В диалоге ввода имени укажем AT101 (AT 101). В основе любого кадра и страницы должен лежать элемент "Группа элементов (Box)" поэтому мы его и выбрали.
Сразу после создания нового кадра нужно установить его базовые свойства, характерные для кадра мнемосхемы. Свойства или атрибуты любого визуального элемента можно указать в панели инструментов "Атрибуты", предварительно выбрав нужный визуальный элемент. Выберем созданный кадр "AT 101" и установим следующие свойства:
В результате получим пустой кадр (Рис.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. В инспекторе атрибутов установим свойства протокола:
Добавленные элементы можно расположить как Вам будет угодно, просто выделяя и перетаскивая мышью. Таким-же образом можно изменить их размер. Простое изменение размера вызовет изменение только геометрии контейнера виджета, что часто не нужно. Для изменения размера всего содержимого виджета его нужно масштабировать, что осуществляется удержанием клавиши "Ctrl", при изменении размера, или переключением состояния "Изм. размера" в строке статуса на "Масштаб".
После выполнения всех манипуляций у нас должна получиться мнемосхема с видом, похожим на рисунок 5.2.4.
На этом процедуру создания мнемосхемы будем считать законченной. Сохраним новую библиотеку виджетов "KM 101" и приступим к этапу размещения нашей мнемосхемы в дереве проекта "Старт".
Поместим нашу мнемосхему в ветвь "Старт"->"Корневая страница"->"Группа 1"->"Мнемосхемы", путём выбора пункта меню "Библиотека: CM101"->"AT 101", в контекстном меню пункта страницы проекта "Мнемосхемы". Идентификатор новой мнемосхемы установим в "2", при этом поле имени оставим пустым — 2.
Далее нужно произвести уже знакомую нам, по предыдущей главе, операцию, а именно — установку связей на ранее созданные параметры контроллеров. Для этого, откроем вкладку "Связи" (Рис.5.2.5) диалога редактирования свойств мнемосхемы, где мы увидим дерево с элементами "A1_Ti", "A1_To", "A2_Ti" и "A2_To". Развернув любой из элементов мы увидим ветку "Parameter", в которой мы должны указать, или выбрать, адрес значений наших атрибутов "Ti" и "To", соответственно. В процессе заполнении элементов, часть свойств нужно указывать постоянными:
Как и в случае с группой графиков в предыдущем разделе, для комплексных параметров объекта-тега "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).
Приступим к рассмотрению задач третьего уровня сложности, а именно к созданию комплексного элемента. Создание комплексного элемента, включающего в себя комбинацию различных базовых примитивов, может осуществляться в несколько этапов. В качестве примера рассмотрим задачу, состоящую из двух этапов:
Виджет будем создавать в ранее нами созданной библиотеке "КМ 101". Для этого кликаем правой кнопкой манипулятора "мышь" по пункту этой библиотеке и выбираем пункт меню "Библиотека: originals"->"Элементарная фигура", как это показано на рисунке 5.3.1.1, и называем новый елемент air_cooler (Воздушный холодильник).
После подтверждения появится новый виджет с именем "Воздушный холодильник". Выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования, посредством контекстного меню нового элемента (Рис.5.3.1.2). В инспекторе атрибутов установим свойства:
Теперь изобразим визуальное представление виджета, что можно осуществить двумя способами:
Дополнительную информацию о редакторе можно получить здесь.
В нашем примере мы воспользуемся вторым способом. Для этого, в поле "Список элементов" инспектора атрибутов, введем нижеприведенный перечень и нажмем "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).
На этом процесс создания первого виджета можно считать завершенным. Перейдем к этапу компоновки и создания результирующего виджета.
Финальный виджет будем создавать в библиотеке "KM 101", для чего кликаем правой кнопкой манипулятора "мышь" по этой библиотеке и выбираем примитив "Группа элементов", как это показано на рисунке 5.3.2.1. Назовём новый элемент — elCooler (Холодильник).
После подтверждения появится новый виджет с именем "Холодильник". Выберем его в списке виджетов библиотеки "KM 101" и откроем для редактирования. В инспекторе атрибутов установим свойства:
Возьмём ранее созданный элемент "Воздушный холодильник (air_cooler)" и перетащим его — нажмём на нем левую кнопку манипулятора "мышь" и переместим курсор до области только что созданного виджета, где отпустим кнопку (Рис.5.3.2.2).
В результате появится окно диалога с предложением ввести идентификатор и имя нового виджета. Идентификатор и имя могут быть заданы произвольно. Мы введём идентификатор air_cooler, а имя оставим пустым и оно унаследуется от родителя — элемента "air_cooler". Таким образом только что созданный виджет внутри контейнера "elCooler" унаследует элемент "Воздушный холодильник (air_cooler)". После подтверждения ввода идентификатора и имени, виджет "Воздушный холодильник (air_cooler)" добавится в нашем виджете-контейнере "elCooler" (Рис.5.3.2.3). В инспекторе атрибутов установим для него свойства:
Далее, развернем пункт меню библиотеки "Элементы мнемосхемы", найдем там элемент "Вентилятор 2 (cooler2)" и перетащим его на виджет-контейнер. Этот элемент будет динамически отображать интенсивность работы воздушного холодильника. Для нового виджета введём идентификатор cooler2 и имя снова оставим пустым, после чего виджет "Вентилятор 2 (cooler2)" добавится в наш виджет-контейнер "elCooler". Таким образом только что созданный виджет, внутри контейнера "elCooler", унаследует элемент библиотеки "Элементы мнемосхемы" — "Вентилятор 2 (cooler2)". В инспекторе атрибутов установим свойства:
Теперь, в виджете-контейнере "elCooler" добавим два текстовых поля, основанных на примитиве "Текст", с целью отображения входной и выходной температур потока. Для этого, выделим виджет "Холодильник" и, на панели визуальных элементов библиотеки "KM 101", выберем пункт меню примитива "Текст", как это показано на рисунке 5.3.2.5. Для первого текстового поля введем идентификатор Ti и, в инспекторе атрибутов, установим свойства:
%1 град.C
Теперь, с целью создания аналогичного виджета для выходной температуры, скопируем виджет "Ti". Вставим скопированный виджет и укажем ему идентификатор To (Рис.5.3.2.10). В инспекторе атрибутов установим свойства:
Теперь добавим виджет, основанный на примитиве "Элемент формы" (Рис.5.3.2.11), который будем использовать для выбора заданий производительности холодильника. Укажем идентификатор cw (Рис.5.3.2.12) и, в инспекторе атрибутов, установим свойства:
0 50 100 150 200
Для отображения единицы измерения производительности холодильника добавим ещё один виджет, основанный на примитиве "Текст". Делаем ту-же процедуру, что и для виджета "Ti". Укажем идентификатор dimension (Рис.5.3.2.13) и, в инспекторе атрибутов, установим свойства:
Для добавления логики обработки виджета "Холодильник (elCooler)", откроем диалог редактирования свойств этого визуального элемента и перейдём на вкладку "Обработка". На этой вкладке мы увидим дерево атрибутов виджета и поле текста программы обработки атрибутов. Для решения нашей задачи нужно добавить три атрибута: 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".
Полученная вкладка "Обработка" виджета "elCooler" библиотеки "KM 101" будет иметь вид, показанный на рисунке 5.3.2.16.
Закроем диалог редактирования свойств визуального элемента, создадим иконку нашего элемента, закроем внутреннее окно редактирования и сохраним это всё.
На этом разработку комплексного элемента можно считать законченной.
Для проверки работоспособности и оценки результатов наших усилий, добавим созданный виджет на мнемосхему, разработанную в разделе 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", развернув любой мы увидим ветвь "Параметр" с атрибутами "Ti", "To" и "Cw". Таким образом в поле "Параметр" мы можем просто указать адрес параметра prm:/LogicLev/CM101/AT101_1 и prm:/LogicLev/CM101/AT101_2, соответственно, а атрибуты будут расставлены автоматически.
Сохраним нашу мнемосхему и проверим результат. Для чего, закроем окно диалога свойств, запустим проект "Старт" на исполнение и переключимся на вторую мнемосхему кнопками перелистывания. При безошибочной конфигурации мы должны увидеть подобное изображённому на рисунке 5.3.3.3.
На этой мнемосхеме, посредством наших комплексных элементов, мы можем не только наблюдать, но и управлять производительностью холодильников, просто меняя значение в комбобоксе. Меняя производительность, мы можем заметить и изменение температуры и срабатывание сигнализации по комплексному аналоговому параметру объекта-тренда. Историю изменения мы можем увидеть и исследовать на группе графиков, созданной нами в разделе 5.1, и документе "Протокол нарушений", о котором упоминалось в разделе 5.2.
Таким образом мы получили полноценный типовой интерфейс технологического процесса (ТП) с реальным сбором данных в разный способ, а соответственно, получили представление и навыки работы с OpenSCADA.
При построении интерфейса ТП мы рассмотрели все три уровня сложности, а соответственно и получили представление про нужный квалификационный уровень программиста SCADA.
Сбор и обработку данных мы рассмотрели и осуществили в разные способы, от простого-типового и по отражение модели данных ПЛК, построенного на основе OpenSCADA. Т.е., получено представление про источники данных SCADA-систем и доступ к ним с помощью сетевых интерфейсов и протоколов обмена, поддержку которых реализуют соответствующие модули OpenSCADA.
И конечно, мы рассмотрели методы распространения (дистрибуции) OpenSCADA, способы её установки и получения нужного окружения, таких как: сервера SCADA, ПЛК OpenSCADA и рабочего места оператора.
Информация про OpenSCADA этим документом не ограничивается и, в разрешении специфических вопросов, Вы должны использовать всю доступную документацию и примеры демонстрационных конфигураций-моделей OpenSCADA, пользуясь тем самым преимуществами "открытых исходных текстов (OpenSource)". Отдельно тут нужно ещё раз отметить "Руководство по программе", "Как сделать ..." и "Динамическую модель реального времени АГЛКС", как наиболее полные источники информации про OpenSCADA.
| Documents/Quick_start/ru - GFDL | February 2022 | OpenSCADA 1+r2802 |