火星探路者太空船上的軟體到底怎麼了?

dryrun發表於2013-07-11

【感謝@dryrun 的熱心翻譯。如果其他朋友也有不錯的原創或譯文,可以嘗試推薦給伯樂線上。】

火星探路者(Mars Pathfinder)是一艘在1997年攜帶探測車登陸火星並建立基地的美國太空船。它包括命名為卡爾薩岡紀念站的登陸者,和一輛重量很輕 (10.6公斤/23磅),命名為旅居者號的輪型機器人火星車。這艘太空船於火星全球探勘者號發射一個月之後的1996年12月4日由德爾它 II發射,並於1997年7月4日於火星上稱為歐克西亞沼區的克里斯平原阿瑞斯谷著陸。

圖1:旅居者號火星車

火星探路者著陸後﹐開始把資料傳送回地球。幾天後,資訊和影象傳送就被一系列的總系統復位所中斷。對於軟體工程師來說,這個問題是被如何診斷和解決的,仍然是一個引人入勝的故事。【1】

 

診斷問題

探路者號的應用程式是由 VxWorks 實時作業系統(RTOS)來排程。由於VxWorks提供優先順序搶佔的執行緒排程,依據相對緊迫性,具有優先順序執行緒的任務會被執行。

氣象資料採集任務作為一個普通的、低優先順序執行緒執行,並且使用互斥鎖定(mutexes)來同步的資訊匯流排。其它高優先順序的執行緒在必要時會獲得優先權,其中包括一個非常高優先順序的匯流排管理任務,它也以互斥鎖定來訪問匯流排。不幸的是,在這種情形下,一個長期執行的、具有比氣象任務更高、但是比匯流排管理任務更低優先順序的通訊任務,阻止了匯流排管理任務的執行。

不久,一個看門狗定時器注意到匯流排管理任務已經很長時間沒有被執行了,一定是出了什麼問題,所以強制總系統復位。(後來工程師們承認在飛行前測試時已經發現系統復位。他們把這些復位歸類於硬體故障,而去專注於關鍵任務――登陸軟體。)

 

尋求解決方案

工程師們瘋狂的工作在實驗室複製品上去診斷和解決這個問題,最終發現了優先順序反轉。當一個高優先順序任務間接地被一個“反轉”了相對優先順序的中等優先順序任務優先搶佔時,則優先順序反轉發生(見圖2)。這個顯然違反了優先順序模型――高優先順序任務只能被更高優先順序的任務阻止執行,或者被能迅速完成共享資源使用的低優先順序任務短暫地阻止執行。

Mars Pathfinder spacecraft priority inversion1

圖2:優先順序反轉

為了解決這個問題,他們開啟了一個布林引數,來指示是否應該進行互斥鎖定的優先順序繼承。 上述的互斥鎖定已經把該引數關閉;如果開啟它,優先順序反轉就能被阻止。

根據優先順序繼承,當高優先順序任務請求訊號(semaphore)時,持有訊號的任務優先順序繼承高優先順序任務的優先順序。在圖2中,當任務“high”請求訊號時,任務“low”將繼承任務“high”的優先順序。這使得“low”能優先搶佔“medium”。

造成問題(對其它兩個也可能造成同樣的問題)的互斥鎖定的初始化引數儲存在一個全域性變數中,其地址放在發射軟體的符號表裡。因為VxWorks包含一個C語言直譯器,允許開發人員輸入和執行C表示式和函式來進行系統除錯。它可以給太空船上傳一個簡短的C程式。在解釋C程式時,可以改變這些變數的值從假(FALSE)到真(TRUE)。這就杜絕了系統復位問題。

 

工程師們學到了什麼?

  • 只有對實際系統行為的詳細追蹤,才能捕獲和識別錯誤執行序列。而對一個不能追蹤的黑盒子來說,是無法診斷的;
  • 系統中具備除錯工具是非常重要的。如果不能修改系統,則問題無法修正;
  • 花費額外的時間確保在測試階段的優先順序繼承正確性,甚至犧牲一些本來非常寶貴的額外效能開銷。

 

解決方案來源

當主講人提到一份論文――它第一個識別優先順序反轉問題,並且提出瞭解決方案。特別的事發生了――令人驚訝的是,作者們都在房間裡,收到了熱情的接待。論文原文是:

L. Sha, R. Rajkumar, and J. P. Lehoczky. Priority Inheritance Protocols: An Approach to Real-Time Synchronization. In IEEE Transactions on Computers, vol. 39, pp. 1175-1185, Sep. 1990.

【1】本摘要根據麥克•瓊斯(Mike Jones)於1997年12月所記錄的風河系統(Wind River Systems)公司技術長大衛•維爾納(David Wilner)在IEEE實時作業系統研討會上的專題演講。

(全文完)

相關文章