Потоплення береговим ракетним комплексом «Нептун» крейсеру «Москва», постійна “піджарка” Криму морськими дронами, ураження російського корабля «Оленегорский горняк» – лише деякі сумісні операції Сил Оборони України в Чорному морі, які є беззаперечно успішними. В чому їх особливості? Як вдалося зробити ефективне ураження по ворожим кораблям з першого разу? В чому секрет їх ефективності?
Майор Єлизавета Бойко та старший лейтенант Тарас Шевчук, представники Центру інновацій та розвитку оборонних технологій Міністерства оборони, під час концеренції Fwdays React + TS 2023 розповіли про вітчизняні цифрові рішення для армії, які допомагають в реалізації складних військових операцій із застосуванням безпілотних систем. Це продукти та сервіси для управлінням бойовим простором та ситуаційної обізнаності, зібрані під одним брендом – DELTA. Саме DELTA зробила можливими виконання сумісних операцій в Україні.
Творці DELTA рідко виступають на публіці або дають інтерв’ю, адже бойові системи та їх розробка “люблять тишу”. Ми зібрали найважливіше з їх виступу в одній статті.
Що особливого в операціях із застосуванням морських дронів? Морські операції України виконувалися у взаємодії різних підрозділів, які до цього могли навіть не співпрацювати один з одним.
Усім їм треба знати, де знаходиться ворог, де знаходяться свої сили, що є в наявності і де саме знаходиться ціль, до того ж ще й у постійному русі. Це неможливо забезпечити без цифрових технологій та сучасних протоколів обміну даними, синергія яких створює ситуаційну обізнаність: знання про ворога, його маневри, наміри, сили та засоби. Важливим аспектом також є знання про свої сили, кількість наявного озброєння, рельєф місцевості та навіть погоду. Ситуаційна обізнаність залежить від повноти отриманих даних, їх достовірності, актуальності і дозволяє краще планувати свої дії та швидше ухвалювати рішення про ураження.
Сьогодні DELTA – це єдина система для ситуаційної обізнаності, яка є власною розробкою України та є взаємосумісною з аналогічними системами НАТО. Різними продуктами DELTA користуються тисячі військових по всій лінії фронту, задіяних у відсічі агресора.
Еволюція Центру інновацій
Команда Центру інновацій має доволі довгу історію. Підрозділ був створений з волонтерів – учасників Революції Гідності, Автомайдану, які стали добровольцями у перших хвилях мобілізації.
У 2016 команда Центру інновацій познайомилася з NATO-Ukraine C4 Trust Fund – фондом, що активно допомагає Україні з перших днів російського вторгнення та залучає фахових спеціалістів, які розробляють інтеграційні стандарти у НАТО.
З 2017 команда розробників системи DELTA є постійним учасником ключових для розробників заходів НАТО: хакатонів, де виборювали перші місця, офіційних тестуваннях на взаємосумісність з НАТО, профільних конференцій тощо.
На 2023 рік DELTA була успішно протестована з системами більш, ніж 10 країнами-членами НАТО, та підтвердила взаємосумісність з 4 стандартами Альянсу. Це означає, що нові іноземні радари та системи, які Україна отримує від союзників – від засобів виявлення дронів до захоплення цілей літаком F-16 – можуть бути інтегровані в єдину систему – DELTA.
Як народилася DELTA?
Розуміння, що Силам Оборони України потрібна власна система ситуаційної обізнаності прийшло у 2015 році, коли волонтери почали купувати на фронт техніку, яка раніше в бойових діях Україною не застосовувалася: стаціонарні камери та дрони. Так з’явилася лінія камер вздовж бойового зіткнення та дані з різних типів коптерів.
Одразу почала накопичуватися величезна кількість інформації, яку потрібно було, по-перше, переглядати вручну, а по-друге – кудись складати, щоб можна було аналізувати її в історичній перспективі. Країни-партнери НАТО давно зрозуміли недоцільність використання для такого виду інформації паперових мап, тому розробляли свої системи ситуаційної обізнаності з 90х років. В Україні такої системи не було. Тому у 2016 році підрозділ, в якому служили програмісти, почав розробляти власну українську систему ситуаційної обізнаності. Перший прототип DELTA почали застосувати в зоні АТО вже у 2016 році.
Сьогодні DELTA - більше, ніж про ситуаційну обізнаність. Це і платформа для стрімінгу відео з будь-якого пристрою, захищений чат, продукти для планування операцій, для розвідки, а також додатки, що дозволяють планувати взаємодію з телефонів та планшетів в режимі офлайн.
Як розвивалася DELTA?
DELTA як команда розробників і DELTA як софт пережили багато трансформацій за 8 років. З системи для збору інформації з сенсорів DELTA перетворилася у систему управління бойовим простором: на землі, у повітрі, на морі та навіть у кіберпросторі.
Основний підхід у створенні продуктів Центру інновацій схожий до підходу Google: дати підрозділу базовий захищений набір сервісів та додатків, який допоможе якісно, вчасно і швидко виконувати бойові задачі.
Команда системи DELTA будує свій беклог на запитах кінцевих користувачів, звідки формуються пріоритети розробки. Оскільки запити на новий функціонал зʼявляються кожен день, швидкість розробки та впровадження нових фіч є пріоритетом.
На момент проведення конференції Fwdays React + TS 2023 був 605 день повномасштабного вторгнення. За цей час команда Центру інновацій встигла випустити більше 150 релізів DELTA Monitor - флагманського продукту екосистеми. Сьогодні команда прагне робити 3 стабільних релізи продукту на тиждень, а від початку розробки (інтеграції) нового продукту в екосистемі до його повномасштабного виходу в середньому проходить 3 місяці. Також в DELTA активно використовують фіче-прапори у повсякденній розробці, забезпечуючи користувачів системи гарно протестованим і відшліфованим функціоналом. Такий підхід цінується та знаходить позитивний відгук у користувачів системи DELTA:
Однак при такій динаміці самі розробники приречені на боротьбу зі складністю проекту. Професійний спільноті знайомий так званий «закон спадної віддачі», коли збільшення ресурсів на розробку фіч не призводить до пропорційного збільшення кількості фіч, але призводить до значного збільшення складності коду і кількості багів у проекті. Цей закон є прихованим супротивником екосистеми DELTA. Основним інструментом для боротьби з ним є правильно закладена архітектура на рівні проекту та інфраструктура на міжпроектному рівні.
Особливості інфраструктури фронтенду DELTA
DELTA - це набір цільових SPA-додатків, кожен з яких має свою складну доменну область.
Micro frontends
Більшість аплікейшнів мають спільний функціонал, представлений компонентами на UI. Це може бути, наприклад, хедер аплікейшна, де розташовані кабінет користувача, переключення локалізації, тощо. Ми хочемо, щоб життєвий цикл таких компонент існував окремо від цільових застосунків. Оновлення таких компонент має відбуватись в runtime-режимі для основних проектів, і при цьому не блокувати їх розробку. Для реалізації даного мікрофронтенду ми використовуємо Webpack Module Federation. Це дає можливість винести спільний функціонал в окремий SPA та підключати його до host-проектів у якості remote container.
Monorepo
Також використовується монорепа на базі NPM Workspaces для пакетів, які імпортуються по всій екосистемі DELTA. Набір пакетів монорепи включає як звичайний сет іконок, який транспілиться з SVG в JSX, так і повноцінний UI Kit на базі React-компонент.
З розвитком дизайн-системи потрібно було “подружити” legacy компоненти, які вже себе зарекомендували в проекті, з новими елементами, які постійно зʼявляються в процесі розробки нових фіч. Ми вирішили розробляти власний UI Kit і дотримуються певного воркфлоу в його розробці. Спочатку відбувається комунікація з дизайн-командою і компоненти структуруються на рівні Figma. У випадку складних компонент ми пишемо технічний дизайн для API компоненти, який згодом віддається на міжкомандне ревʼю. Тільки після цих підготовчих кроків починається імплементація комопоненти. Також ми використовуємо Storybook як для візуального преставлення, так і для ведення документації і покриття тестами компонент.
SSR
В екосистемі DELTA є сторінки, які не належать до SPA, але для яких важлива швидкість загрузки і інколи навіть SEO-метрики. Наразі це звичайні темплейти, згенеровані бекенд-шаблонізаторами і збагачені Vanilla JS. Але команда розробників рухається в бік Next.js щоб мати всі продукти DELTA в одній React-екосистемі.
Архітектури фронтенд проектів
Для фронтенду системи DELTA використовується багатошарова архітектура: проекти розділяються на зони відповідальності, яким ставляться у відповідність архітектурні шари і задаються правила інтеграції шарів між собою. Для того щоб пояснити необхідність даного підходу, варто ознайомитись з нефункціональними вимогами, які стоять перед нами при розрозбці застосунків.
У DELTA використовується широкий спектр термінології та симвології НАТО. Це робить її доменну область доволі складною, а проекти – високонавантаженими. Для прикладу, по вебсокету можуть приходити десятки тисяч сутностей. В кожної сутності може бути власна структура та поведінка, яку необхідно враховувати при розробці.
Також, звичайним кейсом для юзера є робота із застосунком, де одночасно відображаються як React-елементи, так і карта, відмальована сторонньою бібліотекою. При зміні стану панелі, написаній на React, ми повинні миттєво змінювати оперативну обстановку на карті, і навпаки.
Щоб пояснити як вибрана нами архітектура задовільняє наші нефункціональні вимоги, потрібно описати зону відповідальності для кожного архітектурного шару.
- Шар Models є свого роду копією шару Entities із парадигми Clean architecture. Бізнес-логіка є найвищим рівнем абстракції. Тут описуються структури даних домену і їх поведінка без привʼязки до технологій.
- На рівні шару Services описана комунікація із сторонніми вендорами, backend-ендпоінтами чи Browser API. Всі ці речі ізольовані у межах TS сутностей та описані інтерфейсами. Це дає можливість легкої міграції чи оновлення технології, яка використвовується для сервіса, не переписуючи при цьому всієї кодової бази.
- Шар UseCases. На абстрактному рівні юз-кейс є представленням певного функціоналу у системі. На рівні імплементації – це клас, який використовує сервіси, обробляє сайд-ефекти і зберігає дані в моделях, відповідно до правил доменної області.
- Шар ViewModels є першим представником UI частини проекту. Він нічого “не знає” про доменну область. На цьому рівні імплементується складний функціонал на UI, який необхідно покрити юніт-тестами, але не привʼязувати до UI-бібліотек.
- Останній шар – View layer. У нашій інтерпретації – це царство React та всієї React-екосистеми.
Web технології
Typescript
З переходом на Typescript, у наших проектах зʼявилась більша впевненість щодо використання кращих практик принципів SOLID. Для прикладу, ми використвуємо TS interface як основний контракт при композиції сутностей, що є проявом принципу Dependency Inversion, і саме Typescript надає нам можливість отримати якісний абстрактний та обʼєктно-орієнтований код.
MobX
Розробники Центру інновацій беруть краще з усіх світів програмування: не тільки ООП, але і ФРП. Ми використовуємо MobX для реактивного реагування на зміну стейта. Для цього нам потрібна структура даних, яка найбільш поширена під назвою «атом». Ми не можемо використовувати вже готові імплементації атомів з таких бібліотек як Jotai чи Recoil, оскільки вони не можуть існувати за межами React-екосистеми, а ми маємо працювати з атомами і на шарах, які нічого не знають про React. Отже, з поширених рішень у нас є два варіанти: RxJS BehaviorSubject I MobX Observable. Оскільки у наших проектах нема складних кейсів по роботі з потоками івентів, для простоти обрався другий варіант.
В результаті, ми можемо “слухати” зміну стану на будь-якому рівні. На рівні доменної області – за допомогою класичних MobX реакцій, а на рівні React - використовується mobx-react, який завертає компоненту в observer HOC і при зміні стану обсьорвбла - перерендерює її.
XState
Xstate – імплементація стейт-машини для Javascript. Хтось використовує його як повноцінний стейт-менеджер, але в екосистемі продуктів DELTA для нього є трохи інші задачі.
Для початку потрібно розібрати термінологію поняття Dimension, який ми штучно вводимо в розробку застосунків. В інтерпретації розробників DELTA, Dimension – це глобальний стейт аплікейшна, який описує, де саме зараз перебуває юзер на UI. У нього можуть бути свої вкладеності, і цим самим він дуже зручно лягає на поняття стану у стейт-машині. Але насправді важливо є не те, де саме зараз перебуває юзер, а те, що робити, коли він попав в цей діменшн і коли він залишить його.
В класичному випадку це можна було б реалізувати на рівні useEffect в компоненті React і реагувати на маунт і анмаунт відповідних компонент. Але ми не хочемо завʼязувати View Layer на доменну область, перетворюючи React в інструмент архітектури. Також у діменшна і React-компоненти нема відповідності “один до одного”, тому даний варіант нам не підходить.
Для того, щоб реалізувати відповідний технічний виклик, використовуються XState actions – entry та exit. Це дозволяє декларативно описувати хендлери стейту і трекати зміну діменшна на доменному рівні.
Tech orcherstra: each instrument plays a unique tune
Широкий арсенал технологій при неочевидних архітектурних рішеннях не є формулою успіху для будь-якого проекту, тому вибір технології має відбуватися з усвідомленням того, яку проблему необхідно вирішити. В нашому випадку, ми вирішуємо проблему високої швидкості feature delivery для наших користувачів, задовільняючи при цьому функціональні та нефункціональні вимоги системи.
Процеси розробки
Розробники DELTA керуються класичним Agile та PPT-фреймоворком. Це значає, що паралельно з програмістами, які будують IT-продукт, його інші відділи досліджують, як він використовується і випрацьовують найкращі стратегії по його застосуванню, засновані на сучасних підходах до ведення бойових дій.
Новий функціонал розробляється лише на запит користувачів, про що дбають підрозділи BA та дизайнерів – вони докладно аналізують кожен запит, його терміновість та весь життєвий цикл першої версії і подальших покращень.
Також DELTA має 2 лінії технічної підтримки для цілодобової допомаги користувачам. Цей же підрозділ постійно влаштовує віддалені та офлайн навчання для нових користувачів та під запит підрозділів.
Accessibility, safety and reusability – основні принципи, якими розробники системи DELTA керуються у щоденній роботі.
DELTA є хмарним рішенням, завдяки чому досягається найбільше покриття користувачів навіть у віддалених і гарячих точках фронту. Це спрощує роботу військових, але водночас ускладнює механізми кіберзахисту системи. DELTA використовує безпекову модель Zero Trust і має окрему когорту сек’юріті спеціалістів, які цілодобово слідкують та покращують механізми захисту системи а також - користувачів.
DELTA також є інтеграційною платформою і у 80% випадках працює на найбільш сучасних протоколах інтеграції і взаємодії, що використовують західні країни. З початком повномасштабної війни розобники DELTA відпрацювали підхід мульти-доменних операцій: військові різних видів та родів військ мали можливість планувати та проводити операції в єдиній системі та у взаємодії, чим досягалася максимальна ефективність.
Також DELTA іноді використовує опен-сорс рішення, які дозволяють створювати дійсно унікальні рішення, а не придумували власні “велосипеди”.
Що робить є українські бойові системи достатньо гнучкими та адаптивними?
Команда Центру інновацій використовує концепт Bring your own device у поєднанні з Mobile Device Management підходом. Таким чином DELTA не змушує своїх юзерів купувати дорогі спеціалізовані пристрої, водночас, має можливість відділено керувати робочим профілем користувача у випадку втрати девайсу.
В DELTA підключені різні радари, сенсори, трекери, супутникові дані, які надходять у систему у вигляді фотографій або об’єктів на цифровій мапі і оновлюються в режимі реального часу без ручної роботи користувача.
Розробники також намагаються зменшити та автоматизувати рутинну роботу військового інструментами штучного інтелекту, наприклад, сервісом розпізнавання відео з дронів та відображенням результатів на мапі.