Анализ построения сети удалённого контроля термодатчиков на базе процессоров серии KW40Z фирмы NXP

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РФ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ



«Рязанский государственный радиотехнический университет»



Факультет радиотехники и телекоммуникаций

Кафедра теоретических основ радиотехники







Выпускная квалификационная работа



«Анализ построения сети удалённого контроля термодатчиков на базе процессоров серии KW40Z фирмы NXP»













Выполнил: студент 319 группы

Рыбаков Д.А.

Руководитель: доцент кафедры ТОР

Бакке А.В.







Рязань 2017

Оглавление



	Оглавление	2

	Список аббревиатур и условных сокращений	4

	Введение	7

	2. Технология BLE	8

	2.1. Криптостойкость BLE	16

	2.2. Уровень GAP и профили приложений	19

	2.3. Стек протокола BLE	20

	2.4. Характеристики потребления питания BLE устройств.	23

	2.5. Топология сети BLE.	25

	Заключение.	27

	3. Анализ рынка BLE чипов	28

	4. Общее описание сети сбора термоданных	32

	5. Соединение BLE устройств	34

	5.1. Режим объявления	35

	5.1.1. Особенности режима объявления	39

	5.2. Идентификация устройств TEMP	43

	5.2.1. Установление принадлежности к сети сбора термоданных	43

	5.2.2. Адрес устройств BLE	43

	5.2.3. Получение системного идентификатора устройства TEMP	45

	5.3. Подключение к конкретному устройству	46

	5.3. Отсоединение от устройства.	48

	5.4. Управление и контроль устройства TEMP клиентским приложением	48

	5.4.1. Мониторинг данных батареи	48

	5.4.2. Извлечение текущего времени	49

	5.4.3. Съём термоданных	49

	5.4.4. Управление светодиодом устройства TEMP	52

	3.3.1. Очереди задач и события RTOS	57

	3.3.2. База данных GATT	63

	3.3.3. Инициализация стека хоста и API-интерфейсы	65

	3.3.3.1. Инициализация задач хоста	65

	3.3.3.2. Main функция инициализации хоста	65

	3.3.3.3. Точки входа и выхода HCI	66

	3.3.3.4. Библиотеки стека хостов и доступность API	67

	3.3.3.5. Уровень мощности радиопередатчика	68

	3.3.4. Протокол общего доступа (GAP)	69

	3.4.5.Generic Attribute Profile (GATT) Layer	76

	3.4.8. Электрические характеристики и потребление.	78

	Заключение	82

	Приложение А	86

	Приложение Б	96

	Список используемыx источников.	97








Список аббревиатур и условных сокращений



Advertising — Процесс широковещательной трансляции BLE устройством пакетов оповещений(адвертайсинг). В этих пакетах устройство сообщает своё имя и адрес, сообщает о сервисах, которые предоставляет, а также специальную информацию.

BLE Host — ведущее устройство, хост, предоставляет собой верхние уровни стека протоколов BLE. Часть программного обеспечения стека BLE выполняющаяся на главном процессоре, на котором выполняется и основное приложение либо выполняется функциональность моста к основному приложению. Хост содержит GAP, GATT, базу данных GATT, L2CA.

BLE Controller — контроллер, занимается нижними уровнями BLE. Часть программного обеспечения стека BLE выполняющаяся на радио-чипе BLE.

BLE – Bluetooth Low Energy (Bluetooth снизкимэнергопотреблением).

Bonding — привязка(бондинг). Процесс сохранения совместных секретных ключей для использования при последующих доверительных соединениях пар BLE устройств.

CSRK — Connection Signature Resolving Key.Ключ для подписи сообщений.

Deviceauthentication — проверка(аутентификация) на предмет того, что два устройства имеют одинаковые секретные ключи.

EDIV — 16-и битная случайная величина, применяется для формирования LTK.

GAP — GenericAccessProfile, типовой профиль доступа. Обычно сразу же это называют layer (слой). Но это довольно странно называть профиль слоем. В исходниках это представлено как множество макросов, объявления и функций для установления и поддержания связи между BLE устройствами.

GATT — Generic Attribute Profile, типовойпрофильатрибутов.В исходниках это набор функций для обмена данными между устройствами. Атрибуты — это единицы данных разных типов (строки, числа, структуры...) организованные в виде иерархического дерева узлами которого являются сервисы, характеристики, дескрипторы и т.д. Атрибут характеризуется тем, что имеет уникальный идентификатор UUID.

HCI — HostControllerInterface. Протокол или API в зависимости от контекста для взаимодействия между BLE хостом и BLE контроллером.

IRK — IdentityResolvingKey. Ключ для расшифровки реального адреса устройства из запутанного публичного.

CA — Logical Link Control and Adaptation Layer.Программный слой с соответствующим протоколом ответственный за установления и поддержание логических каналов связи. Занимается планированием пересылок, контролем ошибок, сегментацией пакетов, управлением потоками, мультиплексированием пакетов между протоколами верхнего уровня. Является частью BLE хоста.

LTK — Long-TermKey. Секретный ключ применяющийся при шифровании BLE трафика.

Messageintegrity — защита от подделки сообщений.

MITM — man-in-the-middle.Попытка вскрыть третьей стороной совместный секретный ключ двух устройств внедряясь в канал связи между устройствами как промежуточное звено.

Pairing — связывание (пайринг). Процесс создания парами BLE устройств одного или более совместных секретных ключей для последующего шифрования трафика. Пользователь оказывается вовлечён в этот процесс, когда система просит ввести PIN код.

Profile — профиль. Набор перечней функций, свойств, поведений и ролей для совокупности уровней определённого стека протоколов.

RAND — 64-х битная случайная величина, применяется для формирования LTK.

SDK (softwaredevelopmentkit) — комплект средств разработки, который позволяет специалистам по программному обеспечению создавать приложения для определённого пакета программ, программного обеспечения базовых средств разработки, аппаратной платформы, компьютерной системы, игровых консолей, операционных систем и прочих платформ.

Scanning — Процесс приёма пакетов адвертайсинга от других BLE устройства при пассивном сканировании. При активном сканировании отсылка пакетов запросов на дополнительную информацию от устройств, работающих в режиме адвертайсинга.

SMP — SecurityManagerProtocol.Протокол используемый для пайринга. Работает по выделенному каналу в L2CA.

UUID — universallyuniqueidentifier. 128-и битный уникальный идентификатор атрибута.

Фреймворк — программное обеспечение в исходных текстах, призванное упростить создание приложений на определённой аппаратной платформе с определёнными библиотеками стеков коммуникационных протоколов. Включает обычно в себя BSP (boardsupportpackage), HAL (hardwareabstractionlayer), OSA (OS abstractionlayer), промежуточное программное обеспечение (middleware) такое как: менеджеры памяти, файловые системы, планировщики и таймеры и проч.




Введение



Одной из таких технологий, которая массово вошла в повседневную жизнь стала технологии BLE – BluetoothLowEnergy. Выпущена технология в декабре 2009 года, является версией спецификации ядра беспроводной технологии Bluetooth, наиболее существенным достоинством которой является сверхмалое пиковое энергопотребление, среднее энергопотребление и энергопотребление в режиме простоя. [9]. Практически все устройства BLE работают более года на одной миниатюрной батарейке типа таблетка без подзарядки (расчёт этого утверждения будет приведён далее). Таким образом, стало возможным иметь небольшие датчики, работающие непрерывно (например датчик температуры), общающиеся с другими устройствами, такими как сотовый телефон или персональные компьютеры. 

Новая версия спецификации Bluetooth даёт возможность поддержки широкого диапазона приложений и уменьшает размер конечного устройства для удобного использования в областях здравоохранения, физкультуры и спорта, охранных систем и домашних развлечений. На  основе BLE могут быть построены самые разнообразные сети всевозможных топологий с пакетной или потоковой передачей информации, а также различными уровнями и параметрами безопасности.

Основные работы в области стандартизации протоколов, используемых в беспроводных сетях, проводятся Институтом инженеров электротехники и электроники (IEEE), Международным союзом электросвязи (ITU), Инженерным советом Интернета (IETF) и Международной организацией по стандартизации (ISO). Результатом работ по стандартизации беспроводных систем связи стало семейство беспроводных стандартов IEEE 802.15.1, регламентирующих 7-уровней сетевой модели OSI в контектстеBLEтехнологии.

Целью настоящей дипломной работы является построение архитектуры сети сбора термоданных по технологии BLE, проектирование многопользовательской сети передачи телеметрических данных температуры человека. Частными задачами работы являются знакомство с программной и аппаратной реализацией BLE на базе чипа NXP KW40Z, разработка ПО, подготовка и сборка файла прошивки и запуск его на отладочной плате, знакомство со средой разработки чипа, создание платы прототипа для демонстрации работоспособности сети.

Актуальность выпускной квалификационной работы состоит в том, что разрабатываемое устройство, использующее передовую, стандартизированную, общемировую технологию BLE, позволит удалённо снимать графики изменения температуры тела человека в течение дня и анализировать информацию на пользовательском приложении, при этом устройство в конечном итоге, будет иметь миниатюрные габариты корпуса. В совокупности с тем, что устройство будет потреблять минимальный ток и будет способно больше года проработать от одной небольшой батареи, откроет возможность широкого использования данного устройства в мире «интернет вещей»: в качестве медицинского устройства, промышленного монитора температуры, метрологического средства измерения и т.д.





2. Технология BLE



Технические параметры спецификации BLE в сравнении с классическимBluetoothприведены в таблице 1.



Таблица 1 – Техническая спецификация BLE

Параметр

Классический Bluetooth

BLE

Радиочастота

2,4 ГГц

2,4 ГГц

Дальность

100 м

50 м

Скорость передачи данных по воздуху

1-3 Мбит/с

1 Мбит/с

Пропускная способность

0,7-2,1 Mбит/с

0,26 Mбит/с

Метод расширения спектра

FHSS (ширина канала 1 МГц)

FHSS (ширина канала 2 МГц)

Чувствительность приёмника, дБм

<-70, -87…-93

-90

Выходная мощность передатчика, дБм

20/4/0 (класс 1/2/3)

-20…10

Размер данных пакета, байт

До 358

От 8 до 47

Адресация

48-бит открытый адрес Bluetooth

48-бит открытый/ случайный

Типовые требования к реализации стека протоколов

~100 Кбайт ПЗУ; ~30 Кбайт ОЗУ

~40 Кбайт ПЗУ; ~2.5 Кбайт ОЗУ

Битовая скорость

<721 (v1.2), 3000(v2), <24000(v3)

1000

Тип модуляции

GFSK(v1.2), GFSK/4-DQPSK/8DPSK (v2+EDR), 802.11 (v3+HS)

GFSK

Ведомые устройства

7

Не предопределено

Безопасность

64/128-бит шифрование и определяемый пользователем прикладной уровень

128-бит шифрование AESCounterMode CBC-MAC и определяемый пользователем прикладной уровень

Задержка включения

Обычно 100 мс

6 мс

Общее время передачи данных

100 мс

6 мс

Сертификация

Bluetooth SIG

Bluetooth SIG

Передача голоса

Да

Нет

Топология сети

Scatternet

Star-bus

Потребляемая мощность

1 Вт

От 0,01 Вт до 0,5 Вт 

Максимальный потребляемый ток

< 30 мА

< 20 мА (max. 15 мА)



Как и классический стек протоколов Bluetooth, стек BLE состоит из двух основных частей: контроллера (Controller) и узла сети (Host). Контроллер включает в себя физический и канальный уровень и может быть реализован в виде системы-на-кристалле (СнК) с интегрированным беспроводным трансивером. Часть стека, именуемая узлом сети, реализуется программно на микроконтроллере приложений и включает в себя функциональность верхних уровней: 

- уровень логической связи (LogicalLinkControl – LLC); 

- протокол адаптации (AdaptationProtocol – L2CAP); 

- протоколатрибутов (Attribute Protocol – ATT); 

- протоколатрибутовпрофилейустройств (Generic Attribute Profile – GATT); 

- протокол обеспечения безопасности (SecurityManagerProtocol – SMP); 

- протокол обеспечения доступа к функциям профиля устройств (GenericAccessProfile – GAP) [1]. 

Взаимодействие между верхней и нижней частями стека осуществляется через интерфейс HostControllerInterface (HCI). Дополнительная функциональность прикладного уровня может быть реализована поверх уровня узла сети. Структура стека протоколов BLE представлена на рисунке 1 [1]. 

Следует также отметить, что спецификация Bluetooth 4.0 предусматривает одно- и двухрежимную работу устройств (рисунок 2) [1]. При этом однорежимные контроллеры КлассическогоБлютус и BLE не совместимы. Для обеспечения совместимости контроллер должен быть двухрежимным. Что касается узлов сети, то они являются, как правило, однорежимными.



Рисунок 1 - Стек протоколов BluetoothLowEnergy (BLE):

а) структура стека; б) формат пакета данных BLE





Рисунок 2 – схема взаимодействия между однорежимным, двухрежимными устройствами и классическими Bluetooth устройствами.



Графики, иллюстрирующие мировое использование чипов, поддерживающих двухрежимный и однорежимный вариант работы представлены на рисунке 3 [12].



Рисунок 3 – графики использования BLE чипов.



Устройства BLE работают в диапазоне 2,4 ГГц. В стандарте определено 40 частотных каналов с расстоянием в 2 МГц между каналами. На физическом уровне применена GFSK-модуляция (частотная модуляция с гауссовой фильтрацией) с индексом модуляции в пределах от 0,45 до 0,55, что позволяет уменьшить пиковое потребление энергии. Скорость передачи на физическом уровне 1 Мбит/с. В стандарте BLE чувствительность приемника определена как уровень сигнала на приемнике, при котором частота битовых ошибок (BitErrorRate – BER) достигает уровня . Она должна составлять – 70 дБм или лучше.

В BLE используется метод кодирования FHSS. Для того чтобы радиообмен нельзя было перехватить или подавить узкополосным шумом, было предложено вести передачу с постоянной сменой несущей в пределах широкого диапазона частот. В результате мощность сигнала распределялась по всему диапазону, и прослушивание какой-то определенной частоты давало только небольшой шум. BLE – устройство использует каждый канал в течение 0.625 мс (смена канала происходит 1600 раз в секунду). Последовательность несущих частот псевдослучайна, известна только передатчику и приемнику. Попытка подавления сигнала в каком-то узком диапазоне также не слишком ухудшала сигнал, так как подавлялась только небольшая часть информации. Технология  скачкообразной перестройки частоты спектра (FHSS) хорошо известна как одна из основных методов цифрового кодирования. Технология кодирования увеличивает количество передаваемых битов и увеличивает пропускная способность сигнала [5].

Переключение между частотами в псевдослучайной последовательности во время передачи данных должно быть синхронизировано. Синхронизация потребует гораздо большей мощности в методе FHSS по сравнению с расширенным спектром прямой последовательности (DSSS). Идею данного метода проиллюстрирует на рисунке 4.



Рисунок 4 -  расширение спектра скачкообразной перестройкой частоты



В течение фиксированного интервала времени передача ведется на неизменной несущей частоте. На каждой несущей частоте для передачи дискретной информации в BLE применяются стандартный метод модуляции - GFSK. Для того чтобы приемник синхронизировался с передатчиком, для обозначения начала каждого периода передачи в течение некоторого времени передаются синхробиты. Так что полезная скорость этого метода кодирования оказывается меньше из-за постоянных накладных расходов на синхронизацию.

Несущая частота меняется в соответствии с номерами частотных подканалов, вырабатываемых алгоритмом псевдослучайных чисел. Псевдослучайная последовательность зависит от параметра - начального числа. Если приемнику и передатчику известны алгоритм и значение начального числа, то они меняют частоты в одинаковой последовательности, называемой последовательностью псевдослучайной перестройки частоты.

Если частота смены подканалов ниже, чем скорость передачи данных в канале, то такой режим называют медленным расширением спектра в противном случае в BLE мы имеем дело с быстрым расширением спектра. Метод быстрого расширения спектра более устойчив к помехам и применяется в BLE, поскольку узкополосная помеха, которая подавляет сигнал в определенном подканале, не приводит к потере бита, так как его значение повторяется несколько раз в различных частотных подканалах. В этом режиме не проявляется эффект межсимвольной интерференции, потому что ко времени прихода задержанного вдоль одного из путей сигнала система успевает перейти на другую частоту.  Метод медленного расширения спектра таким свойством не обладает, но зато он проще в реализации и сопряжен с меньшими накладными расходами.

На канальном уровне различают два типа каналов – каналы объявления и каналы данных. Каналы объявления используются для поиска устройств, установления соединения, широковещательных передач, тогда как каналы данных используются для двунаправленного обмена между устройствами.

Для каналов объявления выделено три частотных канала в центре полосы, что минимизирует перекрытие с каналами 1, 6 и 11 стандарта IEEE 802.11. Остальные 37 каналов используются для обмена данными [4]. Для снижения влияния помех, многолучевого распространения, а также для снижения влияния соседних устройств при обмене данными предусмотрено скачкообразное переключение частоты (рисунок 5). Такое распределение рекламных каналов выбрано не случайно. Во-первых, рекламные каналы попадают между каналами Wi-Fi (1, 6, 11 каналы), что позволяет даже при малом уровне мощности, быть услышанными другими устройствами. Во-вторых, когда мы разносим рекламные каналы далеко друг от друга, мы получаем гарантированную доставку сообщения. Это связано с интерференцией сигнала в помещениях. Известно, что в результате отражения радиосигналов от стен, может получиться ситуация, когда приемник и передатчик не слышат друг друга. Однако в нашем случае, когда передача рекламных пакетов идет последовательно на трех разных каналах, максимально удаленных друг от друга по частоте, этот эффект отсутствует.





Рисунок 5 - Соотношение частотных каналов BLE и каналов IEEE 802.11



Протокол L2CAP в BLE отвечает за установление логического соединения. В BLE основной задачей L2CAP является мультиплексирование данных трех протоколов (ATT, SMP, LinkLayer) для соединения канального уровня. Сегментирования пакетов или сборки пакетов не производится, т.к. максимальная полезная нагрузка L2CAP в BLE составляет 23 байта.

Протокол ATT определяет коммуникационные сообщения между двумя устройствами, выступающими в контексте данного протокола в качестве клиента и сервера. Сервер поддерживает набор атрибутов, представляющих собой структуру данных, позволяющую получать доступ к информации, управляемой протоколом GATT. Роли клиента и сервера определяются протоколом GATT и не зависят от роли устройства в соединении (ведущий/ведомый).

Клиент посредством запросов может получить доступ к атрибутам сервера. Кроме того, сервер посылает клиенту два типа сообщений, содержащих атрибуты:

- уведомления, не требующие подтверждения;

- индикаторы, на которые клиент обязан ответить.

Клиент также может послать серверу команды на изменение значений атрибутов.

Протокол GATT определяет среду исполнения, используемую протоколом ATT для обнаружения сервисов и обмена характеристиками между устройствами. Характеристика в данном случае представляет собой набор данных, включающих в себя значения и свойства. Данные, относящиеся к сервисам и характеристикам, сохраняются в атрибутах. К примеру, сервер с работающим сервисом «температурный датчик» может быть связан с характеристикой «температура», которая используется для описания датчика, а другой атрибут может применяться для хранения результатов измерений.

2.1. Криптостойкость BLE



BLE предлагает несколько сервисов безопасности для защиты данных, передаваемых между парой соединенных устройств. Большинство из поддерживаемых сервисов могут быть описаны в терминах двух режимов: LE SecurityMode 1 и LE SecurityMode 2. Эти режимы обеспечивают сервисы безопасности на канальном уровне и на уровне ATT, соответственно.

Канальный уровень BLE поддерживает шифрование и аутентификацию на основе алгоритма CipherBlockChaining-MessageAuthenticationCode (CCM) и блочного шифра AES-128. При использовании в соединении шифрования и аутентификации, к полезной нагрузке (PDU) добавляется четырехбайтное сообщение проверки целостности MessageIntegrityCheck (MIC), после чего поля PDU и MIC шифруются.

Также возможна передача аутентификационных данных поверх нешифрованного соединения канального уровня. В данном случае на уровне ATT к полезной нагрузке добавляется 12-байтная сигнатура. Сигнатура вычисляется путем использования алгоритма AES-128 как блочного шифра. Одним входом алгоритма является счетчик, позволяющий предотвратить атаки типа повтора сообщений. Если приемнику удается верифицировать сообщение, считается, что оно пришло от достоверного источника.

В дополнение к этим сервисам безопасности BLE поддерживает механизм, называемый приватным (или частным) адресом, который позволяет устройству использовать множество часто меняемых адресов. Этот механизм снижает угрозу отслеживания BLE-устройства по его адресу. Приватные адреса генерируются на основе публичного адреса устройства путем его шифрования с использованием ключа, полученного от доверенного устройства.

Каждый режим безопасности предусматривает наличие нескольких уровней, применяемых в зависимости от типа соединения пары устройств (таблица 2).

Таблица 2. Сервисы и уровни безопасности, определяемые в стеке протоколов BLE.

Режим

Уровень безопасности

Тип соединения (Pairing)

Шифро-вание

Проверка целостности

Уровень стека

LE Security Mode 1

Уровень 1

Нет

Нет

Нет

Канальный уровень (Link Layer)



Уровень 2

Без аутентификации

Есть

Есть





Уровень 3

Аутентификация

Есть

Есть



LE Security Mode 2

Уровень 1

Без аутентификации

Нет

Есть

Уровень ATT (ATT Layer)



Уровень 2

Аутентификация

Есть

Есть





Логическое соединение устройств (pairing) происходит в три этапа. На первом этапе соединенные на канальном уровне устройства объявляют свои доступные возможности ввода-вывода, и на основе их принимается решение о методе взаимодействия на втором этапе.

Целью второго этапа является генерация короткоживущего ключа (Short-TermKey – STK), который будет использован на третьем этапе для обеспечения безопасности передачи распространения ключевой информации. На втором этапе устройства первоначально договариваются о временном ключе (TemporaryKey – TK) при помощи одного из следующих методов:

Out Of Band;

Passkey Entry;

JustWorks.

Метод OutOfBand (передача вне полосы) предполагает передачу временного ключа по альтернативным каналам, например, используя NFC. В методе PasskeyEntry ключ задает пользователь в виде последовательности из шести цифр. Когда применение обоих методов невозможно, используется метод JustWork, хотя он не поддерживает проверку аутентификаций, и не защищен от атаки типа «посредник» (ManInTheMiddle - MITM).

На базе ключа ТК и случайных чисел, генерируемых каждым из узлов, создается STK, что является завершением второго этапа.

На третьем этапе каждая из конечных точек соединения может передать другой конечной точке до трех 128-битных ключей, называемых Long-TermKey (LTK), ConnectionSignatureResolvingKey (CSRK) и IdentityResolvingKey (IRK).

LTK используется для генерации 128-битного ключа для шифрования и аутентификации на канальном уровне, CSRK – для подписи данных на уровне ATT, а IRK – для генерации частных адресов.

Протокол управления безопасностью SecurityManagerProtocol (SMP), работающий поверх фиксированного канала уровня L2CAP, отслеживает выполнение всех трех этапов.

Уязвимым местом BLE на текущий момент является незащищенность ни одного из реализованных в нем методов установления соединения от пассивного прослушивания. Однако, в следующих версиях BLE планируется использование эллиптической криптографической кривой и алгоритма обмена открытыми ключами (алгоритм Диффи-Хэлмана).

2.2. Уровень GAP и профили приложений



Протокол GAP определяет роли устройств, режимы и процедуры обнаружения устройств и сервисов, управление установлением соединения и безопасностью. В BLE GAP выделяет четыре роли для контроллера – широковещательный, наблюдатель, периферийный и центральный.

Широковещательный узел может только передавать пакеты по каналам объявления и не поддерживает соединение с другими устройствами. Наблюдатель способен только прослушивать каналы объявлений, в частности, способен принимать пакеты, передаваемые широковещательным узлом. Центральные узлы представляют собой устройства, способные поддерживать несколько соединений, в то время как периферийные узлы – это простые устройства, способные поддерживать одно соединение с центральным узлом. Роли центрального и периферийного узла предполагают, что устройство способно выполнять функции, соответственно, ведущего или ведомого. Устройство может поддерживать несколько ролей, но одновременно активной может быть только одна из них.

Поверх GAP могут быть построены дополнительные профили приложений, обеспечивающие необходимую пользователю функциональность. В BLE поддерживается иерархия профилей – профиль верхнего уровня может использовать функции профиля низкого уровня.



2.3. Стек протокола BLE



На рисунке 15 дано представление BLE как его видит программист микроконтроллеров. Стек BLE состоит из двух программных частей: Host и Controller. Программная часть Host занимается высокоуровневыми функциями организации и управления данными, подключениями, а Controller управляет физической периферией приёмопередатчика, работает с секретными ключами и занимается другими низкоуровневыми функциями. Названные части соединены программным интерфейсом HCI (HostControllerInterface). В реализации на микроконтроллере обе части работают на одном чипе, а интерфейс HCI превращается просто в прямую передачу данных из задачи (программного модуля) хоста в задачу (программный модуль) контроллера и обратно. 



Рисунок 15 – архитектура чипсета

По сути, программист видит несколько наборов API работающих на уровне Host: называемые GATT, GAP, L2CA, SMP, HCI. С помощью GAP API устанавливается режим работы устройства — Central, Peripheral, Observer, Broadcaster и устанавливается соединение, когда нужно. А с помощью GATT API выполняется непосредственная передача и приём полезных данных и их разбор.

Важной особенностью BLE по сравнению с Wi-Fi является специфицирование не только канала связи, но и самих прикладных приложений его использующих. Это называется профилями и сервисами. Они описывают роли устройств, предназначение данных, состав и формат данных, защиту данных, порядок, типы и события обмена, а не только то, как передаются данные. Спецификации уже даны, остаётся на стороне устройства только заполнить нужные поля для отправки результатов измерений. Клиенты таких (смартфон) распознают эти данные автоматически и отобразят их или используют соответствующим образом, так как все производители руководствуются одними и теми же спецификациями BLE по поводу того, как представлены данные о температуре или пульсе и как с ними работать. Но остаётся место и для фантазии разработчика, так как профили имеют механизмы для расширений функциональности. На рисунке 16 приведена грубая иерархия атрибутов в BLE устройстве.



Рисунок 16 – иерархия атрибутов BLE

	На рисунке 17 чуть более подробное типовое дерево атрибутов. Это не полное дерево, большинство опущено поскольку заняло бы слишком много места. Цветами выделяются уровни дерева, каждый атрибут имеет уникальный номер — UUID. Запись стандартных номеров сокращается до 16-и бит. На данном рисунке все номера стандартные. Профили GAP и GATT тоже представлены как сервисы со своими стандартными характеристиками. У каждого сервиса может быть своя модель защиты и авторизация. Все дерево целиком в устройстве хранится как база данных называемая базой GATT, обычно в виде простой таблицы с перекрёстными ссылками. 



Рисунок 17 – типовое дерево атрибутов BLE



У характеристик сервисов есть множество возможностей (характеристик), как показано на рисунке 18. У  характеристики принадлежащей сервису могут специфицироваться допуски на чтение, запись, необходимость извещений, подтверждений, подписей и прочее.



Рисунок 18 – характеристики сервисов BLE





2.4. Характеристики потребления питания BLE устройств.



Одним из наиболее важных эксплуатационных показателей, определяющих возможность применения технологии беспроводной связи в той или иной задаче, является энергопотребление узлов сети, работающей по данной технологии. Этот показатель определяет время автономной работы устройств и схему их технического обслуживания.

Для устройств BLE потребление будет зависеть от роли устройства в соединении и параметрах соединения, в частности от connInterval, connSlaveLatency, connSupervisionTimeout, а также от качества связи.

Среднее энергопотребление узла в режиме ведомого в зависимости от величины connInterval представлено на рисунке 7.





Рисунок 7 - Средний ток потребления BLE-устройства в режиме ведомого (узел построен на базе СнК CC2450, connSlaveLatency=0)

Теоретическое время автономной работы BLE-устройства в качестве ведомого в зависимости от интервала следования событий связи connInterval и уровня битовых ошибок (BER) показаны на рисунке 8 и 9 [3].

Приведенные результаты, хотя и представляют теоретически максимальные оценки времени работы BLE-устройств, тем не менее показывают, что BLE вполне подходит для сенсорных устройств с автономным питанием, а среднее потребление BLE-устройств вполне сравнимо с потреблением устройств, «традиционных» для сенсорных сетей.

Основным недостатком BLE-сетей являются топологические ограничения. В отличие от технологий сенсорных сетей, таких как, ZigBee, 6LoWPAN или Z-Wave, ориентированных на разветвленные распределенные сети с многочисленными передачами данных между узлами сети, BluetoothLowEnergyрассчитан на топологии типа «точка-точка» и «звезда».







Рисунок 8 - Теоретические оценки времени автономной работы BLE -устройства на основе CC2540 (от батареи емкостью 230 мАч в режиме ведомого устройства при уровне ошибок равном 0 и максимальном значении connSlaveLatency)





Рисунок 9 - Теоретические оценки времени автономной работы BLE-устройства на основе CC2540 (от батареи емкостью 230 мАч в режиме ведомого устройства при различном уровне ошибок и различных значениях параметров connInterval и connSlaveLatency) [20]



2.5. Топология сети BLE.



Классическая спецификация Bluetooth определяет единую структуру для широкого спектра устройств, которые соединяются друг с другом. Bluetooth работает в основном с использованием специальных пикосетей. Ведущее устройство контролирует до семи ведомых устройств на пикосоту. Ведомые соединяются с ведущим устройством, но не обмениваются данными друг с другом. Однако ведомое устройство может участвовать в одной или нескольких пикосетях, по существу, в виде набора устройств, подключенных через Bluetooth. Ниже приведена классическая топология Bluetooth с несколькими пикосетами, называемая scatternet (рисунок 10).

В топологии BLE ведомые устройства осуществляют связь по отдельному физическому каналу с ведущим. В отличие от классическойпикосетиBluetooth, где все ведомые устройства прослушивают входящие соединения и поэтому должны находиться в постоянном режиме ожидания, ведомое устройство BLE предлагает соединения и, таким образом, полностью контролирует, когда потреблять электроэнергию. Мастер BLE, который, как предполагается, имеет меньше ограничений по мощности, будет прослушивать объявления ведомого устройства и устанавливать соединение после получения пакета объявления. Иллюстрация этого представлена ниже (рисунок 11). Данная топология является смешанной и называется «star-bus» (от англ. star - «звезда», bus – «шина»).





Рисунок 10 – топология scatternet, используемая в классическомBLE.





Рисунок 11 – BLE star-bus топология.



2.6. Система реального времени



Операционная система реального времени (RTOS) — тип операционной системы, основное назначение которой — предоставление необходимого и достаточного набора функций для работы систем реального времени на конкретном аппаратном оборудовании (в нашем случае – ARM микроконтроллере).

Указанный абстрактный уровень предоставляет для прикладного ПО пять основных категорий сервисов: управление задачами, динамическое распределение памяти, управление таймерами, взаимодействие между задачами и синхронизация, контроль устройства ввода-вывода. 

Ключевым отличием сервисов ядра ОСРВ является детерминированный, основанный на строгом контроле времени, характер их работы. В данном случае под детерминированностью понимается то, что для выполнения одного сервиса операционной системы требуется временной интервал заведомо известной продолжительности, а ОС общего назначения не являются детерминированными. Их сервисы могут допускать случайные задержки в своей работе, что может привести к замедлению ответной реакции приложения на действия пользователя в заведомо неизвестный момент времени. 

Каждой задаче в RTOS приложении ставится в соответствие некоторый приоритет. Чем больше приоритет, тем выше должна быть реактивность задачи. Высокая реактивность достигается путём реализации подхода приоритетного вытесняющего планирования, суть которого заключается в том, что планировщику разрешается останавливать выполнение любой задачи в произвольный момент времени, если установлено, что другая задача должна быть запущена незамедлительно.

Каждый раз, когда планировщик задач получает сигнал о наступлении некоторого внешнего события (триггер), причина которого может быть как аппаратная, так и программная, он действует по следующему алгоритму:

Определяет, должна ли текущая выполняемая задача продолжать работать.

Устанавливает, какая задача должна запускаться следующей.

Сохраняет контекст остановленной задачи (чтобы она потом возобновила работу с места остановки).

Устанавливает контекст для следующей задачи.

Запускает эту задачу.

Эти пять шагов алгоритма также называются переключением задач.

В обычных RTOS задача может находиться в трёх возможных состояниях: выполняется, готова к выполнению, заблокирована.

Большую часть времени основная масса задач заблокирована. Только одна задача может выполняться на центральном процессоре в текущий момент времени. Если в списке готовых к выполнению задач последних имеется не больше двух—трёх, то предполагается, что все задачи расположены в оптимальном порядке. Если же случаются такие ситуации, что число задач в списке превыша.......................