Геоінформаційні підсистеми АСУ Збройниз Сил України як інструмент інтероперабельності інформаційно-аналітичних систем військового призначення

Постановка проблеми

На сьогодні в Збройних Силах України (ЗСУ) впроваджено ряд інформаційно-аналітичних систем (ІАС), що вирішують задачі автоматизації процесів мобілізаційного розгортання, оборонного планування, логістичного, кадрового, фінансового забезпечення, і всі вони мають бути інтегровані в ЄАСУ. Інформація у цих ІАС обробляється на всіх рівнях управління згідно з правилами й алгоритмами, розробленими у цих системах. У процесі планування застосування військ (сил) бере участь певна кількість осіб, відповідальних за окремі напрями забезпечення. Зрозуміло, що вимоги до представлення інформації для виконання завдань окремого виду діяльності різні. У цій ситуації від геоінформаційного забезпечення вимагається можливість створювати потрібне інформаційне оточення для кожної окремої посадової особи, не втративши при цьому властивостей системи управління щодо узгодженості та синхронізації всіх її елементів. Реалізація такої вимоги досягається використанням єдиного ядра геоінформаційного забезпечення, яке надає розробникам програмного забезпечення та користувачам базові геоінформаційні сервіси та інструментарій для їхнього спільного використання під час виконання спеціалізованих завдань. При цьому зазначене ядро має діяти в просторово-розподіленому середовищі, бути захищеним від зовнішнього втручання і бути максимально доступним для внутрішніх користувачів відповідно до установлених розподілом повноважень.

Аналіз останніх досліджень і публікацій

Аналіз сучасної зарубіжної та вітчизняної літератури, інтернет-ресурсів на тему формування вимог і впровадження геоінформаційної підсистеми АСУ ЗСУ свідчить про те, що ця тема досить актуальна, а процес впровадження перспективних інформаційних технологій у сферу військового управління потребує подальшого вдосконалення та розвитку. Тему використання геоінформаційних технологій у системі військового управління досліджували у своїх роботах М. Голобородько, В. Федорієнко, Ю. Кірпічніков [1, 2]; створення географічної інформаційної системи в тактичній ланці управління військами (силами) - В. Тарасов, О. Чорнокнижний [3]; інтеграція новітніх ГІС в існуючі інформаційні системи військового призначення - О. Зайцев, Ю. Новохатній, М. Попов [4] та ряд інших авторів. Проблематика забезпечення здатності ГІС ЄАСУ ЗСУ до функціональної та інформаційної взаємодії в середовищі інформаційних систем знайшла своє продовження у ряді науково-дослідних робіт, які виконувалися протягом 2019-2020 років у Військовому інституті Київського національного університету імені Тараса Шевченка.

Мета статті

Актуальність та необхідність створення, впровадження геоінформаційних систем військового призначення як складової інформаційного забезпечення ЄАСУ ЗСУ зумовлена загальним підвищенням вимог військ (сил) до оперативності, повноти та якості інформаційного забезпечення процесів управління. У цьому дослідженні геоінформаційна підсистема ЄАСУ ЗСУ розглядається як інструмент забезпечення інтероперабельності з існуючими у ЗСУ інформаційно-аналітичними системами та новими, що плануються до розгортання, з використанням різнорідних технічних та програмних засобів.

Виклад основного матеріалу дослідження

За визначенням [4], консолідація (інтероперабельність) вимагає об'єднання інформації з різних джерел, що має різне походження, різну структуру і, можливо, різне місцезнаходження. Тому ключовим моментом для консолідації є застосування деяких стандартів в описі інформації, в її передачі, в організації її обробки. Щоб не обмежувати різноманітність джерел інформації і засобів її обробки, ці стандарти мають бути відкритими. Використання відкритих стандартів дає можливість будь-якому виробнику даних зробити підтримуване ним джерело інформації доступним для отримання з нього даних будь-яким (авторизованим) користувачем.

З іншого боку, користувач даних може обробляти їх тим способом, який виявиться найбільш прийнятним для вирішення його завдань. Відкриті стандарти є тією платформою, на якій можлива чесна конкуренція і взаємодія програмних продуктів від різних виробників, що знову ж таки дає користувачеві можливість вибирати кращі з пропозицій і конфігурувати свою систему обробки інформації з компонентів, що якнайкраще відповідають його завданням. Інтеграції корпоративних застосувань Enterprise Application Integration (EAI) - це складна і багатогранна технологія, яка охоплює всі рівні корпоративної системи - її архітектуру, апаратне і програмне забезпечення та процеси. Основне призначення методології і технології EAI полягає в побудові якісно нових інформаційних систем, що мають такі можливості:

• взаємодія розподілених компонентів інформаційних систем, що забезпечують функціонування військових структур і організацій у реальному масштабі часу;

• об'єднання існуючих застосувань в інтегровану систему з метою збереження інвестицій та успадкованих баз даних;

• забезпечення електронної взаємодії між усіма учасниками функціональних процесів;

• оперативна перебудова інформаційних систем без зупинки їхнього функціонування;

• уніфікація протоколів взаємодії, програмного забезпечення, інформаційних об'єктів за допомогою багаторівневих систем і референтних моделей;

• інтеграція з іншими інформаційними системами і цивільними організаціями.

Існують три підходи до інтеграції інформаційних систем [4]:

1. Інтеграція на рівні даних - додатки працюють незалежно один від одного, кожний використовує свій набір даних. У разі потреби здійснюється обмін даними між ними. При цьому, якщо обмін даними здійснюється шляхом виклику сервісів або відправки/отримання повідомлень, то як середовище для обміну можна використати сервісну шину ЗСУ - Enterprise Service Bus (ESB). Якщо ж обмін даними здійснюється в основному між базами даних, які використовуються тим або іншим додатком, то можна використати рішення класу Extract Transform Load (ETL). При цьому деякі реалізації ETL, наприклад, Oracle Data Integration (ODI), можуть використати як джерела і приймачі даних веб-сервіси і системи класу Message Oriented Middleware (MOM).

Системи інтеграції даних можуть забезпечувати їхню взаємодію на фізичному, логічному і семантичному рівнях. Інтеграція даних на фізичному рівні з теоретичної точки зору є найбільш простим завданням і зводиться до конверсії даних з різних джерел у необхідний єдиний формат їхнього фізичного представлення. Інтеграція даних на логічному рівні передбачає можливість доступу до даних, що містяться у різних джерелах, у межах єдиної глобальної схеми, яка описує їхнє спільне представлення з урахуванням структурних і, можливо, поведінкових (при використанні об'єктних моделей) властивостей даних. Семантичні властивості даних при цьому не враховуються. Підтримку єдиного представлення даних з урахуванням їхніх семантичних властивостей у контексті єдиної онтології предметної області забезпечує інтеграція даних на семантичному рівні.

Процесу інтеграції перешкоджає неоднорідність джерел даних відповідно до рівня інтеграції. Зокрема, при інтеграції на фізичному рівні в джерелах даних можуть використовуватися різні формати файлів. На логічному рівні інтеграції може спостерігатись неоднорідність використовуваних моделей даних для різних джерел або різнитися схеми даних, хоча використовується одна і та сама модель. Одні джерела можуть бути вебсайтами, а інші - об'єктними базами даних тощо. При інтеграції на семантичному рівні різним джерелам даних можуть відповідати різні онтології. Наприклад, можливий випадок, коли кожне з джерел представляє інформаційні ресурси, що моделюють деякий фрагмент предметної області, якому відповідає своя понятійна система, і ці фрагменти перетинаються.

2. Інтеграція на рівні бізнес-процесів - додатки застосовують сервіси, що є інтерфейсами до бізнес-логіки цих додатків. Взаємодія між додатками реалізована у межах бізнес-процесу, на окремих кроках якого здійснюється виклик того або іншого сервісу. Реалізується цей підхід за допомогою сервісної шини ЗСУ (ESB), яка займається віртуалізацією сервісів, що надаються додатками, і рішень класу Business Process Management System (BPMS), зазвичай заснованих на використанні мов BPEL або BPMN, що реалізують логіку процесу.

3. Інтеграція на рівні композитних додатків. Логіка окремого додатку будується шляхом виклику сервісів, що надаються як цим додатком, так й іншими системами. Таким чином, на одному етапі процесу можуть взаємодіяти декілька сервісів, тоді як при інтеграції на рівні бізнес-процесів на одному кроці процесу застосовується один сервіс. Реалізація композитних додатків здійснюється за допомогою використання технологій Java Business Integration (JBI, JSR 208) або Service Component Architecture (SCA). Як SCA-контейнери можна використати Oracle Web Logic, Oracle SOA Suite або Apache Tuscany.

В основі усіх зазначених інтеграційних підходів лежить інтеграція даних. Інтеграція даних є основою, від якої залежить успішність взаємодії на всіх інших рівнях інформаційної системи. Основними методами інтеграції корпоративних сховищ даних є консолідація, федералізація і поширення. При використанні методу консолідації дані збираються з декількох первинних систем та інтегруються в одне постійне сховище. Процес заповнення сховища складається з трьох фаз - вибір, перетворення, завантаження (ETL). У багатьох випадках саме ETL розуміють під терміном "інтеграція даних". Ще одна поширена технологія консолідації даних - управління змістом корпорації (Enterprise Content Management, скор. ECM). Більшість рішень ECM спрямована на консолідацію та управління такими неструктурованими даними, як: документи, звіти і web-сторінки.

Консолідація - однонапрямлений процес, тобто дані з декількох джерел зливаються у сховище, але не поширюються з нього назад в розподілену систему. Часто консолідовані дані слугують основою для додатків бізнес-аналітики (Business Intelligence, BI), OLAP-додатків. При використанні цього методу зазвичай існує деяка затримка між моментом оновлення інформації в первинних системах і часом, коли ці зміни з'являються у кінцевому місці зберігання.

У федеративних базах даних (БД) фізичного переміщення даних не відбувається, дані залишаються у власників, доступ до них здійснюється за необхідності (при виконанні запиту). Спочатку федеративні БД припускали створення в кожному з n вузлів (n - 1) фрагментів коду, що дозволяє звертатися до будь-якого іншого вузла. При цьому федеративні БД відділяли від медіаторів. Медіатор - це посередник, що підтримує єдиний, призначений для користувача інтерфейсу, запит на основі глобального представлення даних, що містяться в джерелах, а також підтримку відображення між глобальним і локальним представленнями даних. Призначений для користувача запит, сформульований у термінах єдиного інтерфейсу, розкладається на безліч підзапитів, адресованих до потрібних локальних джерел даних. На основі результатів їхньої обробки синтезується повна відповідь на запит.

Використовуються два різновиди архітектури з посередником - Globalas View і Localas View. Додатки поширення даних здійснюють копіювання даних з одного місця в інше. Ці додатки працюють в оперативному режимі і виконують переміщення даних до місць призначення, тобто залежать від певних подій. Оновлення в первинній системі можуть передаватися в кінцеву систему синхронно або асинхронно. Синхронна передача вимагає, щоб оновлення в обох системах відбувалися під час однієї і тієї ж фізичної транзакції. Незалежно від типу синхронізації, який використовується, метод поширення гарантує доставку даних у систему призначення. Більшість технологій синхронного поширення даних підтримують двосторонній обмін даними між первинними і кінцевими системами. Прикладами технологій, що підтримують поширення даних, є інтеграція корпоративних додатків Enterprise Application Integration (EAI) і тиражування корпоративних даних Enterprise Data Replication, скор. EDR) [2].

4. WEB-інтеграця. Сервісно-орієнтована архітектура SOA (Service Oriented Architecture) успішно використана при інтеграції додатків, застосовується і при інтеграції даних. Дані також залишаються у власників, і навіть місцезнаходження даних невідоме. При запиті відбувається звернення до певних сервісів, які пов'язані з джерелами, де міститься інформація та її конкретна адреса. Інтеграція даних об'єднує інформацію з декількох джерел так, щоб її можна було надати клієнтові у вигляді сервісу. Підхід SOA концентрується насамперед на визначенні і спільному використанні у формі сервісів щодо обмеженої кількості найважливіших бізнесфункцій в ЄАСУ ЗСУ. Отже, сервіс-орієнтовані інтерфейси будуються на обмеженій кількості запитів на необхідну інформацію, яку треба надавати споживачеві.

Практикуються такі підходи до вебінтеграції:

Інтеграція на рівні представлення. Цей рівень дозволяє користувачеві взаємодіяти з додатком. Інтеграція на рівні представлення дає доступ до призначеного для користувача інтерфейсу віддалених додатків.

Інтеграція на рівні функціональності. Ця інтеграція забезпечує прямий доступ до бізнес-логіки додатків. Це досягається безпосередньою взаємодією додатків з API (програмний інтерфейс додатків) або ж взаємодією за допомогою веб-сервісів.

Інтеграція на рівні даних. У цьому випадку передбачається доступ до однієї або декількох баз даних, що використовуються віддаленим додатком.

Комплексна інтеграція. Комерційні рішення вебінтеграції зазвичай містять усі три типи інтеграції. У кожного з перелічених вище методів є свої переваги та недоліки. При використанні методу консолідації можлива деяка затримка між моментом оновлення інформації в первинних системах і часом, коли ці зміни з'являються в кінцевому місці зберігання. А перевагою цього методу є те, що він дозволяє агрегувати (привести у відповідність) дані в процесі передачі інформації в кінцеве сховище. Перевагою федеративного підходу є те, що він забезпечує доступ до необхідних даних і виключає необхідність перенесення інформації з одного сховища в інше. Недоліком цього методу є витрати на продуктивність і доступ до численних сховищ даних. Великою перевагою методу поширення є те, що він може бути використаний для переміщення даних у режимі реального часу або близькому до нього. Інші переваги містять гарантовану доставку даних і двостороннє поширення даних.

Велика кількість систем, стандартів і технологій призводить до того, що ефективно пов'язати різні джерела даних в одну систему не вдається. Навітьтакі, на перший погляд, однорідні джерела, як системи управління базами даних, застосовують мови запитів і формати представлення інформації, які рідко повністю сумісні між собою. Як наслідок проєкти інтеграції в таких умовах вимагають великих зусиль: вимагається вглиблюватися в деталі різних баз даних, протоколів, операційних систем тощо. У результаті інтеграція декількох додатків або систем реалізується за схемою, представленою на рис. 1.

Рис. 1 Реалізація інтеграції декількох додатків