מסך ניטור head-end של AMI, שורות של חותמות זמן ממונים חכמים דוהות לאפור כשהמונים משתתקים
Artificial IntelligenceEnergyTechnology

73,000 מונים חכמים כבו בן לילה — והקושחה עברה כל בדיקת מעבדה

Ashutosh SinghalAshutosh Singhal15 ביוני 202612 min

בנובמבר 2024, חברת שירות בפלאנו, טקסס, דחפה עדכון קושחה שגרתי ל-88,000 מוני מים. העדכון היה אמור לתקן התרוקנות מוקדמת של הסוללה — תיקון בתום לב של בעיה ידועה. במעבדה, הוא עבד. בשטח, 73,000 מונים כבו ומעולם לא חזרו לפעול.

אני חוזר שוב ושוב למספר הזה בגלל מה שהוא מרמז עליו. זו לא הייתה פריצה, סערה או פגם ייצור. זה היה עדכון תוכנה שנבדק ואושר, שהתנהג בדיוק כפי שתוכנן — ובכל זאת הוא הפך 83% מצי ללבנים מתות. הפער הזה בין "עבר את המעבדה" ל"הרג את השטח" הוא כל הבעיה בבינה מלאכותית של מונים חכמים, וזו הסיבה שבנינו מערכת תחזוקה חזויה ל-AMI ב-Veriprajna שמנטרת את האותות שדשבורד אנליטי מעולם לא נבנה כדי לראות.

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

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

אותה קושחה, שתי תוצאות: מונה בריא על שולחן המעבדה מול צי שדה שקורס במתח נמוך, 73,000 מונים כבויים

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

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

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

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

הכשלים האלה מתקבצים. הקושחה של אותו ספק גרמה לתקריות דומות במיניאפוליס, טורונטו וניו יורק. Toronto Hydro גילתה כ-470,000 משדרים שמתנוונים מוקדם והוציאה 5.6 מיליון דולר על סבב התיקון הראשון בלבד. ממפיס רשמה שיעור כשל מערכתי של 8% והקימה קרן תיקונים בסך 9 מיליון דולר. בבריטניה, בערך אחד מכל חמישה מונים חכמים אינו פועל כפי שהוא אמור; יותר מ-600,000 חוברו מחדש מאז יולי 2024. לאף אחת מחברות השירות האלה לא חסרה פלטפורמת אנליטיקה. לכולן הייתה אחת. הפלטפורמה פשוט לא צפתה בדבר שהתקלקל.

הטעות שתמכתי בה זמן רב מדי

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

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

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

זיהוי אנומליות צריכה הוא בדיוק מה שמערכות ניהול נתוני המונים (MDMS) הקיימות כבר עושות. Oracle שחררה זיהוי אנומליות מבוסס בינה מלאכותית לפלטפורמת השירותים שלה ביוני 2025; SAP היא מובילה ב-IDC MarketScape בקטגוריה. הכלים האלה טובים במה שהם עושים — הם תופסים מונה שמדווח מספרים מוזרים. הבעיה היא שמונה שמתקדם לעבר מוות קושחה אינו מדווח מספרים מוזרים. הוא מדווח מספרים נורמליים לחלוטין, עד לרגע שבו הוא מדווח כלום. בנינו מחדש את הדבר שכבר היה קיים וירשנו מחדש את נקודת העיוורון שלו.

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

מה שה-MDMS אינו יכול לראות: שני אותות שבאמת חוזים כשל

שני אותות כשל שה-MDMS מפספס: מצב-טעינת הסוללה לפי קבוצה, ובלאי שקט של זיכרון NAND flash בזמן שהמונה עדיין מדווח

המפנה הגיע כשהפסקנו לשאול "האם הקריאה הזו חריגה?" והתחלנו לשאול "מה נשחק פיזית במונה, והאם נוכל למדוד את זה לפני שהוא נשבר?"

שתי תשובות היו חשובות.

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

השני הוא בלאי שקט של זיכרון NAND flash, וזה באמת שינה את האופן שבו אני חושב על כל הקטגוריה. מונים חכמים רושמים נתונים לזיכרון flash — כל קריאה, כל אירוע, במרווחים של 15 דקות עבור תגובת ביקוש. כל כתיבה שוחקת פיזית את התאים. היצרנים מגדירים במפרט אורך חיים של 20 שנה, אבל רישום בתדירות גבוהה שורף מחזורי כתיבה הרבה יותר מהר ממה שההערכות האלה הניחו. והנה החלק הערמומי: ככל שה-flash מתנוון, קריאות הצריכה השמורות נסחפות ב-2 עד 8% בזמן שהמונה ממשיך לדווח כרגיל. הרדיו עדיין מדבר. ה-MDMS מציג נקודת קצה בריאה ומתקשרת. בינתיים המספרים שגויים בשקט, מחלוקות חיוב מצטברות, ואמון הציבור נשחק — ועד שהמונה משתתק לחלוטין, ה-flash מנוון מכדי אפילו לקבל תיקון קושחה מתקן. היחידה הזו זקוקה למשאית ולהחלפה בעלות של 650 עד 1,400 דולר ליחידה.

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

"Oracle כבר עושה את זה. למה אתם בונים את זה?"

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

זו שאלה הוגנת, והתשובה הכנה היא שהשחקנים הוותיקים מצטופפים סביב בעיה אחרת. פלטפורמת Distributed Intelligence של Itron מרשימה באמת — יותר מ-16 מיליון מונים מאופשרים, יותר מ-100 מיליון נקודות קצה תחת ניהול, שותפות ממרץ 2026 עם NVIDIA להרצת בינה מלאכותית בקצה הרשת. ה-Revelo של Landis+Gyr, בשיתוף פעולה עם Sense, מבצע פירוק עומסים ברמת מכשיר ב-1 מגה-הרץ. Sensus השיקה את Evolve בתחילת 2026 כדי למצב מחדש מונים כחיישני רשת פעילים. כל התעשייה, כפי שהנושא הרשמי של DistribuTECH 2026 קבע, נעה "מ-AMI ל-AI."

אבל כל אחת ממחסניות האנליטיקה האלה עובדת רק עם נקודות הקצה של אותו ספק. הבינה של Itron רואה מונים של Itron. זו של Landis+Gyr רואה Landis+Gyr. חברות שירות אמיתיות מפעילות ציים מעורבים, שנצברו לאורך עשור של מחזורי רכש — חלקם Aclara, חלקם Itron, חלקם Sensus — ואין אנליטיקה של ספק בודד שמכסה את כולם. ואף אחד מהם, קנייני או לא, אינו מציע סימולציית קושחה טרום-פריסה מול הצי הספציפי והמזדקן שלך. הפער שהפך את פלאנו ללבנים מתות הוא, מבנית, חסר-בעלים.

השחקנים הוותיקים יגידו לך שמונה מדווח. כלי אבטחת ה-OT יגידו לך שהוא מריץ קושחה פגיעה. אף אחד מהם לא יגיד לך שהוא שלושה חודשים ממוות חומרה.

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

השולחן שבו הקושחה הולכת להיכשל בכוונה

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

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

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

האם תחזוקה חזויה לא פשוט אומרת יותר אזעקות שווא?

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

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

ניהול קושחה הפך זה עתה למסמך ציות

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

החל מ-1 באפריל 2026, NERC CIP-003-9 בתוקף. הדרישה R1, חלק 1.2.6 שלו מטילה בקרות אבטחה של גישה מרחוק לספק על מערכות סייבר של רשת בעלות השפעה נמוכה — כך מסווגים רוב המונים החכמים. במילים פשוטות: נתיב העדכון האלחוטי שאתה משתמש בו כדי לדחוף קושחה הוא כעת משטח בקרה מפוקח, והקנסות על טעות מגיעים עד מיליון דולר ליום. אותו ערוץ OTA שהפך את פלאנו ללבנים מתות הוא כעת גם ארטיפקט ציות שאתה חייב להציג לו ראיות.

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

יש תקן שקט יותר מתחת לזה שצוותי רכש שואלים עליו ולעיתים רחוקות מקבלים תשובה ישירה: IEC 62443, תקן אבטחת-הסייבר התעשייתי ל-AMI. מעט מאוד ספקי מונים חתרו להסמכה מלאה של IEC 62443 ברמת הרכיב — הקושחה עצמה. רובם מוסמכים ברמת המערכת ומשאירים את קושחת נקודת הקצה לא-מוסמכת, מה שאומר שהשכבה המדויקת שהפכה את פלאנו ללבנים מתות היא גם השכבה עם אישוש האבטחה הדליל ביותר. הפער הזה הוא הסיבה שאנחנו מבצעים ביקורות אבטחה ברמת הרכיב לרוחב שרשראות אספקה מעורבות של AMI, לא רק ה-head-end. בצידו השני של האוקיינוס האטלנטי, תקני Ofgem של בריטניה מחייבים כעת פיצוי אוטומטי — £40 לכל מקרה — עבור כשלי מונים באשמת הספק, המשולם בתוך 10 ימי עבודה. עלותו של מונה מת אינה עוד רק יציאת המשאית. היא הקנס, הפיצוי וממצא הביקורת.

מה הייתי אומר למנהל התפעול עם הדשבורד המיושן

אם הייתי חוזר עכשיו לאותו גיליון אלקטרוני של חותמות זמן מיושנות, הנה מה שהייתי אומר.

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

שוק המונים החכמים צועד לעבר 112 מיליארד דולר עד 2035, ובסיס המותקנים בצפון אמריקה כבר עומד על יותר מ-150 מיליון יחידות. כל אחת מנקודות הקצה האלה היא מחשב קטן עם סוללה מזדקנת ושבב flash מתבלה, יושב בצד של בניין, ממתין לדחיפת קושחה שנבדקה במקום שבו הוא אינו חי. הפלאנו הבא כבר מוקצה. השאלה הפתוחה היחידה היא האם מישהו מידל את הצי שעליו הוא עומד לנחות. אם אתה מעדיף לגלות על שולחן מאשר על הקירות של 73,000 לקוחות, זו המערכת שכדאי לבנות.

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

מחקר קשור

פורסם גם ב

בנו את ה-AI שלכם בביטחון.

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

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