Dmytro / techsd

Інженерний профіль для складних систем

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

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

Де я корисний

  • Вбудовані й радіосистеми. Англійською це часто пишуть як embedded / RF systems: мікроконтролери, плати, інтерфейси, радіоканал, живлення, діагностика.
  • Системний рівень. Не тільки “пишу код”, а бачу ризики між апаратною частиною, прошивкою, мережею, живленням і підтримкою.
  • R&D-рішення. R&D — дослідницька інженерія: де ще не все готово, але вже треба приймати технічні рішення і не плутати концепт з готовим продуктом.
  • Захисний реверс-інжиніринг. Якщо пристрій, протокол або прошивка закриті, можу відновити логіку роботи в дозволеному контурі, щоб підтримувати або інтегрувати систему.

Межі профілю

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

Формати співпраці

Коли потрібен зовнішній технічний партнер

  • Швидко розібрати систему, де проблема лежить між залізом, прошивкою, живленням, радіоканалом і реальною експлуатацією.
  • Перевести “воно працює тільки коли автор поруч” у схему, телеметрію, журнал рішень, інструкцію діагностики й підтримуваний процес.
  • Зайти в неповну документацію, старе обладнання або закритий контролер і відновити логіку роботи без довгого входу великої команди.
  • Провести технічний розбір прототипу: що вже можна показувати, що ще сире, де ризики, який наступний інженерний крок.

Коли корисна колаборація або субпідряд

  • Пілотний проєкт у defense tech, industrial IoT, battery/power systems, RF/LPWAN або польовій діагностиці.
  • Технічна перевірка перед інвестицією, грантом або закупівлею: не презентація, а тверезий інженерний зріз.
  • Потрібно швидко зібрати proof pack — доказовий пакет: схема, рівень зрілості, ризики, перевірки, логи, межі відповідальності.
  • Команда має сильних людей, але бракує погляду на стики між апаратною частиною, радіо, живленням і підтримкою.

Інженерна база під реальні умови

Що перевіряю першим

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

Що дає найбільшу цінність

  • Failure-mode first — спочатку думаю про типові відмови: кабелі, волога, живлення, радіоперешкоди, неправильне підключення, відсутність логів.
  • Evidence before intuition — симптом, вимірювання, гіпотеза, тест, виправлення, документація.
  • COTS-first prototyping — спершу швидко перевірити ідею на доступних компонентах, а не одразу будувати дорогий кастом.
  • Path to product — не тільки прототип, а модель встановлення, сервісу, навчання, вартості й повторюваного розгортання.

Автономне живлення / ATS

Linux на ARM64-платі, силова автоматика, Smart BMS, акумулятори, генератор, MikroTik/Ubiquiti мережа, телеметрія і польова підтримка. Підтверджений масштаб: 80+ польових вузлів підтримки, 23k LOC, 270+ днів uptime, ріст технічної групи з 1 до 3 інженерів.

LoRa / LPWAN

LoRa / LPWAN — далекий малопотужний радіозв'язок. Досвід: NRF52 з GNSS/BLE, Semtech SX1302, AES 128/256 на вбудованому рівні, зміни в LoRa/LoRaWAN-стеку там, де готова бібліотека не закривала задачу.

BMS і прошивки

BMS — система керування батареєю. Досвід: TI BQ, JKong, STM32, I2C/SPI/RS485/Bluetooth. Практична цінність: закритий пристрій перестає бути чорним ящиком для інтеграції й підтримки.

РЛС SAAB ARTHUR

Сервісне навчання в Норвегії: “Service maintenance SAAB”. Це досвід підтримки складної радіолокаційної системи на рівні електроніки й програмного забезпечення.

Автомобільний embedded RE

Tesla MCU / Autopilot-related задачі у 2021 році: embedded Linux, CAN/LIN, навігаційна логіка, робота з закритою автомобільною системою без нормального офіційного API.

Старе обладнання без документації

До 2020 року: пусконалагодження установок 1960-1980-х в Інституті Монокристалів НАН України. Тут важливий навик: відновити логіку роботи з фізичного заліза, коли документація неповна або відсутня.

Сучасні стики технологій

STM32 / NRF52 / ESP32 — мікроконтролери, сенсори, зв'язок, периферія Embedded Linux — Linux на платі, сервіси, GPIO/UART, стан заліза CAN / LIN / I2C / SPI / RS485 — інтерфейси між пристроями SDR — програмно-кероване радіо для аналізу сигналів GNU Radio — інструмент для складання й перевірки радіообробки KiCAD / RF PCB — плати й радіочастотна трасировка NanoVNA / антени — вимірювання й практична RF-налагоджуваність Grafana / TimescaleDB — телеметрія й часові дані FastAPI / Flask — API як частина інженерної системи Redis Streams — потокова обробка подій TDOA / GCC-PHAT — алгоритми локалізації джерела сигналу Локальні мовні моделі — аналіз великих технічних корпусів і логів

R&D без надування

Є напрями TRL 2-3: акустичне й оптичне виявлення, RF localization, sensor fusion, edge CV, автономні VTOL-концепти. TRL — рівень готовності технології. Якщо це концепт, я не називаю його готовим продуктом.

AI як інструмент, не декорація

Локальні мовні моделі, пошук по технічному корпусу, pre-summary hooks, аналіз vault-структур, routing моделей, автоматизація документації. Це корисно там, де багато файлів, логів, протоколів і треба швидко відновити контекст.

OPSEC / NDA / OSINT

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