ניתוב הודעות ב-IoT Hub לעומת Event Grid — מדוע טלמטריה ואירועים אינם אותה בעיה

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

בפרק זה אנו מפרקים את ההבדל הארכיטקטוני בין Azure IoT Hub Message Routing לבין Azure Event Grid, תוך מעקב אחר תרחיש ייצור מציאותי. קו לחיצה שולח באופן רציף טמפרטורה, רטט, ספירת מחזורים, צריכת אנרגיה ומידע על מצב המכונה דרך שער תעשייתי. המדידות האלה יוצרות היסטוריה תפעולית שמהנדסים, צוותי נתונים, צוותי תחזוקה ומערכות ייצור may need לנתח בהמשך. נתק של התקן שונה, כי הוא מייצג שינוי שעשוי לדרוש מערכת אחרת או אדם אחר להגיב.

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


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

הרשומות האלה עשויות לתמוך מאוחר יותר בניטור מצב, חקירות איכות, ניתוח אנרגיה, חישובי OEE, אנליטיקה של Microsoft Fabric, דיווח ב-Power BI ואופטימיזציה של הייצור. לכן טלמטריה דורשת שמירה, שידור חוזר, טיפול בכפילויות, צרכנים עצמאיים ודרך אמינה לשחזר את ציר הזמן של הייצור.

IOT HUB MESSAGE ROUTING כמישור הנתונים של הטלמטריה
Azure IoT Hub מספק את הגבול המבוקר מהתקן לענן. התקנים ושערים מתאמתים באמצעות זהויות משלהם, שולחים הודעות מהתקן לענן, שומרים על מצב ניהול ההתקנים, ויכולים להשתתף בתקשורת מבוקרת מהענן להתקן.

ברגע שהודעת טלמטריה מגיעה ל-IoT Hub, Message Routing קובע לאן הנתונים צריכים להישלח. הניתוב יכול לבדוק מאפייני הודעה, מאפייני מערכת, חלקים מגוף ההודעה ומידע מתוך device twin. כך אפשר להפריד בין טלמטריית ייצור, מדידות אנרגיה, אבחון או סוגי הודעות אחרים לפני שהם מגיעים לצרכנים במורד הזרם.
ארכיטקטורה נפוצה נראית כך: שער תעשייתי → Azure IoT Hub → Message Routing → Event Hubs או Storage → עיבוד → Microsoft Fabric.

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

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

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

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

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

EVENT GRID פותר בעיה אחרת
Azure Event Grid בנוי סביב התראות מסוג פרסום-והרשמה. במקום לשחזר ללא הרף את מצב המכונה מתוך אלפי קריאות, Event Grid מודיע למערכות מעוניינות שמשהו השתנה, ונותן למנויים הזדמנות להגיב.
דוגמאות בסביבת IoT כוללות יצירת התקן, מחיקת התקן, התחברות, ניתוק, או תנאים שנגזרו מטלמטריה ונבחרו בקפידה. אירוע של יצירת התקן עשוי להפעיל תהליך קליטת נכס. אירוע של ניתוק התקן עשוי להתחיל חקירה טכנית. תנאי הנדסי שזוהה עשוי להפעיל תהליך תחזוקה.

מנויים טיפוסיים כוללים:
• Azure Functions
• Logic Apps
• Webhooks
• תהליכי אבטחה
• מערכות ניהול נכסים
• יישומים תפעוליים

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

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

מטפלים צריכים להיות מתוכננים סביב:
• עיבוד אידמפוטנטי
• אימות מצב נוכחי
• זהות האירוע וחותמות זמן
• בעלות מוגדרת בבירור על הפעולה שנוצרת

זה חשוב כי אירועים כפולים לא צריכים ליצור כרטיסים כפולים, התראות כפולות או רשומות תפעוליות סותרות.

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

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

לכן ארכיטקטורה שימושית מפרידה בין מצב הקישוריות לענן, בריאות השער, מצב הייצור של המכונה ומצב פקודת העבודה ב-MES. רק שילוב של המקורות האלה מאפשר לעסק לקבוע אם בעיית קישוריות טכנית באמת השפיעה על הייצור.

סינון ב-IoT Hub לעומת סינון ב-Event Grid
שתי הטכנולוגיות תומכות בסינון, אבל המטרה שונה. סינון ב-IoT Hub Message Routing עונה על השאלה אילו הודעות תפעוליות צריכות להיכנס לנתיב נתונים מסוים. סינון במנויי Event Grid עונה על השאלה אילו התראות מנוי מסוים צריך לקבל.

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