OpenSCADAWiki: Doc/ Program Manual ...

Home | Index | Changes | Comments | Users | Registration | Login  Password:  
 
English (1 Кб) English

 (2 Кб) Страница заморожена, актуальная тут и тут.


55459

Описание программы OpenSCADA

Автор: Роман Савоченко


Contents


Введение.

Данный документ является описанием "open source" проекта системы именуемой "OpenSCADA". OpenSCADA представляет собой открытую SCADA систему, построенную по принципам модульности, многоплатформенности и масштабируемости.


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


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


Система OpenSCADA может применяться:


В качестве базовой (хостовой) операционной системы для разработки и использования выбрана ОС Linux, которая является оптимальным решением в вопросах:


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


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


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


Клиентские конфигурации могут строиться на основе различных графических библиотек (GUI/TUI ToolKits), как используя ядро программы и его модули (путём добавления к нему UI-user interface модуля), так и в качестве самостоятельного приложения, подключая ядро OpenSCADA как библиотеку.


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


1. Функции системы.

Блочная схема структуры системы OpenSCADA (73 Кб)
Рис. 1. Блочная схема системы OpenSCADA

1.1. Модульность.

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


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


На основе модулей реализованы следующие функциональные части системы OpenSCADA:


Управление модулями осуществляется подсистемой «Управление модулями». Функциями подсистемы является: подключение, отключение, обновление модулей, а также другие операции, связанные с модулями и библиотеками модулей.

1.2. Подсистемы.

Архитектурно система OpenSCADA делится на подсистемы. Подсистемы могут быть двух типов: обычные и модульные. Модульные подсистемы обладают свойством расширения посредством модулей. Каждая модульная подсистема может содержать множество модульных объектов. Например, модульная подсистема «Базы данных» содержит модульные объекты типов баз данных. Модульный объект является корнем внутри модуля.


Всего система OpenSCADA содержит 9 подсистем из них 7 подсистем являются модульными. 9 подсистем системы OpenSCADA являются базовыми и присутствуют в любой конфигурации. К списку 9 подсистем могут добавляться новые подсистемы посредством модулей. Подсистемы системы OpenSCADA:

1.3. PLC и другие источники динамических данных. Подсистема "Сбор данных".

Для обеспечения поддержки источников динамических данных, будь то PLC-контроллеры, платы УСО, виртуальные источники и т.д., предназначена подсистема «Сбор данных». В функции этой подсистемы входит предоставление полученных данных в структурированном виде и обеспечение управления этими данными, например, модификация данных.


Подсистема «Сбор данных» является модульной и, как следствие, содержит модульные объекты типов источников динамических данных. Например, на октябрь 2007г, система OpenSCADA поддерживает следующие типы источников данных:


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


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


Структуры контроллеров, параметров и их типов содержатся в подсистеме "Сбор данных", а объекты модулей выполняют их заполнение в соответствии с собственной спецификой.


Источник динамических данных может быть удалённым, т.е. быть подключен на удалённой системе OpenSCADA. Для связи с такими источниками данных используется транспортный тип контроллеров (Transporter). Функцией данного типа источника данных является отражение источников данных удалённой OpenSCADA станции на локальную станцию.

1.4. Базы данных. Подсистема "Базы данных"

Для хранения данных системы повсеместно используются базы данных (БД). В целях систематизации доступа и управления базами данных в системе OpenSCADA предусмотрена подсистема "Базы данных". Для обеспечения поддержки различных БД/СУБД подсистема выполнена модульной.


В роли модульных объектов, содержащихся в подсистеме, выступает тип БД/СУБД, т.е. модуль подсистемы «Базы данных» практически содержит реализацию доступа к определённому типу БД. Например, модули: DBF, MySQL, SQLite.


Объект типа БД/СУБД в свою очередь содержит список объектов отдельных БД данного типа, а объект БД содержит список объектов таблиц, которые и содержат данные в табличной форме.


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


Для организации централизованного доступа распределённой системы к единой БД предусматриваются два способа. Первый это использование сетевых СУБД, например, MySQL. Второй способ это использование транспортного типа БД на локальных системах для доступа к одной центральной БД (Планируется). Функцией транспортной БД является пересылка запросов к БД на удалённую OpenSCADA систему.


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


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


В дальнейшем планируется реализация дублирования БД путём связывания зарегистрированных БД. Этот механизм позволит значительно повысить надёжность системы OpenSCADA в целом путём резервирования механизма хранения данных (Планируется).

1.5. Архивы. Подсистема "Архивы".

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


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


Особенностью архивов значений является их периодичность, определяемая промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный, то и архивировать его можно только путём введения понятия квантования опроса значений, поскольку иначе мы получаем архивы бесконечных размеров, ввиду непрерывности самой природы процесса. Кроме этого практически мы можем получать значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1 кГц. И это без учёта самих датчиков имеющих ещё менее качественные характеристики.


Для решения задач архивирования потоков данных в системе OpenSCADA предусмотрена подсистема "Архивы". Подсистема "Архивы" позволяет вести как архивы сообщений, так и архивы значений. Подсистема "Архивы" является модульной. Модульным объектом, содержащимся в подсистеме "Архивы", выступает тип архиватора. Тип архиватора определяет способ хранения данных, т.е. хранилище (файловая система, СУБД, сеть и т.д.). Каждый модуль подсистемы "Архивы" может реализовывать как архивирование сообщений, так и архивирование значений. Подсистема "Архивы" может содержать множество архивов, обслуживаемых различными модулями подсистемы.


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


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


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


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


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


Для организации выделенных архиваторов в распределённых системах можно использовать транспортный тип архиватора (Планируется). Функцией транспортного типа архиватора является отражение удалённого центрального архиватора на локальной системе. Как следствие архиваторы транспортного типа выполняют передачу данных между локальной системой и архиватором удалённой системы, скрывая от подсистем локальной системы реальную природу архиватора.

1.6. Коммуникации. Подсистемы "Транспорты" и "Транспортные протоколы".

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


Подсистема «Транспорты» предназначена для обмена неструктурированными данными между системой OpenSCADA и внешними системами. В роли внешних систем могут выступать и удалённые OpenSCADA системы. Под неструктурированными данными понимается массив символов определённой длины. Модульным объектом, содержащимся в подсистеме «Транспорты», выступает тип транспорта. Тип транспорта определяет механизм передачи неструктурированных данных. Например, это могут быть:


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


Подсистема "Транспортные протоколы" предназначена для структуризации данных, полученных от подсистемы "Транспорты". По сути, подсистема "Транспортные протоколы" является продолжением подсистемы "Транспорты" и выполняет функции проверки структуры и целостности полученных данных. Так, для указания протокола, в связке с которым должен работать транспорт, предусмотрено специальное конфигурационное поле. Модульным объектом, содержащимся в подсистеме "Протоколы", является сам протокол. Например, транспортными протоколами могут быть:


Полную цепочку связи можно записать следующим образом:


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


Благодаря стандартному API-доступа к транспортам системы OpenSCADA можно легко менять способ обмена данными, не затрагивая самих обменивающихся систем. Например, в случае локального обмена можно использовать более быстрый транспорт на основе разделяемой памяти, а в случае обмена через интернет и локальную сеть использовать TCP или UDP сокеты.

1.7. Интерфейсы пользователя. Подсистема "Интерфейсы пользователя".

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


Подсистема "Пользовательские интерфейсы" является модульной. Модульным объектом подсистемы выступает собственно конкретный интерфейс пользователя. Модульность подсистемы позволяет создавать различные интерфейсы пользователей на различных GUI/TUI библиотеках и использовать наиболее оптимальное из решений в конкретно взятом случае, например, для сред исполнения программируемых логических контроллеров можно использовать конфигураторы и визуализаторы на основе Web-технологий (WebCfg, WebUI), а в случае стационарных рабочих станций использовать те же конфигураторы и визуализаторы, но на основе библиотек типа Qt, GTK.

1.8. Безопасность системы. Подсистема "Безопасность".

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

1.9. Управление библиотеками модулей и модулями. Подсистема "Управление модулями".

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


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

1.10. Непредусмотренные возможности. Подсистема "Специальные".

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

1.11. Пользовательские функции. Объектная модель и среда программирования системы.

Любая современная SCADA система должна содержать механизмы, предоставляющие возможность программировать на пользовательском уровне, т.е. содержать среду программирования. Система OpenSCADA содержит такую среду. С помощью среды программирования системы OpenSCADA можно реализовывать:


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


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


Библиотеки функций фиксированного типа могут предоставляться стандартными модулями системы, органично дополняя объектную модель. Функции таких библиотек будут представлять собой интерфейс доступа к средствам модуля на уровне пользователя. Например, «Среда визуального представления данных» может предоставлять функции для выдачи различных сообщений. Используя эти функции, пользователь может реализовывать интерактивные алгоритмы взаимодействия с системой.


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


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


2. SCADA системы и их структура.

SCADA-система. (145 Кб)
Рис. 2. SCADA-система.

SCADA (Supervisory Control And Data Acquisition) в общем виде имеют распределённую архитектуру вроде изображённой на рис. 2. Элементы SCADA систем в смысле программного обеспечения выполняют следующие функции:
Сервер сбора: представляет собой задачу или группу задач занимающихся сбором данных из источников данных, или же сами выступают в роли источником данных. В задачи сервера входит:

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

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

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

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

Рабочее место руководителя: представляет собой GUI приложение, как правило, выполненное в одномониторном режиме и выполняющее функции:

Рабочее место технолога: полностью включает в себя функции рабочего места оператора плюс модель технологического процесса (без непосредственной связи с технологическим процессом).
Рабочее место технолога-программиста: полностью включает в себя функции рабочего места технолога плюс инструментарий для создания моделей технологических процессов.


3. Варианты конфигурирования и использования.

3.1. Простое серверное подключение.

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


Простое серверное подключение. (24 Кб)
Рис. 3.1. Простое серверное подключение.

3.2. Дублированное серверное подключение.

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


Дублированное серверное подключение. (30 Кб)
Рис. 3.2. Дублированное серверное подключение.

3.3. Дублированное серверное подключение на одном сервере.

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


Дублированное серверное подключение на одном сервере. (32 Кб)
Рис. 3.3. Дублированное серверное подключение на одном сервере.

3.4. Клиентский доступ посредством Web-интерфейса. Место руководителя.

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


Клиентский доступ посредством Web-интерфейса. Место руководителя. (31 Кб)
Рис. 3.4. Клиентский доступ посредством Web-интерфейса. Место руководителя.

3.5. Автоматизированное рабочее место (место руководителя/оператора).

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


Автоматизированное рабочее место (место руководителя/оператора) (44 Кб)
Рис. 3.5. Автоматизированное рабочее место (место руководителя/оператора)

3.6. АРМ с сервером сбора и архивирования на одной машине (место оператора, модель ...).

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


АРМ с сервером сбора и архивирования на одной машине (место оператора, модель ...) (41 Кб)
Рис. 3.6. АРМ с сервером сбора и архивирования на одной машине (место оператора, модель ...)

3.7. Простейшее смешанное подключение (модель, демонстрация, конфигуратор ...).

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


Простейшее смешанное подключение (модель, демонстрация, конфигуратор ...) (25 Кб)
Рис. 3.7. Простейшее смешанное подключение (модель, демонстрация, конфигуратор ...)

3.8. Устойчивая, распределённая конфигурация.

Данная конфигурация является одним из вариантов устойчивого/надёжного соединения (рис. 3.8). Устойчивость достигается путём распределения функций по:


Устойчивая, распределённая конфигурация (62 Кб)
Рис. 3.8. Устойчивая, распределённая конфигурация

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


Центральный сервер архивирования и обслуживания клиентских запросов выполняет функцию централизованного сбора и обработки параметров серверов опроса и их значений. Доступ к серверам опроса выполняется посредством одного из доступных в OpenSCADA транспортов+протоколов (на примере это SGA). Для предоставления единого интерфейса доступа к параметрам и контроллерам используется модуль Transporter, который отражает данные серверов опроса на структуру локальных параметров.


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


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


Для доступа клиентов к серверу используются доступные для OpenSCADA сетевые транспорты, на примере - это Sockets, и транспортные протоколы, на примере - это протокол OpenSCADA "SelfSystem".


Конфигурация центрального сервера хранится в одной из доступных БД (на примере это сетевая СУБД MySQL).


Для предоставления пользовательского WEB-интерфейса используется модуль WebCfg посредством транспортного протокола "HTTP".


Различные клиенты в их числе АРМ и WEB-клиенты выполняются на отдельных машинах в необходимом количестве. АРМ реализуется на основе системы OpenSCADA. В его функции входит опрос значений параметров из центрального сервера и их визуализация на GUI интерфейсе(ах). Для получения параметров в АРМ также используется модуль отражения удалённых параметров Transporter. Для предоставления доступа к архивам может использоваться модуль архива сетевого типа. Конфигурация АРМ может храниться в одной из доступных БД (в примере это сетевая СУБД MySQL, расположенная на машине центрального сервера архивирования).


4. Конфигурация и настройка системы

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


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


В OpenSCADA используется формализованный подход к описанию конфигурационных интерфейсов, основанный на языке XML. Фактически особенности конфигурации компонента системы предоставляется самим компонентом, пронизывая тем самым всю систему, как нервная система организма. В терминах OpenSCADA это называется интерфейсом контроля OpenSCADA (Control interface). На основе интерфейса контроля формируются графические интерфейсы конфигурации пользователя посредством модулей OpenSCADA. Такой подход имеет следующие важные преимущества:


В OpenSCADA уже предоставляется три модуля конфигурации на разной основе визуализации. Отметим их и их возможности конфигурации:


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


Кроме БД данные о конфигурации могут содержаться в конфигурационном файле OpenSCADA, а также передаваться посредством параметров командной строки при вызове OpenSCADA. Сохранение конфигурации в конфигурационном файле осуществляется наравне с БД. Типовым именем конфигурационного файла OpenSCADA является /etc/oscada.xml. Формат конфигурационного файла и параметры командной строки рассмотрим в отдельном разделе.


Изменение конфигурации того или иного узла устанавливает флаг модификации соответствующего узла, а также активирует кнопки "Загрузить из БД", для загрузки первоначальной конфигурации, и "Сохранить в БД" для сохранения изменений. Признак модификации также поднимается к родительскому узлу, что позволяет осуществлять восстановление-сохранение от корневого узла, хотя реально, при операциях с БД, будут участвовать только модифицированные узлы.  (2 Kb) Удаление узла приводит к непосредственному удалению его из хранилища-БД и механизм модификации на эту операцию не распространяется.


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


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


Рассмотрение начнём с конфигурации системных параметров OpenSCADA, которая размещается в шести вкладках корневой страницы станции:


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


Нужно отметить ещё один важный момент! Поля идентификаторов всех объектов OpenSCADA недопустимы для прямого редактирования, поскольку являются ключом для хранения данных объектов в БД. Однако поменять идентификатор объекта можно с помощью команды переноса и последующей вставки объекта (Cut->Paste) в конфигураторе.


Вкладка "Станция" корневой страницы конфигурации системы. (166 Кб)
Рис. 4a. Вкладка "Станция" корневой страницы конфигурации системы.

Вкладка "Подсистемы" корневой страницы конфигурации системы. (71 Кб)
Рис. 4b. Вкладка "Подсистемы" корневой страницы конфигурации системы.

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


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


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


Далее на конкретной станции, с копией общей БД, настраиваем её специфические параметры во вкладке "Резервирование" главной страницы (рис.4c), которые будут сохранены в конфигурационном файле.


После этого вся конфигурация резервирования осуществляется во вкладке "Резервирование" соответствующей подсистемы, "Сбор данных" (рис.4.5b) или "Архивы" (рис.4.6b). Если установить параметр "Передача локальных первичных команд" (рис.4c) то эта конфигурация, как и любая другая конфигурация общего характера, может осуществляться на одной из станций, а внесённые изменения попадут и на все резервные, конечно если они будут доступны.


Вкладка "Резервирование" корневой страницы конфигурации системы. (99 Кб)
Рис. 4c. Вкладка "Резервирование" корневой страницы конфигурации системы.

Вкладка "Задачи" корневой страницы конфигурации системы. (195 Кб)
Рис. 4d. Вкладка "Задачи" корневой страницы конфигурации системы.

Для отладки различных особенностей работы OpenSCADA может потребоваться включение генерации дополнительных-отладочных сообщений, что осуществляется установкой минимального уровня сообщений, на вкладке "Станция", в "Отладка (0)". В результате этого появится вкладке "Отладка" (рис.4e) где доступны счётчики объектов для контроля за утечками, а также таблица с перечнем категорий поступающий отладочных сообщений. В таблице категорий можно выбрать только те источники отладочных сообщений, которые нужны, тем самым не перегружая подсистему вывода и архивирования сообщений, а так-же не понижая производительность системы в целом. Можно выбирать категории и высших уровней, вплоть до корневой категории системы, что выключит детальный выбор и включит генерацию всех сообщений по уровню или системе. Для изучения отладочных сообщений нужно перейти в подсистему "Архивы" (рис. 4.6c), для чего предусмотрена кнопка "Просмотр сообщений". Выбранный режим отладки и перечень категорий отладки может быть сохранён в конфигурационном файле стандартным образом и при следующем старте режим отладки активируется сразу, что важно в первую очередь для счётчиков объектов.


Вкладка "Отладка" корневой страницы конфигурации системы. (98 Кб)
Рис. 4e. Вкладка "Отладка" корневой страницы конфигурации системы.

Вкладка "Переводы" корневой страницы конфигурации системы. (154 Кб)
Рис. 4f. Вкладка "Переводы" корневой страницы конфигурации системы.

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

4.1. Подсистема "БД"

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


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


Иерархическая структура подсистемы БД. (28 Кб)
Рис. 4.1a. Иерархическая структура подсистемы "БД".

Вкладка "Модули" корневой страницы подсистемы "БД". (55 Кб)
Рис. 4.1b. Вкладка "Модули" корневой страницы подсистемы "БД".

Каждый модуль подсистемы "БД" предоставляет конфигурационную страницу с вкладками "БД" и "Модуль". Вкладка "БД" (рис.4.1c) содержит список БД, зарегистрированных в модуле и флажок признака полного удаления БД при выполнении команды удаления. В контекстном меню списка БД предоставляется пользователю возможность добавления, удаления и перехода к нужной БД. Во вкладке "Модуль" содержится информация о модуле подсистемы "БД" (рис.4.1d):


Вкладка "БД" модуля подсистемы "БД". (61 Кб)
Рис. 4.1c. Вкладка "БД" модуля подсистемы "БД".

Вкладка "Модуль" модуля подсистемы "БД". (79 Кб)
Рис. 4.1d. Вкладка "Модуль" модуля подсистемы "БД".

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


Вкладка "База данных" (рис.4.1e) содержит основные настройки БД в составе:


Вкладка "Таблицы" (рис.4.1f) содержит список открытых таблиц. При нормальной работе программы эта вкладка пуста, поскольку после завершения работы с таблицами программа их закрывает. Наличие открытых таблиц говорит о том, что программа сейчас с таблицами работает или таблицы открыты пользователем для изучения их содержимого. В контекстном меню перечня открытых таблиц можно открыть таблицу для изучения (команда "Добавить"), закрыть открытую страницу (команда "Удалить") и перейти к изучению содержимого таблицы.


Вкладка "SQL" (рис.4.1g) доступна только для баз данных, поддерживающих SQL-запросы, и содержит поле ввода запроса, кнопку отправки запроса и таблицу с результатом запроса. Для управления контекстом транзакции запроса предусмотрено отдельное конфигурационное поле.


Вкладка "База данных" БД модуля подсистемы "БД". (92 Кб)
Рис. 4.1e. Вкладка "База данных" БД модуля подсистемы "БД".

Вкладка "Таблицы" БД модуля подсистемы "БД". (61 Кб)
Рис. 4.1f. Вкладка "Таблицы" БД модуля подсистемы "БД".

Вкладка "SQL" БД модуля подсистемы "БД". (100 Кб)
Рис. 4.1g. Вкладка "SQL" БД модуля подсистемы "БД".

Страница изучения содержимого таблицы содержит только одну вкладку "Таблица". Вкладка "Таблица" (рис.4.1h) содержит поле имени таблицы и таблицу с содержимым. Таблицей содержимого предоставляются функции:


Вкладка "Таблица" таблицы БД модуля подсистемы "БД". (105 Кб)
Рис. 4.1h. Вкладка "Таблица" таблицы БД модуля подсистемы "БД".

4.2. Подсистема "Безопасность"

Подсистема не является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Безопасность", содержащая вкладку "Пользователи и группы пользователей". Вкладка "Пользователи и группы пользователей" (рис.4.2a) содержит списки пользователей и групп пользователей. Пользователь в группе "Security" и с правами привилегированного пользователя может добавить, удалить пользователя или группу пользователей. Все остальные пользователи могут перейти к странице пользователя или группы пользователя.


Вкладка "Пользователи и группы пользователей" корневой страницы подсистемы "Безопасность". (63 Кб)
Рис. 4.2a. Вкладка "Пользователи и группы пользователей" корневой страницы подсистемы "Безопасность".

Для конфигурации пользователя предоставляется страница, содержащая только вкладку "Пользователь" (рис.4.2b). Вкладка содержит конфигурационные данные профиля пользователя, которые может изменять сам пользователь, пользователь в группе "Security" или привилегированный пользователь:


Вкладка "Пользователь" страницы пользователя подсистемы "Безопасность". (83 Кб)
Рис. 4.2b. Вкладка "Пользователь" страницы пользователя подсистемы "Безопасность".

Для конфигурации группы пользователей предоставляется страница, содержащая только вкладку "Группа" (рис.4.2c). Вкладка содержит конфигурационные данные профиля группы пользователей, которые может изменять только привилегированный пользователь:


Вкладка "Группа" страницы группы пользователей подсистемы "Безопасность". (66 Кб)
Рис. 4.2c. Вкладка "Группа" страницы группы пользователей подсистемы "Безопасность".

4.3. Подсистема "Транспорты"

Подсистема является модульной и содержит иерархию объектов, изображённую на рис.4.3a. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Транспорты", содержащая вкладки "Подсистема" и "Модули".


Иерархическая структура подсистемы «Транспорты». (14 Кб)
Рис. 4.3a. Иерархическая структура подсистемы "Транспорты".

Вкладка "Подсистема" (рис.4.3b) содержит таблицу конфигурации внешних, для данной, OpenSCADA станций. Внешние станции могут быть системными, пользовательскими или одновременно, что выбирается в соответствующей колонке. Системные внешние станции доступны только привилегированному пользователю и используются компонентами системного назначения, например, механизмом горизонтального резервирования и модулем DAQ.DAQGate. Пользовательские внешние станции привязаны к пользователю, который их создавал, а значит список пользовательских внешних станций индивидуален для каждого пользователя. Пользовательские внешние станции используются компонентами графического интерфейса, например: UI.QTCfg, UI.WebCfgD и UI.Vision. В таблице внешних станций возможно добавление и удаление записей про станцию, а также их модификация. Каждая запись содержит поля:


Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.


Вкладка "Подсистема" корневой страницы подсистемы "Транспорты". (76 Кб)
Рис. 4.3b. Вкладка "Подсистема" корневой страницы подсистемы "Транспорты".

Каждый модуль подсистемы "Транспорты" предоставляет конфигурационную страницу с вкладками "Транспорты" и "Модуль". Вкладка "Транспорты" (рис.4.3c) содержит список входящих и исходящих транспортов, зарегистрированных в модуле. В контекстном меню списков транспортов пользователю предоставляется возможность добавления, удаления и перехода к нужному транспорту. Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспорты" (рис.4.1d), состав которой идентичен для всех модулей.


Вкладка "Транспорты" модуля подсистемы "Транспорты". (73 Кб)
Рис. 4.3c. Вкладка "Транспорты" модуля подсистемы "Транспорты".

Каждый транспорт содержит собственную страницу конфигурации с одной вкладкой "Транспорт". Эта вкладка содержит основные настройки транспорта. Входящий транспорт (рис.4.3d) содержит:


Вкладка "Транспорт" страницы входящего транспорта модуля подсистемы "Транспорты". (96 Кб)
Рис. 4.3d. Вкладка "Транспорт" страницы входящего транспорта модуля подсистемы "Транспорты".

Исходящий транспорт (рис.4.3e) содержит:


Вкладка "Транспорт" страницы исходящего транспорта модуля подсистемы "Транспорты". (87 Кб)
Рис. 4.3e. Вкладка "Транспорт" страницы исходящего транспорта модуля подсистемы "Транспорты".

Исходящий транспорт, в дополнение, предоставляет вкладку формирования пользовательского запроса через данный транспорт (рис.4.3f). Вкладка предназначена для наладки связи, а также для отладки протоколов и содержит:


Вкладка "Запрос" страницы исходящего транспорта модуля подсистемы "Транспорты". (105 Кб)
Рис. 4.3f. Вкладка "Запрос" страницы исходящего транспорта модуля подсистемы "Транспорты".

4.4. Подсистема "Транспортные протоколы"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Транспортные протоколы", содержащая вкладку "Модули". Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы "Транспортные протоколы" и идентична для всех модульных подсистем.


Каждый модуль подсистемы "Транспортные протоколы" предоставляет конфигурационную страницу с одной вкладкой "Модуль". Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспортные протоколы" (рис.4.1d), состав которой идентичен для всех модулей.

4.5. Подсистема "Сбор данных"

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


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


Иерархическая структура подсистемы \'Сбор данных\'. (25 Кб)
Рис. 4.5a. Иерархическая структура подсистемы "Сбор данных".

Объектом резервирования подсистемы "Сбор Данных" выступает объект контроллера в рамках которого резервирование данных выполняет функции:


Вкладка "Резервирование" (рис.4.5b) доступна только если в резерве указана хотя-бы одна станция и содержит конфигурацию резервирования источников данных подсистемы "Сбор данных", в составе настроек:


Вкладка "Резервирование" подсистемы "Сбор данных". (115 Кб)
Рис. 4.5b. Вкладка "Резервирование" подсистемы "Сбор данных".

Вкладка "Библиотеки шаблонов" (рис.4.5c) содержит список библиотек шаблонов для параметров этой подсистемы. В контекстном меню списка библиотек шаблонов пользователю предоставляется возможность добавления, удаления и перехода к нужной библиотеке. Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.


Вкладка "Библиотеки шаблонов" подсистемы "Сбор данных". (57 Кб)
Рис. 4.5c. Вкладка "Библиотеки шаблонов" подсистемы "Сбор данных".

Каждая библиотека шаблонов подсистемы "Сбор данных" предоставляет конфигурационную страницу с вкладками "Библиотека" и "Шаблоны параметров". Вкладка "Библиотека" (рис.4.5d) содержит основные настройки библиотеки в составе:


Вкладка "Шаблоны параметров" (рис.4.5e) содержит список шаблонов в библиотеке. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному шаблону.


Основная вкладка конфигурации библиотеки шаблонов подсистемы "Сбор данных". (73 Кб)
Рис. 4.5d. Основная вкладка конфигурации библиотеки шаблонов подсистемы "Сбор данных".

Вкладка списка шаблонов в библиотеке шаблонов подсистемы "Сбор данных". (68 Кб)
Рис. 4.5e. Вкладка списка шаблонов в библиотеке шаблонов подсистемы "Сбор данных".

Каждый шаблон библиотеки шаблонов предоставляет конфигурационную страницу с вкладками "Шаблон" и "IO". Вкладка "Шаблон" (рис.4.5f) содержит основные настройки шаблона в составе:


Главная вкладка конфигурации шаблона параметров подсистемы "Сбор данных". (82 Кб)
Рис. 4.5f. Главная вкладка конфигурации шаблона параметров подсистемы "Сбор данных".

Вкладка "IO" (рис.4.5g) содержит конфигурацию атрибутов (IO) шаблонов и программу шаблона на одном из языков пользовательского программирования OpenSCADA, например, DAQ.JavaLikeCalc.JavaScript. В таблицу атрибутов шаблона пользователь может, посредством контекстного меню, добавить, вставить, удалить, передвинуть вверх или вниз запись атрибута, а также отредактировать поля атрибута:


С синтаксисом языка программы шаблона можно ознакомиться в документации модуля, предоставляющего интерпретатор выбранного языка. Например, типичным языком пользовательского программирования OpenSCADA является DAQ.JavaLikeCalc.JavaScript.


Вкладка конфигурации атрибутов и программы шаблона подсистемы "Сбор данных". (156 Кб)
Рис. 4.5g. Вкладка конфигурации атрибутов и программы шаблона подсистемы "Сбор данных".

Каждый модуль подсистемы "Сбор данных" предоставляет конфигурационную страницу с вкладками "Контроллеры" и "Модуль". Вкладка "Контроллеры" (рис.4.5h) содержит список контроллеров, зарегистрированных в модуле. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному контроллеру. Во вкладке "Модуль" содержится информация о модуле подсистемы "Сбор данных" (рис.4.1d), состав которой идентичен для всех модулей.


Вкладка "Контроллеры" модуля подсистемы "Сбор данных". (71 Кб)
Рис. 4.5h. Вкладка "Контроллеры" модуля подсистемы "Сбор данных".

Каждый контроллер содержит собственную страницу конфигурации с вкладками "Контроллер", "Параметры" и "Диагностика".


Вкладка "Контроллер" (рис.4.5i) содержит основные настройки. Состав этих настроек может несколько отличаться от одного модуля этой подсистемы к другому, о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки контроллера у модуля контроллера логического уровня DAQ.LogicLev:


Главная вкладка конфигурации контроллера подсистемы "Сбор данных". (89 Кб)
Рис. 4.5i. Главная вкладка конфигурации контроллера подсистемы "Сбор данных".

Вкладка "Параметры" (рис.4.5j) содержит список параметров в контроллере, выбор типа параметров, создаваемых по умолчанию, а также информацию об общем количестве и количестве включенных параметров. В контекстном меню, списка параметров, пользователю предоставляется возможность добавления, удаления и перехода к нужному параметру.


Вкладка "Параметры" страницы конфигурации контроллера подсистемы "Сбор данных". (67 Кб)
Рис. 4.5j. Вкладка "Параметры" страницы конфигурации контроллера подсистемы "Сбор данных".

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


Вкладка "Диагностика" страницы конфигурации контроллера подсистемы "Сбор данных". (131 Кб)
Рис. 4.5k. Вкладка "Диагностика" страницы конфигурации контроллера подсистемы "Сбор данных".

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


Вкладка "Параметр" (рис.4.5l) содержит основные настройки в составе:


Вкладка "Атрибуты" (рис.4.5m) содержит атрибуты параметра и их значения в соответствии с конфигурацией используемого шаблона и вычисления его программы.


Вкладка "Архивация" (рис.4.5n) содержит таблицу с атрибутами параметра в колонках, и архиваторами в строках. Пользователь имеет возможность установить архивацию нужного атрибута требуемым архиватором просто изменив ячейку на пересечении.


Вкладка "Конфигурация шаблона" (рис.4.5o) содержит конфигурационные поля в соответствии с шаблоном. В примере это групповая связь на внешний параметр. Эту связь можно установить, просто указав путь к параметру, если флаг "Показывать только атрибуты" не установлен, или же установить адреса атрибутов по отдельности, если флаг установлен. Знак "(+)", в конце адреса, сигнализирует об успешной линковке и присутствии целевого объекта.


Главная вкладка конфигурации параметра контроллера подсистемы "Сбор данных". (66 Кб)
Рис. 4.5l. Главная вкладка конфигурации параметра контроллера подсистемы "Сбор данных".

Вкладка "Атрибуты" параметра контроллера подсистемы "Сбор данных". (64 Кб)
Рис. 4.5m. Вкладка "Атрибуты" параметра контроллера подсистемы "Сбор данных".

Вкладка "Архивация" параметра контроллера подсистемы "Сбор данных". (69 Кб)
Рис. 4.5n. Вкладка "Архивация" параметра контроллера подсистемы "Сбор данных".

Вкладка "Конфигурация шаблона" параметра контроллера подсистемы "Сбор данных". (74 Кб)
Рис. 4.5o. Вкладка "Конфигурация шаблона" параметра контроллера подсистемы "Сбор данных".

4.6. Подсистема "Архивы"

Подсистема является модульной и содержит иерархию объектов, изображённую на рис.4.6a. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Архивы", содержащая вкладки "Резервирование", "Архив сообщений", "Архивы значений" и "Модули".


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


Иерархическая структура подсистемы \'Архивы\'. (15 Кб)
Рис. 4.6a. Иерархическая структура подсистемы "Архивы".

Объектом резервирования подсистемы "Архивы" выступает объект архиватора сообщений в рамках которого резервирование данных выполняет функции:


Резервирование архиваторов значений не предоставляется прямо ввиду осуществления этого процесса через источники данных и подсистему сбора данных.


Вкладка "Резервирование" (рис.4.6b) доступна только если в резерве указана хотя-бы одна станция и содержит конфигурацию резервирования архиваторов сообщений подсистемы "Архивы", в составе настроек:


Вкладка "Резервирование" подсистемы "Архивы". (83 Кб)
Рис. 4.6b. Вкладка "Резервирование" подсистемы "Архивы".

Вкладка "Архив сообщений" (рис.4.6c) содержит конфигурацию архива сообщений и форму запроса сообщений из архива.


Конфигурация архива сообщений представлена полями:


Форма запроса сообщений содержит конфигурационные поля запроса и таблицу результата. Конфигурационные поля запроса:


Таблица результата содержит строки сообщений с колонками:


Вкладка "Архив сообщений" подсистемы "Архивы". (139 Кб)
Рис. 4.6c. Вкладка "Архив сообщений" подсистемы "Архивы".

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


Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы "Архивы" и идентична для всех модульных подсистем.


Вкладка "Архивы значений" подсистемы "Архивы". (112 Кб)
Рис. 4.6d. Вкладка "Архивы значений" подсистемы "Архивы".

Архив значений подсистемы "Архивы" предоставляет конфигурационную страницу с вкладками "Архив", "Архиваторы" и "Значения".


Вкладка "Архив" (рис.4.6e) содержит основные настройки архива в составе:


Основная вкладка конфигурации архива значений подсистемы "Архивы". (147 Кб)
Рис. 4.6e. Основная вкладка конфигурации архива значений подсистемы "Архивы".

Вкладка "Архиваторы" (рис.4.6f) содержит таблицу с конфигурацией процесса обработки данного архива доступными архиваторами. В строках расположены доступные архиваторы, а в колонках параметры:


Вкладка "Архиваторы" архива значений подсистемы "Архивы". (77 Кб)
Рис. 4.6f. Вкладка "Архиваторы" архива значений подсистемы "Архивы".

Вкладка "Значения" (рис.4.6g) содержит запрос значений в архиве и результат в виде таблицы значений или изображения тренда. Запрос значений содержит поля:


Вкладка "Значения" архива значений подсистемы "Архивы". (108 Кб)
Рис. 4.6g. Вкладка "Значения" архива значений подсистемы "Архивы".

Каждый модуль подсистемы "Архивы" предоставляет конфигурационную страницу с вкладками "Архиваторы" и "Модуль". Вкладка "Архиваторы" (рис.4.6h) содержит списки архиваторов сообщений и значений, зарегистрированных в модуле. В контекстном меню списков пользователю предоставляется возможность добавления, удаления и перехода к нужному контроллеру. Во вкладке "Модуль" содержится информация о модуле подсистемы "Архивы" (рис.4.1d), состав которой идентичен для всех модулей.


Вкладка "Архиваторы" модуля подсистемы "Архивы". (72 Кб)
Рис. 4.6h. Вкладка "Архиваторы" модуля подсистемы "Архивы".

Архиваторы сообщений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Сообщения".


Вкладка "Архиватор" (рис.4.6i) содержит основные настройки. Состав этих настроек может несколько отличаться от одного модуля этой подсистемы к другому о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки архиватора сообщений у модуля архива на файловую систему Arch.FSArch:


Главная вкладка конфигурации архиватора сообщений подсистемы "Архивы". (99 Кб)
Рис. 4.6i. Главная вкладка конфигурации архиватора сообщений подсистемы "Архивы".

Вкладка "Сообщения" (рис.4.6j) содержит форму запроса сообщений из архива данного архиватора:


Таблица результата содержит строки сообщений с колонками:


Вкладка запроса сообщений "Сообщения" архиватора сообщений подсистемы "Архивы". (156 Кб)
Рис. 4.6j. Вкладка запроса сообщений "Сообщения" архиватора сообщений подсистемы "Архивы".

Архиваторы значений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Архивы".


Вкладка "Архиватор" (рис.4.6k) содержит основные настройки. Состав этих настроек может несколько отличаться от одного модуля этой подсистемы к другому, о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки архиватора значений у модуля архива на файловую систему Arch.FSArch:


Главная вкладка конфигурации архиватора значений подсистемы "Архивы". (100 Кб)
Рис. 4.6k. Главная вкладка конфигурации архиватора значений подсистемы "Архивы".

Вкладка "Архивы" (рис.4.6l) содержит таблицу с информацией об архивах, обрабатываемых архиватором. В строках таблица содержит архивы, а в колонках информацию:


В случае с модулем Arch.FSArch в этой вкладке ещё содержится форма экспорта данных архиватора.


Вкладка "Архивы" архиватора значений подсистемы "Архивы". (89 Кб)
Рис. 4.6l. Вкладка "Архивы" архиватора значений подсистемы "Архивы".

4.7. Подсистема "Пользовательские интерфейсы"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Пользовательские интерфейсы", содержащая вкладку "Модули". Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы и идентична для всех модульных подсистем.


Каждый модуль подсистемы "Пользовательские интерфейсы" предоставляет конфигурационную страницу с вкладками "Пользовательский интерфейс" и "Модуль". Вкладка "Пользовательский интерфейс" (рис.4.7a) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Пользовательские интерфейсы" (рис.4.1d), состав которой идентичен для всех модулей.


Вкладка "Пользовательский интерфейс" модуля подсистемы "Пользовательские интерфейсы". (85 Кб)
Рис. 4.7a. Вкладка "Пользовательский интерфейс" модуля подсистемы "Пользовательские интерфейсы".

4.8. Подсистема "Специальные"

Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Специальные", содержащая вкладку "Модули". Вкладка "Модули" (рис.4.1b) содержит список модулей подсистемы и идентична для всех модульных подсистем.


Каждый модуль подсистемы "Специальные" предоставляет конфигурационную страницу с вкладками "Специальный модуль" и "Модуль". Вкладка "Специальный модуль" (рис.4.8a) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Специальные" (рис.4.1d), состав которой идентичен для всех модулей.


Вкладка "Специальный модуль" модуля подсистемы "Специальные". (71 Кб)
Рис. 4.8a. Вкладка "Специальный модуль" модуля подсистемы "Специальные".

4.9. Подсистема "Управление модулями"

Подсистема не является модульной. Для конфигурации подсистемы предусмотрена страница подсистемы "Управление модулями", содержащая вкладку "Подсистема". Вкладка "Подсистема" (рис.4.9a) содержит основные настройки подсистемы. Состав вкладки "Подсистема":


Главная вкладка конфигурации подсистемы "Управление модулями". (147 Кб)
Рис. 4.9a. Главная вкладка конфигурации подсистемы "Управление модулями".

4.10. Конфигурационный файл OpenSCADA и параметры командной строки вызова OpenSCADA

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


Называться конфигурационный файл системы OpenSCADA может по разному, однако принято название oscada.xml и производные от него. Конфигурационный файл обычно указывается, при запуске станции, параметром командной строки "--config=/home/roman/roman/work/OScadaD/etc/oscada_demo.xml". Для удобства вызова создаются скрипты запуска станции с нужным конфигурационным файлом или используется менеджер проектов при запуске скрипта openscada_start. Например скрипт (openscada_demo) использкется для вызова демонстрационной станции:

#!/bin/sh
openscada --config=/etc/oscada_demo.xml $@


Если конфигурационный файл не указан то используется стандартный: /etc/oscada.xml .


Структурно конфигурационный файл организован на расширяемом языке разметки текста XML. Следовательно требуется жёсткое соблюдение правил синтаксиса XML. Пример образца типового конфигурационного файла OpenSCADA, с узлами конфигурации большинства компонентов OpenASCADA, приведен ниже:


<?xml version="1.0" encoding="UTF-8" ?>
<OpenSCADA>
    <!--
    This is the OpenSCADA configuration file.
    -->
    <station id="AGLKS">
        <!--
        Describe internal parameters for station.
        The station is OpenSCADA program.
        -->
        <prm id="StName">AGLKS</prm>
        <prm id="StName_ru">АГЛКС</prm>
        <prm id="StName_uk">АГЛКС</prm>
        <prm id="WorkDB">SQLite.GenDB</prm>
        <prm id="LogTarget">10</prm>
        <prm id="Lang2CodeBase">en</prm>
        <prm id="SaveAtExit">0</prm>
        <prm id="SavePeriod">0</prm>

        <node id="sub_BD">
            <prm id="SYSStPref">0</prm>
            <tbl id="DB">
                <fld ID="GenDB" TYPE="SQLite" NAME="Generic DB" NAME_ru="Основная БД" NAME_uk="Основна БД" ADDR="St.db" CODEPAGE="UTF-8"/>
            </tbl>
        </node>

        <node id="sub_Security">
            <!--
            <tbl id="Security_user">
                <fld
                    NAME="root"
                    DESCR="Super user"
                    DESCR_ru="Супер пользователь"
                    DESCR_uk="Супер користувач"
                    PASS="openscada"/>
                <fld
                    NAME="user"
                    DESCR="System user"
                    DESCR_ru="Системный пользователь"
                    DESCR_uk="Системний користувач"
                    PASS=""/>
            </tbl>
            <tbl id="Security_grp">
                <fld
                    NAME="root"
                    DESCR="Super users groups"
                    DESCR_ru="Группа суперпользователей"
                    DESCR_uk="Група суперкористувачів"
                    USERS="root;user"/>
            </tbl>-->
        </node>

        <node id="sub_ModSched">
            <prm id="ModAllow">*</prm>
            <prm id="ModDeny"></prm>
            <prm id="ChkPer">0</prm>
        </node>

        <node id="sub_Transport">
            <!--
            <tbl id="Transport_in">
                <fld
                    ID="WEB_1"
                    MODULE="Sockets"
                    NAME="Generic WEB interface"
                    NAME_ru="Основной WEB интерфейс"
                    NAME_uk="Основний WEB інтерфейс"
                    DESCRIPT="Generic transport for WEB interface."
                    DESCRIPT_ru="Основной транспорт для WEB интерфейса."
                    DESCRIPT_uk="Основний транспорт для WEB інтерфейсу."
                    ADDR="TCP::10002:0"
                    PROT="HTTP"
                    START="1"/>
                <fld
                    ID="WEB_2"
                    MODULE="Sockets"
                    NAME="Reserve WEB interface"
                    NAME_ru="Резервный WEB интерфейс"
                    NAME_uk="Резервний WEB інтерфейс"
                    DESCRIPT="Reserve transport for WEB interface."
                    DESCRIPT_ru="Резервный транспорт для WEB интерфейса."
                    DESCRIPT_uk="Резервний транспорт для WEB інтерфейсу."
                    ADDR="TCP::10004:0"
                    PROT="HTTP"
                    START="1"/>
            </tbl>
            <tbl id="Transport_out">
                <fld
                    ID="testModBus"
                    MODULE="Sockets"
                    NAME="Test ModBus"
                    NAME_ru="Тест ModBus"
                    NAME_uk="Тест ModBus"
                    DESCRIPT="Data exchange by protocol ModBus test."
                    DESCRIPT_ru="Тест обмена по протоколу ModBus."
                    DESCRIPT_uk="Тест обміну за протоколом ModBus."
                    ADDR="TCP:localhost:10502"
                    START="1"/>
            </tbl>-->
        </node>

        <node id="sub_DAQ">
            <!--
            <tbl id="tmplib">
                <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" DB="tmplib_test2"/>
            </tbl>
            <tbl id="tmplib_test2">
                <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
                    PROGRAM="JavaLikeCalc.JavaScript&#010;cnt=5*i;"/>
            </tbl>
            <tbl id="tmplib_test2_io">
                <fld TMPL_ID="test2" ID="i" NAME="I" NAME_ru="I" NAME_uk="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
                <fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_ru="Cnt" NAME_uk="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
            </tbl>-->

            <node id="mod_LogicLev">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="test2"
                        NAME="Test 2"
                        NAME_ru="Тест 2"
                        NAME_uk="Тест 2"
                        DESCR=""
                        DESCR_ru=""
                        DESCR_uk=""
                        ENABLE="1"
                        START="1"
                        PRM_BD="test2prm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" MODE="2" PRM="test2.test2"/>
                </tbl>-->
            </node>

            <node id="mod_System">
                <!--
                <tbl id="DAQ">
                    <fld
                        ID="DataOS"
                        NAME="Data OS"
                        NAME_ru="Даные ОС"
                        NAME_uk="Дані ОС"
                        DESCR="Data of services and subsystems OS."
                        DESCR_ru="Данные сервисов и подсистем ОС."
                        DESCR_uk="Дані сервісів та підсистем ОС."
                        ENABLE="1"
                        START="1"
                        AUTO_FILL="0"
                        PRM_BD="DataOSprm"
                        PERIOD="1000"
                        PRIOR="0"/>
                </tbl>
                <tbl id="DataOSprm">
                    <fld SHIFR="CPU" NAME="CPU load" NAME_ru="Нагрузка CPU" NAME_uk="Навантаження CPU" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" TYPE="CPU" SUBT="gen"/>
                    <fld SHIFR="MEM" NAME="Memory" NAME_ru="Память" NAME_uk="Пам\'ять" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TYPE="MEM"/>
                </tbl>
                -->
            </node>

            <node id="mod_DiamondBoards">
                <!--
                <tbl id="DAQ">
                    <fld ID="Athena" NAME="Athena board" NAME_ru="Плата Athena" NAME_uk="Плата Athena" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="0" BOARD="25" PRM_BD_A="AthenaAnPrm" PRM_BD_D="AthenaDigPrm" ADDR="640" INT="5"
                        DIO_CFG="0" ADMODE="0" ADRANGE="0" ADPOLAR="0" ADGAIN="0" ADCONVRATE="1000"/>
                </tbl>
                <tbl id="AthenaAnPrm">
                    <fld SHIFR="ai0" NAME="AI 0" NAME_ru="AI 0" NAME_uk="AI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
                </tbl>
                <tbl id="AthenaDigPrm">
                    <fld SHIFR="di0" NAME="DI 0" NAME_ru="DI 0" NAME_uk="DI 0" DESCR="" DESCR_ru="" DESCR_uk="" EN="0" TYPE="0" PORT="0" CNL="0"/>
                </tbl>
                -->
            </node>

            <node id="mod_BlockCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="Model" NAME="Model" NAME_ru="Модель" NAME_uk="Модель" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="Model_prm" BLOCK_SH="Model_blcks" PERIOD="1000" PRIOR="0" PER_DB="0" ITER="1"/>
                </tbl>
                <tbl id="Model_blcks">
                    <fld ID="Klap" NAME="Klapan" NAME_ru="Клапан" NAME_uk="Клапан" DESCR="" DESCR_ru="" DESCR_uk=""
                        FUNC="DAQ.JavaLikeCalc.lib_techApp.klap" EN="1" PROC="1"/>
                </tbl>
                <tbl id="Model_blcks_io">
                    <fld BLK_ID="Klap" ID="l_kl1" TLNK="0" LNK="" VAL="50"/>
                    <fld BLK_ID="Klap" ID="l_kl2" TLNK="0" LNK="" VAL="20"/>
                </tbl>
                <tbl id="Model_prm">
                    <fld SHIFR="l_kl" NAME="Klap lev" NAME_ru="Полож. клапана" NAME_uk="Полож. клапана" DESCR="" DESCR_ru="" DESCR_uk=""
                        EN="1" IO="Klap.l_kl1"/>
                </tbl>
                -->
            </node>

            <node id="mod_JavaLikeCalc">
                <!--
                <tbl id="DAQ">
                    <fld ID="CalcTest" NAME="Calc Test" NAME_ru="Тест вычисл." NAME_uk="Тест обчисл." DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="CalcTest_prm" FUNC="TemplFunc.d_alarm" SCHEDULE="1" PRIOR="0" ITER="1"/>
                </tbl>
                <tbl id="CalcTest_val">
                    <fld ID="in" VAL="0"/>
                    <fld ID="alrm" VAL=""/>
                    <fld ID="alrm_md" VAL="1"/>
                    <fld ID="alrm_mess" VAL="Error present."/>
                </tbl>
                <tbl id="CalcTest_prm">
                    <fld SHIFR="alrm" NAME="Alarm" NAME_ru="Авария" NAME_uk="Аварія" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" FLD="alrm"/>
                </tbl>
                <tbl id="lib">
                    <fld ID="TemplFunc" NAME="" NAME_ru="" NAME_uk="" DESCR="" ESCR_ru="" DESCR_uk="" DB="lib_TemplFunc"/>
                </tbl>
                <tbl id="lib_TemplFunc">
                    <fld ID="d_alarm" NAME="Digit alarm" NAME_ru="Авария по дискр." NAME_uk="Аварія за дискр" DESCR=""
                        FORMULA="alrm=(in==alrm_md)?&quot;1:&quot;+alrm_mess:&quot;0&quot;;"/>
                </tbl>
                <tbl id="lib_TemplFunc_io">
                    <fld F_ID="d_alarm" ID="in" NAME="Input" NAME_ru="Вход" NAME_uk="Вхід" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
                    <fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_ru="Авария" NAME_uk="Аварія" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
                    <fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_ru="Режим аварии" NAME_uk="Режим аварії"
                        TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
                    <fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_ru="Сообщ. аварии" NAME_uk="Повід. аварії"
                        TYPE="0" MODE="0" DEF="" HIDE="0" POS="3"/>
                </tbl>-->
            </node>

            <node id="mod_Siemens">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" CIF_DEV="0" ADDR="5" ASINC_WR="0"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" TMPL="S7.ai_man"/>
                </tbl>-->
            </node>

            <node id="mod_SNMP">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        ENABLE="1" START="1" PRM_BD="test2prm" PERIOD="1000" PRIOR="0" ADDR="localhost" COMM="public" PATTR_LIM="20"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" OID_LS="system"/>
                </tbl>-->
            </node>

            <node id="mod_ModBus">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" TRANSP="Sockets" ADDR="exlar.diya.org" NODE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1"
                        ATTR_LS="321:0:tst:Test"/>
                </tbl>-->
            </node>

            <node id="mod_DAQGate">
                <!--
                <tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1000" PRIOR="0" SYNCPER="60" STATIONS="loop" CNTRPRM="System.AutoDA"/>
                </tbl>-->
            </node>

            <node id="mod_DCON">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" ADDR="" REQ_TRY="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" MOD_TP="0"
                        MOD_ADDR="1" CRC_CTRL="1"/>
                </tbl>-->
            </node>

            <node id="mod_ICP_DAS">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" PERIOD="1" PRIOR="0" BUS="1" BAUD="115200" LP_PRMS="" REQ_TRY="3"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1"
                        MOD_TP="552985" MOD_ADDR="0" MOD_SLOT="1" MOD_PRMS="0"/>
                </tbl>-->
            </node>

            <node id="mod_OPC_UA">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" SCHEDULE="1" PRIOR="0" SYNCPER="60" ADDR="" EndPoint="opc.tcp://localhost:4841" SecPolicy="None"
                        SecMessMode="1" Cert="" PvKey="" AttrsLimit="100"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" ND_LS=""/>
                </tbl>-->
            </node>

            <node id="mod_SoundCard">
                <!--<tbl id="DAQ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" ENABLE="1" START="1"
                        PRM_BD="test2prm" CARD="" SMPL_RATE="8000" SMPL_TYPE="1"/>
                </tbl>
                <tbl id="test2prm">
                    <fld SHIFR="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" EN="1" CHANNEL="0"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Archive">
            <prm id="MessBufSize">1000</prm>
            <prm id="MessPeriod">5</prm>
            <prm id="ValPeriod">1000</prm>
            <prm id="ValPriority">10</prm>
            <!--
            <tbl id="Archive_mess_proc">
                <fld
                    ID="StatErrors"
                    MODUL="FSArch"
                    NAME="Errors"
                    NAME_ru="Ошибки"
                    NAME_uk="Помилки"
                    DESCR="Local errors\' archive"
                    DESCR_ru="Архив локальных ощибок"
                    DESCR_uk="Архів локальних помилок"
                    START="1"
                    CATEG="/DemoStation*"
                    LEVEL="4"
                    ADDR="ARCHIVES/MESS/stError/"/>
                <fld
                    ID="NetRequsts"
                    MODUL="FSArch"
                    NAME="Net requests"
                    NAME_ru="Сетевые запросы"
                    NAME_uk="Мережеві запити"
                    DESCR="Requests to server through transport Sockets."
                    DESCR_ru="Запросы к серверу через транспорт Sockets."
                    DESCR_uk="Запити до сервера через транспорт Sockets."
                    START="1"
                    CATEG="/DemoStation/Transport/Sockets*"
                    LEVEL="1"
                    ADDR="ARCHIVES/MESS/Net/"/>
            </tbl>
            <tbl id="Archive_val_proc">
                <fld
                    ID="1h"
                    MODUL="FSArch"
                    NAME="1hour"
                    NAME_ru="1час"
                    NAME_uk="1год"
                    DESCR="Averaging for hour"
                    DESCR_ru="Усреднение за час"
                    DESCR_uk="Усереднення за годину"
                    START="1"
                    ADDR="ARCHIVES/VAL/1h/"
                    V_PER="360"
                    A_PER="60"/>
            </tbl>
            <tbl id="Archive_val">
                <fld
                    ID="test1"
                    NAME="Test 1"
                    NAME_ru="Тест 1"
                    NAME_uk="Тест 1"
                    DESCR="Test 1"
                    DESCR_ru="Тест 1"
                    DESCR_uk="Тест 1"
                    START="1"
                    VTYPE="1"
                    BPER="1"
                    BSIZE="200"
                    BHGRD="1"
                    BHRES="0"
                    SrcMode="0"
                    Source=""
                    ArchS=""/>
            </tbl>-->
        </node>

        <node id="sub_Protocol">
        </node>

        <node id="sub_UI">
            <node id="mod_QTStarter">
                <prm id="StartMod">QTCfg</prm>
            </node>
            <node id="mod_WebCfg">
                <prm id="SessTimeLife">20</prm>
            </node>
            <node id="mod_VCAEngine">
                <!--
                <tbl id="LIB">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk=""
                        DB_TBL="wlib_test2" ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2">
                    <fld ID="test2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="wlib_test2_io">
                    <fld IDW="test2" ID="name" IO_VAL="Test 2" IO_VAL_ru="Тест 2" IO_VAL_uk="Тест 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                    <fld IDW="test2" ID="dscr" IO_VAL="Test module 2" IO_VAL_ru="Тест модуля 2" IO_VAL_uk="Тест модуля 2" SELF_FLG=""
                        CFG_TMPL="" CFG_TMPL_ru="" CFG_TMPL_uk="" CFG_VAL=""/>
                </tbl>
                <tbl id="PRJ">
                    <fld ID="test2" NAME="Test 2" NAME_ru="Тест 2" NAME_uk="Тест 2" DESCR="" DESCR_ru="" DESCR_uk="" DB_TBL="prj_test2"
                        ICO="" USER="root" GRP="UI" PERMIT="436"/>
                </tbl>
                <tbl id="prj_test2">
                    <fld OWNER="/test2" ID="pg1" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
                    <fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" PROC_ru="" PROC_uk="" PROC_PER="-1"
                        USER="root" GRP="UI" PERMIT="436" FLGS="0"/>
                </tbl>
                <tbl id="prj_test2_incl">
                    <fld IDW="/prj_test2/pg_pg1" ID="wdg1" PARENT="/wlb_originals/wdg_Box"/>
                </tbl>-->
            </node>
        </node>

        <node id="sub_Special">
            <node id="mod_SystemTests">
                <prm id="Param" on="0" per="5" name="LogicLev.experiment.F3"/>
                <prm id="XML" on="0" per="10" file="/etc/oscada.xml"/>
                <prm id="Mess" on="0" per="10" categ="" arhtor="DBArch.test3" depth="10"/>
                <prm id="SOAttach" on="0" per="20" name="../../lib/openscada/daq_LogicLev.so" mode="0" full="1"/>
                <prm id="Val" on="0" per="1" name="LogicLev.experiment.F3.var" arch_len="5" arch_per="1000000"/>
                <prm id="Val" on="0" per="1" name="System.AutoDA.CPULoad.load" arch_len="10" arch_per="1000000"/>
                <prm id="DB" on="0" per="10" type="MySQL" addr="server.diya.org;roman;123456;oscadaTest" table="test" size="1000"/>
                <prm id="DB" on="0" per="10" type="DBF" addr="./DATA/DBF" table="test.dbf" size="1000"/>
                <prm id="DB" on="0" per="10" type="SQLite" addr="./DATA/test.db" table="test" size="1000"/>
                <prm id="DB" on="0" per="10" type="FireBird" addr="server.diya.org:/var/tmp/test.fdb;roman;123456" table="test" size="1000"/>
                <prm id="TrOut" on="0" per="1" addr="TCP:127.0.0.1:10001" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:10001" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UNIX:./oscada" type="Sockets" req="time"/>
                <prm id="TrOut" on="0" per="1" addr="UDP:127.0.0.1:daytime" type="Sockets" req="time"/>
                <prm id="SysContrLang" on="0" per="10" path="/Archive/FSArch/mess_StatErrors/%2fprm%2fst"/>
                <prm id="ValBuf" on="0" per="5"/>
                <prm id="Archive" on="0" per="30" arch="test1" period="1000000"/>
                <prm id="Base64Code" on="0" per="10"/>
            </node>
        </node>
  </station>

</OpenSCADA>


Рассмотрим детальнее структуру конфигурационного файла. Один конфигурационный файл может содержать конфигурацию нескольких станций в секциях <station id="AGLKS"/>. Атрибутом указывается идентификатор станции. Использование той или иной секции станции, при вызове, указывается параметром командной строки --station=AGLKS. Секция станции непосредственно содержит параметры станции и секции подсистем. Параметры конфигурации секции записываются в виде <prm id="StName">AGLKS</prm>. Где в атрибуте <id> указывается идентификатор атрибута, а в теле тега указывается значение параметра "AGLKS". Перечень доступных параметров и их описание для станции и всех остальных секций можно получить в консоли, посредством вызова OpenSCADA с параметром --help.


Секции подсистем (<node id="sub_DAQ" />) содержат параметры подсистемы, секции модулей и секции таблиц отражения данных баз данных в конфигурационном файле. Секции модулей (<node id="mod_DiamondBoards" />) содержат индивидуальные параметры модулей и секции таблиц отражения данных баз данных в конфигурационном файле.


Секции таблиц отражения данных баз данных предназначены для размещения в конфигурационном файле записей таблиц БД для компонентов OpenSCADA. Рассмотрим таблицу входящих транспортов "Transport_in" подсистемы транспорты (<node id="sub_Transport">) из примера конфигурационного файла выше. Таблица содержит две записи с полями: ID, MODULE, NAME, DESCRIPT, ADDR, PROT, START. После загрузки с такой секцией и вообще без БД в подсистеме "Транспорты" модуля "Sockets" появятся два входных транспорта. Форматы структур таблиц основных компонентов включены в демонстрационные конфигурационные файлы. За деталями структуры БД нужно обращаться к документации соответствующих модулей или просто сохранить объект в конфигурационом файле.


Результат вызова команды: # ./openscada_AGLKS --help


5. Общесистемное API пользовательского программирования.

API пользовательского программирования представляет собой дерево объектов системы OpenSCADA, каждый объект которого может представлять собственный перечень свойств и функций. Свойства и функции объектов могут использоваться пользователем в процедурах на языках пользовательского программирования OpenSCADA. Точкой входа для доступа к объектам системы OpenSCADA из языка пользовательского программирования JavaLikeCalc является зарезервированное слово "SYS" корневого объекта OpenSCADA. Например, для доступа к функции исходящего транспорта нужно записать: SYS.Transport.Serial.out_ModBus.messIO(mess);.


API объектов, предоставляемых модулями, описывается в собственной документации модуля.

5.1. Общесистемные пользовательские объекты.

Абстрактный объект представляет собой ассоциативный контейнер свойств и функций. Свойства могут содержать как данные четырёх базовых типов, так и другие объекты. Доступ к свойствам объекта обычно осуществляется посредством записи имён свойств через точку к объекту "obj.prop", а также посредством заключения имени свойства в квадратные скобки "obj["prop"]". Очевидно, что первый механизм статичен, а второй позволяет указывать имя свойства через переменную. Базовое определение объекта не содержит функций. Операции копирования объекта на самом деле делают ссылку на исходный объект. При удалении объекта осуществляется уменьшения счётчика ссылок, а при достижении счётчика ссылок нуля объект удаляется физически.


Разные компоненты могут доопределять базовый объект особыми свойствами и функциями. Стандартным расширением объекта является массив "Array".

Объект Array

Особенностью массива является то, что он работает со свойствами, как с индексами, и полное их именование бессмысленно, а значит доступен механизм обращения только заключением индекса в квадратные скобки "arr[1]". Массив хранит свойства в собственном контейнере одномерного массива. Цифровые свойства массива используются для доступа непосредственно к массиву, а символьные работают как свойства объекта.


Массив предоставляет специальное свойство "length" для получения размера массива "var = arr.length;". Также массив предоставляет следующие функции:

Объект RegExp

Объект работы с регулярными выражениями, основан на библиотеке PCRE. При глобальном поиске устанавливается атрибут объекта "lastIndex", что позволяет продолжить поиск при следующем вызове функции. В случае неудачного поиска атрибут "lastIndex" сбрасывается в ноль.


В качестве аргументов создания объекта передаётся строка с текстом регулярного выражения и флаги в виде строки символов:


Свойства объекта:


Функции объекта:


Объект XMLNodeObj

Функции:

5.2. Система (SYS)

Функции объекта:

5.3. Любой объект (TCntrNode) дерева OpenSCADA (SYS.*)

Функции объекта:

5.4. Подсистема "Безопасность" (SYS.Security)

Функции объекта подсистемы (SYS.Security):


Функции объекта пользователя (SYS.Security["usr_User"]):


Функции объекта группы (SYS.Security["grp_Group"]):

5.5. Подсистема "БД" (SYS.BD)

Функции объекта БД (SYS.BD["TypeDB"]["DB"]):


Функции объекта Таблицы (SYS.BD["TypeDB"]["DB"]["Table"]):


5.6. Подсистема "Сбор данных" (SYS.DAQ)

Функции объекта подсистемы (SYS.DAQ):


Функции объекта контроллера (SYS.DAQ["Modul"]["Controller"]):


Функции объекта параметра контроллера (SYS.DAQ["Modul"]["Controller"]["Parameter"]):


Функции объекта атрибута параметра контроллера (SYS.DAQ["Modul"]["Controller"]["Parameter"]["Attribute"]):


Функции объекта библиотеки шаблона (SYS.DAQ[tmplb_Lib"]) и шаблона (SYS.DAQ[tmplb_Lib"]["Tmpl"]) параметра контроллера:

5.6.1. Модуль DAQ.JavaLikeCalc


Объект "Библиотека функций" (SYS.DAQ.JavaLikeCalc["lib_Lfunc"])

  • ElTp {funcID}(ElTp prm1, ...) — вызов функции "funcID" библиотеки "Lfunc". Возвращает результат вызываемой функции. Префикс "lib_" перед идентификатором библиотеки обязателен!

Объект "Пользовательская функция" (SYS.DAQ.JavaLikeCalc["lib_Lfunc"]["func"])

  • ElTp call(ElTp prm1, ...) — вызов функции "func" библиотеки "Lfunc" с параметрами "prm{N}". Возвращает результат вызываемой функции. Префикс "lib_" перед идентификатором библиотеки обязателен!

5.6.2. Модуль DAQ.LogicLev


Объект "Параметр" [this]

  • bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [для включенного параметра стандартного типа] — добавить атрибут id с именем name и для типа tp. Если атрибут уже присутствует, то будут применены свойства, которые возможно изменить "на ходу": имя, режим выбора и параметры выбора.
    • id, name — идентификатор и имя нового атрибута;
    • tp — тип атрибута [boolean | integer | real | string | text | object] + режим выбора [sel | seled] + только для чтения [ro];
    • selValsNms — две строки со значениями в первой и их именами во второй (разделённые ";").
  • bool attrDel( string id ) [для включенного параметра стандартного типа] — удалить атрибут id.

5.6.3. Модуль DAQ.BlockCalc


Объект "Блок" (SYS.DAQ.BlockCalc["cntr"]["blk_block"])

  • ElTp cfg(string nm) — получение значения конфигурационного поля nm объекта.
  • bool cfgSet(string nm, ElTp val) — установка конфигурационного поля nm объекта в значение val.
  • TCntrNodeObj cntr() — возвращает объект контроллера этого параметра, независимо от вложенности.

5.6.4. Модуль DAQ.ModBus


Объект "Контроллер" [this.cntr()]

  • string messIO(string pdu) — отправка PDU pdu через транспорт объекта контроллера посредством ModBus протокола. PDU результата запроса помещается вместо запроса в pdu, а ошибка возвращается в результате функции.

Объект "Параметр" [this]

  • bool attrAdd( string id, string name, string tp = "real", string selValsNms = "" ) [для включенного параметра логического типа] — добавить атрибут id с именем name и для типа tp. Если атрибут уже присутствует, то будут применены свойства, которые возможно изменить "на ходу": имя, режим выбора и параметры выбора.
    • id, name — идентификатор и имя нового атрибута;
    • tp — тип атрибута [boolean | integer | real | string | text | object] + режим выбора [sel | seled] + только для чтения [ro];
    • selValsNms — две строки со значениями в первой и их именами во второй (разделённые ";").
  • bool attrDel( string id ) [для включенного параметра логического типа] — удалить атрибут id.

5.7. Подсистема "Архивы" (SYS.Archive)

Функции объекта подсистемы:


Функции объекта архиватора сообщений (SYS.Archive["mod_Modul"]["mess_Archivator"]):


Функции объекта архиватора значений (SYS.Archive["val_Modul"]["val_Archivator"]):


Функции объекта архива (SYS.Archive["va_Archive"]):

5.8. Подсистема "Транспорты" (SYS.Transport)

Функции объекта входящего транспорта (SYS.Transport["Modul"]["in_Transp"]):


Функции объекта исходящего транспорта (SYS.Transport["Modul"]["out_Transp"]):


5.9. Подсистема "Пользовательские интерфейсы" (SYS.UI)

5.9.1. Модуль UI.VCAEngine

Action source page doesn't exist yet(/Doc / Koncepcija Sredy Vizualizacii / part 4 / part 14?)

5.10. Подсистема "Специальные" (SYS.Special)

5.10.1. Модуль Special.FLibSYS


Объект "Библиотека функций" (SYS.Special.FLibSYS)

  • ElTp {funcID}(ElTp prm1, ...) — вызов функции библиотеки {funcID}. Возвращает результат вызываемой функции.

Объект "Пользовательская функция" (SYS.Special.FLibSYS["funcID"])

  • ElTp call(ElTp prm1, ...) — вызов данной функции с параметрами <prm{N}>. Возвращает результат вызываемой функции.

5.10.2. Модуль Special.FLibMath


Объект "Библиотека функций" (SYS.Special.FLibMath)

  • ElTp {funcID}(ElTp prm1, ...) — вызов функции библиотеки {funcID}. Возвращает результат вызываемой функции.

Объект "Пользовательская функция" (SYS.Special.FLibMath["funcID"])

  • ElTp call(ElTp prm1, ...) — вызов данной функции с параметрами <prm{N}>. Возвращает результат вызываемой функции.

5.10.3. Модуль Special.FLibComplex1


Объект "Библиотека функций" (SYS.Special.FLibComplex1)

  • ElTp {funcID}(ElTp prm1, ...) — вызов функции библиотеки {funcID}. Возвращает результат вызываемой функции.

Объект "Пользовательская функция" (SYS.Special.FLibComplex1["funcID"])

  • ElTp call(ElTp prm1, ...) — вызов данной функции с параметрами <prm{N}>. Возвращает результат вызываемой функции.

Ссылки

Referring pages: Developers
Doc
Doc/API/part2
Doc/DCON
Doc/HTTP
Doc/JavaLikeCalc
Doc/ModBus
Doc/ModuleBuild
Doc/QuickStart
Doc/VCA/part4/part5
Doc/VCAEngine
Doc/Vision
Doc/WebVision
HomePageUk/Developers
HomePageUk/Doc
HomePageUk/Doc/HTTP
HomePageUk/Doc/JavaLikeCalc
HomePageUk/Doc/ModBus
HomePageUk/Doc/ModuleBuild
HomePageUk/Doc/WebVision
Using/GraphicElementsLibraries/MainElements


 
There are 2 files on this page.[Display files/form]
Comments [Hide comments/form]