בתשובה לדב אנשלוביץ, 08/01/20 20:25
 |
|
 |
||
|
||||
 |
החזרת אותי לפתיל הזה ואני לא יודע אם אנחנו לא מסכימים על העובדות או רק על התיוג שלהן. הנה הסיפור כפי שאני מכיר אותו: איירבאס השיקה את פרויקט הדור החדש של משפחת 320 - ה 320neo - בדצמבר 2010. המיקוד של הדגם החדש היה על חסכון בדלק ועלויות אחזקה לעומת הדגם הקודם (ואכן בפועל הראה שיפור משמעותי של 15% בצריכת הדלק ובעלויות האחזקה), בעיקר על ידי שימוש במנועים חדשים. ביוני 2011 קיבל הדגם החדש כבר יותר מ 1000 הזמנות, מספר שיא למטוס מסחרי חדש. בואינג נכנסה לעמדת נחיתות בתחרות מול איירבאס והכריזה על השקת פרויקט מקביל עבור ה 737 באוגוסט 2011. תכנון של מטוס חדש מדף חלק, שנשקל ונדחה במשך כמה שנים, נזנח. כיוון שהחלה באיחור מול המתחרה, בואינג שאפה לקצר ככל האפשר את זמני הפיתוח והאישור על ידי הרשויות. בתהליך האישור המטרה העיקרית של בואינג היתה שהמקס יקבל את אותו Type rating [Wikipedia] של הדגמים הקודמים של 737. Type rating חדש היה דורש אימון ארוך של כל הטייסים שמיועדים להטיס את הדגם החדש, והיה מייקר את העלות שלו באופן שהופך אותו ללא תחרותי. המנועים הגדולים יותר של המקס מותקנים גבוה יותר וקדימה יותר מאשר בדגם הקודם. זה גרם להתנהגות האוירודינמית של הדגם החדש להיות שונה, מה שהיה מחייב Type rating חדש. על מנת שהדגם יקבל את אותו Type rating בואינג התקינו תוכנה שתגרום לו לחקות את ההתנהגות האווירודינמית של הדגם הקודם1. זוהי ה MCAS [Wikipedia] הידועה לשמצה. בואינג התייחסו ל MCAS כחלק ממערכת בקרת הטיסה והשמיטו אותה מה manual של המטוס ומחומרי ההדרכה, שוב על מנת שטייסים לא יצטרכו לעבור אימון מיוחד. בתהליך היישום והאישור של ה MCAS למקס היו מספר כשלים, שבמצטבר הפכו את ה MCAS לגורם סיכון גדול וחבוי במטוס, בלי שהטייסים שמטיסים אותו יידעו על קיומו. 1. בניגוד לגרסה המוקדמת, שקיבלה את אישור ה FAA, ה MCAS על המקס נכנסה לפעולה גם בכוחות G נמוכים. 2. התוכנה קיבלה מידע מחיישן זווית התקפה בודד בכל טיסה, מהשניים שמותקנים במטוס. תקלה בחיישן גרמה להפעלת ה MCAS באופן שגוי ולהתרסקויות. 3. התוכנה לקחה את השליטה מהטייס מבלי לאפשר ניתוק פשוט שלה, גם זה בניגוד לגרסה המקורית של המערכת שהותקנה במטוס קודם (KC-46, מטוס תדלוק של חיל האוויר) אלה העובדות הידועות לי. ועכשיו השאלה היא האם אנחנו מסכימים עליהן, ורק לא מסכימים על התיוג של הכשל כ"תקלת תוכנה". __________ 1 במקום הפתרון של שינוי אוירודינמי במטוס, שהעדיף טייס המבחן של בואינג. פתרון שאולי היה ארוך ויקר יותר לבואינג ואולי גם מסוכן לה מבחינת ה Type rating. |
 |
 |
 |
|
|
|
||
|
||||
|
הוויכוח בפתיל היה על שני עניינים. הראשון הוא האם אכן אפשר להגדיר את הכשל ב737 מקס ככשל בתוכנה כפי שטענת. העניין השני הוא האם באופן כללי תקלות תכנה קשות יותר לתיקון מתקלות חומרה כפי שטענת. התגובה האחרונה שלי עסקה בעניין השני, בהנחה (שאיני מסכים לה) שאתה צודק בעניין הראשון. אמרתי שגם אם אתה צודק בעניין הראשון זה לא גורר את זה שאתה צודק בעניין השני, כפי שניסית להסביר, וזאת גם בגלל שטעות היא להסיק מסקנות על סמך מקרים ספורים. איני מבין מדוע מצאת לנכון לספר את כל הסיפור מהתחלה. |
|
|
|
|
|
|
||
|
||||
|
אתה צודק. ההשוואה עם טויוטה לא היתה במקומה, וקשה ללמוד מהמקרה הספציפי על הכלל. כשסיפרתי את הסיפור מחדש התחוור לי שהתקלות בתכנון התוכנה, שהן מה שריסק בפועל את המטוסים, לא עמדו בפני עצמן אלא היו תוצאה של הבעיה העיקרית. הבעיה העיקרית היתה שהמטרה העליונה של בואינג היתה להכניס את התכנון של המקס לסד של "שמירת הדגם" הרגולטורית, וכל שאר השיקולים הפכו למשניים. בואינג לא ניסתה לעשות את המטוס הכי טוב שהיא יכולה, אלא את המטוס הכי טוב שהיא יכולה בלי לחרוג ממסגרת ה type rating של ה 737 הקודמים, וממסגרת הזמן. התוצאה היתה קטלנית. אז לקרוא לבעיות של המקס "תקלת תוכנה" כנראה נכון טכנית, אבל מגמד את האחריות של התאגיד לתהליך הפיתוח והאישור הרשלני שהביא לכשל. |
|
|
|
|
|
|
||
|
||||
|
לגזור ולשמור לפעם הבאה שמבקשים מכם תאימות באגים (bug to bug compatibility). | |
|
|
|
|
|
||
|
||||
|
לעניות דעתי "תקלת תוכנה" נשמעת כמו באג. אבל באג הוא רק סוג אחד של תקלות תוכנה - כשהתוכנה *לא* מבצעת את מה שהיתה אמורה לבצע. מהמעט שקראתי כאן בפתיל, נראה שהכשל המדובר הוא לא מהסוג הזה - התוכנה ביצעה את מה שהיתה אמורה לבצע, אבל תכנון התוכנה והגדרת הדרישות שלה לקו בחסר. אני לא קורא למצב כזה תקלת תוכנה - מאחר ובמקרה כזה של כשל בהגדרת הדרישות, הוא היה מיתרגם לכשל מערכתי (קטלני כמובן) בלי קשר לשפת התכנות, או אפילו למימוש, ויהא זה מימוש תוכנתי, חומרתי, עם כבלים מנחושת, עם גלגלי שיניים, עם מחשב קוונטי, וואטאבר. |
|
|
|
|
|
|
||
|
||||
|
אז כשל תכנוני? התוכנה ביצעה מה שהגדירו לה לבצע, וזה ריסק שני מטוסים (ועוד כמה כמעט-ים). ללא התוכנה לא היו התרסקויות. הכניסו אותה בתור קונץ-פטנט כדי לדמות את התנהגות הדגמים הקודמים של המטוס, במטרה להתחמק מאישור נרחב וארוך יותר של דגם חדש. אילו התוכנה היתה מקבלת הזנת נתונים משני חיישני זוית ההתקפה ביחד, משווה ביניהם וזורקת את הנתון של המקולקל, לא היתה בעיה. כמה זמן לדעתך אמור לקחת עדכון תוכנה כזה? |
|
|
|
|
|
|
||
|
||||
|
בהחלט כשל תכנוני. לגבי השאלה האחרונה - זה לא נשמע עדכון מסוכך, אבל בדרך כלל עדכון תוכנה במערכות קריטיות מצריך סבב בדיקות מחדש שיכול להימשך שבועות או חודשים. (ומי שתכנן מערכת שלא עושה את זה מלכתחילה קצת התרשל, בוא נאמר). |
|
|
|
|
|
|
||
|
||||
|
יש לך באג.. כאשר יש שני חיישנים שלא מסכימים ביניהם, אי אפשר לדעת מי מהם הוא המקולקל. בכל מקרה ממה שכתוב כאן נראה שהתוכנה כן קיבלה מידע משני החיישנים והיתה אמורה להתריע אם יש אי הסכמה בינהם. המחדל הוא מורכב יותר. |
|
|
|
|
|
|
||
|
||||
|
אני משוכנע שהמוחות המבריקים בבואינג יוכלו לתת לתוכנה פרמטרים לזהות מי החיישן התקול. התוכנה קיבלה מידע רק מחיישן אחד בכל פעם. היתה מערכת שבואינג מכרה כאופציה, שרק מתריעה אם יש חוסר הסכמה בין החיישנים (כוסות רוח למת). While it has defended its design, Boeing is working on an update for the 737 Max that will make the MCAS software less intrusive and will take a reading from more than one sensor...
a Boeing spokesperson defended the decision to use a single sensor to CNN: "Single sources of data are considered acceptable in such cases by our industry." |
|
|
|
|
|
|
||
|
||||
|
אצלנו אומרים: “באג בדיזיין, זיין בדיבאג”. | |
|
|
| חזרה לעמוד הראשי | המאמר המלא |
| מערכת האייל הקורא אינה אחראית לתוכן תגובות שנכתבו בידי קוראים | |
 RSS מאמרים |
כתבו למערכת |
אודות האתר |
טרם התעדכנת |
ארכיון |
חיפוש |
עזרה |
תנאי שימוש
|
© כל הזכויות שמורות |