BLE под микроскоп (ATTы GATTы…)

BLE под микроскоп (ATTы GATTы…)

Дел 1, преглед

Веќе помина доста време откако беше објавена првата спецификација за Bluetooth 4.0. И, иако темата BLE е многу интересна, таа сепак одложува многу програмери поради нејзината сложеност. Во моите претходни написи, главно гледав на најниското ниво, Слој за врски и Физички слој. Ова ни овозможи да избегнеме да прибегнуваме кон такви сложени и збунувачки концепти како што се протоколот за атрибути (ATT) и профилот на општ атрибут (GATT). Сепак, нема каде да се оди, без да ги разбереме, невозможно е да се развијат компатибилни уреди. Денес би сакал да го споделам ова знаење со вас. Во мојата статија ќе се потпирам на тетратка за почетници од нордиската веб-страница. Па ајде да започнеме.

Зошто с everything е толку тешко?

Според мое мислење, веднаш беше јасно дека управувањето со уреди преку паметни телефони е многу ветувачка и долготрајна тема. Затоа решиле веднаш и максимално да го структурираат. За производителите на различни гаџети да не смислуваат свои протоколи, кои потоа ќе бидат некомпатибилни. Оттука и тешкотијата. Веќе во првата фаза, тие се обидоа да стиснат сè што е можно во протоколот BLE. И не е важно дали ќе биде корисно подоцна или не. Дополнително, тие предвидоа можност за проширување на листата на уреди за во иднина.

Ајде да ја погледнеме сликата каде што е нацртан дијаграмот на протоколот BLE. Се состои од неколку слоеви. Најнискиот физички слој (PHY) е одговорен за радио каналот на уредот. Слој за врски (LL) ја содржи целата низа бајти во пренесената порака. Во претходните статии го проучувавме токму ова. Интерфејсот на контролорот на домаќинот (HCI) е протокол за размена помеѓу слоевите или чиповите BLE ако контролорот и домаќинот се имплементирани на различни чипови. Протоколот за контрола и адаптација на логичка врска (L2CAP) е одговорен за формирање на пакети, кадрирање, контрола на грешки и склопување пакети. Протоколот за управување со безбедност (SMP) е одговорен за шифрирање на пакети. Општиот профил за пристап (GAP) е одговорен за првичната размена на податоци помеѓу уредите за да се одреди „Кој е кој“. Вклучува и скенирање и рекламирање. Во оваа статија ќе се фокусирам на двата преостанати дела од протоколот - ГАТТ и АТТ. ГАТТ е надградба на АТТ, така што тие се тесно испреплетени.

За да ја поедноставам приказната, би сакал да се осврнам на аналогија. Го слушнав некаде и би сакал да го поддржам. Замислете го уредот BLE како полица за книги со неколку полици. Секоја полица е посебна тема. На пример, имаме полици со научна фантастика, математика и енциклопедии. На секоја полица има книги со одредена тема. А некои книги имаат дури и хартиени обележувачи со белешки. Дополнително, имаме мал хартиен каталог од сите книги. Ако се сеќавате, училишните библиотеки се тесна кутија со хартиени картички. Со оваа аналогија, кабинетот е профилот на нашиот уред. Полиците се услуги, книгите се карактеристики, а каталогот е табела со атрибути. Обележувачите во книгите се дескриптори, за кои исто така ќе зборувам подоцна подетално.

Секој кој има развиено уреди знае дека многу проекти имаат слични парчиња код. Факт е дека многу уреди имаат слична функционалност. На пример, ако уредите се напојуваат со батерии, тогаш проблемот со полнење и следење на нивното ниво ќе биде ист. Истото важи и за сензорите. Всушност, објектно-ориентиран пристап кон програмирањето „Обезбедува способност да се создадат објекти кои комбинираат својства и однесувања во самостојна унија што потоа може повторно да се користи“. Според мое мислење, BLE се обиде со сличен пристап. Профилите беа развиени од страна на Bluetooth Special Interest Group (SIG). Уредите од различни производители кои имаат исти профили треба да работат едни со други без тешкотии. Профилите, пак, се состојат од услуги и услуги на карактеристики, дополнети со дескриптори. Во принцип, може да изгледа вака:

На пример, разгледајте го дијаграмот на профилот на мониторот за отчукувањата на срцето (фитнес нараквица). Се состои од две услуги и неколку карактеристики. Од него хиерархијата на профилот веднаш станува јасна. Карактеристиката на контролната точка го ресетира вкупниот број на трошење калории на нула.

1. Услугата за отчукувањата на срцето вклучува три карактеристики (0x180D):
    а) Задолжителна карактеристика на срцевиот ритам (0x2A37)
    б) Изборна карактеристика на положбата на сензорот на телото (0x2A38)
    в) Условни карактеристики на контролната точка на срцевиот ритам (0x2A39)
2. Сервис за одржување на батеријата (0x180F):
    а) Карактеристика на задолжително ниво на полнење на батеријата (0x2A19)

УУИД

За да имаме единствен пристап до елементите на профилот (услуги, карактеристики и дескриптори), треба некако да ги нумерираме сите. За таа цел се воведува концепт како што е универзално единствен идентификатор (UUID) или универзално единствен идентификатор. UUID е означен во заградите на секоја линија. И тука има една особеност. За UUID, решивме да користиме код од 16 и 128 бита во должина. Зошто прашуваш? Во протоколот BLE, сè е за зачувување на енергијата. Затоа, димензијата од 16 бита е сосема разумна. Малку е веројатно дека во блиска иднина ќе бидат создадени повеќе од 65 илјади. уникатни услуги и карактеристики. Во моментов, сè што можеше да биде веќе изброено (сетете се од каде ова - „и тој ве изброи“ :-)) Нумерирани елементи профили, услуги, карактеристики и дескриптори можете да ги погледнете линковите.

Сепак, мислам дека сите се сеќаваат на приказната со 4 бајти IP адреси на Интернет. Отпрвин мислевме дека е доволно, но сега сè уште не можеме да се префрлиме на адреса од 6 бајти. За да не се повтори оваа грешка и да не им се даде слобода на разиграните раце на оние кои сами си го прават, SIG веднаш реши да воведе 128-битни UUID. Ова лично ме потсетува на нелиценцираниот опсег од 433 MHz, кој беше даден на секакви Кулибини од радио каналот. Во нашиот случај, беше создаден 128-битен идентификатор на услуги и карактеристики. Ова значи дека ние, за нашите услуги и уреди, можеме да користиме речиси секоја 128-битна вредност. Сеедно, веројатноста да се дојде до истиот UUID се стреми кон нула.

Всушност, кратките 16-битни UUID имаат свое проширување до 128-битна вредност. Во спецификацијата, оваа екстензија се нарекува Bluetooth Base UUID и има вредност 00000000-0000-1000-8000-00805F9B34FB. Ако, на пример, 16-битниот атрибут UUID има вредност 0x1234, тогаш еквивалентниот 128-битен UUID ќе ја има вредноста 00001234-0000-1000-8000-00805F9B34FB. Па дури и соодветната формула е дадена:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Не знам од каде дојде овој магичен број. Ако некој од читателите знае нека пише во коментар (Корисник со прекар Sinopteek веќе го има направено ова. Погледнете ги коментарите). Што се однесува до доаѓањето до 128-битни UUID, во принцип можете да користите специјален од генераторкој ќе го направи тоа за тебе.

ATTy GATTy...

Всушност, тогаш започнува забавата. Дозволете ми да ве потсетам дека ATT се заснова на однос клиент-сервер. Сега го разгледуваме серверот. Содржи информации како што се вредностите на сензорот, статусот на прекинувачот за светло, податоци за локацијата итн. Сега, кога сите „учесници во нашата парада“ се нумерирани, треба некако да ги ставиме во меморијата на уредот. За да го направите ова, ги ставаме во табела наречена табела за атрибути. Запомнете го ова добро. Ова е самото срце на BLE. Ова е она што ќе го разгледаме понатаму. Сега секоја линија ќе ја наречеме атрибут. Оваа табела се наоѓа длабоко во магацинот и, по правило, немаме директен пристап до неа. Ние го иницијализираме и пристапуваме до него, но она што се случува внатре е скриено од нас зад седум печати.

Да ја погледнеме сликата од спецификацијата, но пред тоа би сакал веднаш да привлечам внимание на честата конфузија во термините, имено во дескрипторите. Улогата на дескрипторот е да го надополни описот на карактеристиката. Кога е неопходно да се прошират неговите можности, тогаш се користат дескриптори. Тие се исто така атрибути, и исто како и услугите и карактеристиките, тие се наоѓаат во табелата со атрибути. Детално ќе ги испитаме во вториот дел од статијата. Меѓутоа, понекогаш дескрипторите се однесуваат на бројот на редот во табелата со атрибути. Ова мора да се има на ум. За да избегнеме забуна, ќе го користиме терминот „покажувач на атрибути“ за овие цели.


Значи, атрибутот е дискретна вредност што ги има следните својства поврзани со него:
1. Рачка за атрибути е индекс на табелата што одговара на атрибутот
2. Тип на атрибут е UUID што го опишува неговиот тип
3. Вредност на атрибутот е податокот индексиран од покажувачот на атрибутот
4. Дозволи за атрибути се дел од атрибутот, дозволите, кои не можат да се читаат или напишат со помош на протоколот за атрибути

Како да се разбере сето ова? Покажувачот на атрибутот е, релативно кажано, неговиот број во нашата табела.
Тоа му овозможува на клиентот да упатува на атрибут во барањата за читање или пишување. Можеме да ги нумерираме нашите линии (атрибути) од 0x0001 до 0xFFFF. Во нашата поврзаност со полица за книги, ова е бројот на картичката во каталогот за хартија. Слично на тоа, како и во каталогот на библиотеката, картичките се подредени по зголемен број. Бројот на секоја следна линија мора да биде поголем од претходниот. Исто како во библиотеката, понекогаш некои картички се губат, така што кај нас може да има празнини во нумерирањето на линиите. Ова е дозволено. Главната работа е дека тие одат прогресивно.

Типот на атрибутот одредува што претставува атрибутот. По аналогија со јазикот Ц,
каде што има булови, нумерички променливи и низи, така е тука. По тип на атрибут препознаваме
со што се занимаваме и како можеме да продолжиме да работиме со овој атрибут. Подолу ќе разгледаме некои специфични типови на атрибути. На пример, „декларација за услуга“ (0x2800), „карактеристична декларација“ (0x2803), „декларација за дескриптор“ (0x2902).

Вредноста на атрибутот е неговото вистинско значење, простете на тавтологијата. Ако типот на атрибут е низа, тогаш вредноста на атрибутот може да биде, на пример, слоганот „Здраво свет !!!“. Ако типот на атрибут е „декларација за услуга“, тогаш неговата вредност е самата услуга. И понекогаш ова е информација за тоа каде да се најдат други атрибути и нивните својства.

Дозволите за атрибути му дозволуваат на серверот да разбере дали е дозволен пристап за читање или пишување.
Забележете дека овие дозволи се однесуваат само на вредноста на атрибутот, а не и на самото поле за покажувач, тип или дозвола. Оние. ако е дозволено снимање на атрибути, тогаш можеме да ја промениме, на пример, линијата „Здраво свет !!!“ до редот „Добро утро“. Но, не можеме да забраниме пишување нова линија или да го промениме типот на атрибутот и да ја означиме линијата како „декларација за услуга“. Кога клиентот контактира со сервер, клиентот ги бара неговите атрибути. Ова му овозможува на клиентот да знае што може да обезбеди серверот. Иако не е неопходно да се читаат и пишуваат вредностите.

Како изгледа

Концептот на ГАТТ е да се групираат атрибутите во табелата со атрибути заедно по многу специфичен и логичен редослед. Ајде внимателно да го разгледаме профилот на срцевиот ритам подолу. Најлевата колона од оваа табела е изборна. Тоа едноставно ни опишува што е оваа линија (атрибут). Сите други колумни ни се веќе познати.

На врвот на секоја група секогаш имаме атрибут за декларација на услуга. Неговиот тип е секогаш 0x2800, а покажувачот зависи од тоа колку атрибути се веќе присутни во табелата. Неговите дозволи се секогаш само за читање, без никаква автентикација или овластување. Ќе зборуваме за овие концепти малку подоцна. Вредноста е уште еден UUID што идентификува што е услугата. Во табелата, вредноста е 0x180D, што е дефинирано од Bluetooth SIG како услуга за отчукувањата на срцето.

По објавувањето на услугата, доаѓа и објавувањето на карактеристиката. Таа е слична во форма на декларација за услуга. Неговиот UUID е секогаш 0x2803, а неговите дозволи секогаш се само за читање без никаква автентикација или овластување. Да го погледнеме полето Вредност на атрибути, кое вклучува некои податоци. Секогаш содржи покажувач, UUID и збир на својства. Овие три елементи ја опишуваат последователната декларација на карактеристичната вредност. Покажувачот природно ја означува локацијата на декларацијата на карактеристичната вредност во табелата со атрибути. UUID опишува каков тип на информации или вредност можеме да очекуваме. На пример, вредноста на температурата, состојбата на прекинувачот за светло или некоја друга произволна вредност. И конечно својства, кои опишуваат како може да се интеракција со карактеристичната вредност.

Овде не чека уште една замка. Тој е поврзан со дозволи за атрибути и карактеристични својства. Ајде да ја погледнеме сликата на својствата на битното поле од спецификацијата.

Како што можете да видите, тука има и полиња кои обезбедуваат можности за читање и пишување. Можеби се прашувате зошто имаме дозволи за читање/пишување за атрибут и својство
чита/пишува за карактеристична вредност? Зарем не треба секогаш да бидат исти? Факт е дека својствата за карактеристичната вредност се всушност само препораки за клиентот што се користат во ГАТТ и во апликативните слоеви. Ова се само совети за тоа што клиентот може да очекува од карактеристичниот атрибут за декларација. Ајде да го разгледаме ова подетално. Какви видови дозволи има атрибутот?

1. Дозволи за пристап:
     - читање
     - рекорд
     - чита и пишува
2. Дозвола за автентикација:
     - потребна е автентикација
     - не е потребна автентикација
3. Дозвола за овластување:
     — потребно е овластување
     - не е потребно овластување

Главната разлика помеѓу резолуцијата на атрибутите и карактеристичните својства е тоа што првите се однесуваат на серверите, а вторите за клиентите. На серверот може да му биде дозволено да ја чита карактеристичната вредност, но може да бара автентикација или авторизација. Затоа, кога клиентот ќе ги побара својствата на карактеристиката, ќе добиеме дека читањето е дозволено. Но, кога се обидуваме да читаме, добиваме грешка. Затоа, можеме безбедно да зборуваме за приоритетот на дозволите пред својствата. На страната на клиентот, не можеме да добиеме знаење за тоа какви дозволи има атрибутот.

Описувач

Да се ​​вратиме на нашата маса. По декларирањето на вредноста на карактеристиката, можни се следните декларации на атрибути:
1. Нова декларација на карактеристики (услугата може да има многу карактеристики)
2. Декларација за нова услуга (може да има многу од нив во табелата)
3. Декларирање рачка

Во случај на карактеристика на мерење на срцевиот ритам, во нашата табела, декларацијата на карактеристичната вредност е придружена со декларација на дескрипторот. Описувач е атрибут со дополнителни информации за карактеристика. Постојат неколку видови дескриптори. Ние ќе зборуваме за нив детално во вториот дел од оваа статија. Засега, ќе го допреме само Описникот за конфигурација на карактеристики на клиентот (CCCD). Има UUID еднаков на 0x2902. Користејќи го овој дескриптор, клиентот има можност да овозможи индикација или известување на серверот. Разликата меѓу нив е мала, но сепак постои. Известувањето не бара потврда за прием од клиентот. Индикацијата го бара ова, иако се јавува на ниво на ГАТТ, не достигнувајќи го нивото на апликација. Зошто така, прашуваш? За жал, јас не го знам ова. Само да кажам дека нордиските експерти препорачуваат користење известувања. Покрај тоа, проверка на интегритетот на пакетот (со користење на CRC) се случува и во двата случаи.

Заклучок

На крајот од статијата би сакал да го кажам ова. Последната табела е малку збунувачка. Сепак, го избрав затоа што е дадено Член, на кој се потпирам. Во вториот дел од мојата статија, имам намера да навлезам подлабоко во спецификацијата BlueTooth 4.0. Таму не очекуваат поточни дијаграми и цртежи. Во третиот дел, би сакал да го анализирам дневникот добиен со помош на програмата Wireshark од еден од гаџетите и да ја видам „во живо“ целата теорија што ја проучуваме.

Вработен во Групацијата на компании „Сателитот Цезар“
Печерских Владимир

Извор: www.habr.com