הבעיה שהניסוי מנסה לענות עליה מתחילה במקום מוכר. בבית עם עשר נורות חכמות, עיכוב קטן או ניסיון חיבור חוזר הם בעיקר מטרד. בבניין עם מאות גופי תאורה, חיישני נוכחות ומפסקים, פקודה אחת שמגיעה מאוחר לחלק מהחדרים כבר נראית לעין, והחלפת התקן תקול הופכת לפעולת תחזוקה שחוזרת שוב ושוב.
Matter הוא השפה המשותפת של המוצרים: הוא מגדיר כיצד נורה, מתג או חיישן מציגים את היכולות שלהם וכיצד שולחים להם פקודות בצורה מאובטחת. Thread הוא הכביש האלחוטי שעליו ההודעות יכולות לנוע. זו רשת דלת־הספק שמבוססת על כתובות IP, ולכן התקן Matter יכול להשתמש בה בלי שכל יצרן ימציא שער תרגום פרטי משלו.
Thread בנויה כרשת Mesh, כלומר חלק מההתקנים שמחוברים לחשמל יכולים גם להעביר הודעות עבור התקנים אחרים. אפשר לדמיין שורת שליחים במסדרון: אם היעד רחוק מדי מהשולח, החבילה עוברת מיד ליד. נתב גבול, או Border Router, מחבר בין רשת Thread לבין רשת ה־Ethernet או ה־Wi-Fi של הבניין. הוא מעביר חבילות IP בין הצדדים; הוא אינו צריך לתרגם את המשמעות של פקודת התאורה.
כדי לכבות מאתיים נורות אפשר לשלוח מאתיים פקודות נפרדות, אבל רשת תאורה גדולה מעדיפה לעיתים פקודת קבוצה אחת. ב־Matter היא נקראת הודעת Multicast: השולח פונה לכתובת של קבוצה, והרשת מפיצה את אותה הודעה לחברים בה. זה חוסך עבודה מהבקר, אבל כל העברה בין נתבים וכל הצפה של ההודעה ברשת מוסיפות זמן ושימוש בערוץ הרדיו.
Silicon Labs בנתה את הניסוי מלוחות BRD4187C עם שבב הרדיו EFR32MG24. ההתקנים סודרו באשכולות ברחבי המשרד, במרחק מרבי של כ־50 מטר בין אשכולות. החברה מציינת שבמקום נראו בדרך כלל לפחות 12 רשתות Wi-Fi, אך חשוב לדייק: היא הסתמכה על העומס הטבעי במשרד ולא יצרה בכוונה תרחיש קיצון של ערוץ רדיו עמוס.
המדידה נעשתה בקצה שרשרת העיבוד, במקום שבו יישום התאורה כבר קיבל את הפקודה, ולא רק ברגע שבו הביט הגיע לאנטנה. ממשק מעקב חומרתי סימן את זמן השליחה והקבלה בדיוק של מיקרו־שנייה. זה חשוב, מפני שבבדיקות מוקדמות עצם הדפסת יומן האבחון האטה את המערכת; כיבוי רישום ההודעות של Matter הוריד את זמן ההשהיה בערך בחצי.
גם תהליך ההצטרפות קיבל מספר יפה: 100% הצלחה וכשבע שניות בממוצע לכל התקן. אבל זו לא הייתה חוויית התקנה רגילה עם טלפון ו־Bluetooth. סקריפט הכניס תחילה כל לוח לרשת Thread באמצעות פרטי הרשת שסיפק נתב הגבול, ורק אז ביצע On-network commissioning — צירוף ההתקן שכבר נמצא ברשת אל קבוצת האמון המאובטחת של Matter. זו דרך הגיונית למתקין של בניין, אך היא אינה מוכיחה שאפשר לפתוח 200 קופסאות ולצרף אותן מהטלפון באותה הצלחה.
החלק המעניין פה הוא הפער בין 150 ל־200 התקנים. ברשתות של 50, 100 ו־150 התקנים, זמן התגובה הממוצע לפקודת קבוצה היה בערך 87 עד 96 מילישניות, לפי גודל ההודעה שנשלחה. ב־95% מהמקרים הפקודה עובדה בתוך 110 מילישניות. כאשר הרשת גדלה ל־200 התקנים, הממוצע עלה לכ־117 עד 130 מילישניות — אבל הזנב האיטי השתנה הרבה יותר: 95% מהפקודות עובדו רק בתוך 320 עד 350 מילישניות.
הסיבה אינה רק המספר 200. חמישים ההתקנים האחרונים הוצבו בפינה מרוחקת של המשרד, עם קו ראייה יחיד אל שאר הרשת. הודעות אליהם נאלצו לעבור כמה תחנות ולהיות מופצות לאורך המסלול; אפילו עמודים שהפרידו בין לוחות הוסיפו קפיצה. במילים אחרות, הוספת 50 התקנים גם שינתה את הגאוגרפיה של הרשת. הדוח אינו מאפשר להפריד לגמרי בין מחיר הגודל לבין מחיר המיקום, וזו בדיוק המגבלה שצריך לזכור כשמציגים את התוצאה כהוכחת קנה מידה.
בדיקת Unicast, פקודה שמיועדת להתקן יחיד ומקבלת תשובה, בודדה את מחיר הקפיצות בתוך קופסאות מיגון שמכריחות מסלול ידוע. פקודה עם תוכן של 8 בתים חזרה בממוצע בתוך 62 מילישניות אחרי קפיצה אחת ובתוך 341 מילישניות אחרי שבע קפיצות. עם תוכן של 296 בתים, שבע קפיצות העלו את הממוצע ל־473 מילישניות ואת התוצאה האיטית ביותר ל־526 מילישניות. בכל שילוב של גודל ומספר קפיצות נשלחו רק עשר חבילות, ולכן המספרים מראים היטב את המגמה אך אינם מבחן סטטיסטי ארוך.
הזמן הזה אינו רק זמן שידור. כל התקן צריך לפענח הצפנה, לפרש את מבנה ההודעה ולהפעיל את פקודת ה־Matter המתאימה. יישום הבדיקה רץ על FreeRTOS עם 13 משימות תוכנה מקבילות שמטפלות בין השאר ברשת, באבטחה ובגילוי שירותים. הודעה גדולה יותר גם עלולה להתפצל לכמה מסגרות קטנות בשכבת Thread. לכן Ping פשוט על אותה רשת יהיה מהיר יותר, אבל הוא אינו מודד את הזמן עד שנורה אמיתית משנה מצב.
במבחן יציבות של שלוש שעות נשלחה שוב ושוב פקודת קבוצה לכל 200 ההתקנים. שיעור האובדן שנמדד היה בערך 0.01% למטענים של 8, 16 ו־32 בתים, וכאחוז אחד למטען של 64 בתים. אלו תוצאות טובות, אך שלוש שעות הן עדיין משמרת קצרה ולא מבחן של חודשים בבניין שבו ספקי כוח נופלים, קושחה מתעדכנת ודיירים מוסיפים ציוד אלחוטי.
המחיר האמיתי נמצא במה שהניסוי עדיין לא בדק. כל הלוחות, השבבים וערימת התוכנה הגיעו מ־Silicon Labs, והבקר היה כלי בדיקה ולא מערכת מסחרית של יצרן אחר. הדוח השתמש ב־Matter 1.4, אף שהודעת החברה מזכירה בנפרד את תמיכתה ב־Matter 1.6. כל ההתקנים הוגדרו כהתקני Thread מלאים שמסוגלים להשתתף בניתוב, כדי להגדיל את תעבורת התחזוקה; זו אינה התערובת המקובלת של נתבים וחיישנים חסכוניים שמבלים זמן רב בשינה.
גם Silicon Labs משאירה לרשימת הבדיקות העתידיות את השאלות הקשות: כמה זמן לוקח לרשת שלמה לחזור אחרי הפסקת חשמל, כיצד היא מתנהגת בעומס Wi-Fi שנוצר בכוונה, מה קורה כאשר מאות חיישנים מדווחים יחד, ואיך בקר Matter מסחרי מגיב תחת העומס. לכן זו אינה הוכחה שכל בניין עם 200 מוצרים יעבוד מיד. זו כן מדידה פומבית ושימושית שמראה שהרשת יכולה להישאר פעילה — ושמסלול רדיו גרוע יכול להוסיף כרבע שנייה לזנב התגובה גם כאשר ממוצע הביצועים עדיין נראה יפה.
למתכנן של תאורה או אוטומציה לבניין, המסקנה מעשית: לא לבחור רשת לפי ספירת התקנים בלבד. צריך למפות קירות ועמודים, לבדוק כמה קפיצות עובר המסלול אל האזור המרוחק, למדוד פקודת קבוצה בקצה היישום ולא רק Ping, ולתכנן מראש התאוששות מהפסקת חשמל. מאתיים התקנים הם כותרת טובה; 350 מילישניות והסיבה שהן הופיעו הן כבר מידע שאפשר לתכנן לפיו.
הזווית ההנדסית
למה זה מעניין
הניסוי של Silicon Labs נותן הצצה נדירה למקום שבו הבטחה על רשת Mesh פוגשת תוכנית קומה אמיתית. רשת של 200 התקנים אכן עבדה, אבל מעבר מ־150 ל־200 התקנים והצבת הקבוצה החדשה באזור מרוחק העלו את זמן ה־95% לפקודת קבוצה מ־110 ל־320–350 מילישניות. הדוח מועיל במיוחד מפני שהוא גם חושף מה עוד חסר: רק שלוש שעות יציבות, חומרה ותוכנה של יצרן אחד, וללא מבחני הפסקת חשמל, עומס מכוון או בקר מסחרי.
השיחה ממשיכה
תגובות
שאלות, תיקונים ורעיונות שאפשר לבנות מהם משהו.