"פשוט תשלח את הנתונים לשרת" — למה זה לא פשוט

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

אבני הבניין בצד הקושחה

מחסנית תקשורת ופרוטוקול

מעל שכבת הרשת (WiFi, סלולר או Ethernet) נדרש פרוטוקול הודעות. הבחירה הנפוצה למוצרים משובצים היא MQTT — קל משקל, עובד טוב על קווים איטיים ותומך במודל פרסום-הרשמה שמתאים לטלמטריה. מתי בכל זאת HTTP — השווינו בMQTT או HTTP. בקושחה זה מתורגם לספריית client, ניהול חיבור מתמשך והודעות keep-alive.

אבטחה: TLS ותעודות

כל תעבורה לענן חייבת לעבור על גבי TLS. במיקרו-בקר זה אומר ספריית הצפנה, זיכרון פנוי של עשרות קילובייט לפחות לתהליך ה-handshake, ואחסון מאובטח למפתחות — רצוי ברכיב secure element ייעודי. כל מכשיר צריך זהות ייחודית משלו: תעודה או מפתח שמוטמעים כבר בפס הייצור, כך שהענן יודע בדיוק איזה מכשיר מדבר איתו ויכול לנתק מכשיר בודד שנפרץ. איך בונים את זה נכון — ברישום מכשירים בענן — Provisioning מאובטח. ובלי הגנה על הקושחה עצמה האבטחה לא שלמה — ראו Secure Boot והצפנת קושחה.

שעון אמת

פרט קטן שמפיל מערכות: אימות תעודת TLS דורש לדעת מה השעה. מיקרו-בקר שמתעורר בלי שעון חייב לסנכרן זמן (למשל מול שרת SNTP) לפני שהוא בכלל יכול להתחבר בצורה מאובטחת. תכננו את סדר האתחול בהתאם, וחשבו מה קורה כששרת הזמן עצמו לא זמין.

התנהגות במצבי ניתוק

הרשת תיפול. השאלה היחידה היא איך המוצר מתנהג כשזה קורה:

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

עדכוני קושחה מרחוק (OTA)

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

ומה עם צריכת החשמל?

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

איך בודקים שזה באמת עמיד

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

לתכנן מהיום הראשון, לא להדביק בסוף

חיבור מוצר משובץ לענן נוגע בבחירת המיקרו-בקר (זיכרון להצפנה), בתכנון החשמל (צריכת רדיו), בפס הייצור (הטמעת זהויות) ובענן עצמו — בחירת הפלטפורמה מצידה משפיעה חזרה על הקושחה, כמתואר בAWS IoT או Azure IoT. לכן מתכננים את שרשרת החיבור כולה כבר באפיון, לא כתוספת מאוחרת. עוד בנושאי קושחה — בעמוד האשכול פיתוח תוכנה embedded.

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.