Носимые устройства в ВКР: архитектура энергоэффективного трекера и метрики качества по ISO/IEC 25010
Весной 2026 года Fitbit Inspire 3 снова ушёл на отметку $69,95 — это исторический минимум для модели, которая тянет десять дней на одном заряде, считает шаги, пульс, фазы сна и умеет подавать сигнал о нерегулярном ритме. При этом в устройстве принципиально нет SpO₂, ЭКГ, встроенного GPS и бесконтактной оплаты. Для студента ИТ-направления это не новость из мира гаджетов, а готовый инженерный кейс: как уложить продукт в жёсткие ограничения по энергии, стоимости и объёму функций и при этом доказать, что решение качественное. Именно такие ограничения дают измеримые метрики для расчётной части диплома — то, чего чаще всего не хватает в главах «Практическая реализация».
Темы ВКР, которые вырастают из этого кейса
1. Энергоэффективный прототип трекера на ESP32 с BLE-синхронизацией
Актуальность. Бюджетный сегмент носимых устройств живёт по правилу «десять дней автономности против трёх дней у флагманов». Inspire 3 подтверждает: потребителю важнее续航, а не набор сенсоров. Значит, оптимизация энергопотребления — самостоятельная научно-практическая задача.
Цель: спроектировать прототип носимого трекера с автономностью не менее 7 суток в режиме непрерывного мониторинга пульса.
- сравнить режимы сна микроконтроллера (light sleep / deep sleep / ULP-сопроцессор);
- спроектировать протокол обмена с телефоном на BLE GATT;
- реализовать буферизацию отсчётов с пакетной отправкой;
- измерить средний ток потребления и пересчитать его в прогноз автономности.
Структура: Глава 1 — обзор архитектур носимых устройств и стандарта ISO/IEC 25010; Глава 2 — схемотехника, выбор компонентов, диаграммы классов и последовательностей; Глава 3 — стенд для замера тока, результаты, экономика серийного производства.
2. Сервис агрегации данных носимых устройств: edge-to-cloud на MQTT
Актуальность. Устройства вроде Inspire 3 собирают данные локально, а ценность появляется в приложении. Пункт про клип-крепление и синхронизацию — прямая отсылка к задаче переноса и агрегации телеметрии.
Цель: разработать сервис приёма и агрегации данных с носимых устройств с задержкой обработки не более 2 секунд.
- обосновать MQTT против HTTP long-polling и WebSocket;
- спроектировать иерархию топиков и политику QoS;
- реализовать конвейер «брокер → потоковая обработка → time-series хранилище»;
- провести нагрузочное тестирование на 10 000 виртуальных устройств.
Структура: Глава 1 — анализ брокеров (Mosquitto, EMQX, HiveMQ) и моделей доставки; Глава 2 — архитектура, диаграмма развёртывания в нотации UML, конфигурация кластера; Глава 3 — методика нагрузочных испытаний, RTO/RPO, расчёт стоимости облачных ресурсов.
3. Методика оценки качества носимых устройств по ISO/IEC 25010
Актуальность. Статья прямо перечисляет, что устройство умеет, а что «оставлено флагманам». Это готовый набор функциональных и нефункциональных требований для построения модели качества.
Цель: разработать методику балльной оценки носимых устройств по восьми характеристикам ISO/IEC 25010.
- формализовать метрики: точность подсчёта шагов, полнота данных о сне, автономность, удобство ношения;
- построить матрицу весов методом анализа иерархий;
- провести сравнительную оценку 5–7 моделей бюджетного сегмента;
- проверить методику на согласованность (коэффициент конкордации Кендалла).
Структура: Глава 1 — стандарты качества ПО и встраиваемых систем; Глава 2 — проектирование оценочной модели и анкет экспертов; Глава 3 — расчёты, визуализация, выводы о применимости.
Аналитическая глава: как обосновать стек, а не перечислить его
Самая частая слабость первой главы — «обзор технологий» превращается в список с википедии. Кейс Inspire 3 даёт критерий отбора: всё подчиняется бюджету энергии и стоимости. Стройте таблицу сравнения не по принципу «что популярно», а по ограничениям проекта.
| Протокол | Средний ток передачи | Дальность | Пропускная способность | Уместность в ВКР |
|---|---|---|---|---|
| BLE 5.x (GATT) | единицы мА в пике, микроамперы в покое | до 30 м | до 2 Мбит/с | основной вариант для связи с телефоном |
| Zigbee | сопоставим с BLE | до 100 м в mesh | 250 Кбит/с | нужен шлюз, избыточно для трекера |
| Wi-Fi (ESP32) | десятки–сотни мА | до 50 м | высокая | только для синхронизации по расписанию |
| LoRaWAN | низкий, но пиковый | километры | сотни бит/с | не для носимого формата |
Дальше — обоснование элементной базы. Укажите не только марку, но и критерий: ток в режиме deep sleep, наличие аппаратного FIFO у акселерометра, поддержка аппаратного шифрования. Например, выбор между MAX30102 и MAX86150 удобно защитить именно через энергопотребление и необходимость ЭКГ — той самой функции, которой у Inspire 3 нет.
Проектная часть: схемы, алгоритмы, интеграция
Вторая глава — место для инженерной конкретики. Опирайтесь на ГОСТ 34.602-89 при оформлении технического задания: раздел «Требования к системе» должен содержать измеримые величины, а не пожелания. Вместо «устройство должно работать долго» пишите «средний ток потребления в режиме мониторинга пульса — не более 1,8 мА, прогноз автономности от батареи 200 мА·ч — не менее 168 часов».
Минимальный набор диаграмм, который ожидает комиссия:
- диаграмма компонентов прототипа (сенсоры → микроконтроллер → радиомодуль → мобильное приложение);
- диаграмма последовательности для процедуры синхронизации с обработкой обрыва связи;
- диаграмма состояний конечного автомата режимов энергосбережения;
- ER-модель хранилища телеметрии с партиционированием по дате.
Отдельно продумайте интеграцию с мобильной платформой. Если прототип не свой, а работа посвящена приложению-агрегатору, используйте Health Connect или Google Fit API — это снимает вопрос «где брать реальные данные» и даёт материал для главы о приватности: разрешения гранулируются по типу данных, а часть метрик устройства вроде бюджетных моделей просто не отдают.
// пример организации топиков MQTT для парка устройств
devices/{deviceId}/telemetry/hr // QoS 1, публикация раз в 10 с
devices/{deviceId}/telemetry/activity // QoS 0, пакетом раз в 15 мин
devices/{deviceId}/status // retained, LWT для обнаружения обрыва
devices/{deviceId}/cmd // QoS 2, команды конфигурацииТестирование и метрики: чем доказать работоспособность
Это раздел, который отличает защищаемую работу от «текста с картинками». Ниже — набор метрик, которые реально считаются и защищаются.
| Метрика | Как считается | Инструмент | Ориентир |
|---|---|---|---|
| Автономность | ёмкость батареи / средний ток за цикл | USB-тестер с логом, INA219 | ≥ 168 ч |
| Точность подсчёта шагов | MAPE относительно эталонного счётчика | эталонный шагомер, 3 сценария похода | ≤ 5 % |
| Задержка синхронизации | P95 времени от публикации до записи в БД | OpenTelemetry-трейсинг | ≤ 2 с |
| Потери пакетов | разница отправленных и принятых сообщений | Mosquitto/EMQX метрики | ≤ 0,1 % при QoS 1 |
| Восстановление после сбоя | время до полной работоспособности | сценарий отключения брокера | RTO ≤ 60 с, RPO ≤ 5 мин |
Нагрузочное тестирование описывайте через профиль нагрузки: сколько устройств, с какой периодичностью публикуют данные, какой размер пакета. Простейший генератор на Python с библиотекой paho-mqtt выдаёт воспроизводимые результаты, а графики из Prometheus и Grafana становятся иллюстрациями третьей главы. Не забудьте про негативные сценарии: потеря связи, переполнение буфера, смена часового пояса, перевод часов.
Чему вы научитесь на такой работе
- переводить маркетинговое описание продукта в формализованные требования по ГОСТ 34.602-89;
- обосновывать выбор протокола и компонентов через ограничения проекта, а не через популярность;
- снимать и интерпретировать метрики энергопотребления и производительности;
- строить наблюдаемость сервиса: трейсинг, метрики, логирование;
- оформлять результаты так, чтобы расчёты проверялись комиссией за пять минут.
Типичные ошибки студентов
1. Смешение уровней абстракции. В одной главе описывают и электрическую схему, и облачную инфраструктуру, не разделяя уровни. Как избежать: зафиксируйте три представления — устройство, транспорт, сервис — и ведите каждое в своём разделе.
2. Отсутствие измеримых метрик. Формулировки «работает быстро», «потребляет мало» не проверяются. Как избежать: для каждой нефункциональной характеристики задайте числовой порог и способ измерения до начала разработки.
3. Игнорирование требований ГОСТ при оформлении ТЗ. Отсутствие разделов «Требования к видам обеспечения» и «Этапы разработки» тянет за собой замечания на защите. Как избежать: возьмите структуру ГОСТ 34.602-89 как шаблон оглавления второй главы.
4. Выдуманные данные. Идеальные графики без описания стенда вызывают прямой вопрос комиссии. Как избежать: приложите протокол испытаний с датой, условиями и погрешностью прибора.
Чек-лист перед сдачей
- Задачи во введении дословно совпадают с выводами по главам и пунктами заключения.
- Каждое заимствованное утверждение подкреплено ссылкой на источник и корректно оформлено по ГОСТ Р 7.0.5-2008.
- Все диаграммы имеют подписи, легенды и единую нотацию (UML 2.5 или IDEF0 — без смешивания).
- Числовые результаты сопровождаются единицами измерения и указанием условий эксперимента.
- Техническое задание оформлено по ГОСТ 34.602-89 и вынесено в приложение.
- Термины употребляются однозначно: не путайте платформу, инфраструктуру и приложение.
- Приложения пронумерованы и упомянуты в тексте хотя бы один раз.
- Список литературы содержит не менее 20 источников, из них не менее трети — за последние пять лет.
Частые вопросы
Обязательно ли собирать физический прототип?
Нет, но это сильный аргумент на защите. Если сборка невозможна, используйте симулятор: эмулятор BLE-периферии или программный генератор телеметрии. Тогда в главе о тестировании честно укажите, что данные синтетические, опишите модель их порождения и её ограничения.
Какую сложность реализации выберет комиссия?
Оценивают не объём кода, а глубину проработки. Проект на 2 000 строк с продуманной архитектурой, трейсингом и рассчитанными метриками выглядит убедительнее, чем 20 000 строк без единого измерения. Уровень «прототип с доказанной автономностью» — уже достаточная сложность для бакалаврской работы.
Где брать реальные данные для расчётов?
Три источника: собственные замеры (шагомер, пульсометр, лабораторный блок питания), открытые датасеты физической активности и данные мобильных платформ через Health Connect или Google Fit API. Для нагрузочного тестирования подходит синтетический трафик, сгенерированный по реалистичному профилю.
Как связать экономическую часть с технической?
Считайте не абстрактную окупаемость, а эффект от конкретного решения: снижение энергопотребления на 30 % уменьшает требуемую ёмкость батареи и цену компонента; переход с HTTP на MQTT сокращает трафик в роуминге. Каждое техническое решение должно превращаться в строку затрат или экономии.
Не хватает времени на расчётную часть или хочется сверить архитектуру с практикующим инженером? Оставьте заявку на бесплатную консультацию: мы оценим объём работы, покажем, какие метрики стоит заложить, и подскажем, как выстроить главы под требования вашей кафедры. Средний срок сопровождения проекта — от 120 часов работы с вашим материалом.
Источник: Fitbit’s budget-friendly Inspire 3 is $30 off, matching its best price (опубликовано 2026-03-26)