From OpenSCADAWiki
Jump to: navigation, search
This page is a translated version of the page Modules/DBArch and the translation is 100% complete.

Other languages:
English • ‎российский • ‎українська
Модуль Имя Версия Лицензия Источник Языки Платформы Тип Автор Описание
DBArch Архиватор на БД 2.8 GPL2 arh_DBArch.so en,uk,ru,de x86,x86_64,ARM Архив Роман Савоченко Модуль архиватора. Предоставляет функции архивирования сообщений и значений на БД.

Модуль предназначен для архивирования сообщений и значений OpenSCADA на одну из баз данных, поддерживаемых OpenSCADA.

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

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

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

Для ведения архивов в OpenSCADA предусмотрена подсистема "Архивы-История". Данная подсистема, в соответствии с типами архивов, состоит из двух частей: архив сообщений и архивы значений. Подсистема, в целом, является модульной, что позволяет создавать архивы, основанные на различной природе и способах хранения данных. Данный модуль предоставляет механизм архивирования на файловую систему как для потока сообщений, так и для потока значений.

1 Архиватор сообщений

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

Архиватор сообщений этого модуля хранит данные в таблице БД, которая называется "DBAMsg_{ArchID}", где:

  • ArchID — идентификатор архиватора сообщений.

Модулем предоставляются дополнительные параметры настройки процесса архивирования, рисунок 1.

Рис.1. Дополнительные параметры настройки процесса архивирования сообщений.

В число дополнительных параметров входят:

  • Размер архива, дней — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения данного лимита и некоторого повышения производительности.
  • Формировать время как строка — сохранять время сообщения в читабельном виде. Только для БД поддерживающих такое посредством специфических типов данных вроде "datetime" в MySQL. At.png Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы.

Таблица БД архиватора сообщений имеет структуру {MIN, TM, TMU, CATEG, MESS, LEV}, где:

  • MIN — UTC время, в минутах, используется для ускорения при чтении минутами.
  • TM — UTC время сообщения, секунды от эпохи (01.01.1970). Тут может использоваться специализированный тип для параметра "Формировать время как строка", если он поддерживается БД.
  • TMU — микросекунды времени.
  • CATEG — категория сообщения.
  • MESS — текст сообщения.
  • LEV — уровень сообщения.

2 Архиватор значений

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

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

Общая схема архивирования значений наглядно изображена на рисунке 2.

Рис.2. Общая схема процесса архивирования значений.

Архиватор значений этого модуля хранит данные в таблице БД, которая называется "DBAVl_{ArchivatorID}_{ArchiveID}", для одиночного режима, и "DBAVl_{ArchivatorID}_<GRP>{N}", для группового режима, где:

  • ArchivatorID — идентификатор архиватора значений;
  • ArchiveID — идентификатор архива значений;
  • N — номер группы, опущен для первой.

Модулем предоставляются дополнительные параметры настройки процесса архивирования, рисунок 3.

Рис.3. Дополнительные параметры настройки процесса архивирования значений.

В число дополнительных параметров входят:

  • Размер архива, дней — определяет размер архива по времени. После превышения лимита старые записи начнут удаляться! Установить в 0 для отключения данного лимита и некоторого повышения производительности.
  • Формировать время как строка — сохранять время сообщения в читабельном виде. Только для БД поддерживающих такое посредством специфических типов данных вроде "datetime" в MySQL. At.png Данная опция несовместима, т.е. при её изменении Вы потеряете существующие архивы.
  • Ограничение группировки параметров — ненулевое значение включает групповое архивирование и определяет ограничение на количество параметров в группе/таблице.

Таблица БД архиватора значений имеет структуру {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

5 Ссылки