BLE תחת מיקרוסקופ (ATTы GATTы…)

BLE תחת מיקרוסקופ (ATTы GATTы…)

חלק 1, סקירה

די הרבה זמן כבר חלף מאז יצא המפרט הראשון ל-Bluetooth 4.0. ולמרות שהנושא BLE מעניין מאוד, הוא עדיין דוחה מפתחים רבים בגלל המורכבות שלו. במאמרים הקודמים שלי, הסתכלתי בעיקר על שכבת הקישור והשכבה הפיזית ברמה הנמוכה ביותר. זה איפשר לנו להימנע מהצורך לפנות למושגים מורכבים ומבלבלים כמו פרוטוקול התכונה (ATT) ופרופיל התכונה הכללית (GATT). עם זאת, אין לאן ללכת, בלי להבין אותם, אי אפשר לפתח מכשירים תואמים. היום אני רוצה לחלוק את הידע הזה איתך. במאמר שלי אסתמך על ספר לימוד למתחילים מהאתר הנורדי. אז בואו נתחיל.

למה הכל כל כך קשה?

לדעתי, מיד היה ברור שניהול מכשירים דרך הסמארטפונים הוא נושא מאוד מבטיח ומתמשך. לכן, הם החליטו לבנות אותו באופן מיידי ומקסימום. כדי שיצרני גאדג'טים שונים לא יציגו פרוטוקולים משלהם, אשר אז יהיו בלתי תואמים. מכאן הקושי. כבר בשלב הראשון ניסו לדחוס כל מה שאפשר לפרוטוקול BLE. וזה לא משנה אם זה יהיה שימושי מאוחר יותר או לא. בנוסף, הם נתנו אפשרות להרחיב את רשימת המכשירים לעתיד.

בואו נסתכל על התמונה שבה מצויר דיאגרמת פרוטוקול BLE. זה מורכב מכמה שכבות. השכבה הפיזית הנמוכה ביותר (PHY) אחראית על ערוץ הרדיו של המכשיר. שכבת קישור (LL) מכילה את כל רצף הבתים בהודעה המשודרת. במאמרים קודמים למדנו בדיוק את זה. Host Controller Interface (HCI) הוא פרוטוקול החלפה בין שכבות BLE או שבבים אם הבקר והמארח מיושמים על שבבים שונים. פרוטוקול הבקרה וההסתגלות הלוגי (L2CAP) אחראי על יצירת מנות, מסגור, בקרת שגיאות והרכבת מנות. פרוטוקול מנהל האבטחה (SMP) אחראי על הצפנת מנות. פרופיל הגישה הכללי (GAP) אחראי לחילופי נתונים ראשוניים בין מכשירים כדי לקבוע "מי זה מי". זה כולל גם סריקה ופרסום. במאמר זה אתמקד בשני החלקים הנותרים של הפרוטוקול - GATT ו-ATT. GATT הוא מבנה-על של ATT, ולכן הם שלובים זה בזה.

כדי לפשט את הסיפור, ברצוני לפנות לאנלוגיה. שמעתי את זה איפשהו והייתי רוצה לתמוך בזה. חשבו על מכשיר BLE כעל כוננית עם מספר מדפים. כל מדף הוא נושא נפרד. לדוגמה, יש לנו מדפים עם מדע בדיוני, מתמטיקה ואנציקלופדיות. בכל מדף יש ספרים עם נושא מוגדר. ולכמה ספרים יש אפילו סימניות נייר עם הערות. בנוסף, יש לנו קטלוג נייר קטן של כל הספרים. אם אתה זוכר, ספריות בית ספר הן קופסה צרה עם כרטיסי נייר. עם אנלוגיה זו, הארון הוא הפרופיל של המכשיר שלנו. מדפים הם שירותים, ספרים הם מאפיינים, והקטלוג הוא טבלת תכונות. סימניות בספרים הן מתארות, שגם עליהן אדבר בהמשך ביתר פירוט.

כל מי שפיתח מכשירים יודע שלפרויקטים רבים יש פיסות קוד דומות. העובדה היא שלמכשירים רבים יש פונקציונליות דומה. לדוגמה, אם מכשירים מופעלים על ידי סוללות, אזי בעיית הטעינה והניטור של רמתם תהיה זהה. אותו דבר לגבי חיישנים. למעשה, גישה מונחה עצמים לתכנות "מספק את היכולת ליצור אובייקטים המשלבים מאפיינים והתנהגויות לכדי איחוד עצמאי שניתן לעשות בו שימוש חוזר". לדעתי, BLE ניסה גישה דומה. פרופילים פותחו על ידי קבוצת האינטרסים המיוחדת של Bluetooth (SIG). מכשירים מיצרנים שונים בעלי אותם פרופילים צריכים לעבוד אחד עם השני ללא קושי. פרופילים, בתורם, מורכבים משירותים ושירותים של מאפיינים, בתוספת מתארים. באופן כללי זה עשוי להיראות כך:

לדוגמה, שקול את דיאגרמת הפרופיל של מד דופק (צמיד כושר). הוא מורכב משני שירותים ומספר מאפיינים. ממנו מתבררת מיד היררכיית הפרופילים. מאפיין המחסום מאפס את ספירת ההוצאה הכוללת של הקלוריות לאפס.

1. שירות הדופק כולל שלושה מאפיינים (0x180D):
    א) מאפיין דופק חובה (0x2A37)
    ב) מאפיין מיקום חיישן גוף אופציונלי (0x2A38)
    ג) מאפיינים מותנים של נקודת בקרת הדופק (0x2A39)
2. שירות תחזוקת סוללות (0x180F):
    א) מאפיין חובה לרמת טעינת הסוללה (0x2A19)

UUID

כדי שנוכל לגשת באופן ייחודי לרכיבי פרופיל (שירותים, מאפיינים ומתארים), עלינו למספר את כולם איכשהו. לשם כך, מוצג מושג כמו מזהה ייחודי אוניברסלי (UUID) או מזהה ייחודי אוניברסלי. ה-UUID מצוין בסוגריים של כל שורה. ויש כאן ייחוד אחד. עבור UUID, החלטנו להשתמש בקוד של 16 ו-128 סיביות באורך. למה אתה שואל? בפרוטוקול BLE הכל עוסק בחיסכון באנרגיה. לכן, המימד של 16 סיביות סביר למדי. לא סביר שייווצרו יותר מ-65 אלף בעתיד הקרוב. שירותים ומאפיינים ייחודיים. כרגע, כל מה שהם יכלו כבר נספר (זכור מאיפה זה בא - "גם הוא ספר אותך" :-)) אלמנטים ממוספרים פרופילים, של שירותים, מאפיינים и מתארים אתה יכול להסתכל בקישורים.

עם זאת, אני חושב שכולם זוכרים את הסיפור עם 4 בתים של כתובות IP באינטרנט. בהתחלה חשבנו שזה מספיק, אבל עכשיו אנחנו עדיין לא יכולים לעבור לכתובת של 6 בתים. כדי לא לחזור על הטעות הזו ולתת דרור לידיים המשובבות של עשה זאת בעצמך, SIG החליטה מיד להציג UUIDs של 128 סיביות. זה באופן אישי מזכיר לי את רצועת ה-433 מגה-הרץ ללא רישיון, שניתנה לכל מיני קוליבינים מערוץ הרדיו. במקרה שלנו, מזהה של 128 סיביות של שירותים ומאפיינים נבנה. משמעות הדבר היא שאנו, עבור השירותים והמכשירים שלנו, יכולים להשתמש כמעט בכל ערך של 128 סיביות. עם זאת, ההסתברות להגיע לאותו UUID שואפת לאפס.

למעשה, לרכיבי UUID קצרים של 16 סיביות יש את ההרחבה שלהם לערך של 128 סיביות. במפרט, הרחבה זו נקראת Bluetooth Base UUID ובעלת הערך 00000000-0000-1000-8000-00805F9B34FB. אם, למשל, לתכונת 16 סיביות UUID יש את הערך 0x1234, אז ל-UUID המקביל של 128 סיביות יהיה הערך 00001234-0000-1000-8000-00805F9B34FB. ואפילו הנוסחה המתאימה ניתנת:

                                128_bit_value = 16_bit_value * 2^96 + Bluetooth_Base_UUID

אני לא יודע מאיפה הגיע המספר הקסום הזה. אם מישהו מהקוראים יודע, שיכתוב בתגובות (משתמש עם הכינוי Sinopteek כבר עשה זאת. ראו את ההערות). באשר להמצאת UUIDs של 128 סיביות, באופן עקרוני אתה יכול להשתמש במיוחד גֵנֵרָטוֹרמי יעשה את זה בשבילך.

ATTy GATTy...

למעשה, אז הכיף מתחיל. הרשו לי להזכיר לכם ש-ATT מבוסס על יחסי לקוח-שרת. כעת אנו מסתכלים על התקן השרת. הוא מכיל מידע כגון ערכי חיישנים, מצב מתג האור, נתוני מיקום וכו'. כעת, כשכל "המשתתפים במצעד שלנו" ממוספרים, עלינו איכשהו למקם אותם בזיכרון המכשיר. לשם כך, שמנו אותם בטבלה שנקראת טבלת תכונות. זכור זאת היטב. זה הלב של BLE. זה מה שנבחן עוד. כעת נקרא לכל שורה תכונה. שולחן זה ממוקם עמוק בערימה, וככלל, אין לנו גישה ישירה אליו. אנחנו מאתחלים אותו וניגשים אליו, אבל מה שקורה בפנים מוסתר מאיתנו מאחורי שבעה חותמות.

הבה נתבונן בתמונה מתוך המפרט, אך לפני כן, ברצוני להפנות מיד את תשומת הלב לבלבול התכוף במונחים, כלומר בתיאורים. תפקידו של המתאר הוא להשלים את תיאור המאפיין. כאשר יש צורך להרחיב את היכולות שלו, אז נעשה שימוש בתיאורים. הם גם תכונות, ובדיוק כמו שירותים ומאפיינים, הם ממוקמים בטבלת התכונות. נבחן אותם בפירוט בחלק השני של המאמר. עם זאת, לפעמים מתארים מתייחסים למספר השורה בטבלת התכונות. יש לזכור זאת. כדי למנוע בלבול, נשתמש במונח "מצביע על מאפיינים" למטרות אלו.


אז תכונה היא ערך בדיד שיש לו את המאפיינים הבאים המשויכים אליו:
1. ידית תכונה היא אינדקס הטבלה המתאים לתכונה
2. Attribute Type הוא UUID שמתאר את הסוג שלו
3. ערך תכונה הוא הנתונים שנוספו על ידי מצביע התכונה
4. הרשאות תכונה הן חלק של תכונה, הרשאות שלא ניתן     להקריא או לכתוב באמצעות פרוטוקול התכונה

איך להבין את כל זה? מצביע התכונה הוא, יחסית, המספר שלו בטבלה שלנו.
זה מאפשר ללקוח להתייחס לתכונה בבקשות קריאה או כתיבה. אנחנו יכולים למספר את השורות (התכונות) שלנו מ-0x0001 ל-0xFFFF. בשיוך שלנו לארון הספרים, זה מספר הכרטיס בקטלוג הנייר. באופן דומה, כמו בקטלוג הספרייה, הכרטיסים מסודרים בסדר גדל והולך של מספרם. המספר של כל שורה שלאחר מכן חייב להיות גדול מהקודמת. ממש כמו בספרייה, לפעמים חלק מהכרטיסים הולכים לאיבוד, כך שאצלנו יתכנו פערים במספור השורות. זה מותר. העיקר שהם הולכים בהדרגה.

סוג התכונה קובע מה התכונה מייצגת. באנלוגיה לשפת C,
היכן שיש משתנים בוליאניים, מספריים ומחרוזות, אז זה כאן. לפי סוג התכונה אנו מזהים
במה אנו מתמודדים וכיצד נוכל להמשיך לעבוד עם התכונה הזו. להלן נבחן כמה סוגים ספציפיים של תכונות. לדוגמה, "הצהרת שירות" (0x2800), "הצהרה אופיינית" (0x2803), "הצהרת מתאר" (0x2902).

הערך של תכונה הוא המשמעות האמיתית שלה, סליחה על הטאוטולוגיה. אם סוג התכונה הוא מחרוזת, אז ערך התכונה יכול להיות, למשל, הסלוגן "Hello World !!!". אם סוג התכונה הוא "הצהרת שירות", אז הערך שלו הוא השירות עצמו. ולפעמים זהו מידע על היכן למצוא תכונות אחרות והמאפיינים שלהן.

הרשאות תכונה מאפשרות לשרת להבין אם מותרת גישת קריאה או כתיבה.
שימו לב שההרשאות הללו חלות רק על ערך התכונה, ולא על המצביע, הסוג או שדה ההרשאה עצמו. הָהֵן. אם הקלטת תכונות מותרת, נוכל לשנות, למשל, את השורה "Hello World !!!" לשורה "בוקר טוב". אבל אנחנו לא יכולים לאסור כתיבת שורה חדשה או לשנות את סוג התכונה ולציין את השורה כ"הצהרת שירות". כאשר לקוח יוצר קשר עם שרת, הלקוח מבקש את התכונות שלו. זה מאפשר ללקוח לדעת מה השרת יכול לספק. אמנם אין צורך לקרוא ולכתוב את הערכים.

איך זה נראה

הרעיון של GATT הוא לקבץ תכונות בטבלת תכונות יחד בסדר ספציפי והגיוני. בואו נסתכל מקרוב על פרופיל הדופק למטה. העמודה השמאלית ביותר בטבלה זו היא אופציונלית. זה פשוט מתאר לנו מהי השורה (התכונה) הזו. כל שאר הטורים כבר מוכרים לנו.

בראש כל קבוצה יש לנו תמיד תכונה של הצהרת שירות. הסוג שלו הוא תמיד 0x2800, והמצביע תלוי בכמה תכונות כבר קיימות בטבלה. ההרשאות שלה הן תמיד לקריאה בלבד, ללא כל אימות או הרשאה. על מושגים אלה נדבר מעט מאוחר יותר. הערך הוא UUID אחר שמזהה מהו השירות. בטבלה, הערך הוא 0x180D, המוגדר על ידי Bluetooth SIG כשירות דופק.

בעקבות ההכרזה על השירות, מגיעה ההכרזה על המאפיין. זה דומה בצורתו להצהרת שירות. ה-UUID שלו הוא תמיד 0x2803, וההרשאות שלו תמיד לקריאה בלבד ללא כל אימות או הרשאה. הבה נסתכל על השדה ערך תכונה, הכולל כמה נתונים. הוא תמיד מכיל מצביע, UUID וקבוצת מאפיינים. שלושת האלמנטים הללו מתארים את ההכרזה שלאחר מכן על הערך האופייני. המצביע מציין באופן טבעי את המיקום של הצהרת הערך המאפיין בטבלת התכונות. ה-UUID מתאר איזה סוג של מידע או ערך אנחנו יכולים לצפות. לדוגמה, ערך הטמפרטורה, מצב מתג האור או ערך שרירותי אחר. ולבסוף מאפיינים, המתארים כיצד ניתן ליצור אינטראקציה עם הערך האופייני.

עוד מחכה לנו כאן. זה משויך להרשאות תכונות ומאפיינים אופייניים. בואו נסתכל על התמונה של מאפייני שדה הסיביות מהמפרט.

כפי שניתן לראות, יש כאן גם שדות המספקים יכולות קריאה וכתיבה. ייתכן שאתה תוהה מדוע יש לנו הרשאות קריאה/כתיבה עבור תכונה ונכס
לקרוא/לכתוב עבור ערך מאפיין? האם הם לא צריכים להיות תמיד אותו הדבר? העובדה היא שהמאפיינים עבור הערך המאפיין הם למעשה רק המלצות עבור הלקוח המשמש בשכבות GATT ושכבות יישום. אלו הם רק רמזים לגבי מה שהלקוח עשוי לצפות מתכונת ההצהרה האופיינית. בואו נסתכל על זה ביתר פירוט. אילו סוגי הרשאות יש לתכונה?

1. הרשאות גישה:
     - קריאה
     - תקליט
     - תקרא ותכתוב
2. הרשאת אימות:
     - נדרש אימות
     - אין צורך באימות
3. הרשאת הרשאה:
     - נדרש אישור
     - אין צורך באישור

ההבדל העיקרי בין רזולוציית תכונות ומאפיינים אופייניים הוא שהראשונים חלים על שרתים, והאחרונים על לקוחות. ייתכן שהשרת יורשה לקרוא את הערך המאפיין, אך עשוי לדרוש אימות או הרשאה. לכן, כאשר הלקוח יבקש את המאפיינים של המאפיין, נקבל כי הקריאה מותרת. אבל כשאנחנו מנסים לקרוא, אנחנו מקבלים שגיאה. לכן, אנו יכולים לדבר בבטחה על העדיפות של הרשאות על פני נכסים. בצד הלקוח, איננו יכולים לקבל ידע לגבי ההרשאות שיש לתכונה.

מתאר

נחזור לשולחן שלנו. לאחר הצהרת הערך של מאפיין, הצהרות התכונות הבאות אפשריות:
1. הצהרת מאפיינים חדשה (שירות יכול להיות בעל מאפיינים רבים)
2. הצהרת שירות חדשה (ייתכן שיש הרבה מהן בטבלה)
3. הכרזה על ידית

במקרה של מאפיין מדידת הדופק, בטבלה שלנו, ההצהרה על הערך המאפיין מלווה בהצהרה של המתאר. מתאר הוא תכונה עם מידע נוסף על מאפיין. ישנם מספר סוגים של מתארים. נדבר עליהם בפירוט בחלק השני של מאמר זה. לעת עתה, ניגע רק ב-Client Characteristic Configurator Descriptor (CCCD). יש לו UUID שווה ל-0x2902. באמצעות מתאר זה, ללקוח יש את היכולת לאפשר חיווי או התראה בשרת. ההבדל ביניהם קטן, אבל עדיין קיים. הודעה אינה מחייבת אישור קבלה מהלקוח. אינדיקציה מחייבת זאת, למרות שהיא מתרחשת ברמת GATT, לא מגיעה לרמת היישום. למה כן, אתם שואלים? אבוי, אני לא יודע את זה. הרשו לי רק לומר שמומחים נורדיים ממליצים להשתמש בהודעות. יתרה מכך, בדיקת תקינות החבילה (באמצעות CRC) מתרחשת בשני המקרים.

מסקנה

בסוף המאמר אני רוצה לומר זאת. הטבלה האחרונה קצת מבלבלת. עם זאת, בחרתי בו כי הוא נכנע статье, שעליו אני סומך. בחלק השני של המאמר שלי, אני מתכוון להעמיק במפרט ה-BlueTooth 4.0. דיאגרמות וציורים נכונים יותר מחכים לנו שם. בחלק השלישי, ברצוני לנתח את היומן שהושג באמצעות תוכנית Wireshark מאחד הגאדג'טים ולראות "חי" את כל התיאוריה שאנו לומדים.

עובד קבוצת החברות "קיסר לוויין"
פצ'רסקיך ולדימיר

מקור: www.habr.com