«Інколи з джунами простіше, ніж із сеньйорами». 8 відмінностей Embedded-розробки в DefTech
Embedded-розробка в оборонних технологіях — це значно ширше, ніж просто програмування мікроконтролерів. Тут фахівці працюють і з кодом, і з «залізом» та сучасними пристроями — від антен і камер до осцилографів та аналізаторів.
Embedded-фахівці потрібні. За аналітикою DOU, від початку 2025 року кількість вакансій для Embedded-розробників збільшилася удвічі і в серпні становила 50 позицій. Деякі компанії шукають цих фахівців постійно.
Які вимоги ставлять до Embedded-спеціалістів в оборонці та як краще ввійти у цю сферу, ми дізналися у Skiftech, Skyeton і «Око Камера».
Про проджект-менеджерів у DefTech ми розповідали у попередньому матеріалі.
1 Безпека ПЗ: як захищають код і якими мовами пишуть
Еmbedded-розробник у DefTech програмує мікроконтролери й процесори у продуктах для війська — від БПЛА до сенсорів і навігаційних пристроїв. Він має розумітися на «залізі» й інтегрувати його з ПЗ, відповідати за стабільність роботи системи та оптимізувати її — зменшувати споживання пам’яті, скорочувати час відгуку тощо.
Тобто embedded-інженер не лише пише код, а й працює з апаратною частиною: розробляє плати, підбирає компоненти. Для цього бажано мати базові знання з електроніки, математики та фізики.
У мілітарних розробках особливу увагу приділяють захисту ПЗ — його зберіганню та безпеці на контролерах.
«Якщо ми знаємо, що пристрій використовуватимуть безпосередньо на лінії бойового зіткнення, ворогу не можна залишати шансів отримати доступ до ПЗ», — підкреслює Павло зі Skiftech.
Тому оборонні компанії застосовують різні підходи до захисту програмного забезпечення на мікроконтролерах:
- Readout Protection (ROP, або «захист від зчитування») — механізм, який унеможливлює викрадення чи зміну прошивки. Деякі рівні захисту навіть блокують перепрошивку контролера після початкової інсталяції. В інших випадках захист можна зняти, але тоді втрачається увесь програмний код.
- Кастомні bootloader-и для контролерів, які гарантують безпечне завантаження й оновлення ПЗ та захищають систему від несанкціонованого доступу.
- Власні файлові системи, що мінімізують ризик доступу до пам’яті. Навіть якщо зробити повну копію («зліпок») оперативної пам’яті, без розуміння принципів організації цієї файлової системи дані залишаться недоступними.
Щодо мов програмування, то у дефтеку вони такі ж, як у цивільній embedded-розробці на аутсорсі: С і С++ (через обмеження щодо потужності «заліза»), а також мови високого рівня Python, JavaScript тощо.
Фото Skiftech
2 «Сам собі господар»: свобода, доступ до ресурсів і технологій
У DefTech менше контролю й більше простору для творчості та роботи з новітніми технологіями, ніж у класичному ІТ.
«У DefTech можна занурюватися в технології високого рівня. Зараз ми працюємо з оптичним каналом зв’язку, де є чимало специфіки з фізики, оптики та аналогової електроніки. На перший погляд все просто: є лазер і є його пляма. Здавалося б, вона має бути рівномірною на будь-якій відстані.
Але насправді все складніше: на форму впливають чутливість приймача, розподіл енергії всередині плями, лінза чи навіть кристал — у деяких лазерів пляма від початку нерівномірна. Тому на великій відстані сигнал може вловлюватися лише частково.
Щоб зрозуміти, де система „ламається“ і як це виправити, доводиться звертатися до фізики: розрахунки займають формулу майже на сторінку А4. Це непросто, але надзвичайно цікаво — восьми годин на день для цього замало», — ділиться Павло зі Skiftech.
Завдяки роботі в оборонній сфері Skiftech отримали доступ і до закритих досліджень Інституту лазерних технологій, які використовують у своїх розробках.
Але DefTech — це не лише складна технологічна глибина, а й значна свобода в ухваленні рішень. Тут часто цінують швидкість і результат більше, ніж вартість чи суворе дотримання процесів.
«Створюється враження, що наявність готового рішення для ринку важливіша за вартість розробки. Тут ти сам собі господар: маєш доступ до всіх ресурсів, можеш обирати мову програмування, середовище, сервер чи ліцензію, якщо це допомагає виконати задачу. Або ж не перейматися інтеграцією, бо найчастіше вона теж лишається за тобою», — додає Юрій зі Skyeton.
3 Польові (і не лише) тести
Оскільки пристрої в DefTech створюють для роботи в польових умовах, їх тестують значно ретельніше, ніж у цивільній розробці.
У Skiftech розповідають про кілька типів тестування, що передують Manual QA:
- юніт-тестування — автоматична перевірка роботи окремих модулів, а також верхнього рівня застосунку, який інтегрує та керує цими модулями;
- апаратне («ручне») тестування — інженери налагоджують роботу плат із ПЗ, використовуючи логічні аналізатори та UART-перетворювачі для відстеження поведінки системи через логування;
- перформанс-тестування — перевірка навантаження системи та пошук аномальних піків, яких не має виникати;
- тестування енергоспоживання — для пристроїв із ультранизьким енергоспоживанням застосовують прилади на кшталт Joulescope, які вимірюють споживання плати, знаходять піки та перевіряють, чи програма коректно переходить у режими низької енергії;
- mock-тестування — функціональна перевірка із частковою підміною поведінки системи. Наприклад, якщо пристрій «прокидається» раз на добу й відправляє дані, можна «замокати» його інтерфейс — створити керовану розробниками ідентичну систему, щоб відправляти дані та перевіряти правильність роботи.
«Оскільки від розробок у DefTech залежить життя, ми намагаємось перевіряти все по максимуму. Якщо знаємо, що прилад працюватиме в діапазоні температур від —20 до +60, то тестуємо його при —30 та +70. І все має функціонувати безвідмовно», — додає Павло зі Skiftech.
Водночас кількість і глибина тестувань залежать від дедлайнів. У Skyeton пояснюють: «Якщо фронт очікує продукт у визначений час, ці строки „залізні“ й пересунути їх неможливо».
До польових тестів долучаються й ембедед-розробники — спочатку у контрольованих умовах, зазвичай виїжджаючи на день. А іноді й на кілька днів — безпосередньо на лінію бойового зіткнення, щоб побачити реальне застосування пристрою. У компаніях наголошують: усі овертайми оплачують.
Фото від Skyeton
4 Швидкість змін: новий тиждень — нові вхідні дані
Одним з викликів для ембедерів в оборонці компанії називають потребу подбати про надійність пристрою. Особливо коли потреби військових регулярно змінюються, а технології ворога швидко розвиваються.
У Skiftech цей виклик вирішують завдяки модульній розробці:
«Ми створюємо програмні модулі, які дозволяють швидко під’єднувати до проєкту нові технологічні блоки. Кожен модуль має власні тести, і після інтеграції він гарантує працездатність системи. Це можуть бути модулі роботи з файловою системою чи живленням, які інтегруються через API. Ми відпрацьовували цей підхід близько шести років, щоб довести його до стабільності».
Динаміка середовища породжує й велику кількість фіча-реквестів.
«Часто доводиться відкладати ідеальні рішення й робити так, щоб система просто стабільно працювала. До складніших підходів повертаємося, коли є час і ресурс. Адже наш продукт використовується на передовій, і від його якості залежить дуже багато», — кажуть в «Око Камера».
У Skyeton специфіку сфери описують фразою «новий тиждень — нові вхідні дані». Тут немає класичного життєвого циклу продукту, як у цивільних компаніях, де є чіткі етапи — планування, реалізація, підтримка. Усе відбувається менш системно.
«Наприклад, ми отримуємо сигнал, що наш радіомодуль перестав працювати через нові системи РЕР чи РЕБ. Тоді ми відкладаємо поточні завдання й беремося за нагальніші. Це може бути пошук альтернативних рішень або доопрацювання протоколів, щоб зробити систему стійкішою. Часто зміни виникають після зворотного зв’язку від експлуатаційних і сервісних підрозділів, які безпосередньо контактують із військовими. Це невіддільна частина процесу», — пояснює Юрій зі Skyeton.
5 Оновлення «по повітрю» та fault-tolerance
Ще на етапі створення архітектури важливо правильно обрати технології: одні з них легко «придушити», інші — більш стійкі, зазначають у Skiftech.
У Skyeton усі системи проєктують з підходом fault-tolerance — тобто з дублюванням модулів. Завдяки цьому навіть у разі пошкодження пристрій зберігає цілісність і продовжує працювати.
Не менш важливою є стратегія оновлення ПЗ з урахуванням польових умов. Павло зі Skiftech пояснює, що існує кілька варіантів:
- оновлення на етапі серійного виробництва — коли пристрій фізично під’єднують до програматора й прошивають. Для фронту цей метод майже не придатний;
- автоматичне оновлення «як у комерційних пристроях» — користувач отримує сповіщення, підтверджує інсталяцію, і система перезавантажується. Але тут потрібне стабільне підключення до інтернету;
- over-the-air (OTA) — бездротове оновлення через спеціальний застосунок: достатньо завантажити файл і запустити процес. Для OTA інтернет не обов’язковий, що робить цей варіант оптимальним для військових умов.
«Через те, що військові з об’єктивних причин не завжди мають доступ до інтернету, ми здебільшого обираємо саме OTA-оновлення без під’єднання до мережі», — пояснює Павло зі Skiftech.
У Skyeton теж віддають перевагу оновленням «по повітрю», але визнають: частину пристроїв доводиться повертати на сервіс, адже OTA-доступ надають не всім підрозділам.
6 Складнощі інтеграції: коли стандарти не працюють
У військових системах інтерфейси, стандарти й протоколи описані інакше, ніж у цивільній розробці, зауважують фахівці. Зокрема, тут застосовують інші системи шифрування — кастомні та більш захищені.
Для кращої інтеграції пристроїв іноді доводиться спільно доопрацьовувати рішення:
«Продукти субпідрядників ми тестуємо на наших полігонах. Часткову інтеграцію вже виконано, але бачимо: ініціалізація можлива лише за стабільної роботи GPS, а в польових умовах це складно. Щоб досягти результату, ми залучаємо власників інших проєктів до доробки під конкретні умови чи виконання окремих завдань, наприклад, отримання відеостріму з камер. Через швидкий розвиток сфери нам також доводиться швидко змінюватися», — розповідає Юрій зі Skyeton.
Ще одна проблема — обмежений доступ до інформації. У Skyeton пояснюють: поки компанія чи її контактні особи не пройшли верифікацію, їм не відкривають документацію на пристрої та компоненти через ризик витоку даних.
7 Джуни vs сеньйори: кому простіше адаптуватися в оборонці
У DefTech іноді легше навчати Junior-фахівця, ніж змінювати звички Middle чи Senior, розповідають у Skiftech:
«У досвідчених працівників часто вже є усталені, але не завжди ефективні підходи. Наприклад, були випадки, коли Senior-розробники питали: „Навіщо нам юніт-тести? Я й так швидко зроблю“. Але в нас прийнято працювати інакше. З такими людьми складніше комунікувати, бо вони надто впевнені у власному досвіді. У деяких випадках із джунами працювати навіть простіше».
У Skyeton жартома говорять про «примусову самоосвіту»:
«Що б ви не знали з цивільної розробки — це лише база. На місці все одно доведеться багато чого доучувати й переймати специфіку».
Фото від «Око Камера»
8 Офіс проти ремоуту
Спікери зазначають, що роботу Embedded-розробників складно виконувати віддалено, бо треба працювати з фізичними пристроями.
За такого формату, звісно, є безпекові ризики. Однак офіси мають укриття, а ставлення до тривог — суворе: обовʼязково потрібно ховатися за кожного сповіщення про небезпеку.
Похожие статьи:
8 лютого уряд схвалив новий законопроєкт, розроблений Міністерством економіки України, щодо посилення захисту працівників. У ньому,...
Комітет Верховної Ради України з питань податкової та митної політики рекомендував парламенту ухвалити законопроєкт № 5270 у...
Константин Мирин — CEO IT-компании Postindustria. Шесть лет назад он переехал в город Бар в Черногории и открыл там офис. Константин...
Штучний інтелект LaMDA запустили в бета-версії. Тепер користувачі можуть протестувати технології у застосунку AI Test Kitchen від...
