ב-Online
 
 
 
 
 
 
 
לפרק את הבייט 
מה באמת קרה על מאדים 
 
 קולאז` נוף מאדים שצולם ע``י Mars Pathfinder    צילום: NASA/JPL/Caltech    
לפרק את הבייט |
 

בשנת 1997, תקלת מחשב מסתורית איימה על הצלחתה של משימה לחקר מאדים. מה בעצם קרה שם?

 
 
 
 
 
 
 
 
 
 
 
זה היה אירוע ששווה להישאר ער כל הלילה בשבילו. ברביעי ביולי 1997, אחרי עשרים ואחת שנים בהן לא בוצעה שום נחיתה מוצלחת על פני המאדים ובתום מסע בן שבעה חודשים בחלל, הנחחת Mars Pathfinder ביצעה באופן מושלם את תמרון הנחיתה המורכב להפליא (שכלל מצנחים על-קוליים, רקטות בלימה וקפיצה מטורפת על כריות אוויר), פרשה את הלוחות הסולריים שהגנו עליה כמו עלי כותרת והחלה לשדר מידע מכוכב הלכת האדום. תמונת הנוף הפנורמית והצבעונית הראשונה הגיעה אי-שם לקראת הזריחה, שעון ישראל. כעבור יממה של בדיקות עצמיות ואיסוף נתונים יצא לדרכו גם הרובוט הממונע הקטן והעצמאי Sojourner, שבחן את האדמה והסלעים מקרוב. הכל תקתק כמו שעון, בדיוק לפי התוכנית. זה היה נצחון מזהיר לנאס"א, לטכנולוגיה ולחקר החלל.

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

מערכת הפעלה בזמן אמת

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

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

איך נוצר היפוך קדימויות

רובוט על מאדים
 רובוט על מאדים 
 צילום: GettyImages 
 
בכל מערכת מחשב קיימת מידה של תלות בין תהליכים שונים. לדוגמה, במחשב בנקאי, תהליך אחד יכול לכתוב מידע לקובץ (כגון העברת כסף מחשבון העו"ש לחברת כרטיסי האשראי), ותהליך אחר (המשתמש שגולש מהבית ובודק את מצב החשבון שלו באתר הבנק) קורא מידע מאותו הקובץ. אם שניהם יפעלו יחדיו, עלולה להיווצר בעיה גם מבחינה לוגית – המידע עלול להיות חלקי או משובש – וגם פיזית, משום שהדיסק הקשיח לא מסוגל לכתוב ולקרוא בו זמנית. במקרים כאלה משתמשים במנגנון תכנותי שנקרא Mutex – קיצור של Mutual Exclusion או "מניעה הדדית", מין "דגל" פשוט למניעת התנגשויות שמציין מתי משאב כלשהו נמצא בשימוש ומתי הוא פנוי. בכל רגע נתון, רק תהליך אחד יכול להשתמש במשאב, והוא "מרים" את הדגל עם תחילת העבודה ו"מוריד" אותו כשסיים. כל תהליך אחר שרוצה להשתמש באותו משאב חייב להמתין עד שהדגל יירד.

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

הפתרון והלקחים

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

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

לפירוט טכני ומדויק יותר של מה שקרה על מאדים, ראו כאן.
 
 
 
@@@@@@@@@@@@@@@@@@@ ilan @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
@@@@@@@@@@@@@@@@@@@ ilan @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
 
תגובות
הוסף תגובה0 תגובות
הוספת תגובה
מאת
 
נושא
 
תוכן
 
 
 
 
תודה! תגובתך התקבלה.
התגובה תתפרסם בכפוף לתנאי האתר.
 
 
 
 
 

כל הזכויות שמורות 2011 © נענע 10 בע"מ
 
 
 
 
כל הזכויות שמורות © Nana10 בע"מ
Video powered by