Екосистема I-SEE: API, SDK і система плагінів для комплексу боротьби з дронами

💡 Усі статті, обговорення, новини про оборонні технології — в одному місці. Приєднуйтесь до DefTech спільноти!

Вітаємо усіх поціновувачів ІТ технологій в мілітарі сегменті України. Сьогодні трошки поговоримо про розвиток I-SEE і першу спробу переходу з закритого контуру в повноцінну екосистему. Комплекс виявлення, супроводу та ураження БПЛА I-SEE отримав три контури інтеграції — програмний інтерфейс (API), комплект розробника (SDK) і систему модулів, що підключаються (плагіни). Тепер підрозділ, інтегратор або сторонній інженер може під’єднати до ядра I-SEE власне обладнання й програмне забезпечення — і дописати функцію, якої бракує, не чекаючи оновлення від вендора.

Нижче ми докладніше пояснюємо, що саме відкрили, чому ухвалили саме такі архітектурні рішення і що це дає на практиці. Принципово: ми розповідаємо про можливості та інженерну філософію, але не розкриваємо внутрішню «кухню» — алгоритми виявлення, супроводу, фільтрації та розрахунків залишаються нашою закритою частиною.

Від закритого продукту — до платформи I-SEE

I-SEE бачить ціль, веде її та розраховує параметри застосування. Сьогодні комплекс уже успішно працює із сіткострілами; інтеграція таких ефекторів, як турелі та засоби РЕБ, перебуває на етапі активних лабораторних тестувань. У недалекому майбутньому — й автономні дрони-перехоплювачі.

Досі все це працювало як єдине ціле всередині однієї програми. Головна зміна, про яку ми оголошуємо, — архітектурна: I-SEE перетворюється із закритого продукту на відкриту платформу. З’явилися три способи взаємодіяти із системою зовні та розширювати її зсередини:

• API — отримувати дані комплексу в реальному часі в будь-якому зовнішньому ПЗ;
• SDK — готовий інструментарій, щоб зробити це за хвилини, а не за тижні;
• Плагіни — додавати нову функціональність прямо в ядро, не чіпаючи вихідний код.

Принцип, який ми формулюємо прямо:

«I-SEE ядро — це мозок, розширення — на краях».

Виявлення, супровід, розрахунки, вибір цілі, рішення про застосування та захисні механізми залишаються за ядром I-SEE. Усе інше — візуалізація, аналітика, інтеграції, підключення обладнання — виноситься в модулі, що підключаються.

Це не косметика. Закритий монолітний продукт у польових умовах завжди відстає від реальності: кожна нова камера, кожен новий ефектор, кожен новий формат сусіднього комплексу — це чекання релізу вендора. Платформа знімає це обмеження: те, що змінюється часто й залежить від конкретного фронту, виноситься на край, де його може дописати інженер на місці. Те, що визначає бойові якості й безпеку, залишається в ядрі під нашим контролем.

API: дані комплексу — у реальному часі

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

Практичний зміст простий: дані I-SEE можна завести в сторонню систему командного пункту, на тактичну карту, у журнал подій або в суміжний комплекс — без реверс-інжинірингу і «милиць».

Що саме віддає API

Ми віддаємо назовні не «сирий» технічний шум, а готові результати — те, що вже обчислило ядро. Зовнішній розробник не пересвердлює нашу математику; він бере значення з готових повідомлень. Сімейства даних, доступні інтегратору:

1. Обстановка за цілями. Геокоординати цілі, дальність, азимут від півночі, висота, швидкість, кут місця та повний вектор руху — усе, чого достатньо для відображення на карті та для випереджального наведення на стороні інтегратора.
2. Якість і достовірність даних. Разом із координатами ми віддаємо оцінку невизначеності та показники якості супроводу. Це принципово важливо: зовнішня система має знати не лише «де ціль», а й «наскільки можна довіряти цьому значенню прямо зараз». Без цього коректне власне прогнозування неможливе.
3. Мультикамерна картина. Якщо ціль бачать кілька сенсорів, інтегратор отримує узгоджений (об’єднаний) результат і склад джерел — а не суперечливі дублікати з різних камер.
4. Стан наведення та готовність до застосування. Параметри наведення й балістичної готовності по пріоритетній цілі — як телеметрія, а не як команда. Зовнішня система бачить, що відбувається, але рішення про застосування лишається за ядром і оператором.
5. Телеметрія обладнання. Стан привода (положення), стан ефектора, режим сканування, стан запису — щоб командний пункт мав повну картину справності контуру.
6. Службова телеметрія. «Здоров’я» каналу спостереження (умови зйомки — світло, фокус, стабілізація), метеодані та виміряні затримки конвеєра. Це дозволяє зовнішній системі розуміти межі довіри до картинки й компенсувати «вік» даних.
7. Відеопотік — про транспорти відео нижче окремо.

Важливий нюанс інженерної чесності: усе перелічене вимикається й вмикається оператором. За замовчуванням назовні йде базовий, найбільш універсальний набір, а розширена телеметрія вмикається явно — рівно під потреби конкретної інтеграції. Це не «прихований функціонал»: будь-яка зміна конфігурації прозора й контрольована.

Самоописовий протокол: «спитай у сервера, а не вгадуй»

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

За цим стоїть свідоме рішення: єдиний реєстр контрактів як джерело істини. Кожен тип даних описаний один раз, і з цього ж опису народжуються і перевірка на сервері, і об’єкти в SDK, і документація. Класична проблема відкритих API — «у документації є, а насправді не приходить» — у нас закрита by design: те, що оголошено, гарантовано передається, бо інакше не пройшов би наш внутрішній контроль покриття.

SDK: інтеграція за хвилини

Щоб не змушувати кожного інтегратора писати з нуля, ми випустили готовий набір інструментів розробника.

• Клієнтська бібліотека ховає всю «транспортну» складність: підключення, аутентифікацію, перепідключення, синхронізацію часу й вимір затримок. Дані приходять уже розібраними у зручні типізовані об’єкти — з готовими полями та методами. Розробник пише бізнес-логіку, а не розбирає байти.
• Веб-тестувальник відкривається прямо в браузері, без встановлення. Він показує живе відео, малює обстановку за цілями в реальному часі, виводить розширену телеметрію, дозволяє запитати схему в сервера й навіть надіслати керуючі команди — щоб інженер за лічені хвилини переконався, що інтеграція працює, ще до написання власного коду.

Поріг входу мінімальний — і це свідоме проєктне рішення. Підключитися й почати отримувати дані можна буквально за один вечір. Тестувальник, до того ж, виконує подвійну роль: він і навчальний приклад, і живий діагностичний пульт, на якому видно, які канали реально працюють, а які — вимкнені в поточній конфігурації.

Двонаправленість: контур керування (з повним пріоритетом ядра)

API — це не лише «дивитися». Ми відкрили й контур керування: зовнішня система може надсилати ядру команди — наприклад, керувати приводом камери/турелі, перемикати режим роботи, запитувати пріоритетну ціль. Контур двонаправлений: на кожну команду система відповідає підтвердженням або обґрунтованою відмовою, з обмеженням частоти, щоб канал керування не можна було «залити».

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

Це критично для військової системи: рішення про застосування завжди залишається за ядром I-SEE і оператором. Жоден контур, що підключається, не може діяти в обхід захисних механізмів комплексу. Відкритість екосистеми не коштує нам контролю над зброєю — і це не гасло, а властивість нашої архітектури.

Відео: транспорт на вибір під конкретні умови

Відео — найважчий за обсягом потік, і вимоги до нього різні: десь критична мінімальна затримка, десь — сумісність зі старим обладнанням командного пункту, десь — простота й мінімум залежностей. Тому ми не нав’язуємо один формат, а даємо кілька транспортів на вибір оператора:

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

Якщо обраний режим у конкретному середовищі недоступний, система сама плавно переходить на доступний — відео не зникає мовчки, а інтегратор завжди розуміє, що відбувається. Метадані (обстановка за цілями) при цьому йдуть окремим легким каналом і синхронізуються з відео за часовою міткою — це класичний, перевірений підхід розділення «метадані окремо, медіа окремо».

Система плагінів: «поклав модуль — ядро підхопило»

Найпомітніша частина анонсу. Сторонній розробник додає свій модуль — а програма при запуску сама знаходить, перевіряє, завантажує й показує його в інтерфейсі: панеллю, оверлеєм на відео або вкладкою налаштувань. Разом з анонсом ми постачаємо робочі модулі-приклади й шаблон для власної розробки. Це не обіцянка, а працюючий результат, який можна взяти за основу.

Але ключове тут — не лише зручність, а безпека й передбачуваність. Ми проєктували систему плагінів так, ніби кожен сторонній модуль може бути ненадійним:

• Права за принципом «дозволено рівно те, що дозволено». Модуль отримує доступ тільки до того, що йому явно надано, і не може дотягнутися до решти ядра чи до сусідніх модулів. За замовчуванням заборонено все.
• Ізоляція. Довірений код може працювати ефективно, поруч із ядром; недовірений — у відокремленому середовищі з обмеженням ресурсів. Збій одного плагіна не впускає систему: він просто вимикається, а оператор бачить причину.
• Криптографічний підпис. Модуль і його код мають перевірятися підписом — це локальне рішення про довіру з боку користувача. Модулі-драйвери ефекторів (зброя) без підпису не запускаються взагалі.
• Драйвери обладнання — як модулі. Сторонній модуль може бути драйвером турелі, сіткострілу чи засобу РЕБ і виконувати команди. Але — як описано вище — застосування зброї проходить той самий одноразовий дозвіл від ядра. Драйвер виконує механіку, рішення ухвалює ядро й оператор.

Така модель дає головне для відкритої військової системи: можна швидко підключати чуже «залізо» й чужий код — не відкриваючи при цьому ні алгоритмів ядра, ні контролю над застосуванням.

Безпека й сумісність за замовчуванням

Кілька принципів, які ми заклали в усі три контури:

• Заборона за замовчуванням (deny-by-default). Розширені можливості вимкнено, поки оператор їх явно не ввімкне. Нова інтеграція не «розширює» доступ випадково.
• Не ламати те, що працює. Усі нові можливості — додаткові й сумісні назад: уже наявні клієнти й ключі доступу продовжують працювати без змін. Жодне розширення не змінює базову поведінку «по-тихому».
• Захищений транспорт і автентифікація на всіх контурах; службові канали відладки доступні лише локально.
• Чесні межі. Ми відкрито позначаємо, що вже працює, що вмикається опціонально, а що потребує додаткового обладнання чи перевірки на стенді. Платформа не обіцяє «магії».

Окремо наголосимо на інженерній дисципліні. Перш ніж заявити про можливість, ми перевіряємо її наскрізними тестами — від ядра до зовнішнього клієнта й назад, по реальних мережевих каналах, включно з контуром безпеки застосування. Ми не публікуємо «папір» — ми публікуємо те, що відтворювано проходить перевірку.

Що це означає на практиці

Для підрозділів та інтеграторів розширення I-SEE означає три речі:

1. Дані комплексу — назовні. Будь-яка зовнішня система — командний пункт, карта, суміжні засоби — може в реальному часі отримувати обстановку, телеметрію й відео від I-SEE, причому рівно в тому обсязі, який увімкнув оператор.
2. Своє обладнання — всередину. Нову камеру, турель, сіткостріл або засіб РЕБ можна під’єднати як змінний модуль, не чекаючи вендора — а контроль над застосуванням залишається за ядром.
3. Свою функцію — у ядро. Потрібна специфічна аналітика, інтеграція чи відображення під конкретне завдання — її можна дописати модулем і підключити, не чіпаючи закритий код ядра.

Куди ми рухаємося далі

Ми відкриті щодо дорожньої карти. Наступні кроки, над якими працюємо, — це переважно «проводка» й зручність, а не зміна філософії екосистеми:

• Вибіркова підписка на дані — щоб клієнт брав лише потрібні йому типи й камери та економив канал, коли інтеграторів багато й у кожного свої потреби;
• Розмежування доступу між інтеграторами — окремі права для різних споживачів (мультиарендність);
• Додаткові класи подій і продюсери даних — у міру того, як з’являються відповідні джерела на стороні комплексу;
• Розширення сумісності транспортів під конкретні інфраструктури замовників.

Якщо вам потрібен якийсь пункт раніше за інші — скажіть, ми пріоритизуємо під реальне завдання.

Останні пару слів про екосистему I-SEE

Ми робимо ставку на те, що в реальних умовах перемагає не закритий продукт, а платформа/екосистема, що адаптується, — яку можна добудувати під конкретний фронт, конкретне обладнання й конкретне завдання: швидко, безпечно й без участі вендора в кожній дрібниці.

При цьому ми не розмінюємо на відкритість дві речі, які роблять I-SEE бойовою системою, а не конструктором: закриту інтелектуальну частину ядра й повний контроль над застосуванням. Відкриваємо краї — зберігаємо мозок. Саме в цьому балансі, на нашу думку, і полягає правильна архітектура військової платформи.

Підписуйтеся на WhatsApp-канал DefTech спільноти!