KillTech project: through innovation to a winning capability [ukr]

Дякую. Всім привіт. Я думаю, ви вже здогадалися, що мене звати Ліза, а це мій колега Тарас. І сьогодні ми дійсно прийшли до вас доволі незвичайною темою. І мені одразу хочеться задати вам питання. Я сподіваюся, що ви зможете дати мені на нього відповідь. Скажіть, будь ласка, чи знаєте ви, якими IT-рішеннями користуються наші військові щоденно для відбиття російської збройної агресії? Я буду вдячна, якщо ви зможете мені їх поназивати. Кропива, чудова. Вежа. Що ще? Ви обізнані. Що ще є? Слухайте, ви багато чого знаєте.

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

І як вже правильно зазначили в залі, сьогодні ми будемо розповідати вам про систему ситуаційної обізнаності Дельта. І навіть не просто систему, а про екосистему продуктів, які виробляються військовими для військових. І отже, хто ми є? Я повторюю, я Ліза. Це Тарас з Центру Інновацій та розвитку оборонних технологій Міністерства оборони України. Насправді, ми є військові. І одночасно... І одночасно інженерами-програмістами. В нас дуже різний життєвий досвід. Оскільки я являюся професійною військовою, як ви вже бачите, 8 років досвіду. А Тарас мобілізований з цивільного сектору. Але зараз ми працюємо над одним і тим самим проєктом, що досить активно розвивається. Обростає новим функціоналом та новими продуктами всередині однієї екосистеми.

І сьогодні я вас проведу по історії розвитку нашого продукту. А Тарас дозволить заглибитися в нашу потойбічну кухню-фронтенду, щоб ви знали, чим користуються військові, що вони розробляють, і що воно взагалі там всередині таке. Без таких сильних деталей. Я одразу вас попереджую. І мені хочеться, щоб ви приєдналися. Відповівши на питання, чи можете ви згадати, які найгучніші операції виконували Збройні Сили України під час повномасштабного вторгнення? Чудово. Що-що? Дякую. Що ще? Дякую. Що ще? Так, і я вам виведу на слайд, мабуть, навіть не 10% операцій, в яких ми приймали. Але вони є доволі однотипними, але показовими.

Отже, в нас ураження береговим ракетним комплексом «Нентун» крейсеру «Москва». Далі кастомний дрон Служби безпеки України, який впевнено нас крокує до Кримського мосту 17 липня 2023 року. Та ураження чергового судна «Олєнігорськ». Чим же вони були такі круті, окрім того, що всі досягли мети? Насправді, вони всі виконувалися при кооперації різних підрозділів, які до цього могли навіть не співпрацювати один з одним. Наприклад, ВМС та СБУ, ВМС та ГУР, СБУ та суміжні підрозділи, тощо. Чому вийшло зробити таке ефективне ураження, власне, з першого разу? Тому що вони всі знали. Де знаходиться ворог, де знаходяться свої сили, що є в наявності, і де саме в нас ціль.

І я думаю, що ви зауважили, що дві з трьох цих цілей, вони були рухомі. Тобто вони точно знали, що потрібно уразити. Цього ніколи би не відбулося, якби військові не використовували технології. А саме, можемо подякувати цьому багатьом системам, в тому числі системі, ситуаційної обізнаності Дельта, яка використовувалась в цих трьох операціях, що виведені на складі, а також в багатьох інших. І в мене до вас, ну, я не буду вас запитувати це питання, тому що ви, скоріше, це не знаєте, але як маленька совкова армія, яка ще не повністю впровадила стандарти НАТО, може перемогти велику совкову армію? Я думаю, що ви тут здогадуєтеся, що нам треба багато факторів, але два найосновніші, це технології та сучасне озброєння. І, як ви вже зауважили на попередньому слайді, нам завжди треба знати, де знаходиться ворог, де знаходяться свої сили, що відбувається навколо і тому подібне.

Для того, щоб… Така інформація в совокупності, вона називається ситуаційною обізнаністю. І, власне, ситуаційна обізнаність залежить від повноти даних, їх достовірності, актуальності і швидкості розповсюдження між усіма учасниками, які потребують цю інформацію. Сьогодні Дельта – це єдина система ситуаційної обізнаності, яка розроблена в Україні і взаємосумісна з найсучаснішими стандартами НАТО. Це означає, що як тільки нове озброєння приходить в Україну, ми можемо якомога швидше це інтегрувати в єдиний світ, а також в структурну систему для того, щоб військовослужбовці різних рівнів використовували те, що їм потрібно. Наша система працює через браузер. Власне, ми тут. І це в нас головна сторінка системи, де ви можете побачити, що ми складаємося з цілої екосистеми продуктів. І кожен військовослужбовець може використовувати те, що йому буде потрібно.

Давайте трошечки про історію. А як же ж так вийшло, що в нас є в Україні військові програмісти? Все почалося з 2015 року, коли волонтери приєдналися до відбиття збройної агресії під час перших днів навіть не повномасштабного, а першого взагалі цього російського вторгнення. І, власне, тоді створився унікальний підрозділ, тому що він був створений на 80% з програмістів з різним життєвим досвідом. Вони змогли закласти в цей підрозділ правильну культуру і, по суті, ми зараз працюємо як маленька продуктова компанія. Окрім цього, у 2016 році цей центр познайомився з представниками CFO NATO Trust Fund, фондом, що активно залучає експертів, що працюють в тому числі над розробкою стандартів взаємосумісності НАТО. Синім ви бачите івенти, на яких залучався центр. І я з гордістю можу сказати, що у 2017 році представники нашого центру приймали участь в хакатоні, який відбувався в НАТО. І, власне, в тому році ми вперше як країна були залучені до таких типів івентів і в тому році ми зайняли два перших місця.

Ми також декілька разів повторювали свій успіх на подібних хакатонах, а також нас активно запрошували на профільні конференції, де ми могли ділитися своїм досвідом з країнами-партнерами НАТО з приводу розробки бойових систем. Ми також приймаємо участь в тестуванні нашої системи на взаємосумісність, яка відбувається кожен рік. І ми там активно приймаємо участь з 2018 року, для того, щоб не бути голослівними, що це дійсно ми маємо підтвердження, що ми є взаємосумісними з НАТО. Він був в принципі для нашої країни і нашої системи безпрецедентним з точки зору підтримки нас партнерами, оскільки в цьому році наша країна змогла протестувати систему з 10 різними країнами на 4 стандарти взаємосумісності.

Ми працюємо з різними видами і родами сил оборони і маємо досить широке охоплення користувачів, зрозуміло, не 100%. 100% охоплення нам насправді і не потрібно, оскільки маючи хоча б 10 користувачів в кожному маленькому підрозділі, можна налаштувати необхідну взаємодію між ними і досягти того ефективного ураження, яке ми бачили з вами на перших слайдах. А на що ж нам систему ситуаційного бізнесу спитаєте ви? Насправді це розуміння воно з'явилося ще в 2015 році, коли волонтери так само приєдналися до відбиття збройної агресії і закуповували, як і зараз, купу новітньої техніки, яка до цього не застосовувалася. Вони тоді почали з камер стаціонарного спостереження, ну і як зараз відбувається з дронів. Вони навезли купу техніки і спробували перекрити між собою всю лінію фронту, яка в той момент становила Донецьку область, Луганську область і Крим.

Зрозуміло, що почала одразу накопичуватися величезна кількість інформації, наносити руками, по-друге, якось аналізувати, а по-третє, розповсюджувати між підрозділями, власне, між всіма, кому ця інформація була потрібна. Оскільки, якщо ти це маєш, інформацію в одному місці, зрозуміло, ти з цього, в принципі, нічого не отримаєш. Країни НАТО цією проблемою займаються з 90-х років. Власне, кожна країна має свою систему ситуаційного бізнесу, яка на даний момент вже, в принципі, будується, ну якщо ви порахуєте, десь 30 років. Наша країна такої системи не мала, і завдяки залученню експертів 2016-го року SIFO NATO Trust Fund нам допомогли з цією ідеєю. Сказали, Україна, вас, ви от не можна більше воювати паперовими мапами. Вам треба своя система ситуаційного бізнесу. В той момент наша країна вирішила не закуповувати нічого чужого, а розробляти свою. І, власне, для цього знадобився наш підрозділ, який містив програмістів. Нам дали задачу будувати свою систему ситуаційного бізнесу.

На сьогоднішній день ми вже з системи ситуаційного бізнесу виросли до екосистеми продуктів. І в нас, окрім цього, є ще стрімінгова платформа, захищений чат, інструменти для планування, а також офлайн-застосунки. І більшість з них з'явилася саме під час повномасштабного вторгнення. Розуміння, як працює наша екосистема, давайте ми подивимося на таку аналогію. Як Google надає вам всі інструменти для повсякденної роботи, і, власне, ви там маєте в одному кабінеті все, що вам необхідно, так само і Delta надає вам всі необхідні інструменти для вашої бойової роботи для різних типів користувачів, але для досягнення єдиної мети – для перемоги. А далі, щоб вам було більш цікаво, ми спробуємо з вами поділитися технічними інсайдами. А що ж ми все-таки застосовуємо? Наших веб-застосунках. І для цього я передаю слово Тарасу.

Дякую, Ліза. Як уже сказала Ліза, враховуючи специфіку нашої роботи, я поверхнево пройдуся по наших технологіях без жодного рядку коду, але постараюся детально пояснювати доцільність, чому ми використовуємо той чи інший підхід. Але, перш за все, перед цим я хочу сформулювати проблематику, яка стоїть перед нами в плані розвитку і масштабування наших продуктів. Наші користувачі, наші військові, практично кожен день закидують нас реквестами про те, що вони хочуть бачити той чи інший функціонал, який їм потрібен в наших продуктах. Ну і, звичайно, розуміючи, в яких обставинах перебувають наші побратими, ми стараємось ставити в перший пріоритет, не стараємось, ми це робимо, ми ставимо в перший пріоритет саме розвиток фіч в наших продуктах.

При такому підході ми стикаємось із такою проблемою, яка називається закон спадної віддачі. Хто не знайомий з цим явищем, це коли при збільшенні кількості ресурсів настає певний момент часу, після якого вже не відбувається лінійного збільшення кількості фіч, але відбувається нелінійне збільшення кількості дефектів, складності коду, неякісного коду, який починає обростати функціоналом, починає перевикористовуватися, його стає важко рефакторити. Ми вважаємо, що інструментом для вирішення цієї проблеми є правильно закладена архітектура на проектах і міжпроектна інфраструктура, яка буде масштабованою, буде легкопідтримуваною, і, власне, про це я і хочу сьогодні поговорити. Почнемо ми із веб-інфраструктури. Що у нас дано? У нас є набір вузькоспеціалізованих військових доменних single-page applications. Ви вже можете побачити.

Ви можете підмітити зі слайду, що в них багатошарова архітектура. Про неї я поговорю трошки пізніше. Практично всі ці проекти мають якийсь спільний функціонал, який відповідає за спільні компоненти на UI. Ми хочемо, щоб розробка таких спільних компонентів не впливала на розвиток життєвого циклу наших продуктів, щоб зміни в цих компонентах відбувалися в рентайм-режимі в наших основних проектах, і щоб це ніяк не блокувало процес розробки цих проєктів. Як я пам'ятаю, з попередньої презентації пан Віталій сказав, що так робити не можна. Але ми чекаємо його в наших рядах, щоб він нам це змінив. Ми використовуємо Webpack Module Federation для мікрофронтального підходу. Ми весь цей спільний функціонал виносимо в якийсь окремий single-page application. І в якості remote контейнерів їх вже підключаємо до наших host applications.

Є у нас MonoREPA на базі NPM Workspaces. Там ми тримаємо пакети, які ми перевикористовуємо по всій екосистемі Delta. Це може бути як звичайний набір іконок, який там транспілиться із .svg в JSX код, так і повноцінний UI-код, написаний на базі React Component. Власне, про UI-код я хочу трошки детальніше розказати. У нас є випадки. В процесі розвитку дизайн-системи виникла необхідність подружити наші legacy компоненти, які вже себе зарекомендували у нашій Delta, із новими компонентами, які нам дизайнери зробили під час розробки нових фіч. Ми вирішили, що ми будемо писати власний UI-код, але дотримуватись певного workflow при процесі розробки компонент.

Перш за все, ми комунікуємо із дизайн-командою. Вона структурує всі наші компоненти у Figma. Після цього ми пишемо технічний дизайн для API цих компонент, і тільки вже після командного рев'ю, останню ітерацію, ми приступаємо до розробки цієї компоненти. Ще ми використовуємо Storybook не тільки для візуального відображення, а й для ведення документації компонент, а інколи навіть і для тестування цих компонент. Не всі наші проекти є вузькоспеціалізованими single-page applications, але і з цих інших проєктів нам важливо, щоб вони були швидкі, і інколи нам навіть важливо, щоб у них були хороші SEO-метрики. Для імплементації Service-Side-Rendering на таких проєктах ми зараз використовуємо backend-шаблонізатори, які віддають темплейти, який ми збагачуємо Vanilla.js, але ми вже зараз перебуваємо в процесі міграції на Next.js, для того, щоб вся наша Delta жила в одній React-екосистемі.

Добре, це була проста частина. Про архітектуру. Як я вже сказав, ми використовуємо багатошаровий підхід для архітектури. Можливо, не всі стикалися з цим підходом. Багатошарова архітектура — це коли проєкт ділиться на певні технічні зони відповідальності. Кожній з цих зон відповідальності ставиться у відповідності певний архітектурний шар, і задаються правила інтеграції цих шарів між собою. Вже в залежності від заданих правил формується парадигма багатошарової архітектури. І у нас ця парадигма своя. Для того, щоб пояснити, чому вона у нас така, треба сформувати нефункціональні вимоги, які стоять перед нами, щоб ми розуміли, як архітектура їх задовільняє.

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

Ще одним викликом, який стоїть перед нами, є синхронізація UI. Це звичайна ситуація, коли у користувача є користувацька панель, написана на React, відрендерена, і є карта на Canvas, куди бібліотека Map-based малює нашу карту. Користувач може змінювати користувацьку панель, і оперативна обстановка на карті повинна динамічно змінюватися. З іншого боку, зміни в обстановці на карті повинні впливати на стан React-додатка. У нас можуть бути власні рішення для Canvas, де ми обробляємо зображення, і в цих модулях може бути свій стан, який враховує стан всіх його сусідніх модулів UI. Отже, багатошарова архітектура.

Давайте подивимося на кожен шар по черзі та визначимо його зону відповідальності, щоб зрозуміти, як це допомагає виконувати наші нефункціональні вимоги. Найвищим рівнем абстракції в наших проектах є рівень Models. Фактично, це схоже на шар Entities в парадигмі Clean Architecture. Тут ми описуємо бізнес-правила та визначаємо доменні структури даних. Цей рівень нічого не знає про текст, який ми використовуємо в проектах, окрім бібліотек, які нам допомагають працювати зі структурами даних.

Далі йде рівень Services. Він відповідає за комунікацію з певними Enterprise-вендорами, з backend-точками, з браузеровим API, наприклад, Local Storage. Ми не хочемо розподіляти всі ці речі по всьому проекту. Ми їх інкапсулюємо в певні сутності, описуємо їхні інтерфейси. Таким чином, наприклад, при міграції технології нам не потрібно переписувати весь проект. Ми змінюємо виключно сутність, яка відповідає за цей сервіс.

Use Cases. Термінологія, знову ж таки, взята з Clean Architecture. У нашій інтерпретації один Use Case – це один функціонал. На практиці це виглядає як TypeScript Class, який взаємодіє з сервісами, обробляє сайд-ефекти та записує дані в моделі відповідно до його бізнес-правил. Share View Models. Тут вже немає зв'язку з доменною областю. Тут ми зберігаємо складну реалізацію логіки, необхідної для UI. Це дозволяє нам тестувати цю логіку за допомогою юніт-тестів. Наприклад, якщо ми не хочемо зберігати таку логіку на рівні View, ми можемо тримати її в різних хуках React. View в нашій імплементації – це царство React і всієї React-екосистеми. Як бачите, архітектура надає великий акцент на Domain Driven Development.

Щодо технологій, які ми використовуємо для підтримки цієї архітектури: на конференції ми використовуємо React і TypeScript. Також, важливо відзначити TypeScript. Його введення дало нам впевненість в тому, що ми правильно дотримуємося принципів Solid. Про ці принципи я зараз не буду розповідати, оскільки вони, ймовірно, вам відомі. Просто відзначу, що завдяки цим принципам у нас вийшов гарний абстрактний об'єктно-орієнтований код. Без TypeScript, можливо, ми не досягли б такого результату, оскільки, наприклад, нам б не вдалося дотримуватися принципу інверсії залежностей при композиції сутностей.

Ми також використовуємо MobX. Стараємось взяти краще з різних парадигм програмування, як об'єктно-орієнтованого, так і функціонально-реактивного. А для чого нам потрібен MobX? Він необхідний нам для реактивного реагування на зміну стану додатка. Наприклад, в нашій доменній області змінився певний стан, і в об'єкті змінилося яке-сь поле. Ми хочемо зріз цього стану зберегти в Local Storage і відобразити це все на карті, відмалювати це на мапі, буквально зразу, і оновити стан React-додатка. Для цього нам потрібна така структура даних, яка найбільш поширена під назвою Atom. Теж такий відступ. Atom — це... Можливо, хтось не працював з ними. Це об'єкт, який має стан, на який можна підписатись, і при зміні цього стану ти можеш зразу синхронно обробляти цю зміну, не відкладаючи її кудись в Event Loop.

Як я вже казав, що ми робимо великий акцент на Domain Driven Development, то у нас багато логіки на вищих шарах архітектури. Через це... І тут ми також підписуємося на ці атоми. Через це ми не можемо використовувати вже готові імплементації атомів, які є в React екосистемі. Там, наприклад, в Recoil або Jotai. У нас залишається два популярних варіанти. Це RxJS Behavior Subject або MobX Observable. У нас немає складних сценаріїв роботи з потоками подій. Тому немає потреби використовувати таку складну і чудову бібліотеку, як RxJS. Ми використовуємо MobX Observable як спрощену концепцію атома. Тому нам цього цілком достатньо.

Таким чином, ми можемо реагувати на зміну стану вже на доменному рівні завдяки MobX реакціям. А вже на React ми просто обгортаємо компоненту в Observable.hoc. І якщо там Observable, який використовується в цій компоненті, змінюється, компонента перерендерюється. Остання технологія, про яку я хочу сказати, яку ми використовуємо для домену, це XState. Хто знайомий із XState, той знає, що це імплементація стейт-машини в JavaScript. Деякі використовують XState як повноцінний стейт-менеджер, але це не зовсім наш кейс. І щоб пояснити, для чого саме нам потрібен цей XState, давайте я введу певне поняття, яке називається Dimension. Dimension — це не сутність XState. Це наш термін, який ми запозичили з аналітичних систем, таких як Google Analytics. Він означає наступне. Dimension — це стан системи, який вказує, де саме користувач зараз перебуває на UI.

Я не буду глибоко вдаватися в це поняття, просто скажу, що в Dimension можуть бути свої вкладеності. І саме це Dimension дуже зручно лягає на поняття стану в стейт-машині. Нам насправді не так важливо розуміти, де саме перебуває користувач, як описати логіку переходів між станами. І в самій базовій імплементації це можна було б зробити на рівні React, наприклад, в якому-небудь Lifecycle-хуці, на mount, unmount, прописувати цю логіку переходів туди-сюди, але нам цей варіант не підходить. Як я вже казав, ми не хочемо прив'язувати ViewLayer до доменної області. Ну і по-друге, у Dimension може і не бути. Тому React у нас не є єдиним фреймворком UI. Тут нам і допомагає XState. Для того щоб обробити всі переходи між станами, ми можемо використовувати Entry і Exit Actions. Таким чином ми вже декларативно описуємо логіку входу і виходу зі стану об'єкта. І тримаємо цю логіку ще на доменному рівні.

Цим самим її не поширюючи на інші архітектурні шари UI. Як бачите, у нас широкий арсенал технологій при неочевидних архітектурних рішеннях. Ну і звісно, що така комбінація не є формулою успіху для будь-якого проекту. Все-таки вибір технології — це наслідок, усвідомлення того, яку проблему ми хочемо вирішувати. І цією технічною частиною я хотів поділитися нашим власним досвідом того, як ми вирішуємо проблему швидкості постачання функцій для наших користувачів, при цьому дотримуючись функціональних і нефункціональних вимог. Але є також і така річ, як процеси, і про це вам вже розповість Ліза більш детально. Передаю їй слово.

Дякую. Я думаю, що вже у всіх посилилися в головах такі питання. Як же так вийшло, що військові в нас ходять? Ну насправді, я думаю, що наш підрозділ є винятком з правил. Зрозуміло, що, маючи бюрократію, журнали для ведення записів, це неможливо. Але саме те саме правильно закладене в культурі, допомагає нам виростити військові програмні продукти. І власне, я думаю, що ви розумієте, що враховуючи специфіку, деякі військові знання іноді вам потрібні. Зрозуміло, що їх можна набути, але це чудово, коли є фахівці, які можуть з вами цим поділитися. Насправді, ми працюємо за методологією Agile, як і всі. І ми намагаємося дотримуватися PPT-фреймворку, що означає People, Technology, and Processes. Це означає, що ми, як програмісти, будуємо код. Зрозуміло, намагаємося його зробити найкращим і найбільш відтестованим і т.д. Але у нас також є окремі відділи, які, по-перше, намагаються зрозуміти, який саме функціонал зараз потрібний нашим користувачам. Відсортовують його і визначають пріоритет. Тому що, зрозуміло, іноді якийсь функціонал запитує цілий підрозділ, іноді кілька людей просить конкретну функцію. І це різні пріоритети.

У нас є окремі відділи та дизайнерів, які працюють над дорожньою картою випуску нашої функціональності. Тобто ми завжди працюємо над якоюсь першою версією, яка буде максимально швидко відправлена користувачам. А потім також версії з її удосконаленням. Так, щоб на виході ми отримали найкращий функціонал, який можемо поставити перед нашими спільниками. Але, зрозуміло, з урахуванням того, що відбувається в нашій країні, ми випускаємо його якнайшвидше. А потім просто вдосконалюємо. У нас також є дві лінії технічної підтримки. Також всередині підрозділу. І ми намагаємося забезпечити наших користувачів як онлайн, так і офлайн навчанням, якщо вони дуже зайняті. Доступність, використовуваність і безпека. Ось наші основні принципи під час розробки. Наш продукт є хмарним. І це, в принципі, дає свободу нашим користувачам використовувати його з будь-якої точки нашої країни. Але в той же час це накладає на нас певні обмеження з точки зору безпеки. У нас є ціла група спеціалістів із безпеки, які, по-перше, моніторять трафік, що проходить через систему, цілодобово, а по-друге, негайно вживають заходи забезпечення безпеки до того, як щось виявить ворог. Ми також, як я вже зазначила, керуємося стандартами, як військовими, так і професійними, якісними підходами. Ми також відпрацювали те, що ефективна операція — це мультидоменна операція. Ви не можете будувати продукт конкретно для військово-морських сил або повітряних сил і так далі.

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

І в принципі ми намагаємося ще й автоматизувати роботу наших побратимів тим, що деякі речі виносимо на штучний інтелект. Наприклад, це стосується переглядання відео. Зрозуміло, що відео з дронів і з камер спостереження — це рутинна робота. Зрозуміло, що у нас є нейронні мережі, які розпізнають техніку. Ми це об'єднали і таким чином у нас є можливість автоматизовано переглядати відео з дронів, розпізнавати там російську техніку, і наносити її одразу на мапу. Таким чином, позбавивши наших побратимів зайвої роботи, яка їм в принципі та й не потрібна. Сьогодні 605-й день повномасштабного вторгнення. За цей час ми встигли випустити більше 150 релізів нашого флагманського продукту системи ситуаційної об'єднанності Delta Monitor. Ми також змогли вийти на швидкість до 3 км. І Звіми бури Ліза і Тарас з центру інновацій МОУ, я дуже дякую вам за увагу.