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

מכונת ייצור שולחת קריאות טמפרטורה, נתוני רטט, ספירת מחזורים, צריכת חשמל ומצבי הפעלה כל כמה שניות. לפתע, השער (gateway) מתנתק. האם כל ההודעות האלה הן פשוט "אירועים"? מבחינה טכנית, אפשר לתאר אותן כך. מבחינה ארכיטקטונית, זה עלול ליצור בעיות רציניות. Azure IoT Hub Message Routing ו־Azure Event Grid פותרים בעיות שונות. מסלול אחד נועד לשמר ולהפיץ נתונים תפעוליים. השני נועד להודיע למערכות שמשהו השתנה ועשוי לדרוש תגובה. התייחסות אליהם כאל דברים זהים עלולה להוביל לתהליכי עבודה יקרים שמעבדים נתוני חיישנים שגרתיים, או לאותות חשובים שטמונים בתוך צינור טלמטריה שאיש אינו עוקב אחריו באופן פעיל. בפרק הזה של M365 FM אנחנו עוקבים אחר מכונת ייצור דרך ארכיטקטורת Azure IoT אמיתית, ומסבירים היכן בדיוק משתלבים IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions ו־Logic Apps.

מה תלמדו

בפרק הזה נבחן:

• מדוע טלמטריה של מכונות ואירועים עסקיים או מחזור חיים נדרשים לדפוסי ארכיטקטורה שונים
• כיצד פועל Azure IoT Hub Message Routing כחלק ממישור נתונים של טלמטריה
• היכן Azure Event Grid משתלב בארכיטקטורות מונעות אירועים ותגובתיות
• מדוע סדר ההודעות חשוב לטלמטריה בייצור
• מדוע Event Grid לא צריך להפוך לאפיק הטלמטריה הראשי שלכם בנפח גבוה
• מדוע אין לאלץ ניתוב של IoT Hub לכל תהליך התראה
• כיצד IoT Hub ו־Event Grid יכולים לעבוד יחד באותה ארכיטקטורה
• כיצד Event Hubs יכול לתמוך בצרכני עיבוד זרמים עצמאיים
• מדוע יש לשמר לעיתים קרובות נתוני טלמטריה גולמיים לצורך מעקב וחקירה מאוחרת
• כיצד Microsoft Fabric ו־Power BI יכולים לצרוך נתונים תפעוליים מעובדים
• מדוע MES, ERP ומודלי נכסים מספקים הקשר שנתוני המכשיר לבדם אינם יכולים לספק
• כיצד יש לפרש אירועי ניתוק של מכשיר, מבלי להניח אוטומטית שהייצור נעצר
• כיצד שליחה כפולה, ניסיונות חוזרים, חותמות זמן ו־idempotency משפיעים על ארכיטקטורות תעשייתיות אמינות
• כיצד לתכנן תהליכי ניטור מצב, תחזוקה חזויה, מעקב איכות ותהליכי הפרעה לייצור
• כיצד להחליט האם הודעה שייכת למישור הנתונים, למסלול התגובה, או לשניהם

טלמטריה היא רשומה לאורך זמן

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

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

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

אירועים קיימים כדי להפעיל תגובה

לאירוע יש מטרה אחרת. אירוע אומר: משהו השתנה. מערכת או אדם עשויים להידרש להגיב. דוגמאות כוללות:

• התקן חדש נרשם
• שער התנתק מ־IoT Hub
• מכשיר התחבר מחדש
• מכשיר נמחק
• תהליך ניטור זיהה מצב הדורש בדיקה
• בדיקה הושלמה וניתן להתחיל תהליך עבודה נוסף

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

• הפעלת Azure Function
• הפעלת Logic App
• פתיחת חקירת תמיכה
• עדכון רשומת נכס
• בדיקת מצב המכשיר הנוכחי
• קריאה ליישום חיצוני דרך webhook
• הודעה לצוות האחראי על המערכת המושפעת

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

למה "הכול הוא אירוע" נשבר

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

מה Azure IoT Hub עושה בפועל

Azure IoT Hub מספק את הגבול הענן הפונה למכשירים. הוא תומך בתחומים כגון:

• זהויות מאובטחות של מכשירים
• הודעות מהתקן לענן (device-to-cloud)
• תקשורת מהענן להתקן (cloud-to-device)
• ניהול מכשירים
• Device twins
• גישה מבוקרת בין ציוד מחובר לשירותי Azure

IoT Hub יודע שמכשיר מאומת שלח הודעה. הוא אינו מבין אוטומטית מה ההודעה אומרת לגבי הייצור. שער עשוי לדווח: state = running אך "running" יכול להשמע כ:

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

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

הפכו לתומכים של הפודקאסט הזה: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.