| Модуль | Имя | Версия | Лицензия | Источник | Языки | Платформы | Тип | Автор | Описание |
|---|---|---|---|---|---|---|---|---|---|
| DBArch | Архиватор на БД | 3.0 | GPL2 | arh_DBArch.so | en,uk,ru,de | x86,x86_64,ARM | Архив | Роман Савоченко | Модуль архиватора. Предоставляет функции архивирования сообщений и значений на БД.
|
Модуль предназначен для архивирования сообщений и значений OpenSCADA на одну из баз данных, поддерживаемых OpenSCADA.
Любая SCADA система предоставляет возможность архивирования собранных данных, т.е. формирование истории изменения (динамики) процессов. Архивы условно можно разделить на два типа: архивы сообщений и архивы значений.
Особенностью архивов сообщений является то, что архивируются так называемые события. Характерным признаком события является его время возникновения. Архивы сообщений обычно используются для архивирования сообщений программы, т.е. ведение логов и протоколов. В зависимости от источника, сообщения могут классифицироваться по различным критериям. Например, это могут быть: протоколы аварийных ситуаций, протоколы действий операторов, протоколы сбоев связи и др.
Особенностью архивов значений является их периодичность, определяемая промежутком времени между двумя смежными значениями. Архивы значений применяются для архивирования истории непрерывных процессов. Поскольку процесс непрерывный то и архивировать его можно только путём введения понятия квантования времени опроса, поскольку иначе мы получаем архивы бесконечных размеров ввиду непрерывности самой природы процесса. Кроме этого, практически мы можем получать значения с периодом ограниченным самими источниками данных. Например, довольно качественные источники данных в промышленности редко позволяют получать данные с частотой более 1кГц. И это без учёта самих датчиков, имеющих ещё менее качественные характеристики.
Для ведения архивов в OpenSCADA предусмотрена подсистема "Архивы-История". Данная подсистема, в соответствии с типами архивов, состоит из двух частей: архив сообщений и архивы значений. Подсистема, в целом, является модульной, что позволяет создавать архивы, основанные на различной природе и способах хранения данных. Данный модуль предоставляет механизм архивирования на файловую систему как для потока сообщений, так и для потока значений.
Contents
[hide]1 Архиватор сообщений
Архивы сообщений формируются архиваторами, которых может быть множество и с индивидуальными настройками, что позволяет разделять архивирование различных классов сообщений.
Архиватор сообщений этого модуля хранит данные в таблице БД, которая называется "DBAMsg_{ArchID}", где:
- ArchID — идентификатор архиватора сообщений.
Модулем предоставляются дополнительные параметры настройки процесса архивирования, рисунок 1.
These additional parameters:
- Archive size, days — determines the size of the archive over time. After exceeding the limit the old records will be deleted! Set to 0 to disable this limit and to rise some the performance.
- To form time as a string — store messages time in the readable form. Only for databases that support such by means of specific data types like "datetime" in MySQL.
This option is incompatible, that is, if you change it, you will lose your current archives. - Unique and non duple messages for time and category only — in the primary key there used the fields MIN, TM, TMU and CATEG; otherwise the field MESS is included also to the primary key and is limited in 255 symbols.
Таблица БД архиватора сообщений имеет структуру {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 |