22.7
המודל ישב בכלי נפרד
ל־POC של המסווג היה דף אינטרנט עצמאי משלו, באנגלית. מפעילים היו צריכים לעבור בין שתי מערכות.
תרגמתי לעברית, התאמתי לריצה בתוך iframe, ושילבתי כמסך ”בדיקה ידנית” באפליקציית הניהול, מאחורי כתובת HTTPS שנקבעת לפי סביבה.
יצרנית פלסטיק ישראלית רצתה שקו הייצור שלה ייבדק במצלמות, ולא רק בעין. הובלתי ובניתי מערכת בקרה חזותית שבודקת כל מצלמה פעם בשנייה, פותחת תקלה רק אחרי שלושה פריימים בעייתיים ברצף, מעדכנת את אות התקלה ב־PLC של הקו, ומראה למפעילים מה נמצא ואיפה, בעברית או באנגלית.
יריעת הפלסטיק יוצאת מהמכונה דרך חלון יציאה. קיפולים, קרעים בצד, חומר שלא ממורכז או סוף גליל יכולים להופיע בכל רגע, ועד שמישהו שם לב, הקו ממשיך לייצר פסולת. הלקוח רצה מצלמות על חלון היציאה, מודל שמבדיל בין פריים תקין לבעייתי, מסך למפעילים ולמנהלי מערכת, ואות ישיר ל־PLC של הקו. הכול היה צריך לרוץ On‑prem ליד המכונה, ולשתוק כשאין בעיה: מערכת שמתריעה לשווא פשוט מכבים אותה.
התרשים רחב מהמסך: החליקו הצידה לצפייה בכולו →
הכול רץ על מחשב אחד ליד הקו, כך שאין תלות בענן במסלול הזיהוי. בין המצלמות ל־backend אין שום חיבור חוץ מתיקייה: המצלמה כותבת תמונות, והצינור קורא את התמונה התקינה האחרונה. החלפת ספק מצלמות לא דורשת שינוי בקוד.
בהתחלה סטטוס בריאות אחד כיסה גם ”השרת לא עובד” וגם ”יש תקלה בקו”. נורה אדומה יכלה להיות מסד נתונים שנפל או יריעה קרועה. פיצלתי לזרם של בריאות השירות ולזרם של תקלות הקו, לכל אחד שעון משלו. המחיר: הלקוח מאחד את שניהם בעצמו, ומציג מצב שלישי כשאי אפשר לסמוך על זרם התקלות.
תקלה נפתחת אחרי 3 פריימים בעייתיים ברצף. פריים תקין מאפס את הספירה, ופריים שלא נקרא לא משנה אותה. אחרי תקלה רק המצלמה הזו מפסיקה להידגם ל־10 דקות, ומצלמות אחרות עדיין יכולות לדווח. המחיר: המערכת לא רואה שהתקלה נפתרה מוקדם, ולכן המפעילים קיבלו כפתור אישור.
ספים ומרווח הדגימה נקראים פעם אחת ונשמרים לכל חיי התהליך. המצב נשמר בזיכרון ונכתב קודם למסד. שאילתה בכל טיק של שנייה הייתה מגיעה ל־86,400 קריאות ביום. המחיר: חלק מהעריכות דורשות restart, ולכן אפליקציית הניהול מציגה פס ”ממתין ל־restart” עד שהוא קורה.
המודיע על התקלה רק מכניס את הביט החדש לתור. לולאת רקע מתחברת, כותבת פעם אחת, מתנתקת, ומנסה שוב כל 5 שניות עד שהכתיבה מצליחה. בין שינויים יכולות לעבור שעות, וחיבור S7 שעומד בטל נופל. המחיר: אחרי כיבוי והדלקה של ה־PLC הביט שומר את ערכו האחרון עד השינוי הבא. לבדיקת החיווט יש מצב ידני.
עם 642 תמונות מתויגות, backbone קפוא של MobileNetV3 וראש של random forest ניצחו fine-tuning. הוא רץ על CPU בכ־30 ms לתמונה ומתאמן מחדש בפחות משנייה מפיצ׳רים שמורים. המחיר: תמונות גבוליות שלא סווגו הן נקודת התורפה (recall של 58% בתת־קבוצה הזו).
זו המחשה של החוקים שה־backend אוכף על מצלמה אחת שנדגמת פעם בשנייה. אין בה נתונים של הלקוח.
רוב החלקים הקשים היו קשורים לזמן, לרעש ולאמון, לא למודל. מבחר:
ל־POC של המסווג היה דף אינטרנט עצמאי משלו, באנגלית. מפעילים היו צריכים לעבור בין שתי מערכות.
תרגמתי לעברית, התאמתי לריצה בתוך iframe, ושילבתי כמסך ”בדיקה ידנית” באפליקציית הניהול, מאחורי כתובת HTTPS שנקבעת לפי סביבה.
מסך הסטטוס שאל את השרת שוב ושוב, והמידע בו היה עדכני רק ברמת מרווח הדגימה.
העברתי את הבריאות לזרם SignalR שנדחף בהתחברות, ב־heartbeat ובכל שינוי. מסלול ה־polling נשאר כגיבוי.
קריאת חיזוי יכולה להימשך עד 30 שניות. אם מצב Setup היה מחכה לסיום המחזור הנוכחי, המערכת הייתה ממשיכה לקרוא פריימים ולשמור ראיות חצי דקה אחרי שהמפעיל עצר.
חיברתי cancellation token לכל סשן ניטור, וכל מחזור מקושר אליו. כניסה ל־Setup מבטלת מיד את קריאת ה־HTTP ואת כתיבת הראיה, ומחזור שבוטל נרשם כמידע ולא ככשל של הצינור.
בדיקת הבריאות רצה כל 30 שניות והדוגם כל שנייה. רישום של כל תוצאה היה מייצר כ־2,900 וכ־86,400 שורות זהות ביום.
כל רכיב שרץ בלולאה מחזיק בעצמו את המצב ”כבר דווח”, ורושם ב־audit רק מעברים. שעה של נפילת מסד היא עכשיו 2 רשומות במקום 120. טקסט של exceptions לא נכנס ל־audit, כך ש־connection strings לא יכולים לדלוף אליו.
תקלות מצלמה הגיעו ללקוחות דרך מפרסם הבריאות, שרץ על שעון קבוע של 30 שניות. תקלה שזוהתה יכלה לחכות חצי דקה בלי דיווח.
פיצלתי את התקלות לזרם משלהן, שנדחף על ידי הרכיב שרואה את הפריים השלישי. הזמן מזיהוי ועד המסך ירד מעד 30 שניות לטיק דגימה אחד (כשנייה).
פרמטרים שדורשים restart נשמרו ב־cache רק בקריאה הראשונה. עד שמשהו קרא אותם, ערך שנערך בממשק עוד יכול היה להיכנס לתוקף, וההתנהגות הייתה תלויה בתזמון.
הקפאתי את כל הפרמטרים שדורשים restart ב־snapshot אחד בזמן העלייה, השארתי את דגל ה־restart רק בפרמטרים שבהם הוא שווה את זה, והוספתי פס ”ממתין ל־restart” באפליקציית הניהול.
כשהתיקייה של מצלמה התרוקנה או לא הייתה נגישה, לולאת הצינור המשיכה להסתובב ונשארה ירוקה, למרות שחלק מהקו כבר לא נבדק.
מצלמה שלא מספקת פריים עוברת ל־Error בטיק הראשון וחוזרת בפריים התקין הראשון, בעדכון compare-and-set. כל מצלמה ב־Error הופכת את רכיב צינור התמונות ל־Unhealthy.
חלק מדגמי המצלמות כותבים תמונות לתתי־תיקיות לפי תאריך, ולא לתיקייה שהוגדרה להם, כך שהדוגם לא מצא כלום.
הוספתי מבנה תיקיות שמוצא פריימים בתתי־תיקיות לפי תאריך, והרחבתי את ניקוי ה־snapshots כך שגם הן מנוקות.
ה־PLC של הקו היה צריך ביט תקלה אחד, והמהנדסים היו צריכים דרך לבדוק את החיווט בלי לחכות לתקלה אמיתית.
בניתי כותב S7 מבוסס שינויים, עם תור, ניסיונות חוזרים ורשומות audit, ומצב ידני למנהלי מערכת בלבד. שחרור המצב הידני תמיד כותב בחזרה את המצב האמיתי, כך שה־PLC אף פעם לא נשאר עם ערך בדיקה. המפעילים קיבלו כפתור אישור לסגירת תקלה שתוקנה.
| מה | לפני | אחרי |
|---|---|---|
| מעקב אחרי חלון היציאה | בעין, בין משימות אחרות | כל מצלמה נבדקת פעם בשנייה, במצב Monitor |
| מתקלה ועד מסך המפעיל | עד 30 שניות (heartbeat של הבריאות) | כשנייה (טיק דגימה אחד) |
| מתקלה ועד המכונה | מישהו היה צריך לשים לב ולהגיב | ביט תקלה ב־PLC באותו רגע, עם ניסיונות חוזרים עד הצלחה |
| רעש | כל פריים בעייתי בודד יכול היה להתריע | 3 ברצף, דיווח אחד לתקלה, חלון של 10 דקות לכל מצלמה |
| נפח audit, נפילה של שעה | 120 רשומות זהות | 2 רשומות (נפל, חזר) |
| קריאות הגדרות במסלול החם | שאילתה בכל טיק (86,400 ביום) | קריאה אחת בעלייה, ואז זיכרון |
שיחת אבחון חינם · 30 דקות · ללא התחייבות
כתבו בכמה שורות: איזה תהליך או מערכת, מה כואב היום (זמן, טעויות, עלויות או פיילוט AI שנתקע) ומי עובד עם זה. אחרי שיחה קצרה מקבלים תוך כ־3 ימים תוכנית כתובה והצעת מחיר סגורה.
נפתח מייל מוכן מראש · מענה תוך יום עסקים
ה־AI קורא. הקוד סופר.
כל הפרויקטים