BLE all mikroskoobi all (ATTid GATTid…)

BLE mikroskoobi all (ATT-d ja GATT-d…)

Osa 1, ülevaade

On möödunud juba piisavalt aega, mil ilmus esimene Bluetooth 4.0 spetsifikatsioon. Kuigi BLE teema on väga huvitav, pelgavad paljud arendajad seda veel oma keerukuse tõttu. Minu eelnevates artiklites olen arutanud enamasti linkkihistiku ja füüsikalise kihistiku kõige madalamat taset. See võimaldas mul mitte puutuda kokku nii keeruliste ja segaste mõistetega nagu atribuudiprotokoll (ATT) ja üldine atribuudiprofiil (GATT). Siiski ei pääse neist, nende mõistmata ei ole võimalik koostalitlusvõimelisi seadmeid arendada. Täna soovin jagada teiega neid teadmisi. Artiklis tuginen õpetust Nordic-i algajate juhendile. Nii et alustame.

Miks on kõik nii keeruline?

Minu arvates oli kohe selge, et seadmete haldamine nutitelefonide kaudu on väga perspektiivikas ja pikaajaline teema. Seetõttu otsustati see struktuuri läbi mõelda ja maksimaalselt ellu viia. Et erinevate vidinate tootjad ei leiutaks oma protokolle, mis hiljem võivad olla ühilduvad. Sealt ka keerukus. Juba esimesel etapil püüti BLE protokolli suruda kõik, mis vähegi võimalik. Ja pole tähtis, kas see hiljem tuleb kasuks või mitte. Lisaks arvati tulevikus seadmete loendi laiendamise võimalust.

Vaadakem pilti, kus on kujutatud BLE protokolli skeem. See koosneb mitmest kihist. Kõige alumine, füüsiline kiht (PHY) vastutab seadme raadiosignaali eest. Link Layer (LL) sisaldab kõiki bite järjestusi edastatavas sõnumis. Eelnevates artiklites oleme just seda uurinud. Host Controller Interface (HCI) on protokoll vahetamiseks kihtide või BLE kiipide vahel, kui Controller ja Host on erinevates kiipides. Pakettide koostamise, konverteerimise raamideks, vigade kontrollimise ja pakettide kogumise eest vastutab Logical Link Control and Adaptation Protocol (L2CAP). Pakettide krüpteerimise eest vastutab Security Manager Protocol (SMP). Üksuse käitusprofiil (GAP) vastutab andmete esialgse vahetuse eest seadmete vahel, et määrata, kes on kes. Selle alla kuuluvad samuti skaneerimine ja reklaamimine. Selles artiklis peatun protokolli kahel ülejäänud osal — GATT ja ATT. GATT on ATT üleehitus, seega on nad tihedalt seotud.

Kergendamiseks tooksin ma kasutusele analoogia. Olen seda kusagil kuulnud ja tahaksin seda toetada. Kujutage ette BLE-seadet kui raamaturiiulit, kus on mitmeid riiuleid. Iga riiul esindab erinevat teemat. Näiteks on meil riiulid ulme, matemaatika ja entsüklopeediate jaoks. Igal riiulil on teemaga seotud raamatud. Mõnedes raamatutes on isegi paberist järjehoidjad märkmete jaoks. Lisaks on meil väike paberikataloog kõigist raamatutest. Kui mäletate kooli raamatukogasid — see on kitsas kapp paberkaartidega. Sellise analoogia järgi on kapp meie seadme profiil. Riiulid on teenused, raamatud on omadused ja kataloog on atribuutide tabel. Raamatute järjehoidjad on deskriptorid, millest ma räägin hiljem üksikasjalikumalt.

Iga, kes on seadmeid arendanud, teab, et paljudes projektides on sarnased kooditükid. Probleem on selles, et paljudel seadmetel on sarnane funktsionaalsus. Näiteks, kui seadmed töötavad aku toel, on laadimise ja taseme kontrollimise probleem sama. See kehtib ka sensorite kohta. Tegelikult on objekti-orienteeritud lähenemine programmeerimisel. "annab võimaluse luua objekte, mis ühendavad omadused ja käitumise iseseisvaks liiduks, mida saab seejärel korduvalt kasutada".. Minu arvates tehti BLE-s sarnase lähenemise katse. Bluetoothi Erifookusgrupi (SIG) poolt töötati välja profiilid. Erinevatelt tootjatelt olevad seadmed, millel on samad profiilid, peaksid omavahel hõlpsasti sobima. Profiilid koosnevad omakorda teenustest ja teenused omadustest, mida täiendavad kirjeldajad. Üldiselt võib see välja näha nii:

Näiteks vaatame südame löögisageduse monitori (fitness-rannekell) profiiliga seotud skeemi. See koosneb kahest teenusest ja mitmest omadusest. Selgelt on näha profiili hierarhia. Kontrollpunkti omadus nullib üldise kalorite arvestuse.

1. Südame löögisageduse teenus sisaldab kolme omadust (0x180D):
    a) Kohustuslik löögisageduse omadus (0х2A37)
    b) Valikuline kehaanduri asendi omadus (0x2A38)
    c) Tingimuslik südame löögisageduse kontrollpunkti omadus (0x2A39)
2. Aku teenus (0x180F):
    a) Kohustuslik aku laadimistaseme omadus (0x2A19)

UUID

Kuna me saaksime ühemõtteliselt viidata profiilielementidele (teenustele, omadustele ja deskriptoritele), tuleb need kõik korralikult nummerdada. Selle eesmärgi saavutamiseks tutvustatakse mõistet Universally Unique ID (UUID) ehk Üldiselt Unikaalne Identifikaator. Iga rea sulgudes ongi näidatud UUID. Siin on üks eripära. UUID jaoks otsustati kasutada 16- ja 128-bitist koodi. Miks, küsiksite? BLE protokollis on kõik suunatud energia säästmisele. Seetõttu on 16-bitisus täiesti mõistlik. Ebatõenäoline, et lähitulevikus luuakse üle 65 tuhande unikaalse teenuse ja omaduse. Praeguseks on kõik arvestatud, mis suudeti (kas mäletate, kust see on — „ta arvutas ka teid“ :-)) Numereeritud elemendid. profiilide, teenuste, omaduste ja deskriptorite võite vaadata linkide kaudu.

Kuid ma arvan, et kõik mäletavad lugu neljast baitist IP-aadressist internetis. Algul arvati, et see on piisav, aga nüüd ei suudeta kuidagi üle minna kuue baitise aadressile. Et vältida sama vea kordamist ja anda võimalus käsitööliste näppudele, otsustas SIG kohe tutvustada ka 128-bitiseid UUID-sid. See meenutab mulle isiklikult litsentseerimata 433 MHz sagedust, mis anti igasugustele kätetöölistele raadioala valdusesse. Meie puhul on antud 128-bitine identifikaator teenuste ja omaduste jaoks. See tähendab, et saame oma teenuste ja seadmete jaoks kasutada praktiliselt ükskõik millist 128-bitist väärtust. Looduslikult kipub sama UUID loomise tõenäosus olema nulli lähedane.

Tegelikult on lühikesed 16-bitised UUID-d oma laienduseks 128-bitistele väärtustele. Spetsifikatsioonis nimetatakse seda laiendust Bluetooth Base UUID ja selle väärtus on 00000000-0000-1000-8000-00805F9B34FB. Näiteks kui 16-bitise attribuudi UUID väärtus on 0x1234, siis vastav 128-bitine UUID väärtus on 00001234-0000-1000-8000-00805F9B34FB. Ja isegi antakse vastav valem:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

Kust see maagiline number pärineb, ei oska ma öelda. Kui keegi lugejatest teab, siis palun kirjutage kommentaaridesse (kasutaja nimega Sinopteek on seda juba teinud. Vaadake kommentaare). Mis puutub 128-bitiste UUID-de genereerimisse, siis põhimõtteliselt võib kasutada spetsiaalset generaatorit, mis teeb selle teie eest valmis.

ATT-d GATT-d…

Edasi hakkab tõeliselt huvitav osa. Tuletan meelde, et ATT põhineb kliendi ja serveri suhtlusel. Nüüd vaatame serveri seadmeid. See sisaldab sellist teavet nagu anduri väärtused, valgusti olek, asukohateave jne. Nüüd, kui kõik meie "paradi osalised" on nummerdatud, tuleb nad kuidagi seadme mällu paigutada. Selleks paneme nad tabelisse, mida nimetatakse atribuutide tabeliks. Pidage seda meeles. See on BLE süda. Just seda me edaspidi käsitleme. Nüüd nimetame iga rida atribuudiks. See tabel asub virna sügavuses ja tavaliselt pole meil sellele otsest juurdepääsu. Me initsialiseerime selle ja pöördume selle poole, kuid mis seal sees toimub, on meie eest peidetud seitsme pitseri taga.

Vaatame specifikatsiooni pilti, kuid enne seda tahan juhtida tähelepanu terminoloogias esinevale segadusele, nimelt deskriptoritele. Deskriptorite roll on täiendada omaduse kirjeldust. Kui on vaja laiendada selle võimalusi, siis kasutatakse deskriptoreid. Need on ka atribuudid ja koos teenuste ja omadustega asuvad nad atribuuditaotluse tabelis. Uurime neid hoolikalt artikli teises osas. Siiski mõnikord nimetatakse deskriptoriteks atribuuditaotluse tabelis rea numbrit. Seda tuleks silmas pidada. Me kasutame nende eesmärkide jaoks terminit „atribuutide viit”.


Nii et atribuut on diskreetne väärtus, millel on järgmised omadused:
1. Atribuudi viit (Attribute Handle) — see on tabeli indeks, mis vastab atribuudile.
2. Atribuudi tüüp (Attribute Type) — see on UUID, mis kirjeldab selle tüüpi.
3. Atribuudi väärtus (Attribute Value) — need on andmed, mida indekseeritakse atribuudi viita kaudu.
4. Atribuutide õigused (Attribute Permissions) — see on osa atribuudist, õigused, mida ei saa lugeda ega kirjutada atribuudiprotokolli kaudu.

Kuidas seda kõike mõista? Atribuudi viit — see on tinglikult öeldes selle number meie tabelis.
See võimaldab kliendil viidata atribuudile lugemise või kirjutamise päringutes. Saame numeerida oma ridu (atribuutide) alates 0x0001 kuni 0xFFFF. Meie raamatukapid assotsieerimisel — see on kaardi number paberkataloogis. Sarnaselt sellele, kuidas raamatukogus on kaardid järjestatud numbrite kasvuga. Iga järgnev rida peab olema suurem kui eelmine. Nagu raamatukogus, võivad ka mõned kaardid kaduma minna, meie ridadel võivad olla vahed. See on lubatud. Peamine on see, et need lähevad kasvavas järjekorras.

Atribuudi tüüp määrab, millega see atribuut esindab. Sarnaselt C-keelele,
kus on boolsed, numbrilised muutujad ja stringid, on see siin samuti. Atribuudi tüübi järgi saame teada,
millega me tegeleme ja kuidas me selle atribuudiga edasi töötame. Allpool vaatame mõningaid spetsiifilisi atribuuditüüpe. Näiteks 'teenuse deklaratsioon' (0x2800), 'deklaratsioon omadusest' (0x2803), 'deklaratsioon deskriptorist' (0x2902).

Atribuudiväärtus on selle tegelik väärtus, vabandust tautoloogia pärast. Kui atribuudi tüüp on string, siis võib atribuudi väärtus olla näiteks slogan "Hello World !!!". Kui atribuudi tüüp on "teenuse deklaratsioon", siis on selle väärtuseks teenus ise. Mõnikord sisaldab see teavet, kus leida teisi atribuute ja nende omadusi.

Atribuutide õigused võimaldavad serveril mõista, kas lugemine või kirjutamine on lubatud.
Pange tähele, et need õigused kehtivad ainult atribuudi väärtuse kohta, mitte viitaja, tüübi ega ise õiguste välja kohta. St, kui atribuudi kirjutamine on lubatud, saame näiteks rida "Hello World !!!" muuta reale "Good morning". Kuid me ei saa keelata uue rea kirjutamist või muuta atribuudi tüüpi ning määrata rida kui "teenuse deklaratsioon". Klient küsib serverile juurdepääsu, et teada saada, milliseid atribuute server pakub. Kuigi pole tingimata vaja väärtusi lugeda ja kirjutada.

Kuidas see välja näeb

GATT kontseptsioon seisneb atribuutide rühmitamises atribuutide tabelis väga spetsiifilises ja loogilises järjekorras. Vaatame lähemalt allpool toodud südame löögisageduse profiili. Selle tabeli vasakpoolsem veerg ei ole kohustuslik. See lihtsalt kirjeldab, millega tegemist on (atribuut). Kõik ülejäänud veerud on meile juba tuttavad.

Iga grupi ülaosas on meil alati teenuse deklaratsiooni atribuut. Selle tüüp on alati 0x2800, ning selle näitaja sõltub sellest, kui palju atribuute tabelis juba olemas on. Selle lahendused on alati ainult lugemiseks, ilma igasuguste autentimise või autoriseerimise kontrollideta. Nendest mõistedest räägime hiljem. Väärtus on veel üks UUID, mis määratleb, mis teenus see on. Tabelis on väärtus 0x180D, mille Bluetooth SIG määratleb südame löögisageduse teenusena.

Seejärel, kui teenus on kuulutatud, tuleb välja kuulutada ka omaduste kirjeldus. Selle vorm on sama, mis teenuse kuulutamisel. Selle UUID on alati 0x2803, ja õigused on samuti alati vaid lugemiseks, ilma igasuguste autentimise või autoriseerimise nõueteta. Vaatame nüüd välja Attribute Value, mis sisaldab teatud andmeid. See sisaldab alati näitajat, UUID-d ja omaduste kogumit. Need kolm elementi kirjeldavad järgnevat omaduse väärtuse kuulutamist. Näitaja tähistab loogiliselt selle omaduse väärtuse kuulutamise kohta atribuutide tabelis. UUID määratleb, millist tüüpi teavet või väärtust me eeldada saame. Näiteks temperatuuriväärtus, valguse lüliti olek või mõni muu meelevaldne väärtus. Ja lõpuks omadused, mis kirjeldavad, kuidas omaduse väärtusega suhelda on võimalik.

Siin ootab meid veel üks üllatus. See on seotud atribuutide õiguste ja omaduste omadustega. Vaatame pilti bitifiltri omadustest spetsifikatsioonist.

Nagu näete, on siin samuti väljad, mis annavad lugemise ja kirjutamise võimalused. Võite küsida, miks meil on lugemis-/kirjutamisõigused atribuudile ja omadusele
lugemise/kirjutamise jaoks omaduse väärtusele? Kas need ei peaks olema alati ühesugused? Tegelikult on omadused omaduse väärtuse jaoks lihtsalt soovitused kliendile, mida kasutatakse GATT-i ja rakendustasanditel. Need on lihtsalt vihjed selle kohta, mida klient võib oodata omaduse kuulutuse atribuudilt. Vaatame seda lähemalt. Millised on atribuudil olemasolevad õigused?

1. Juurdepääsuload:
     — lugemine
     — kirjutamine
     — lugemine ja kirjutamine
2. Autentimise luba:
     — autentimine on nõutav
     — autentimine ei ole nõutav
3. Autoriõiguse luba:
     — autoriseerimine on nõutav
     — autoriseerimine ei ole nõutav

Peamine erinevus atribuudi õiguste ja omaduste vahel on see, et esimesed kehtivad serverite kohta, teised aga klientide kohta. Serveril võib olla lubatud omaduse väärtuse lugemine, kuid selleks võib olla nõue autentimiseks või autoriseerimiseks. Seetõttu, kui klient küsib omaduste kohta, saame, et lugemine on lubatud. Kuid lugemiseks üritamisel saame vea. Seega võib julgelt öelda, et õiguste prioriteet on omaduste ees. Me ei saa kliendi poolelt teada, millised õigused atribuudi osas on.

Kirjeldaja

Naaseme meie tabeli juurde. Pärast omaduse väärtuse kuulutamist on võimalikud järgmised atribuudi kuulutused:
1. Uus omaduse kuulutus (teenuses võib olla palju omadusi)
2. Uus teenuse deklaratsioon (tabelis võib neid palju olla)
3. Kirjeldaja kuulutus

Kui räägime südame löögisageduse mõõtmise omadustest, siis meie tabelis tähistatakse omaduse väärtuse avaldamist descriptor'i avaldamisega. Descriptor on atribuut, mis sisaldab lisainfot omaduse kohta. On olemas mitu tüüpi descriptor'e. Nendest arutame põhjalikult teises osa artiklist. Praegu käsitleme ainult kliendi omaduste konfiguratsiooni descriptor'it (Client Characteristic Configuration Descriptor — CCCD). Selle UUID on 0x2902. Selle descriptor'i abil saab klient serveris aktiveerida indikaatori või teate. Nende vahel on väike erinevus, kuid see on siiski olemas. Teade ei vaja kliendilt kinnitus, kuid indikaator seda nõuab, ehkki see toimub GATT tasemel, mitte jõudes rakenduse tasemele. Miks nii, küsite? Kahjuks ei ole see mulle teada. Ütlen vaid, et Nordic'i spetsialistid soovitavad kasutada teateid. Eriti kuna paketi terviklikkuse kontroll (CRC abil) toimub mõlemas olukorras.

Kokkuvõte

Artikli lõpus tahaksin rääkida ühest asjast. Viimane tabel on pisut keeruline. Siiski olen ma sellele keskendunud, kuna see on esitatud artiklis, millele toetun. Artikli teises osas kavatsema süveneda BlueTooth 4.0 spetsifikatsiooni. Seal ootavad meid täpsemad skeemid ja joonised. Kolmandas osas tahaksin analüüsida Wiresharki programmi abil ühe seadme logifaili ja näha "otse" kogu seda teooriat, mida koos õpime.

Grupi töötaja «Tsezar Satellit»
Pecherski Vladimir

Allikas: habr.com