23 марта 2026 года компания Steplife — производитель бионических протезов конечностей — объявила о старте разработки единого мобильного приложения для управления своими коленными модулями, с планами подключить к нему в перспективе и датчики. Для выпускника ИТ-направления это не просто новость индустрии, а готовая рамка для ВКР: здесь сходятся мобильная разработка, Bluetooth Low Energy, телеметрия с носимого устройства, офлайн-синхронизация и — что редко встретишь в студенческих работах — реальные требования к качеству и безопасности ПО медицинского назначения. Ниже разберём, как превратить этот кейс в защищаемую работу: какие темы брать, какие схемы рисовать, какие метрики считать и где чаще всего сыпятся дипломники.
Начните с одной платформы. Для ВКР достаточно нативной Android-разработки (Kotlin + Jetpack Compose) либо кроссплатформенного варианта, если в задачах есть сравнительный анализ. Ключевой навык не в UI, а в работе с Bluetooth-стеком: сканирование, GATT-подключение, подписка на характеристики, восстановление связи после разрыва. Не тащите в диплом пять технологий — комиссия оценивает глубину, а не ширину.
Три рабочих пути: (1) аппаратный эмулятор на ESP32 или Raspberry Pi, отдающий GATT-характеристики и MQTT-топики по заданному контракту; (2) программный симулятор, генерирующий поток телеметрии по лог-нормальному распределению углов и моментов; (3) открытые датасеты походки и электромиографии. В главе 1 обязательно опишите модель данных и допущения — именно это отличает инженерную работу от «нарисовал экраны».
Эффективность здесь — это измеримые характеристики качества: задержка установления соединения, доля успешных синхронизаций телеметрии, crash-free sessions, расход батареи, время восстановления после потери связи. Фиксируйте их до и после оптимизации, стройте таблицу «метрика — базовая версия — улучшенная версия — прирост». Такой формат третьей главы защищается лучше, чем абстрактное «приложение работает быстро».
Зависит от того, что вы проектируете. Если в работе есть система в целом — техническое задание, эскизный и технический проект, — опирайтесь на комплекс ГОСТ 34 (в частности, 34.601 и 34.602). Если акцент на программном изделии, уместнее ГОСТ 19 (19.201 — ТЗ, 19.202 — пояснительная записка). Уточните требование у научного руководителя до того, как напишете половину текста: переделка структуры на последнем курсе — самый дорогой способ потерять месяц.
Не пересказывайте пресс-релиз. Возьмите из него три факта — единое приложение, линейка коленных модулей, планы по датчикам — и разверните каждый в аналитический тезис. Дальше сравните минимум три аналога: фирменное приложение конкурента, универсальный BLE-сканер с открытыми профилями и платформенное решение производителя чипов. Итогом главы должна стать таблица требований, из которой логично вытекает цель вашей разработки. Здесь же уместно описать регуляторный контекст: для ПО медицинского назначения применимы ГОСТ 34 и ГОСТ 19, стандарт IEC 62304 для жизненного цикла, ISO 14971 для управления рисками, а качество продукта удобно раскладывать по ISO/IEC 25010.
Рисуйте C4: контекст, контейнеры, компоненты. На контекстном уровне у вас появятся пациент, мобильное приложение, бионический модуль, облачный сервис телеметрии и — опционально — кабинет врача. На уровне контейнеров видно главное разделение: локальный BLE-канал с жёсткими таймингами и сетевой канал с ненадёжной связью. Отсюда рождается архитектурный выбор offline-first: устройство пишет данные в локальное хранилище, а синхронизация идёт асинхронно и идемпотентно.
Ниже — минимальный контракт, который стоит зафиксировать в работе до написания кода. Он же отлично смотрится в приложении к диплому.
// Пример описания сервиса телеметрии (GATT) + сетевой контракт
GATT SERVICE 0000fff0-0000-1000-8000-00805f9b34fb
CHAR 0000fff1 (read, notify) -> режим модуля: {mode: "stance"|"swing"|"lock"}
CHAR 0000fff2 (read, notify) -> телеметрия, пакет 20 байт @ 10 Гц
[0..1] uint16 angle_deg * 100 // угол сгиба
[2..3] uint16 torque_Nm * 100 // момент
[4..5] uint16 battery_mV // напряжение
[6] uint8 flags // bit0: ошибка датчика
[7..19] reserved / CRC16
// Публикация в облако (MQTT)
TOPIC: devices/{serial}/telemetry
PAYLOAD:
{
"device_serial": "KNEE-0001",
"ts": "2026-03-23T10:15:42.117Z",
"angle_deg": 42.7,
"torque_nm": 3.15,
"battery_mv": 3712,
"firmware": "1.4.2",
"idempotency_key": "KNEE-0001:1742206542117"
}
Отдельно проработайте конечный автомат соединения: отключено → сканирование → подключение → обнаружение сервисов → подписка → поток данных → разрыв → переподключение с экспоненциальной задержкой. Этот автомат — идеальный кандидат на UML-диаграмму состояний в главе 2 и на набор тест-кейсов в главе 3.
Соберите измерения в единую таблицу. Снимайте значения телеметрии через OpenTelemetry или собственные счётчики, а сбои приложения — через отчёты о падениях. Главное правило: у каждой метрики должно быть указано, каким инструментом она получена и на какой выборке.
| Метрика | Что показывает | Как измерять | Ориентир для ВКР |
|---|---|---|---|
| Время установления BLE-соединения | Отзывчивость приложения | Логи приложения, 100 запусков | p95 ≤ 3 с |
| Доля потерянных пакетов телеметрии | Надёжность канала | Сверка счётчиков устройства и сервера | ≤ 1 % |
| Доля успешных синхронизаций | Работа офлайн-очереди | Идемпотентные ключи, логи сервиса | ≥ 99 % |
| Crash-free sessions | Стабильность сборки | Отчёты о падениях | ≥ 99,5 % |
| Расход батареи в режиме потока | Пригодность к повседневному ношению | Замеры на реальном устройстве, 1 ч | ≤ 4 %/ч |
| Трассируемость требований | Готовность к аудиту качества | Матрица «требование — тест — результат» | 100 % покрытия |
Источник: Steplife выпускает единое мобильное приложение для бионических коленных модулей (опубликовано 2026-03-23)