BLE-прошивка для IoT: что нужно знать до старта разработки
Вы проектируете устройство, которое должно по Bluetooth забирать данные с датчика, тонометра, весов или промышленной периферии. Кажется, что «прикрутить блютус» — задача на пару недель. На практике BLE-прошивка — это самый рискованный компонент IoT-продукта. Разбираем на примере реального медицинского устройства.
О чём эта статья
Мы в Платформе Качества разрабатываем BLE-прошивки для встраиваемых устройств. Один из наших проектов — адаптер для терминалов прохождения медосмотров: компактное устройство, которое автоматически получает результат измерения давления с Bluetooth-тонометра и передаёт его в информационную систему.
Звучит просто. По факту — 6 месяцев разработки и отладки, два обнаруженных в продакшене бага, детективное расследование по 470 000 строкам логов и микроконтроллер, который должен безотказно работать в сотнях поликлиник без возможности удалённого обновления.
Эта статья — для тех, кто принимает решение о разработке IoT-продукта с Bluetooth. CTO, технических директоров, продакт-менеджеров. Не про код — про риски, архитектурные решения и то, на что обратить внимание при выборе подрядчика.
Первый сюрприз: ваше устройство — не «колонка с Bluetooth»
Когда люди слышат «Bluetooth», они думают о наушниках и колонках. Там всё просто: телефон находит устройство, пользователь нажимает «подключить», музыка играет.
В IoT всё наоборот. Наш адаптер должен:
- Сам искать целевое устройство в эфире — без человека с телефоном
- Сам подключаться — проходить многоступенчатую BLE-аутентификацию
- Сам забирать данные — через стандартизированный прикладной протокол
- Сам восстанавливаться после обрыва связи, помехи или ошибки
- Делать всё это на микроконтроллере с 256 КБ оперативной памяти
Это роль BLE Central (как смартфон), а не BLE Peripheral (как наушники). И это принципиально другой уровень сложности прошивки.
Что реально входит в «прикрутить Bluetooth»
Возьмём наш проект: адаптер получает результат измерения давления с серийного тонометра. Вот что для этого делает прошивка — каждый раз, когда пациент нажимает кнопку на тонометре:
| Шаг | Что происходит | Время |
|---|---|---|
| Сканирование | Прошивка ищет нужное устройство в эфире по имени или сохранённому адресу | 1–3 сек |
| Подключение | Устанавливает BLE-соединение на радиоуровне | < 1 сек |
| Шифрование | Обмен криптографическими ключами (или восстановление ранее сохранённых) | < 1 сек |
| Обнаружение сервисов | Полный обход дерева GATT-характеристик для поиска нужного сервиса | 1–2 сек |
| Подписка | Регистрация на получение данных с тонометра | < 1 сек |
| Ожидание | Тонометр измеряет давление | 20–30 сек |
| Приём и декодирование | Парсинг пакета в медицинском формате IEEE 11073 | мгновенно |
| Передача хосту | Результат отправляется терминалу по серийному порту | мгновенно |
Весь цикл — 25–40 секунд. Но каждый шаг может провалиться. И прошивка должна корректно обработать каждый вариант отказа — не зависнуть, не потерять данные, не потребовать перезагрузки.
Три архитектурных решения, которые определяют надёжность
1. Автовосстановление без участия хоста
Когда BLE-соединение обрывается (а оно будет обрываться — помехи, расстояние, разряд батареи тонометра), прошивка должна сама вернуться в рабочее состояние. Без команды от терминала, без перезагрузки.
В нашем адаптере при любом обрыве соединения прошивка автоматически очищает внутреннее состояние и заново запускает поиск устройства. Терминал даже не знает, что что-то произошло — он просто получает следующее измерение.
Почему это важно для бизнеса: терминалы стоят в поликлиниках, где нет IT-персонала. Если адаптер требует ручного вмешательства после каждого обрыва связи — это отказ сервиса, жалобы пациентов, выезд инженера.
2. Сохранение настроек в энергонезависимой памяти
BLE-устройства при первом подключении обмениваются криптографическими ключами — это называется бондинг. Если ключи потеряются при перезагрузке, каждое подключение начинается с повторного паринга. А некоторые устройства (включая медицинские) допускают только ограниченное число паринг-сессий.
Прошивка хранит ключи бондинга и настройки (имя целевого устройства, его BLE-адрес) во flash-памяти микроконтроллера. После отключения питания, перезагрузки, обновления прошивки — всё на месте, адаптер сразу находит «свой» тонометр.
Почему это важно для бизнеса: без персистентного бондинга после каждого отключения питания (а в поликлиниках бывают перебои) нужна ручная переинициализация.
3. Watchdog — аппаратная защита от зависания
BLE-стек — это сотни тысяч строк кода, работающего в реальном времени. Гарантировать отсутствие зависаний невозможно. Но можно гарантировать, что зависание будет длиться не дольше 8 секунд: аппаратный watchdog перезагрузит устройство, и оно вернётся в рабочее состояние.
Почему это важно для бизнеса: устройство, которое «иногда зависает и требует ручной перезагрузки» — мёртвый продукт. Устройство, которое само перезагружается за 8 секунд без потери настроек — надёжный продукт.
Чего не видно на стенде: баги, которые живут только в поле
Самый коварный аспект BLE-разработки — ошибки, которые невозможно воспроизвести в лаборатории.
В нашем проекте прошивка прошла полный цикл тестирования на стенде: сотни подключений, измерений, разрывов. Всё работало идеально. В продакшене — 30% измерений пропадали на одном из устройств.
Как мы нашли причину
Устройства развёрнуты по стране, физического доступа нет. Но софт-драйвер на терминале логирует каждый обмен с адаптером в systemd journal. Мы получили недельный лог — 470 000 строк — и провели автоматизированный анализ.
Результат: 936 измерительных сессий, из которых 62 провалились. Причины:
| Проблема | Сессий | Причина | Решение |
|---|---|---|---|
| Зависание прошивки | 33 | Ошибка в обработке неудачного BLE-подключения | Исправление в прошивке |
| Мгновенный обрыв | 8 | Ошибка в обработке сбоя безопасности | Исправление в прошивке |
| Тонометр не найден | 21 | Тонометр не включён или вне зоны | Не баг прошивки |
Ключевой инсайт: зависание прошивки происходило при ошибке BLE-подключения на радиоуровне. В лаборатории, где тонометр в полуметре от адаптера, эта ошибка не возникает. В поликлинике, через стену, среди десятка Wi-Fi-роутеров — 2 раза в неделю. Одно зависание блокировало все измерения на 2+ часа.
Чему это учит
- BLE-прошивка обязательно должна быть инструментирована для удалённой диагностики. Без логов с реальных устройств вы будете чинить наугад.
- Тестирование в идеальных условиях бесполезно. Нужен стресс-тест: дальнее расстояние, помехи, тысячи циклов подключения.
- Исправление бага — это две строки кода. Нахождение бага — это неделя анализа. Компетентность команды проявляется не в написании кода, а в способности диагностировать проблему по косвенным данным.
Из чего складывается разработка BLE-прошивки
Аппаратная часть — модуль, плата, антенна, корпус — это относительно недорого, особенно при серийном производстве. Основная статья расходов — разработка прошивки. Что входит:
- BLE Central стек — сканирование, подключение, безопасность, GATT discovery
- Прикладной протокол — парсинг профиля конкретного устройства (Blood Pressure, Glucose, Weight Scale или проприетарный)
- Интерфейс с хостом — UART, SPI, USB или что требуется
- Надёжность — watchdog, автовосстановление, персистентность
- Тестирование — стенд + полевые условия + анализ логов
Реалистичные сроки при опытной команде: 2–4 месяца до первого релиза, ещё 1–2 месяца на стабилизацию по данным из продакшена.
На что обратить внимание при выборе подрядчика
Спросите про BLE Central
Большинство embedded-команд имеют опыт с BLE Peripheral (beacon, датчик, который ждёт подключения от телефона). BLE Central — это другая задача и другой набор компетенций. Спросите: «Вы делали устройство, которое само ищет и подключается к BLE-периферии?»
Спросите про медицинские профили
Стандартные BLE-профили (Blood Pressure, Glucose, Heart Rate) — это не просто «получить байты». Это GATT-дерево с обязательным security, indication (не notification), IEEE 11073 формат данных. Если команда не знает, что такое SFLOAT — они будут разбираться месяц.
Спросите про продакшен-отладку
Как будут диагностироваться проблемы на устройствах в поле? Какие логи пишет прошивка? Есть ли AT-команды или аналог для удалённой диагностики? Если ответ «подключим отладчик» — это значит, что каждый баг потребует физического доступа к устройству.
Спросите про error handling
Попросите показать, что произойдёт, если BLE-соединение оборвётся в каждой из фаз: при подключении, при установке безопасности, при GATT discovery, при подписке. Ответ должен быть одинаковым: «прошивка очистит состояние и начнёт сканирование заново». Если в какой-то фазе ответ «нужна перезагрузка» — это красный флаг.
Резюме
- BLE Central ≠ BLE Peripheral. Устройство, которое само ищет и подключается — на порядок сложнее устройства, которое ждёт подключения.
- Баги живут в эфире. Лабораторное тестирование не покрывает реальные радиоусловия. Нужна инструментация для удалённой диагностики.
- Аппаратура дешёвая, разработка — нет. Себестоимость устройства при серии невелика. Разработка прошивки — месяцы. Экономить на опыте команды — экономить на работающем продукте.
- Надёжность — это архитектура, а не тестирование. Watchdog, автовосстановление, персистентность — это проектируется на старте, а не добавляется перед релизом.
Мы разрабатываем BLE/IoT-прошивки для медицинских, промышленных и потребительских устройств — от прототипа до серийного устройства.
Если вашему продукту нужен Bluetooth — расскажите о задаче. Оценим сроки и стоимость без завышенных оценок.