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

כשלים? אילו כשלים?

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

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

איך לחשוב על כשלים

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

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

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

חיי כלב

הטריגר לפוסט הזה היה מאמר בן כמה שנים של ג'ק גנסל, Great Watchdog Timers For Embedded Systems. מאמר זה בוחן את עצם הרעיון של watchdog, מעין מנגנון שמאתחל את המערכת אחרי זמן קצוב אם זו לא מצליחה מסיבה כלשהי להתחיל מחדש את הספירה לאחור.

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