​2025年2月26日，NASA發射月球軌道探測器“月球探路者”Lunar Trailblazer。這顆小衞星由美國宇航局JPL管理、加州理工學院領導，任務目標為獲取月球水資源分佈數據，繪製月球水資源分佈圖。探測器成功完成發射與部署，並在入軌初期與地面建立通信。然而僅在發射一天後，航天器電源系統出現異常，通信鏈路間歇中斷，任務控制中心失去了與探測器的聯繫。2025年8月4日，NASA宣佈無法恢復與探測器的通信，任務徹底終止。

​

事故發生1年後，2026年2月27日，調查報告公佈。報告指出，這起耗資7200萬美元的任務失敗根本原因，是航天器的太陽能板控制軟件出現了致命錯誤——本應將太陽能電池板對準太陽以獲取能源，卻將其指向了完全相反的方向，也就是偏離約180度。同時，航天器自主故障管理系統在異常狀態下執行了一系列不利動作，疊加姿態未鎖定狀態，使系統逐步喪失能量閉環能力，最終失去控制。

該航天器由Lockheed Martin洛克希德·馬丁公司研製。NASA審查小組認定，該公司未在發射前對太陽指向軟件進行充分測試，也就是説從技術層面上看，這是一次由軟件邏輯問題引發的系統級失效。

01.姿態控制失控後的連鎖反應

在月球軌道器運行初期，姿態獲取與太陽指向控制是確保能量閉環建立的關鍵步驟。姿態未鎖定時，航天器可能進入低功率模式併產生緩慢翻滾。此時，太陽能板必須在姿態動態條件下持續維持有效入射角，否則功率輸入將迅速下降。

調查顯示，太陽指向算法目標向量發生反向計算錯誤。單從代碼層面看，這類錯誤並不複雜，但其工程後果取決於系統耦合關係。若姿態已經穩定，方向誤差可能被部分抵消；但在姿態未鎖定、功率受限、自主控制邏輯尚未完全建立閉環的狀態下，該誤差會迅速放大。

飛行系統中的控制邏輯並非孤立存在。姿態控制、電源管理、熱控策略與通信調度共享統一的時間基準與功率預算。當能量輸入下降，姿態控制能力隨之減弱；姿態不穩定進一步削弱太陽入射效率，形成負向反饋迴路。若自主故障管理策略在此過程中未能識別真實問題來源，反而執行進一步限制動作，則系統將失去恢復路徑。

本次事件呈現的並非單點模塊失效，而是多子系統動態耦合後連鎖演化的結果。

02.軟件規模增長與驗證覆蓋不足的結構性矛盾

近年來，低成本深空任務逐漸成為主流模式，然而控制成本並不意味着系統複雜度降低。現代小型軌道器的軟件系統通常涵蓋實時操作系統調度、姿態控制算法、電源分配策略、故障檢測與自主恢復邏輯、通信管理等多個模塊，各模塊之間存在高度交互。

在這種結構下，單模塊功能驗證並不能充分代表系統穩定性。若測試環境未構建完整動力學模型、電源模型與姿態模型的聯合仿真，方向邏輯誤差可能不會在地面階段暴露。尤其在默認姿態初始條件正確的情況下，部分錯誤路徑可能被隱藏。

如同本次事故調查報告所指出的那樣，洛克希德·馬丁公司未在發射前對太陽指向軟件進行充分驗證，其背後更值得關注的問題是：驗證體系是否足以覆蓋跨系統耦合場景。工程實踐中，測試通常按照子系統劃分：姿態控制單獨驗證、電源管理單獨驗證、故障管理邏輯獨立測試，然而真實運行環境並不存在這種隔離。所有控制邏輯在統一時序下同時生效，其穩定性取決於整體動態行為，而非局部正確性。

當軟件規模持續擴大，而驗證體系仍停留在模塊級分割階段時，跨系統耦合問題往往難以在早期暴露，其風險可能在系統集成階段甚至實際運行環境中才顯現，代價也隨之成倍放大。

03.並非航天特例：複雜嵌入式系統的共同風險

從技術角度看，本次任務的失效過程呈現出複雜嵌入式系統常見的演化特徵。首先，問題源自邏輯層面，而非硬件損毀。其次，異常在初期並非完全失控，而是在多個子系統相互作用下逐步惡化。再次，自主故障管理邏輯未能建立有效恢復路徑，反而與主控制邏輯形成衝突。

在複雜裝備領域，這種失效模式並非孤例。飛控系統、電池管理系統、工業控制器乃至低空飛行器平台均面臨類似挑戰。隨着裝備形態向軟件主導轉型，控制邏輯與狀態機數量持續增加，若無法在研發階段對這些組合進行充分推演，系統穩定性將越來越依賴真實運行反饋。

軟件錯誤本身或許較難避免，但錯誤是否能在發射前或量產前被識別，取決於驗證環境的真實性與覆蓋深度。

04.解決方案

從工程視角看，月球探測者的任務失效並不僅僅是一次軟件缺陷暴露，更反映出複雜系統驗證能力與軟件複雜度之間的矛盾。問題核心不在於某一算法方向參數出現偏差，而在於該偏差未能在系統級耦合環境中被充分識別與推演。

事故調查公佈後，洛克希德·馬丁公司與NASA均表示已從此次失敗中吸取經驗。NASA稱：“儘管任務損失令人遺憾，但為未來低成本任務提供了重要經驗。”洛克希德·馬丁則承認，低成本任務在資源約束條件下本身面臨更高風險，並提出將從故障管理架構、飛行軟件實現方式以及發射前測試流程三個方面強化核心設計原則，同時在風險接受與可靠性之間取得更合理的平衡。

從官方迴應可以看出，改進的方向並不侷限於某一段代碼或某一次測試，而是指向更完整的系統級驗證能力。無論是優化故障管理架構，還是提升飛行軟件實現質量，本質上都離不開在地面階段對複雜系統行為的充分推演。這也再次凸顯出一個關鍵問題：在硬件尚未完全就緒之前，是否具備構建高保真虛擬環境並實現多系統協同運行的能力，往往決定了風險能否在早期被識別。

國產自主研發的天目全數字實時仿真軟件SkyEye，具備ARM、PowerPC、x86、DSP、MIPS、SPARC等多種處理器架構的指令級仿真能力，支持多架構處理器仿真和外設建模，可實現指令執行、總線通信、外設響應的高保真還原。藉助SkyEye，工程師無需等待物理硬件製造完成，就能提前在虛擬環境中調試飛控算法、任務規劃邏輯，甚至驗證推進系統的點火策略，顯著縮短研發週期，提高可靠性。

在此基礎上，多領域分佈式協同仿真平台DigiThread則能進一步擴展驗證深度。通過將推進系統模型、軌道動力學模型、通信鏈路模型與嵌入式控制軟件協同運作，可形成跨領域跨學科的驗證，而無需依賴真實發射環境驗證。