החומר המופיע בעמוד זה פורסם לראשונה בכתב העת "הבטים בהוראת מדעי המחשב" גליון יולי 1998  עמודים 20-22

לא ניתן לעשות שימוש מסחרי בחומר זה ללא רשות בכתב מן המחברים או מערכת כתב העת

ה"באג" שחיסל משגר

פרופ' מוטי בן ארי
המחלקה להוראת המדעים, מכון ויצמן למדע

moti.ben-ari@weizmann.ac.il

 

מבוא

ב- 09:34 בבוקר מעונן חלקית של הרביעי ביוני 1996 ניתן האות לשיגור המשגר הצרפתי החדש אריאן 5 ממתקן קורו בגויאנה באמריקה הדרומית. כעבור 37 שניות המשגר נטה על צידו והחל להתפרק. מנגנון הבטיחות של המשגר זיהה את ההתפרקות ויזם פיצוץ כדי למנוע נזק ונפגעים בסביבה. וועדת החקירה שמונתה על ידי סוכנות החלל האירופאית קבעה שגורם התאונה היה "באג" בתכנה. זהו סיפורו של ה"באג".

 

למה זה מעניין?

תלמידים ובעלי מחשבים אישיים אחרים התרגלו למידה רבה של סובלנות כלפי תקלות בתכנה. אתה פשוט מסנן קללה עסיסית ולוחץ על ctrl-alt-del . כשלון השיגור גרם להפסדים של מאות מיליונים של דולרים, עיכוב של שנה בתכנית החלל האירופאית וביזיון מתוקשר היטב! המעניין במקרה של האריאן הוא לא בשגיאה השטותית בתכנות, אלא הכשלים  המרובים בתהליך הפיתוח שאיפשרו לשגיאה קטנה לגרום לתאונה קשה כל כך. שיטות העבודה הנכללות תחת הכותרת הנדסת תכנה הומצאו כדי לאפשר פיתוח מערכות עתירות תכנה אמינות, ובמקרה זה נעשו מספר קיצורי דרך שלא היו מוצדקים. (בהקשר זה ראוי להזכיר את השיטות להבטחת אמינות תכנה שסיפר עליהן פרופ' אמיר פנואלי בגליון הקודם.)

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

 

סליחה קצת פיסיקה

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

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

דרישות הדיוק מחייבות בקרה ממוחשבת - לא אדם הנוהג עם "ג'ויסטיק"! השאלה היא: איך יכול המחשב לדעת אם יש סטיות מהמסלול המתוכנן? יסתכל מהחלון על העננים?

 

משגרים משתמשים ב-"מערכת ניווט אינרציאלי" (להלן מנ"א). מאחורי שם מפחיד זה מסתתר רעיון הדומה לשיטה פשוטה שהיתה בשימוש לניווט ספינה בים הפתוח לפני המצאת אמצעי הניווט המודרניים. אתה מתכנן מסלול לפי מרחק ובודק את ההתקדמות לפי  זמן ומהירות. למשל, אם עליך לשוט 100 ק"מ ואז לפנות צפונה, אפשר למדוד את המהירות כל חמש דקות ולחשב את ההתקדמות. נניח שהמהירויות שנמדדות עד עתה הן: 10, 12, 9, 11 ו- 12 קמ"ש. המרחק שעברת   הוא(12+11+9+12+10)*(5/60) = 4.6  ק"מ ב25- דקות, ועוד דרך ארוכה לפניך. משגר הטס באוויר חייב להתחשב בשלושה ממדים ובשלושה כיוונים של הטייה אבל העקרון דומה: שימוש בתאוצות ומהירויות זוויתיות שניתן למדוד אותן באמצעות מיכשור מתאים, וחישוב (אינטגרציה) כדי לקבל את מקומו המדוייק של המשגר. החישוב נעשה עשרות פעמים בשניה ותוצאות החישוב מועברות למחשב המרכזי של המשגר המתרגם את הסטיות מהמסלול להוראות ניהוג:

 

אז מה קרה שם?

השלבים שהביאו להתפרקות המשגר היו:

        1.          במהלך החישוב של המנ"א היתה הוראה להמיר מספר ממשי של 64 סיביות למספר שלם של 16 סיביות. אולם, המספר הממשי היה גדול מדי וההמרה גרמה לשגיאת ביצוע.

        2.          השגיאה גרמה להפסקת הביצוע של התכנית במנ"א, בדומה ל runtime error בטורבו פסקל.

        3.          מחשב הגיבוי ביצע אותו חישוב למקרה של תקלה, אבל מחשב זה נעצר בגלל אותה שגיאה.

        4.          החמרה של המנ"א שלחה הודעת שגיאה למחשב המרכזי כדי להודיע על הפסקת ביצוע התכנית.

        5.          המחשב המרכזי התיחס להודעת השגיאה כאל נתוני אמת ופקד על נחיר הפליטה לבצע הטייה מקסימלית לצד אחד!

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

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

 

למה זה קרה?

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

        1.           ה"באג" היה בתכנה המתבצעת לפני השיגור לצורך כיוון המערכת. באריאן 4 היתה סיבה כלשהי להמשיך להריץ תכנה זו בזמן השיגור, אבל הסיבה התבטלה עם המעבר לאריאן 5. במונחים שלנו, הבעיה האלגוריתמית היתה שונה, אך התכנית לא שונתה בהתאם.

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

        3.          ההמרה ממספר של 64 סיביות למספר של 16 סיביות היא למעשה זימון של פונקציה. לפני זימון של פונקציה, חובה לוודא האם טענת הכניסה מתקיימת. אפשרות אחת היא לתכנת משפטי IF  לבדיקה. אפשרות אחרת היא לטעון שתנאי הכניסה חייב להתקיים. למשל, ניתן לזמן ללא בדיקה פונקציה לחישוב שורש של a2+b2 כי ביטוי זה חייב להיות לא-שלילי. כדי לחסוך בזמן חישוב, העדיפו בחלק מהמקרים להעדיף טענה פיסיקלית ולא בדיקה.בתכנות. בגלל השינוי המסלול, טענת הכניסה לפונקציה לא היתה נכונה.

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

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

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

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

 

מה אפשר ללמוד מהכשלון של האריאן 5?

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

 

רשימת מקורות

http://www.esrin.esa.it/htdocs/tidc/Press/Press96/ariane5rep.html

 

אתר המרכז הארצי

אתר הבטים

חזרה לתחילת העמוד