Данный документ является руководством программы с открытыми исходными текстами именуемую "OpenSCADA". OpenSCADA представляет собой открытую SCADA систему, построенную по принципам модульности, многоплатформенности и масштабируемости.
В качестве политики разработки данной программы выбраны "open source" принципы. Выбор данной политики определяется необходимостью создания открытой, надёжной и общедоступной SCADA системы. Данная политика позволяет привлечь к разработке, тестированию, развитию, распространению и использованию программы значительное количество разработчиков, энтузиастов и других заинтересованных лиц с минимизацией и распределением усилий и финансовых затрат.
OpenSCADA предназначена для сбора, архивирования, визуализации информации, выдачи управляющих воздействий, а также других родственных операций, характерных для полнофункциональных SCADA систем. Благодаря высокому уровню абстракции и модульности программа может использоваться во многих смежных отраслях.
OpenSCADA может и применяться на/в:
В качестве основной операционной системы (программной платформы) для разработки и использования выбрана ОС Linux, которая является оптимальным решением в вопросах:
Поскольку проект разрабатывается и реализуется по принципам многоплатформенности то не составляет особой проблемы портировать его на другие операционные системы (программные платформы) и аппаратные платформы. Что запланировано на будущее и в значительной степени уже осуществлено для некоторых платформ.
Сердцем программы является модульное ядро. И в зависимости от того, какие модули подключены, программа может выступать как в роли различных серверов, так и в роли разнообразных клиентов, а также совмещать эти функции в одной программе. Это позволяет реализовывать клиент-серверную архитектуру на базе одних и тех же компонентов/модулей, экономя при этом машинную память, дисковое пространство, а также ценное время программистов.
Серверные конфигурации программы предназначены для выдачи управляющих воздействий, сбора, обработки, архивирования, протоколирования информации от различных источников, а также предоставления этой информации клиентам (UI, GUI, TUI ...). Модульная архитектура позволяет расширять функциональность сервера без его перегрузки.
Клиентские конфигурации могут строиться на основе различных графических библиотек (GUI/TUI ToolKits), как используя ядро программы и его модули (путём добавления к нему модуля пользовательского интерфейса), так и в качестве самостоятельного приложения, подключая ядро OpenSCADA как библиотеку.
Возможность гибкой конфигурации программы позволяет строить решения под конкретные требования надёжности, функциональности и размеры-сложность программы.
Про фактические функции и требования OpenSCADA Вы можете прочитать на странице "Функции и требования", а в этом документе мы рассмотрим общие функции и свойства программы.
Для придания гибкости и высокой степени масштабируемости OpenSCADA построена по модульному принципу. Тесная интеграция модулей с ядром улучшает стабильность програми в целом, благодаря повторному использованию отлаженного кода. Однако сам процесс разработки собственного кода модулей OpenSCADA накладывает большую ответственность — возможные ошибки вводят элемент нестабильности в программу. Возможность создания распределённых конфигураций сглаживает эту опасность.
Модули OpenSCADA хранятся в динамических библиотеках. Каждая динамическая библиотека может содержать множество модулей различного типа. Наполнение динамических библиотек модулями определяется функциональной связностью самих модулей. Динамические библиотеки допускают горячую замену, что позволяет производить обновление отдельных частей программы в процессе функционирования. Метод хранения кода модулей в динамических библиотеках является основным для OpenSCADA, поскольку поддерживается практически всеми современными операционными системами(ОС). Однако это не исключает возможности разработки других методов хранения кода модулей.
На основе модулей реализованы следующие функциональные части OpenSCADA:
Управление модулями осуществляется подсистемой "Диспетчер модулей". Функциями подсистемы является: подключение, отключение, обновление и другие операции, связанные с модулями и библиотеками модулей.
Архитектурно OpenSCADA делится на подсистемы. Подсистемы могут быть двух типов: обычные и модульные. Модульные подсистемы обладают свойством расширения посредством модулей. Каждая модульная подсистема может содержать множество модульных объектов. Например, модульная подсистема "Базы данных" содержит модульные объекты типов баз данных. Модульный объект является корнем внутри модуля.
Всего OpenSCADA содержит девять подсистем, из них семь являются модульными. Эти девять подсистем OpenSCADA являются базовыми и присутствуют в любой конфигурации. К списку девяти подсистем могут добавляться новые, посредством самих модулей. Подсистемы OpenSCADA:
Подсистема "Сбор данных" (Рис.1.3) предусмотрена для предоставления поддержки источников динамических данных, будь то: ПЛК, платы УСО, виртуальные источники и другое. В функции этой подсистемы входит предоставление полученных данных в структурированном виде — модель данных и обеспечение управления этими данными, например — модификация данных.
Подсистема "Сбор данных" является модульной и, как следствие, содержит модульные объекты типов источников динамических данных. Например, OpenSCADA сейчас предоставляет более чем двадцать модулей и библиотечных элементов источников логических типов. Наиболее значимые и проработанные с которых:
Каждый тип источника нелогического типа реализуется в отдельном модуле, который может содержать множество источников (объектов контроллеров) и каждый этот источник обычно выполняется в отдельном потоке-задаче.
Отдельно взятый объект контроллера может содержать параметры определённых модулем типов. Например, параметры аналогового типа, основной информацией которых являются значения целого или реального типа. Структурно параметр представляет собой перечень атрибутов, которые и содержат данные. Атрибуты могут быть пяти базовых типов: логический, целый, реальный, символьная строка(текст) и объект. Структуры объектов контроллеров, параметров и их типов содержатся в подсистеме "Сбор данных", а объекты модулей осуществляют их наполнение согласно собственной специфики.
Отдельные типы источников данных сами могут продуцировать данные как полностью их генерируя, так и обрабатывая физические данные и даже полностью реализуя получение этих данных в окружении OpenSCADA и на её внутреннем языке. Такие источники данных называются логическими. Полностью логические источники данных представлены модулями: LogicLev и BlockCalc. Существует ряд модулей, которые объединяют в себе логические данные как результат непосредственной обработки физических: ModBus и Siemens.
Источники динамических данных могут быть удалёнными, т.е. формироваться или получаться на удалённой станции OpenSCADA. Для связи с такими источниками данных используется модуль шлюзования DAQGate. Функцией этого типа источников данных является отражение источников данных удалённой OpenSCADA станции на локальную.
Детально ознакомиться с ключевой подсистемой "Сбор данных" и её функциями Вы можете в отдельном документе "Сбор данных в OpenSCADA".
Для хранения данных программы повсеместно используются базы данных (БД). С целью унификации доступа и управления базами данных в OpenSCADA предусмотрена подсистема "Базы данных" (Рис.1.4). Для обеспечения поддержки различных БД/СУБД подсистема выполнена модульной.
В роли модульного объекта, который содержится в подсистеме, выступает тип БД/СУБД, т.е. модуль подсистемы "Базы данных" практически содержит реализацию доступа к определённому типу БД. OpenSCADA предоставляет следующие наиболее значительные и проработанные модули: SQLite, MySQL, PostgreSQL, FireBird.
Тип БД/СУБД в свою очередь содержит перечень объектов отдельных БД этого типа, а объект БД содержит перечень объектов таблиц, которые и содержат данные в табличном виде.
Практически все данные OpenSCADA хранятся в той или иной БД. Инструментарий программы позволяет легко переносить данные из одного типа БД в другой, и, как следствие, оптимально подбирать тип БД под конкретную область применения OpenSCADA. Перенос информации с одной БД в другую может быть выполнен двумя способами. Первый — это изменение адреса рабочей БД и сохранение всей конфигурации программы на неё, второй — это прямое копирование информации между БД. Кроме копирования поддерживается и функция прямого редактирования содержимого таблиц БД.
Для организации централизованного доступа распределённой программы к единой БД предусматривается два способа. Первый это использование сетевых СУБД, например — MySQL. Второй способ это использование транспортного типа БД на локальных станциях, для доступа к единой центральной БД другой OpenSCADA станции, через пересылку запросов к БД на этой удалённой станции — не реализовано ещё в OpenSCADA.
Данные могут храниться также в конфигурационном файле программы. Реализован механизм полного отражения структуры БД на структуру конфигурационного файла. Т.е. стандартную конфигурацию можно размещать в конфигурационном файле. Смысл такого механизма состоит в том, что типовые (по умолчанию) данные программы можно описывать в конфигурационном файле, например — при старте без БД. Далее эти данные могут переопределяться в БД. Кроме того, для случаев невозможности запуска какой нибудь БД вообще, можно все данные хранить в конфигурационном файле.
Для доступа к базам данных используется механизм регистрации БД. Зарегистрированные в программе БД доступны всем подсистемам OpenSCADA и могут использоваться в их работе. Благодаря этому механизму можно обеспечить разделение хранения данных. Например, различные библиотеки могут храниться и распространяться независимо, а подключения библиотеки будет заключаться в простой регистрации нужной БД.
Любая SCADA система должна предоставлять возможность архивации собранных данных, т.е. формирование истории изменения (динамики) процесса. Архивы условно можно разделить на два типа: архивы сообщений и архивы значений.
Особенностью архивов сообщений является архивация так называемых сообщений программы, а именно — ведение логов и протоколов. Характерной особенностью сообщения является время его возникновения. В зависимости от источника сообщения могут классифицироваться по различным критериям. Например, это могут быть протоколы аварийных ситуаций, протоколы действий операторов, протоколы отказов связи и другое.
Особенностью архивов значений является их периодичность, которая определяется промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный то и архивировать его можно только путём введения понятия квантования опроса значений, иначе мы получим архивы бесконечных размеров, в соответствии с непрерывностью самой природы процесса. Кроме того, практически мы можем получить значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1 кГц, и это без учёта самих датчиков которые имеют менее качественные частотные характеристики.
Для решения задач архивирования потоков данных в OpenSCADA предусмотрена подсистема "Архивы-История" (Рис.1.5), которая является модульной и позволяет вести архивы сообщений и значений. Модульным объектом, который содержится в подсистеме "Архивы-История", выступает тип архиватора. Тип архиватора определяет способ хранения данных т.е. хранилище — файловая система, СУБД. Каждый модуль подсистемы "Архивы-История" соответственно может реализовывать архивирование сообщений и значений, а сама подсистема может содержать множество архивов, которые обслуживаются различными модулями.
Сообщения в OpenSCADA характеризуются датой, уровнем важности, категорией и непосредственно текстом сообщения. Дата сообщения соответственно указывает на дату и время его создания. Уровень важности указывает на степень важности сообщения. Категория определяет адрес или условный идентификатор-ключ источника сообщения. Часто категория содержит полный путь к источнику сообщения в программе. Текст сообщения соответственно и несет главную смысловую нагрузку сообщения.
В процессе архивирования сообщения пропускаются через фильтр, который работает по уровню важности и категории сообщений. Уровень сообщений в фильтре указывает на то, что нужно пропускать сообщения с указанным или высшим уровнем важности. Для фильтрации по категории применяются шаблоны или регулярные выражения, которые определяют какие сообщения пропускать. Каждый архиватор содержит собственные настройки фильтра, соответственно можно легко создавать различные специализированные архиваторы для архива сообщений. Например, архиваторы сообщений можно направить на:
Ввиду схожести природы сообщений и нарушений подсистема "Архивы-История" содержит буфер текущий нарушений, который содержит активные на текущее время нарушения с категорией сообщения в роли ключа-идентификатора нарушения. Доступ к перечню-буферу текущих нарушений осуществляется путём указания отрицательного значения уровня сообщений. Так, формирование сообщений с отрицательным уровнем -2 вызывает помещение этого сообщений в буфер активных нарушений с уровнем 2, а также дублирование его непосредственно в архиве сообщений (буфере общих сообщений). При формировании сообщения в такой-же категории, но с положительным уровнем — скажем 1, будет осуществлено удаление указанного нарушения из буфера нарушений, а само сообщений также попадёт в архив сообщений (буфер общих сообщений). Такой механизм позволяет одновременной вести учёт активных нарушений и протоколировать их прохождение в архиве сообщений. При запросе к архиву сообщений, указание положительного уровня осуществляет запрос к архиву сообщений (через общий буфер сообщений), а отрицательного к буферу-перечню текущих нарушений.
Строгой структуры категории и текста сообщения не предусматривается и пользователь, для собственных сообщений, может формировать их производно, но стоит учесть структуру системных сообщений и сообщений, определённых стандартными библиотеками OpenSCADA, чтобы исключить пересечение с ними, или предметно расширить:
Архивы значений в OpenSCADA выступают как независимые компоненты, которые включают буферы, обрабатываемые архиваторами. Основным параметром архивов значений является источник данных, в роли которого могут выступать атрибуты параметров подсистемы "Сбор Данных", а также другие внешние источники данных (пассивный режим). Другими источниками данных могут быть сетевые архиваторы удалённых станций OpenSCADA, среда программирования OpenSCADA и другое.
Ключевым компонентом архивирования значений непрерывных процессов является буфер значений, который предназначен для промежуточного хранения массива значений, полученного с указанной периодичностью (квантом времени). Буфер значений используется для непосредственного хранения больших массивов значений в архивах значений как перед непосредственным "сбросом" на физический носитель, так и для манипуляций с кадрами значений, т.е. в функциях покадрового запроса значений и их помещения в буфере архивов.
Для организации удалённых архиваторов в распределённых конфигурациях используется транспортный тип архиватора, на данный момент не реализовано в OpenSCADA. Функцией транспортного типа архиваторов является отражение удалённого центрального архиватора OpenSCADA в локальной конфигурации. Как следствие, архиваторы транспортного типа выполняют передачу данных между локальной конфигурацией и архиватором удаленной конфигурации программы, скрывая от подсистем локальной конфигурации реальную природу архиватора.
Поскольку OpenSCADA является высоко-масштабируемой то поддержка коммуникаций должна быть достаточно гибкой, для чего она реализована в подсистемах "Транспорты" и "Транспортные протоколы" (Рис.1.6), которые являются модульными.
Подсистема "Транспорты" предназначена для обеспечения обмена неструктурированными данными между OpenSCADA и внешними системами, в роли которых также могут выступать удалённые станции OpenSCADA. Под неструктурированными данными подразумевается поток символов определённой длины. Модульным объектом, который содержится в подсистеме "Транспорты", выступает тип транспорта, который и определяет механизм передачи неструктурированных данных. Например, это могут быть и есть:
Подсистема "Транспорты" включает поддержку входных и выходных транспортов. Входные транспорты предназначены для обслуживания внешних запросов и отправки ответов. Выходные транспорты наоборот предназначены для отправки сообщений и ожидания ответов. Соответственно входные транспорты содержат конфигурацию локальной станции, как сервера прослушивания запросов, а выходные транспорты содержат конфигурацию удалённого сервера, для подключения. Такая специализация характерна для типового механизма "запрос-ответ", однако на данное время входные и выходные транспорты поддерживают независимую передачу и приём данных. Модули подсистемы "Транспорты" реализуют поддержку как входных, так и выходных транспортов.
Подсистема "Транспортные протоколы" предназначена для структуризации данных, полученных от подсистемы "Транспорты", является продолжением подсистемы "Транспорты", от чего имеет такое название, и осуществляет функции проверки структуры и целостности полученных данных. В глобальной нотации, эта подсистема содержит и реализует КОММУНИКАЦИОННЫЕ протоколы! Для указания протокола, вмести с которым должен работать транспорт, предусмотрено специальное конфигурационное поле. Модульным объектом, который содержится в подсистеме "Протоколы", является сам протокол. Например, транспортными протоколами могут быть и есть:
Полную последовательность сеанса входной связи для типовых протоколов режима "запрос-ответ" можно записать следующим образом:
Протоколы также поддерживаются для выходных транспортов и берут на себя функцию общения с транспортом и реализацию особенностей этих протоколов, при подготовке данных к передаче и разборе ответов. Внешний интерфейс доступа к протоколам, из кода других модулей и окружения программирования OpenSCADA, реализуется в XML дереве с собственной структурой для каждого протокольного модуля. Такой механизм позволяет выполнять прозрачный доступ к внешним системам, посредством транспортов, просто указывая имя протокола с помощью которого обслуживать передачу.
Благодаря стандартному доступу к транспортам в OpenSCADA, можно легко менять способ обмена данными не затрагивая самих программ, которые обмениваются. Например, в случае локального обмена, можно использовать более быстрый транспорт на основе UNIX-сокетов, а в случае обмена через интернет и локальную сеть использовать TCP- или UDP-сокеты.
SCADA-системы, как класс, предусматривают наличие интерфейсов пользователя. В OpenSCADA для предоставления пользовательских интерфейсов предусмотрена подсистема "Пользовательские интерфейсы" под которой предусматривается не только среда визуализации, с которой должен работать конечный пользователя, но и всё, что имеет отношение к пользователю, например:
Подсистема "Пользовательские интерфейсы" является модульной и её модульным объектом выступает собственно конкретный интерфейс пользователя. Модульность подсистемы позволяет создавать различные интерфейсы пользователя на разных GUI/TUI библиотеках и использовать наиболее оптимальное решения в конкретно взятом случае, например, для среды исполнения программируемых логических контроллеров можно использовать конфигураторы и визуализаторы на основе Web-технологий (WebCfg, WebCfgD, WebVision, WebUser), а в случае стационарных рабочих станций использовать те-же конфигураторы и визуализаторы, но на основе библиотек вроде Qt (QTCfg, Vision).
OpenSCADA является разветвлённой программой, которая состоит из десятка подсистем и может включать множество модулей. Следовательно предоставление всем неограниченного доступа к этим ресурсам является как минимум неосторожным. Для разграничения доступа в OpenSCADA предусмотрена подсистема "Безопасность" основными функциями которой является:
OpenSCADA построена по модульному принципу, что предусматривает наличие множества модулей, которые нужно контролировать и планировать доступность, для чего предусмотрена подсистема "Диспетчер модулей". Все модули на данное время предоставляются в программу посредством разделяемых библиотек(контейнеров) или встраиваются прямо в библиотеку ядра OpenSCADA. Каждый контейнер может содержать множество модулей различного типа согласно их логической связности.
Подсистема "Диспетчер модулей" реализует контроль за состоянием контейнеров и позволяет осуществлять "горячее" добавление, удаление и обновление контейнеров и модулей, которые он содержит.
Очевидно, что невозможно предусмотреть все нужные функции и функции, которые могут понадобиться в будущем, поэтому в OpenSCADA предусмотрена подсистема "Специальные", которая является модульной и предназначена для добавления непредусмотренных функций путём модульного расширения. Например, с помощью этой подсистемы могут быть и реализованы:
Современная SCADA система должна содержать механизмы которые предоставляют возможность программирования на пользовательском уровне, т.е. — среду программирования пользователя. OpenSCADA содержит такое окружение и с его помощью можно реализовывать:
Среда программирования представляет собой комплекс средств, которые организуют вычислительное окружение пользователя в состав которого входят:
Модули библиотек функций предоставляют статические функции определённой направленности, которые расширяют объектную модель программы и представляют собой интерфейс доступа к средствам модуля на уровне пользователя. Например, "Среда Визуализации и Управления" может предоставлять функции для выдачи различных сообщений, используя которые пользователь может реализовывать интерактивные алгоритмы взаимодействия с программой. Библиотеки функций в целом могут реализовываться как набором функций фиксированного типа — статические, так и функциями, которые допускают свободную модификацию и дополнение — динамические.
Библиотеки функций свободного типа (динамические) предоставляют среду написания пользовательских функций на одном из языков программирования, на данный момент это язык похожий на Java, который реализуется модулем DAQ.JavaLikeCalc. Таким образом можно создавать библиотеки аппаратов технологических процессов и многих других, а далее использовать их путём связывания.
На основе функций, которые предоставляются объектной моделью, строятся объекты вычислительных контроллеров, которые осуществляют связывание функций с параметрами программы и механизмом вычисления. Также пишутся процедуры и протоколы сбора данных уровня пользователя, процедуры виджетов "Среды Визуализации и Управления" и много другого.
SCADA (Supervisory Control And Data Acquisition) в общем виде имеют распределённую архитектуру вроде изображённой на рисунке 2. Элементы SCADA систем, в смысле программного обеспечения, выполняют следующие функции:
Сервер сбора: представляет собой задачу или группу задач, занимающихся сбором данных из источников данных, или же сам выступает в роли источника данных. В задачи сервера входит:
Сервер архивирования-истории: представляет собой задачу или группу задач, занимающихся архивированием данных или ведением их истории. В задачи сервера входит:
Сервер протоколирования: представляет собой задачу или группу задач, занимающихся архивированием сообщений или ведением их истории. В задачи сервера входит:
Сервер сигнализации: представляет собой задачу или группу задач, выполняющих функции сервера протоколирования в отношении узкой категории сообщений сигнализации.
Рабочее место оператора: представляет собой постоянно функционирующее GUI(Grafical User Interface) приложение, выполненное в одномониторном, многомониторном или панельном режиме и выполняющее функции:
Рабочее место инженера: представляет собой GUI приложение, используемое для конфигурации SCADA систем. В задачи приложения входит:
Рабочее место руководителя: представляет собой GUI приложение, как правило выполненное в одномониторном режиме, выполняющее функции:
Рабочее место технолога: полностью включает в себя функции рабочего места оператора плюс модели технологических процессов (без непосредственной связи с технологическим процессом).
Рабочее место технолога-программиста: полностью включает в себя функции рабочего места технолога плюс инструментарий для создания моделей технологических процессов.
В простейшем случае OpenSCADA можно сконфигурировать в серверном режиме (Рис.3.1) для сбора и архивирования данных. Данная конфигурация позволяет выполнять следующие функции:
Для повышения надёжности и производительности OpenSСADA допускает множественное резервирование (Рис.3.2), при котором источники данных (контроллеры) и архивы-история одного экземпляра отражаются в другом. При использовании подобной конфигурации возможно распределение нагрузки опроса/вычисления по различным станциям. Данная конфигурация позволяет выполнять функции:
Частным случаем дублированного подключения является дублирование в рамках одного сервера (Рис.3.3), т.е. запуск нескольких станций на одной машине с перекрещиванием параметров. Целью данной конфигурации является повышение надёжности и отказоустойчивости конфигурации, путём резервирования ПО.
Для визуализации данных, содержащихся на сервере, хорошим решением является использование пользовательского WEB-интерфейса (Рис.3.4). Данное решение позволяет использовать стандартный WEB-браузер у клиента и следовательно является наиболее гибким, поскольку не привязано к одной платформе, т.е. является многоплатформенным. Однако это решение имеет существенные недостатки – это невысокая производительность и надёжность. В связи с этим рекомендуется использовать данный метод для визуализации некритичных данных или данных, имеющих резервный высоконадёжный способ визуализации. Например, хорошим решением будет использование этого метода у начальства промышленных установок, где всегда существует операторская с надёжным способом визуализации. Данная конфигурация позволяет выполнять следующие функции:
Для визуализации критических данных, а также в случае если требуется высокое качество и производительность, можно использовать визуализацию на основе OpenSCADA, сконфигурированной с GUI модулем (Рис.3.5). Данная конфигурация позволяет выполнять следующие функции:
Полнофункциональная клиент-серверная конфигурация на одной машине (Рис.3.6) может использоваться для повышения надёжности конфигурации в целом путём запуска клиента и сервера в разных процессах. Данная конфигурация позволяет без последствий для сервера останавливать клиент и выполнять с ним различные профилактические работы. Рекомендуется для использования на станциях оператора путём установки двух машин, совмещающих в себе станции оператора и резервированный сервер. Данная конфигурация позволяет выполнять следующие функции:
Смешанное подключение совмещает функции сервера и клиента (Рис.3.7). Может использоваться для тестовых, демонстрационных функций, а также для предоставления моделей и тренажёров технологических процессов как единое целое. В этом режиме могут выполняться следующие функции:
Данная конфигурация является одним из вариантов устойчивого-надёжного соединения (Рис.3.8). Устойчивость достигается путём распределения функций по:
Сервер опроса конфигурируется на основе OpenSCADA и представляет собой задачу или группу задач, занимающихся сбором данных — опросом контроллера или группы контроллеров одного типа. Полученные значения доступны центральному серверу через любой транспорт поддержка которого добавляется путём подключения соответствующего модуля транспорта. Для снижения частоты опроса и величины сетевого трафика, сервер опроса может оснащаться небольшим архивом значений. Конфигурация сервера опроса хранится в одной из доступных БД.
Центральный сервер архивирования и обслуживания клиентских запросов выполняет функцию централизованного сбора и обработки параметров серверов опроса и их значений. Доступ к серверам опроса выполняется посредством одного из доступных в OpenSCADA транспортов+протоколов (на примере это Sockets). Для предоставления единого интерфейса доступа к параметрам и контроллерам используется модуль DAQGate, который отражает данные серверов опроса на структуру локальных параметров сбора данных.
Для выполнения внутренних вычислений и дополнительного анализа параметров используются объекты вычислительных контроллеров.
Для разностороннего и глубокого архивирования используются различные модули архивов-истории.
Для доступа клиентов к серверу используются доступные у OpenSCADA сетевые транспорты, на примере — Sockets; и транспортные протоколы, на примере — протокол OpenSCADA "SelfSystem".
Конфигурация центрального сервера хранится в одной из доступных БД (на примере это сетевая СУБД MySQL).
Для предоставления пользовательского WEB-интерфейса используется модуль WebCfgD посредством транспортного протокола "HTTP".
Различные клиенты, в их числе АРМ и WEB-клиенты, выполняются на отдельных машинах в необходимом количестве. АРМ реализуется на основе OpenSCADA. В его функции входит опрос значений параметров из центрального сервера и их визуализация на GUI интерфейсе(ах). Для получения параметров сбора данных в АРМ также используется модуль отражения удалённых параметров DAQGate. Для предоставления доступа к архивам-истории может использоваться модуль архива сетевого типа. Конфигурация АРМ может храниться в одной из доступных БД (в примере это сетевая СУБД MySQL, расположенная на машине центрального сервера архивирования).
Как можно видеть в разделе выше, OpenSCADA предоставляет возможность конфигурации для исполнения в различных ролях. Поддержка этой возможности обеспечивается развитыми механизмами конфигурации, хранения конфигурационных данных и организации проектов этих конфигураций. Данный раздел содержит описание этих механизмов и призван дать представление о гибкости и разнообразии, позволив тем самым использовать OpenSCADA на все 100 процентов.
При описании механизмов конфигурации и способов её хранения в этом разделе, будет делаться упор на общие механизмы. Особенности конфигурации и использования модулей подсистем OpenSCADA предоставляются в собственной документации этих модулей.
В OpenSCADA используется декларативный подход к описанию конфигурационных интерфейсов, основанный на языке XML. Фактически, особенности конфигурации компонента программы предоставляется самим компонентом, пронизывая тем самым всю программу, как нервная система организма. В терминах OpenSCADA это называется интерфейсом контроля и управления OpenSCADA (Control interface). На основе интерфейса контроля формируются графические интерфейсы конфигурации пользователя посредством модулей OpenSCADA. Такой подход имеет следующие важные преимущества:
Для упрощения конфигурации и её хранения, OpenSCADA предусматривает проекты программы, в рамках которых предоставляется отдельная директория проекта OpenSCADA для сохранения там конфигурации и всех связанных файлов. Т.е., в ядро OpenSCADA встроен механизм выбора проекта, который осуществляет установку рабочего каталога и адреса конфигурационного файла согласно указанному проекту. Детальнее про это описано в разделе "Проекты OpenSCADA".
OpenSCADA предоставляет три модуля конфигурации на разной основе визуализации. Отметим их и их возможности конфигурации:
Значения конфигурации, изменённые в конфигураторах, а также большинство данных сохраняются в базах данных (БД). Учитывая модульность подсистемы "БД", ими могут быть различные БД. Причём предоставляется возможность хранения различных частей OpenSCADA как в разных БД одного типа, так и в БД разных типов.
Кроме базы данных конфигурации могут содержаться в конфигурационном файле OpenSCADA, а также передаваться посредством параметров командной строки при вызове OpenSCADA. Сохранение конфигурации в конфигурационном файле осуществляется наравне с БД. Типовым именем конфигурационного файла OpenSCADA является {sysconfdir}/oscada.xml (где sysconfdir типично — "/etc"), для конфигураций за проектами OpenSCADA, и {Proj}/oscada.xml для проекта "Proj". Формат конфигурационного файла и параметры командной строки рассмотрим в отдельном разделе.
Изменение конфигурации того или иного узла устанавливает флаг модификации соответствующего узла, а также активирует кнопки "Загрузить из БД", для загрузки первоначальной конфигурации, и "Сохранить в БД" для сохранения изменений. Признак модификации также поднимается к родительскому узлу, что позволяет осуществлять восстановление-сохранение от корневого узла, хотя реально в операциях с БД, будут участвовать только модифицированные узлы. 
Удаление узла приводит к непосредственному удалению его из хранилища-БД и механизм модификации на эту операцию не распространяется.
Ряд настроек и конфигураций объектов OpenSCADA, которые исполняются или уже включены, не применяются сразу-же по внесению изменений, поскольку конфигурация читается/применяется обычно только при включении или запуске. Следовательно для применения изменений в таких случаях достаточно включить/выключить включенный объект или перезапустить исполняющийся — остановить/запустить. На данный момент большинство настроек, не предусматривающих непосредственного применения, просто недоступны для редактирования.
Дальнейшее рассмотрение конфигурации OpenSCADA будет производиться на основе интерфейса конфигуратора UI.QTCfg, однако принципы работы будут полностью соответствовать остальным конфигураторам, благодаря использованию общего интерфейса контроля OpenSCADA.
Рассмотрение начнём с конфигурации системных параметров OpenSCADA, которая размещается в шести вкладках корневой страницы станции:
Вы можете выбрать или ввести другой язык кроме Английский(en), но имейте ввиду, что все стандартные библиотеки OpenSCADA сформированы для базового языка Английский(en), т.е другой базовый язык будет портить эти БД при изменении!Для модификации полей этой страницы могут потребоваться права привилегированного пользователя. Получить такие права можно, включив вашего пользователя в группу суперпользователя "root" или войдя на станцию от имени суперпользователя "root".
Нужно отметить ещё один важный момент! Поля идентификаторов всех объектов OpenSCADA недопустимы для прямого редактирования поскольку являются ключом для хранения данных объектов в БД. Однако поменять идентификатор объекта можно с помощью команды переноса и последующей вставки объекта (Cut->Paste) в конфигураторе.
Задача обслуживания механизма резервирования запускается всегда и исполняется с периодичностью, установленной в соответствующем конфигурационном поле. Реальная работа по осуществлению резервирования производится при наличии хотя бы одной резервной станции в списке станций и предполагает:
Резервирование рекомендуется настраивать таким образом чтобы БД резервных станций сохранялись одинаковыми, что в дальнейшем позволит безболезненно копировать их, при восстановлении, на любую станцию и, соответственно, в резервной копии можно хранить только один набор БД. При этом, настройки, специфичные для отдельной станции, будут сохраняться в конфигурационном файле и можно будет легко конфигурировать и менять нужную станцию через выбор соответствующего конфигурационного файла.
Настройка резервирования начинается с добавления резервных станций в список станций OpenSCADA на вкладке "Подсистема" подсистемы "Транспорты" (Рис.4.3b). Причём, добавлять тут нужно не только резервные станции к текущей, но и саму эту текущую станцию с её внешним адресом, т.е. своеобразная петля. В дальнейшем эти настройки будут сохранены в общую БД резервированной системы и сама БД с этого момента будет использоваться при создании всех резервных станций. Соответственно важно на этом этапе внести все нужные изменения в общую БД вокруг проекта в целом!
Далее, на конкретной станции с копией общей БД, настраиваем её специфические параметры во вкладке "Резервирование" главной страницы (Рис.4c), которые будут сохранены в конфигурационном файле.
После этого вся конфигурация резервирования осуществляется во вкладке "Резервирование" соответствующей подсистемы — "Сбор данных" (Рис.4.5b) или "Архивы" (Рис.4.6b). Если установить параметр "Передача локальных первичных команд" (Рис.4c) то эта конфигурация, как и любая другая общего характера, может осуществляться на одной из станций, а внесённые изменения попадут на все резервные, конечно если они будут доступны.
Для отладки различных особенностей работы OpenSCADA может потребоваться включение генерации дополнительных-отладочных сообщений, что осуществляется установкой минимального уровня сообщений, на вкладке "Станция", в "Отладка (0)". В результате этого появится вкладке "Отладка" (Рис.4e) где доступны счётчики объектов для контроля за утечками, а также таблица с перечнем категорий поступающий отладочных сообщений. В таблице категорий можно выбрать только те источники отладочных сообщений, которые нужны, тем самым не перегружая подсистему вывода и архивирования сообщений, а так-же не понижая сильно производительность программы в целом. Можно выбирать категории высших уровней, вплоть до корневой категории подсистемы, что выключит детальный выбор и включит генерацию всех сообщений по уровню или подсистеме. Для изучения отладочных сообщений нужно перейти в подсистему "Архивы" (Рис.4.6c), для чего предусмотрена кнопка "Просмотр сообщений". Выбранный режим отладки и перечень категорий отладки может быть сохранён в конфигурационном файле стандартным образом и при следующем старте режим отладки активируется сразу, что важно в первую очередь для счётчиков объектов.
При рассмотрении страниц конфигурации модульных подсистем будут описаны общие для всех модулей свойства. Однако нужно отметить, что каждый модуль может предоставлять как дополнительные вкладки, так и отдельные поля для конфигурации собственных особенностей функционирования для страниц, объекты которых наследуются модулями. С особенностями и дополнениями модулей можно ознакомиться в отдельной документации на них.
Подсистема является модульной и содержит иерархию объектов, изображённую на рисунке 1.4. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "БД", содержащая вкладку "Подсистема" и вкладку "Модули". Вкладка "Подсистема" (Рис.4.1a) на данный момен содержит только конфигурационное поле установки времени жизни открытых таблиц, в секундах. Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "БД", доступных на станции.
Для модификации полей страниц этой подсистемы могут потребоваться права привилегированного пользователя или включение вашего пользователя в группу "БД".
Каждый модуль подсистемы "БД" предоставляет конфигурационную страницу с вкладками "БД" и "Модуль". Вкладка "БД" (Рис.4.1c) содержит список объектов БД, зарегистрированных в модуле и флажок признака полного удаления БД при выполнении команды удаления. В контекстном меню списка БД пользователю предоставляется возможность добавления, удаления и перехода к нужной БД. Во вкладке "Модуль" содержится информация о модуле подсистемы "БД" (Рис.4.1d):
Каждый объект БД содержит собственную страницу конфигурации с вкладками "База данных", "Таблицы" и "SQL", в случае поддержки SQL-запросов. Кроме основных операций можно выполнять копирование содержимого БД стандартной функцией копирования объектов в конфигураторе. Операция копирования содержимого БД подразумевает копирование исходной БД в БД назначения, при этом содержимое БД назначения не очищается перед операцией копирования. Копирование содержимого БД производится при условии включения обоих БД, иначе будет выполняться простое копирование объекта БД!
Вкладка "База данных" (Рис.4.1e) содержит основные настройки объекта БД, в составе:
Вкладка "Таблицы" (Рис.4.1f) содержит список открытых таблиц. При нормальной работе программы эта вкладка пуста, поскольку после завершения работы с таблицами программа их закрывает. Наличие открытых таблиц говорит о том, что программа сейчас с таблицами работает или таблицы открыты пользователем для изучения их содержимого. В контекстном меню перечня открытых таблиц можно открыть таблицу для изучения (команда "Добавить"), закрыть открытую таблицу (команда "Удалить") и перейти к изучению её содержимого.
Вкладка "SQL" (Рис.4.1g) доступна только для баз данных, поддерживающих SQL-запросы, и содержит поле ввода запроса, кнопку отправки запроса и таблицу с результатом запроса. Для управления режимом транзакции запроса предусмотрено отдельное конфигурационное поле.
Страница изучения содержимого таблицы содержит только одну вкладку "Таблица". Вкладка "Таблица" (Рис.4.1h) содержит поле названия таблицы и таблицу с содержимым. Таблицей содержимого предоставляются функции:
Подсистема не является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Безопасность", содержащая вкладку "Пользователи и группы пользователей". Вкладка "Пользователи и группы пользователей" (Рис.4.2a) содержит списки пользователей и групп пользователей. Пользователь в группе "Security" или с правами привилегированного пользователя может добавить, удалить пользователя или группу пользователей. Все остальные пользователи могут переходить к страницам пользователей или групп пользователей и изменять ряд персональных параметров на собственной странице пользователя.
Для конфигурации пользователя предоставляется страница, содержащая только вкладку "Пользователь" (Рис.4.2b). Вкладка содержит конфигурационные данные профиля пользователя, которые может изменять сам пользователь, пользователь в группе "Security" или привилегированный пользователь:
Для конфигурации группы пользователей предоставляется страница, содержащая только вкладку "Группа" (Рис.4.2c). Вкладка содержит конфигурационные данные профиля группы пользователей, которые может изменять только привилегированный пользователь:
Подсистема является модульной и содержит иерархию объектов, изображённую на рисунке 1.6. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Транспорты", содержащая вкладки "Подсистема" и "Модули".
Вкладка "Подсистема" (Рис.4.3a) содержит таблицу конфигурации внешних, для данной, OpenSCADA станций. Внешние станции могут быть системными, пользовательскими или одновременно, что выбирается в соответствующей колонке. Системные внешние станции доступны только привилегированному пользователю и используются компонентами системного назначения, например, механизмом горизонтального резервирования и модулем DAQ.DAQGate. Пользовательские внешние станции привязаны к пользователю, который их создавал, а значит список пользовательских внешних станций индивидуален для каждого пользователя. Пользовательские внешние станции используются компонентами графического интерфейса, например: UI.QTCfg, UI.WebCfgD и UI.Vision. В таблице внешних станций возможно добавление и удаление записей про станции, а также их модификация. Каждая запись содержит поля:
Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.
Каждый модуль подсистемы "Транспорты" предоставляет конфигурационную страницу с вкладками "Транспорты" и "Модуль".
Вкладка "Транспорты" (Рис.4.3b) содержит список входных и выходных транспортов, зарегистрированных модулем. В контекстном меню списков транспортов пользователю предоставляется возможность добавления, удаления и перехода к нужному транспорту. Выходные транспорты также предоставляют функцию времени жизни, которая предусматривает закрытие транспортов по неактивности. Установите это поле в 0 для выключения этой функции!
Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспорты" (Рис.4.1d), состав которой идентичен для всех модулей.
Каждый транспорт содержит собственную страницу конфигурации с вкладкой "Транспорт". Эта вкладка содержит основные настройки транспорта. Входной транспорт (Рис.4.3c) содержит:
Выходной транспорт (Рис.4.3d) содержит:
Выходной транспорт дополнительно предоставляет вкладку формирования пользовательского запроса через данный транспорт (Рис.4.3e). Вкладка предназначена для наладки связи и протоколов обмена, и она содержит:
Входной и выходной транспорты также содержат вкладку "Лог ВВ" (Рис.4.3f). Вкладка предоставляется для общего контроля, наблюдения и изучения трафика через транспорты и включает поле длины лога и ограничение блока и саму текстовую область лога. Для отключения лога Вы можете поле длины лога установить в ноль.
Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Транспортные протоколы", содержащая вкладку "Модули". Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Транспортные протоколы" и идентична для всех модульных подсистем.
Каждый модуль подсистемы "Транспортные протоколы" предоставляет конфигурационную страницу с вкладкой "Модуль". Во вкладке "Модуль" содержится информация о модуле подсистемы "Транспортные протоколы" (Рис.4.1d), состав которой идентичен для всех модулей.
Подсистема является модульной и содержит иерархию объектов, изображённую на рисунке 1.3. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Сбор данных", содержащая вкладки: "Резервирование", "Библиотеки шаблонов" и "Модули".
Для получения доступа на модификацию объектов этой подсистемы необходимы права пользователя в группе "DAQ" или права привилегированного пользователя.
Объектом резервирования подсистемы "Сбор Данных" выступает объект контроллера в рамках которого резервирование данных выполняет функции:
Вкладка "Резервирование" (Рис.4.5a) доступна только если в резерве указана хотя-бы одна станция (Рис.4c) и содержит конфигурацию резервирования источников данных подсистемы "Сбор данных", в составе настроек:
Вкладка "Библиотеки шаблонов" (Рис.4.5b) содержит список библиотек шаблонов для параметров этой подсистемы. В контекстном меню списка библиотек шаблонов пользователю предоставляется возможность добавления, удаления и перехода к нужной библиотеке. Вкладка "Модули" (Рис.4.1c) содержит список модулей подсистемы "Транспорты" и идентична для всех модульных подсистем.
Каждая библиотека шаблонов подсистемы "Сбор данных" предоставляет конфигурационную страницу с вкладками "Библиотека" и "Шаблоны параметров". Вкладка "Библиотека" (Рис.4.5d) содержит основные настройки библиотеки в составе:
Вкладка "Шаблоны параметров" (Рис.4.5d) содержит список шаблонов в библиотеке. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному шаблону.
Каждый шаблон библиотеки шаблонов предоставляет конфигурационную страницу с вкладками "Шаблон" и "ВВ". Вкладка "Шаблон" (Рис.4.5e) содержит основные настройки шаблона в составе:
Вкладка "ВВ" (Рис.4.5f) содержит конфигурацию атрибутов (Вход-Выход) шаблонов и текст программы шаблона на языке пользовательского программирования OpenSCADA, например, "JavaLikeCalc.JavaScript". Признак "Переводить программу" указывает на сохранение и перевод текста программы для каждого языка (человеческого) отдельно, что усложняет поддержание алгоритма одинаковым для многоязычных конфигураций. Этот признак в целом внедрён для совместимости со старыми версиями OpenSCADA, не рекомендуется для установки и на данное время практикуется перевод конкретных текстовых сообщений в тексте программы, через функцию tr().
В таблице атрибутов шаблона пользователь может, посредством контекстного меню: добавить, вставить, удалить, передвинуть вверх или вниз запись атрибута, а также отредактировать поля атрибута:
С синтаксисом языка программы шаблона можно ознакомиться в документации модуля, предоставляющего интерпретатор выбранного языка. Например, типичным языком пользовательского программирования OpenSCADA является JavaLikeCalc.JavaScript.
Каждый модуль подсистемы "Сбор данных" предоставляет конфигурационную страницу с вкладками "Контроллеры" и "Модуль". Вкладка "Контроллеры" (Рис.4.5g) содержит список объектов контроллеров, зарегистрированных в модуле. В контекстном меню списка пользователю предоставляется возможность добавления, удаления и перехода к нужному объекту контроллера. Во вкладке "Модуль" содержится информация о модуле подсистемы "Сбор данных" (Рис.4.1d), состав которой идентичен для всех модулей.
Каждый объект контроллера содержит собственную страницу конфигурации с вкладками "Контроллер", "Параметры" и "Диагностика".
Вкладка "Контроллер" (Рис.4.5h) содержит основные настройки. Состав этих настроек может несколько отличаться от одного модуля этой подсистемы к другому, о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки объекта контроллера у модуля контроллера логического уровня DAQ.LogicLev:
Вкладка "Параметры" (Рис.4.5i) содержит список параметров в объекте контроллера, предоставляет выбор типа создаваемых по умолчанию параметров, а также информацию об общем количестве и количестве включенных параметров. В контекстном меню списка параметров пользователю предоставляется возможность добавления, удаления и перехода к нужному параметру.
Вкладка "Диагностика" (Рис.4.5j) содержит форму диагностических сообщений источника данных. Поскольку многие источники данных представляют собой внешние устройства с доступом к данным посредством сетевого обмена или системной шины то возможны различные нештатные ситуации при доступе к данным. Вывод всех их в поле "Статус" объекта контроллера невозможен поскольку он отображает только текущее состояние доступа к данным. С помощью диагностики можно проследить все нештатные ситуации в виде сообщений, сформированных данным объектом контроллера за указанный промежуток времени и с выбранным уровнем сообщения. Кроме непосредственно рабочей диагностической информации ряд модулей источников данных могут предоставлять здесь различные отладочные дампы обмена, на уровне сообщений "Отладка (0)".
Параметры объектов контроллеров подсистемы "Сбор данных" предоставляют конфигурационную страницу с вкладками "Параметр", "Атрибуты", "Архивация", "Включение" и "Конфигурация шаблона".
Вкладка "Параметр" (Рис.4.5k) содержит основные настройки в составе:
Вкладка "Атрибуты" (Рис.4.5l) содержит атрибуты параметра и их значения в соответствии с конфигурацией используемого шаблона и вычисления его программы.
Вкладка "Архивация" (Рис.4.5m) содержит таблицу с атрибутами параметра в строках и архиваторами в колонках. Пользователь имеет возможность установить архивацию нужного атрибута требуемым архиватором просто изменив ячейку на пересечении.
Вкладка "Включение" (Fig.4.5n) содержит перечень параметров иерархически включенных в другой параметр, предоставляет информацию об общем количестве и количестве включенных параметров. В контекстном меню пользователь может добавить, удалить и перейти к нужному параметру. Включение параметров поддерживается большинством источников данных и глубина включения обычно ограничена 10 уровнями!
Вкладка "Конфигурация шаблона" не является типовой, а присутствует только в параметрах модулей подсистемы "Сбор данных", которые реализуют механизмы работы по шаблону в контексте источника данных ими обслуживаемого для логического типа. В данный обзор эта вкладка включена для обеспечения логической завершённости обзора конфигурации шаблонов параметров подсистемы "Сбор данных" как финальный этап использования. Эта вкладка (Рис.4.5o) содержит конфигурационные поля в соответствии с шаблоном. В примере это групповая связь на внешний параметр. Эту связь можно установить просто указав путь к параметру, если флаг "Показать атрибуты" не установлен, или же установить адреса отдельных атрибутов, если флаг установлен. Знак "(+)" в конце адреса сигнализирует про успешное связывание и присутствии целевого объекта.
Подсистема является модульной и содержит иерархию объектов изображённую на рисунке 1.5. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Архивы-История", содержащая вкладки "Резервирование", "Сообщения", "Значения" и "Модули".
Для получения доступа на модификацию объектов этой подсистемы необходимы права пользователя в группе "Archive" или права привилегированного пользователя.
Объектом резервирования подсистемы "Архивы-История" выступает объект архиватора сообщений в рамках которого резервирование данных выполняет функции:
Резервирование архиваторов значений не предоставляется прямо ввиду осуществления этого процесса через источники данных и подсистему сбора данных.
Вкладка "Резервирование" (Рис.4.6a) доступна только если в резерве указана хотя-бы одна станция (Рис.4c) и содержит конфигурацию резервирования архиваторов сообщений подсистемы "Архивы-История", в составе настроек:
Вкладка "Сообщения" (Рис.4.6b) содержит конфигурацию архива сообщений и форму запроса сообщений из него.
Конфигурация архива сообщений представлена полями:
Форма запроса сообщений содержит конфигурационные поля запроса и таблицу результата. Конфигурационные поля запроса:
Таблица результата содержит строки сообщений с колонками:
Для сообщений о нарушениях, после таблицы появляется кнопка очистки этой таблицы активных нарушений, что полезно для сервисных функций. Таблица также дополняется командой "Удалить" для удаления отдельных нарушений.
Вкладка "Значения" (Рис.4.6c) содержит общую конфигурацию архивирования значений и список архивов значений. В контекстном меню списка значений пользователю предоставляется возможность добавления, удаления и перехода к нужному архиву. Общая конфигурация архивирования представлена полями:
Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Архивы-История" и идентична для всех модульных подсистем.
Архив значений подсистемы "Архивы-История" предоставляет конфигурационную страницу с вкладками "Архив", "Архиваторы" и "Значения".
Вкладка "Архив" (Рис.4.6d) содержит основные настройки архива в составе:
Вкладка "Архиваторы" (Рис.4.6e) содержит таблицу с конфигурацией процесса обработки данного архива доступными архиваторами. В строках расположены доступные архиваторы, а в колонках параметры:
Вкладка "Значения" (Рис.4.6f) содержит запрос значений в архиве и результат в виде таблицы значений или изображения тренда. Запрос значений содержит поля:
Каждый модуль подсистемы "Архивы-История" предоставляет конфигурационную страницу с вкладками "Архиваторы" и "Модуль". Вкладка "Архиваторы" (Рис.4.6g) содержит списки архиваторов сообщений и значений, зарегистрированных в модуле. В контекстном меню списков пользователю предоставляется возможность добавления, удаления и перехода к нужному архиватору. На вкладке "Модуль" содержится информация о модуле подсистемы "Архивы-История" (Рис.4.1d), состав которой идентичен для всех модулей.
Архиваторы сообщений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Сообщения".
Вкладка "Архиватор" (Рис.4.6h) содержит основные настройки. Состав этих настроек может несколько отличаться от модуля к модулю этой подсистемы о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки архиватора сообщений у модуля архивирования на файловую систему Arch.FSArch:
Вкладка "Сообщения" (Рис.4.6i) содержит форму запроса сообщений из архива данного архиватора:
Таблица результата содержит строки сообщений с колонками:
Архиваторы значений содержат собственную страницу конфигурации с вкладками "Архиватор" и "Архивы".
Вкладка "Архиватор" (Рис.4.6j) содержит основные настройки. Состав этих настроек может несколько отличаться от модуля к модулю этой подсистемы о чём можно узнать в собственной документации модулей. В качестве примера рассмотрим настройки архиватора значений у модуля архивирования на файловую систему Arch.FSArch:
Вкладка "Архивы" (Рис.4.6k) содержит таблицу с информацией об архивах, обрабатываемых архиватором. Таблица в строках содержит архивы, а в колонках информацию:
В случае с модулем Arch.FSArch в этой вкладке ещё содержится форма экспорта данных архиватора.
Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Пользовательские интерфейсы", содержащая вкладку "Модули". Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Специальные" и идентична для всех модульных подсистем.
Каждый модуль подсистемы "Пользовательские интерфейсы" предоставляет конфигурационную страницу с вкладками "Пользовательский интерфейс" и "Модуль". Вкладка "Пользовательский интерфейс" (Рис.4.7) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации, специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Пользовательские интерфейсы" (Рис.4.1d), состав которой идентичен для всех модулей.
В связи с тем, что большинство модулей этой подсистемы являются графическими интерфейсами то они сами могут предоставлять развитый интерфейс настройки, например, модуль UI.Vision, а информацию про специфику их конфигурации можно найти в собственной документации этих модулей.
Подсистема является модульной. Для конфигурации подсистемы предусмотрена корневая страница подсистемы "Специальные", содержащая вкладку "Модули". Вкладка "Модули" (Рис.4.1b) содержит список модулей подсистемы "Специальные" и идентична для всех модульных подсистем.
Каждый модуль подсистемы "Специальные" предоставляет конфигурационную страницу с вкладками "Специальный" и "Модуль". Вкладка "Специальный" (Рис.4.8) предоставляет параметр для контроля за состоянием "Выполняется" модуля, а также разделы конфигурации, специализированные для модулей этой подсистемы. Во вкладке "Модуль" содержится информация о модуле подсистемы "Специальные" (Рис.4.1d), состав которой идентичен для всех модулей.
Подсистема не является модульной. Для конфигурации подсистемы "Диспетчер модулей" предусмотрена страница подсистемы, содержащая вкладку "Подсистема". Вкладка "Подсистема" (Рис.4.9) содержит основные настройки подсистемы в составе:
Конфигурационный файл OpenSCADA предназначен для хранения основной конфигурации станции OpenSCADA. Только в конфигурационном файле и через параметры командной строки можно указать часть ключевых параметров станции, поэтому знакомство со структурой конфигурационного файла необходимо для специалистов, развёртывающих специфические решения на основе OpenSCADA.
Структурно конфигурационный файл организован на расширяемом языке разметки текста XML. Следовательно требуется жёсткое соблюдение правил синтаксиса XML. Показательный пример конфигурационного файла OpenSCADA с примерами конфигурации большинства компонентов OpenSCADA, приведен ниже:
<?xml version='1.0' encoding='UTF-8' ?>
<OpenSCADA>
<!--
This is the OpenSCADA configuration file.
-->
<station id="SimulatorStation">
<!--
Description of the internal parameters of the station.
The station is the OpenSCADA program.
-->
<prm id="StName">AGLKS</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_uk="Основна БД" NAME_ru="Основная БД" ADDR="St.db" CODEPAGE="UTF-8" />
</tbl>
</node>
<node id="sub_Security">
<tbl id="Security_user">
<fld NAME="roman" DESCR="Roman Savochenko" PASS="$1$roman$wleNCf/uyA84cGpBn5QuG." />
<fld NAME="root" DESCR="Administrator (superuser)!!!" DESCR_uk="Супер користувач" DESCR_ru="Супер пользователь" PASS="$1$root$lCn57dP9yzkCIAyrwJ24r1" />
<fld NAME="test" DESCR="Test user" PASS="$1$test$pi/xDtU5WFVRqYS6BMU8X/" />
<fld NAME="user" DESCR="Simple user" DESCR_uk="Звичайний користувач" DESCR_ru="Простой пользователь" PASS="$1$user$k8sntSoh7jhsc6lwspjsU." />
</tbl>
<tbl id="Security_grp">
<fld NAME="Archive" DESCR="Archives-History" DESCR_uk="Архіви-Історія" DESCR_ru="Архивы-История" />
<fld NAME="BD" DESCR="Databases" DESCR_uk="Бази даних" DESCR_ru="Базы данных" />
<fld NAME="DAQ" DESCR="Data acquisition" DESCR_uk="Збір даних" DESCR_ru="Сбор данных" />
<fld NAME="ModSched" DESCR="Modules scheduler" DESCR_uk="Диспетчер модулів" DESCR_ru="Диспетчер модулей" />
<fld NAME="Protocol" DESCR="Transport protocols" DESCR_uk="Транспортні протоколи" DESCR_ru="Транспортные протоколы" />
<fld NAME="Security" DESCR="Security" DESCR_uk="Безпека" DESCR_ru="Безопасность" />
<fld NAME="Special" DESCR="Specials" DESCR_uk="Спеціальні" DESCR_ru="Специальные" />
<fld NAME="Transport" DESCR="Transports" DESCR_uk="Транспорти" DESCR_ru="Транспорты" />
<fld NAME="UI" DESCR="User Interfaces" DESCR_uk="Інтерфейси користувача" DESCR_ru="Интерфейсы пользователя" />
<fld NAME="root" DESCR="Administartors group" DESCR_uk="Група адміністраторів" DESCR_ru="Группа администраторов" USERS="roman;" />
<fld NAME="users" DESCR="Users group" DESCR_uk="Група користувачів" DESCR_ru="Группа пользователей" USERS="test;user;" />
<fld NAME="ITW" DESCR="IT worker" DESCR_uk="Робітник IT" DESCR_ru="Работник IT"
LONGDESCR="Information Technology or service worker."
LONGDESCR_uk="Робітник Інформаційних Технологій та сервісу."
LONGDESCR_ru="Работник Информационных Технологий и сервиса." />
<fld NAME="op" DESCR="Operator" DESCR_uk="Оператор" DESCR_ru="Оператор" />
</tbl>
</node>
<node id="sub_ModSched">
<prm id="ModAllow">*</prm>
<prm id="ModDeny" />
<prm id="ChkPer">0</prm>
</node>
<node id="sub_Transport">
<tbl id="ExtTansp">
<fld OP_USER="roman" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
<fld OP_USER="*" ID="loop" NAME="Loop" NAME_uk="Петля" NAME_ru="Петля" TRANSP="Sockets" ADDR="TCP:localhost:10005" USER="roman" PASS="roman" />
<fld OP_USER="roman" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
<fld OP_USER="*" ID="loopSSL" NAME="Loop SSL" NAME_uk="Петля SSL" NAME_ru="Петля SSL" TRANSP="SSL" ADDR="localhost:10045" USER="roman" PASS="roman" />
</tbl>
<tbl id="Transport_in">
<fld ID="Self" MODULE="Sockets" NAME="Self system" DESCRIPT="Main transport of OpenSCADA self protocol."
DESCRIPT_uk="Основний транспорт власного протоколу OpenSCADA." DESCRIPT_ru="Основной транспорт собственного протокола OpenSCADA." ADDR="TCP::10005:1" PROT="SelfSystem" START="1">
<A_PRMS><prms MaxQueue="10" MaxClients="20" MaxClientsPerHost="5" BufLen="5" KeepAliveReqs="0" KeepAliveTm="60" /></A_PRMS>
</fld>
<fld ID="WEB_1" MODULE="Sockets" NAME="WEB 1" DESCRIPT="Main transport of the WEB interfaces."
DESCRIPT_uk="Основний транспорт WEB інтерфейсів." DESCRIPT_ru="Основной транспорт WEB интерфейсов." ADDR="TCP::10002:0" PROT="HTTP" START="1">
<A_PRMS><prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /></A_PRMS>
</fld>
<fld ID="WEB_2" MODULE="Sockets" NAME="WEB 2" DESCRIPT="Reserve transport of the WEB interfaces."
DESCRIPT_uk="Резервний транспорт WEB інтерфейсів." DESCRIPT_ru="Резервный транспорт WEB интерфейсов." ADDR="TCP::10004:0" PROT="HTTP" START="1">
<A_PRMS><prms MaxQueue="10" MaxClients="100" MaxClientsPerHost="25" BufLen="5" KeepAliveReqs="0" KeepAliveTm="5" /></A_PRMS>
</fld>
</tbl>
<!--
<tbl id="Transport_out">
<fld
ID="testModBus"
MODULE="Sockets"
NAME="Test ModBus"
NAME_uk="Тест ModBus"
NAME_ru="Тест ModBus"
DESCRIPT="ModBus protocol exchange test."
DESCRIPT_uk="Тест обміну за протоколом ModBus."
DESCRIPT_ru="Тест обмена по протоколу ModBus."
ADDR="TCP:localhost:10502"
START="1"/>
</tbl>-->
</node>
<node id="sub_DAQ">
<!--
<tbl id="tmplib">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" DB="tmplib_test2"/>
</tbl>
<tbl id="tmplib_test2">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
PROGRAM="JavaLikeCalc.JavaScript
cnt=5*i;"/>
</tbl>
<tbl id="tmplib_test2_io">
<fld TMPL_ID="test2" ID="i" NAME="I" NAME_uk="I" NAME_ru="I" TYPE="4" FLAGS="160" VALUE="" POS="0"/>
<fld TMPL_ID="test2" ID="cnt" NAME="Cnt" NAME_uk="Cnt" NAME_ru="Cnt" TYPE="4" FLAGS="32" VALUE="" POS="0"/>
</tbl>-->
<node id="mod_LogicLev">
<!--
<tbl id="DAQ">
<fld
ID="test2"
NAME="Test 2"
NAME_uk="Тест 2"
NAME_ru="Тест 2"
DESCR=""
ENABLE="1"
START="1"
PRM_BD="test2prm"
PERIOD="1000"
PRIOR="0"/>
</tbl>
<tbl id="test2prm">
<fld SHIFR="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
EN="1" MODE="2" PRM="test2.test2"/>
</tbl>-->
</node>
<node id="mod_System">
<!--
<tbl id="DAQ">
<fld
ID="dataOS"
NAME="OS data"
NAME_uk="Дані ОС"
NAME_ru="Даные ОС"
DESCR="Data of services and subsystems of OS."
DESCR_uk="Дані сервісів та підсистем ОС."
DESCR_ru="Данные сервисов и подсистем ОС."
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_uk="Навантаження CPU" NAME_ru="Нагрузка CPU" DESCR=""
EN="1" TYPE="CPU" SUBT="gen"/>
<fld SHIFR="MEM" NAME="Memory" NAME_uk="Пам'ять" NAME_ru="Память" DESCR="" EN="1" TYPE="MEM"/>
</tbl>
-->
</node>
<node id="mod_DiamondBoards">
<!--
<tbl id="DAQ">
<fld ID="Athena" NAME="Athena board" NAME_uk="Плата Athena" NAME_ru="Плата Athena" DESCR=""
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_uk="AI 0" NAME_ru="AI 0" DESCR="" EN="0" TYPE="0" CNL="0" GAIN="0"/>
</tbl>
<tbl id="AthenaDigPrm">
<fld SHIFR="di0" NAME="DI 0" NAME_uk="DI 0" NAME_ru="DI 0" DESCR="" EN="0" TYPE="0" PORT="0" CNL="0"/>
</tbl>
-->
</node>
<node id="mod_BlockCalc">
<!--
<tbl id="DAQ">
<fld ID="Model" NAME="Model" NAME_uk="Модель" NAME_ru="Модель" DESCR=""
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_uk="Клапан" NAME_ru="Клапан" DESCR=""
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 level" NAME_uk="Положення клапану" NAME_ru="Положение клапана" DESCR=""
EN="1" IO="Klap.l_kl1"/>
</tbl>
-->
</node>
<node id="mod_JavaLikeCalc">
<!--
<tbl id="DAQ">
<fld ID="CalcTest" NAME="Calculation test" NAME_uk="Тест обчислення" NAME_ru="Тест вычисления" DESCR=""
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_uk="Аварія" NAME_ru="Авария" DESCR="" EN="1" FLD="alrm"/>
</tbl>
<tbl id="lib">
<fld ID="TemplFunc" NAME="" DESCR="" DB="lib_TemplFunc"/>
</tbl>
<tbl id="lib_TemplFunc">
<fld ID="d_alarm" NAME="Digit alarm" NAME_uk="Аварія за дискретним" NAME_ru="Авария по дискретному" DESCR=""
FORMULA="alrm=(in==alrm_md)?"1:"+alrm_mess:"0";"/>
</tbl>
<tbl id="lib_TemplFunc_io">
<fld F_ID="d_alarm" ID="in" NAME="Input" NAME_uk="Вхід" NAME_ru="Вход" TYPE="3" MODE="0" DEF="" HIDE="0" POS="0"/>
<fld F_ID="d_alarm" ID="alrm" NAME="Alarm" NAME_uk="Аварія" NAME_ru="Авария" TYPE="0" MODE="1" DEF="" HIDE="0" POS="1"/>
<fld F_ID="d_alarm" ID="alrm_md" NAME="Alarm mode" NAME_uk="Режим аварії" NAME_ru="Режим аварии"
TYPE="3" MODE="0" DEF="" HIDE="0" POS="2"/>
<fld F_ID="d_alarm" ID="alrm_mess" NAME="Alarm message" NAME_uk="Повідомлення аварії" NAME_ru="Сообщение аварии"
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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" TMPL="S7.ai_man"/>
</tbl>-->
</node>
<node id="mod_SNMP">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" OID_LS="system"/>
</tbl>-->
</node>
<node id="mod_ModBus">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1"
ATTR_LS="321:0:tst:Test"/>
</tbl>-->
</node>
<node id="mod_DAQGate">
<!--
<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" EN="1" ND_LS=""/>
</tbl>-->
</node>
<node id="mod_SoundCard">
<!--<tbl id="DAQ">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_uk="Помилки"
NAME_ru="Ошибки"
DESCR="Archive of local errors"
DESCR_uk="Архів локальних помилок"
DESCR_ru="Архив локальных ощибок"
START="1"
CATEG="/DemoStation*"
LEVEL="4"
ADDR="ARCHIVES/MESS/stError/"/>
<fld
ID="NetRequsts"
MODUL="FSArch"
NAME="Network requests"
NAME_uk="Мережеві запити"
NAME_ru="Сетевые запросы"
DESCR="Requests to the server via Sockets transport."
DESCR_uk="Запити до сервера через транспорт Sockets."
DESCR_ru="Запросы к серверу через транспорт 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_uk="1година"
NAME_ru="1час"
DESCR="Averaging at hour"
DESCR_uk="Усереднення за годину"
DESCR_ru="Усреднение за час"
START="1"
ADDR="ARCHIVES/VAL/1h/"
V_PER="360"
A_PER="60"/>
</tbl>
<tbl id="Archive_val">
<fld
ID="test1"
NAME="Test 1"
NAME_uk="Тест 1"
NAME_ru="Тест 1"
DESCR="Test 1"
DESCR_uk="Тест 1"
DESCR_ru="Тест 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>
<prm id="CloseToTray">0</prm>
<prm id="Style"></prm>
<prm id="Palette"></prm>
<prm id="StyleSheets"></prm>
<tbl id="LookFeel">
<fld NAME="Typical TDE" STYLE="" STL_SHTS="">
<PALETTE>#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b
#808080, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #c7c7c7, #ffffff, #808080, #ffffff, #efefef, #000000, #567594, #ffffff, #0000ee, #52188b
#000000, #dddfe4, #ffffff, #ffffff, #555555, #c7c7c7, #000000, #ffffff, #000000, #ffffff, #efefef, #000000, #678db2, #ffffff, #0000ee, #52188b</PALETTE>
</fld>
<fld NAME="Blue Slate" STYLE="" STL_SHTS="">
<PALETTE>#000000, #9db9c8, #f6fcff, #c9dae3, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#808080, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #808080, #bfe2f4, #808080, #c3c3c3, #9db9c8, #000000, #558097, #808080, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000
#000000, #9db9c8, #f6fcff, #b5d5e6, #4e5c64, #697b85, #000000, #bfe2f4, #000000, #c3c3c3, #9db9c8, #000000, #558097, #ffffff, #0000ee, #52188b, #b4b4b4, #000000, #ffffdc, #000000</PALETTE>
</fld>
<fld NAME="Blue Darkness" STYLE="" STL_SHTS="">
<PALETTE>#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff
#555555, #426794, #5788c3, #4871a2, #162231, #37567b, #37567b, #5788c3, #555555, #002a4e, #426794, #000000, #4c95d4, #ffffff, #00ffff, #c0c0ff
#ffffff, #426794, #5788c3, #4871a2, #162231, #37567b, #dcdcdc, #5788c3, #ffffff, #002a4e, #426794, #000000, #5cb3ff, #000000, #00ffff, #c0c0ff</PALETTE>
</fld>
</tbl>
</node>
<node id="mod_QTCfg">
<prm id="StartUser">roman</prm>
</node>
<node id="mod_Vision">
<prm id="StartUser">roman</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_uk="Тест 2" NAME_ru="Тест 2" DESCR=""
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_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_uk="Тест 2" IO_VAL_ru="Тест 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
<fld IDW="test2" ID="dscr" IO_VAL="Test of the module 2" IO_VAL_uk="Тест модуля 2" IO_VAL_ru="Тест модуля 2" SELF_FLG="" CFG_TMPL="" CFG_VAL=""/>
</tbl>
<tbl id="PRJ">
<fld ID="test2" NAME="Test 2" NAME_uk="Тест 2" NAME_ru="Тест 2" DESCR="" 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_PER="-1" USER="root" GRP="UI" PERMIT="436" FLGS="1"/>
<fld OWNER="/test2/pg1" ID="pg2" ICO="" PARENT="/wlb_originals/wdg_Box" PROC="" 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" 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="SimulatorStation"/>. Атрибутом "id" указывается идентификатор станции — класс станции. Использование той или иной секции станции указывается параметром командной строки --station=SimulatorStation, при вызове. Секция станции непосредственно содержит параметры станции и секции подсистем. Параметры конфигурации секции записываются в виде <prm id="StName">AGLKS</prm>, где атрибутом "id" указывается идентификатор параметра, а в теле тега "prm" указывается значение параметра "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
***************************************************************************
********** OpenSCADA v0.9+r2535 (Linux-4.9.0-0.bpo.5-amd64). *********
***************************************************************************
===========================================================================
======================= Основные опции ====================================
===========================================================================
-h, --help Этот текст помощи по опциям командной строки и параметрам конфигурационного файла программы.
--projName=<имя> Имя проекта OpenSCADA для переключения.
Для такой операции также используется переменная окружение "OSCADA_ProjName" и имя бинарной программы "openscada_{ProjName}".
--projUserDir={дир.} Директория пользовательских проектов OpenSCADA (доступна для записи), по умолчанию "~/.openscada".
--projLock={per} Использовать блокирование проектов созданием файла "lock" в директории проекта и его обновление с периодом <per>,
по умолчанию включено и период обновления <per> составляет 60 секунд. Для отключения установить период обновления <per> в нуль.
--lang=<LANG> Язык станции, в виде "ru_RU.UTF-8".
--config=<файл> Конфигурационный файл станции.
--station=<ид> Идентификатор станции.
--statName=<имя> Имя станции.
--modDir=<path> Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
--messLev=<уров> Уровень обрабатываемых сообщений (0-7).
--log=<направл.> Направление сообщений в, по битовому полю:
0x1 - системный логер (syslogd);
0x2 - стандартный выход (stdout);
0x4 - стандартный выход ошибок (stderr);
0x8 - архив сообщений.
--consoleCharSet={CharSet} Принудительно установить кодовый набор символов консоли в <CharSet>, по умолчанию он системный.
--demon, --daemon Запуск в режиме демона.
--pidFile=<файл> файл для помещения ID процесса программы сюда.
--noCoreDump Предотвращать создание предсмертных дампов - не снимать это ограничение.
--permCrtFiles={права} Права создаваемых OpenSCADA файлов, по умолчанию это 0755 (RWXRW_RW_).
-------------- Параметры станции 'AGLKS(SimulatorStation)' в конфигурационном файле ------------
StName <имя> Имя станции.
WorkDB <Тип.Имя> Рабочая БД (тип и имя).
WorkDir <path> Рабочая директория.
ModDir <path> Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
IcoDir <path> Директория с иконками.
DocDir <path> Директория с документами.
MessLev <уровень> Уровень обрабатываемых сообщений (0-7).
SelDebCats <список> Список категорий отладки, разделены ';'.
LogTarget <направл.> Направление сообщений в, по битовому полю:
0x1 - системный логер (syslogd);
0x2 - стандартный выход (stdout);
0x4 - стандартный выход ошибок (stderr);
0x8 - архив сообщений.
Lang <язык> Язык станции, в виде "ru_RU.UTF-8".
Lang2CodeBase <язык> Базовый язык для перевода текстовых переменных, два символа.
MainCPUs <список> Основной перечень используемых процессоров, разделены ':'.
TaskInvPhs <n> Количество фаз вызова задач, 1 для отключения фазирования.
ClockRT <0|1> Установить использование источника часов в REALTIME (иначе MONOTONIC), несколько проблематичное при модификации системных часов.
SaveAtExit <0|1> Сохранять программу при выходе.
SavePeriod <секунд> Период сохранения программы, 0 для отключения.
ModifCalc <0|1> Устанавливать модификацию для вычислительных объектов.
RdStLevel <уров> Уровень резервирования текущей станции.
RdTaskPer <секунд> Период вызова задачи обслуживания резервирования.
RdRestConnTm <секунд> Время восстановления соединения с "мёртвой" резервной станцией.
RdStList <список> Список резервных станций, разделённых символом ';' (st1;st2).
RdPrimCmdTr <0|1> Включение транзита первичных команд на резервные станции.
Глобальные конфигурируемые лимиты:
limObjID_SZ [*20..50] Размер ИД объектов OpenSCADA.
ВНИМАНИЕ! Большой размер может вызвать ошибку размера ключа на БД похожих на MySQL!
Измените это только один раз перед использованием на БД с фиксированным типом "char({N})"!
limObjNm_SZ [*100...200] Размер НАЗВАНИЯ объектов OpenSCADA.
ВНИМАНИЕ! Измените это лишь один раз перед использованием на БД с фиксированным типом "char({N})"!
limArchID_SZ [*50...90] Размер ИД объектов архива значений.
ВНИМАНИЕ! Только увеличивайте его, иначе можете получить проблемы в Archive.FSArch!
Измените это лишь один раз перед использованием на БД с фиксированным типом "char({N})"!
limUserFile_SZ [1MB...*10MB...1000MB] Ограничение на размер файлов при загрузке и обработке в пространстве пользователя
и размер частей передачи больших файлов.
limUserIts_N [1000...*1000000...1000000000] Ограничение на количество создаваемых елементов пользователя, вроде елементов массивов.
limCacheIts_N [*100...100000] Ограничение на количество елементов в кеше.
Глобальные конфигурируемые параметры:
prmStrBuf_SZ [1000...*10000...1000000] Длина строковых буферов, не строковых классов.
prmWait_DL [0.001...*0.1...1] Время кванта циклов ожидания, секунд.
prmWait_TM [*5...10] Стандартный размер таймаута ожидания, секунд.
prmInterf_TM [*7...15] Время ожидания реакции интерфейса, секунд.
prmServTask_PER [1...*10...120] Период сервисной задачи, секунд.
========================= Опции подсистемы "БД" =========================
---------- Параметры секции '/sub_BD/' конфигурационного файла ----------
SYSStPref <0|1> Использовать идентификатор станции в общей таблице (SYS).
TblLifeTime <секунд> Время жизни открытых таблиц (по умолчанию 600 секунд).
==================== Опции подсистемы "Безопасности" ====================
====================== Опции подсистемы "Транспорты" ====================
========================== Опции модуля <Transport:Sockets> ==========================
------ Параметры модульной секции '/sub_Transport/mod_Sockets/' конфигурационного файла ------
OutLifeTime <секунд> Время жизни выходного транспорта (по умолчанию 0 секунд), 0 - для выключения функции.
========================== Опции модуля <Transport:Serial> ==========================
------ Параметры модульной секции '/sub_Transport/mod_Serial/' конфигурационного файла ------
OutLifeTime <секунд> Время жизни выходного транспорта (по умолчанию 0 секунд), 0 - для выключения функции.
========================== Опции модуля <Transport:SSL> ==========================
------ Параметры модульной секции '/sub_Transport/mod_SSL/' конфигурационного файла ------
OutLifeTime <секунд> Время жизни выходного транспорта (по умолчанию 0 секунд), 0 - для выключения функции.
============== Опции подсистемы "Транспортные Протоколы" ================
======================= Опции модуля <Protocol:HTTP> =============================
------ Параметры модульной секции '/sub_Protocol/mod_HTTP/' конфигурационного файла ------
AuthTime <мин> Время жизни сеанса аутентификации, минут (по умолчанию 10).
=================== Опции подсистемы "Сбор данных" ======================
---------- Параметры секции '/sub_DAQ/' конфигурационного файла ----------
RdRestDtTm <час> Глубина восстановления данных архива из резервной станции, при включении, в часах.
==================== Опции подсистемы "Архивы-История" ======================
---------- Параметры секции '/sub_Archive/' конфигурационного файла ----------
MessBufSize <ед.> Размер буфера сообщений.
MessPeriod <секунд> Период архивирования сообщений.
ValPeriod <мсекунд> Период активного архивирования значений.
ValPriority <уровень> Уровень приоритета задачи активного архивирования значений.
RdRestDtOverTm <дней> Глубина принудительной перезагрузки истории резерва при запуске, в днях.
======================= Опции модуля <Archive:FSArch> =============================
--noArchLimit Отключить лимит на количество файлов.
Используйте для режима просмотра архивов, не для работы.
===================== Опции подсистемы "Специальные" ====================
========================== Опции модуля <Special:SystemTests> ==========================
------ Параметры модульной секции '/sub_Special/mod_SystemTests/' конфигурационного файла ------
*** Общие опции всех тестов ***
id идентификатор теста;
on флаг включения теста;
per период повторения, секунд.
*** Опции тестов ***
1) Param Тест DAQ параметров. Вычитывает атрибуты и конфигурационные поля параметра.
1:name Адрес DAQ параметра
2) XML Тест разбора файла XML. Разбирает и отображает структуру указанного файла.
1:file XML файл
3) Mess Тест архива сообщений. Периодически вычитывает новые сообщения из архива, для указанного архиватора.
1:arhtor Архиватор
2:categ Шаблон категории сообщения
3:depth Глубина сообщения, секунд
4) SOAttach Тест подключения/отключения модулей.
1:name Путь к модулю
2:mode Режим (1-подключение;-1-отключение;0-изменение)
3:full Полное подключение(при старте)
5) Val Тест значений атрибута параметра.
Выполняет периодический опрос последнего значения указанного атрибута, а также опрос архива на указанную глубину.
1:name Путь к атрибуту параметра
2:arch_len Глубина получения архивных значений, секунд
3:arch_per Глубина получения архивных значений, микросекунды
6) DB Полный тест БД. Выполняет:
- создание/открытие БД;
- создание/открытие таблицы;
- создание множества записей (строк) предопределённой структуры;
- модификация множества записей;
- получение и проверка значений множества записей;
- модификация структуры записи и таблицы;
- удаление записей;
- закрытие/удаление таблицы;
- закрытие/удаление БД.
1:type Тип БД
2:addr Адрес БД
3:table Таблица БД
4:size Количество записей
7) TrOut Тест выходных и/или входных транспортов.
Выполняет тестирование выходного транспорта путём отправки запроса к указанному входному транспорту.
1:addr Адрес
2:type Модуль транспорта
3:req Текст запиту
8) SysContrLang Тест языка управления программой.
Производит запрос элементов языка посредством полного пути.
Полный путь к элементу языка имеет вид </Archive/%2fbd%2fm_per>.
Полный путь состоит из двух вложенных путей.
Первый </Archive/> это путь к узлу дерева контроля.
Второй </bd/m_per> это путь к конкретному элементу узла.
1:path Путь к элементу языка
9) ValBuf Тесты буфера значений.
Содержит 13 тестов всех аспектов буфера значений (подсистема "Архивы").
10) Archive Тесты размещения в архиве значений.
Содержит 7(8) тестов архиватора значений на проверку корректности функционирования последовательного механизма упаковки.
1:arch Архив значений
2:period Период значений, микросекунды
3:archtor Архиватор
11) Base64Code Тесты кодирования Mime Base64 алгоритмом.
============= Опции подсистемы "Пользовательские интерфейсы" ============
======================== Опции модуля <UI:Vision> ============================
------ Параметры модульной секции '/sub_UI/mod_Vision/' конфигурационного файла ------
StartUser <польз> Стартовый, беспарольный, пользователь.
UserPass <пароль> Пароль пользователя для нелокального запуска.
RunPrjs <список> Перечень запускаемых при старте проектов.
ExitLstRunPrjCls <0|1> Выход при закрытии последнего исполняющегося проекта (по умолчанию = 1).
CachePgLife <часы> Время жизни страниц в кеше (по умолчанию = 1).
CachePgSz <кол.> Максимальное количество страниц в кеше (по умолчанию 10).
CachePgLife <часы> Время жизни страниц в кеше.
VCAstation <id> Станция с движком СВУ ('.' - локальная).
RestoreTime <секунды> Время восстановления подключения.
======================== Опции модуля <UI:QTStarter> ============================
--QtInNotMainThread Запускать Qt в отдельном потоке от основного.
--showWin=<0,1,2> Режим отображения окон, начальный и от которого разрешён для изменения: 0-типовое окно, 1-максимизированое окно, 2-полный экран.
--simulRightMKeyTm=<tm> Время, в секундах, симуляции правой клавиши мыши и контекстного меню путём удержания правой клавиши в течении этого времени - более нуля.
------ Отладочные параметры Qt, командной строки --
--noX11 Предотвращать запуск Qt, в основном для чистой консоли.
--sync Переключение в синхронный режим X11 для отладки.
--widgetcount Печать отладочных сообщений при выходе, о количеcтве
виджетов оставшихся неудалёнными и максимальном их количестве.
------ Параметры Qt, командной строки -------------
--qws Делает данное приложение сервером с Qt для встраиваемого Linux.
--style=<имя> Установить GUI стиль в имя (windows, platinum, plastique, ...).
--stylesheet=<путь> Установить таблицу стилей из файла по пути.
--session=<имя> Восстановить из предыдущего сеанса с указанным именем.
--reverse Установить направление размещения в Qt::RightToLeft.
--graphicssystem=<имя> Установить механизм рендеринга для экранных виджетов и QPixmaps (raster, opengl).
--display=<имя> Установить X экран (типично в $DISPLAY).
--geometry=<геом> Установить клиентскую геометрию первого отображаемого окна.
------ Параметры модульной секции '/sub_UI/mod_QTStarter/' конфигурационного файла ------
StartMod <модули> Список запускаемых модулей, разделённых ';'.
CloseToTray <0|1> Закрывать все окна или запускать без Qt модулей в системный лоток.
Style <имя> GUI стиль Qt.
Font <шрифт> Общий шрифт Qt.
Palette <цвета> Двадцать цветов палитры разделённые символом ',' в трёх строках для активной, отключенной и неактивной групп.
StyleSheets <CSS> Правила таблиц каскадных стилей (CSS).
======================= Опции модуля <UI:QTCfg> =============================
------ Параметры модульной секции '/sub_UI/mod_QTCfg/' конфигурационного файла ------
StartPath <path> Путь первичной страницы конфигуратора.
StartUser <user> Стартовый пользователь, беспарольный.
======================== Опции модуля <UI:WebVision> ============================
------ Параметры модульной секции '/sub_UI/mod_WebVision/' конфигурационного файла ------
SessTimeLife <мин> Время жизни сеансов в минутах (по умолчанию 10).
SessLimit <кол.> Максимальное количество сеансов (по умолчанию 5).
CachePgLife <часы> Время жизни страниц в кеше (по умолчанию = 1).
CachePgSz <кол.> Максимальное количество страниц в кеше (по умолчанию 10).
PNGCompLev <уров.> Уровень сжатия [-1..9] создаваемых PNG-фафлов.
ImgResize <0|1> Изменение размера растровых изображений на стороне сервера.
=================== Опции подсистемы "Планировщик модулей" ====================
--ModPath=<путь> Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
---------- Параметры секции '/sub_ModSched/' конфигурационного файла ----------
ModPath <путь> Директории модулей, разделённые ';', и в конце могут содержать шаблон файлов.
Это синоним параметра уровня станции "ModDir".
ModAllow <список> Список разделяемых библиотек допустимых для автоматической загрузки, подключения и запуска (bd_DBF.so;daq_JavaLikeCalc.so).
Использовать значение '*' для разрешения всех модулей.
ModDeny <список> Список разделяемых библиотек запрещённых для автоматической загрузки, подключения и запуска (bd_DBF.so;daq_JavaLikeCalc.so).
ChkPer <секунд> Период поиска новых разделяемых библиотек (модулей), 0 для отключения.
OpenSCADA изначально является программой, которая может быть запущена из консоли или терминала, набрав openscada. В такой способ программа запустится с сообщениями её действий в эту консоль и блокированием консоли на ожидании действий пользователя, что является типовым режимом запуска в консоль-терминал и может использоваться для оперативной отладки и контроля результата действий и ошибок. Кроме типового режима предусмотрено также ещё два режима, которые определяются передачей параметров в команду запуска:
OpenSCADA является модульной и имеет модули локальных графических интерфейсов, а следовательно может запускаться в графическом интерфейсе, что производится одновременно при типовом запуске из консоли, при наличии доступного X-сервера. Для запуска исключительно в, и с графического интерфейса команда типового запуска может, и используется: в конфигурации иконок-ярлыков, запуска программ (также автоматического) из окружения графической среды — рабочего стола (DE). Сам модуль запуска локального графического окружения может предусматривать несколько режимов, про что можно узнать из документации на этот модуль, которым сейчас является UI.QTStarter и который предусматривает режимы:
Простой запуск является малополезным, неудобным и предусматривает использование и работу только с одной конфигурацией, это — конфигурационный файл {sysconfdir}/oscada.xml, как первичное хранилище конфигурации. Для предоставления возможности выбора конфигурации при запуске программы предусмотрен параметр командной строки --config и изменение рабочей папки программы перед запуском или параметром "WorkDir" этого конфигурационного файла, что может быть использовано и исключительно использовалось OpenSCADA до версии 0.9, через создание отдельного сценария командной строки (Shell) для отдельной конфигурации. В версии OpenSCADA 0.9 добавлено понятие "Проекта OpenSCADA", которое сначала реализовывалось отдельным сценарием командной строки openscada_start, а затем было интегрировано в ядро OpenSCADA и модуль запуска локального графического интерфейса.
В OpenSCADA 0.9 бала определена, внедрена и окончательно сформирована суть проекта OpenSCADA, как отдельное место (папка) с конфигурацией и всеми данными отдельного проекта-решения SCADA-системы — объект технологического процесса, ПЛК, сервер визуализации, сервер Web и другое.
Данные отдельного проекта-папки обычно предусматривают:
Название папки проекта равно названию проекта и размещается в рабочей папке OpenSCADA. Рабочая папка OpenSCADA делится на системную ("{datadir}/openscada", где "datadir" обычно — "/usr/share"), которая обычному-непривилегированному пользователю доступна только для чтения, и пользовательская ("{HOME}/.openscada"), которая, при необходимости, создаётся в домашней папке пользователя. В системную рабочую папку обычно помещаются предварительно-установленные проекты и библиотеки OpenSCADA, которые устанавливаются соответствующими пакетами дистрибутива Linux. Соответственно, для обеспечения полноценной работы, проекты и библиотеки из системной рабочей папки копируются в пользовательскую, что менеджер проектов осуществляет автоматически.
Первым механизмом реализации сущности проекта стал сценарий командной строки openscada_start, который всё ещё предоставляется для совместимости, предусматривает и определяет следующие функции и требования:
С целью унификации и расширения функциональности, и по опыту эксплуатации openscada_start, сущность проекта позже была интегрирована в ядро OpenSCADA и модуль запуска локального графического интерфейса UI.QTStarter. Соответственно, ядро OpenSCADA, а именно первичный бинарный файл openscada, предусматривает определение конфигурационного файла, папки с данными и имя по указанному названию проекта и переключение на эту конфигурацию согласно пунктам 1, 2 и 4, выше-перечисленных функций менеджера проекта. Формирование элементов интерфейса для выбора и создания новых проектов, пункт 5, осуществляет модуль запуска локального графического интерфейса UI.QTStarter (Рис.5a,5c). Пункты 3 и 6 вынесены в отдельный сценарий командной строки openscada-proj из-за специфичности этих операций к программной платформе, а соответственно и необходимость в простой адаптации к этой специфики.
Соответственно, сейчас OpenSCADA можно запустить как в режиме демона-сервиса, так и графического интерфейса просто указав имя присутствующего проекта четырьмя способами:
Создать новый проект можно из локального графического интерфейса UI.QTStarter (Рис.5c) и через сценарий командной строки менеджера проектов openscada-proj, который собственно и вызывается из локального графического интерфейса.
Результат исполнения команды $ openscada-proj --help:
Projects management script of OpenSCADA mostly designed to call from OpenSCADA but also can be used independently.
The script is mostly software platform specific and relates now for Linux.
openscada-proj list
openscada-proj proc|create|remove|update {ProjName}
Commands:
list - allowed projects list;
proc - proceed for copy RO projects to WR, create desktop links, process core dumps;
create - create new projects or copy RO projects to WR, create desktop links;
remove - remove project;
update - update from 0.8.0 LTS;
Arguments:
ProjName - project name;
Environments:
dPrj - directory of projects OpenSCADA, can be RO;
dPrjUser - directory of projects OpenSCADA of the user, WR;
dSysCfg - directory of system configuration;
dData - directory of system data;
openscada-proj backup|backupRestore {ProjName} [{BackupName}]
openscada-proj backupList {ProjName}
Commands:
backup - backup the selected project <ProjName> to the name <BackupName>, or to the current date at missing;
backupRestore - restore the selected project <ProjName> from the pointed backup name <BackupName>, or from the last one at missing;
backupList - list the project <ProjName> backups.
Arguments:
ProjName - project name;
BackupName - the backup archive name.
Environments:
OSCADA_TAR_ComprPrg - TAR compression program, at missing there used gzip.
OSCADA_BackLim - Backups limit, 10 by default
В целом, сценарий командной строки менеджера проектов openscada-proj предусматривает функции и команды над проектами:
Дополнительно, сценарий командной строки содержит команды менеджера резервного копирования проектов:
Резервное копирование в целом осуществляется в рабочем каталоге OpenSCADA, рядом с каталогами самих проектов, для которых создаются файлы запакованных каталогов с названием {ProjName}_{BackupName}.backup, например — "Boiler_2020-06-24_20.09.backup". По умолчанию каталоги проектов сжимаются программой "gzip", которую можно заменить установкой переменной окружения "OSCADA_TAR_ComprPrg". Соответственно, резервирование можно осуществлять из вне, например, по указанному расписанию из CRON, кроме того, что осуществлять это вручную из графического интерфейса менеджера проектов (Рис.5a).
| Documents/Program_manual/ru - GFDL | July 2021 | OpenSCADA 0.9.4 |