IoT Hub מול Event Hubs — למה רוב היצרנים בוחרים בשירות הלא נכון

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

2. סיווג תעבורת המפעל
לפני בחירת שירותי Azure, יש לסווג את התעבורה לפי שם, כיוון ובעלות כדי להבטיח טיפול נכון.

• אירועים הם עובדות הקשורות לנקודת זמן מסוימת, המתארות מה קרה ומתי, כגון השלמת מחזור לחיצה או קריאת רטט החוצה סף. אלה רשומות מסוג append-only שאין לערוך במורד הזרם.
• פקודות הן בקשות המורות להתקן או לגייטוויי לבצע פעולה עם כוונה מסוימת, כגון איסוף אבחונים או בדיקת חיבור. הן נושאות באחריות הביצוע ויש לכבד בהן את גבולות בקר הלוגיקה המתוכנת המקומי (PLC) ואת גבולות הבטיחות.
• מצב משקף את המצב הידוע הנוכחי של התקן, כגון גרסת תוכנה או מיפוי מתכון פעיל, ולא את ההיסטוריה המלאה הכרונולוגית שלו. מצב מנוהל בדרך כלל באמצעות מאפיינים מבוקשים ומדווחים.
• הודעות עסקיות כוללות עבודה תפעולית שחייבת להתבצע ולהיות מעוקבת, כולל עצירות איכות ובקשות תחזוקה. אין לערבב אותן ישירות עם צינורות אירועי חיישנים גולמיים.

3. מודל מנטלי: שער זהות לעומת כביש נתונים
Azure IoT Hub פועל כשער מבוקר, המתמקד בעיקר בקשרי התקנים ובמחזור החיים שלהם באמצעות רישום זהויות, אימות וסטטוס מופעל או מנוטרל. כך צוותי אבטחה יכולים לבודד או לנטרל גייטוויי יחיד חשוד או פרוץ, כגון גייטוויי של קו 4, במהלך אירוע אבטחה, מבלי לכבות את כל נתיב הטלמטריה של המפעל. לעומת זאת, Azure Event Hubs משמש ככביש הנתונים, והוא מתמקד לחלוטין בעיבוד זרמים ובהעברה בנפח גבוה עבור קוראים עצמאיים רבים. Event Hubs אינו מנהל מחזורי חיים של התקנים, קושחה או תצורות רצויות; תפקידו העיקרי הוא לשמור על תנועת התעבורה יעילה דרך מחיצות וקבוצות צרכנים.

4. ניהול התקנים ואבטחה
אפשרויות האימות תלויות במידה רבה ביכולות החומרה וארכיטקטורת האבטחה. מפתחות סימטריים באמצעות אסימוני SAS מתאימים היטב לחומרה מוגבלת ולגייטוויים, אך הם דורשים אחסון חומרתי מאובטח כדי למנוע גניבת מפתחות. לחלופין, אישורי X.509 מספקים שרשראות נקיות יותר באמצעות רשות אישורים מהימנה עבור צי גדול יותר, אם כי הם דורשים ניהול רוטציה ומחזור חיים איתן. מחזור החיים של התקן עוקב אחר דפוס של רישום, שינוי, השבתה והחלפה, ומבטיח שיחידת חומרה חלופית תתקשר בצורה נקייה לתפקידה התפעולי ולזהותה בענן מבלי לשבור צינורות במורד הזרם או ליצור נכסים פנטומים. יתרה מכך, תאומי התקנים (device twins) משתמשים במצבים רצויים ומדווחים לניהול תצורה ולמצב בריאות, אם כי יש לשמור טלמטריה בתדירות גבוהה לעולם לא בתוך תאומי התקנים.

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

6. סיכום החלטות ארכיטקטוניות
בעת הערכת שירותים, Azure IoT Hub מתאים ביותר לגייטוויים קצה מנוהלים, תצורות מרחוק ובידוד אבטחה של התקנים באמצעות רישום לכל התקן ותאומי התקנים מובנים. Azure Event Hubs מתאים ביותר לטלמטריה רציפה ובנפח גבוה המופצת למספר צרכנים באמצעות מדיניות גישה ברמת המרחב (namespace), ללא ניהול מחזור חיים מובנה של התקנים. ארכיטקטורה חזקה למפעל משלבת לעתים קרובות את שני השירותים: IoT Hub בגבול החיבור לניהול אמון, זהות ותצורה, ו-Event Hubs במורד הזרם להפצה בטוחה של זרם האירועים בנפח גבוה לצרכנים עצמאיים.

הפוך לתומך של הפודקאסט הזה: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.