Модуль: | FSArch |
Ім'я: | Архіватор на файлову систему |
Тип: | Архів |
Джерело: | arh_FSArch.so |
Версія: | 2.9 |
Автор: | Роман Савоченко |
Опис: | Модуль архіватору. Надає функції архівування повідомлень та значень на файлову систему. |
Ліцензія: | GPL |
Модуль призначено для архівування повідомлень та значень системи OpenSCADA на файлову систему.
Будь яка SCADA система надає можливість архівування зібраних даних, тобто формування історії змін (динаміки) процесів. Архіви умовно можна поділити на два типи: архіви повідомлень та архіви значень.
Особливістю архівів повідомлень є те, що архівуються, так звані, повідомлення. Характерною ознакою повідомлення є час його виникнення. Архіви повідомлень за звичай використовуються для архівування повідомлень у системі, тобто ведення логів та протоколів. У залежності від джерела повідомлення можуть класифікуватися за різними критеріями. Наприклад, це можуть бути протоколи аварійних ситуацій, протоколи дій операторів, протоколи збоїв зв'язку та інше.
Особливістю архівів значень є їх періодичність, яка визначається проміжком часу між двома суміжними значеннями. Архіви значень застосовуються для архівування історії безперервних процесів. Оскільки процес безперервний, то й архівувати його можна тільки шляхом введення поняття квантування часу опитування, оскільки інакше ми отримуємо архіви нескінченних розмірів у зв'язку із неперервністю самої природи процесу. Крім того, практично ми можемо отримати значення з періодом обмеженим самими джерелами даних. Наприклад, доволі якісні джерела даних у промисловості рідко дозволяють отримувати дані з частотою більшою за 1кГц. І це без врахування самих давачів, які мають ще менш якісні характеристики.
Для ведення архівів у системі OpenSCADA передбачено підсистему "Архіви". Ця підсистема, у відповідності із типами архівів, складається із двох частин: архів повідомлень та архіви значень. Підсистема в цілому є модульною, що дозволяє створювати архіви основані на різній природі та способах зберігання даних. Цей модуль надає механізм архівування на файлову систему як для потоку повідомлень, так і для потоку значень.
Архіви повідомлень формуються архіваторами. Архіваторів може бути безліч з індивідуальними налаштуваннями, які дозволяють поділяти архівування різних класів повідомлень.
Архіватор повідомлень цього модуля дозволяє зберігати дані як у файлах формату мови XML, так і у форматі плоского тексту. Мова розмітки XML є стандартним форматом, який з легкістю розуміють багато сторонніх додатків. Однак відкриття та розбір файлів у такому форматі вимагає значних ресурсів. З іншого боку, формат плоского тексту вимагає значно менше ресурсів, хоча і не є уніфікованим, а також вимагає знань його структури для розбору.
В будь якому разі підтримуються обидва формати та користувач може обрати будь який з них, у відповідності із власними потребами.
Файли архівів іменуються архіваторами, виходячи із дати першого повідомлення у архіві. Наприклад, так: "2006-06-21 17:11:04.msg".
Файли архівів можуть обмежуватися за розміру та часом. Після перевищення ліміту створюється новий файл. Максимальна кількість файлів у теці архіватору також може бути обмежена. Після перевищення ліміту на кількість файлів, старі файли почнуть видалятися!
З метою оптимізації використання дискового простору архіватори підтримують упаковку старих архівів пакувальником gzip. Упаковка здійснюється після тривалого невикористання архіву.
При використанні архівів у форматі мови XML відповідні файли завантажуються цілком! Для вивантаження невикористаних тривалий час архівів застосовується таймаут доступу до архіву, після перевищення якого архів вивантажується із пам'яті, а потім і пакується.
Модулем надаються додаткові параметри налаштування процесу архівування (рис.1).
До числа цих параметрів входять:
Для контролю за файлами архіватору Ви можете подивитися у вкладці "Файли" (рис. 2).
У таблиці нижче приведено синтаксис файлу архіву, побудованого на XML-мові:
Тег | Опис | Атрибути | Вміст |
FSArch | Кореневий елемент. Ідентифікує файл як той що належить цьому модулю. | Version — версія файлу архіву; Begin — час початку архіву (hex - UTC в секундах від 01/01/1970); End — час закінчення архіву (hex - UTC в секундах від 01/01/1970). | (m) |
m | Тег окремого повідомлення. | tm — час створення повідомлення (hex - UTC в секундах від 01/01/1970); tmu — мікросекунди часу повідомлення; lv — рівень повідомлення; cat — категорія повідомлення. | Текст повідомлення |
Архівний файл на основі плоского тексту складається із:
Текст повідомлення та категорія кодуються з метою виключення символів роздільників (символ пробілу).
Приклад вмісту архівного файлу у форматі мови XML:
<?xml version='1.0' encoding='UTF-8' ?> <FSArch Version="1.3.0" Begin="4a27dfbc" End="4a28c990"> <m tm="4a28c982" tmu="905587" lv="4" cat="/DemoStation/sub_DAQ/mod_DiamondBoards/">Помилка dscInit.</m> <m tm="4a28c990" tmu="595549" lv="4" cat="/DemoStation/sub_Transport/mod_Sockets/out_HDDTemp/">Помилка підключення до Internet сокету: Операція виконується на цей час!</m> </FSArch>
Приклад вмісту архівного файлу у форматі плоского тексту:
FSArch 1.2.0 UTF-8 4a27dfbb 4a28c991 4a28c98f:432619 1 /DemoStation/ Запуск! 4a28c98f:432858 1 /DemoStation/sub_Transport/ Пуск%20підсистеми. 4a28c98f:455400 1 /DemoStation/sub_DAQ/mod_DAQGate/cntr_test/ Включення%20контролеру! 4a28c98f:457360 1 /DemoStation/sub_DAQ/mod_ModBus/cntr_testTCP/ Включення%20контролеру! 4a28c98f:460691 1 /DemoStation/sub_DAQ/mod_ModBus/cntr_testRTU/ Включення%20контролеру! 4a28c98f:464227 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_Anast1to2node/ Включення%20контролеру! 4a28c98f:680767 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM102cntr/ Включення%20контролеру! 4a28c98f:705683 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_Anast1to2node_cntr/ Включення%20контролеру! 4a28c98f:753659 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM101/ Включення%20контролеру! 4a28c98f:905073 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM102/ Включення%20контролеру! 4a28c990:81670 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM201/ Включення%20контролеру! 4a28c990:206208 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_КМ202/ Включення%20контролеру! 4a28c990:333471 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM301/ Включення%20контролеру! 4a28c990:457490 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM302/ Включення%20контролеру! 4a28c990:591702 1 /DemoStation/sub_DAQ/mod_System/cntr_AutoDA/ Включення%20контролеру! 4a28c990:595549 4 /DemoStation/sub_Transport/mod_Sockets/out_HDDTemp/ Помилка%20підключення%20к%20Internet%20сокету:%20Операція%20виконується%20на%20цей%20час! 4a28c990:618617 1 /DemoStation/sub_DAQ/mod_SoundCard/cntr_test/ Включення%20контролеру! 4a28c990:621487 1 /DemoStation/sub_DAQ/mod_LogicLev/cntr_experiment/ Включення%20контролеру! 4a28c990:729323 1 /DemoStation/sub_DAQ/mod_JavaLikeCalc/cntr_testCalc/ Включення%20контролеру! 4a28c990:733434 1 /DemoStation/sub_DAQ/mod_Siemens/cntr_test/ Включення%20контролеру! 4a28c990:754368 1 /DemoStation/sub_DAQ/mod_DAQGate/cntr_test/ Включення%20контролеру! 4a28c990:786925 1 /DemoStation/sub_Archive/ Пуск%20підсистеми. 4a28c990:955967 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_Anast1to2node/ Запуск%20контролера! 4a28c990:957251 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM102cntr/ Запуск%20контролера! 4a28c990:957636 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_Anast1to2node_cntr/ Запуск%20контролера! 4a28c990:958006 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM101/ Запуск%20контролера! 4a28c990:958637 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM102/ Запуск%20контролера! 4a28c990:959268 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM201/ Запуск%20контролера! 4a28c990:959875 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_КМ202/ Запуск%20контролера! 4a28c990:961261 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM301/ Запуск%20контролера! 4a28c990:961919 1 /DemoStation/sub_DAQ/mod_BlockCalc/cntr_KM302/ Запуск%20контролера! 4a28c990:963775 1 /DemoStation/sub_DAQ/mod_System/cntr_AutoDA/ Запуск%20контролера! 4a28c990:966980 1 /DemoStation/sub_DAQ/mod_LogicLev/cntr_experiment/ Запуск%20контролера! 4a28c991:26791 1 /DemoStation/sub_Archive/ Пуск%20підсистеми. 4a28c991:28489 1 /DemoStation/sub_UI/mod_VCAEngine/ Старт%20модуля.
Архіви значень, по замовченню, формуються архіваторами значень індивідуально для кожного зареєстрованого архіву. Архіваторів може бути безліч із індивідуальними налаштуваннями, які дозволяють поділити архіви за різними параметрами, наприклад, за точністю та глибиною.
Архів значень є незалежним компонентом, який включає буфер, який обробляється архіваторами. Основним параметром архіву значень є джерело даних. У ролі джерела даних можуть виступати атрибути параметрів системи OpenSCADA, а також інші зовнішні джерела даних (пасивний режим). Іншими джерелами даних можуть бути: мережеві архіватори віддалених OpenSCADA систем, середовище програмування системи OpenSCADA та інше. Не менш важливими параметрами архіву є параметри його буферу. Від параметрів буферу залежить можливість роботи архіваторів. Так, періодичність значень у буфері має бути не більше за періодичність самого швидкого архіватору, а розмір буферу не менш подвійного розміру для самого повільного архіватору. Інакше можливі втрати даних.
Загальну схему архівування значень наочно зображено на рис.3.
Файли архівів іменуються архіваторами, виходячи із дати першого значення у архіві та ідентифікатору архіву. Наприклад, таким чином: "MemInfo_use 2006-06-17 17:32:56.val".
Файли архівів можуть обмежуватися за часом. Після перевищення ліміту створюється новий файл. Максимальна кількість файлів у теці архіватору також може обмежуватися. Після перевищення ліміту на кількість файлів старі файли почнуть видалятися!
З метою економії дискового простору архіватори підтримують пакування, додатково до послідовного пакування старих архівів пакувальником gzip. Пакування здійснюється після тривалого невикористання архіву. Для забезпечення можливості швидкого підключення великих архівів до іншої системи можна включити використання інформаційних файлів для упакованих файлів, що попередить попереднє розпакування всіх файлів на іншій системі.
Модулем надаються додаткові параметри налаштування процесу архівування (рис.4).
До числа цих параметрів входять:
Для контролю за файлами архіватору Ви можете переглянути у вкладці "Файли" (рис. 5).
Для реалізації архівування на файлову систему пред'являлися наступні вимоги:
Відповідно до вищевикладених вимог організовано архівування методом множинності файлів (для кожного джерела). Циклічність архіву реалізується на рівні файлів, тобто створюється новий файл, а самий старий видаляється. Для швидкого стиснення використовується метод притягнення до останнього однакового значення. Для цих цілей у файлі архіву передбачається бітова таблиця упаковки розміром один в один із кількістю збережених даних. Тобто кожний біт відповідає одному значенню у архіві. Значення біту вказує на наявність значення. Для потоку однакових значень біти онулені. У випадку із архівом рядків таблиця є не бітовою а байтовою та містить довжину відповідного значення. у випадку надходження потоку однакових значень, довжина буде нульовою та читатися буде перше однакове значення. Оскільки таблиця байтова, то архів зможе зберігати рядки довжиною не більше 255 символів. Таким чином, методики збереження можна розділити на методику даних фіксованого та нефіксованого розміру. Загальну структуру файлу архіву приведено на рис.6.
При створені нового файлу архіву формується: заголовок (структура заголовку у таблиці 1), нульова бітова таблиця упаковки архіву та перше недостовірне значення. Таким чином, виходить архів, ініційований недостовірними значеннями. Надалі нові значення будуть вставлятися у область значень із коригуванням індексної таблиці упаковки. З цього слідує, що пасивні архіви будуть вироджуватися у файли розміром з заголовок та бітову таблицю.
Таблиця 1. Структура заголовку файлу архіву
Поле | Опис | Розмір байт(біт) |
f_tp | Системне ім'я архіву ("OpenSCADA Val Arch.") | 20 |
archive | Ім'я архіву, якому належить файл. | 20 |
beg | Час початку архівних даних (мкс) | 8 |
end | Час кінця архівних даних (мкс) | 8 |
period | Періодичність архіву (мкс) | 8 |
vtp | Тип значення у архіві (Логічний, Цілий, Реальний, Рядок) | (3) |
hgrid | Ознака використання жорсткої сітки у буфері архіву | (1) |
hres | Ознака використання часу високої роздільної здатності (мкс) у буфері архіву | (1) |
reserve | Резерв | 14 |
term | Символ закінчення заголовку архіву (0x55) | 1 |
Роз'яснення механізму послідовної упаковки приведено на рис. 7. Як можна бачити з рисунку ознака упаковки містить довжину (нефіксовані типи) або ознаку упаковки (фіксовані типи) окремо взятого значення. Це означає, що для отримання зміщення потрібного значення необхідно скласти довжини всіх попередньо дієвих значень. Виконання цієї операції кожний раз та для кожного значення є дуже накладною операцією. Тому було запроваджено механізм кешування зміщень значень. Механізм кешує зміщення значень через визначену їх кількість, а також кешує зміщення останнього значення до якого здійснювався доступ (окремо на читання та запис).
Зміни значень всередині існуючого архіву також передбачено. Однак, враховуючи необхідність виконання зсуву хвоста архіву, рекомендується виконувати цю операцію якомога рідше та якомога більшими блоками.
При проектуванні та реалізації цього модуля було закладено механізми підвищення ефективності процесу архівування.
Першим механізмом є механізм блокового(покадрового або транзакційного) розташування даних у файли архівів значень. Такий механізм дозволяє досягти максимальної швидкості архівування, а відповідно і дозволяє одночасно архівувати більше потоків даних. Досвід практичного застосування показав, що система K8-3000 із звичайним IDE жорстким диском спроможна архівувати до 300000 потоків даних із періодичністю 1 секунда або, система K5-400 з IDE диском (2.5") спроможна архівувати до 100 параметрів з періодичністю 1 мілісекунда.
Другим механізмом є упаковка як поточних значень, так і застарілих файлів архівів для оптимізації використаного дискового простору. Реалізовано два механізми упаковки: механізм послідовної упаковки (архіви значень) та механізм дотискування архівів стандартним пакувальником (gzip). Цей підхід дозволив досягти високої продуктивності у процесі архівування поточних даних з ефективним механізмом послідовного стиснення. Та дотискання стандартним пакувальником застарілих архівів завершує загальну картину компактного зберігання великих масивів даних. Статистика практичного застосування в умовах реального зашумленого сигналу(найгірша ситуація) показала, що ступінь послідовної упаковки склала 10%, а ступінь повної упаковки склала 71%.