למה מוצר "נתקע" בכלל

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

איך watchdog עובד בפועל

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

הטעות הנפוצה ביותר היא לרפרש את ה-watchdog מתוך פסיקת טיימר. פסיקות ממשיכות לרוץ גם כשהלולאה הראשית תקועה — וכך המנגנון מדווח "הכול תקין" בזמן שהמוצר מת בפועל. ליטוף נכון נעשה רק מהלולאה הראשית, ורק אחרי שבדקנו שכל המשימות הקריטיות אכן התקדמו. במערכת עם RTOS נהוג שכל משימה מדווחת דגל משלה, ומשימת פיקוח מלטפת את ה-watchdog רק כשכל הדגלים התקבלו — עוד סיבה לבחור נכון ארכיטקטורה, כמפורט בRTOS או Bare Metal.

התאוששות היא יותר מאיפוס

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

  • למה אופסנו? רוב המיקרו-בקרים שומרים את סיבת האיפוס בְּרגיסטר ייעודי: הפעלה רגילה, נפילת מתח, watchdog. קושחה טובה קוראת את הרגיסטר בעלייה, רושמת את הסיבה ביומן לא-נדיף ומדווחת לענן. כך מגלים תקלות שטח לפני שהלקוח מתקשר.
  • באיזה מצב נחזור לעבוד? מוצר ששולט במנוע, בגוף חימום או בשסתום חייב לחזור למצב בטוח מוגדר, לא להמשיך מאיפה שנעצר. יש לשמור הקשר קריטי בזיכרון לא-נדיף, עם בדיקת תקינות (CRC) כדי לא לשחזר נתונים פגומים.
  • מה עושים כשהאיפוסים חוזרים? איפוס בודד פותר תקלה חולפת; איפוס בלולאה מסתיר באג אמיתי. מונה איפוסים רצופים שמעביר את המוצר למצב בטוח מוגבל אחרי שלושה-ארבעה ניסיונות — ומדווח החוצה — עדיף על מוצר שמהבהב לנצח.

שכבות הגנה נוספות

watchdog הוא שכבה אחת מתוך כמה שנהוג לשלב:

  • Brown-out detection — איפוס מסודר כשהמתח צונח, במקום ריצה במצב לא צפוי שמשחית זיכרון.
  • Window watchdog — גרסה קפדנית שמתריעה גם על ליטוף מוקדם מדי, סימן לקוד שרץ לא כמתוכנן.
  • Watchdog חיצוני — רכיב עצמאי נפרד מהמיקרו-בקר, שממשיך להשגיח גם כשהמנגנון הפנימי הושבת בטעות בקונפיגורציה או נפגע יחד עם המעבד. במוצרים קריטיים — רפואיים, תעשייתיים, מערכות בטיחות — נהוג לשלב את שניהם; מדובר ברכיב של שקלים בודדים.
  • טיים-אאוט בדרייברים — כל המתנה לרכיב חיצוני (חיישן I2C, מודם) חייבת גבול זמן ונתיב יציאה, כדי שתקלת רכיב לא תגרור את כל המערכת.
  • Bootloader עמיד — אם עדכון קושחה נקטע באמצע, המוצר חייב לחזור לגרסה תקינה ולא להפוך ללבנה. כך בדיוק פועל Bootloader במיקרו-בקר, והוא קריטי במיוחד במוצרים עם עדכוני תוכנה מרחוק.

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

איך בודקים שזה באמת עובד

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

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

רוצים להפוך רעיון למוצר? צרו קשר עם צוות פרוג'קטס האוס בע"מ – טלפון: 054-8936922 | דוא"ל: info@projects-house.com – ונשמח ללוות אתכם משלב הרעיון ועד המדף.