Z-Stack 3.0 Developer’s Guide - CC2530/CC2538

Опубликовано admin в Сб, 2020-03-14 13:08

Z-Stack 3.0 Руководство разработчика

Скачать оригинал (eng)

Описывает теорию работы ядра стека ZigBee и Z-Stack ™, параметры конфигурации, примеры разработки приложений и флаги компиляции для опытных пользователей. Сырой перевод.

 

 

 

 

 

 

 

 

 

СОДЕРЖАНИЕ

1. ВВЕДЕНИЕ ............................................... 1
1.1 ЦЕЛЬ ................................................  1
1.2 ОБЛАСТЬ ПРИМЕНЕНИЯ ................................................  1
1.3 ОПРЕДЕЛЕНИЯ, СОКРАЩЕНИЯ И АКРОНИМЫ ............................................  1
1.4 СПРАВОЧНЫЕ ДОКУМЕНТЫ ...............................................  2
2. ZigBee ............................................... 3
2.1 ТИПЫ УСТРОЙСТВ ............................................... 3
2.1.1 Координатор .............................................. 3
2.1.2 Маршрутизатор ..............................................  3
2.1.3 Конечное устройство ............................................  4
2.2 ПРОФИЛЬ СТЕКА ...............................................  4
3. АДРЕСАЦИЯ ...............................................  5
3.1 ТИПЫ АДРЕСОВ ...............................................  5
3.2 НАЗНАЧЕНИЕ АДРЕСОВ В СЕТИ ............  5
3.2.1 Стохастическая адресация ............................................. 5
3.3 АДРЕСАЦИЯ В Z-STACK ............................................  5
3.3.1 Одноадресная передача - Unicast ............... 6
3.3.2 Косвенный - Indirect.......................... 6
3.3.3 Трансляция - Broadcast.........................  6
3.3.4 Групповая адресация - Group Addressing .........  6
3.4 Важные адреса устройств - Important Device Addresses ..............................................  7
4. Привязка - Binding ............................................... 8
4.1 Построение таблицы привязок .............................................  8
4.1.1 Запрос привязки объекта устройства - ZigBee Device Object Bind Request........  8
4.1.1.1 Заявка на ввод в эксплуатацию ............................................ 8
4.1.1.2 Запрос привязки конечного устройства объекта - ZigBee Device Object End Device Bind Request..  8
4.1.2 Диспетчер привязки приложений устройства ...........................................  9
4.1.3 Нахождение и привязка - Finding and binding ............... 9
4.2 Настройка привязки источника .............................................. 9
5. ММаршрутизация - Routing .....................  10
5.1 ОБЗОР ............................ 10
5.2 Протокол маршрутизации - Routing protocol .............  10
5.2.1 Обнаружение и выбор маршрута - Route Discovery and Selection ....... 11
5.2.2 Обслуживание маршрута - Route maintenance ........................11
5.2.3 Срок действия маршрута - Route expiry ........................  11
5.3 Таблица хранения - Table storage .....................  11
5.3.1 Таблица маршрутизации - Routing table ............ 11
5.3.2 Таблица обнаружения маршрутов - Route discovery table ..........  12
5.4 Протокол маршрутизации «многие к одному» - Many-to-One Routing Protocol ... 12
5.4.1 Обзор маршрутизации «многие к одному» - Many-to-One Routing Overview ... 12
5.4.2 Обнаружение маршрута «многие к одному» - Many-to-One Route Discovery ... 12
5.4.3 Команда записи маршрута - Route Record Command ........................ 13
5.4.4 Обслуживание маршрута «многие к одному» - Many-to-One Route Maintenance .14
5.5 Краткая справка по настройке маршрутизации ............................................. 14
5.6 Очистка маршрутизатора вне сети - Router Off-Network Association Cleanup... 15
9. РАЗНОЕ ...............................................  19
9.1 НАСТРОЙКА КАНАЛА ............................................... 19
9.2 Настройка PAN ID и сети для подключения ............ 19
9.3 Максимальный размер полезной нагрузки ................... 19
9.4 Выйти из сети ...............................................  20
9.5 Дескрипторы ................................................ 20
9.6 Элементы энергонезависимой памяти ............................ 20
9.6.1. Глобальная конфигурация энергонезависимой памяти ......................................... 20
9.6.2. Энергонезависимая сетевая память .........................................  20
9.6.3 Применение энергонезависимой памяти ..........................................  21
9.7 АСИНХРОННЫЕ ССЫЛКИ ...............................................  21
9.8 Многоадресные сообщения - Multicast Messages ...................... 22
9.9 ФРАГМЕНТАЦИЯ ................................................ 22
9.9.1 Краткое руководство ............................................. 24
9.10 Расширенные PAN ID ..............................................  24
9.11 Присоединение с предварительно настроенными параметрами сети/a> ...... 4
9.12 Управление детьми ............................................... 24
9.12.1 Настройка дочернего управления для родительского устройства ...  25
9.12.2 Настройка дочернего управления для дочерних устройств ......... 25
9.12.3 Родитель Эннс - Parent Annce ......................... 25
10. БЕЗОПАСНОСТЬ ........................................ 26
10.1 ОБЗОР ................................ 26
10.2 КОНФИГУРАЦИЯ ............................26
10.3 ЦЕНТРАЛИЗОВАННАЯ СЕТЬ БЕЗОПАСНОСТИ ...................... 26
10.3.1 Политики трастового центра ..................26
10.3.1.1 zgAllowRemoteTCPolicyChange ........................ 26
10.3.1.2 bdbJoinUsesInstallCodeKey ............................... 27
10.3.1.3 bdbTrustCenterRequireKeyExchange ........................ 27
10.3.2 Обновление ключей ........................ 27
10.4 РАСПРЕДЕЛЕННАЯ СЕТЬ БЕЗОПАСНОСТИ ..............................  27
10.5 Типы ключей ссылок .............................................. 27
10.5.1 Ключ ссылки по умолчанию для глобального центра управления безопасностью .. 27
10.5.2 Установить ключ получения производного кода центра доверия ................ 28
10.5.3 Ключ глобальной ссылки распределенной безопасности .......................................... 28
10.5.4 Предварительно настроенный ключ связи Touchlink ...........................................28
10.6 Ненадежное присоединение к сети ............................................ 28
10.6.1 Небезопасное присоединение к централизованной сети ......................................... 29
10.6.2 Небезопасное присоединение к распределенной сети............ 29
10.6.3 Вопросы безопасности Z-Stack ........................ 31
10.6.3.1 Для устройств TC ................................. 31
10.6.3.2 Для присоединения устройств ...................... 31
10.7 Соединение Touchlink ........................ 31
10.8 Обратная совместимость ............................. 32
10.9 Краткое руководство ......................... 33
11. Обзор приложения ............................34
11.1 ВВЕДЕНИЕ .................................... 34
11.1.1 Инициализация .................................. 34
11.1.2 Организация ...................................... 34
11.1.3 Приоритет задачи ................................... 34
11.1.4 Системные сервисы ................................... 35
11.1.5 Разработка приложения ............................. 35
11.1.5.1 Одна задача OSAL на множество объектов приложения.. 35
11.1.5.2 Одна задача OSAL на один объект приложения ........ 35
11.1.6 Обязательные методы ......................... 35
11.1.6.1 Инициализация задачи ............................ 35
11.1.6.2 Обработчик событий задачи ....................... 35
11.1.7 Обязательные события ........................... 35
11.1.7.1 SYS_EVENT_MSG (0x8000) .................... 35
11.2 Общая прикладная структура / программный поток .......... 36
11.2.1 Инициализация ........................... 36
11.2.2 Обработка событий .................................. 37
12. Примеры приложений ................................ 39
12.1 ВВЕДЕНИЕ ................................................ 39
12.2 ИНИЦИАЛИЗАЦИЯ ........................ 39
12.3 АРХИТЕКТУРА ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ ................... 39
12.4 Файловая структура ............... 40
12.4.1 Пример приложения On Off Light (свет и выключатель). .................... 40
12.4.2. Пример приложения DoorLock (DoorLock и DoorLockController). ................. 41
12.4.3 Пример приложения Temperature Sensor (Термостат, Датчик температуры). ............ 41
12.4.4. Дополнительные файлы проекта. ................................ 41
12.5 Приложение Sample Light .................... 41
12.5.1 Введение .................................... 41
12.5.2 Модули .................................... 41
12.6 Приложение Sample Switch ........................... 42
12.6.1 Введение ................................ 42
12.6.2 Модули .................................. 42
12.6.3 Демонстрационные конфигурации сборки OTA коммутатора .............. 42
12.6.3.1 Введение ..................................42
12.6.3.2 Модули .....................................42
12.7 Приложение Sample Door Lock ..................... 42
12.7.1 Введение ................................ 42
12.7.2 Модули .................................. 42
12.8 Приложение Sample Door Lock Controller .............. 42
12.8.1 Введение ................................... 42
12.8.2 Модули ...................................... 43
12.9 Приложение Sample Thermostat ................... 43
12.9.1 Введение ..................................... 43
12.9.2 Модули ................................... 43
12.10 Приложение Sample Temperature Sensor ....................... 43
12.10.1 Введение .......................... 43
12.10.2 Модули ..................................... 43
12.11 ОСНОВНЫЕ ФУНКЦИИ ............................................... 43
14. КЛАСТЕРЫ, КОМАНДЫ И АТРИБУТЫ ...........................................  47
14.1 АТРИБУТЫ .............................. 47
14.2 Пример добавления атрибута ...................... 47
14.3 Инициализация кластеров .......................... 48
14.4 КЛАСТЕРНАЯ АРХИТЕКТУРА ........................................... 48
14.5. Пример обратных вызовов кластера .................... 49
14.6 Функциональность отчетности по атрибутам ..................... 49
15. Commissioning - Ввод в эксплуатацию .............................. 51
15.1 BDB notifications - уведомления .............................. 51
15.2 ПРОЦЕДУРА ИНИЦИАЛИЗАЦИИ ......................................... 53
15.3 Parent Lost - Родитель потерян ................................. 53
15.4 Процедура управления сетью для узла в сети .................................. 54
15.5 Процедура управления сетью для узла, не находящегося в сети .................. 54
15.6 ФОРМИРОВАНИЕ СЕТИ ............................................... ..................................................  56
15.7 Поиск и привязка - Finding and Binding .............................................. .57
15.7.1 Процедура поиска и привязки для целевой конечной точки .................. 57
15.7.2 Процедура поиска и привязки для конечной точки инициатора ............ 58
15.8 Ввод в эксплуатацию Touchlink ............................................... 60
15.8.1 Конфигурации ..............................................  60
15.8.1.1 Установка ключа ............................................. 61
15.8.1.2 Константы .............................................. 61
15.8.1.3 Настройка конечной точки .............................. 61
15.8.1.4 Определение интервала времени последовательности ................... 62
15.8.1.5 Пороги разделения свободных диапазонов ............................. 62
15.8.1.6 Пороги разделения свободных диапазонов ............................ 62
15.8.2 Параметры только для разработки ...........................................  62
15.8.2.1 Смещение канала .............................................  62
15.8.2.2 Фиксированный выбор первого канала ...........................................  62
15.8.3 Процедура ввода в эксплуатацию Touchlink для инициатора ................ 62
15.8.4 Процедура ввода в действие Touchlink для цели ......................................... 63
15.9 ПРОЦЕДУРЫ СБРОСА ...............................................  64
15.9.1 Сброс через базовый кластер ........................................... 64
15.9.2 Сброс с помощью Кластера ввода в эксплуатацию Touchlink .................... 65
15.9.3 Сброс с помощью команды Mgmt_leave_req ZDO ........................ 65
15.9.4 Сброс через локальное действие ...........................................  65
15.9.5 Сброс через Nwk Leave request ..........................................  65
16. Сетевой менеджер - Network Manager .............................................. 66
16.1 ОБЗОР ................................................  66
16.2 Помехи в канале ...............................................  66
16.2.1 Обнаружение помех в канале ............................................ 66
16.2.2 Разрешение помех в канале ............................................  66
16.2.3 Краткое руководство ............................................. 67
16.3 Конфликт PAN ID ..............................................  67
16.3.1 Обнаружение конфликта PAN ID .................................... 68
16.3.2 Разрешение конфликтов PAN ID ...........................................  68
17. Сохранение питания - Green Power ..................................... 69
17.1 ВВЕДЕНИЕ ................................................ 69
17.2 Green Power Basic Proxy ............................................. 69
18.1 ОБЗОР ................................................ 70
18.2 ОБМЕН ДАННЫМИ ...............................................70
18.2.1 Краткое руководство ............................................. 71
19. Настройка ZMAC LQI ............................................. 72
19.1 ОБЗОР ................................................ 72
19.2 Режимы настройки LQI .............................................. 72
19.3 Использование настройки LQI..............................................  72
20. Управление Heap Memory ............................................. 73
20.1 ОБЗОР ................................................73
20.2 API ................................................  73
20.2.1 osal_mem_alloc () ............................................  73
20.2.1.1 Прототип .............................................. 73
20.2.1.2 Параметры ..............................................73
20.2.1.3 Возврат .............................................. 73
20.2.2 osal_mem_free () ............................................  73
20.2.2.1 Прототип .............................................. 73
20.2.2.2 Параметры .............................................. 73
20.2.2.3 Возврат ..............................................  74
20.3 СТРАТЕГИЯ ................................................ 74
20.4 ОБСУЖДЕНИЕ ................................................ 74
20.5 КОНФИГУРАЦИЯ ................................................  75
20.5.1 MAXMEMHEAP .............................................. 75
20.5.2 OSALMEM_PROFILER ..............................................  75
20.5.2.1 OSALMEM_INIT ..............................................  75
20.5.2.2 OSALMEM_ALOC ..............................................  75
20.5.2.3 OSALMEM_REIN .............................................. 75
20.5.2.4 OSALMEM_PROMAX ..............................................  75
20.5.3 OSALMEM_MIN_BLKSZ ..............................................  76
20.5.4 OSALMEM_SMALL_BLKSZ .............................................. 76
20.5.5 OSALMEM_SMALLBLK_BUCKET ..............................................  76
20.5.6 OSALMEM_NODEBUG .............................................. 76
20.5.7 OSALMEM_PROFILER_LL .............................................. 76
21. Опции компиляции .............................................. 78
21.1 ОБЗОР ................................................  78
21.2 ТРЕБОВАНИЯ ................................................ 78
21.2.1 Требования к целевой системе разработки .................................... 78
21.3 Использование опций компиляции Z-Stack ......................................... 78
21.3.1 Расположение параметров компиляции ................................. 78
21.3.1.1 Опции компиляции в управляющих файлах компоновщика ........................ 82
21.3.1.2 Параметры компиляции в файлах проекта IAR ......................................... 82
21.3.2 Использование параметров компиляции ........................ 83
21.4 Поддерживаемые параметры и определения компиляции .............................. 84
21.4.1 Общие параметры компиляции ............................................  84
21.4.2 Неизменяемые параметры компиляции ................................... 86
21.4.3 Опции компиляции Monitor-Test (MT) ..................................... 86
21.4.4 Опции компиляции ZigBee Device Object (ZDO) ................................. 86
 

1. Введение

1.1 Цель

В этом документе объясняются некоторые компоненты стека Texas Instruments ZigBee и их функционирование. Это объясняет настраиваемые параметры в стеке ZigBee и как они могут быть изменены разработчиком приложения соответствовать требованиям приложения.

1.2 Область применения

В этом документе описываются концепции и настройки для выпуска Texas Instruments Z-Stack ™. Это ZigBee-2015 совместимый стек для профилей стека ZigBee и ZigBee PRO. Здесь также объясняются дополнительные функции Z3.0 и как их можно настроить на совместимость с Z3.0 или устаревшими устройствами.

1.3 Определения, сокращения и сокращения

Термин  Определение
AF  Application Framework
AES  Расширенный стандарт шифрования
AIB  Информационная база APS
API  интерфейс прикладного программирования
APS Подуровень поддержки приложений
APSDE  APS Date Entity
APSME  APS Management Entity
ASDU  Сервисная датаграмма APS
BDB Поведение базового устройства
BSP  ПАКЕТ ПОДДЕРЖКИ BOARD - ВМЕСТЕ, HAL & OSAL СОСТАВЛЯЮТ РУДИМЕНТАРНЫЙ ОПЕРАЦИОННАЯ СИСТЕМА ОБЩАЯ ОТНОСИТСЯ К BSP
CCM * Расширенный счетчик с режимом работы CBC-MAC
EPID  Расширенный PAN ID
GP Green Power
GPD  Green Power Device
HAL  Аппаратный (H / W) уровень абстракции
MSG Сообщение 
MT  Z-Stack монитор и тестовый слой
NHLE  следующий объект более высокого уровня
NIB  Сетевая информационная база
NWK Сеть 
OSAL  Z-Stack Уровень абстракции операционной системы
OTA  по воздуху
PAN Персональная сеть
RSSI  получил индикатор силы сигнала
SE  Smart Energy
Sub-Device Функциональность автономного устройства в конечной точке приложения устройства Zigbee.
TC  Trust Center
TCLK  Trust Center Link Key Ключ ссылки Trust Center
ZCL  ZigBee Cluster Library
ZDO  ZigBee Device Object
ZHA  ZigBee Home Automation Домашняя автоматизация
ZC  ZigBee Coordinator
ZR  ZigBee Router
ZED  Конечное устройство ZigBee


1.4 Справочные документы

[1] Texas Instruments document SWRA195, Z-Stack API
[2] Texas Instruments document SWRA194, Z-Stack OSAL API
[3] Texas Instruments document SWRU354, Z-Stack 3.0 Sample Application User’s Guide.
[4] Texas Instruments document SWRA353, Z-Stack OTA Upgrade User’s Guide.
[5] ZigBee document 05-3474-21 ZigBee ZigBee Specification
[6] ZigBee document 07-5123-06 ZigBee Cluster Library Specificiation
[7] ZigBee document 13-0402-13 ZigBee Base Device Behavior
[8] ZigBee document 14-0563-16 ZigBee Green Power specification
 

2. ZigBee

Сеть ZigBee - это многосетевая сеть с устройствами на батарейках. Это означает, что два устройства, которые хотят обмен данными в сети ZigBee может зависеть от других промежуточных устройств, чтобы успешно так. Из-за этого кооперативного характера сети для правильного функционирования требуется, чтобы каждое устройство (i) выполняло конкретные сетевые функции и (ii) настроить определенные параметры для конкретных значений. Набор сетей Функции, которые выполняет устройство, определяют роль устройства в сети и называются типом устройства. Набор параметров, которые должны быть настроены на конкретные значения, наряду с этими значениями, называется профилем стека.

2.1 Типы устройств

В сети ZigBee существует три типа логических устройств: (i) Координатор (ii) Маршрутизатор и (iii) Конечное устройство.
Сеть ZigBee состоит из устройства с возможностями формирования (например, Координатор или Маршрутизатор) и нескольких Маршрутизаторов.
и узлы конечных устройств. Обратите внимание, что тип устройства никоим образом не ограничивает тип приложения, которое может работать на конкретное устройство.
Рисунок 1: Пример типичной сети ZigBee
 
Пример сети показан на рисунке 1 с координатором Coordinator ZigBee (черный), маршрутизаторами Routers (красный) и конечные устройства End Devices (белые).

2.1.1 Координатор

Координатор - это устройство с возможностями формирования сети, но без возможности присоединения к сети. Это значит можно только создать собственную сеть, но не присоединиться к существующим сетям. Чтобы создать сеть, узел-координатор сканирует РЧ среда для существующих сетей выбирает канал и идентификатор сети (также называемый идентификатором PAN), а затем запускает сеть. В Z3.0 это устройство создает централизованную сеть безопасности и уполномочено вести себя как траст центр Trust Center этой сети, что означает, что это устройство отвечает за управление безопасностью сети, и это единственное устройство, способное распространять ключи и позволяющее устройствам подключаться к созданной им сети.
Координирующий узел также может использоваться, при необходимости, для помощи в настройке привязок уровня приложения в сети.
Роль координатора в основном связана с запуском сети и управлением ключами, кроме того, он ведет себя как устройство маршрутизатора. Важно отметить, что сетевые процедуры, связанные с подключением или выходом устройств из сети должен присутствовать координатор, следовательно, он не может отсутствовать в своей собственной сети. Более подробная информация о безопасности схемы доступны в разделе 10.

2.1.2 Маршрутизатор

Маршрутизатор выполняет функции для (i) разрешения другим устройствам присоединяться к сети (ii) многопереходной маршрутизации (iii) помощи в
связь для своих дочерних конечных устройств. В Z3.0 это устройство было предоставлено с возможностями формирования, которые позволяют это создать распределенную сеть безопасности. Эта возможность формирования позволяет устройству маршрутизатора создавать сеть, которая не имеет менеджера по безопасности. Это означает, что после создания сети маршрутизатор, который ее создал не имеет особой роли в этой сети. Более подробная информация доступна в разделе 10.
Обычно маршрутизаторы должны быть активны все время и, следовательно, должны питаться от сети.

2.1.3 Конечное устройство

Конечное устройство не несет конкретной ответственности за поддержание сетевой инфраструктуры, поэтому оно может спать и просыпаться
так как он выбирает, таким образом, это может быть узел с питанием от батареи.
Как правило, требования к памяти (особенно к оперативной памяти) ниже для конечного устройства.
 
Примечания: 
В Z-Stack тип устройства обычно определяется во время компиляции с помощью параметров компиляции (ZDO_COORDINATOR и RTR_NWK). Все примеры приложений предоставляются с отдельными файлами проекта для создания каждого типа устройства.

2.2 Профиль стека

Набор параметров стека, которые должны быть настроены на конкретные значения, а также приведенные выше значения типа устройства, называется стековым профилем. Параметры, составляющие профиль стека, определяются Альянсом ZigBee.
Все устройства в сети должны соответствовать одному и тому же профилю стека (т. е. все устройства должны иметь профиль стека)
параметры настроены на одинаковые значения, если разработчики приложений решат изменить настройки для любого из этих параметров, они могут сделать это с оговоркой что эти устройства больше не смогут взаимодействовать с устройствами других поставщиков, которые решили следовать
ZigBee указанный профиль стека. Таким образом, разработчики «закрытых сетей» могут выбрать изменение настроек стека переменные профиля. Эти профили стека называются «сетевыми» профилями стека.
Идентификатор профиля стека, которому соответствует устройство, присутствует в маяке, передаваемом этим устройством. Это позволяет устройству определять профиль стека сети перед подключением к нему. «Специфичный для сети» профиль стека имеет идентификатор 0, в то время как устаревший профиль стека ZigBee имеет идентификатор 1, и профиль стека ZigBee PRO (который используется для Z3.0) имеет идентификатор 2. Профиль стека настраивается параметром STACK_PROFILE_ID в файле nwk_globals.h.
Профиль стека 3 зарезервирован для устройств Green Power и отображается в соответствующих кадрах.

3. Адресация

3.1 Типы адресов

Устройства ZigBee имеют два типа адресов. 64-битный адрес IEEE (также называемый MAC-адресом или расширенным адресом) и 16-битный сетевой адрес (также называемый логическим адресом или коротким адресом).
64-разрядный адрес является глобально уникальным адресом и назначается устройству на весь срок его службы. Обычно устанавливается производителем или во время установки. Эти адреса поддерживаются и распределяются IEEE. Больше информации как получить блок этих адресов можно узнать по адресу http://standards.ieee.org/regauth/oui/index.shtml. 16-битный адрес назначается устройству, когда оно подключается к сети, и предназначено для использования, когда оно находится в сети. Это только уникальный в этой сети. Он используется для идентификации устройств и отправки данных в сети.

3.2 Назначение сетевого адреса

3.2.1 Стохастическая адресация

ZigBee PRO использует стохастическую (случайную) схему адресации для назначения сетевых адресов. Это решение схема случайным образом назначает короткие адреса новым устройствам, а затем использует остальные устройства в сети для убедитесь, что нет повторяющихся адресов. Когда устройство подключается, оно получает случайно сгенерированный адрес от его родителя. Затем новый сетевой узел генерирует «Объявление устройства» Device Announce (которое содержит его новый короткий адрес и его расширенный адрес) для остальной части сети. Если есть другое устройство с таким же коротким адресом, узел (маршрутизатор) в сети отправит широковещательную рассылку «Состояние сети - адрес конфликта» Network Status – Address Conflict на всю сеть и на все устройства с конфликтующим коротким адресом изменит свой короткий адрес. Когда конфликтующие устройства меняют свой адрес, они выдают свое собственное «Объявление устройства» Device Announce, чтобы проверить свой новый адрес на наличие конфликтов в сети.
Конечные устройства не участвуют в «конфликте адресов» Address Conflict. Их родители делают это для них. Если «Адресный конфликт» происходит для конечного устройства, его родитель выдаст конечному устройству сообщение «Ответ о присоединении» Rejoin Response, чтобы изменить конечное устройство короткий адрес устройства и конечное устройство выдает «Device Announce», чтобы проверить новый адрес на наличие конфликтов в сети.
Когда получено «Объявление устройства» Device Announce, таблицы ассоциации и привязки обновляются новым коротким адресом, информация таблицы маршрутизации не обновляется (должны быть установлены новые маршруты). Если родитель определяет, что «Device Announce» относится к одному из его дочерних конечных устройств, но оно не пришло непосредственно от дочернего элемента, родитель предположил, что ребенок перешел к другому родителю.

3.3 Адресация в Z-Stack

Для отправки данных на устройство в сети ZigBee приложение обычно использует AF_DataRequest () функция. Устройство назначения, которому должен быть отправлен пакет, имеет тип afAddrType_t (определенный в ZComDef.h).
 
typedef struct
{
  union
{
  uint16 shortAddr;
  ZLongAddr_t extAddr;
} addr;
  afAddrMode_t addrMode;
  byte endPoint;
} afAddrType_t;
 
Обратите внимание, что в дополнение к сетевому адресу также необходимо указать параметр режима адреса. Назначение режим адреса может принимать одно из следующих значений (режимы адреса AF определены в AF.h)
 
typedef enum
{
  afAddrNotPresent = AddrNotPresent,
  afAddr16Bit = Addr16Bit,
  afAddr64Bit = Addr64Bit,
  afAddrGroup = AddrGroup,
  afAddrBroadcast = AddrBroadcast
} afAddrMode_t;
 
Параметр режима адреса необходим, потому что в ZigBee пакеты могут быть одноадресными, многоадресными или широковещательными.
Одноадресный пакет отправляется на одно устройство, многоадресный пакет предназначен для группы устройств, а широковещательный пакет как правило, отправляется на все устройства в сети. Это объясняется более подробно ниже.

3.3.1 Одноадресная передача - Unicast

Это нормальный режим адресации, который используется для отправки пакета одному устройству, сетевой адрес которого известен.
Для addrMode задано значение Addr16Bit, а сетевой адрес назначения передается в пакете.

3.3.2 Косвенный - Indirect

Это когда приложение не знает о конечном пункте назначения пакета. Режим установлен на AddrNotPresent и адрес назначения не указан. Вместо этого пункт назначения ищется от «Таблица привязок» binding table, которая находится в стеке отправляющего устройства. Эта функция называется привязкой исходного кода (см. Следующий раздел для деталей по переплету).
Когда пакет отправляется в стек, адрес назначения и конечная точка ищутся из таблицы привязок и использовал. Пакет затем обрабатывается как обычный одноадресный пакет. Если в таблице привязки копия пакета отправляется каждому из них. Если связывающая запись не найдена, пакет не будет тправлен.

3.3.3 Трансляция - Broadcast

Этот режим адреса используется, когда приложение хочет отправить пакет всем устройствам в сети. Адрес режим установлен на AddrBroadcast, а адрес назначения может быть установлен на один из следующих широковещательных адресов:
 
NWK_BROADCAST_SHORTADDR_DEVALL (0xFFFF) - сообщение будет отправлено на все устройства в сети (включает в себя спящие устройства). Для спящих устройств сообщение удерживается у его родителя, пока спящее устройство не опрашивает это или сообщение истекло (NWK_INDIRECT_MSG_TIMEOUT в f8wConfig.cfg).
NWK_BROADCAST_SHORTADDR_DEVRXON (0xFFFD) - сообщение будет отправлено на все устройства, которые имеют приемник в режиме ожидания (RXONWHENIDLE). То есть все устройства, кроме спящих устройств.
NWK_BROADCAST_SHORTADDR_DEVZCZR (0xFFFC) - сообщение отправляется всем маршрутизаторам (включая координатор).

3.3.4 Групповая адресация - Group Addressing

Этот режим адреса используется, когда приложение хочет отправить пакет группе устройств. Режим адреса устанавливается в afAddrGroup, а в addr.shortAddr устанавливается идентификатор группы.
Перед использованием этой функции необходимо определить группы в сети, см. Aps_AddGroup () в API Z-Stack [1] документ.
Обратите внимание, что группы могут также использоваться в сочетании с косвенной адресацией. Адрес назначения найденый в таблице привязок может быть одноадресной или групповой адрес. Также обратите внимание, что широковещательная адресация - это просто особый случай групповой адресации, где группы настроены заранее.
Пример кода для устройства, чтобы добавить себя в группу с идентификатором 1:
 
aps_Group_t group;
// Assign yourself to group 1
group.ID = 0x0001;
group.name[0] = 6; // First byte is string length
osal_memcpy( &(group.name[1]), “Group1”, 6);
aps_AddGroup( SAMPLEAPP_ENDPOINT, &group );

3.4 Важные адреса устройств - Important Device Addresses

Приложению может потребоваться узнать адрес своего устройства и адрес его родителя. Используйте следующие функции, чтобы получить адрес этого устройства, определенный в документе Z-Stack API [1]:
  • NLME_GetShortAddr () - возвращает 16-битный сетевой адрес этого устройства.
  • NLME_GetExtAddr () - возвращает 64-разрядный расширенный адрес этого устройства.
  • Используйте следующие функции, чтобы получить адреса родительского устройства, определенные в документе Z-Stack API [1].
Обратите внимание, что термин «Coord» в этих функциях относится не к координатору ZigBee, а к родителю устройства (MAC Coordinator):
  • NLME_GetCoordShortAddr () - возвращает 16-битный короткий адрес родителя этого устройства.
  • NLME_GetCoordExtAddr () - возвращает 64-битный расширенный адрес родительского устройства.

4. Привязка - Binding

Привязка - это механизм управления потоком сообщений из одного приложения в другое (или несколько Приложения). Механизм привязки реализован во всех устройствах и называется привязкой источника. Привязка позволяет приложению отправлять пакет, не зная адреса назначения, уровень APS определяет адрес назначения из таблицы привязок, а затем пересылает сообщение в приложение назначения (или несколько приложений) или группа.

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

Существует 4 способа создания таблицы привязок:
  • Запрос привязки объекта устройства ZigBee Device Bind Request - инструмент ввода в эксплуатацию может сказать устройству сделать запись привязки.
  • Запрос на привязку конечного устройства к объекту ZigBee Device Object End Device Bind Request - 2 устройства могут сообщить координатору, что они хотели бы настроить запись таблицы привязок. Координатор выполнит сопоставление и создаст записи таблицы привязки в 2 устройства.
  • Приложение устройства Device Application - Приложение на устройстве может создавать или управлять таблицей привязок.
  • Поиск и привязка Finding and Binding процесса ввода в эксплуатацию для устройств-инициаторов.

4.1.1 Запрос привязки объекта устройства - ZigBee Device Object Bind Request

Любое устройство или приложение может отправить сообщение ZDO на другое устройство (по беспроводной сети), чтобы создать запись привязки для этого другое устройство в сети. Это называется Assisted Binding и создаст запись привязки для отправляющего устройства.

4.1.1.1 Заявка на ввод в эксплуатацию

Приложение может сделать это, вызвав ZDP_BindReq () [определенный в ZDProfile.h] с двумя приложениями (адреса и конечные точки) и идентификатор кластера, требуемый в записи привязки. Первый параметр (target dstAddr) короткий адрес исходного адреса привязки (где будет храниться запись привязки). Вызов ZDP_UnbindReq () может использоваться с теми же параметрами для удаления записи привязки.
Целевое устройство отправит ответное сообщение «Привязать или отменить привязку объекта устройства ZigBee», в котором указан код ZDO координатор проанализирует и уведомит ZDApp.c, вызвав ZDApp_ProcessMsgCBs () со статусом действие.
Для ответа Bind статус, возвращаемый координатором, будет ZDP_SUCCESS, ZDP_TABLE_FULL, ZDP_INVALID_EP или ZDP_NOT_SUPPORTED.
Для ответа Unbind статус, возвращаемый координатором, будет ZDP_SUCCESS, ZDP_NO_ENTRY, ZDP_INVALID_EP или ZDP_NOT_SUPPORTED.

4.1.1.2 Запрос привязки конечного устройства объекта - ZigBee Device Object End Device Bind Request

Этот механизм использует нажатие кнопки или другое подобное действие на выбранных устройствах для привязки в течение определенного времени
период. Сообщения запроса на привязку конечного устройства собираются координатором в течение периода ожидания и результирующая запись в таблице привязок создается на основе согласования идентификатора профиля и идентификатора кластера. Конечное устройство по умолчанию
время ожидания привязки (APS_DEFAULT_MAXBINDING_TIME) составляет 16 секунд (определено в nwk_globals.h), но может быть изменено, если добавлено в f8wConfig.cfg или как флаг компиляции.
Для процесса привязки конечного устройства координатора координатор зарегистрировал ZD_RegisterForZDOMsg () для получать сообщения ZDO запроса привязки конечного устройства, ответа привязки и ответа отмены привязки в ZDApp_RegisterCBs (), определенный в ZDApp.c. Когда эти сообщения получены, они отправляются ZDApp_ProcessMsgCBs (), где они анализируются и обрабатываются.
Привязка конечного устройства координатора является процессом переключения. Это означает, что при первом прохождении процесса создайте обязательную запись в запрашивающих устройствах. Затем, когда вы пройдете этот процесс снова, он удалит привязки в запрашивающих устройствах. Вот почему в следующем процессе он отправит unbind и будет ждать отмена была успешной. Если отмена была успешной, обязательная запись должна была существовать и быть удалена, в противном случае он отправляет обязательный запрос на создание записи.
Когда координатор получит 2 соответствующих запроса на привязку конечного устройства, он начнет процесс создания источника связывание записей в запрашивающих устройствах. Координатор выполняет следующий процесс, предполагая, что совпадения были находится в запросах на привязку конечного устройства ZDO:
1. Отправьте запрос на отмену привязки ZDO на первое устройство. Привязка конечного устройства - это процесс переключения, поэтому отмена
отправляется первым, чтобы удалить существующую запись связывания.
2. Дождитесь ответа отмены привязки ZDO. Если статус ответа ZDP_NO_ENTRY, отправьте привязку ZDO
Запрос сделать обязательную запись в исходном устройстве. Если статус ответа ZDP_SUCCESS, перейти к идентификатору кластера для первого устройства (отмена привязки удалила запись - переключение).
3. Дождитесь ответа ZDO Bind. После получения перейдите к следующему идентификатору кластера для первого устройства.
4. Когда первое устройство выполнено, проделайте тот же процесс со вторым устройством.
5. Когда второе устройство будет готово, отправьте сообщения ответа привязки конечного устройства ZDO обоим первым и второе устройство.

4.1.2 Диспетчер привязки приложений устройства

Другой способ ввода записей привязки на устройстве - приложение для управления таблицей привязки для себя.
Это означает, что приложение будет вводить и удалять записи таблицы привязок локально, вызывая следующую привязку функции управления таблицами, см. Z-Stack API [1] Документ - раздел Управление таблицами привязки:
  • bindAddEntry () - Добавить запись в таблицу привязок
  • bindRemoveEntry () - Удалить запись из таблицы привязок.
  • bindRemoveClusterIdFromList () - удаление идентификатора кластера из существующей записи таблицы привязок
  • bindAddClusterIdToList () - добавить идентификатор кластера в существующую запись таблицы привязок
  • bindRemoveDev () - удаляет все записи с адресной ссылкой
  • bindRemoveSrcDev () - удаляет все записи с указанным исходным адресом.
  • bindUpdateAddr () - обновить записи на другой адрес
  • bindFindExisting () - Найти запись таблицы привязки
  • bindIsClusterIDinList () - проверка существующего идентификатора кластера в записи таблицы
  • bindNumBoundTo () - Количество записей с одинаковым адресом (источник или место назначения)
  • bindNumOfEntries () - Количество записей в таблице
  • bindCapacity () - максимально допустимое количество записей
  • BindWriteNV () - обновить таблицу в NV.

4.1.3 Нахождение и привязка - Finding and binding

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

4.2 Настройка привязки источника

Чтобы включить привязку источника на вашем устройстве, включите флаг компиляции REFLECTOR в f8wConfig.cfg. Также в f8wConfig.cfg, посмотрите на 2 элемента конфигурации привязки (NWK_MAX_BINDING_ENTRIES & MAX_BINDING_CLUSTER_IDS). NWK_MAX_BINDING_ENTRIES - максимальное количество записей в таблица привязок и MAX_BINDING_CLUSTER_IDS - максимальное количество идентификаторов кластера в каждой записи привязки.
Таблица привязок поддерживается в статическом ОЗУ (не выделяется), поэтому количество записей и номер кластера идентификаторы для каждой записи действительно влияют на объем используемой оперативной памяти. Каждая запись таблицы привязки составляет 6 байтов плюс (MAX_BINDING_CLUSTER_IDS * 2 байта). Помимо количества статической памяти, используемой таблицей привязки, привязка элементов конфигурации также влияет на количество записей в менеджере адресов.

5. Маршрутизация - Routing

5.1 Обзор

Ячеистая сеть описывается как сеть, в которой маршрутизация сообщений выполняется как децентрализованная, совместный процесс, включающий маршрутизацию множества одноранговых устройств от имени друг друга.
Маршрутизация полностью прозрачна для прикладного уровня. Приложение просто отправляет данные, предназначенные для любого устройства до стека, который затем отвечает за поиск маршрута. Таким образом, приложение не знает о дело в том, что он работает в многоскачковой сети.
Маршрутизация также обеспечивает «самовосстановление» природы сетей ZigBee. Если определенная беспроводная связь не работает, маршрутизация
функции в конечном итоге найдут новый маршрут, который позволит избежать этой конкретной неработающей ссылки. Это значительно усиливает надежность беспроводной сети и является одной из ключевых особенностей ZigBee.
Маршрутизация «многие к одному» - это специальная схема маршрутизации, которая обрабатывает сценарий, в котором задействован централизованный трафик. Это часть набора функций ZigBee PRO, чтобы помочь минимизировать трафик, особенно когда все устройства в сети отправка пакетов на шлюз или концентратор данных. Обнаружение маршрута многие-к-одному подробно описано в разделе 5.4.

5.2 Протокол маршрутизации - Routing protocol

ZigBee использует протокол маршрутизации, основанный на протоколе маршрутизации AODV (Ad-hoc Distance On Vector) для специальных сетей. Упрощенный для использования в сенсорных сетях, протокол маршрутизации ZigBee облегчает среду способен поддерживать мобильные узлы, сбои соединения и потери пакетов.
Соседние маршрутизаторы - это маршрутизаторы, которые находятся в радиусе действия радиосвязи друг от друга. Каждый маршрутизатор отслеживает своих соседей в «таблица соседей» neighbor table, и «таблица соседей» neighbor table обновляется, когда маршрутизатор получает любое сообщение от соседнего маршрутизатора (одноадресная, трансляция или маяк).
Когда маршрутизатор получает одноадресный пакет от своего приложения или от другого устройства, уровень NWK пересылает его согласно следующей процедуре. Если пункт назначения является одним из соседей маршрутизатора (включая его дочерний элемент устройства) пакет будет передан непосредственно на устройство назначения. В противном случае роутер проверит свою маршрутизацию таблица для записи, соответствующей пункту назначения пакета. Если есть активная запись в таблице маршрутизации для адрес назначения, пакет будет ретранслирован на адрес следующего перехода, сохраненный в записи маршрутизации. Если первая попытка передачи не удалась, уровень NWK будет повторять процесс передачи пакета и ожидания подтверждение, максимум до NWK_MAX_DATA_RETRIES раз. Максимальное количество повторов данных в NWK слой можно настроить в файле f8wconfig.cfg. Если активная запись не может быть найдена в таблице маршрутизации или с использованием сбой записи после максимального числа попыток, обнаружение маршрута инициируется и пакет буферизуется до тех пор пока процесс завершен.
Конечные устройства ZigBee не выполняют никаких функций маршрутизации. Конечное устройство, желающее отправить пакет на любое устройство
просто пересылает его на родительское устройство, которое будет выполнять маршрутизацию от его имени. Точно так же, когда любое устройство
желает отправить пакет на конечное устройство и инициировать обнаружение маршрута, родитель конечного устройства отвечает на его от имени.
Обратите внимание, что схема назначения ZigBee Tree Addressing (non-PRO) позволяет получить маршрут к любому пункту назначения на основе его адреса. В Z-Stack этот механизм используется как автоматический запасной вариант в случае регулярного процедура маршрутизации не может быть инициирована (обычно из-за отсутствия табличного пространства маршрутизации).
Также в Z-Stack реализация маршрутизации оптимизировала хранение таблицы маршрутизации. В общем, таблица маршрутизации запись необходима для каждого устройства назначения. Но путем объединения всех записей для конечных устройств конкретного родителя благодаря записи для этого родительского устройства хранилище оптимизируется без потери какой-либо функциональности.
Маршрутизаторы ZigBee, включая координатора, выполняют следующие функции маршрутизации (i) обнаружение и выбор маршрута (ii) обслуживание маршрута (iii) истечение срока действия маршрута.

5.2.1 Обнаружение и выбор маршрута - Route Discovery and Selection

Обнаружение маршрутов - это процедура, посредством которой сетевые устройства взаимодействуют для поиска и установления маршрутов через сеть. Обнаружение маршрута может быть инициировано любым устройством-маршрутизатором и всегда выполняется в отношении определенного устройства назначения. Механизм обнаружения маршрутов ищет все возможные маршруты между источником и пунктом назначения устройства и пытается выбрать оптимальный маршрут.
Выбор маршрута осуществляется путем выбора маршрута с наименьшей возможной стоимостью. Каждый узел постоянно отслеживает «Ссылка стоит» link costs всем своим соседям. Стоимость линии связи обычно является функцией мощности принятого сигнала. По суммируя стоимость ссылок для всех ссылок вдоль маршрута, получается «стоимость маршрута» route cost для всего маршрута. Алгоритм маршрутизации пытается выбрать маршрут с наименьшей «стоимостью маршрута» route cost.
Маршруты обнаруживаются с использованием пакетов запроса / ответа. Исходное устройство запрашивает маршрут для адреса назначения путем широковещательной рассылки пакета запроса маршрута (RREQ) своим соседям. Когда узел получает пакет RREQ, он по очереди ретранслирует пакет RREQ. Но перед этим он обновляет поле стоимости в пакете RREQ, добавляя стоимость ссылки для последней ссылки и вносится в ее таблицу  обнаружения маршрутов (5.3.2). Таким образом, пакет RREQ несет сумму стоимости ссылки по всем ссылкам, которые он пересекает. Этот процесс повторяется, пока RREQ не достигнет устройство назначения. Многие копии RREQ достигнут устройства назначения, путешествующего через различные возможные маршруты. Каждый из этих пакетов RREQ будет содержать общую стоимость маршрута по маршруту, который он прошел. Назначение устройство выбирает наилучший пакет RREQ и отправляет ответ Route Reply (RREP) обратно источнику.
RREP является одноадресным по обратным маршрутам промежуточных узлов, пока не достигнет исходного запрашивающего узла.
Когда пакет RREP возвращается к источнику, промежуточные узлы обновляют свои таблицы маршрутизации, чтобы указать маршрут к месту назначения. Таблица обнаружения маршрута на каждом промежуточном узле используется для определения следующего перехода RREP возвращается к источнику RREQ и делает запись в Таблице маршрутизации.
Как только маршрут создан, пакеты данных могут быть отправлены. Когда узел теряет подключение к следующему прыжку (он не получает MAC ACK при отправке пакетов данных), узел делает недействительным свой маршрут, отправляя RERR всем узлам, которые потенциально получил свой RREP и помечает ссылку как плохую в соседней таблице. После получения RREQ, RREP или RERR, узлы обновляют свои таблицы маршрутизации.

5.2.2 Обслуживание маршрута - Route maintenance

Сетчатые сети обеспечивают обслуживание маршрута и самовосстановление. Промежуточные узлы отслеживают сбои передачи по ссылке. Если связь (между соседями) определена как плохая, вышестоящий узел инициирует восстановление маршрута для всех маршруты, которые используют эту ссылку. Это делается путем инициации повторного обнаружения маршрута при следующем поступлении пакета данных для этотого маршрут. Если повторное обнаружение маршрута не может быть инициировано или по какой-то причине не удается, пакет ошибок маршрута (RERR) отправляется обратно к источнику пакета данных, который затем отвечает за инициирование обнаружения нового маршрута. Так или иначе маршрут будет восстановлен автоматически.

5.2.3 Срок действия маршрута - Route expiry

Таблица маршрутизации поддерживает записи для установленных маршрутов. Если никакие пакеты данных не отправляются по маршруту в течение периода время маршрут будет помечен как просроченный. Истекшие маршруты не удаляются, пока не потребуется место. Таким образом, маршруты не
удаляется пока не станет абсолютно необходимым. Время истечения автоматического маршрута можно настроить в файле f8wconfig.cfg.
Установите ROUTE_EXPIRY_TIME на время истечения в секундах. Установите в 0, чтобы отключить функцию истечения маршрута.

5.3 Таблица хранения - Table storage

Функции маршрутизации требуют, чтобы маршрутизаторы поддерживали некоторые таблицы.

5.3.1 Таблица маршрутизации - Routing table

Каждый маршрутизатор ZigBee, включая координатор ZigBee, содержит таблицу маршрутизации, в которой хранится устройство информация, необходимая для участия в маршрутизации пакетов. Каждая запись в таблице маршрутизации содержит пункт назначения адрес, узел следующего перехода и статус ссылки. Все пакеты, отправленные на адрес назначения, направляются через следующий узел прыжка. Кроме того, записи в таблице маршрутизации могут истечь, чтобы восстановить табличное пространство из записей, которые больше не являются в использовании.
Емкость таблицы маршрутизации указывает на то, что в таблице маршрутизации устройства есть свободная запись в таблице маршрутизации, или она уже имеет маршрутизацию запись таблицы, соответствующая адресу назначения. Размер таблицы маршрутизации настраивается в файле f8wconfig.cfg.
Установите для MAX_RTG_ENTRIES количество записей в (по умолчанию 40). Смотрите раздел по обслуживанию маршрутов для
Сведения об окончании маршрута.

5.3.2 Таблица обнаружения маршрутов - Route discovery table

Устройства маршрутизатора, участвующие в обнаружении маршрута, ведут таблицу обнаружения маршрута. Эта таблица используется для временного хранения информация во время обнаружения маршрута. Эти записи действуют только на время операции обнаружения маршрута. По истечении срока действия записи ее можно использовать для другой операции обнаружения маршрута. Таким образом, это значение определяет максимальное количество обнаружений маршрута, которые могут быть одновременно выполнены в сети. Это значение настраивается путем установки MAX_RREQ_ENTRIES в f8wconfig.cfg.

5.4 Протокол маршрутизации «многие к одному» - Many-to-One Routing Protocol

Далее поясняется процедура маршрутизации «многие к одному» и «источник» many-to-one and source для лучшего понимания пользователями маршрутизации ZigBee протокол. В действительности все маршрутизации выполняются на сетевом уровне и прозрачны для приложения. Выдача много-
одно обнаружение маршрута и обслуживание маршрута являются решениями приложения.

5.4.1 Обзор маршрутизации «многие к одному» - Many-to-One Routing Overview

Многоуровневая маршрутизация принята в ZigBee PRO, чтобы помочь минимизировать трафик, особенно когда централизованные узлы участвует. В беспроводных сетях с низким энергопотреблением обычно используется устройство, выполняющее роль шлюза или концентратора данных.
Все узлы в сетях должны поддерживать хотя бы один действительный маршрут к центральному узлу. Для достижения этого все узлы имеют инициировать обнаружение маршрута для концентратора, опираясь на существующее решение маршрутизации на основе ZigBee AODV широковещательные запросы на маршрутизацию сложатся и приведут к огромным накладным расходам сетевого трафика чтобы лучше оптимизировать маршрутизацию решение позволяет использовать маршрутизацию «многие к одному», чтобы концентратор данных мог устанавливать маршруты из всех узлов в сеть с одним обнаружением маршрута и минимизировать широковещательный шторм обнаружения обнаружения маршрута.
Исходная маршрутизация является частью маршрутизации «многие к одному», которая предоставляет концентратору эффективный способ отправки ответа или подтверждение обратно в пункт назначения. Концентратор размещает полную информацию о маршруте от концентратор к месту назначения в кадре данных, который должен быть передан. Минимизирует размер таблицы маршрутизации и маршрут обнаружения трафика в сети.

5.4.2 Обнаружение маршрута «многие к одному» - Many-to-One Route Discovery

На следующем рисунке показан пример процедуры обнаружения маршрута «многие к одному». Инициировать много-к-одному обнаружение маршрута, концентратор передает широковещательный запрос «многие к одному» по всей сети. После получения запрос маршрута, каждое устройство добавляет запись таблицы маршрутов для концентратора и сохраняет соседа с одним переходом, который ретранслирует запрос в качестве адреса следующего перехода. Ответ маршрута не будет сгенерирован.
 
Рисунок 2: Иллюстрация обнаружения маршрута многие-к-одному
 
Команда запроса маршрута «многие к одному» аналогична команде запроса маршрута одноадресной передачи с тем же идентификатором команды и
формат кадра полезной нагрузки. Поле опции в запросе маршрута - «многие к одному», а адрес назначения - 0xFFFC.
Следующий API Z-Stack может использоваться концентратором для отправки запроса маршрута «многие к одному». Пожалуйста, обратитесь к ZStack Документация API [1] для подробного использования этого API.
 
ZStatus_t NLME_RouteDiscoveryRequest( uint16 DstAddress,
byte options, uint8 radius )
 
Поле параметров является битовой маской, чтобы указать параметры для запроса маршрута. Может иметь следующие значения:
 
Значение Описание 
0x00 Открытие одноадресного маршрута
0x01 
Обнаружение маршрута многие-к-одному с кешем маршрута (концентратор не имеет ограничений памяти).
0x03  Обнаружение маршрута многие-к-одному без кэша маршрутов (концентратор имеет ограничения памяти)
Если поле параметра имеет значение 0x01 или 0x03, поле DstAddress будет перезаписано множеством к одному адрес назначения 0xFFFC. Следовательно, пользователь может передать любое значение DstAddress в случае маршрута «многие к одному» запрос.

5.4.3 Команда записи маршрута - Route Record Command

Вышеупомянутая процедура обнаружения маршрутов "многие к одному" устанавливает маршруты от всех устройств до концентратора.
Обратная маршрутизация (от концентратора к другим устройствам) осуществляется с помощью команды route record (исходная схема маршрутизации).
Процедура маршрутизации источника показана на рисунке 3. R1 отправляет пакет данных DATA концентратору, используя ранее установленный маршрут «многие к одному» и ожидает подтверждения. Чтобы предоставить маршрут для концентратор для отправки ACK обратно, R1 отправляет команду записи маршрута вместе с пакетом данных, который записывает путь маршрутизации, через который проходит пакет данных, и концентратор предлагает обратный путь для отправки ACK обратно.
 
 
Рисунок 3: Иллюстрация команды записи маршрута (исходная маршрутизация)
 
После получения команды записи маршрута устройства на пути ретрансляции будут добавлять свои собственные сетевые адреса к список ретрансляции в полезной нагрузке команды записи маршрута. К тому времени, когда команда записи маршрута достигает концентратора, она включает в себя полный путь маршрутизации, по которому пакет данных передается на концентратор. Когда концентратор отправляет ACK обратно на R1, он должен включить исходный маршрут (список ретрансляции) в заголовок сетевого уровня пакет. Все устройства, принимающие пакет, должны ретранслировать пакет на устройство следующего перехода в соответствии с исходным маршрутом.
Для концентратора без ограничений памяти он может хранить все записи записей маршрута, которые он получает, и использовать их для отправки
пакеты на исходные устройства в будущем. Поэтому устройства должны отправлять команду записи маршрута только один раз.
Однако для концентратора без возможности кэширования исходного маршрута устройства всегда должны отправлять запись маршрута.
Команды вместе с пакетами данных. Концентратор временно сохранит исходный маршрут в памяти, а затем откажитесь от него после использования.
Вкратце, маршрутизация «многие к одному» является эффективным улучшением обычной одноадресной маршрутизации ZigBee, когда большинство устройств в сети проходят трафик на одно устройство. Как часть маршрутизации «многие к одному», исходная маршрутизация используется при определенных обстоятельствах. Во-первых, он используется, когда концентратор отвечает на запрос, инициированный исходное устройство. Во-вторых, концентратор должен хранить информацию об исходном маршруте для всех устройств, если он имеет достаточно памяти. Если нет, то всякий раз, когда устройства выдают запрос концентратору, они также должны отправлять запись маршрута вместе с ним.

5.4.4 Обслуживание маршрута «многие к одному» - Many-to-One Route Maintenance

Если во время пересылки перенаправленного кадра «многие к одному» устройство обнаруживает сбой соединения (обратите внимание, что «многие к одному») сам маршрутизируемый кадр не отличается от обычного одноадресного пакета данных, однако запись в таблице маршрутизации имеет поле
чтобы указать, что пункт назначения является концентратором), устройство сгенерирует команду состояния сети с кодом «Сбой маршрута многие-к-одному» Many-to-one route failure. Команда состояния сети будет передана на концентратор через случайный сосед и, надеюсь, у этого соседа еще есть действующий маршрут к концентратору. Когда концентратор получает сбой маршрута, приложение решит, следует ли повторно выполнить запрос маршрута «многие к одному».
Когда концентратор получает команду состояния сети, указывающую сбой маршрута «многие к одному», он передает индикация уровню ZDO и вызывается следующая функция обратного вызова ZDO в ZDApp.c:
 
void ZDO_ManytoOneFailureIndicationCB ()
 
По умолчанию эта функция повторяет обнаружение маршрутов «многие к одному» для восстановления маршрутов. Вы можете изменить эту функцию
если вы хотите более сложный процесс, чем по умолчанию.

5.5 Краткая справка по настройке маршрутизации

Настройка размера таблицы маршрутизации
Set MAX_RTG_ENTRIES
Примечание: значение должно быть больше 4. (См.f8wConfig.cfg)
Установка времени истечения маршрута Set ROUTE_EXPIRY_TIME на время истечения в секундах. Установлен в 0, чтобы отключить истечение маршрута. (См. F8wConfig.cfg)
Настройка размера таблицы обнаружения маршрутов Set MAX_RREQ_ENTRIES максимальное количество в сети разрешено одновременное обнаружение маршрутов. (см. f8wConfig.cfg)
Включить концентратор Set CONCENTRATOR_ENABLE (см. ZGlobals.h)
Настройка свойства концентратора - Кэш-память с маршрутом Set CONCENTRATOR_ROUTE_CACHE (See ZGlobals.h)
Установка размера таблицы маршрутизации источника Set MAX_RTG_SRC_ENTRIES (See ZGlobals.h)
Настройка радиуса радиопередачи по умолчанию Set CONCENTRATOR_RADIUS (See ZGlobals.h)

5.6 Очистка маршрутизатора вне сети - Router Off-Network Association Cleanup

В случае, если маршрутизатор ZigBee выходит из сети на длительный период времени, его дочерние элементы будут пытаться присоединиться к альтернативному родителю.
Когда маршрутизатор снова подключен, дочерние элементы все еще будут отображаться в его дочерней таблице, предотвращая правильную маршрутизацию выхода трафик к ним.
Во избежание этого рекомендуется, чтобы маршрутизаторы, склонные к отключению и находящиеся в сети, имели для флага zgRouterOffAssocCleanup установлено значение TRUE (сопоставлено с элементом NV:
ZCD_NV_ROUTER_OFF_ASSOC_CLEANUP):
uint8 cleanupChildTable = TRUE;
zgSetItem (ZCD_NV_ROUTER_OFF_ASSOC_CLEANUP, sizeof (cleanupChildTable),
& cleanupChildTable);
Если этот параметр включен, устаревшие записи конечных устройств будут удаляться из дочерней таблицы, если трафик, полученный от них, был
маршрутизируется другим родителем.

6. Запросы сообщений ZDO - ZDO Message Requests

Модуль ZDO предоставляет функции для отправки сообщений с запросом на обнаружение услуги ZDO и получения услуги ZDO ответные сообщения об обнаружении. Следующая блок-схема иллюстрирует вызовы функций, необходимые для выдачи IEEE запрос адреса и получение ответа адреса IEEE для приложения.
 
Рисунок 4: запрос и ответ ZDO IEEE Address
 
В следующем примере приложение хотело бы знать, когда какие-либо новые устройства присоединяются к сети. Приложение хотело бы получать все объявления устройства ZDO
 
 
Рисунок 5: Объявление устройства ZDO доставлено приложению
 

7. Портативные устройства - Portable Devices

Конечное устройство обнаруживает, что родитель не отвечает ни из-за сбоев опроса (запросов данных MAC), и / или через сбои сообщений данных. Чувствительность к сбоям (количество последовательных ошибок) контролируется настройкой has_pollFailureRetries = true и pollFailureRetries для количества сбоев (чем выше число - чем менее чувствительно и тем дольше будет возвращаться), в zstack_sysConfigWriteReq_t при вызове
в Zstackapi_sysConfigWriteReq ().
Когда сетевой уровень обнаруживает, что его родитель не отвечает, он уведомляет приложение, что он потерял своего родителя.
Через интерфейс BDB (см. раздел 15.3), тогда приложение отвечает за управление воссоединением устройство с помощью BDB API bdb_ZedAttemptRecoverNwk () (описана в [1]), который будет запускать процесс сканирования канала, на котором было запущено это устройство, с целью поиска другого подходящего родителя устройство. Рекомендуется, чтобы, как только конечное устройство потеряло своего родителя, оно попыталось восстановить. Если восстановление не удается, устройство должно повторить попытку после небольшой задержки, и, если оно все еще выходит из строя, оно должно периодически повторять попытку с большим ожиданием период. Эта практика обеспечивает лучшее энергопотребление на конечном устройстве и не мешает другим сетям, которые может быть на том же канале.
В защищенных сетях предполагается, что устройство уже имеет ключ, и новый ключ не выдается устройству.
Короткий адрес конечного устройства сохраняется при переходе от родителя к родителю; маршруты к таким конечным устройствам восстанавливаются
автоматически.

8. Сквозные подтверждения - End-to-end acknowledgements

Для не широковещательных сообщений существует в основном 2 типа повторной отправки сообщения: сквозное подтверждение (APS ACK) и подтверждение одного перехода (MAC ACK). MAC ACK всегда включены по умолчанию и обычно достаточно, чтобы гарантировать высокую степень надежности в сети. Для обеспечения дополнительной надежности, а также для включить отправляющее устройство, получить подтверждение, что пакет был доставлен к месту назначения, APS подтверждения могут быть использованы.
Подтверждение APS выполняется на уровне APS и является системой подтверждения от устройства назначения к исходное устройство. Отправляющее устройство будет удерживать сообщение, пока целевое устройство не отправит ACK APS сообщение, указывающее, что оно получило сообщение. Эта функция может быть включена / отключена для каждого сообщения, отправленного с поле параметров вызова AF_DataRequest (). Поле опций - это битовая карта опций, поэтому ИЛИ в AF_ACK_REQUEST, чтобы включить APS ACK для сообщения, которое вы отправляете. Количество раз, что
сообщение повторяется (если сообщение APS ACK не получено), и время ожидания между повторными попытками является элементами конфигурации в
f8wConfig.cfg. APSC_MAX_FRAME_RETRIES - количество попыток, которые уровень APS отправит сообщение, если он не получил ACK APS, прежде чем сдаться. APSC_ACK_WAIT_DURATION_POLLED - время между попытками.

9. Разное

9.1 Настройка канала

Каждое устройство Z3.0 имеет конфигурацию маски основного канала (BDB_DEFAULT_PRIMARY_CHANNEL_SET) и конфигурация маски вторичного канала (BDB_DEFAULT_SECONDARY_CHANNEL_SET). Для устройств с возможности формирования, которые были поручены для создания сети, эти каналы маски используются при сканировании для канал с наименьшим количеством шума для создания сети. Для устройств с возможностями соединения, которые были при указании присоединиться к сети эти маски каналов используются при сканировании существующих сетей для присоединения. Устройство сначала попробует все каналы, определенные в маске первичного канала, а затем, если процесс не будет успешным (
сеть не была создана или не была найдена сеть для присоединения) используется маска вторичного канала. Эти два канала маски могут быть настроены приложением по мере необходимости. Значение 0 в одной из этих масок отключит соответствующие фаза сканирования канала (первичная или вторичная). Маска основного канала по умолчанию определена равной DEFAULT_CHANLIST (в f8wConfig.cfg), а маска вторичного канала определяется как все остальные каналы (т.е. DEFAULT_CHANLIST ^ 0x07FFF800). Раздел 15 содержит более подробную информацию о вводе в эксплуатацию
методы.

9.2 Настройка PAN ID и сети для подключения

Это необязательный элемент конфигурации, позволяющий контролировать, к какой сети будет подключен маршрутизатор ZigBee или конечное устройство. Это также может использоваться для предварительной установки идентификатора PAN новой сети, создаваемой координатором или маршрутизатором.
Для параметра ZDO_CONFIG_PAN_ID в файле f8wConfig.cfg можно установить значение (от 1 до 0xFFFE). Координатор или формирующий сеть маршрутизатор будет использовать это значение в качестве идентификатора PAN сети, когда ему будет поручено создать сеть. Присоединяющийся маршрутизатор или конечное устройство будут подключаться только к сети с идентификатором PAN, который соответствует значению этого параметр. Чтобы отключить эту функцию, установите для параметра значение 0xFFFF. В этом случае вновь созданная сеть будет иметь произвольный идентификатор PAN, и присоединяющееся устройство сможет подключиться к любой сети независимо от его идентификатора PAN.
Процесс обнаружения сети управляется процессом ввода в эксплуатацию Network Steering, который объясняется 15.5. Позволяет фильтровать обнаруженные сети, регистрируя обратный вызов с помощью функции bdb_RegisterForFilterNwkDescCB (), к которому приложение получает список сетевых дескрипторов сети, найденные при каждой попытке сканирования (сначала первичные каналы, а затем другой вызов для вторичного канала, если
выполнила). Приложение может пропустить попытку присоединиться к определенной сети, освободив сетевые дескрипторы, используя bdb_nwkDescFree (). Подробнее об этих API см. В [1].
Для дальнейшего управления процедурой соединения, функция ZDO_NetworkDiscoveryConfirmCB в ZDApp.c должен быть изменен. ZDO_NetworkDiscoveryConfirmCB () вызывается, когда сетевой уровень имеет завершил процесс Обнаружения сети, начав с вызова NLME_NetworkDiscoveryRequest (), подробно описано в документе Z-Stack API [1].

9.3 Максимальный размер полезной нагрузки

Максимальный размер полезной нагрузки для приложения зависит от нескольких факторов. Уровень MAC обеспечивает постоянную
длина полезной нагрузки 116 (можно изменить в файле f8wConfig.cfg - MAC_MAX_FRAME_SIZE). Слой NWK требуется фиксированный размер заголовка, один размер с защитой и один без защиты. Уровень APS имеет обязательный, но переменная, размер заголовка на основе различных настроек, включая версию протокола ZigBee, управление кадром APS настройки и т. д. В конечном счете, пользователю не нужно рассчитывать максимальный размер полезной нагрузки, используя вышеупомянутые факторы. Модуль AF предоставляет API, который позволяет пользователю запрашивать у стека максимальный размер полезной нагрузки, или максимальная транспортная единица (MTU). Пользователь может вызвать функцию afDataReqMTU () (см. AF.h), которая вернуть MTU или максимальный размер полезной нагрузки.
typedef struct
{
  uint8 kvp;
  APSDE_DataReqMTU_t aps;
} afDataReqMTU_t;
uint8 afDataReqMTU( afDataReqMTU_t* fields )
 
В настоящее время единственное поле, которое должно быть установлено в структуре afDataReqMTU_t, это kvp, которое указывает, KVP используется, и это поле должно быть установлено в FALSE. Поле aps зарезервировано для будущего использования.

9.4 Выйти из сети

Управление ZDO реализует функцию ZDO_ProcessMgmtLeaveReq (), которая обеспечивает доступ к примитив NLME-LEAVE.request. «NLME-LEAVE.request» позволяет устройству удалить себя или удалить удаленный устройство из сети. ZDO_ProcessMgmtLeaveReq () удаляет устройство на основе предоставленного IEEE адрес. Когда устройство удаляет себя, оно будет ждать LEAVE_RESET_DELAY (5 секунд по умолчанию), а затем
сброс настроек. Когда устройство удаляет дочернее устройство, оно также удаляет устройство из локальной «таблицы связей».
Адрес NWK будет использоваться повторно только в том случае, если дочернее устройство является конечным устройством ZigBee. В случае ребенка
ZigBee Router, адрес NWK не будет использоваться повторно.
Если родительский элемент дочернего устройства покидает сеть, дочерний элемент остается в сети.
В версии R21 спецификации ZigBee PRO обработка «NWK Leave Request» настраивается для маршрутизаторов.
Приложение контролирует эту функцию, устанавливая для переменной zgNwkLeaveRequestAllowed значение TRUE (по умолчанию значение) или FALSE, чтобы разрешить / запретить маршрутизатору покидать сеть, когда получен «NWK Leave Request».
zgNwkLeaveRequestAllowed определяется и инициализируется в ZGlobals.c и соответствующем элементе NV, ZCD_NV_NWK_LEAVE_REQ_ALLOWED, определяется в ZComDef.h. Обработка этих команд в зависимости от тип логического устройства также изменился: координаторы не обрабатывают команды выхода, обрабатывают устройства маршрутизатора оставлять команды с любого устройства в сети (если разрешено, как указано выше), а конечные устройства обрабатывают только оставить команды от своего родительского устройства.
В спецификации поведения базового устройства также указано, что если какое-либо устройство получает действительный запрос на отпуск с набором для повторного подключения FALSE (это означает, что это устройство не должно присоединяться к сети), то это устройство вынуждено выполнить Factory
New reset. В этом случае Z-Stack очищает все постоянные данные ZigBee, в то время как приложение должно очистить соответствующие данные приложения от Nv.

9.5 Дескрипторы

Все устройства в сети ZigBee имеют дескрипторы, которые описывают тип устройства и его приложения. Эта информация доступна для обнаружения другими устройствами в сети.
Элементы конфигурации настраиваются и определяются в ZDConfig.c и ZDConfig.h. Эти 2 файла также содержат узел, Power Descriptors и дескриптор пользователя по умолчанию. Обязательно измените эти дескрипторы, чтобы определить ваше устройство.

9.6 Элементы энергонезависимой памяти

9.6.1. Глобальная конфигурация энергонезависимой памяти

Глобальные элементы конфигурации устройства хранятся в ZGlobal.c. Это включает в себя такие элементы, как PAN ID, key information,
сетевые настройки и т. д. Значения по умолчанию для большинства этих элементов указаны в файле f8wConfig.cfg. Эти предметы загружаются в оперативную память при запуске для быстрого доступа во время работы Z-Stack. Инициализировать энергонезависимую память область для хранения этих элементов, флаг компиляции NV_INIT должен быть включен в вашем проекте (он включен по умолчанию в примеры приложений).

9.6.2. Энергонезависимая сетевая память

Устройство ZigBee имеет много информации о состоянии, которую необходимо сохранить в энергонезависимой памяти, чтобы ее можно было
восстанавливается в случае случайного сброса или потери питания. В противном случае он не сможет присоединиться к сети или функции эффективно.
Эта функция включена по умолчанию включением опции компиляции NV_RESTORE. Обратите внимание, что эта функция должна быть всегда включенным в реальной сети ZigBee. Возможность отключить его предназначена только для использования в стадии разработки.
Уровень ZDO отвечает за сохранение и восстановление важной информации сетевого уровня, но это слой BDB, который будет определять, когда извлекать эту информацию или когда очищать и запускать как «фабрично-новое» устройство.
Сюда входит база информации о сети (NIB - атрибуты, необходимые для управления сетевым уровнем устройства); список дочерних и родительских устройств и таблица, содержащая привязки приложения. Это также используется для обеспечения безопасности хранить счетчики кадров и ключи.
Если устройство не предназначено для установки в заводское новое состояние, устройство будет использовать эту информацию для восстановления
устройство в сети, если устройство сбрасывается любым способом.
После инициализации уровень BDB проверит атрибут bdbNodeIsOnANetwork, чтобы узнать, было ли это устройство введен в эксплуатацию в сети. Если он был введен в эксплуатацию в сети, и ему также было поручено возобновить работу в той же сети, тогда уровень BDB вызовет ZDOInitDeviceEx (), который будет обрабатывать операцию возобновления в соответствии с состоянием и типом логического устройства.

9.6.3. Применение энергонезависимой памяти

Как правило, устройство должно иметь энергонезависимую память, разрешенную для сертификации, поскольку оно должно помнить свою сеть
конфигурации. В дополнение к «внутренним» данным стека, NVM также может использоваться для хранения данных приложения.
Чтобы сохранить переменную в NVM, для этой переменной должен быть создан идентификатор элемента. ID, зарезервированные для приложений, варьируются от 0x0401 до 0x0FFF. Полный список этих идентификаторов приведен в файле ZComDef.h.
После выбора идентификатора элемента его необходимо инициализировать с помощью osal_nv_item_init (). Эта функция получает идентификатор элемента, длина сохраняемой переменной и начальное значение.
Чтобы записать элемент в NVM, используйте osal_nv_write (). Эта функция получает идентификатор элемента, смещение индекса в item, длина данных для записи и переменная для записи.
Чтобы прочитать элемент из NVM, используйте osal_nv_read (). Эта функция получает идентификатор элемента, смещение индекса в элемент, длина данных для чтения и переменная для чтения данных.
Эти функции можно найти в файле OSAL_Nv.c.

9.7 Асинхронные ссылки

Асинхронная связь возникает, когда узел может получать пакеты от другого узла, но не может отправлять пакеты этому узел. Всякий раз, когда это происходит, эта ссылка не является хорошей ссылкой для маршрутизации пакетов.
В ZigBee PRO эта проблема решается с помощью сообщения о состоянии сетевого соединения. Каждый роутер в ZigBee PRO сеть периодически отправляет сообщение Link Status. Это сообщение является однопроходным широковещательным сообщением, которое содержит список соседей отправляющего устройства. Идея заключается в следующем - если вы получаете статус ссылки вашего соседа, и вы либо отсутствует в списке соседей или ваша стоимость получения слишком низкая (в списке), вы можете предположить, что связь между вами и этот сосед является асинхронным каналом, и вы не должны использовать его для маршрутизации.
Чтобы изменить время между сообщениями Link Status, вы можете изменить флаг компиляции NWK_LINK_STATUS_PERIOD, который используется для инициализации _NIB.nwkLinkStatusPeriod. Вы также можете измените _NIB.nwkLinkStatusPeriod напрямую. Помните, что только PRO-маршрутизаторы отправляют сообщение о статусе ссылки и что каждый маршрутизатор в сети должен иметь одинаковый период времени состояния соединения.
_NIB.nwkLinkStatusPeriod содержит количество секунд между сообщениями о состоянии канала.
Другим параметром, влияющим на сообщение о статусе ссылки, является _NIB.nwkRouterAgeLimit (по умолчанию NWK_ROUTE_AGE_LIMIT). Это представляет количество периодов состояния канала, которые маршрутизатор может оставаться в список соседей устройства без получения статуса соединения с этого устройства до того, как оно выйдет из списка. Если мы не получил сообщение о статусе ссылки от соседа внутри (_NIB.nwkRouterAgeLimit * _NIB.nwkLinkStatusPeriod), мы состарим соседа и предположим, что это устройство отсутствует или оно асинхронная ссылка и не использовать ее.

9.8. Многоадресные сообщения - Multicast Messages

Эта функция предназначена только для ZigBee PRO (в качестве флага компиляции должен быть указан ZIGBEEPRO). Эта функция похожа на
отправка в группу APS, но на сетевом уровне.
Многоадресное сообщение отправляется с устройства в группу в виде широковещательного сообщения MAC. Приемное устройство будет
определить, является ли она частью этой группы: если она не является частью группы, она уменьшит радиус не члена и ретранслировать; если он является частью группы, он сначала восстановит радиус группы, а затем повторно передаст сообщение. Если радиус уменьшается до 0, сообщение не передается повторно.
Разницу между многоадресными и групповыми сообщениями APS можно увидеть только в очень больших сетях, где не члены радиус будет ограничивать количество прыжков от группы.
_NIB.nwkUseMultiCast используется сетевым уровнем для включения многоадресной рассылки (по умолчанию TRUE, если ZIGBEEPRO определено) для всех групповых сообщений, и если это поле имеет значение FALSE, групповое сообщение APS отправляется как обычная широковещательная рассылка сетевое сообщение.
zgApsNonMemberRadius - это значение радиуса группы и радиуса, не являющегося членом. Эта переменная должна быть контролируется приложением для контроля распространения вещания. Если это число слишком велико, эффект будет так же, как сообщение группы APS. Эта переменная определена в ZGlobals.c и ZCD_NV_APS_NONMEMBER_RADIUS (определено в ZComDef.h) является элементом NV.

9.9 Фрагментация

Фрагментация сообщений - это процесс, в котором большое сообщение - слишком большое для отправки в одном пакете APS - разбивается и передается в виде небольших фрагментов. Фрагменты сообщения большего размера затем собираются получателем устройство.
Чтобы включить функцию фрагментации APS в вашем проекте Z-Stack, включите ZIGBEE_FRAGMENTATION флаг компиляции. По умолчанию все проекты, в которых определен ZIGBEEPRO, включают фрагментацию, и в этом нет необходимости добавьте флаг компиляции ZIGBEE_FRAGMENTATION. Все приложения, использующие фрагментацию, будут включать APS задача фрагментации APSF_Init () и APSF_ProcessEvent (). Если у вас есть существующее приложение, сделайте убедитесь, что код в OSAL_xxx.c вашего приложения включает заголовочный файл:
#iffined (ZIGBEE_FRAGMENTATION)
#include "aps_frag.h"
#endif
А в tasksArr [] есть запись для APSF_ProcessEvent (), как в примере ниже:
const pTaskEventHandlerFn tasksArr[] = {
  macEventLoop,
  nwk_event_loop,
#if (ZG_BUILD_RTR_TYPE)
  gp_event_loop,
#endif
  Hal_ProcessEvent,
#if defined( MT_TASK )
  MT_ProcessEvent,
#endif
  APS_event_loop,
#if defined ( ZIGBEE_FRAGMENTATION )
  APSF_ProcessEvent,
#endif
  ZDApp_event_loop,
#if defined ( ZIGBEE_FREQ_AGILITY ) || defined ( ZIGBEE_PANID_CONFLICT )
  ZDNwkMgr_event_loop,
#endif
  zcl_event_loop,
  bdb_event_loop,
  xxx_ProcessEvent /* Where xxx is your application’s name */
};
 
И функция osalInitTasks () вызывает APSF_Init (), как в коде ниже;
 
void osalInitTasks( void )
{
  uint8 taskID = 0;
  tasksEvents = (uint16 *)osal_mem_alloc( sizeof( uint16 ) * tasksCnt);
  osal_memset( tasksEvents, 0, (sizeof( uint16 ) * tasksCnt));
  macTaskInit( taskID++ );
  nwk_init( taskID++ );
#if (ZG_BUILD_RTR_TYPE)
  gp_Init( taskID++ );
#endif
  Hal_Init( taskID++ );
#if defined( MT_TASK )
  MT_TaskInit( taskID++ );
#endif
  APS_Init( taskID++ );
#if defined ( ZIGBEE_FRAGMENTATION )
  APSF_Init( taskID++ );
#endif
  ZDApp_Init( taskID++ );
#if defined ( ZIGBEE_FREQ_AGILITY ) || defined ( ZIGBEE_PANID_CONFLICT )
  ZDNwkMgr_Init( taskID++ );
#endif
  zcl_Init( taskID++ );
  bdb_Init( taskID++ );
  xxx_Init( taskID ); /* Where xxx is your application’s name */
}

Когда APS Fragmentation включен, отправка запроса данных с полезной нагрузкой больше, чем обычный запрос данных полезная нагрузка автоматически вызовет фрагментацию.

Параметры фрагментации находятся в структуре afAPSF_Config_t, которая является частью списка дескрипторов конечной точки epList_t, определенный в AF.h, значения по умолчанию для этих параметров используются при вызове afRegister (), чтобы зарегистрируйте дескриптор конечной точки приложения, который в свою очередь вызывает afRegisterExtended (), значения по умолчанию APSF_DEFAULT_WINDOW_SIZE и APSF_DEFAULT_INTERFRAME_DELAY определены в ZGlobals.h:
  • APSF_DEFAULT_WINDOW_SIZE - Размер окна Tx при использовании фрагментации. Это число фрагментов, отправленных до ожидаемого ACK фрагментации APS. Итак, если сообщение разбит на 10 фрагментов и максимальный размер окна равен 5, тогда ACK будет отправлен получателем устройство после получения 5 фрагментов. Если один пакет с размером окна не получен, ACK не отправляется и все пакеты (в этом окне) отправляются повторно.
  • APSF_DEFAULT_INTERFRAME_DELAY - задержка между фрагментами в окне. Это используется отправляющим устройством.
Эти значения могут быть прочитаны и установлены приложением, вызывая afAPSF_ConfigGet () и afAPSF_ConfigSet () соответственно.
Рекомендуется, чтобы приложение / профиль обновили MaxInTransferSize и MaxOutTransferSize дескриптора узла ZDO для устройства, ZDConfig_UpdateNodeDescriptor () в ZDConfig.c. Эти поля инициализируются с помощью MAX_TRANSFER_SIZE (определено в ZDConfig.h). Эти значения не используются в слои APS как максимумы, они только информационные.

9.9.1 Краткое руководство

Флаг компиляции для активации функции ZIGBEE_FRAGMENTATION
Максимальное количество фрагментов в значении окна по умолчанию
APSF_DEFAULT_WINDOW_SIZE (определено в ZGlobals.h)
Значение задержки по умолчанию между кадрами
APSF_DEFAULT_INTERFRAME_DELAY (определено в
ZGlobals.h)
Максимальный размер буфера приложения / профиля MAX_TRANSFER_SIZE (определен в ZDConfig.h)

9.10 Расширенные PAN ID

В Z-Stack используются два расширенных идентификатора PAN:
  • zgApsUseExtendedPANID: это 64-битный идентификатор PAN сети, к которой нужно присоединиться или сформировать. Эта соответствует элементу ZCD_NV_APS_USE_EXT_PANID NV.
  • zgExtendedPANID: это 64-разрядный расширенный идентификатор PAN сети, к которой подключено устройство. Если оно имеет значение 0x0000000000000000, тогда устройство не подключено к сети. Это соответствует элемент ZCD_NV_EXTENDED_PAN_ID NV.
Если устройство обладает возможностями формирования и получает команду на формирование сети, оно будет формировать сеть с использованием
zgApsUseExtendedPANID, если zgApsUseExtendedPANID имеет ненулевое значение. Если zgApsUseExtendedPANID равен 0x0000000000000000, тогда устройство будет использовать свой 64-разрядный расширенный адрес для сформировать сеть.

9.11 Присоединение с предварительно настроенными параметрами сети

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

9.12 Управление детьми

В R21 (редакция 21 спецификации ZigBee, AKA ZigBee 2015) введена функция управления детьми, которая предназначен для обеспечения мобильности конечных устройств, в то же время позволяя родительским устройствам очищать свои таблицы от конечных устройств, которые дольше их дети. Когда конечное устройство присоединяется / присоединяется, оно отправляет команду EndDeviceTimeout nwk, которая сообщает родительскому устройству период времени, по истечении которого он может удалить его из своей таблицы ассоциации, если устройство не отправило сообщение активности Родительское устройство ответит на эту сетевую команду ответом, указав, какие методы оно поддерживает получение сообщений keep-alive. На данный момент этот релиз содержит только один метод keep-alive указан, который использует стандартный опрос MAC. Если устаревшее устройство присоединяется к родительскому устройству R21 или новее, родительское устройство назначит время ожидания по умолчанию для истечения срока действия этого устройства, если это устаревшее устройство не сможет своевременно выполнить опрос. Дополнительно если родительское устройство опрашивается конечным устройством, которое не является его дочерним (из-за истечения срока действия или вообще не является его дочерним),
затем родительское устройство должно запросить это конечное устройство, чтобы оно покинуло сеть с установкой соединения на TRUE, чтобы это устройство могло присоединитесь к сети и найдите нового родителя (который может быть тем же самым маршрутизатором или другим).

9.12.1 Настройка дочернего управления для родительского устройства

Время ожидания конечного устройства по умолчанию (как для устаревших, так и для конечных устройств R21) можно определить в родительском устройстве с помощью изменение NWK_END_DEV_TIMEOUT_DEFAULT. Этот тайм-аут будет перезаписан присоединением устройств, если они
их собственное время ожидания с помощью команды EndDeviceTimeout.
Родительские устройства должны отслеживать устройства, которым должен быть отправлен запрос на отпуск из-за истечения срока действия или конечных устройств опрос этого родителя по неизвестным причинам. Для этого родительское устройство должно поставить в очередь запрос на отпуск в слое MAC.
Количество устройств, которые можно отслеживать одновременно, определяется MAX_NOT_MYCHILD_DEVICES.
Эти устройства будут отслеживаться в течение периода времени, определенного NWK_END_DEVICE_LEAVE_TIMEOUT. Все эти параметры определены в ZGlobals.h.

9.12.2 Настройка дочернего управления для дочерних устройств

Время ожидания, которое дочернее устройство будет указывать родительскому устройству, определяется END_DEV_TIMEOUT_VALUE и рекомендуется, чтобы он был как минимум в 3 раза больше времени опроса MAC, чтобы избежать истечения срока действия при наличии помех когда конечное устройство опрашивает. 

9.12.3 Родитель Эннс - Parent Annce

Функциональность дочернего управления включает использование сообщения Parent Annce ZDO, которое транслируется родительские устройства и содержит 64-битный адрес IEEE всех конечных устройств в таблице ассоциаций родителя. Эта сообщение отправляется только при формировании сети или при сбросе через 10 секунд плюс случайное дрожание до 10 секунд. Если это сообщение получено другим родительским устройством, оно проверит, является ли какой-либо из сообщенных потомков также перечислены в его таблице ассоциации. Если какое-либо совпадение найдено, то это родительское устройство ответит отправителю сообщение, указывающее, какие дети больше не являются его детьми. Использование этого сообщения можно проиллюстрировать с помощью следующий пример:
1) Родительское устройство «A» имеет дочернее устройство «c».
2) Родительское устройство «А» выключено и выключено.
3) Дочернее устройство «c» находит родительское устройство «B» и присоединяется к нему.
4) Когда родительское устройство «А» восстанавливает свои сетевые параметры, оно запускает таймер для отправки родительского сообщения (из 10 секунд плюс случайный джиттер до 10 секунд.)
5) После истечения тайм-аута родительское устройство «A» передает родительскую анну, содержащую IEEE-адрес дочернего «c».
6) Родительское устройство «B» находит соответствие со своими дочерними элементами и отвечает родительским ответом annce, содержащим
адрес IEEE ребенка "c".
7) Родительское устройство удаляет дочерний элемент «c» из таблицы.

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

10.1 Обзор

Безопасность ZigBee строится с использованием блочного шифра AES и режима работы CCM * в качестве базовой защиты примитивный. Алгоритмы безопасности AES / CCM * были разработаны внешними исследователями за пределами ZigBee Alliance и также широко используются в других протоколах связи.
Спецификация ZigBee определяет два типа сетей на основе схем безопасности, которые используют эти сети:
Централизованная сеть безопасности и сеть распределенной безопасности.
По умолчанию сети закрыты для новых устройств. В обоих типах сетей сеть может быть открыта только для максимум 254 секунды за один раз, после чего сеть будет закрыта для присоединения. Сети Z3.0 не могут оставаться открывать до бесконечности. Длительность, в течение которой устройства могут пытаться подключиться к сети, отражается в пакетах маяка отправляется любыми существующими сетями в ответ на присоединение устройств к запросам маяка.
ZigBee предлагает следующие функции безопасности:
  • Безопасность инфраструктуры
  • Контроль доступа к сети
  • Безопасность данных приложения (только для централизованных сетей безопасности)

10.2 Конфигурация

Чтобы использовать безопасность сетевого уровня, все образы устройств должны быть построены с флагом препроцессора SECURE, установленным равным 1.
Это можно найти в файле f8wConfig.cfg и включено по умолчанию во всех проектах, так как это обязательно в Z3.0 ключ по умолчанию для шифрования сетевого уровня (defaultKey, определенный в nwk_globals.c) может быть предварительно настроен на всех присоединяющихся / формирующих сеть устройствах или они могут быть распределены по каждому присоединяющемуся устройству по беспроводной связи, когда они присоединяются к сеть. Это выбирается с помощью опции zgPreConfigKeys в ZGlobals.c. Если он установлен в TRUE, то значение ключ по умолчанию должен быть предварительно сконфигурирован на каждом устройстве (с одинаковым значением). Если установлено значение FALSE, то по умолчанию ключевой параметр необходимо установить только на устройстве, образующем сеть. Этот defaultKey инициализируется с определение макроса DEFAULT_KEY в файле f8wConfig.cfg. Если этот ключ установлен в 0 при инициализации, то случайный ключ будет быть сгенерированным. В Z3.0 этот ключ передается по беспроводной связи на присоединяющиеся устройства с использованием шифрования на уровне APS.

10.3 Централизованная сеть безопасности

Этот тип сети формируется устройствами-координаторами, в которых координатор принимает на себя роль TC. В этом типе в сети только ТС может доставить сетевой ключ для присоединения и позволить им быть частью сети.
Координатор может настроить различные наборы политик TC, которые позволяют контролировать уровень безопасности сети, эти политика будет представлена ​​в разделе 10.3.1. Когда устройство выполняет ассоциацию непосредственно с TC, TC будет оценить политику TC и проверить, разрешено ли устройству подключаться к сети или нет. Когда устройство подключается через маршрутизатор, родительское устройство уведомляет TC с помощью команды APS Update Device, а затем присоединяется к устройству пройдут те же проверки политики TC. Если устройство проходит валидацию, TC доставит сеть ключ к присоединяемому устройству с помощью прямой команды APS Transport Key или APS Tunnel: Transport Key команда, в зависимости от устройств, соединяющих топологию. Если присоединяющееся устройство не проходит валидацию политики TC, он будет удален из сети с помощью команды выхода из сети.
Также важно отметить, что если TC не доступен (отключение питания или нет в сети), новые устройства не будут быть в состоянии присоединиться к сети, поскольку никакое другое устройство не может доставлять сетевой ключ или проверять политики TC.

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

10.3.1.1 zgAllowRemoteTCPolicyChange

Если для этой политики задано значение TRUE, другие устройства в сети могут изменить политику присоединения разрешений центра доверия,
что может позволить другим устройствам присоединиться к сети. Если установлено значение FALSE, удаленные устройства не смогут изменять
разрешить присоединение политики к координатору, что приведет к тому, что TC не доставит сетевой ключ и не вытолкнет устройства, пытающиеся подключиться к сети через промежуточный маршрутизатор, который может иметь локально разрешенное соединение.

10.3.1.2 bdbJoinUsesInstallCodeKey

Если bdbJoinUsesInstallCodeKey имеет значение TRUE, сетевой ключ будет доставлен только тем, кто присоединяется устройства, с которыми связан код установки. Если bdbJoinUsesInstallCodeKey имеет значение FALSE, присоединение устройства могут использовать коды установки. Использование кодов установки описано в разделе 10.5.2.

10.3.1.3 bdbTrustCenterRequireKeyExchange

Если для этой политики установлено значение TRUE (по умолчанию это значение указано в bdb_interface.h), то все присоединяющиеся устройства должны
выполнить процедуру обмена TCLK. Устройства, которые не выполняют эту процедуру, будут исключены из сеть через bdbTrustCenterNodeJoinTimeout секунд (15 по умолчанию). Если эта политика установлена ​​в FALSE, присоединяющиеся устройства не будут обязаны выполнять обновление TCLK, но им будет разрешено это делать. TCLK процедура обмена описана в разделе 10.6.1.
Важно отметить, что устаревшие устройства (реализующие R20 или ранее) не смогут выполнять TCLK процесс обмена, поэтому, если для этой политики задано значение TRUE, устаревшие устройства не смогут подключиться к этой сети.

10.3.2 Ключевые обновления

Центр управления безопасностью может обновить общий ключ сети по своему усмотрению. Примером политики будет обновление cетевой ключ через регулярные периодические интервалы. Другой вариант - обновить клавишу NWK при вводе пользователем (например, при нажатии кнопки).
ZDSO Security Manager ZDSecMgr.c API предоставляет эту функцию через ZDSecMgrUpdateNwkKey () и ZDSecMgrSwitchNwkKey (). ZDSecMgrUpdateNwkKey () позволяет центру управления безопасностью для отправки нового сетевого ключа в dstAddr в сети. На этом этапе новый сетевой ключ хранится в качестве альтернативного ключа в целевом устройстве или устройствах, если dstAddr не был одноадресным адресом. Однажды Trust Center вызывает ZDSecMgrSwitchNwkKey (), с dstAddr устройства или устройств, всех устройств назначения будет использовать их альтернативный ключ.
В редакции R21 спецификации ZigBee счетчик сетевых кадров должен быть постоянным при новых сбросах с завода, но его можно сбросить до 0 при следующих условиях: если счетчик сетевых кадров больше половины своего максимального значения (0x8000000) перед обновлением сетевого ключа выполнение обновления сбросит счетчик кадров на 0.

10.4 Распределенная сеть безопасности

Этот тип сети может быть сформирован формирующими сеть маршрутизаторами. В этой топологии сети все узлы имеют возможность открывать сеть для присоединения, и любое маршрутизирующее устройство может доставить сетевой ключ присоединяющемуся устройству. Сетевой ключ будет зашифрован на уровне APS с помощью Распределенного глобального ключа по умолчанию, в разделе 10.5.3. Эта сеть ключ будет доставлен с помощью команды транспортного ключа APS, в которой адрес TC будет установлен на 0xFFFFFFFFFFFFFFFF, который сообщает присоединяющемуся устройству о присоединении к распределенной сети безопасности. Приложение может обратиться к значению AIB_apsTrustCenterAddress, чтобы узнать, присоединилось ли оно к распределенной сети.
Важно отметить, что после того, как распределенная сеть сформирована, сетевой ключ не может быть обновлен, поскольку не существует определенного способа безопасного распределения сетевого ключа в сети с этой топологией.

10.5 Типы ключей ссылок

Каждый узел должен поддерживать способ использования следующих типов ключей ссылки:
1. Ключ по умолчанию для глобального центра управления безопасностью (используется Z-Stack автоматически).
2. Ключ глобальной ссылки распределенной безопасности (используется Z-Stack автоматически).
3. Предварительно сконфигурированный ключ связи, полученный из кода установки (обратитесь к API Z-Stack, чтобы установить set this [1]).
4. Клавиша с предварительно настроенной ссылкой (если она включена).

10.5.1 Ключ ссылки по умолчанию для глобального центра управления безопасностью

Все устройства имеют общий глобальный ключ связи Центра управления безопасностью. Это ключ уровня APS, и он является первым ключом, который используется при присоединении к сети, если не указан другой ключ связи. Этот ключ нельзя изменить, если требуется взаимодействие с другими устройствами Z3.0.
 
Default global Trust Center link key = 0x5a 0x69 0x67 0x42 0x65 0x65 0x41
(0:15)                                                   0x6c 0x6c 0x69 0x61 0x6e 0x63 0x65
                                                            0x30 0x39

10.5.2 Установить ключ получения производного ключа центра управления безопасностью

Код установки представляет собой последовательность из 16 байтов, за которыми следуют 2 байта CRC. Полная последовательность из 18 байтов необходима для генерации уникального TCLK. Использование кодов установки, определенных в Z3.0, было добавлено, чтобы разрешить обобщенный метод доставки внешнего ключа для ввода в эксплуатацию сети. Это работает следующим образом:
1. TC получает установочный код и 64-битный IEEE-адрес устройства, которое будет использовать этот установочный код для присоединения через любой пользовательский интерфейс (последовательный порт, дисплей и коммутаторы и т. Д.). Код установки должен быть физически предоставлен с присоединяемым устройством.
2. TC проверяет CRC введенного кода установки. Если это действительно так, то в TC добавляется запись TCLK с полученным ключом и адресом соответствующего устройства.
3. Присоединяющемуся устройству предписано использовать его установочный код для генерации соответствующего TCLK.
4. Сеть открыта любым способом.
5. Присоединяющееся устройство выполняет связывание, и Центр управления безопасностью доставляет сетевой ключ, зашифрованный на уровне APS, с ключом, полученным из кода установки.
6. После этого присоединяющееся устройство должно выполнить обновление своего TCLK, как того требует спецификация BDB.
Для получения дополнительной информации о том, как генерировать коды установки, см. Базовую спецификацию устройства [7]. Это поддерживается только версиями R21 или более поздними, поэтому для обеспечения обратной совместимости приложение должно иметь возможность попытаться присоединиться к сети без использования кодов установки.

10.5.3 Ключ глобальной ссылки распределенной безопасности

Когда устройство подключается к распределенной сети безопасности (без центра доверия), сетевой ключ будет доставлен в зашифрованном виде на уровне APS с ключом глобальной ссылки распределенной безопасности родительским устройством-маршрутизатором. Этот ключ нельзя изменить, если требуется взаимодействие с другими устройствами Z3.0.
 
Distributed Trust Center link key = 0xd0 0xd1 0xd2 0xd3 0xd4 0xd5 0xd6
(0:15)                                              0xd7 0xd8 0xd9 0xda 0xdb 0xdc 0xdd
                                                        0xde 0xdf

10.5.4 Предварительно настроенный ключ связи Touchlink

Этот ключ используется для разработки, когда устройство используется для подключения к сети с использованием процедуры ввода в эксплуатацию Touchlink.
 
Touchlink preconfigured link key = 0xc0 0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7
(0:15)                                              0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf

10.6 Небезопасное присоединение к сети

Поведение базового устройства определило процедуру, в которой устройство должно войти в сеть из нового состояния фабрики; этот процесс включает в себя то, как присоединяющееся устройство выполняет обнаружение доступных сетей в нескольких каналах и как оно резервирует для обнаружения дополнительных сетей в оставшихся каналах, это описано в разделе 15.5. Как только устройство выберет подходящую сеть, присоединяющееся устройство выполнит незащищенную ассоциацию (этот термин относится к присоединяющемуся устройству, не имеющему сетевой ключ), и присоединяющееся устройство будет ожидать получения сетевого ключа, от которого присоединяющееся устройство будет определить, присоединился ли он к централизованной сети безопасности или распределенной сети безопасности. Эти сети используют разные ключи для шифрования команды APS Transport, содержащей сетевой ключ, как определено выше. Конкретные безопасные процедуры для присоединения к этим типам защищенных сетей будут объяснены в следующих подразделах.

10.6.1 Небезопасное присоединение к централизованной сети

Как только транспортный ключ будет получен присоединяющимся устройством, он продолжит проверку исходного адреса этой команды транспортного ключа. В этом случае 64-битный адрес IEEE будет отличаться от 0 и FF, поскольку в этой сети существует TC. Следующие шаги описывают небезопасный процесс присоединения к централизованной сети. Процесс присоединения к централизованной сети Z3.0 непосредственно к TC показан на рисунке 6.
1. Присоединяющееся устройство отправляет запрос на ассоциацию.
2. Родительское устройство отправляет ответ ассоциации.
3. Центр управления безопасностью доставляет сетевой ключ с помощью команды Транспортный ключ. Эта команда транспортного ключа шифруется APS либо с использованием глобального централизованного ключа по умолчанию (10.5.1), либо с помощью производного ключа кода установки (10.5.2)
4. Присоединяющееся устройство может получить сетевой ключ из зашифрованной команды транспортного ключа и объявляет себя с помощью команды объявления устройства ZDO.
5. Затем присоединяющееся устройство запрашивает дескриптор узла ZDO из центра доверия.
6. Присоединяющееся устройство анализирует дескриптор узла, чтобы посмотреть версию стека (это поле было добавлено версией спецификации ZigBee R21 [5]).
а. Если версия стека, поддерживаемая TC, отсутствует (0x00), это означает, что она поддерживает версию от ранее до R21, поэтому процесс соединения завершится на этом шаге.
б. Если TC присоединенной сети - R21 или новее, присоединяющееся устройство должно обновить свой ключ APS. Это делается присоединяющимся устройством путем отправки команды APS Request Key.
7. TC доставит уникальный ключ связи Центра доверия с помощью команды APS Transport Key.
8. Присоединяющееся устройство обновит свой ключ со статуса Default или Предварительного статуса, если использовался код установки, до Unverified, после чего ключ должен быть проверен. Для проверки ключа присоединяющееся устройство отправит команду TC APS Verify Key, содержащую хэшированный уникальный ключ (чтобы не отправлять ключ в виде простого текста).
9. TC хэширует ключ, связанный с этим устройством, и сравнивает его с полученным хэшем. Если они совпадают, он отправит команду подтверждения ключа APS со статусом «Успешно», после чего процедура обмена TCLK будет завершена для присоединяющегося устройства.
Присоединяющееся устройство будет пытаться до ВDBC_REC_SAME_NETWORK_RETRY_ATTEMPS каждый шаг от шагов 1 до 4, в случае сбоя на любом из этих шагов; устройство будет повторять следующую подходящую сеть в списке сетевых дескрипторов. Таким же образом, шаги с 5 по 8 предпринимаются до ВDB_DEFAULT_TC_LINK_KEY_EXCHANGE_ATTEMPS_MAX время каждого шага, в случае неудачи на любом из этих шагов; устройство выполнит сброс с заводских настроек, чтобы стереть сетевые параметры и ключи, полученные на шаге сбоя. Приложение получит уведомление об этом в соответствии с разделом 15.1.
 
Рисунок 6: Присоединение напрямую к центру доверия.
 
Аналогичный процесс происходит, когда устройство подключается через родительское устройство, которое не является TC. Родительское устройство отправляет команды устройства обновления APS в TC, чтобы уведомить о новом устройстве, и с этого момента родительское устройство передает только кадры между присоединяющимся устройством и TC, как показано на рисунке 7.
 
 
Рисунок 7. Присоединение, когда родитель не является центром доверия.
 

10.6.2 Небезопасное присоединение к распределенной сети

Как только транспортный ключ будет получен присоединяющимся устройством, он продолжит проверку исходного адреса этой команды транспортного ключа. В этом случае 64-битный адрес IEEE будет FF, что указывает на то, что это распределенная сеть. В этом случае нет никаких дополнительных процедур для обновления ключей, так как нет TC, который мог бы обработать это. Процесс объединения в распределенную сеть Z3.0 показан на рисунке 8.
 
 
Рисунок 8: Распределенное соединение безопасности.
 
В этом случае присоединяющееся устройство будет пытаться присоединиться к этому BDBC_REC_SAME_NETWORK_RETRY_ATTEMPS
сеть, если она не может быть аутентифицирована (получить сетевой ключ), то она попытается использовать следующую сеть в списке сетевых дескрипторов.

10.6.3 Вопросы безопасности Z-Stack

10.6.3.1 Для устройств TC

Устройства центра управления безопасностью имеют диспетчера TCLK, который хранит защищенную информацию APS, связанную с конкретным присоединяющимся устройством (адрес IEEE, счетчики кадров, ключ, статус ключа). Каждая запись определяется структурой APSME_TCLKDevEntry_t, определенной в APSMEDE.h. Эти записи хранятся в Nv, и количество записей, которые могут быть сохранены, определяется ZDSECMGR_TC_DEVICE_MAX, определенным в ZDSecMgr.h. Запись создается для всех присоединяющихся устройств в тот момент, когда TC отправляет сетевой ключ на присоединяющееся устройство. Это ограничивает количество устройств в сети на количество записей, которые есть у ТС. Запись TCLK также используется, когда код установки вводится в TC для присоединяемого устройства, а ключ кода установки сохраняется в отдельной таблице Nv, размер которой контролируется ZDSECMGR_TC_DEVICE_IC_MAX и определяется в ZDSecMgr.h. TC освобождает запись ключа кода установки от Nv всякий раз, когда соответствующее присоединяющееся устройство завершает обмен TCLK, оставляя эту запись свободной для другое устройство для использования записи кода установки, но оно продолжает использовать запись TCLK. Поскольку записи TCLK используются для отслеживания ключа APS, и он не обновляется из глобального централизованного ключа по умолчанию устаревшими устройствами (R20 или ранее), нет смысла сохранять записи TCLK для этих устройств, поэтому TC зависит от на конфигурации of bdbTrustCenterRequireKeyExchange (10.3.1.3) удалит из сети устройства, которые не завершили процесс обмена TCLK, и сотрет связанную с ним запись TCLK или оставит ее в сети, но все равно сотрет запись TCLK для этого устройства. Эта оптимизация позволяет устройству Z3.0 TC иметь в сети до ZDSECMGR_TC_DEVICE_MAX устройств Z3.0 и столько же устаревших устройств могут подключаться к сети, что ограничено любым другим параметром или конфигурацией топологии.

10.6.3.2 Для присоединения устройств

Когда устройство является новым на заводе и получает команду APS Transport Key, оно загружает ключ, который необходимо использовать для централизованной сети (код установки, если он загружен через BDB API, или глобальный централизованный ключ по умолчанию, если код установки не задан). Если расшифровка не удалась, Z-Stack автоматически попытается использовать глобальный распределенный ключ по умолчанию. Это связано с тем, что присоединяющееся устройство не может знать, к какому типу сети присоединяются, пока оно не обработает содержимое команды транспортного ключа.
Безопасные процедуры для присоединения к централизованным или распределенным сетям уже реализованы на уровне BDB.
Присоединяющиеся устройства должны учитывать, что обмен APS TCLK будет включать в себя чтение / запись в Nv материала безопасности APS TC, поэтому, если предполагается, что несколько устройств должны быть введены в эксплуатацию одновременно с Factory New, должен быть реализован джиттер, чтобы позволить TC для обработки процедур присоединения всех устройств.
Присоединяющееся устройство без пользовательского интерфейса для настройки его механизма присоединения можно настроить так, чтобы оно пыталось выполнить все предварительно сконфигурированные ключи, которые оно может попробовать при присоединении (Установить код, Глобальный централизованный ключ по умолчанию и Глобальный распределенный ключ по умолчанию), установив для gZDSECMGR_TC_ATTEMPT_DEFAULT_KEY значение TRUE, однако, если устройство предназначен только для присоединения к сетям, в которых должны использоваться только коды установки, тогда для этой политики должно быть установлено значение FALSE.
Значением по умолчанию является FALSE.
Присоединяющиеся устройства могут пропустить процедуру обмена TCLK, установив для requestNewTrustCenterLinkKey значение FALSE, чтобы позволить устройствам Z3.0 развертывать пользовательскую большую сеть, не требуя больших таблиц TCLK в устройствах координатора.
Однако это не следует использовать, если предполагается совместимость с сертифицированными устройствами Z3.0.

10.7 Соединение Touchlink

Ввод в действие Touchlink - это распределенное соединение безопасности, которое требует физической близости и использует свой собственный предварительно настроенный ключ связи. Для этой процедуры инициатор сенсорной связи запускает запрос сканирования по всем активированным каналам, ищущим цель, если цель отвечает и выбрана, ей будет предложено сформировать новую сеть для инициатора или присоединиться
в сеть инициатора.
 
 
Рисунок 9: Запрос на подключение к вводу в эксплуатацию Touchlink.
 
 
Рисунок 10: Запрос на запуск сети с вводом в эксплуатацию Touchlink.

10.8 Обратная совместимость

Существует известная проблема совместимости, когда используется уникальный тип ключа связи, а стек находится в сети со старыми устройствами (R19). В версии 20 Спецификации ZigBee требуется, чтобы Центр управления безопасностью разрешал только шифрованные сообщения APS с командами APS, но маршрутизаторы ZigBee, работающие с более ранними версиями Z командных сообщений APS (например, устройство обновления), шифровали только NWK. Чтобы преодолеть эту проблему, есть элемент управления конфигурацией. zgApsAllowR19Sec определен в ZGlobals.c, который приложение может установить, чтобы устройства R19 могли подключаться к сети. Соответствующим элементом NV является ZCD_NV_APS_ALLOW_R19_SECURITY, определенный в ZComDef.h.

10.9 Краткое руководство

Включение безопасности Set SECURE = 1 (в файле f8wConfig.cfg).
Включение предварительно настроенного сетевого ключа Set zgPreConfigKeys = TRUE (в ZGlobals.c)
Настройка предварительно настроенного сетевого ключа. Set defaultKey = {KEY} (в nwk_globals.c).
Включение / отключение разрешений на присоединение к
Трастовый центр
 Call ZDSecMgrPermitJoining () (в ZDSecMgr.c)
Проверка конкретного устройства во время присоединения
Изменить ZDSecMgrDeviceValidate (в ZDSecMgr.c)
Обновления сетевых ключей
Вызовите ZDSecMgrUpdateNwkKey () и
ZDSecMgrSwitchNwkKey () (в ZDSecMgr.c)
Включение предварительно настроенного центра управления ссылками Ключи
Set SECURE = 1 (в f8wConfig.cfg) и включите
TC_LINKKEY_JOIN или SE_PROFILE в качестве флага компиляции.
Использовать глобальный набор ключей связи Центра доверия
zgApsLinkKeyType = ZG_GLOBAL_LINK_KEY
(в ZGlobals.c). Элемент NV для этого глобального ZCD_NV_APS_LINK_KEY_TYPE (определено в ZComDef.h).
Использовать уникальные ключи ключей центра доверия zgApsLinkKeyType = ZG_UNIQUE_LINK_KEY (в ZGlobals.c). Элемент NV для этого глобального ZCD_NV_APS_LINK_KEY_TYPE (в ZComDef.h).Настроить предварительно настроенный ключ связи центра доверия для каждого
устройство подключается к сети через SYS_OSAL_NV_WRITE.

11. Обзор приложения

11.1 Введение

Последующие разделы относятся к образцу приложений Z-Stack ™ 3.0. Каждое из примеров приложений Z-Stack обеспечивает начало использования TI-распределения стека ZigBee для реализации конкретного объекта приложения.
Разделы подпоследовательности предназначены для общего обзора. Для практического руководства пользователя, пожалуйста, обратитесь к [3].
Каждое примерное приложение использует минимальное подмножество открытых интерфейсов BDB, которое потребуется, чтобы сделать устройство разумно жизнеспособным в сети ZigBee в соответствии со спецификацией BDB. Кроме того, все примеры приложений используют основные функциональные возможности OSAL API: взаимодействие между задачами и внутри задач, путем отправки и получения сообщений, установки и получения событий задач, установки и получения обратных вызовов таймера, использования динамической памяти и других. Кроме того, каждое примерное приложение использует функциональность HAL API, например, пользовательский интерфейс с кнопками и меню на ЖК-дисплее. Таким образом, любой пример приложения служит плодотворным примером для копирования и вставки, или в качестве базового кода пользовательского приложения, в которое можно добавить дополнительные объекты приложения.
Любой объект приложения должен находиться поверх уникальной конечной точки, а любая конечная точка определяется простым дескриптором.
Числа, используемые для конечных точек в простых дескрипторах, были выбраны произвольно.
Каждое примерное приложение создает только один объект приложения, связанный с конкретным примером приложения, но оно также может содержать дополнительные объекты приложения в других конечных точках, таких как конечная точка GP (242) для устройств ZC и ZR, конечная точка TL (13) для тех устройств, которые поддерживают это дополнительный метод ввода в эксплуатацию. Имейте в виду, что при создании экземпляров нескольких объектов приложения в одном устройстве каждый объект приложения должен реализовывать уникальный номер конечной точки, избегая использования зарезервированных конечных точек ZigBee (0 или любых в диапазоне от 242 до 255) и других конечных точек, уже используемых Z-Stack
В следующих параграфах описаны задачи OSAL:

11.1.1 Инициализация

OSAL разработан и распространяется как источник, так что весь функционал OSAL может быть изменен пользователем Z-Stack. Целью проекта является то, что нет необходимости изменять OSAL, чтобы использовать Z-Stack как распределенный. Единственным исключением является то, что должна быть реализована функция инициализации задачи OSAL, osalInitTasks () пользователем. Примеры приложений реализовали эту функцию в выделенном файле, названном в соответствии со следующим шаблоном: OSAL_ «Имя приложения» .c (например, OSAL_SampleLight.c). BSP вызовет osalInitTasks () как часть процесса включения платы и инициализации Z-Stack.

11.1.2 Организация

Как описано в документе Z-Stack OSAL API [1], OSAL реализует кооперативный циклический цикл обслуживания задач. Каждая основная подсистема Z-Stack работает как задача OSAL. Пользователь должен создать хотя бы одну задачу OSAL, в которой будет выполняться его приложение. Это достигается путем добавления их задачи в массив задач [tasksArr определено в OSAL_ ”Имя приложения” .c] и вызывает функцию инициализации задачи их приложения в osalInitTask ().
Примеры приложений ясно показывают, как пользователь добавляет задачу в систему OSAL.

11.1.3 Приоритет задачи

Задачи выполняются в порядке их размещения в массиве задач [tasksArr в OSAL_ «Имя приложения» .c]. Первая задача в массиве имеет самый высокий приоритет.

11.1.4 Системные сервисы

Системными службами OSAL и HAL являются уведомление клавиатуры (нажатие переключателя) и уведомление активности последовательного порта.
Системные сервисы являются эксклюзивными, что означает, что каждая из них может быть зарегистрирована не более чем одной задачей OSAL. Различные системные службы могут быть зарегистрированы одной и той же задачей OSAL или разными задачами OSAL. По умолчанию ни одна из задач Z-Stack не регистрируется ни для одной из системных служб - обе они оставлены для пользовательского приложения.

11.1.5 Дизайн приложения

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

11.1.5.1 Одна задача OSAL на множество объектов приложения

Вот некоторые из плюсов и минусов дизайна «один на много»:
  • Pro: действие, выполняемое при получении события эксклюзивной задачи (нажатие переключателя или последовательный порт), упрощается.
  • Pro: пространство кучи, необходимое для многих структур задач OSAL, сохраняется.
  • Con: действие, предпринимаемое при получении входящего сообщения AF или подтверждения данных AF, является сложным - бремя демультиплексирования предполагаемого объекта приложения-получателя лежит на однопользовательской задаче.
  • Con: процесс обнаружения службы по запросу дескриптора совпадения (то есть авто-совпадение) более сложный - статический локальный флаг должен поддерживаться, чтобы правильно действовать в сообщении ZDO_NEW_DSTADDR.

11.1.5.2 Одна задача OSAL на один объект приложения

Эти плюсы и минусы дизайна «один на один» обратны приведенным выше для дизайна «один на много»:
  • Pro: входящее сообщение AF или подтверждение данных AF уже были демультиплексированы нижним слоев стека, поэтому получающий объект приложения является предполагаемым получателем.
  • Con: создается пространство кучи, необходимое для многих структур задач OSAL.
  • Con: действие, предпринимаемое при получении события исключительной задачи, может быть более сложным, если два или более объекта приложения используют один и тот же исключительный ресурс.

11.1.6 Обязательные методы

Любая задача OSAL должна реализовывать два метода: один для выполнения инициализации задачи, а другой для обработки событий задачи.

11.1.6.1 Инициализация задачи

В примерах приложений функция обратного вызова для выполнения инициализации задачи именуется по следующей схеме: zcl «Имя приложения» _Init (например, zclSampleLight_Init ()). Функция инициализации задачи должна выполнять следующее:
  • Инициализация переменных, локальных или специфических для соответствующего объекта (ов) приложения. Любое долгосрочное выделение памяти кучи должно быть сделано здесь, чтобы облегчить более эффективную память кучи управление OSAL.
  • Реализация соответствующего объекта (ов) приложения путем регистрации на уровне AF (например, afRegister ()).
  • Регистрация в соответствующих системных службах OSAL или HAL (например, RegisterForKeys ()).

11.1.6.2 Обработчик событий задачи

В примерах приложений функция обратного вызова для выполнения обработки событий задачи именуется в соответствии со следующим шаблоном: zcl «Имя приложения» _event_loop (например, zclSampleLight_event_loop ()). Любая задача OSAL может определить до 15 событий в дополнение к обязательному событию.

11.1.7 Обязательные события

Одно событие задачи, SYS_EVENT_MSG (0x8000), зарезервировано и требуется проектом Задачи OSAL.

11.1.7.1 SYS_EVENT_MSG (0x8000)

Глобальные системные сообщения, отправленные через SYS_EVENT_MSG, указаны в ZComDef.h. Обработчик события задачи должен обработать следующее минимальное подмножество этих глобальных системных сообщений. Рекомендуемая обработка cледующие сообщения должны быть получены непосредственно из примера кода приложения или из изучения потока программы в примере приложения.

11.1.7.1.1 AF_DATA_CONFIRM_CMD

Это признак беспроводного результата для каждого запроса данных, который успешно инициируется с помощью вызова AF_DataRequest (). ZSuccess подтверждает, что запрос данных был успешно передан по беспроводной сети. Если запрос данных был сделан с установленным флагом AF_ACK_REQUEST, то ZSuccess подтверждает, что сообщение было успешно получено в конечном пункте назначения. В противном случае ZSuccess только подтверждает, что сообщение было успешно передано на следующий переход.
Устройство следующего перехода может быть или не быть устройством назначения запроса данных. Поэтому подтверждение доставки данных AF на следующий переход не должно быть неверно истолковано как подтверждение того, что запрос данных был доставлен на устройство назначения. Обратитесь к обсуждению вариантов доставки (AF_ACK_REQUEST в API Z-Stack).

11.1.7.1.2 AF_INCOMING_MSG_CMD

Это указание на входящее сообщение AF.

11.1.7.1.3 KEY_CHANGE

Это признак действия нажатия клавиши.

11.1.7.1.4 ZDO_STATE_CHANGE

Это указывает на то, что состояние сети изменилось. Теперь поддерживаются следующие состояния: DEV_HOLD, DEV_INIT, DEV_END_DEVICE, DEV_ROUTER, DEV_ZB_COORD и DEV_NWK_ORPHAN. Другие состояния могут быть неточными. Рекомендуется основывать поведение приложения на уведомлениях BDB или переносить обработку существующего приложения на применяемые уведомления. Уведомления описаны в разделе 15.1.

11.1.7.1.5 ZDO_CB_MSG

Это сообщение отправляется в пример приложения для каждого зарегистрированного ответного сообщения ZDO [ZDO_RegisterForZDOMsg ()].

11.2 Общая прикладная структура / программный поток

В этом разделе описываются концепции инициализации и обработки основных задач, которые разделяют все примеры приложений. Этот раздел следует прочитать, прежде чем переходить к примерам приложений. Для примеров кода в этом разделе мы будем использовать «SampleLight». предоставляется в установщике Z-Stack 3.0.

11.2.1 Инициализация

Во время включения системы и инициализации будет вызвана функция инициализации задачи (см. 11.1.6.1). Структура этой функции поясняется ниже вместе с некоторыми примерами кода:
 
zclSampleLight_TaskID = task_id;
 
Идентификатор задачи назначается OSAL и задается задаче через параметр функции init задачи. Приложение должно запомнить этот идентификатор задачи, так как оно будет использовать его позже для самостоятельного запуска с использованием таймеров OSAL, событий и сообщений (например, когда задача отправляет сообщение себе). Такой автоматический запуск обычно используется для разделения длинных процессов на более мелкие порции, которые затем вызываются с некоторой временной задержкой между ними. Такое «кооперативное» поведение позволяет другим задачам распределять процессорное время и предотвращает «голодание».
 
bdb_RegisterSimpleDescriptor (& zclSampleLight_SimpleDesc);
 
Объект приложения SampleLightApp создается с помощью приведенного выше кода. Это позволяет уровню AF знать, как маршрутизировать входящие пакеты, предназначенные для профиля / конечной точки - это будет сделано путем отправки OSAL SYS_EVENT_MSGmessage (AF_INCOMING_MSG_CMD) в задачу (идентификатор задачи).
 
RegisterForKeys (zclSampleLight_TaskID);
 
Пример приложения регистрируется на эксклюзивную системную службу уведомления о нажатии клавиши.

11.2.2 Обработка событий

Всякий раз, когда происходит событие OSAL для примера приложения, функции обработки события (см. 11.1.6.2) будут по очереди вызываться из цикла обработки задачи OSAL. Параметром обработчика событий задачи является 16-битная битовая маска; один или несколько битов могут быть установлены в любом вызове функции. Если установлено более одного события, настоятельно рекомендуется, чтобы задача действовала только на одно из событий (вероятно, наиболее критичное по времени, и почти всегда SYS_EVENT_MSG в качестве наиболее приоритетного). Необработанное событие вызовет новый вызов этого обработчика события задачи после того, как все другие обработчики получат возможность обработать свои события.
if ( events & SYS_EVENT_MSG )
{
  MSGpkt = (afIncomingMSGPacket_t*)osal_msg_receive(zclSampleLight_TaskID );
  while ( MSGpkt )
  {
    …
Обратите внимание, что хотя рекомендуется, чтобы задача действовала только на одно из множества ожидающих событий при любом отдельном вызове функции обработки задачи, также рекомендуется (и реализовано в примерах приложений) обработать все возможные многие ожидающие сообщения SYS_EVENT_MSG все в том же «временном отрезке» от OSAL.
switch ( MSGpkt->hdr.event )
Рекомендуется, чтобы задача реализовала минимальное подмножество возможных типов сообщений SYS_EVENT_MSG.
Это рекомендуемое подмножество описано ниже.
case KEY_CHANGE:
  zclSampleLight_HandleKeys ( ((keyChange_t *)MSGpkt)->state,
  ((keyChange_t *)MSGpkt)->keys );
  break;
Полный список всех типов сообщений SYS_EVENT_MSG см. В разделе «Глобальные системные сообщения» в ZComDef.h.
Если задача OSAL зарегистрирована для уведомления о нажатии клавиши, любое нажатие клавиши будет получено как сообщение о системном событии KEY_CHANGE. Существует два возможных пути выполнения программы, в результате которых задача получит это сообщение KEY_CHANGE.
Последовательность программ, возникающая в результате нажатия физической клавиши, следующая:
  • HAL определяет состояние нажатия клавиши (по H/W interrupt или по H/W polling).
  • Задача HAL OSAL обнаруживает изменение состояния ключа и вызывает функцию обратного вызова изменения ключа OSAL.
  • Функция обратного вызова изменения ключа OSAL отправляет сообщение о системном событии OSAL (KEY_CHANGE) в идентификатор задачи, который зарегистрирован для получения уведомления о событии изменения ключа (RegisterForKeys ().)
case AF_DATA_CONFIRM_CMD:
  // The status is of ZStatus_t type [defined in ZComDef.h]
  // The message fields are defined in AF.h
  afDataConfirm = (afDataConfirm_t *)MSGpkt;
  sentEP = afDataConfirm->endpoint;
  sentStatus = afDataConfirm->hdr.status;
  sentTransID = afDataConfirm->transID;
 
Любой вызов AF_DataRequest (), который возвращает ZSuccess, приведет к «обратному вызову» посредством сообщения системного события AF_DATA_CONFIRM_CMD.
Отправленный идентификатор транзакции (sentTransID) является одним из способов идентификации сообщения. Хотя в примере приложения будет использоваться только один счетчик идентификатора транзакции, может быть полезно сохранить отдельный счетчик идентификатора транзакции для каждой отдельной конечной точки или даже для каждого идентификатора кластера в конечной точке для подтверждения сообщения, повторных попыток, дизассемблирования и повторной сборки, и т. д. Обратите внимание, что любая переменная состояния идентификатора транзакции (счетчик), которая передается AF_DataRequest (), увеличивается при успешном использовании этой функцией (таким образом, это параметр, передаваемый по ссылке, а не по значению.)
Возвращаемое значение AF_DataRequest () ZSuccess означает, что сообщение было принято сетевым уровнем, который попытается отправить его на уровень MAC, который попытается отправить его по беспроводной сети.
Отправленный статус (sentStatus) является результатом сообщения в эфире. ZSuccess означает, что сообщение было доставлено на устройство ZigBee следующего перехода в сети. Если AF_DataRequest () был вызван с флагом AF_ACK_REQUEST, то ZSuccess означает, что сообщение было доставлено по адресу назначения.
Если режим адресации сообщения не был косвенным (то есть сообщение было отправлено отражателю сети для выполнения поиск в таблице привязки и повторная отправка сообщения на соответствующее устройство (устройства), и в этом случае ZSuccess означает, что сообщение было доставлено в сетевой отражатель. Существует несколько возможных значений отправленного состояния, указывающих на сбой, см. «Значения состояния MAC» в ZComDef.h.
case ZDO_STATE_CHANGE:
  zclSampleLight_NwkState = (devStates_t)(MSGpkt->hdr.status);
  if (  (zclSampleLight_NwkState == DEV_ZB_COORD) ||
        (zclSampleLight_NwkState == DEV_ROUTER) ||
        (zclSampleLight_NwkState == DEV_END_DEVICE) )
  {
    giLightScreenMode = LIGHT_MAINMODE;
    ...
  }
  break;
 
Всякий раз, когда состояние сети изменяется, все задачи уведомляются сообщением о системном событии ZDO_STATE_CHANGE.
Обратитесь к разделу 11.1.7.1.4 за поддерживаемыми состояниями.
// Release the memory
osal_msg_deallocate( (uint8 *)MSGpkt );
Обратите внимание, что проект системы обмена сообщениями OSAL требует, чтобы задача получения повторно выполняла динамическую память, выделенную для сообщения.
Функция обработки событий задачи должна попытаться получить следующее ожидающее сообщение SYS_EVENT_MSG:
  // Get the next message
  MSGpkt = (afIncomingMSGPacket_t*)osal_msg_receive(zclSampleLight_TaskID);
}
После обработки события функция обработки должна возвращать необработанные события, например, после обработки SYS_EVENT_MSG должно быть возвращено следующее:
  // Return unprocessed events
  return ( events ^ SYS_EVENT_MSG);
}

12. Примеры приложений

12.1 Введение

Z3.0 удалил концепцию профилей и создал единую спецификацию определения устройства, которая будет обязывать кластеры, которые должны поддерживать определенные типы устройств. На момент выпуска этой документации и Z-Stack переход с устройств из разных профилей на Z3.0 не завершен. Из набора примеров приложений только SampleSwitch и SampleLight имеют определение Z3.0. Другие примеры применения (дверной замок, дверной замок устройства контроллера, датчика температуры и термостата все еще полагаются на определение профиля ZHA. Со временем они будут обновлены до Z3.0, поскольку кластеры для них будут преобразованы в Z3.0. Эти примеры приложений по-прежнему будут хорошей отправной точкой для обновления до Z3.0, поскольку изменения от определения устройства ZHA до определения устройства Z3.0 будут зависеть от приложения.
В этом разделе описывается реализация примеров приложений, для подробного описания того, как их использовать, обратитесь к [3].

12.2 Инициализация

Как описано в 11, пользователь должен добавить хотя бы одну задачу (в систему задач OSAL) для обслуживания одного или нескольких экземпляров прикладных объектов. Но при реализации объекта приложения необходимо также добавить задачу, предназначенную для ZCL (см. Раздел «Задачи OSAL») в порядке, указанном в примерах приложений (т. е. перед любыми другими задачами, использующими ZCL).
В дополнение к процедуре инициализации пользовательской задачи, изученной в обобщенном примере в предыдущем разделе, для инициализации объекта приложения также требуются шаги для инициализации ZCL. Следующие примеры приложений (Light и Switch) реализуют эту дополнительную инициализацию в функции инициализации задачи (например, zclSampleLight_Init ()) следующим образом.
  • Зарегистрируйте простой дескриптор (например, zclSampleLight_SimpleDesc), используя bdb_RegisterSimpleDescriptor ().
  • Зарегистрируйте таблицу обратных вызовов команды (например, zclSampleLight_CmdCallbacks) в общем функциональном домене, используя zclGeneral_RegisterCmdCallbacks ().
  • Зарегистрируйте список атрибутов (например, zclSampleLight_Attrs) на базовом уровне ZCL, используя zcl_registerAttrList ().

12.3 Архитектура программного обеспечения

Приложения отправляют данные через различные функции отправки (например, zclGeneral_SendOnOff_CmdToggle). Приложения получают данные в функциях обратного вызова после регистрации обратных вызовов. Каждый кластер имеет свой собственный регистр и набор функций обратного вызова (например, zclSampleLight_OnOffCB).
Способ связи Z-Stack с другими устройствами может быть описан на рисунке 11. Клиенты инициируют команду или запрашивают ответ. Серверы действуют по команде или доставляют ответ.
 
Рисунок 11: Блок-схема команд
 
Функции обратного вызова кластера регистрируются в функции инициализации приложения (zclSampleLight_Init) путем включения каждой функции регистрации приложения (например, zclGeneral_RegisterCmdCallbacks) команда. Только те обратные вызовы, которые определены как non. В качестве примера функции обратного вызова, если клиент отправляет команду BasicReset на сервер, зарегистрированной функцией обратного вызова BasicReset приложения на стороне сервера является zclSampleDoorLockController_BasicResetCB, поддерживаемая приложением, к их значениям по умолчанию.
Функция обратного вызова в приложении обеспечивает дополнительную обработку приложения.
Под капотом данные, отправленные с помощью функции Send, преобразуются из собственного формата в прямой порядок данных. Данные, передаваемые по радиоканалу, преобразуются с точки зрения приложения, все данные представлены в форме собственной структуры.
Чтобы функции Send и ProcessIn были доступны, кластеры или группы кластеров должны быть включены либо в файле f8wZCL.cfg, либо в разделе предопределенных констант компилятора.

12.4 Файловая структура

Следующие каталоги содержат большинство примеров кода приложений Z3.0:

12.4.1 Образец приложения «Вкл. Выкл. Свет» (свет и выключатель).

1. Файлы рабочей области IAR для проекта Light
\Projects\zstack\HomeAutomation\SampleLight\<platform>
2. Исходные файлы для проекта Light
\Projects\zstack\HomeAutomation\SampleLight\Source
3. Файлы рабочей области IAR для проекта Switch:
\Projects\zstack\HomeAutomation\SampleSwitch\<platform>
4. Исходные файлы для проекта Switch
\Projects\zstack\HomeAutomation\SampleSwitch\Source

12.4.2. Пример приложения DoorLock (DoorLock и DoorLockController).

1. Файлы рабочей области IAR для проекта DoorLock:
\Projects\zstack\HomeAutomation\SampleDoorLock\<platform>
2. Исходные файлы для проекта DoorLock:
\Projects\zstack\HomeAutomation\SampleDoorLock\Source
3. Файлы рабочей области IAR для проекта DoorLockController:
\Projects\zstack\HomeAutomation\SampleDoorLockController\<platform>
4. Исходные файлы для проекта DoorLockController:
\Projects\zstack\HomeAutomation\SampleDoorLockController\Source

12.4.3 Применение образца датчика температуры (Термостат, Датчик температуры).

1. Файлы рабочей области IAR для проекта Thermostat:
\Projects\zstack\HomeAutomation\SampleThermostat\<platform>
2. Исходные файлы для проекта Thermostat:
\Projects\zstack\HomeAutomation\SampleThermostat\Source
3. Файлы рабочей области IAR для проекта TemperatureSensor:
\Projects\zstack\HomeAutomation\SampleTemperatureSensor\<platform>
4. Исходные файлы для проекта TemperatureSensor:
\Projects\zstack\HomeAutomation\SampleTemperatureSensor\Source

12.4.4. Дополнительные файлы проекта.

1. Исходные файлы, общие для всех проектов Z3.0:
\Projects\zstack\HomeAutomation\Source
2. Исходный код библиотеки кластеров ZigBee:
\Components\stack\zcl

12.5 Приложение Sample Light

12.5.1 Введение

Этот пример приложения можно использовать для включения / выключения светодиода 1 на устройстве с помощью команд кластера включения / выключения.

12.5.2 Модули

Приложение Sample Light состоит из следующих модулей (поверх модулей стека ZigBee):
OSAL_SampleLight.c - функции и таблицы для инициализации задачи.
zcl_samplelight.c - основная прикладная функция, которая имеет функцию инициализации и цикл обработки событий.
zcl_samplelight.h - заголовочный файл для модуля приложения.
zcl_samplelight_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.6 Приложение Sample Switch

12.6.1 Введение

Этот пример приложения можно использовать в качестве переключателя освещения для включения / выключения светодиода 1 на устройстве, на котором запущено приложение Sample Light.

12.6.2 Модули

Приложение Sample Switch состоит из следующих модулей (поверх модулей стека ZigBee):
OSAL_SampleSw.c - функции и таблицы для инициализации задачи.
zcl_samplesw.c - основная прикладная функция, которая имеет функцию инициализации и цикл обработки событий.
zcl_samplesw.h - заголовочный файл для модуля приложения.
zcl_samplesw_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.6.3 Демонстрационные конфигурации сборки OTA

12.6.3.1 Введение

Рабочее пространство Sample Switch Application содержит несколько конфигураций сборки, которые демонстрируют обновление прошивки с помощью функции ZigBee OTA (т.е. по беспроводной сети). При использовании OTA для обновления прошивки во флэш-памяти одновременно может находиться до двух образов FW: активный образ и загруженный образ, который будет активируется при следующем включении.
Подробнее о функциях обновления OTA см. [4].

12.6.3.2 Модули

Эта конфигурация сборки добавляет следующие модули приложения Sample Switch:
hal_ota.c - служебные функции OTA, которые зависят от платформы.
hal_ota.c - заголовочный файл для служебных функций OTA.
zcl_ota.c - обработчик событий для базовой OTA обработки событий ZCL.
zcl_ota.h - заголовочный файл для модуля обработчика OTA.
ota_common.h - содержит определения, необходимые при использовании OTA.

12.7 Приложение Sample Door Lock

12.7.1 Введение

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

12.7.2 Модули

Приложение Sample Door Lock состоит из следующих модулей (поверх модулей стека ZigBee):
OSAL_SampleDoorLock.c - функции и таблицы для инициализации задачи.
zcl sampledoorlock.c - основная прикладная функция, которая имеет функцию инициализации и цикл обработки событий.
zcl sampledoorlock.h - заголовочный файл для модуля приложения.
zcl sampledoorlock_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.8 Приложение Sample Door Lock Controller

12.8.1 Введение

Этот пример приложения может использоваться в качестве контроллера дверного замка и может отправлять команды кластера дверного замка, такие как переключение блокировки / разблокировки и установка главного PIN-кода, на устройство дверного замка.

12.8.2 Модули

Пример приложения «Контроллер дверных замков» состоит из следующих модулей (поверх стековых модулей ZigBee):
OSAL_SampleDoorLockController.c - функции и таблицы для инициализации задачи.
zcl_sampledoorlockcontroller.c - основная прикладная функция с функцией инициализации и цикла обработки событий.
zcl_sampledoorlockcontroller.h - заголовочный файл для модуля приложения.
zcl_sampledoorlockcontroller_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.9 Приложение Sample Thermostat

12.9.1 Введение

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

12.9.2 Модули

Приложение Sample Thermostat состоит из следующих модулей (поверх стековых модулей ZigBee):
OSAL_SampleThermostat.c - функции и таблицы для инициализации задачи.
zcl_samplethermostat.c - основная прикладная функция, которая имеет функцию инициализации и цикл обработки событий.
zcl_samplethermostat.h - заголовочный файл для модуля приложения.
zcl_samplethermostat_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.10 Приложение Sample Temperature Sensor

12.10.1 Введение

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

12.10.2 Модули

Приложение «Датчик температуры образца» состоит из следующих модулей (поверх стека ZigBee модули):
OSAL_SampleTemperaSensor.c - функции и таблицы для инициализации задачи.
zcl_sampletemperaturesensor.c - основная прикладная функция, которая имеет функцию инициализации и цикл обработки событий.
zcl_sampletemperaturesensor.h - заголовочный файл для модуля приложения.
zcl_sampletemperaturesensor_data.c - контейнер для объявления атрибутов, кластеров, простого дескриптора.

12.11 Основные функции

Все примеры приложений имеют одинаковую архитектуру и одинаковые базовые модули:
<Sample_App> _Init () - Инициализирует задачу приложения:
- Регистрирует конечную точку приложения и его простой дескриптор.
- Регистрирует обратные вызовы общего кластера ZCL.
- Регистрирует список атрибутов приложения.
- Зарегистрируйте приложение для получения необработанных сообщений команды / ответа Foundation.
- Зарегистрировать пусконаладку статуса обратного вызова.
- Зарегистрируйтесь для всех событий нажатия клавиш.
- Регистрирует конечную точку теста
- Регистрируется для следующего сообщения ZDO:
o Match_Desc_rsp
 
<Sample_App> _event_loop () - это «задача» примера приложения. Он обрабатывает следующие события, которые могут различаться в зависимости от образца приложения:
- SYS_EVENT_MSG / ZCL_OTA_CALLBACK_IND: обрабатывает обратные вызовы из OTA ZCL, вызывая zclSampleSw_ProcessOTAMsgs.
- SYS_EVENT_MSG / ZCL_INCOMING_MSG: обрабатывать входящие сообщения команды / ответа ZCL Foundation.
- SYS_EVENT_MSG / ZDO_CB_MSG: обрабатывать ответные сообщения, вызывая <Sample_App> _ProcessZDOMsgs ()
- SYS_EVENT_MSG / KEY_CHANGE: обрабатывать физические нажатия клавиш.
- SYS_EVENT_MSG / ZDO_STATE_CHANGE: обрабатывать изменения состояния NWK устройства.
 
<Sample_App> _ProcessZDOMsgs () - обработать следующие ответные сообщения:
- Match_Desc_rsp
- Все остальные сообщения ZDO, для которых зарегистрирован пример приложения.
 
<Sample_App> _HandleKeys () - обрабатывать нажатия клавиш. Поддерживаемые ключи описаны в [3].
 
<Sample_App> _ProcessIncomingMsg () - это функция-заглушка, предоставляющая разработчику простую отправную точку для обработки входящих сообщений ZCL Foundation.
 
bdbRegisterCommissioningStatusCB () - этот обратный вызов будет проинформирован о событиях и состоянии процесса ввода в эксплуатацию BDB.

13. Использование примеров приложений в качестве базы для новых приложений

Примеры приложений Z3.0 предназначены для использования в качестве основы для пользовательских приложений. Их изменение обычно состоит из следующих шагов:
1. Скопируйте образец приложения по вашему выбору в новую папку и назовите его в соответствии с вашим новым приложением:
Copy
Project\zstack\HomeAutomation\SampleLight\*.*
To
Project\zstack\HomeAutomation\YourApp\*.*
2. Переименуйте файлы в соответствии с именем вашего приложения:
В Projects\zstack\HomeAutomation\YourApp\Source переименуйте файлы следующим образом:
  • OSAL_SampleLight.c  OSAL_YourApp.c
  • zcl_samplelight.c  zcl_yourapp.c
  • И т.п.
3. В Projects\zstack\HomeAutomation\YourApp\CC2538 переименуйте следующие файлы:
  • SampleLight.ewdYourApp.ewd
  • SampleLight.ewpYourApp.ewp
  • SampleLight.ewwYourApp.eww
Удалите все остальные файлы и подпапки из этой папки, если они есть.
4. С помощью текстового редактора замените все вхождения «SampleLight» (без учета регистра) на «YourApp», в YourApp.ewp и YourApp.eww.
5. Теперь вы можете открыть YourApp.eww с помощью IAR. Обратите внимание, что файлы приложения, включенные в проект, являются файлами из вашего приложения:
 
 
Рисунок 12: Файлы приложений в YourApp
 
6. Вам придется отредактировать файлы приложения, чтобы заменить любое вхождение zcl_samplelight.h на zcl_yourapp.h.
7. Теперь вы готовы манипулировать кодом приложения в соответствии с вашими потребностями, например, изменять операции нажатия клавиш, изменять тип устройства, изменять поддерживаемые кластеры и т. д. Для получения дополнительной информации см. соответствующие документы, перечисленные в конце данного руководства пользователя.

14. Кластеры, Команды и Атрибуты

Каждое приложение поддерживает определенное количество кластеров. Думайте о кластере как об объекте, содержащем оба метода (команды) и данные (атрибуты).
Каждый кластер может иметь ноль или более команд. Команды далее делятся на серверную и клиентскую части команды. Команды вызывают действие или генерируют ответ.
Каждый кластер может иметь ноль или более атрибутов. Все атрибуты можно найти в файле zcl_sampleapp_data.c, где «sampleapp» заменяется данным примером приложения (например, samplesw_data.c для образца включения / выключения света переключатель). Атрибуты описывают текущее состояние устройства или предоставляют информацию об устройстве, например, свет в настоящее время включен или выключен.
Все кластеры и атрибуты определены либо в спецификации библиотеки кластеров ZigBee.

14.1 Атрибуты

Атрибуты находятся в одном списке с именем zclSampleApp_Attrs [], в файле zcl_sampleapp_data.c. каждая запись атрибута инициализируется типом и значением и содержит указатель на данные атрибута. Типы данных атрибута можно найти в библиотеке кластеров ZigBee.
Атрибуты должны быть зарегистрированы с помощью функции zcl_registerAttrList () во время приложения инициализация, по одному на конечную точку приложения.
Каждый атрибут имеет тип данных, определенный ZigBee (например, UINT8, INT32 и т. Д.). Каждая запись атрибута содержит тип атрибута и указатель на фактические данные для атрибута. Данные, доступные только для чтения, могут совместно использоваться конечными точками.
Данные, которые являются уникальными для конечной точки (например, состояние источника света OnOff), должны иметь уникальную переменную C.
Все атрибуты могут быть прочитаны. Некоторые атрибуты могут быть написаны. Некоторые атрибуты являются отчетными (могут быть автоматически отправлены к месту назначения в зависимости от времени или изменения атрибута с помощью функции отчетности атрибута). Некоторые атрибуты
сохранен как часть «сцены», которую позже можно вызвать для установки устройства в определенное состояние (например, включение или выключение света).
Доступ к атрибуту контролируется через поле в структуре атрибута.
Чтобы сохранить атрибут в энергонезависимой памяти (который будет сохранен при перезагрузке), обратитесь к разделу 9.6.3.

14.2 Добавление примера атрибута

Чтобы добавить дополнительный атрибут в проект, обратитесь к информации об атрибуте в спецификации ZCL [5].
На примере кластера DoorLock ниже показано, как добавить «Максимальную длину PIN-кода» атрибут для проекта DoorLock. Этот процесс может быть воспроизведен во всех типовых проектах Z3.0.
Все атрибуты, используемые приложением, определены в файле zcl_sampleapplication_data.c исходного файла проекта.
Для этого примера DoorLock этот файл данных: zcl_sampledoorlock_data.c. Найдите раздел, определенный как атрибут
Определения и включают атрибут «Максимальная длина PIN-кода» в следующем формате:
 
{
  ZCL_CLUSTER_ID_CLOSURES_DOOR_LOCK,
  { // Attribute record
    ATTRID_DOORLOCK_NUM_OF_MAX_PIN_LENGTH,
    ZCL_DATATYPE_UINT8,
    ACCESS_CONTROL_READ,
    (void *)&zclSampleDoorLock_NumOfMaxPINLength
  }
},
 
Строка 2 представляет идентификатор кластера, строка 4 представляет идентификатор атрибута, строка 5 - тип данных, строка 6 - атрибут чтения / записи, и строка 7 - указатель на переменную, используемую в приложении. При изменении списка атрибутов для добавления или удаления
атрибуты, не забудьте оставить порядок структуры по идентификатору атрибута в том же кластере в порядке возрастания, чтобы обработка команд обнаружения будет выполнена правильно (Атрибуты того же кластера будут перечислены один после другой, от более низкого ID к более высокому ID).
Идентификатор кластера можно получить из файла zcl.h, идентификатор атрибута можно найти в (в данном случае) файл zcl_closures.h и остальная информация из спецификации ZCL [5].
Включая атрибут в этот список, устройства могут взаимодействовать с атрибутами на других устройствах. Это дополнение в списке атрибутов должно быть отражено в макросе SAMPLEDOORLOCK_MAX_ATTRIBUTES в файле zcl_sampledoorlock.h. Также в этом файле определите внешнюю переменную, используя соответствующие правила кодирования:
extern uint8 zclSampleDoorLock_NumOfMaxPinLength
Наконец, определите переменную в zcl_sampledoorlock.c, которая будет использоваться приложением. Обратите внимание на значение по умолчанию и допустимый диапазон переменной в спецификации.

14.3 Инициализация кластеров

Чтобы приложение взаимодействовало с кластером, в конфигурации проекта должен быть включен флаг компиляции кластера (если это применимо к кластеру), а исходный файл кластера должен быть добавлен в папку профиля проекта в рабочей области IAR. Пример этого можно увидеть на рисунке 13. Список флагов компиляции кластера см. В f8wZCL.cfg.
После включения обратные вызовы кластера могут быть зарегистрированы в приложении (см. Раздел 14.5).
 
 
Рисунок 13: Список исходных файлов кластера в папке профиля

14.4. Кластерная архитектура

Все кластеры имеют одинаковую архитектуру.
Кластеры заботятся о преобразовании структур, передаваемых из собственного формата в беспроводной формат, как того требует ZigBee. Все взаимодействие приложения с кластерами происходит в собственном формате.
Все они имеют следующие функции:
  • Send - эта группа команд позволяет отправлять различные команды в кластере.
  • ProcessIn - эта функция обрабатывает входящие команды.
Обычно для каждой команды есть одна функция отправки. Функция send имеет либо набор параметров, либо определенную структуру для команды.
Если приложение зарегистрировало функции обратного вызова, ProcessIn направит команду (после преобразования в собственную форму) для обратного вызова приложения для этой команды.

14.5. Пример обратных вызовов кластера

Обратные вызовы используются для того, чтобы приложение могло выполнить ожидаемое поведение для данной входящей кластерной команды.
Это зависит от приложения, чтобы отправить ответ соответствующим образом. Z-Stack обеспечивает синтаксический анализ, но выполнение приложения зависит от приложения.
Функции обратного вызова кластера регистрируются в функции инициализации приложения, включая конечную точку приложения и указатель на запись обратного вызова в функции обратного вызова команд register. На рисунке 14 показан пример списка записей обратного вызова общего кластера. Команды зарегистрированы для их соответствующих функции обратного вызова, определенные в профиле кластера.
Например, как только команда BasicReset достигает уровня приложения на устройстве, список записей обратного вызова кластера указывает команде функцию обратного вызова BasicReset: zclSampleLight_BasicResetCB. Команда сброса приложения может затем восстановить все данные до заводских настроек по умолчанию.
Функция обратного вызова в приложении обеспечивает дополнительную обработку команды, специфичной для этого приложения. Эти функции обратного вызова работают вместе с ответом на входящую команду, если ответ является подходящим.
 
 
Рисунок 14: Пример обратных вызовов кластера

14.6 Функциональность отчетности по атрибутам

Модуль отчетов об атрибутах заботится о периодической отправке командных сообщений ZCL Report Attributes для всех отчетных атрибутов, определенных в приложении. Модуль также обрабатывает команды ZCL Configure Reporting и Read Reporting Configuration. Несколько независимых флагов компиляции управляют функциональностью отчетов, поэтому ненужные функциональные возможности могут быть исключены из кода для экономии ресурсов.
- Чтобы включить функцию отправки отчетов BDB на устройстве, включите опцию компиляции BDB_REPORTING.
- Чтобы включить функцию приема / обработки отчетов BDB, включите ZCL_REPORT_DESTINATION_DEVICE опция компиляции.
- Чтобы включить настройку параметров отчетов удаленных устройств, включите опцию компиляции ZCL_REPORT_CONFIGURING_DEVICE.
 
Реализация функции отправки отчета находится в bdb_reporting.c
 
Функциональность отчетов об атрибутах была реализована, как описано в документе ZCL [5], однако для оптимизации количества сообщений командных атрибутов отчетов, отправляемых по беспроводной сети, была создана консолидация для атрибутов в одном и том же кластере, для всех кластеров в каждой конечной точке. Другими словами, это означает, что все отчетные атрибуты в одном кластере будут иметь только один сводный Минимальный интервал отчетности и Максимальный отчет Интервальное значение. Подход консолидации, используемый для слияния Максимального интервала отчетности записи конфигурации атрибутов, заключается в получении минимального значения всех значений атрибутов одного кластера, минимальный консолидированный интервал отчетности кластера также является минимальным значением. Обратитесь к разделу 2.5.11.2.5 документа ZCL [5] для получения дополнительной информации о консолидации отчетных атрибутов.
 
Модуль отчетов об атрибутах автоматически просматривает определения атрибутов, зарегистрированные в приложении, для всех атрибутов с флагом ACCESS_REPORTABLE. Каждый из этих отчетных атрибутов будет иметь соответствующую запись конфигурации отчетов об атрибутах, для которой впоследствии будут установлены некоторые значения по умолчанию. Модуль отчетов об атрибутах автоматически запускает или останавливает создание отчетов об атрибутах в кластере конечной точки, привязка которой добавляется или удаляется.
 
В API BDB (расположенном в файле bdb_interface.h) есть метод с именем bdb_RepAddAttrCfgRecordDefaultToList, который используется для добавления значений по умолчанию каждой записи конфигурации отчетов об атрибутах. Этот метод необходимо вызвать до того, как устройство начнет ввод в эксплуатацию BDB. Если приложения не добавляют значения по умолчанию для заданной записи конфигурации отчетов об атрибутах, тогда применяются глобальные значения по умолчанию значения будут назначены, эти глобальные MACROS по умолчанию находятся в bdb_Reporting.h.
Когда конечный автомат BDB начинает ввод в эксплуатацию, модуль отчетов об атрибутах либо загружает ранее сохраненные записи конфигурации отчетов об атрибутах из NV, либо ищет определения атрибутов приложений, чтобы определить отчетные атрибуты и создать необходимые записи конфигурации отчетов об атрибутах, используя значения по умолчанию, ранее добавленные приложением. Затем модуль объединит отчетные атрибуты в каждом кластере каждой конечной точки, чтобы инициировать периодическую отправку командных сообщений Report Attributes с использованием значений максимального интервала отчетности.
 
Во время выполнения модуль отчетов об атрибутах прослушивает сообщения «Настроить команду отчетов» и повторно объединяет значения «Максимальный интервал отчетности» и «Минимальный интервал отчетности» кластера с учетом новых записей конфигурации отчетов об атрибутах, содержащихся в сообщении. Вызовы метода bdb_RepAddAttrCfgRecordDefaultToList после начала ввода в эксплуатацию BDB будут иметь влияет на текущие записи конфигурации отчетов об атрибутах.
 
Чтобы модуль отчетов об атрибутах управлял отправкой команд атрибутов отчета, когда атрибуты изменяют значение, приложение должно информировать модуль, когда любой отчетный атрибут имеет новое значение. Это уведомление должно быть сделано путем вызова метода bdb_RepChangedAttrValue API BDB. Атрибут Модуль отчетности будет получать текущее значение атрибута из обратного вызова, определенного в определениях атрибутов приложения, что означает, что новое значение должно быть установлено до вызова метода уведомления.

15. Commissioning - Ввод в эксплуатацию

Метод ввода в эксплуатацию BDB предоставляет механизм для вызова ряда процедур, который дает возможность легко подключать устройства вместе. В зависимости от используемых методов ввода в эксплуатацию устройства будут выполнять действия как формирование сетей, присоединение к существующим сетям и привязка конечных точек приложений.
Исходные файлы, которые контролируют процедуры ввода в эксплуатацию, находятся в группе файлов BDB в проектах IAR.
Интерфейс API находится в bdb_interface.h и описан в [1].
Интерфейс BDB предоставляет API для запуска одной или нескольких процедур ввода в эксплуатацию, определенных следующим образом:
 
bdb_StartCommissioning( mode )
 
где mode - битовая маска для режимов ввода в эксплуатацию, которая определяется как:
 
BDB_COMMISSIONING_MODE_INITIATOR_TL 0b00000001
BDB_COMMISSIONING_MODE_NWK_STEERING 0b00000010
BDB_COMMISSIONING_MODE_NWK_FORMATION 0b00000100
BDB_COMMISSIONING_MODE_FINDING_BINDING 0b00001000
 
Эта маска ввода в эксплуатацию добавляется к текущим режимам ввода в эксплуатацию. Задачи также выполняется с приоритетом, указанным ранее (сначала TL в качестве инициатора, затем управление Nwk, затем формирование и, наконец, поиск и обязательна). Приоритет задач проверяется всякий раз, когда завершаются другие задачи, поэтому, если TL запрашивается раньше Nwk Steering и Formation выполняются, тогда инициатор TL будет обрабатываться после Nwk Steering, но до Formation. Задачи могут быть добавлены в любое время (например, в ответ на уведомление о вводе в эксплуатацию).
Существуют другие состояния ввода в эксплуатацию, что состояние машины BDB обрабатывает как режимы, это INITIALIZATION и PARENT_LOST. Эти состояния не должны использоваться приложением напрямую.

15.1 BDB notifications - уведомления

Приложение должно зарегистрировать обратный вызов, используя bdb_RegisterCommissioningStatusCB, в котором оно будет получать уведомления о процессе ввода в эксплуатацию, выполняемого модулем BDB. Приложение может вызвать другой способ ввода в эксплуатацию после получения определенного уведомления, например, устройство маршрутизатора может начать управление сетью найти подходящую сеть и посчитать, сколько раз этот процесс не удался; если этот процесс терпит неудачу "х" раз подряд, он может принять решение об изменении маски канала для поиска сетей в других каналах, которые не были предприняты, или для вызова формирования и создать свою собственную сеть. Полный API описан в [1].
Уведомления вызываются, когда начинаются определенные задачи или когда они заканчивают с результирующим статусом. Некоторые уведомления
являются исключительными для определенных типов логических устройств или имеют разное значение для разных логических устройств.
Каждое уведомление будет иметь указатель на структуру типа bdbCommissioningModeMsg_t, которая содержит режим ввода в эксплуатацию сообщается, статус и маска остальных режимов ввода в эксплуатацию должны быть выполнены.
Определения уведомлений можно найти в bdb_interface.h, а также в полной таблице уведомлений и ее описание можно найти в следующей таблице. В первом столбце приведены режимы ввода в эксплуатацию, обратите внимание, что эти определения макросов можно найти в коде как BDB_COMMISSIONING_mode, где слово «mode» должно быть заменяется любым из режимов, найденных в первом столбце. То же самое относится ко второму столбцу, которые являются статусы режима ввода в эксплуатацию. Определения макросов в коде можно найти как BDB_COMMISSIONING_status, где слово «status» должно быть заменено любым из статусов, найденных в втором столбеце.
 
Режим ввода в эксплуатацию
(BDB_COMMISSIONING_mode)
Статус
(BDB_COMMISSIONING_status)
 Описание
INITIALIZATION NETWORK_RESTORED
Отправлять, только если устройство восстановило свои сетевые параметры.
На конечных устройствах, если не найден родитель с восстановлеными параметрами сети, Parent Lost режим со статусом No Network уведомление.
NWK_STEERING (for Router and End Devices)
 IN_PROGRESS
Уведомляет о запуске сетевого управления (только если устройство не находится в сети, в противном случае сообщает об успехе)
NO_NETWORK
Подходящая сеть не была найдена в первичной маске канала или вторичного канала или процесс присоединения потерпел неудачу в попытке соединения к сети.
TCLK_EX_FAILURE
Устройство успешно подключено к сети, но не удалось выполнить процесс обмена Trust Center Link Key. Устройство будет сброшено до заводских установок после сообщения об этом приложению.
SUCCESS
Устройство сейчас в сети и транслировало Management Permit Joining ZDO.
NWK_STEERING (for Coordinators) NO_NETWORK
Устройство не находится в сети, поэтому оно не можетвыполнить это действие.
SUCCESS Устройство находится в сети и транслировало Management Permit Joining ZDO.
FORMATION IN_PROGRESS Уведомляет о начале процесса формирования.
SUCCESS Сеть была успешно создана.
FORMATION_FAILURE
Устройство не может создать сеть с этими параметрами.
FINDING_BINDING FB_TARGET_IN_PROGRESS
Указывает начало поиска и привязки Finding and Binding как цель. Никакое уведомление не дается этим обратным вызовом когда процесс заканчивается.
FB_INITITATOR_IN_PROGRESS
Указывает начало поиска и привязки Finding and Binding как инициатор Initiator.
FB_NO_IDENTIFY_QUERY_RESPONSE
После завершения процесса поиска и привязки как инициатор (однократная попытка периодической попытки), не было идентифицировано ответов на запросы.
FB_BINDING_TABLE_FULL
В процессе поиска и привязки переплетная таблица заполнена, поэтому процесс останавливается и дополнительные привязки не могут быть добавлены.
FAILURE
Не найдена конечная точка для выполнения поиска и
привязки или конечная точка не были правильно реализовал кластер идентификации.
TOUCHLINK TL_TARGET_FAILURE
Узел не присоединился к сети, когда запрашивался при TouchLink
TL_NOT_AA_CAPABLE
Инициатор не может назначать адреса при TouchLink
TL_NO_SCAN_RESPONSE
Нет ответа на запрос команды сканирования Scan Reques inter-PAN была получена при TouchLink
TL_NOT_PERMITTED
Была сделана попытка кражи контактной ссылки, когда узел уже подключен к централизованной сети безопасности.
PARENT_LOST (Only for EndDevices) NO_NETWORK
Уведомляется, если конечное устройство теряет связь с родительским устройством или если после инициализации не может найти родительское устройство в введена в эксплуатацию сеть.
NETWORK_RESTORED
Уведомление о получении подходящего родительского устройства
найден и процесс присоединения прошел успешно.
Таблица 1: Состояние ввода в эксплуатацию, сообщаемое различными режимами ввода в эксплуатацию.

 

15.2 Процедура инициализации

Интерфейс BDB будет выполнять инициализацию один раз за цикл питания и управляется глобальной RAM переменной bdb_initialization и запускается любым вызовом bdb_StartCommissioning () с любым вводом в эксплуатацию маска режима. Процедура инициализации извлекает параметры сети из Nv, если атрибут bdbNodeIsOnANetwork - TRUE. Этот атрибут также хранится в Nv и извлекается из Nv во время процесса инициализации. Для устройств-координаторов и маршрутизаторов будет выполнено автоматическое восстановление (устройство возобновит работу операции в сети, как если бы она никогда не уходила, за исключением того, что она будет обрабатывать process parent annce, см. раздел 9.12.3, чтобы узнать, когда parent annce срабатывает). Конечные устройства восстановят параметры сети и попытаются выполнить соединение на любом доступном родителе  в одной сети только один раз. Эта процедура показана на рисунке 15.
 

Рисунок 15: Процедуры инициализации: а) Маршрутизатор и координаторы, б) Конечные устройства.

Обратите внимание, что если процесс инициализации завершится неудачно для конечного устройства, он уведомит приложение о статусе PARENT_LOST.
Обратитесь к разделу 15.3 о восстановлении сети или разделу 15.9, чтобы восстановить заводские настройки устройства.
 

15.3 Parent Lost - Родитель потерян 

Если конечное устройство теряет связь со своим родительским устройством или сбрасывается, находясь в сети, модуль BDB уведомит приложение о состоянии BDB_COMMISSIONING_PARENT_LOST, после чего конечное устройство не может выполнить любой другой метод ввода в эксплуатацию. Устройство должно либо восстановить свою сеть, найдя другого родителя или сброс до заводских настроек, а затем снова ввод в эксплуатацию. Для восстановления сети устройство должно позвонить bdb_ZedAttemptRecoverNwk, это заставит устройство выполнить одно активное сканирование в том же канале, в котором был частью сети для поиска любого подходящего родителя (тот же Extended PANID и дочернее устройство вместимость). Это означает, что устройство отправит только один запрос маяка, и если подходящее родительское устройство не найдено, другое приложение BDB_COMMISSIONING_PARENT_LOST отправлено приложению. Приложение отвечает за попытку восстановления сети, но рекомендуется иметь период, в течение которого попытки короткий интервал, а затем переходит к большему интервалу, чтобы уменьшить потребление энергии. Если поиск и привязка Finding and Binding были во время как устройство потеряло своего родителя, оно продолжит работу и возобновит работу в течение времени, оставшегося после устройство восстанавливает свою работу.
 

15.4 Процедура управления сетью для узла в сети

Если управление сетью вызывается устройством, которое уже находится в сети (для bdbNodeIsOnANetwork установлено значение TRUE), оно будет транслировать запрос на присоединение в течение 180 секунд (BDBC_MIN_COMMISSIONING_TIME), после чего устройство уведомит BDB_COMMISSIONING_SUCCESS.
 
 
Рисунок 16. Процедура управления сетью для узла в сети.
 

15.5 Процедура управления сетью для узла, не находящегося в сети

Эта процедура выполняется, когда запрашивается управление сетью, а устройство не находится в сети(bdbNodeIsOnANetwork установлен в ЛОЖЬ). Это заставит устройство начать поиск подходящих сетей для подключения.
Процедура показана на рисунке 17 и описана следующим образом:
1. Устройство выполнит сканирование всех каналов, определенных в BDB_DEFAULT_PRIMARY_CHANNEL_SET, поиск любой подходящей сети и создание список сетевых дескрипторов найденных сетей.
а. Приложение может отфильтровать найденные сети, зарегистрировав функцию обратного вызова с bdb_RegisterForFilterNwkDescCB (). Обратный вызов приложения получит список сетевых дескрипторов, содержащий все найденные сети, тогда приложение может использовать bdb_nwkDescFree () для выпуска сетевых дескрипторов сетей, которые он не будет пытаться присоединиться (например, попытаться выполнить только известные сети с расширенным идентификатором PAN).
б. Если подходящие сети не найдены или устройство не может выполнить соединение в найденных сетях (подключение не было успешным или не удалось получить сетевой ключ), устройство перейдет к выполнить те же шаги, но с маской канала, определенной в BDB_DEFAULT_SECONDARY_CHANNEL_SET.
с. Только ненулевые маски каналов используются для обнаружения сети.
2. Конечный автомат BDB попытается выполнить сопоставление и аутентификацию в подходящих сетях обнаружены с использованием ключей безопасности для централизованных сетей (ключ по умолчанию или код установки) или распределенных сети, как определено в разделе 10. Для централизованных сетей также будет выполняться обмен TCLK.
3. Если процедура присоединения завершена, присоединяющееся устройство будет передавать запрос на присоединение к обновите тайм-аут соединения (refresh the joining timeout) для других устройств, пытающихся присоединиться одновременно. До сети менеджер, чтобы закрыть сеть для присоединения при желании, отправив запрос на разрешение на присоединение с таймаутом = 0 ..
Каждый шаг сообщает приложению о статусе в регистре функции обратного вызова с bdb_RegisterCommissioningStatusCB (). Возможные статусы для этого процесса ввода в эксплуатацию описано в таблице 1.
 
Рисунок 17: Процедура управления сетью для узла, не находящегося в сети.
 

15.6 Формирование сети

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

Рисунок 18: Формирование сети.

15.7 Поиск и связывание - Finding and Binding

Процедура поиска и привязки может быть выполнена как инициатор, цель или оба, в зависимости от кластеров, которые конечная точка, выполняющая процедуру поиска и привязки, имеет. Это означает, что если конечная точка имеет кластер, который как предназначено для инициатора, процесс поиска и привязки для этой конечной точки будет выполняться как инициатор. Определения для инициатора или цели на кластерах можно найти в спецификации ZigBee ZCL [5].
Приложение должно указать, с какой конечной точкой оно хочет выполнить процедуру поиска и привязки, вызвав bdb_SetIdentifyActiveEndpoint (). Обратите внимание, что указанная конечная точка должна содержать кластер идентификации для того, чтобы можно было выполнить процедуру.

15.7.1 Процедура поиска и привязки для целевой конечной точки

Когда поиск и привязка запускаются на целевой конечной точке, конечная точка идентифицирует себя в течение конечного периода времени и обрабатывает команды запроса идентификации от устройства-инициатора. Этот режим ввода в эксплуатацию будет уведомлять, когда он начинается с уведомления BDB_COMMISSIONING_FB_INITIATOR_IN_PROGRESS, но оно не уведомит, когда процесс ввода в эксплуатацию заканчивается уведомлением BDB. Вместо этого приложение должно использовать bdb_RegisterIdentifyTimeChangeCB() для регистрации обратного вызова, в котором обрабатываются изменения в определить кластер.

Рисунок 19. Процедура поиска и привязки для целевой конечной точки.

15.7.2 Процедура поиска и привязки для конечной точки инициатора

В этой процедуре инициатор будет искать идентифицирующие конечные точки, отправляя команды запроса идентификации в широковещательное сообщение и запрос простого дескриптора для каждого найденного узла. Затем связывает для соответствующего приложения кластеры создаются в инициаторе. Если запрашивается привязка группы, конечная точка инициатора настраивает членство в группе целевой конечной точки.
Процесс поиска и привязки для инициирующего устройства показан на рисунке 20 и описан здесь:
1. Приложение уведомляется о запуске метода ввода в эксплуатацию, и локальное устройство передает Identify Query command.
а. Если в течение процесса не получены ответы на идентифицирующие запросы, приложение получает BDB_COMMISSIONING_FB NO_IDENTIFY_QUERY_RESPONSE и процесс завершается.
б. Если устройство получает один или несколько ответов, устройство создает список ответов устройства. (отвечающие устройства).
2. Локальное устройство отправляет запрос простого дескриптора ZDO каждому устройству в списке (по одному за раз), если нет ответ на запрос простого дескриптора - получение следующего в списке, а ответивший отказ после того, как список был перенесен до INDING_AND_BINDING_MAX_ATTEMPTS, перед тем как пометить респондент полностью обработан.
3. После получения простого дескрипторного ответа локальное устройство будет искать противоположное совпадение кластеры приложений с конечной точкой на локальном устройстве, выполняющем поиск и привязку процедура.
4. Если устройство выполняет одноадресные привязки (BDB_DEFAULT_COMMISSIONING_GROUP_ID! = 0xFFFF), IEEE-адрес устройства-респондента ищется в диспетчере адресов, если он не найден, это запрашивается с помощью команды запроса адреса ZDO IEEE. Этот респондент остается в процессе до ответ адреса IEEE получен, и запись привязки создана для соответствующих кластеров, или до FINDING_AND_BINDING_MAX_ATTEMPTS попытки сделаны, после чего этот респондент помечен как обрабатывается без добавления каких-либо привязок. Для групповых привязок (BDB_DEFAULT_COMMISSIONING_GROUP_ID ! = 0xFFFF), привязки создаются, если найдено какое-либо совпадение. См. Спецификацию ZigBee ZCL для определение прикладных кластеров.
а. Приложение может зарегистрировать обратный вызов с помощью bdb_RegisterBindNotificationCB () для получать уведомления о каждой привязке, созданной тем или иным способом.
б. Если таблица привязок заполняется во время этого процесса, приложение получит уведомление BDB_COMMISSIONING_FB TABLE_FULL и процесс будет завершен.
5. Локальное устройство будет повторять шаги с 2 по 4, пока все устройства, которые ответили на запрос идентификации команда, и затем приложение BDB_COMMISSIONING_SUCCESS будет уведомлено.
Процедура поиска и связывания для групп позволила APS Acknowledge включить повышение надежности при создании
членство в группе на удаленном устройстве.
Процесс поиска и привязки для устройства-инициатора может быть настроен на периодическое выполнение каждые FINDING_AND_BINDING_PERIODIC_TIME секунд больше BDBC_MIN_COMMISSIONING_TIME (180) секунд. Это определяется FINDING_AND_BINDING_PERIODIC_ENABLE, которая по умолчанию установлена ​​в TRUE.
В этом случае, если одно и то же устройство отвечает на множественные команды запроса идентификации с локального устройства, это не будет
дублируется в списке и будет пытаться до FINDING_AND_BINDING_MAX_ATTEMPTS раз. Эта процедура может быть прервана досрочно, вызвав bdb_StopInitiatorFindingBinding ().
 
Рисунок 20. Процедура поиска и привязки для конечной точки инициатора.

15.8 Ввод в эксплуатацию Touchlink

Ввод в эксплуатацию Touchlink - это дополнительный механизм ввода в эксплуатацию, определенный в спецификации ZigBee BDB, где узлы вводятся в эксплуатацию с использованием связи между PAN и требуют физической близости устройства.

15.8.1 Конфигурации

Следующие конфигурации должны быть изменены пользователем для создания действительного устройства Touchlink. Все они находятся в файле bdb_interface.h:

15.8.1.1 Установка ключа

Все коммерческие продукты Touchlink используют «мастер-ключ Touchlink» и «предварительно установленный ключ связи Touchlink».
Этот набор ключей может быть доступен производителям, которые успешно сертифицировали продукт Touchlink, используя набор ключей сертификации предоставляется по умолчанию.
Обратите внимание, что любая реализация Touchlink не сможет взаимодействовать с коммерческими устройствами Touchlink без Touchlink master keys. После того, как мастер-ключи Touchlink были получены, они должны быть установлены в коде со следующими модификациями:
1. Перезаписать TOUCHLINK_CERTIFICATION_ENC_KEY
TOUCHLINK_CERTIFICATION_LINK_KEY и с фактическими секретными значениями.
2. Измените определение TOUCHLINK_KEY_INDEX на TOUCHLINK_KEY_INDEX_MASTER.

15.8.1.2 Константы

BDB определяет значения констант и внутренних атрибутов по умолчанию, чтобы устройство могло управлять способом Touchlink
устройство работает (см. раздел 5.2 в Base Device Behavior Specification [7]).
 
Определение
Спецификации константы /
Атрибут по умолчанию
 Значение
BDBCTL_INTER_PAN_TRANS_ID_LIFETIME bdbcTLInterPANTransIdLifetime 8000
BDBCTL_MIN_STARTUP_DELAY_TIME bdbcTLMinStartupDelayTime 2000
BDBCTL_PRIMARY_CHANNEL_LIST bdbcTLPrimaryChannelSet 0x02108800
BDBCTL_RX_WINDOW_DURATION bdbcTLRxWindowDuration 5000
BDBCTL_SCAN_TIME_BASE_DURATION bdbcTLScanTimeBaseDuration 250
BDBCTL_SECONDARY_CHANNEL_LIST bdbcTLSecondaryChannelSet 0x05EF7000
Таблица 2: Определения, полученные из спецификации Base Device Behavior ZigBee

15.8.1.3 Настройка конечной точки - Endpoint Setup

Так как ввод в действие Touchlink управляется отдельной задачей, отделенной от приложений, ее конечная точка может быть переопределена на любое допустимое значение, которое не используется какой-либо конечной точкой приложения на устройстве и его device ID, появляющийся в простом дескрипторе, не должен быть равен никакому допустимому значению, чтобы предотвратить случайное совпадение.
TOUCHLINK_INTERNAL_ENDPOINT (по умолчанию = 13).
TOUCHLINK_INTERNAL_DEVICE_ID (по умолчанию = 0xE15E).

15.8.1.4 Определение интервала времени последовательности

В последовательности ввода в действие Touchlink, если получена соответствующая команда ответа сканирования, инициатор отправить команду идентификации выбранной цели, а затем ждать интервал времени, определенный следующим параметром (в миллисекундах) перед отправкой команды запуска или присоединения к сети.
Когда получена команда запроса на идентификацию со значением поля длительности идентификации, установленным в 0xffff (время по умолчанию известно получателем), функция обратного вызова Identify приложения будет вызываться со значением продолжительности, установленным в соответствии с следующий параметр (в секундах):
TOUCHLINK_DEFAULT_IDENTIFY_TIME - определить продолжительность, если она не указана в полученной команде (по умолчанию = 3)
Можно грациозно прервать процесс сенсорной связи (см. Раздел 8.7 в Base Device Behavior Specification 2), пока конец этого временного интервала. Кроме того, целевое состояние может необратимо измениться. Если прерывание используется и контролируется в результате взаимодействия с человеком рекомендуется увеличить это значение (например, до 2000). Обратите внимание, что увеличение его до более высокого значения, чем значение по умолчанию, также увеличивает риск сбоя touch-link из-за истечения срока действия транзакции, особенно если это сделано на вторичном наборе каналов.

15.8.1.5 Пороги разделения свободных диапазонов

При запуске ввода в эксплуатацию Touchlink с устройствами, которые способны назначать адреса, диапазоны свободного сетевые адреса и групповые идентификаторы, хранящиеся у инициатора, могут быть разделены и переданы цели.
Инициатор может разделить свои диапазоны, пока оставшийся диапазон и целевой диапазон не меньше минимального размера, определяемый следующими параметрами:
TOUCHLINK_ADDR_THRESHOLD - минимальный размер диапазона адресов после разделения (по умолчанию = 10).
TOUCHLINK_GRP_ID_THRESHOLD - минимальный размер диапазона идентификаторов групп после разделения (по умолчанию = 10).

15.8.1.6 Пороги разделения свободных диапазонов

Эта функция позволяет переопределить выбор цели по умолчанию на основе RSSI во время Touchlink с помощью  выбора функции приложения. Функция выбора приложения может использоваться в сценариях, где ожидается, что несколько целей имеют одинаковый RSSI (например, несколько источников света, связанных вместе) и позволяют интегрировать другие параметры в выборку (например, заводское новое состояние, ранее выбранное устройство и т. д.).

15.8.2. Параметры только для разработки

Следующие параметры, если они включены, нарушают правила соответствия и безопасности Touchlink. Они могут быть использованы для помочь во время разработки, но должен быть отключен перед выпуском. Все параметры могут быть прокомментированы в bdb.h файл, вместо того, чтобы быть определенным глобально в проекте.

15.8.2.1 Смещение канала

Флаги Ch_Plus_1, Ch_Plus_2 или Ch_Plus_3 могут быть установлены в определении TOUCHLINK_CH_OFFSET в bdb.h для смещения набора первичных каналов, что позволяет тестировать несколько устройств Touchlink, установленных в одном пространстве, без помехи только для целей тестирования. TOUCHLINK_CH_OFFSET по умолчанию определяется как No_Ch_offset, это означает, что к первичному набору каналов сдвиг не применяется.

15.8.2.2 Фиксированный выбор первого канала

Флаг TOUCHLINK_DEV_SELECT_FIRST_CHANNEL, если он включен во время компиляции, переопределит случайный механизм выбора канала, используемый устройством Touchlink, и он всегда будет выбирать первый первичный канал.

15.8.3 Процедура ввода в эксплуатацию Touchlink для инициатора

В этой процедуре инициатор сканирует узлы, которые поддерживают touchlink, и, если таковые имеются, touchlink процедура ввода в эксплуатацию устанавливает новую распределенную сеть с целью.

Рисунок 21: Процедура ввода в эксплуатацию Touchlink для инициатора.

15.8.4 Процедура ввода в действие Touchlink для цели

В этой процедуре цель отвечает на команды ввода в действие touchlink от инициатора, чтобы начать новый сеть или присоединиться к сети инициатора.
Рисунок 22: Процедура ввода в действие touchlink для цели.

15.9 Процедура сброса

Это должно быть взаимодействие следующим образом:

15.9.1 Сброс через базовый кластер

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

15.9.2 Сброс с помощью Кластера ввода в эксплуатацию Touchlink

Если Touchlink в качестве цели поддерживается, этот механизм сброса заставит устройство обрабатывать запрос на отпуск к себе с Rejoin, установленным в FALSE, и RemoveChildren в FALSE. См. Раздел 15.9.5 для более подробной информации о процессе оставить запрос.

15.9.3 Сброс с помощью команды Mgmt_leave_req ZDO

Если команда действительна, принимающее устройство обработает запрос на отпуск для себя с Rejoin, установленным в FALSE, и
RemoveChildren установлен в FALSE. См. Раздел 15.9.5 для более подробной информации о процессе запроса на отпуск.

15.9.4 Сброс через локальное действие

Этот тип сброса - тот, который пользователь будет запускать при нажатии специальной кнопки или выполнять последовательность действий для сброса
заводское новое локальное устройство. Это обрабатывается как сетевой запрос на отпуск к себе с Rejoin, установленным в FALSE и RemoveChildren имеет значение FALSE для устройств, не являющихся координаторами. Для координирующих устройств это реализует последовательность шаги для очистки тех же данных о сохранении ZigBee, что и команда выхода из сети, как устройства-координаторы не может обработать команды выхода из сети. См. Раздел 15.9.5 для более подробной информации о процессе запроса на отпуск. к для выполнения этого действия вызовите функцию bdb_resetLocalAction ().

15.9.5 Сброс через Nwk Leave request

Запрос на выход из сети обрабатывается в зависимости от логического устройства, которое получает команду. Координатор устройства игнорировать команду (включая те, что были выданы самим собой), в то время как конечные устройства принимают команду только в том случае, если сам или его родительское устройство. Устройства маршрутизатора обрабатывают команду от себя и от любого другого устройства в сети если NwkLeaveRequestAllowed включен. Действительный запрос заставит устройство очистить все постоянные данные ZigBee (Привязки, сетевые параметры, группы, атрибуты и т. Д.), За исключением счетчика кадров исходящей сети для сеть, которая остается.

16. Сетевой менеджер - Network Manager

16.1 Обзор

Одно устройство может стать диспетчером сети. Это устройство выступает в качестве центрального механизма для приема сеть:
  • Отчеты о помехах в канале и изменение канала сети при обнаружении помех, и
  • Отчеты о конфликте PAN ID и изменение идентификатора PAN сети в случае обнаружения конфликта.
По умолчанию адрес сетевого менеджера является координатором. Однако это можно обновить, отправив команду Mgmt_NWK_Update_req с другим коротким адресом для менеджера сети. Устройство, которое является диспетчером сети устанавливает бит диспетчера сети в маске сервера в дескрипторе узла и отвечает на команды System_Server_Discovery_req.
Реализация Network Manager находится в файлах ZDNwkMgr.c и ZDNwkMgr.h.

16.2 Помехи в канале

Диспетчер сети реализует меры по изменению частоты в условиях помех. Этот раздел объясняет, как с помощью команд Mgmt_NWK_Update_req и Mgmt_NWK_Update_notify канал сеть может быть изменена.

16.2.1 Обнаружение помех в канале

Каждый маршрутизатор или координатор отслеживает сбои передачи, используя поле Transmit Failure в соседней таблице, а также попытка сохранить счетчик NIB для общего количества передач. Как только общее количество попыток передачи закончено ZDNWKMGR_MIN_TRANSMISSIONS (20), если ошибки передачи превышают ZDNWKMGR_CI_TX_FAILURE (25) в процентах от отправленных сообщений устройство может обнаружить помехи в используемом канале.
Затем устройство выполняет следующие действия:
1. Проведите сканирование энергии на всех каналах. Если это сканирование энергии не указывает на более высокую энергию тока канал, чем другие каналы, никаких действий не предпринимается. Устройство должно продолжать работать как обычно, а счетчики сообщений не сбрасываются.
2. Если сканирование энергии указывает на увеличение энергии в используемом канале, Mgmt_NWK_Update_notify следует отправить диспетчеру сети, чтобы указать, что помехи присутствуют. Этот отчет отправляется как APS одноадресная передача с подтверждением и после получения подтверждения общая передача и передача счетчики ошибок сбрасываются на ноль.
3. Чтобы устройство с проблемами связи не отправляло отчеты в Network Manager постоянно, устройство не отправляет Mgmt_NWK_Update_notify более 4 раз в час.

16.2.2 Разрешение помех в канале

После получения незапрошенного Mgmt_NWK_Update_notify, Network Manager применяет различные методы для лучшего определить, когда требуется смена канала и как выбрать наиболее подходящий канал.
Сетевой менеджер делает следующее:
1. После получения сообщения Mgmt_NWK_Update_notify администратор сети определяет, является ли изменение канала требуется с использованием следующих критериев:
а. Если какое-либо одно устройство имеет более ZDNWKMGR_CC_TX_FAILURE (50) процентов передачи при сбоях следует учитывать смену канала.
б. Диспетчер сети сравнивает частоту отказов, сообщенную на текущем канале, с сохраненная частота отказов от последнего изменения канала. Если текущая частота отказов выше, чем последняя частота отказов, после чего рассматривается смена канала.
2. Если приведенные выше данные указывают на то, что следует рассмотреть изменение канала, Network Manager завершает следующий:
а. Выберите один канал на основе Mgmt_NWK_Update_notify на основе самой низкой энергии. Это предлагаемый новый канал. Если этот новый канал не имеет уровень энергии ниже допустимый порог ZDNWKMGR_ACCEPTABLE_ENERGY_LEVEL, смена канала не должно быть сделано.
3. Перед сменой каналов Network Manager сохраняет значение сканирования энергии в качестве последнего сканирования энергии значение и частота отказов от существующего канала в качестве последней частоты отказов.
4. Диспетчер сети передает (всем маршрутизаторам и координатору) сообщение Mgmt_NWK_Update_req устройства нового канала. Затем он увеличивает параметр nwkUpdateId в NIB и маяке полезная нагрузка, и включает его в Mgmt_NWK_Update_req. Диспетчер сети устанавливает таймер на основе значение ZDNWKMGR_UPDATE_REQUEST_TIMER (т.е. apsChannelTimer) при выдаче Mgmt_NWK_Update_req, который меняет каналы и не будет выдавать еще одну такую ​​команду до этого таймер истекает.
5. При выдаче Mgmt_NWK_Update_req со сменой каналов локальный сетевой менеджер устанавливает таймер, равный nwkNetworkBroadcastDeliveryTime и переключает каналы по истечении этого таймер.
После получения Mgmt_NWK_Update_req со сменой каналов от диспетчера сети устройство устанавливает таймер равен nwkNetworkBroadcastDeliveryTime и переключает каналы по истечении этого таймера каждый узел сохраняет полученный nwkUpdateId в полезной нагрузке NIB и маяка, а также сбрасывает общее количество передаваемых данных и счетчики ошибок передачи.
Для устройств с RxOnWhenIdle, равным FALSE, любое изменение сетевого канала не будет принято. На этих устройствах или в маршрутизаторах, которые потеряли сеть, активное сканирование проводится по списку каналов в NIB (т.е. apsChannelMask) использование расширенного идентификатора PAN (EPID) для поиска сети. Если расширенный идентификатор PAN найден на разных каналах устройство выбирает канал с более высоким значением в параметре nwkUpdateId. Если расширенный идентификатор PAN не найден с помощью списка apsChannelMask, сканирование завершено с использованием всех каналов.

16.2.3 Краткое руководство

Установка минимального количества попыток передачи для канала обнаружение помех Channel Interference detection
Set ZDNWKMGR_MIN_TRANSMISSIONS
(in ZDNwkMgr.h)
Установка минимальной частоты ошибок при передаче для канала обнаружение помех Channel Interference detection
Set ZDNWKMGR_CI_TX_FAILURE
(in ZDNwkMgr.h)
Установка минимальной частоты ошибок при передаче для смены канала Channel Change
Set ZDNWKMGR_CC_TX_FAILURE
(in ZDNwkMgr.h)
Установка допустимого порога уровня энергии для смены канала Channel Change
Set ZDNWKMGR_ACCEPTABLE_ENERGY_LEVEL
(in ZDNwkMgr.h)
Настройка таймера канала APS для выдачи изменений канала Channel Change
Set ZDNWKMGR_UPDATE_REQUEST_TIMER
(in ZDNwkMgr.h)

16.3 Конфликт PAN ID

Поскольку 16-битный идентификатор PAN не является уникальным номером, существует вероятность конфликта идентификатора PAN в локальной сети окрестности. Диспетчер сети реализует разрешение конфликтов PAN ID. Этот раздел объясняет, как при использовании команд Network Report и Update, PAN ID сети может быть обновлен.

16.3.1 Обнаружение конфликта PAN ID

Любое устройство, работающее в сети и получающее сигнал маяка, в котором идентификатор PAN идентификатора маяка соответствует его собственный PAN ID, но значение EPID, содержащееся в полезной нагрузке маяка, либо отсутствует, либо не равно cчитается, что nwkExtendedPANID обнаружил конфликт идентификатора PAN.
Узел, обнаруживший конфликт идентификатора PAN, отправляет команду сетевого отчета типа конфликта идентификатора PAN назначенный сетевой менеджер, идентифицируемый nwkManagerAddr в NIB. Поле «Информация об отчете» Report Information field будет содержит список всех 16-битных идентификаторов PAN, которые используются в локальной среде. Список построен из результатов АКТИВНОГО сканирования.

16.3.2 Разрешение конфликтов PAN ID

При получении команды «Отчет по сети» Network Report command диспетчер сети выбирает новый 16-разрядный идентификатор PAN для сети.
Новый PAN ID выбирается случайным образом, но выполняется проверка, чтобы убедиться, что выбранный PAN ID не содержится в поле информация об отчете Report Information field команды сетевого отчета.
После выбора нового PAN ID сетевой менеджер сначала увеличивает атрибут NIB nwkUpdateID и затем создает команду обновления сети типа обновления PAN ID. Поле Информация об обновлении Report Information field установлено на значение нового PAN ID. После отправки этой команды диспетчер сети запускает таймер со значением равно nwkNetworkBroadcastDeliveryTime секунд. Когда таймер истекает, он меняет свой текущий идентификатор PAN на
вновь выбранный.
По получении команды обновления сети типа обновления идентификатора PAN от диспетчера сети, устройства (в том же сеть) запускает таймер со значением, равным nwkNetworkBroadcastDeliveryTime секунд. Когда таймер истекает, устройство изменяет свой текущий идентификатор PAN на значение, содержащееся в поле «Информация об обновлении». Это также хранит новый получил nwkUpdateID в NIB и полезную нагрузку маяка.
 

17. Сохранение питания - Green Power

17.1 Введение

В качестве требования для сертификации Z3.0 все устройства маршрутизации ZigBee (координаторы, маршрутизаторы) должны поддерживать Green
Power Basic proxy - это приложение, которое может передавать команды с GPD на устройство GP Sink.
GPD - это устройство, которое имеет очень ограниченную мощность или зависит от сбора энергии для функционирования, и оно не может выполнить двустороннюю связь для установления связи с сетью ZigBee. Эти GPD используют Inter-PAN кадры для ввода себя в сеть или для доставки команд. Методы ввода в эксплуатацию и тип команды, поддерживаемые GPD, будут зависеть от его возможностей и ресурсов. Детали тех ввод в эксплуатацию
методы и команды выходят за рамки этого документа.
Базовый прокси Basic proxy требует реализации заглушки GP и кластера GP. Заглушка GP обрабатывает Inter-PAN команды и передает их в приложение конечной точки GP. Он также отправляет кадры данных GP обратно в GPD наверняка методы ввода в эксплуатацию. Заглушка GP определена таким образом, что различные приложения могут располагаться поверх нее, например устройство для мойки Реализация устройства Sink выходит за рамки этого документа. Для получения дополнительной информации о Sink Device относится к [8], также для интерфейса заглушки GP stub interface, к [1] ​​и файлу заголовка dGP_stub.h.
GP реализован в зарезервированной конечной точке 242 ZigBee.

17.2 Green Power Basic Proxy

Поскольку базовый прокси-сервер Basic Proxy GP является приложением для передачи команд на устройство Sink, он не обеспечивает функциональность, которая должна обрабатываться фактическим приложением, работающим на базовом прокси-устройстве, реализующем его (это означает ваше фактическое применение, свет, выключатель и т. д.). Единственный интерфейс, который имеет эта функциональность, это следующий:
  • gp_RegisterGPChangeChannelReqCB (): зарегистрируйте обратный вызов, чтобы запросить у вашего приложения разрешение на переключение операционного канала на канал GPD для ввода в эксплуатацию GPD в течение не более gpBirectionalCommissioningChangeChannelTimeout (5 секунд). Зарегистрированный обратный вызов может вернуть FALSE, чтобы не допустить смену канала, если операция приложения не может быть прервано. Модуль BDB также проверяет операции, прежде чем запрашивать приложение. Если приложение возвращает TRUE или обратный вызов не зарегистрирован, основное прокси-приложение GP будет обрабатывать смена каналов.

18. Inter-PAN передача - Inter-PAN Transmission

18.1 Обзор

Передача между PAN позволяет устройствам ZigBee выполнять ограниченный, небезопасный и, возможно, анонимный обмен информация с устройств по соседству без необходимости создавать или присоединяться к той же сети ZigBee.
Функция Inter-PAN реализована на уровне заглушки APS, который можно включить в проект, определив опцию компиляции INTER_PAN и включение файлов stub_aps.c и stub_aps.h в проект.

18.2 Обмен данными

Обмен данными между PAN осуществляется на уровне заглушки APS, который доступен через INTERP-SAP параллельно с
нормальный APSDE-SAP:
  • INTERP_DataReq () и APSDE_DataReq () вызываются из AF_DataRequest () для отправки сообщения между панорамированием и внутрипанелью соответственно.
  • INTERP_DataIndication () вызывает APSDE_DataIndication (), чтобы указать передачу данных между панорамированием к локальному объекту прикладного уровня. Затем приложение получает данные Inter-PAN как обычное входящее сообщение данных  APS_INCOMING_MSG) из подуровня APS с адресом источника принадлежность к внешней PAN (проверяется API StubAPS_InterPan ()).
  • INTERP_DataConfirm () вызывает afDataConfirm () для отправки данных между панорамированием обратно к заявке. Приложение получает нормальное подтверждение данных (AF_DATA_CONFIRM_CMD) от AF подслой.
Уровень заглушки APS также предоставляет интерфейсы для переключения каналов связи между панорамированием и проверки Inter-
PAN соединения Inter-PAN сообщения. Пожалуйста, обратитесь к документу Z-Stack API [1] для подробного описания API Inter-PAN.
API StubAPS_InterPan () используется для проверки сообщений между панорамированием. Сообщение рассматривается как PAN-сообщение, если оно соответствует одному из следующих критериев:
  • Текущий канал связи отличается от канала NIB устройства, или
  • Текущий канал связи совпадает с каналом NIB устройства, но сообщение предназначено для PAN, отличный от идентификатора NIB PAN устройства, или
  • Текущий канал связи совпадает с каналом NIB устройства, и сообщение предназначено для той же PAN, что и идентификатор NIB PAN устройства, но конечной точкой приложения назначения является Inter-PAN конечная точка (0xFE). Этот случай верен для ответного сообщения Inter-PAN, которое отправляется обратно запрашивающей стороне.
Типичный сценарий использования связи между панорамированием следующий. Инициатор устройства: -
  • Вызывает API StubAPS_AppRegister (), чтобы зарегистрироваться на уровне заглушки APS.
  • Вызывает API StubAPS_SetInterPanChannel () для переключения своего канала связи на канал в использовать удаленное устройство
  • Определяет целевой ID PAN и адрес для сообщения Inter-PAN, которое должно быть передано
  • Вызывает API AF_DataRequest () для отправки сообщения на удаленное устройство через канал Inter-PAN.
  • получает обратно (если требуется) сообщение от удаленного устройства, которое реализует уровень заглушки APS и является способен ответить
  • Вызывает API StubAPS_SetIntraPanChannel (), чтобы переключить свой канал связи обратно на оригинальный канал

18.2.1 Краткое руководство

Настройте приложение как приложение InterPAN. Call StubAPS_RegisterApp( app_endpoint )
Установить канал InterPAN. Call StubAPS_SetInterPanChannel( channel )
Отправить сообщение InterPAN.
Call AF_DataRequest() with:
  • dstPanID different from _NIB.nwkPanId
  • dst address endpoint == STUBAPS_INTER_PAN_EP
Получите сообщение InterPAN.
Получите сообщение OSAL AF_INCOMING_MSG_CMD с
входящий DstEndPoint == STUBAPS_INTER_PAN_EP
Завершите сеанс InterPAN, отложив
канал IntraPAN.
 Call StubAPS_SetIntraPanChannel()

19. Настройка ZMAC LQI

19.1 Обзор

Спецификация IEEE 802.15.4 предоставляет некоторые общие положения по теме LQI. Из раздела 6.7.8: «минимальное и максимальное значения LQI (0x00 и 0xFF) должны быть связаны с самым низким и самым высоким IEEE Сигналы 802.15.4, обнаруживаемые приемником, и значения LQI должны быть равномерно распределены между этими двумя пределы. "Из раздела E.2.3:" LQI (см. 6.7.8) измеряет полученную энергию и / или SNR для каждого полученного пакета. Когда информация об уровне энергии и SNR объединяется, они могут указывать, был ли поврежден пакет от низкого уровня сигнала или от высокого уровня сигнала плюс помехи ".
TI MAC вычисляет 8-битный «индекс качества канала» (LQI) для каждого принятого пакета от радиостанции 2,4 ГГц.
LQI вычисляется из необработанного «индекса мощности принятого сигнала» (RSSI) путем линейного масштабирования его между минимальным
и максимально определенные уровни радиочастот для радио. Это обеспечивает значение LQI, полностью основанное на сила полученного сигнала. Это может вводить в заблуждение в случае узкополосного источника помех, который находится в пределах пропускная способность канала - RSSI может быть увеличен, даже если реальное качество связи снижается.
Радио TI также предоставляют «значение корреляции», которое является мерой качества принятого кадра. Хотя нет рассматриваемый TI MAC в вычислении LQI, корреляция кадра передается на уровень ZMAC (вместе с LQI и RSSI) в данных MCPS подтверждают и обратные вызовы индикации данных. Функция ZMacLqiAdjust () в zmac_cb.c предоставляет возможность настроить значение MAC TI по ​​умолчанию для LQI, принимая во внимание корреляцию.

19.2 Режимы регулировки LQI

Функциональность настройки LQI для принятых кадров, обработанных в zmac_cb.c, имеет три определенных режима работы:
ВЫКЛ, РЕЖИМ1 и РЕЖИМ2. Для обеспечения совместимости с предыдущими версиями Z-Stack, которые не предусматривают при корректировке LQI эта функция по умолчанию выключена, как определено инициализатором (lqiAdjMode = LQI_ADJ_OFF;) в zmac_cb.c - разработчики могут выбрать другое состояние по умолчанию, изменив этот оператор.
MODE1 предоставляет простой алгоритм для использования значения корреляции пакетов (связанного с SNR) для масштабирования входящего LQI
значение (связано с силой сигнала) для «снижения скорости» шумных пакетов. Входящее значение LQI линейно масштабируется с «процент корреляции», который вычисляется из необработанного значения корреляции между теоретическим минимумом / максимумом значения (LQI_CORR_MIN и LQI_CORR_MAX определены в ZMAC.h).
MODE2 предоставляет разработчикам «заглушку» для реализации собственного проприетарного алгоритма. Код можно добавить после оператор else if (lqiAdjMode == LQI_ADJ_MODE2) в ZMacLqiAdjust ().

19.3 Использование настройки LQI

Есть два способа включить функцию настройки LQI:
(1) Измените инициализацию переменной lqiAdjMode, как описано в предыдущем разделе
(2) Скорее всего, вызов функции ZMacLqiAdjustMode () из какого-либо места в приложении Z-Stack из функции инициализации задачи приложения. Подробности смотрите в документе Z-Stack API [1] функция.
Функцию ZMacLqiAdjustMode () можно использовать для изменения режима настройки LQI в соответствии с требованиями заявление. Например, разработчик может захотеть оценить работу устройства / сети с использованием проприетарного MODE2 по сравнению со стандартным MODE1 или OFF.
Настройка режима MODE1 может быть достигнута путем изменения значений LQI_CORR_MIN и / или LQI_CORR_MAX.
При использовании средств разработки IAR, альтернативные значения для этих параметров могут быть предоставлены как директивы компилятора в
файл проекта IDE или один из файлов .cfg Z-Stack (f8wConfig.cfg, f8wCoord.cfg и т. д.). Обратитесь к паспорт радиостанции для получения информации о нормальных минимальных / максимальных значениях корреляции.

20. Управление Heap Memory

20.1 Обзор

Диспетчер динамической памяти OSAL предоставляет POSIX-подобный API для выделения и повторного циклирования динамической динамической памяти.
Два важных соображения в отношении недорогой встроенной системы с ограниченными ресурсами, ее размера и скорости были должным образом
обратился в реализации менеджера кучи памяти.
  • Снижены накладные расходы на память для управления каждым выделенным блоком - всего 2 байта на процессоре с одно- или двухбайтовым доступом к памяти (например, 8051 SOC и MSP430).
  • Задержка прерывания для распределения и свободных операций была сведена к минимуму - освобождение происходит немедленно без вычислительная нагрузка, отличная от проверки границ и небольшого сброса; выделение очень сильно ускорилось с упакованный долгоживущий блок памяти и динамически обновляемый первый свободный указатель для высокочастотного маленького блока распределения (например, таймеры OSAL).

20.2 API

20.2.1 osal_mem_alloc ()

Функция osal_mem_alloc () - это запрос к диспетчеру памяти зарезервировать блок кучи.

20.2.1.1 Прототип

void * osal_mem_alloc (uint16 size);

20.2.1.2 Параметры

size - количество запрошенных байтов динамической памяти.

20.2.1.3 Возврат

Если найден достаточно большой свободный блок, функция возвращает пустой указатель на место в оперативной памяти кучи
зарезервировано для использования. Указатель NULL возвращается, если для выделения недостаточно памяти. Любой ненулевой указатель
возвращенный должен быть освобожден для повторного использования, вызвав osal_mem_free ().

20.2.2 osal_mem_free ()

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

20.2.2.1 Прототип

void osal_mem_free (void *ptr);

20.2.2.2 Параметры

ptr - указатель на буфер для освобождения для повторного использования - этот указатель должен быть указателем, отличным от NULL, который был возвращен предыдущий вызов osal_mem_alloc ().

20.2.2.3 Return

None.

20.3 Стратегия

Управление памятью должно стремиться поддерживать непрерывное свободное пространство в куче, как можно меньше блоков, с каждый блок максимально большой. Такая общая стратегия помогает гарантировать, что запросы на большие блоки памяти всегда успешно, если общий размер кучи был установлен правильно для шаблона использования приложения.
Были реализованы следующие конкретные стратегии:
  • Распределение памяти не наказывается необходимостью обхода долгоживущих выделений кучи, если система инициализация осуществляется в соответствии с рекомендациями данного руководства.
  • Распределение памяти для маленьких блоков почти всегда начинается с поиска первого свободного блока в куче.
  • Распределение памяти пытается объединить все смежные свободные блоки, пройденные в попытке сформировать единый свободный блок достаточно большой для запроса на выделение.
  • Распределение памяти использует первый обнаруженный свободный блок (или созданный путем объединения), который достаточно большой, чтобы удовлетворить просьбу; блок памяти разделяется, если он полезнее, чем запрошенное выделение.

20.4 Обсуждение

Сразу после инициализации системной задачи эффективная метка «начало кучи» устанавливается как первая свободная блок. Поскольку диспетчер памяти всегда начинает «ходить», ища достаточно большой свободный блок, из вышеупомянутая отметка, это значительно уменьшит накладные расходы времени выполнения, если все долгоживущие выделения кучи упакованы в начале кучи, чтобы их не приходилось обходить при каждом выделении памяти. Поэтому любое приложение должно сделать все долгоживущие динамические выделения памяти в своей соответствующей процедуре инициализации системы (например, XXX_Init (), где XXX - имя приложения). В рамках указанных процедур инициализации системы долгоживущий предметы должны быть распределены до любых недолговечных предметов. Любые недолговечные предметы должны быть освобождены до возвращения,
в противном случае долгоживущее ведро может быть фрагментировано, а пропускная способность во время выполнения будет ухудшаться  пропорционально количеству долгоживущих элементов, которые модуль OSAL_Memory вынужден повторять для каждого выделения для остальной части жизни системы. Например, если функция инициализации системы запускает таймер OSAL(osal_start_timerEx ()), это может фрагментировать долгоживущее ведро, потому что память выделена для таймера будут освобождены и повторно использованы в течение всей жизни системы (даже если случится совпадение, что каждое бесплатное и повторное использование просто для сброса того же таймера.) Рекомендуемое решение в этом случае - установить событие, соответствующее к таймеру (osal_set_event ()), а затем продолжить перезапуск таймера, как это необходимо в приложении
дескриптор события для соответствующего события (обратитесь к поведению таймера опроса hal_key и соответствующего событие, HAL_KEY_EVENT). С другой стороны, таймер перезагрузки (osal_start_reload_timer ()) является долгоживущим распределение и рекомендуется запускать во время инициализации системы всех других долгоживущих элементов.
Разработчик приложения должен убедиться, что использование им динамической памяти не оказывает негативного влияния на работу из нижележащих слоев Z-стека. Z-Stack протестирован и квалифицирован с примерами приложений, которые делают минимальное использование кучи памяти. Таким образом, пользовательское приложение, которое использует значительно больше кучи, чем образец приложения или пользовательское приложение, созданное с меньшим значением, установленным для MAXMEMHEAP, чем в примере приложения, могут непреднамеренно истощить нижние слои Z-Stack до такой степени, что они не могут функционировать эффективно или вообще. Например, приложение может выделить столько динамической памяти, что нижележащие слои стека не сможет выделить достаточно памяти для отправки и / или получения любых сообщений OTA - устройство не будет видно, что участие ОТА.

20.5 Конфигурация

20.5.1 MAXMEMHEAP

Константа MAXMEMHEAP обычно определяется в OnBoard.h. Это должно быть определено, чтобы быть меньше чем 32768. 
MAXMEMHEAP - это количество байтов оперативной памяти, которое менеджер памяти зарезервирует для кучи - это не может быть динамически изменяется во время выполнения - он должен быть определен во время компиляции. Если MAXMEMHEAP определено как больше чем или равным 32768, сработает ошибка компилятора в OSAL_Memory.c. MAXMEMHEAP не отражает общее объем динамической памяти, который пользователь может использовать из-за накладных расходов на память распределение.

20.5.2 OSALMEM_PROFILER

Константа OSALMEM_PROFILER определяется локально в OSAL_Memory.c и по умолчанию имеет значение FALSE.
После завершения реализации пользовательского приложения диспетчер памяти OSAL, возможно, придется перенастроить для достижения оптимальной производительности во время выполнения в отношении MAXMEMHEAP и OSALMEM_SMALL_BLKSZ константы определены. Код, включенный путем определения константы OSALMEM_PROFILER, равной TRUE, позволяет пользователю собрать эмпирические результаты во время выполнения, необходимые для настройки менеджера памяти для приложения. Код профилирования делает следующее.

20.5.2.1 OSALMEM_INIT

Константа OSALMEM_INIT определяется локально в OSAL_Memory.c как ascii 'X'.
Инициализация диспетчера памяти устанавливает все байты в куче в значение OSALMEM_INIT.

20.5.2.2 OSALMEM_ALOC

Константа OSALMEM_ALOC определяется локально в OSAL_Memory.c как ascii «A».
Доступные пользователю байты любого выделенного блока устанавливаются в значение OSALMEM_ALOC.

20.5.2.3 OSALMEM_REIN

Константа OSALMEM_REIN определяется локально в OSAL_Memory.c как ascii 'F'.
Всякий раз, когда блок освобождается, для байтов, доступных пользователю, устанавливается значение OSALMEM_REIN.

20.5.2.4 OSALMEM_PROMAX

Константа OSALMEM_PROMAX определена локально в OSAL_Memory.c, чтобы быть 8.
OSALMEM_PROMAX - это число различных размеров сегмента для профиля. Размеры сегмента определяются массивом:
static uint16 proCnt[OSALMEM_PROMAX] = { OSALMEM_SMALL_BLKSZ,
48, 112, 176, 192, 224, 256, 65535 };
Профилированные размеры сегментов должны быть установлены в соответствии с настраиваемым приложением, но всегда должен быть последний сегмент 65535 как всеобъемлющее. Для каждого сегмента хранятся 3 показателя.
  • proCur - текущее количество выделенных блоков, которые соответствуют размеру корзины.
  • proMax - максимальное количество выделенных блоков, которое соответствует размеру корзины одновременно
  • proTot - общее количество выделенных блоков, соответствующее размеру сегмента.
Кроме того, ведется подсчет общего количества раз, когда часть кучи, зарезервированная для «маленьких блоков», была слишком переполнен, чтобы разрешить запрошенное выделение небольших блоков: proSmallBlkMiss.

20.5.3 OSALMEM_MIN_BLKSZ

Константа OSALMEM_MIN_BLKSZ определяется локально в OSAL_Memory.c.
OSALMEM_MIN_BLKSZ - это минимальный размер в байтах блока, который создается путем разделения свободного блока на два новые блоки. 1-й новый блок - это размер, который запрашивается при выделении памяти, и он будет помечен как использовать. 2-й блок имеет любой оставшийся размер, и он будет помечен как свободный. Большее число может привести к значительно ускоряет общее время выполнения приложения, не требуя больше или не намного в целом размер кучи. Например, если приложение сделало очень большое количество смешанных, недолговечных выделений памяти из 2 & 4 байтов каждый, соответствующие блоки будут 4 & 6 байтов каждый с издержками. Диспетчер памяти мог бы потратить много времени, как бы разбивая и объединяя одну и ту же общую область кучи для того, чтобы удовлетворить запросы смешанных размеров.

20.5.4 OSALMEM_SMALL_BLKSZ

Константа OSALMEM_SMALL_BLKSZ определяется локально в OSAL_Memory.c.
Использование памяти кучи Z-Stack было профилировано с использованием образца приложения GenericApp, и оно было эмпирически определили, что наилучшее среднее наихудшее время объединяет время для выделения памяти и освобождения во время интенсивного OTA нагрузки, может быть достигнуто путем разделения свободной кучи на две секции. Первый раздел зарезервирован для распределения блоки меньшего размера, а второй раздел используется для распределения большего размера, а также для меньшего размера ассигнования, если и когда первый раздел заполнен. OSALMEM_SMALL_BLKSZ - это максимальный размер блока в байтах, который можно выделить из первого раздела.

20.5.5 OSALMEM_SMALLBLK_BUCKET

Константа OSALMEM_SMALLBLK_BUCKET определяется локально в OSAL_Memory.c.
OSALMEM_SMALLBLK_BUCKET - это количество байтов, выделенных для ранее описанного первого раздела куча, которая зарезервирована для блоков меньшего размера.

20.5.6 OSALMEM_NODEBUG

Константа OSALMEM_NODEBUG локально определена в OSAL_Memory.c и по умолчанию имеет значение TRUE.
Z-Stack и примеры приложений не используют API динамической памяти. Обязанность быть одинаково правильной лежит на пользовательское приложение: для обеспечения минимально возможной задержки пропускной способности нет никаких проверок времени выполнения для правильное использование API. Можно показать, что приложение корректно, определив константу OSALMEM_NODEBUG в FALSE. Такая настройка активирует код, который перехватывает следующий сценарий неправильного использования.
Вызов osal_mem_alloc () с размером, равным нулю.
Предупреждение: вызов osal_mem_free () с висящим или недействительным указателем не может быть обнаружен.

20.5.7 OSALMEM_PROFILER_LL

Константа OSALMEM_PROFILER_LL определяется локально в OSAL_Memory.c и по умолчанию имеет значение FALSE.
Обычно, распределения, которые упакованы в долгоживущий сегмент всей инициализацией системы, не должны считается во время «профилирования», потому что они не повторяются во время выполнения. Но для того, чтобы правильно настроить размер долгоживущей корзины для любого данного приложения, эта константа должна использоваться для одного запуска на отладчике с зрелая реализация. Числа, использованные в следующем примере, относятся к 8051 SOC, GenericApp, с настройки коробки и, таким образом, с помощью этого по умолчанию:
 
#define OSALMEM_LL_BLKSZ (OSALMEM_ROUND (417) + (19 * OSALMEM_HDRSZ))
 
1. Определите OSALMEM_PROFILER и OSALMEM_PROFILER_LL для TRUE
2. Установите точку останова в osal_mem_kick () после этой операции:
а. ff1 = tmp - 1;
3. Проверьте переменную proCur в окне IAR «Watch» и суммируйте количество всех блоков (19 в этот пример) и включите его в формулу выше - это количество долгоживущих предметов.
4. Вычтите значение ff1 (0x1095 в одном конкретном прогоне) из местоположения кучи (0x0ECE в том же самом выполнить), а затем вычесть промежуточную сумму количества долгоживущих элементов, умноженную на OSALMEM_HDRSZ (19 * 2 = 38 для этого примера.)
 
Дальнейшее профилирование памяти теперь должно быть сделано с OSALMEM_PROFILER_LL, установленным обратно в FALSE, чтобы не
посчитать долгоживущие выделения в статистике.

21. Опции компиляции

21.1 Обзор

Этот раздел содержит информацию и процедуры для использования опций компилятора с Texas Instruments Z-Stack ™, а также рекомендуется не изменять флаги компиляции, которые не перечислены в этом разделе.

21.2 Требования

21.2.1 Требования к целевой системе разработки

Z-Stack построен на основе набора инструментов разработки программного обеспечения IAR Embedded Workbench (www.iar.com). Эти инструменты поддерживают управление проектами, компиляцию, сборку, компоновку, загрузку и отладку для различных платформы разработки. Для поддержки целевой системы разработки Z-Stack требуется следующее:
Platform/Target Compiler/Tool
SmartRF05EB + CC2530 IAR EW8051
SmartRF06EB + CC2538 IAR EWARM

21.3 Использование опций компиляции Z-Stack

21.3.1 Расположение параметров компиляции

Параметры компиляции для конкретного проекта находятся в двух местах. Параметры, которые редко, если вообще изменились, находятся в файлах управления компоновщиком, по одному для каждого типа логического устройства (координатор, маршрутизатор, конечное устройство). Определяемые пользователем параметры и те, которые изменяются для включения / выключения функций, находятся в файле проекта IAR. В демонстрационных целях эти два файлы для проекта координатора GenericApp будут рассмотрены. Доступ ко всем остальным проектам Z-Stack будет аналогичным.

21.3.1.1. Опции компиляции в управляющих файлах компоновщика

Файлы проекта GenericApp находятся в папке ..\Projects\zstack\Samples\GenericApp\(Platform)
 

Рисунок 23: Расположение файлов проекта GenericApp

Откройте проект, дважды щелкнув файл GenericApp.eww, выберите конфигурацию CoordinatorEB из раскрывающийся список ниже рабочей области, а затем откройте папку «Tools». Несколько управляющих файлов компоновщика расположены в папке Tools. Эта папка содержит различные файлы конфигурации и исполняемые инструменты, используемые в проектах Z-Stack. Общие параметры компиляции определены в файле f8wConfig.cfg. Этот файл, например, указывает идентификатор PAN, который будет используется при запуске устройства. Специфичные для устройства параметры компиляции находятся в файле f8wCoord.cfg, Файлы f8wEndev.cfg и f8wRouter.cfg:
 
 
Рисунок 24: Указание каналов в f8wConfig.cfg
 
В проекте GenericApp Coordinator используется файл f8wCoord.cfg. Как показано ниже, параметры компиляции, которые специфичные для устройств координатора, и опции, которые предоставляют «общие» функции Z-Stack, включены в этот файл:
 

Рисунок 25: Настройки координатора в f8wCoord.cfg

Файл f8wCoord.cfg используется всеми проектами, которые создают устройства Coordinator. Поэтому любые изменения, внесенные в этот файл повлияет на всех координаторов. Аналогичным образом файлы f8wRouter.cfg и f8wEnd.cfg влияют на все проекты Router и End-Device соответственно.
Чтобы добавить опцию компиляции во все проекты определенного типа устройства, просто добавьте новую строку в соответствующий компоновщик контрольный файл. Чтобы отключить параметр компиляции, закомментируйте этот параметр, поместив // на левом краю строки. Вы могли бы также удалите строку, но это не рекомендуется, так как опция может потребоваться повторно включить позже.

21.3.1.2. Опции компиляции в файлах проекта IAR

Параметры компиляции для каждой из поддерживаемых конфигураций хранятся в файле GenericApp.ewp. Чтобы изменить эти параметры компиляции, сначала выберите GenericApp - CoordinatorEB. Затем выберите пункт «Options…» в раскрывающемся меню «Project»:

Рисунок 26: Выбор параметров компиляции

Выберите пункт «C/C++ Compiler» и щелкните вкладку «Preprocessor». Параметры компиляции для этой конфигурации
находится в поле «Defined symbols» (по одному на строку):
 
 
Рисунок 27: Включение или отключение параметров
 
Чтобы добавить опцию компиляции в эту конфигурацию, просто добавьте элемент в новую строку в этом поле. Чтобы отключить опцию компиляции, поместите «х» на левом краю строки. Обратите внимание, что опция ZTOOL_P1 была отключена в пример показан выше. Эта опция могла быть удалена, но это не рекомендуется, так как может потребоваться включить позже.

21.3.2. Использование параметров компиляции

Параметры компиляции используются для выбора функций, которые предоставляются в исходных файлах. Большинство параметров компиляции действуют как вкл / выкл переключатели для определенных разделов в исходных программах. Некоторые параметры используются, чтобы обеспечить пользовательский числовой значение, такое как DEFAULT_CHANLIST, компилятору для переопределения значений по умолчанию.
Каждое из примеров приложений Z-Stack (например, GenericApp) предоставляет файл проекта IAR, который определяет компиляцию варианты, которые будут использоваться для этого конкретного проекта. Программист может добавлять или удалять параметры по мере необходимости, чтобы включить или
исключить части доступных функций программного обеспечения. Обратите внимание, что изменение параметров компиляции может потребовать других изменений в файл проекта (см. 21.3.1). Например, добавление опции MT_NWK_FUNC требует наличия MT_NWK.c в списке исходных файлов в конфигурации устройства, которое вы строите.
В следующих разделах этого документа приведены списки поддерживаемых параметров компиляции с кратким описанием того, что функция, которую они включают или отключают. Параметры, которые перечислены как «не меняются» do not change, необходимы для правильной работы скомпилированные программы. Опции, которые указаны как «не использовать» do not use, не подходят для использования с платой.

21.4 Поддерживаемые параметры и определения компиляции

21.4.1. Общие параметры компиляции

Параметры компиляции в следующей таблице могут быть изменены или установлены для выбора нужных функций, многие из которых компилируются
параметры устанавливаются и описываются в f8wConfig.cfg.
APS_DEFAULT_INTERFRAME_DELAY  Задержка между пакетами Tx при использовании фрагментации
APS_DEFAULT_MAXBINDING_TIME 
Максимальное время в секундах, которое координатор будет ожидать между приемом сопоставить запросы привязки дескриптора для выполнения привязки
APS_DEFAULT_WINDOW_SIZE  Размер окна Tx при использовании фрагментации
APS_MAX_GROUPS  Максимальное количество записей, разрешенных в таблице групп
APSC_ACK_WAIT_DURATION_POLLED
Количество 2-миллисекундных периодов, когда конечное устройство опроса будет ожидать APS подтверждение от устройства назначения
APSC_MAX_FRAME_RETRIES 
Максимальное количество попыток (на уровне APS) после передачи отказ
ASSERT_RESET 
Указывает, что устройство должно быть сброшено при подтверждении. Когда нет после того, как произойдет подтверждение, все светодиоды будут мигать.
BEACON_REQUEST_DELAY 
Минимальное количество миллисекунд для задержки между каждым запросом маяка в присоединяющийся цикл
BLINK_LEDS  Включить расширенные функции мигания светодиодов
DEFAULT_CHANLIST  Изменить этот список в f8wConfig.cfg
EXTENDED_JOINING_RANDOM_MASK  Маска для случайной задержки соединения
LCD_SUPPORTED  Включить эмуляцию LCD - текст отправляется на последовательный порт ZTool
MANAGED_SCAN  Включить задержки между сканированиями каналов
MAX_BCAST 
Максимальное количество одновременных трансляций, поддерживаемых устройством на любом данное время
MAX_BINDING_CLUSTER_IDS Максимальное количество идентификаторов кластера в записи привязки
MAX_POLL_FAILURE_RETRIES
Количество попыток опроса родительского элемента перед указанием потери синхронизации с родителем. Обратите внимание, что большее значение приведет к более длительной задержке для ребенка присоединиться к сети
MAX_RREQ_ENTRIES Количество одновременных обнаружений маршрутов в сети
MAX_RTG_ENTRIES 
Количество записей в обычной таблице маршрутизации плюс дополнительные записи для маршрута
ремонт
MAXMEMHEAP
Определяет общий объем памяти, доступной для динамической памяти. Каждый запрос для объема динамической памяти требуется пространство динамической памяти для
накладные расходы, используемые при управлении выделенной памятью. Итак, MAXMEMHEAP не отражает общий объем динамической памяти, которую может ожидать пользователь быть пригодным для использования. Как правило, каждое выделение памяти требует как минимум 2 + N байтов, где N представляет размер блока выравнивания слов цели
CPU (например, N = 1 на AVR и CC2430, но N = 2 на MSP430).
Значение MAXMEMHEAP должно быть меньше 32768
NONWK  Отключить функции NWK, APS и ZDO
NV_INIT  Включить загрузку «базовых» элементов NV при перезагрузке устройства
NV_RESTORE  Позволяет устройству восстанавливать информацию о состоянии сети из NV
NWK_AUTO_POLL  Включить конечное устройство для автоматического опроса родителей
NWK_INDIRECT_MSG_TIMEOUT 
Количество миллисекунд, в течение которых родительское устройство конечного устройства опроса будет хранить
сообщение
NWK_MAX_BINDING_ENTRIES Максимальное количество записей в таблице привязок
NWK_MAX_DATA_RETRIES 
Максимальное количество раз повторных попыток поиска адреса следующего перехода
сообщение
NWK_MAX_DEVICE_LIST  Максимальное количество устройств в списке Ассоциация / Список устройств
NWK_MAX_DEVICES Максимальное количество устройств в сети
NWK_START_DELAY 
Минимальное количество миллисекунд, чтобы задержать запуск устройства в сеть и минимальная задержка между циклами соединения
OSAL_TOTAL_MEM Отслеживать использование кучи памяти OSAL (отображается, если LCD_SUPPORTED)
POLL_RATE
Только для конечных устройств: количество миллисекунд ожидания между запросом данных опросы к родителю. Пример POLL_RATE = 1000 - запрос данных каждый второй. Это изменено в f8wConfig.cfg.
POWER_SAVING Включить функции энергосбережения для устройств с батарейным питанием
QUEUED_POLL_RATE
Используется после получения индикации данных для немедленного опроса в очереди. сообщения (в миллисекундах)
REFLECTOR Включить привязку
REJOIN_POLL_RATE
Это используется в качестве альтернативного опроса частоты ответов только для повторного запроса. Эта скорость определяется временем ответа родителя, которое пытается устройство присоединиться
RESPONSE_POLL_RATE  Используется после получения подтверждения данных для немедленного опроса ответные сообщения (в миллисекундах)
ROUTE_EXPIRY_TIME
Количество секунд до истечения срока действия записи в таблице маршрутизации; установить от 0 до
отключить истечение маршрута
RTR_NWK Включить сеть маршрутизатора
SECURE  Включить безопасность ZigBee (SECURE = 0 для отключения, SECURE = 1 для включения)
ZAPP_Px  Включить сообщения ZApp через последовательный порт Px, где x - это порт (1 или 2)
ZDAPP_CONFIG_PAN_ID 
PAN ID координатора; используется маршрутизаторами и конечными устройствами для подключения к PAN с этот идентификатор
ZDO_COORDINATOR  Включить устройство в качестве координатора
ZIGBEEPRO  Включить использование функций ZigBee Pro
ZTOOL_Px 
Включить сообщения ZTool через последовательный порт Px, где x - это порт (1 или 2)
OSC32K_CRYSTAL_INSTALLED
Этот флаг компиляции определяет, использовать ли внутренний 32 кГц RC OSC (если установлен на false) или внешний кристалл 32 кГц при установке на борту.
Важное примечание: если этот флаг компиляции не определен, ПО выбирает Внешняя конфигурация OSC 32 кГц по умолчанию (так как 253x EM имеют внешние 32 кГц заселены). Если ваш дизайн не имеет внешнего 32 кГц
на борту, пожалуйста, убедитесь, что вы установили OSC32K_CRYSTAL_INSTALLED = FALSE в настройках проекта вашего компилятора.
 

21.4.2. Неизменяемые параметры компиляции

Эти параметры компиляции в следующей таблице не должны быть изменены или использованы. Не все из них доступны в каждом Платформа:
CPU32MHZ  Тактовая частота процессора - 32 МГц (не меняется)
MACSIM Включить симуляцию MAC (не использовать)
NWK_TEST  Включить функции проверки сети (не использовать)

21.4.3 Опции компиляции Monitor-Test (MT)

Пожалуйста, прочитайте документ Z-Stack Monitor и Test API, прежде чем изменять какие-либо из этих параметров компиляции. Вы можете
включите следующие API и функции, связанные с опцией MT_TASK, но вы должны включить MT_TASK вариант.
 
MT_TASK Включить задачу Monitor-Test
MT_AF_FUNC Включить Monitor-Test для обработки команд AF, отправленных из ZTool или ZTrace
MT_AF_CB_FUNC  Включить Monitor-Test для обработки обратных вызовов AF, зарегистрированных ZTool или ZTrace
MT_APP_FUNC  Включить Monitor-Test для обработки команд APP, отправленных из ZTool или ZTrace
MT_DEBUG_FUNC Включить Monitor-Test для обработки команд DEBUG, выданных из ZTool или ZTrace
MT_MAC_FUNC Включить Monitor-Test для обработки MAC-команд, отправленных из ZTool или ZTrace
MT_NWK_FUNC Включить Monitor-Test для обработки команд NWK, отправленных из ZTool или ZTrace
MT_NWK_CB_FUNC  Включить проверку монитора для обработки обратных вызовов NWK, зарегистрированных ZTool или ZTrace
MT_SAPI_FUNC Включить мониторинг-тестовую обработку команд SAPI, отправленных из ZTool или ZTrace
MT_SAPI_CB_FUNC Включить проверку монитора для обработки обратных вызовов SAPI, зарегистрированных в ZTool или ZTrace
MT_SYS_FUNC  Включить Monitor-Test для обработки команд SYS, отправленных из ZTool или ZTrace
MT_SYS_OSAL_NV_READ_CERTIFICATE_DATA
Значение по умолчанию для FALSE в MT_SYS.c и применимо, только если ZCL_KEY_ESTABLISH
определены. Если ZCL_KEY_ESTABLISH определен и
MT_SYS_OSAL_NV_READ_CERTIFICATE_DATA определяется как TRUE, затем три Элементы NV, содержащие данные сертификата Certicom, можно прочитать через MT:
ZCD_NV_IMPLICIT_CERTIFICATE 0x0069
ZCD_NV_DEVICE_PRIVATE_KEY 0x006A
ZCD_NV_CA_PUBLIC_KEY 0x006B
В противном случае данные сертификата не могут быть прочитаны через MT.
MT_UTIL_FUNC Включить Monitor-Test для обработки команд UTIL, отправленных из ZTool или ZTrace
MT_ZDO_CB_FUNC  Включить тестовую проверку монитора команд ZDO, выданных из ZTool или ZTrace
MT_ZDO_FUNC  Включить мониторинг-тестовую обработку команд ZDO, отправленных из ZTool или ZTrace
MT_ZDO_MGMT  Включить проверку монитора-тестирования команд ZDO MGMT из ZTool или ZTrace
MT_APP_CNF_FUNC  Включить проверку Monitor-Test интерфейса API BDB из ZTool
MT_GP_CB_FUNC Включить Monitor-Test обработку интерфейса API GP из ZTool

21.4.4. Опции компиляции ZigBee Device Object (ZDO)

По умолчанию обязательные сообщения (как определено спецификацией ZigBee и BDB) включены в ZDO. Для обзора обязательные сообщения, разрешенные BDB, ссылаются на ZDConfig.h. Вся остальная обработка сообщений контролируется флаги компиляции. Вы можете включить / отключить параметры, комментируя / отменяя комментирование флагов компиляции в ZDConfig.h или включите / исключите их, как и другие флаги компиляции. Есть простой способ включить все ZDO функции и параметры управления: Вы можете использовать MT_ZDO_FUNC, чтобы включить все параметры функции ZDO, и MT_ZDO_FUNC и MT_ZDO_MGMT, чтобы включить все функции ZDO плюс опции управления. Информация о использовании этих сообщений приведено в данном руководстве и в документе API Z-Stack.
 
ZDO_NWKADDR_REQUEST  Включить функцию запроса сетевого адреса и обработку ответа
ZDO_IEEEADDR_REQUEST  Включить функцию запроса адреса IEEE и обработку ответа
ZDO_MATCH_REQUEST  Включить функцию запроса дескриптора совпадения и обработку ответа
ZDO_NODEDESC_REQUEST  Включить функцию запроса дескриптора узла и обработку ответа
ZDO_POWERDESC_REQUEST Включить функцию запроса дескриптора мощности и обработку ответа
ZDO_SIMPLEDESC_REQUEST  Включить функцию простого запроса дескриптора и обработку ответа
ZDO_ACTIVEEP_REQUEST  Включить функцию Active Endpoint Request и обработку ответа
ZDO_COMPLEXDESC_REQUEST  Включить функцию сложного дескриптора запроса и обработку ответа
ZDO_USERDESC_REQUEST  Включить функцию запроса дескриптора пользователя и обработку ответа
ZDO_USERDESCSET_REQUEST  Включить функцию запроса набора дескрипторов пользователя и обработку ответа
ZDO_ENDDEVICEBIND_REQUEST  Включить функцию запроса привязки конечного устройства и обработку ответа
ZDO_BIND_UNBIND_REQUEST  Включить функцию Bind and Unbind Request и обработку ответа
ZDO_SERVERDISC_REQUEST  Включить функцию запроса на обнаружение сервера и обработку ответа
ZDO_MGMT_NWKDISC_REQUEST  Включить функцию запроса на обнаружение Ngk Mgmt и обработку ответа
ZDO_MGMT_LQI_REQUEST  Включить функцию MgQt LQI Request и обработку ответа
ZDO_MGMT_RTG_REQUEST  Включить функцию запроса таблицы маршрутизации Mgmt и обработку ответа
ZDO_MGMT_BIND_REQUEST  Включить функцию запроса таблицы привязок Mgmt и обработку ответа
ZDO_MGMT_LEAVE_REQUEST  Включить функцию MgMT Leave Request и обработку ответа
ZDO_MGMT_JOINDIRECT_REQUEST  Включить функцию прямого запроса Mgmt Join и обработку ответа
ZDO_MGMT_PERMIT_JOIN_REQUEST Включение устройства для ответа на функцию MgMT Permit Join Request
ZDO_USERDESC_RESPONSE  Включить устройство для ответа на функцию запроса дескриптора пользователя
ZDO_USERDESCSET_RESPONSE  Включение устройства для ответа на функцию запроса установки дескриптора пользователя
ZDO_SERVERDISC_RESPONSE  Включить устройство для ответа на функцию запроса на обнаружение сервера
ZDO_MGMT_NWKDISC_RESPONSE  Включить устройство для ответа на функцию запроса сетевого обнаружения Mgmt
ZDO_MGMT_LQI_RESPONSE  Разрешить устройству отвечать на функцию MgMt LQI Request
ZDO_MGMT_RTG_RESPONSE Включить устройство для ответа на функцию запроса таблицы маршрутизации Mgmt
ZDO_MGMT_BIND_RESPONSE  Включить устройство для ответа на функцию запроса таблицы привязок Mgmt
ZDO_MGMT_LEAVE_RESPONSE Включить устройство для ответа на функцию Mgmt Leave Request
ZDO_MGMT_JOINDIRECT_RESPONSE Включить устройство для ответа на функцию прямого запроса Mgmt Join
ZDO_MGMT_PERMIT_JOIN_RESPONSE  Разрешить устройству отвечать на функцию запроса разрешения Mgmt
ZDO_ENDDEVICE_ANNCE Разрешить устройству реагировать на функцию сообщения об окончании устройства
ZDO_NV_SAVE_RFDs  Значение по умолчанию равно TRUE в ZDApp.c и применимо, только если определено NV_RESTORE. Если NV_RESTORE определен, а ZDO_NV_SAVE_RFDs определен как FALSE, тогда соединения RFD будут не инициировать вызов NLME_UpdateNV () и время задержки между получением события триггера и фактически вызов NLME_UpdateNV () расширен до максимального значения таймера OSAL 65 секунд (см. ZDAPP_UPDATE_NWK_NV_TIME). Эта опция компиляции предназначена для значительного расширения жизнь NV страниц RFD в сети с мобильными или очищенными RFD. Когда этот флаг Если задано значение FALSE, все дочерние элементы RFD, которые существуют во время сброса FFD, не будут восстановлены и FFD может повторно выдать свои сетевые адреса другим присоединяющимся RFD.
 ZDAPP_UPDATE_NWK_NV_TIME
Значение по умолчанию равно 700 мсек и применимо, только если определено NV_RESTORE. Время задержки
между получением события запуска состояния сохранения сети и фактическим вызовом NLME_UpdateNV ().
Чем дольше эта задержка, тем дольше срок службы страниц NV, так как эти данные очень велики и заняты в сети (особенно с мобильными RFD) частота событий запуска может быть высокой.
 

 

Ваша оценка: None Средняя: 10 (12 votes)