| Модуль | Имя | Версия | Лицензия | Источник | Языки | Платформы | Тип | Автор | Описание |
|---|---|---|---|---|---|---|---|---|---|
| DBArch | Архиватор на БД | 3.1 | GPL2 | arh_DBArch.so | en,uk,ru,de | x86,x86_64,ARM | Архив | Роман Савоченко | Модуль архиватора. Предоставляет функции архивирования сообщений и значений на БД.
|
Модуль предназначен для архивирования сообщений и значений OpenSCADA на одну из баз данных, поддерживаемых OpenSCADA.
Любая SCADA система предоставляет возможность архивирования собранных данных, т.е. формирование истории изменения (динамики) процессов. Архивы условно можно разделить на два типа: архивы сообщений и архивы значений.
Особенностью архивов сообщений является то, что архивируются так называемые события. Характерным признаком события является его время возникновения. Архивы сообщений обычно используются для архивирования сообщений программы, т.е. ведение логов и протоколов. В зависимости от источника, сообщения могут классифицироваться по различным критериям. Например, это могут быть: протоколы аварийных ситуаций, протоколы действий операторов, протоколы сбоев связи и др.
Особенностью архивов значений является их периодичность, определяемая промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный то и архивировать его можно только путём введения понятия квантования времени опроса, поскольку иначе мы получаем архивы бесконечных размеров ввиду непрерывности самой природы процесса. Кроме этого, практически мы можем получать значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1кГц. И это без учёта самих датчиков, имеющих ещё менее качественные характеристики.
Для ведения архивов в OpenSCADA предусмотрена подсистема "Архивы-История". Данная подсистема, в соответствии с типами архивов, состоит из двух частей: архив сообщений и архивы значений. Подсистема, в целом, является модульной, что позволяет создавать архивы, основанные на различной природе и способах хранения данных. Данный модуль предоставляет механизм архивирования на файловую систему как для потока сообщений, так и для потока значений.
Contents
1 Архиватор сообщений
Архивы сообщений формируются архиваторами, которых может быть множество и с индивидуальными настройками, что позволяет разделять архивирование различных классов сообщений.
Архиватор сообщений этого модуля хранит данные в таблице БД, которая называется "DBAMsg_{ArchID}", где:
- ArchID — идентификатор архиватора сообщений.
Модулем предоставляются дополнительные параметры настройки процесса архивирования, рисунок 1.
В число дополнительных параметров входят:
- Размер архива, дней — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения данного лимита и некоторого повышения производительности.
- Формировать время как строка — сохранять время сообщения в читабельном виде. Только для БД поддерживающих такое посредством специфических типов данных вроде "datetime" в MySQL.
Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы. - Уникальные и недублирующие сообщения только за временем и категорией — в первичном ключе используются поля MIN, TM, TMU и CATEG; иначе поле сообщения включается к первичному ключу и его ограничено 255 символами.
Таблица БД архиватора сообщений имеет структуру {MIN, TM, TMU, CATEG, MESS, LEV}, где:
- MIN — UTC время, в минутах, используется для ускорения при чтении минутами.
- TM — UTC время сообщения, секунды от эпохи (01.01.1970). Тут может использоваться специализированный тип для параметра "Формировать время как строка", если он поддерживается БД.
- TMU — микросекунды времени.
- CATEG — категория сообщения.
- MESS — текст сообщения.
- LEV — уровень сообщения.
2 Архиватор значений
Архивы значений формируются архиваторами значений индивидуально для каждого зарегистрированного архива. Архиваторов может быть множество и с индивидуальными настройками, которые позволяющими разделить архивы по различным параметрам, например, по точности и глубине. Архивы параметров одного архиватора могут группироваться в группы, одна таблица, с указанным ограничением количества параметров в группе. Группирование позволяет значительно увеличить производительность архивации за счёт отправки в БД одного запроса со значениями параметров в группе.
Архив значений является независимым компонентом, который включает буфер, обрабатываемый архиваторами. Основным параметром архива значения является источник данных. В роли источника данных могут выступать атрибуты параметров подсистемы "Сбор данных", а также другие внешние источники данных (пассивный режим). Другими источниками данных могут быть: сетевые архиваторы удалённых OpenSCADA станций, среда программирования OpenSCADA и др. Не менее важными параметрами архива являются параметры его буфера. От параметров буфера зависит возможность работы архиваторов. 
Так, периодичность значений в буфере должна быть не больше периодичности самого быстрого архиватора, а размер буфера не менее двойного размера для самого медленного архиватора. В противном случае возможны потери данных.
Общая схема архивирования значений наглядно изображена на рисунке 2.
Архиватор значений этого модуля хранит данные в таблице БД, которая называется "DBAVl_{ArchivatorID}_{ArchiveID}", для одиночного режима, и "DBAVl_{ArchivatorID}_<GRP>{N}", для группового режима, где:
- ArchivatorID — идентификатор архиватора значений;
- ArchiveID — идентификатор архива значений;
- N — номер группы, опущен для первой.
Модулем предоставляются дополнительные параметры настройки процесса архивирования, рисунок 3.
В число дополнительных параметров входят:
- Размер архива, дней — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения данного лимита и некоторого повышения производительности.
- Формировать время как строка — сохранять время сообщения в читабельном виде. Только для БД поддерживающих такое посредством специфических типов данных вроде "datetime" в MySQL. Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы.
- Ограничение группировки параметров — ненулевое значение включает групповое архивирование и определяет ограничение на количество параметров в группе/таблице.
Таблица БД архиватора значений имеет структуру {MARK, TM, VAL}, для одиночного режима, и {MARK, TM, {PRM1}, {PRM2}, {PRMN}}, для группового, где:
- MARK — метка быстрого доступа/чтения архива, {TM}/(10*{period}).
- TM — UTC время значения, секунды от эпохи (01.01.1970). Тут может использоваться специализированный тип для параметра "Формировать время как строка", если он поддерживается БД.
- VAL — значение параметра в одиночном режиме, тип значения определяет тип данной колонки (Целое, Вещественное, Строка).
- PRM1...PRMN — значение параметра с идентификатором в имени колонки, для группового режима, тип значения определяет тип данной колонки (Целое, Вещественное, Строка).
3 Информационная таблица архивных таблиц
Для хранения начала, конца и иной служебной информации архивов в архивных таблицах, создаётся информационная таблица с именем данного модуля "DBArch". Данная таблица имеет структуру {TBL, BEGIN, END, PRM1, PRM2, PRM3}, где:
- TBL — имя таблицы архива.
- BEGIN — начало данных в архиве. Секунды для сообщений и микросекунды для значений от эпохи UNIX (01.01.1970).
- END — конец данных в архиве. Секунды для сообщений и микросекунды для значений от эпохи UNIX (01.01.1970).
- PRM1 — дополнительный параметр 1: периодичность значений, в микросекундах.
- PRM2 — дополнительный параметр 2: тип значений параметра, в одиночном режиме, или перечень параметров в группе {Type}:{ArchiveId}, для группового режима.
- PRM3 — дополнительный параметр 3.
Согласно информации в указанной таблице, для архиваторов значений поддерживается восстановление и создание объектов архива.
4 Эффективность
При проектировании и реализации данного модуля особых механизмов повышения эффективности процесса архивирования не закладывалось в виду наличия объективных ограничений самих баз данных и интерфейсов доступа к ним. Следовательно, эффективность архивации на БД в основном связана с самой БД и интерфейсом доступа к ней. Из наиболее эффективных интерфейсов и подходов по повышению производительности нужно отметить следующие:
- Чтение из БД нескольких записей не отдельными/конкретными командами SELECT, а обобщающими SELECT запросами, что для всех БД минимум на порядок быстрее. Для использования этой особенности, слой доступа к БД в OpenSCADA, в лице запроса "dataSeek()", был расширен на предмет поддержки предзагрузки всех записей ответа на запрос в full. Данным модулем эта особенность также теперь используется позволяя данные получать часто быстрее чем они потом обрабатываются, хотя и уступая архивации на файловую систему.
- Запись в БД отдельной колонки также значительно быстрее, чем отдельная запись таблицы. Данным модулем эта особенность используется в части архивации значений и в режиме группировки, т.е. значения отдельных сигналов пишутся в одну таблицу как отдельная колонка.
Результаты измерений производительности архивации сведены в таблице ниже:
| Тест / Окружение и БД | Intel Core3 1.3GHz, Локальный PostgreSQL 9.3, SSD | AMD A8 3.5GHz, Локальный PostgreSQL 9.3, HDD |
|---|---|---|
| Values archiving, 60 records, 1 signal (seconds) | 53...63 | 13...14 |
| Values archiving, 60 records, 10 signal (seconds) | 65...67 | 16...19 |
| Values archiving, 60 records, 100 signal (seconds) | 154...163 | 52...60 |
| Result: average time of the writing 60 values of the signal (millisecond), estimated maximum number of the archiving signals in the 1 second periodicity |
1, 60000 | 0.4, 150000 |