כיצד נתוני מכונות מגיעים ל-Microsoft Fabric - מ-OPC UA ועד אנליטיקה בזמן אמת

הקליטה של אזעקות מכונה, ערכי חיישנים, מוני ייצור ואירועי תקלה לענן קלה מתמיד. OPC UA חושף את אות המכונה, שכבת edge אוספת אותו, MQTT יכול להפיץ אותו מקומית, ו-Microsoft Fabric יכול לקלוט ולנתח את הזרם שנוצר. החלק הקשה מתחיל אחרי שהנתונים מגיעים: איך הופכים טלמטריה גולמית להקשר ייצורי מספיק כדי לתמוך בהחלטה ממשית?

הפרק הזה עוקב אחרי אות מכונה אחד מרצפת המפעל דרך מחסנית הנתונים התעשייתית של Microsoft. הוא מתחיל ב-OPC UA, עובר דרך ה-edge וה-MQTT, חוצה בצורה מאובטחת אל Azure ו-Microsoft Fabric, ואז בוחן איך Eventstream, Eventhouse, KQL, Lakehouse, Power BI, MES, ERP, נתוני תחזוקה והקשר ייצורי משתלבים זה בזה. המטרה אינה רק להציג עוד צינור טלמטריה. המטרה היא להסביר מה חייב לקרות לפני שנתוני מכונה הופכים לשימושיים לייצור, תחזוקה, איכות ותכנון.

מעצירת מכונה להשלכה ייצורית

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

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

OPC UA – איפה האות נכנס למסלול הנתונים

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

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

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

שמירו על גבול OT מבוקר

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

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

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

ה-edge צריך לשפר את הנתונים – לא להמציא משמעות עסקית

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

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

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

Azure IoT Edge לעומת Azure IoT Operations

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

Azure IoT Operations ממוצב יותר כסביבת נתוני תעשייה ברמת האתר. הוא פועל על סביבת Kubernetes עם Azure Arc ו-כולל יכולות סביב חיבור OPC UA, MQTT, זרימות נתונים וניהול נכסים והתקנים. זה יכול להיות הגיוני יותר כאשר באתר יש כמה קווים, יצרני מכונות מרובים, צרכנים מקומיים, והצורך לחזור על דפוס edge מנוהל בין מפעלים.

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

MQTT כשדרה של אירועי המפעל

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

זה מסיר תלויות נקודה-לנקודה רבות. יישום חדש יכול להירשם לנושא מאושר בלי ליצור קישור ישיר נוסף אל ה-PLC או לשרת OPC UA.

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

ה-Unified Namespace הוא חוזה – לא רק עץ נושאים

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

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

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

MQTT יכול להעביר את החוזה, אבל MQTT לא יוצר את החוזה.

מאירוע OPC UA להודעת MQTT

הפיכת הודעת OPC UA לאירוע MQTT היא יותר מתרגום פרוטוקול. המחבר נדרש...