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

פוסט זה מראה כיצד קרונס בנה פתרון סטרימינג לניטור הקווים שלהם, בהתבסס על אמזון קינסי ו שירות מנוהל אמזון עבור Apache Flink. השירותים המנוהלים במלואם הללו מפחיתים את המורכבות של בניית יישומי סטרימינג עם Apache Flink. שירות מנוהל עבור Apache Flink מנהל את הרכיבים הבסיסיים של Apache Flink המספקים מצב יישומים עמיד, מדדים, יומנים ועוד, ו-Kinesis מאפשרת לך לעבד בצורה חסכונית נתונים סטרימינג בכל קנה מידה. אם אתה רוצה להתחיל עם אפליקציית Apache Flink משלך, בדוק את מאגר GitHub עבור דוגמאות באמצעות Java, Python או SQL APIs של Flink.

סקירה כללית של הפיתרון

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

מערכת ניטור המצב והערכת כללים בנויה על AWS, תוך שימוש בשירותי ניתוח של AWS. התרשים הבא ממחיש את הארכיטקטורה.

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

מקור נתונים

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

{
  "version": 1,
  "timestamp": 1234,
  "equipmentId": "84068f2f-3f39-4b9c-a995-d2a84d878689",
  "tag": "water_temperature",
  "value": 13.45,
  "quality": "Ok",
  "meta": {      
    "sequenceNumber": 123,
    "flags": ["Fst", "Lst", "Wmk", "Syn", "Ats"],
    "createdAt": 12345690,
    "sourceId": "filling_machine"
  }
}

בליעת זרם

AWS IoT Greengrass הוא שירות זמן ריצה וענן עם קוד פתוח לאינטרנט של הדברים (IoT). זה מאפשר לך לפעול על נתונים מקומית ולצבור ולסנן נתוני מכשירים. AWS IoT Greengrass מספק רכיבים מובנים מראש שניתן לפרוס עד הקצה. פתרון פס הייצור משתמש ברכיב מנהל הזרמים, שיכול לעבד נתונים ולהעבירם ליעדי AWS כגון AWS IoT Analytics, שירות אחסון פשוט של אמזון (Amazon S3), וקינזיס. מנהל הזרם מאחסן ומצבר רשומות, ואז שולח אותם לזרם נתונים של Kinesis.

אחסון זרם

תפקידו של אחסון הזרם הוא לחצץ הודעות בצורה סובלנית לתקלות ולהפוך אותו לזמין לצריכה לאפליקציה אחת או יותר של צרכנים. כדי להשיג זאת ב-AWS, הטכנולוגיות הנפוצות ביותר הן Kinesis ו אמזון מנוהל סטרימינג עבור אפאצ'י קפקא (אמזון MSK). לאחסון נתוני החיישנים שלנו מקווי ייצור, Krones בחר ב-Kinesis. Kinesis הוא שירות הזרמת נתונים ללא שרת הפועל בכל קנה מידה עם זמן אחזור נמוך. רסיסים בתוך זרם נתונים של Kinesis הם רצף מזוהה באופן ייחודי של רשומות נתונים, כאשר זרם מורכב מרסיסים אחד או יותר. לכל רסיס קיבולת קריאה של 2 MB/s ויכולת כתיבה של 1 MB/s (עם מקסימום 1,000 רשומות/שניות). כדי להימנע מפגיעה במגבלות אלו, יש לפזר את הנתונים בין הרסיסים בצורה שווה ככל האפשר. לכל רשומה שנשלחת ל-Kinesis יש מפתח מחיצה, המשמש לקיבוץ נתונים לרסיס. לכן, אתה רוצה שיהיה לך מספר גדול של מפתחות מחיצה כדי לפזר את העומס באופן שווה. מנהל הזרם הפועל ב-AWS IoT Greengrass תומך בהקצאות מפתח מחיצות אקראי, מה שאומר שכל הרשומות מסתיימות ברסיס אקראי והעומס מתחלק באופן שווה. החיסרון של הקצאות מקשי מחיצות אקראיות הוא שהרשומות אינן מאוחסנות בסדר ב-Kinesis. אנו מסבירים כיצד לפתור זאת בסעיף הבא, שבו אנו מדברים על סימני מים.

סימני מים

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

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

public class BucketWatermarkGenerator implements WatermarkGenerator<DataPointEvent> {
private HashMap <String, WatermarkAndTimestamp> lastTimestamps;
private Long idleTimeOut;
private long maxOutOfOrderness;
}

עיבוד זרם

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

שליטה בזרם ובדפוס מצב השידור

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

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

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

קיבוץ מדדים

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

בשלב 1, אנו מגדירים שתי קבוצות תנאים. קבוצה 1 אוספת את מצב המכונה ואיזה מוצר עובר בקו. קבוצה 2 משתמשת בערך של חיישני הטמפרטורה והלחץ. לקבוצת תנאים יכולים להיות מצבים שונים בהתאם לערכים שהיא מקבלת. בדוגמה זו, קבוצה 1 מקבלת נתונים שהמכונה פועלת, והבקבוק של ליטר אחד נבחר כמוצר; זה נותן לקבוצה הזו את המדינה ACTIVE. לקבוצה 2 יש מדדים לטמפרטורה וללחץ; שני המדדים נמצאים מעל הסף שלהם במשך יותר מ-5 דקות. זה מביא לכך שקבוצה 2 נמצאת ב-a WARNING מדינה. זה אומר שקבוצה 1 מדווחת שהכל בסדר וקבוצה 2 לא. בשלב 2 מוסיפים משקלים לקבוצות. זה נחוץ במצבים מסוימים, מכיוון שקבוצות עלולות לדווח על מידע סותר. בתרחיש זה, קבוצה 1 מדווחת ACTIVE ודוחות קבוצה 2 WARNING, כך שלא ברור למערכת מה מצב הקו. לאחר הוספת המשקולות, ניתן לדרג את המצבים, כפי שמוצג בשלב 3. לבסוף, המדינה המדורגת הגבוהה ביותר נבחרה כמנצחת, כפי שמוצג בשלב 4.

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

שינוי קנה המידה של מנוע הכלל

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

יעדים

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

סיכום

בפוסט הזה, הראינו לכם איך Krones בנה מערכת ניטור קו ייצור בזמן אמת ב-AWS. שירות מנוהל עבור Apache Flink אפשר לצוות Krones להתחיל במהירות על ידי התמקדות בפיתוח אפליקציות ולא בתשתית. היכולות בזמן אמת של Flink אפשרו ל-Krones להפחית את זמן ההשבתה של המכונה ב-10% ולהגביר את היעילות עד 5%.

אם אתה רוצה לבנות יישומי סטרימינג משלך, בדוק את הדוגמאות הזמינות באתר מאגר GitHub. אם ברצונך להרחיב את אפליקציית Flink שלך עם מחברים מותאמים אישית, ראה מקל על בניית מחברים עם Apache Flink: היכרות עם ה-Async Sink. ה-Async Sink זמין בגרסה 1.15.1 של Apache Flink ואילך.

על הכותבים

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

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

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

• הפצת תוכן ויחסי ציבור מופעל על ידי SEO. קבל הגברה היום.
• PlatoData.Network Vertical Generative Ai. העצים את עצמך. גישה כאן.
• PlatoAiStream. Web3 Intelligence. הידע מוגבר. גישה כאן.
• PlatoESG. פחמן, קלינטק, אנרגיה, סביבה, שמש, ניהול פסולת. גישה כאן.
• PlatoHealth. מודיעין ביוטכנולוגיה וניסויים קליניים. גישה כאן.
• מקור: https://aws.amazon.com/blogs/big-data/krones-real-time-production-line-monitoring-with-amazon-managed-service-for-apache-flink/