ValueArchive (+ RAIMA) и RDB-архивирование используются для хранения событий по тегам («изменения значений») и аварийных сигналов (экземпляров аварийных сигналов) на основе временных меток с целью их извлечения/запроса. Если ValueArchive предназначен для небольших автономных инсталляций, то RDB Manager ориентирован на более крупные сетевые системы.
NextGenArchive (NGA) для КАСКАД — это современное решение для архивирования, которое расширяет гибкость, сохраняя при этом возможности и достоинства существующих методов.
Главными особенностями нового архивного решения выступают:
Архивирование событий (изменений значений) и аварийных сигналов с использованием концепций конфигурации, аналогичных уже существующим решениям архивирования «КАСКАД Цифра»
Совместимый интерфейс чтения статистических данных (dpGetPeriod, dpGetAsynch, dpQuery with TIMERANGE, alert-GetPeriod)
Возможность прямого чтения для доступа к базовой БД непосредственно из кода CTRL (пользовательский интерфейс, CTRL Manager) без использования обмена сообщениями КАСКАД
Модульная концепция бэкенда БД с возможностью создания пользовательских интерфейсов бэкенда БД
Возможно хранение значений и оповещений*) в нескольких БД/бэкендах. См. разделы Конфигурация — Бэкенд и Конфигурация — Профиль бэкенда
Современная база данных временных рядов InfluxDB® в качестве бэкенда по умолчанию включена в «КАСКАД Цифра»
Снижение требований к хранению данных. Согласно нашим измерениям на примере одного из проектов, сокращение объема хранилища в InfluxDB® составляет от 60% до 80% по сравнению с потреблением хранилища HDB (и даже больше по сравнению с потреблением хранилища RDB / Oracle).
Использование одной БД для нескольких систем «КАСКАД Цифра»
Обслуживание БД (резервное копирование, восстановление и т.д.), управляемое с помощью панелей и скриптов «КАСКАД Цифра»
Работа с резервированием для баз данных с*) (например, PostgreSQL®) и без (например, InfluxDB®) встроенных функций резервирования
ПРИМЕЧАНИЕ
Работа с резервированием для баз данных с*) (например, PostgreSQL®) и без (например, InfluxDB®) встроенных функций резервирования
Поддерживаемые базы данных
В настоящее время в качестве бэкендов NGA поддерживаются следующие базы данных:
В случае баз данных, не поддерживающих резервирование, NextGen Archiver должен позаботиться об основных случаях использования резервирования:
Поддерживание пассивной БД в синхронизации с активной
Переключение между резервными партнерами
Синхронизация БД после перезапуска пассивной системы
Включение состояния базы данных в общее «состояние системы»
Основная идея заключается в использовании двух идентичных бэкендов на каждом резервном узле, один из которых подключен к локальной базе данных, а другой — к базе данных резервного партнера. Активный сервер осуществляет запись в оба бэкенда, а пассивный сервер просто буферизирует блоки данных до тех пор, пока они не будут успешно записаны в базы данных активным бэкендом, после чего эти данные отбрасываются.
В случае резервированной системы фронтенд NGA дополнительно отправляет все данные на бэкенд, пишущий на другой сервер. После переключения ранее пассивный сервер начинает записывать имеющиеся буферы (которые еще не были зафиксированы ранее активным сервером) в базы данных (локальную и удаленную).
Если другой сервер (или база данных) не работает или недоступен, то бэкэнд, пишущий на этот хост, будет буферизировать данные. Для покрытия большего временного диапазона в среде с резервированием необходимо соответствующим образом настроить метод буферизации (буферизация на диск)
После перезапуска пассивного сервера/базы данных бэкэнд активного сервера, осуществляющий запись в пассивную базу данных, автоматически обнаружит доступность базы данных и начнет запись буферизованных данных (восстановление). Пассивная система автоматически удалит все локально хранящиеся буферы, если данные были записаны активным сервером.
Все запросы на чтение исторических значений / оповещений (dpGetPeriod, dpGetAsynch, alertGetPeriod, dpQuery) из пользовательских интерфейсов будут автоматически перенаправлены Event Manager’ом на активную систему. Для автоматической маршрутизации на активный хост менеджеры управления должны быть запущены с помощью параметра командной строки «-connectToRedundantHosts». Это стандартное поведение резервирования «КАСКАД Цифра».
Обзорная панель системы «КАСКАД Цифра» для резервного проекта NGA
Архиватор NextGen Archiver также отображается на панели «Обзор системы» «КАСКАД Цифра». При генерации проекта, использующего NGA, для обоих резервных узлов отображается стандартный бэкенд («InfluxDB®»), а в расчет состояния ошибки включается менеджер NGA (вместо менеджера Value Archive или RDB), Вес рассчитывается в зависимости от соединения бэкенда с базой данных (плохой = нет соединения с базой данных).
ВНИМАНИЕ!
Разделенный режим не доступен для резервных проектов NGA! Разделенный режим не отключается в панели. Поэтому не используйте его в дублированном проекте.
«КАСКАД Цифра» может работать в режиме резервирования, когда используются два сервера «КАСКАД Цифра» («левый» и «правый» в дальнейшем контексте), отказ одного из которых компенсируется другим. Один из серверов всегда является «активным», посылая данные на периферийные устройства и обслуживая пользовательские интерфейсы, другой — «пассивным», сохраняя копию состояния активного сервера.
В этой главе описывается резервирование в среде NGA. Подробнее об общем резервировании см. в главе «Резервирование, основы».
Основным аспектом резервирования NGA является предотвращение потери исторических данных в результате единичных аппаратных или программных сбоев. Предполагается, что данная реализация способна справиться с единичными сбоями, а не с несколькими параллельными (например, сбой жесткого диска на обоих серверах). Другим аспектом резервирования NGA является обеспечение доступа к историческим данным для удаленных пользовательских интерфейсов даже в случае выхода из строя одного резервного узла «КАСКАД Цифра» или одного узла базы данных (если база данных резервируется и располагается на отдельном сервере).
Существует также специальная опция «split mode» для резервирования. Эта выполненная опция переводит оба сервера в активное состояние до тех пор, пока режим не будет отключен — после чего один из серверов остается активным, а другой перезапускается, включая восстановление (стандартная функция резервирования «КАСКАД Цифра» при перезапуске серверного проекта). В настоящее время эта опция не поддерживается NGA.
Каждый резервный сервер имеет «состояние ошибки» (так называемое «состояние здоровья»), которое обычно должно быть одинаковым на обоих серверах. Если это не так, то активным становится сервер с лучшим «состоянием здоровья», что может привести к «переключению» между активным и пассивным сервером. Если сервер остановился, то при следующем перезапуске он должен быть синхронизирован, чтобы иметь такое же «состояние здоровья» (значения точек данных, состояния оповещения и т.д.), как и работающий в данный момент сервер. Это называется восстановлением.
Для преобразования существующего проекта на базе NGA в резервный помимо действий, не связанных с NGA (см. раздел «Резервирование, основы«), необходимо также перевести фронтенд и бэкенд NGA на резервирование. Для этого необходимо нажать кнопку «Создать резервные данные NGA» (вкладка «Общие» панели конфигурации NGA
Для использования NextGen Archiver в системе с резервированием возможны две различные схемы — в зависимости от поддержки резервирования используемой базы данных (баз данных):
Если база данных не способна самостоятельно осуществлять резервирование (например, версия InfluxDB® с открытым исходным кодом), то база данных должна быть запущена на обоих узлах, которые являются независимыми друг от друга (в том, что касается базы данных)
Если база данных поддерживает резервирование (например, PostgreSQL®), то оба резервируемых экземпляра NGA могут взаимодействовать с общим экземпляром базы данных, который будет самостоятельно выполнять резервные операции (переключение, восстановление).
В списке слева отображаются все существующие архивные группы. При щелчке по архивной группе в правой части панели отображаются все известные на данный момент сегменты с указанием времени начала и окончания, а также статуса. Цветной индикатор состояния (красный / зеленый) показывает доступность архивной группы (зеленый = подключен к бэкенду, подключен к БД и группа установлена в активное состояние).
Далее описаны следующие состояния
Текущий: сегмент существует и в данный момент используется для хранения данных. Всегда существует ровно один сегмент с состоянием Current. В некоторых особых случаях это правило не должно применяться — см. примечание в конце списка.
Онлайн: Сегмент присутствует локально и доступен для операций чтения и записи данных, относящихся к этому временному диапазону в прошлом.
Резервная копирования: Сегмент присутствует локально и доступен для операций чтения. Запись в сегмент, находящийся в резервной копии, аннулирует резервную копию, делая сегмент снова доступным для чтения.
Онлайн и в резервной копии: Сегмент присутствует локально и доступен для операций чтения. Он будет автоматически удален при наступлении параметров удаления («возраст»).
Оффлайн и в резервной копии: Сегмент доступен в месте резервного копирования, но не может быть прочитан или записан. Доступен для восстановления.
Восстановлен: Сегмент присутствует и доступен для операций чтения, но не будет удален автоматически.
Удалён: Сегмент не существует (ни локально, ни на резервном хранилище) и не может быть восстановлен, записан или прочитан из него.
ПРИМЕЧАНИЕ
Для баз данных InfluxDB® следует обратить внимание на следующее: Если сегменты находятся в состоянии Онлайн и в состоянии Резервных копий и в них записываются значения или алерты, то эти сегменты автоматически переводятся в состояние Онлайн. Если значения или предупреждения записываются в сегменты, которые находятся в состоянии «Оффлайн и в резервной копии«, «Удален» или «Восстановлен«, то эти значения будут отброшены, а в файл журнала будет записано предупреждение.
ПРИМЕЧАНИЕ
InfluxDB® открывает один файл для каждого сегмента.
Поэтому количество разрешенных файловых дескрипторов для одного процесса должно быть не меньше максимально возможного количества сегментов в соответствии с конфигурацией архивной группы.
Если доступных обработчиков файлов недостаточно, то в файл журнала записывается сообщение об ошибке, подобное следующему:
2023.01.23 11:24:04.716, IMPL, SEVERE,69, Database error, Error while writing values, database response: [shard <shard number>] open <influx database path>/<archive group>/<shard number>/index/2/MANIFEST: too many open files (from <backend data point name>)
Если данные не записываются в течение длительного времени, InfluxDB® не создает новых сегментов. Если необходимо создать резервную копию, то самый новый из существующих сегментов будет изменен с » Текущий» на «Онлайн«. В противном случае резервное копирование не будет работать
Переход между различными состояниями может осуществляться вручную и/или автоматически. Обратите внимание, что восстановление всегда должно выполняться вручную, а переключение не может быть выполнено вручную с определенными базами данных / бэкендами (например, с InfluxDB®).
Каждый сегмент также имеет уникальный идентификатор, который используется для обращения к конкретному сегменту.
В зависимости от того, какие сегменты были выбраны в списке сегментов, некоторые операции могут быть недоступны (кнопка выделена серым цветом).
Для выбора одного сегмента используйте один щелчок мыши,
С помощью комбинации клавиш «Shift + щелчок» можно выделить все сегменты между предыдущим и текущим сегментами,
С помощью «Ctrl + щелчок» можно самостоятельно выделить этот сегмент в дополнение к уже выделенным ранее. Это означает, что, например, восстановить можно только сегменты со статусом «Оффлайн и в резервной копии» или что нельзя удалить «Текущий» сегмент.
При резервном копировании сегментов следует обратить внимание на следующее:
ПРИМЕР Для параметра «Резервная копия сегментов старше» установлено значение 3. При резервном копировании сегментов сегмент «Текущий» и два самых молодых сегмента «Онлайн» не резервируются. Более старые «Онлайн» сегменты резервируются
При архивировании данных с помощью NGA база данных, лежащая в основе архива, будет использовать дисковое пространство для хранения данных, метаинформации, индексов и т.д. Чтобы сохранить эту кучу данных управляемой, NGA структурирует данные каждой архивной группы на сегменты.
Сегмент — это блок данных, ограниченный по времени и содержащий всю информацию об изменении значений или оповещениях элементов архивных точек данных, отнесенных к определенной архивной группе, за определенный интервал времени (т.е. между временем начала и временем окончания сегмента). Сегменты не пересекаются во времени и содержат всю информацию, характерную для данного временного периода (т.е. исходные данные, индексы, …)
«Сегмент» — это искусственный термин, используемый NGA и реализуемый по-разному, в зависимости от базы данных. В InfluxDB® сегменты реализуются в виде так называемых «шардов», в Oracle они называются «табличные пространства». Общим признаком для всех сегментов является возможность легко создать новый сегмент, удалить его из базы данных, скопировать или снова интегрировать уже удаленный (но сохраненный в резервной копии) сегмент.
Некоторые из этих операций выполняются NGA автоматически в зависимости от настроек. К ним относятся переключение между сегментами, резервное копирование и удаление. Некоторые из этих операций могут быть выполнены оператором вручную. Восстановление всегда должно выполняться вручную.
Сертификат — это структура данных с цифровой подписью, описывающая возможности клиента или сервера. Как клиент, так и сервер «КАСКАД Цифра» поставляются с сертификатами по умолчанию, которые могут быть изменены. Сертификаты по умолчанию являются самоподписанными. Вы должны заменить стандартные сертификатами своими собственными.
Для использования сертификата, отличного от стандартного, необходимо задать его через запись serverCertificate в разделе [opcuasrv]. Сертификат для UA-клиента может быть задан через поле Client Certificate
Работа с сертификатами OPC UA позволяет
Определить, какие сертификаты принимаются на сервере или для клиента.
Создать новый сертификат клиента/сервера.
Откройте окно управление сертификатами, нажав на кнопку OPC UA Certificate на вкладке Driver в управлении системой.
Для корректной работы просмотра информации о сертификатах,а также для создания новых, команде openssl должен быть присвоен соответствующий путь (системная переменная окружения PATH).
Работа с сертификатами, специфичными для OPC UA
Сертификаты OPC UA требуют наличия в сертификате поля SubjectAlternativeName для URI приложения и имени хоста или IP-адреса. Для обеспечения безопасности связи сервер OPC UA проверяет, совпадает ли URI приложения клиента с URI приложения в сертификате клиента. URI приложения клиента может быть сконфигурирован с помощью поля конфигурации UA-клиента «Uri приложения».
С другой стороны, в случае защищенной связи клиент проверяет соответствие имени хоста или IP-адреса сервера UA в URL-адресе сервера имени DNS сервера или IP-адресу в серверном сертификате. Эта проверка выполняется только в том случае, если URL-адрес сервера содержит имя хоста или IP-адрес, отличный от «localhost». Проверка может быть отключена в поле конфигурации UA-клиента «checkCertificateHost».
При использовании сертификата по умолчанию для сервера имя хоста не может быть верным. В этом случае проверка со стороны клиента должна быть отключена.
Обработка сертификатов
На сервере можно решить, принимать или не принимать сертификат клиента. Для клиента можно решить, принимать ли сертификат сервера. Для выбора между настройками клиента и сервера можно использовать окно Сертификаты OPC UA.
С технической точки зрения сертификат, который должен быть принят, перемещается из каталога «rejected» в каталог «certs».
Их можно найти в каталоге установки «КАСКАД Цифра» в разделе \data\opcua\client\PKI\CA\ в соответствующих директориях.
Рисунок: Вкладка «Обработка сертификатов»
В списке слева отображаются все сертификаты, которые не принимаются. Их можно найти в каталоге «rejected«.
В списке справа отображаются все сертификаты, которые принимаются. Их можно найти в каталоге «certs«.
Для перемещения сертификатов из одного списка (или каталога) в другой выберите конкретный сертификат и используйте кнопки
(принять сертификат)
и
(отклонить сертификат) для его перемещения.
При перемещении сертификата из списка «Принят» в список «Не принят» клиент отключается от сервера сразу, если соединение уже активно. После повторного соединения клиент отключится от сервера.
Если сертификат выбран из одного из двух списков, то в нижней части панели отображаются сведения о сертификате («Детали сертификата«).
Клиент и сервер проверяют сертификаты своих партнеров и хранят их в отдельном «отвергнутом» каталоге, если они неизвестны. Например, если клиент не знает сервер, то он хранит файл сертификата в каталоге client/PKI/CA/rejected.
Как и для клиента, так и для сервера расположение каталога сертификатов может быть изменено с помощью элемента конфигурации certificateStore.
И клиент, и сервер должны иметь права на запись в каталог «rejected». Для приема сертификатов пользовательский интерфейс должен иметь дополнительное право записи в каталог «certs».
В рамках сервисов SecureChannel обмен сертификатами будет происходить и при установке параметра безопасности в значение None. Это означает, что обмен сертификатами происходит всегда, даже если пользователь работает без настроек безопасности.
Однако проверка сертификатов не производится. Эта процедура выполняется автоматически коммуникационным стеком или SDK.
Создание сертификата клиента/сервера
Панель «КАСКАД Цифра» для работы с сертификатами обеспечивает создание самоподписанных сертификатов клиента/сервера. Таким образом, доступ к серверу могут получить только выбранные клиенты.
Если сертификаты создаются центром сертификации (CA — Certificate Authority), как правило, IT-администратором, то они должны иметь заданные расширения/форматы файлов в соответствии со спецификацией OPC UA.
Рисунок Вкладка для создания клиентского сертификата
Обратите внимание, что:
Все поля ввода должны быть заполнены.
Имя сертификата должно быть введено без расширения файла.
Имя сертификата не должно содержать пробелов и/или специальных символов (/ \ ; ? < > * | : » ‘).
Для создания нажмите кнопку «Создать сертификат«. Сертификат сохраняется в каталоге data\opcua\client\PKI\CA\certs и, таким образом, принимается автоматически.
Для удаления сертификата его необходимо удалить вручную из соответствующего каталога.
Перед созданием сертификатов необходимо переключиться на нужный каталог. По умолчанию при открытии панели выбирается каталог клиента.
Некоторые специальные символы могут некорректно отображаться на панели сертификатов.
Имя файла
Имя файла сертификата. Имя должно быть введено без указания расширения файла.
Срок действия
Дата окончания срока действия сертификата в днях.
Код страны
Двухбуквенный код страны, например, RU для России.
Область, город, организация, отдел
Конкретная информация о местонахождении, компании и т.д.
Название
Имя приложения, например, КАСКАД Цифра.
URI приложения
Единый идентификатор ресурса приложения. В случае сертификата сервера необходим следующий формат:
urn:<имя DNS сервера>:KASKAD:<имя проекта КАСКАД Цифра>:<номер сервераOPC UA>
DNS-имя сервера должно совпадать с указанным в поле DNS Name. Для имени проекта «КАСКАД Цифра должен быть определен проект, в котором работает сервер OPC UA. Номер сервера OPC UA равен номеру менеджера сервера OPC UA.
Имя DNS
Имя хоста. Можно ввести несколько имен хостов, разделенных пробелами.
IP-адрес
Можно ввести несколько IP-адресов, разделенных пробелами.
Управление и форматы
Для UA-сервера и клиента необходим каталог для сертификатов. Каталоги для сервера и клиента могут быть определены с помощью элемента конфигурации certificateStore. Структура каталогов задана, как описано ниже.
По умолчанию UA-сервер ищет свой каталог сертификатов PKI в каталоге /data/opcua/server, клиент — в каталоге /data/opcua/client. Если соответствующего каталога не существует, то просматриваются потенциальные подпроекты и каталог установки.
В версии 3.15 P008 при создании нового проекта каталоги сертификатов клиента и сервера автоматически копируются из инсталляционного каталога в соответствующий проект. Это означает, что созданные сертификаты или отклоненные сертификаты от партнеров по обмену данными по умолчанию хранятся в каталоге проекта.
Сервер
В этом разделе описывается структура и содержание каталогов сертификатов.
Рисунок Структура файлов на сервере OPC UA
В следующей таблице описано назначение конкретных справочников:
ПРИМЕЧАНИЕ Закрытый ключ сертификата клиента или сервера OPC UA не должен иметь пароля. В противном случае UA-сервер или клиент будет работать некорректно. Кроме того, файл закрытого ключа, расположенный в каталоге «private«, должен иметь тот же пароль, что и соответствующий файл сертификата с расширением .pem.
Каталог
Описание
certs
Здесь хранятся сертификаты сервера UA и сертификаты доверенных клиентов или центров сертификации (CA). Эти файлы с расширением .der представляют собой сертификаты X.509, содержащие открытый ключ.
clr
Здесь хранятся списки отзыва сертификатов CA. Пример: Должны приниматься все сертификаты CA xyz, кроме сертификатов из этого каталога.
private
Здесь хранятся файлы с расширением .pem. Эти файлы представляют собой сертификаты X.509, содержащие открытый ключ, и должны быть доступны только авторизованным пользователям на файловом уровне (соответствующие права доступа задаются ИТ-администратором).
rejected
Здесь хранятся все отклоненные сертификаты партнеров по общению. Скопировав эти сертификаты в каталог certs на файловом уровне, их можно применить к списку доверенных сертификатов. Эти файлы должны быть доступны только авторизованным пользователям.
В указанных каталогах хранятся сертификаты сервера КАСКАД Цифра (каталог certs), доверенных клиентов (certs) и отвергнутых клиентов (rejected).
Клиент
Смысл и содержание каталогов аналогичны серверу.
В следующих каталогах хранятся сертификаты клиента КАСКАД Цифра (certs), доверенных серверов (certs) или отвергнутых серверов (rejected).
Использование сертификатов из центра сертификации
Клиент и сервер «КАСКАД Цифра» могут также использовать сертификаты, подписанные центром сертификации, т.е. никаких самоподписанных сертификатов. При использовании таких сертификатов необходимо учитывать несколько аспектов, поскольку OPC UA требует наличия некоторых специфических полей, которые также проверяются. При неудачной проверке безопасная связь невозможна.
Подробное описание содержания и обработки сертификатов приведено в главе 6.2 части 6 (Mappings) спецификации OPC UA. В главе 6.1 части 4 (Services) спецификации описаны проверки сертификатов, выполняемые на стороне клиента и сервера.
Причин неудачного установления защищенной связи может быть несколько:
Сертификат не находится в списке доверенных. В этом случае перенесите его в соответствующий список, если доверяете источнику.
Не удается выполнить проверку имени хоста сертификата на стороне клиента. В этом случае имя хоста или IP-адрес в URL сервера не совпадает с DNS-именем или IP в сертификате сервера. Необходимо либо исправить сертификат сервера, либо пропустить проверку на стороне клиента с помощью элемента checkCertificateHost.
Не удается выполнить проверку URI приложения на стороне сервера. В этом случае URI приложения в сертификате клиента не совпадает с URI приложения, используемого клиентом. URI приложения клиента может быть настроен с помощью записи applicationUri.
Файл Certificate Revocation List имеет формат PEM, но неправильное расширение файла CRL. Необходимо изменить имя файла на правильное расширение.
Общий драйвер представляет собой набор классов, охватывающих функциональный диапазон, которым должен обладать каждый драйвер в «КАСКАД Цифра». Он также определяет интерфейс для аппаратно-специфической части. Общий драйвер включает следующую функциональность:
Инициализация типа точки данных и контейнера точки данных;
Преобразование имен внутренних точек данных в идентификаторы точек данных (через менеджер данных).
ПРИМЕЧАНИЕ Преобразование DpIdentifier в строку с неизвестной точкой данных возвращает номер DpIdentfier.
Регистрация с помощью менеджера событий точек данных (или адресов периферии), которые указаны как выходные;
Регистрация с помощью менеджера событий внутренних точек данных драйвера;
Назначение адресов периферии аппаратным адресам и наоборот;
Механизм соединения (менеджер событий регистрирует атрибуты с помощью драйвера);
Преобразование (из аппаратных форматов в форматы данных «КАСКАД Цифра» и наоборот);
Преобразование и сглаживание команды или сообщения;
Переподключение в случае отказа менеджера событий;
Мониторинг подключений к аппаратным компонентам (механизм проверки присутствия в сети).
Эта функциональность реализована, насколько это возможно, с использованием виртуальных функций таким образом, что, выведя отдельный класс и определив отдельные функции, можно изменить обработку. Естественно, только особые случаи должны приводить к такой обработке: в обычном случае для обработки должны вызываться методы базового класса.
Программный интерфейс для аппаратного обеспечения реализован в виде пустого класса, который должен наследоваться и реализовываться для каждого фактического драйвера (HWService!).
ПРИМЕЧАНИЕ При использовании более трех драйверов и, соответственно, создании новых точек данных _DriverCommon, они должны быть учтены в файле конфигурации config.redu.
Работа драйвера
Общий драйвер выполняет следующие фазы (они соответствуют используемым процедурам):
init()
connectToData()
HWService.initialize()
connectToEvent()
HWService.start()
mainLoop()
HWService.stop()
После запуска происходит инициализации различных модулей драйвера (using init()). Для этого предусмотрены следующие методы:
install_DpContainer(): инициализация и привязка контейнера точки данных
install_DpConfigManager(): инициализация внутреннего менеджера конфигурационных элементов драйвера
install_HWMapper(): составление таблицы соответствий между аппаратными объектами и точками данных
install_HWService(): обработчик HWService представляет собой интерфейс для аппаратного обеспечения содержит все методы связи с ним. Эта часть всегда наследуется.
install_PollGroupList(): управление точками данных, которые циклически запрашиваются с помощью групп опроса.
install_PollList(): управление точками данных, которые подлежат циклическому опросу с помощью списка опроса. Используется в целях совместимости с версиями до 3.0.
install_IOTransCont(): управление транзакциями адресов ввода-ввода.
set_DpConfigInitList(): задает указатель на список типов конфигурационных элементов, которые менеджер данных должен отправить после подключения.
После инициализации устанавливается подключение с менеджером данных (connectToData()), который отправляет конфигурационные элементы для драйвера. Затем происходит инициализация объекта HWService (HWService.initialize()). Устанавливается соединение с менеджером событий (connectToEvent()). Запускается подключение аппаратно-ориентированной части драйвера (HWService.start()). Как правило, одновременно с этим устанавливается связь с периферией. Затем драйвер переходит в циклический режим работы, ожидая сообщений, проверяя необходимость опроса точек данных периферийных устройств и периодически запуская рабочую процедуру (workProc()) объекта HWService, которая обрабатывает данные с периферии и при необходимости раздает отклики. Сообщения, касающиеся внутренних точек данных драйвера, передаются объекту HWService.
При появлении адреса периферии, готового к опросу, в заданное время вызывается функция HWService::singleQuery() для получения значений. Незапрашиваемые сообщения обрабатываются функцией HWService::workProc(). Сообщения со значениями обрабатываются объектом HWService с помощью функции toDp() менеджера Drv. Она принимает на входе аппаратный объект, при необходимости выполняет низкоуровневое сравнение «старый-новый» (настраивается, основано на побитовом сравнении буфера данных аппаратного объекта), преобразует его в формат внутренних данных «КАСКАД Цифра» (с помощью подходящего для этого формата данных преобразования), при необходимости выполняет приведение и сглаживание, после чего отправляет его (если сглаживание не было проведено на предыдущих этапах) менеджеру событий.
В заданном направлении функция toHW() отвечает за преобразование точек данных «КАСКАД Цифра» в аппаратные объекты, которые затем отправляются на периферию методом HWService::writeDate(). Данные, обрабатываемые протоколом связи как блок (как правило, они логически связаны), должны также быть настроены как группа (в конфигурационном элементе адреса периферии). Затем они также автоматически регистрируются общим драйвером как группа, чтобы при каждом изменении данных пользователем, менеджер событий отправлял драйверу всю группу целиком. Процедурой toHW() эти данные собираются в пакет и передаются функции writeData() как единый аппаратный объект.
Перед завершением работы драйвера также вызывается функция HWService.stop() для организованного отключения от периферии.
Этот класс, наследуемый от DpContainer, реализует специальные функции контейнера точек данных драйвера, например, настройку преобразования или сглаживания, которые также могут быть определены в узлах в точке данных и применены к элементам на более низком уровне.
API «КАСКАД Цифра» (Application Programming Interface — интерфейс программирования приложений) предлагает ряд функций, добавляющих специальных менеджеров к системе управления процессами. Менеджер — это программа, которая взаимодействует с системой по протоколу, определенному «КАСКАД Цифра».
Документацию по функциям API можно найти в каталоге вашей установки
<путь_КАСКАД>/api/docu
ПРИМЕЧАНИЕ
Документация доступна только в том случае, если в настройках «КАСКАД Цифра» была выбрана опция установки API.
Классы, подключение из файлов
Для того чтобы облегчить работу с большим количеством классов C++, доступных в «КАСКАД Цифра», все подключаемые файлы называются точно так же, как и имя класса, но имеют расширение «.hxx». Например, класс под названием «ManagerIdentifier» можно найти в файле «ManagerIdentifier.hxx». То есть, для использования класса необходимо включить соответствующий файл с помощью директивы #include.
Многие классы можно использовать и без явного #include, т.к., например, файл Manager.hxx уже включает множество других классов.
Менеджер событий и данных
Один из основных менеджеров в «КАСКАД Цифра» — менеджер событий. Он является центром коммуникаций системы управления и как только любой другой менеджер загружается, начинается обмен сообщениями с менеджером событий.
Второй ключевой менеджер — это Менеджер данных, т.к. он выполняет все задачи по управлению данными. При запуске программы каждый менеджер подключается к Менеджеру данных для инициализации. После успешной инициализации программа подключается к Менеджеру событий (за исключением, конечно, самого Менеджера событий). Соединения с менеджером данных и менеджером событий поддерживаются до тех пор, пока работа текущего менеджера не будет завершена.
Программа может подключиться к менеджерам данных и событий только в том случае, если нет другого подключенного менеджера с тем же идентификатором. Особенно при использовании менеджеров API убедитесь, что все они одного типа и отличаются только идентификационным номером.
ВНИМАНИЕ
ВСЕГДА перекомпилируйте пользовательские менеджеры, созданные с помощью определенной версии «КАСКАД Цифра», при переходе к более поздней версии (это относится и к «branch» версиям!).
Сообщения
Менеджеры обмениваются информацией друг с другом с помощью сообщений. «КАСКАД Цифра» имеет фиксированный набор сообщений, используемых для связи.
Большинство функций API используются для генерации и отправки сообщений. Менеджеры получают сообщения с помощью функции doReceive(), которая применяется ко всем входящим сообщениям.
Файл заголовков FunctionVar
Так же в «КАСКАД Цифра» присутствует файл заголовков FunctionVar.hxx. Однако следует учитывать, что в этот файл также включены заголовки Qt, которые не входят в API «КАСКАД Цифра». Таким образом, необходима отдельная установка Qt.
В данном примере показано, как менеджер подключается к менеджерам данных и событий. Также он подключается к точке данных и каждый раз копирует новое значение в другую точку данных.
Пока вы будете использовать задокументированные функции API, нет необходимости в тщательном знании сообщений: сообщения создаются и отправляются функциями интерфейса API, поэтому пользователю не приходится иметь с ними дело.
Общий драйвер является совокупностью классов, охватывающих функциональный диапазон, которым должен обладать каждый драйвер программы «КАСКАД Цифра». Также он определяет интерфейс для компонентов, относящихся к аппаратному обеспечению.
Подготовлено два примерных сценария, чтобы упростить вам интегрирование новых драйверов в программу «КАСКАД Цифра». Все, что вам необходимо сделать, — это добавить имя и тип в указанных точках в сценариях, и определить свои команды.
EWO (объект внешнего виджета) — это графический объект (виджет), который был создан сторонней организацией (заказчиком), и может быть встроен в любую панель «КАСКАД Цифра». Этот объект не зависит от платформы.
Функция “regexpIndex()” обеспечивает сопоставление с шаблоном с помощью регулярных выражений. Функция выполняет поиск соответствия указанному символу, начиная с заданной позиции.
Краткий обзор
int regexpIndex(строковое регулярное выражение, строковая строка [, параметры сопоставления]);
Параметр
Описание
rexexp
Регулярное выражение. Примером может быть, например, «[a]+” В этом примере выполняется поиск символа a. Знак + выполняет поиск по букве один или несколько раз, что означает, что знак + обозначает по крайней мере однократное повторение.
строка
Строка, которая проверяется.
Опции
Для сопоставления могут использоваться следующие клавиши: StartPosition: задает начальную позицию для поиска: (По умолчанию: int 0 = начало строки). -1 означает, что функция выполняет поиск символов, начинающихся с последнего символа строки. При значении -2 функция выполняет поиск, начиная с предпоследнего символа и т.д. С учетом регистра: установите соответствие с учетом регистра (по умолчанию: bool false). Установите минимальное соответствие (по умолчанию: bool false). Пример минимального соответствия см. в главе regexpSplit().
Возвращаемое значение
Функция возвращает позицию первого совпадения с искомым символом. Индекс начинается с 0. Это означает, что первым совпадением символа s в слове “This” будет позиция 3.
Функция возвращает значение -1, если совпадение не найдено.
Функция возвращает значение -2, когда регулярное выражение содержит ошибку. Ошибки могут быть извлечены с помощью функции GetLastError().
Функция возвращает -3, когда функция содержит неправильные аргументы.
Ошибки
Смотрите выше
Описание
Функция “regexpIndex()” обеспечивает сопоставление с шаблоном с помощью регулярных выражений. Функция выполняет поиск соответствия указанному символу, начиная с заданной позиции.
ПРИМЕР
В первом примере выполняется поиск буквы n, начиная с позиции 0 (начало текста). Функция возвращает первое совпадение буквы. Первое совпадение буквы n — это ein (дас ист эиn тестирует mit n). Индекс вычисляется, начиная с 0. Таким образом, пример возвращает значение 10.
Во втором примере выполняется поиск буквы n, начиная с конца текста. Функция возвращает первое совпадение буквы. Первое совпадение буквы n, начиная с конца текста, равно n (Das ist ein Test mit n). Индекс вычисляется, начиная с 0. Таким образом, пример возвращает 21.
main(mapping event)
{
int i = 0;
i = regexpIndex("[n]+", "Das ist ein Test mit n", makeMapping("startPosition", 0));
DebugN("Position von 'n' in Das ist ein Test mit n. Gesucht ab Position 0:", i);
i = regexpIndex("[n]+", "Das ist ein Test mit n", makeMapping("startPosition", -1));
DebugN("Position von 'n' in Das ist ein Test mit n. Gesucht ab Ende der Zeichenkette:", i);
}
ПРИМЕЧАНИЕ
ВНИМАНИЕ!
ПРИМЕР
ПРИМЕЧАНИЕ
ВНИМАНИЕ