актуальна тутМодуль підсистеми "Архіви" <DBArch>
| Модуль: | DBArch |
| Ім'я: | Архіватор на БД |
| Тип: | Архів |
| Джерело: | arh_DBArch.so |
| Версія: | 2.4 |
| Автор: | Роман Савоченко |
| Опис: | Модуль архіватору. Надає функції архівування повідомлень та значень на БД. |
| Ліцензія: | GPL |
Вступ
Модуль призначено для архівування повідомлень та значень системи OpenSCADA на одну із баз даних, підтримуваних OpenSCADA.Будь яка SCADA система надає можливість архівування зібраних даних, тобто формування джерела змін (динаміки) процесів. Архіви умовно можна поділити на два типи: архіви повідомлень та архіви значень.
Особливістю архівів повідомлень є те, що архівуються, так звані, повідомлення. Характерною ознакою повідомлення є час його виникнення. Архіви повідомлень за звичай використовуються для архівування повідомлень у системі, тобто ведення логів та протоколів. У залежності від джерела повідомлення можуть класифікуватися за різними критеріями. Наприклад, це можуть бути протоколи аварійних ситуацій, протоколи дій операторів, протоколи збоїв зв'язку та інше.
Особливістю архівів значень є їх періодичність, яка визначається проміжком часу між двома суміжними значеннями. Архіви значень застосовуються для архівування історії безперервних процесів. Оскільки процес безперервний, то й архівувати його можна тільки шляхом введення поняття квантування часу опитування, оскільки інакше ми отримуємо архіви нескінченних розмірів у зв'язку із неперервністю самої природи процесу. Крім того, практично ми можемо отримати значення з періодом обмеженим самими джерелами даних. Наприклад, доволі якісні джерела даних у промисловості рідко дозволяють отримувати дані з частотою більшою за 1кГц. І це без врахування самих давачів, які мають ще менш якісні характеристики.
Для ведення архівів у системі OpenSCADA передбачено підсистему "Архіви". Ця підсистема, у відповідності із типами архівів, складається із двох частин: архів повідомлень та архіви значень. Підсистема в цілому є модульною, що дозволяє створювати архіви основані на різній природі та способах зберігання даних. Цей модуль надає механізм архівування на БД як для потоку повідомлень, так і для потоку значень.
1. Архіватор повідомлень
Архіви повідомлень формуються архіваторами. Архіваторів може бути безліч з індивідуальними налаштуваннями, які дозволяють поділяти архівування різних класів повідомлень.Архіватор повідомлень цього модуля зберігає дані у таблиці БД, яка називається "DBAMsg_{ArchID}", де:
- ArchID — ідентифікатор архіватору повідомлень.
Модулем надаються додаткові параметри налаштування процесу архівування (рис.1).
Рис.1. Додаткові параметри налаштування процесу архівування повідомлень.
До числа додаткових параметрів входять:
- Розмір архіву (днів) — визначає розмір архіву за часом. Після перевищення ліміту старі записи почнуть видалятися! Встановити у 0 для відключення цього ліміту та деякого підвищення продуктивності.
- Формувати час як рядок — зберігати час повідомлення у читабельному вигляді. Тільки для БД які це підтримують у специфічному форматі даних на кшталт "datetime" у MySQL.
Ця опція несумісна, тобто при її зміні Ви втратите чинні архіви.
Таблиця БД архіватору повідомлень має структуру {MIN, TM, TMU, CATEG, MESS, LEV}, де:
- MIN — UTC час, у хвилинах, використовується при читанні хвилинами, для прискорення.
- TM — UTC час повідомлення, секунди від епохи (01.01.1970). У БД, які містять спеціалізований тип для зберігання дати та часу, може використовуватися цей спеціалізований тип, для параметру "Формувати час як рядок".
- TMU — мікросекунди часу.
- CATEG — категорія повідомлення.
- MESS — текст повідомлення.
- LEV — рівень повідомлення.
2. Архіватор значень
Архіви значень, по замовченню, формуються архіваторами значень індивідуально для кожного зареєстрованого архіву. Архіваторів може бути безліч із індивідуальними налаштуваннями, які дозволяють поділити архіви за різними параметрами, наприклад, за точністю та глибиною. Архіви параметрів одного архіватору можуть поєднуватися за групами, одна таблиця, із вказаним обмеженням кількості параметрів у групі. Групування дозволяє значно підвищити продуктивність архівації за рахунок надсилання до БД одного запиту із значеннями параметрів у групі.Архів значень є незалежним компонентом, який включає буфер, який обробляється архіваторами. Основним параметром архіву значень є джерело даних. У ролі джерела даних можуть виступати атрибути параметрів системи OpenSCADA, а також інші зовнішні джерела даних (пасивний режим). Іншими джерелами даних можуть бути: мережеві архіватори віддалених OpenSCADA систем, середовище програмування системи OpenSCADA та інше. Не менш важливими параметрами архіву є параметри його буферу. Від параметрів буферу залежить можливість роботи архіваторів.
Так, періодичність значень у буфері має бути не більше за періодичність самого швидкого архіватору, а розмір буферу не менш подвійного розміру для самого повільного архіватору. Інакше можливі втрати даних.Загальну схему архівування значень наочно зображено на рис. 2.
Рис.2. Загальна схема процесу архівування значень.
Архіватор значень цього модуля зберігає дані у таблиці БД, яка іменується "DBAVl_{ArchivatorID}_{ArchiveID}", для одиночного режиму, та "DBAVl_{ArchivatorID}_<GRP>{N}", для групового режиму, де:
- ArchivatorID — Ідентифікатор архіватору значень.
- ArchiveID — Ідентифікатор архіву значень.
- N — Номер групи, опущено для першої.
Модулем надаються додаткові параметри налаштування процесу архівування (рис.3).
Рис.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. Цим модулем така особливість також тепер використовується дозволяючи дані часто отримувати швидше ніж вони потім обробляються, хоча й поступаються архівації на файлову систему.
- Запис до БД окремої колонки також значно швидше, ніж окремого запису. Даним модулем ця особливість використовується в частині архівації значень і у режимі групування, тобто значення окремих сигналів пишуться до однієї таблиці як окрема колонка.
Результати вимірювання продуктивності архівації зведені в таблиці нижче:
| Test / Environment and DB | Intel Core3 1.3GHz, Local PostgreSQL 9.3, SSD | AMD A8 3.5GHz, Local 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 writing 60 values of signal (millisecond), maximum number of the archiving signals in periodicity 1 second | 1, 60000 | 0.4, 150000 |