軟件俱樂部的第一條規則：如果它沒有壞，不要談論它。但是，這在許多情況下是不可行的，例如當由于系統相關原因必須遷移運行良好的代碼時。這在安全關鍵系統中成為一個大問題，在這些系統中，更改代碼可能會觸發許多其他昂貴且有風險的活動。那么設計師該怎么做呢？這里解釋了如何衡量團隊的目標以及應該考慮哪些選項。

將安全關鍵型系統遷移到新技術可能是一個代價高昂且有風險的過程，開發人員應盡可能避免。然而，在某些情況下，出于財務或性能原因，遷移是可取的，或者由于硬件過時和新要求而不可避免。面臨遷移的開發人員需要仔細考慮系統更改的類型和程度，以比較內部活動與設計服務支持的好處。

部署在航空航天和國防領域的安全關鍵嵌入式系統的使用壽命通常超過單個系統組件的使用壽命。技術發展的快速步伐很可能在系統本身退役之前至少需要更改其中一個組件數年甚至數十年。反過來，此類硬件更改可能會引發開發人員需要將系統軟件遷移到新技術以確保持續的可維護性。

許多系統更改可以觸發軟件組件遷移。例如，外圍設備、通信總線或協議可能會發生變化，從而迫使代碼段遷移到新硬件。目標硬件或處理器可能會過時，就像基于 Intel 80860 的系統一樣，迫使整個系統軟件遷移到一個全新的平臺。可能會出現新的功能要求或認證標準，迫使系統設計結合以前不需要的實時操作系統 （RTOS）。同樣，新標準的實施、監管機構（如 FAA）對認證的新要求以及與新系統互操作的需求可能會產生將軟件遷移到新平臺的需求。

對開發環境的更改也可能引發遷移系統軟件的需要。開發和維護應用程序的主機過時，就像 VAX/VMS 主機一樣，當故障硬件的備件變得難以找到時，可能會迫使系統軟件遷移到新的開發工具。開發工具本身的過時或應用程序工具或語言專業知識的喪失可以啟動向新工具的遷移，以確保開發人員可以繼續支持已安裝的系統。同樣，RTOS 的過時可能會促使軟件遷移到新平臺。

即使是業務變化也會刺激遷移。與 RTOS 或其他軟件組件相關的生產版稅會影響系統的盈利能力。隨著利潤的縮小，開發人員可能會選擇遷移系統軟件以消除此類版稅。

降低成本和風險

無論是什么觸發了硬件或軟件的變化，遷移系統軟件都涉及成本和風險。軟件遷移不僅意味著更改軟件及其伴隨的引入錯誤的風險，還意味著重新測試和可能重新認證軟件。開發和測試工作的綜合成本可能相當可觀，尤其是對于必須滿足嚴格要求的安全關鍵系統。

遷移因素

成功遷移的一個關鍵——最小化成本和風險——是徹底了解遷移的影響。開發人員需要考慮許多因素，包括：

性能：新處理器/RTOS/平臺能否滿足系統的實時期限要求？

資源限制：軟件是否適合系統內存和寄存器可用性的限制？

RTOS 影響：將 RTOS 更改或添加到曾經裸板環境中可能會改變代碼執行順序或時序。它還可能增加系統復雜性并改變內存需求。

字長：字長的變化，比如從 16 位到 32 位，將如何影響現有代碼？計算算法、指針、計數器、上溢/下溢條件和執行速度會受到字長變化的影響。

工具可用性：主機或目標平臺的變化是否也意味著工具集的變化？用于創建和維護系統軟件的開發工具可能不適用于主機系統和目標處理器或 RTOS 的給定組合。

數據布局：編譯器將數據映射到寄存器和內存的方式各不相同。這種變化可能會導致與軟件中隱含或預期的映射發生沖突。

可擴展性：軟件遷移可能需要升級或增強功能以??滿足新要求。工具和系統資源需要支持此類增強功能。

可追溯性：將遷移的軟件追溯到原始版本的能力可以通過證明軟件沒有改變來幫助降低測試成本。

遷移過程中發生的變化越多，發揮作用的因素就越多。最低風險的遷移是只改變系統的一個方面，例如主機開發平臺。如果原始軟件開發系統和軟件工具在當前主機平臺（例如運行 Microsoft Windows 的 PC）上可用，則這是可行的。僅更改開發主機對系統和軟件的其余部分的影響很小。

開發人員應該尋求創造性的方法來將更改的數量保持在最低限度。例如，如果新主機平臺上沒有開發工具，則仿真可以提供切換工具集的替代方法。在 PC 上運行的 VAX 仿真器已被證明成功地允許繼續使用工具，并且由此生成的二進制目標代碼通常與原始代碼相同。工具、源代碼和目標代碼沒有改變，減少了重新測試和重新認證的需要。

工具更改需要編譯器專業知識

當工具集必須改變時，開發人員面臨著額外的挑戰。編譯器將源代碼映射到底層硬件結構的方式各不相同，例如內存尋址和寄存器使用。除非開發人員仔細約束編譯器的行為，否則這些變化可能會導致目標代碼發生變化。充其量，這會觸發重新測試并可能重新認證軟件的需要。在最壞的情況下，這些更改可能會在執行期間導致意外且可能存在缺陷的系統行為。

在不引起其他更改的情況下更改工具集要求開發團隊具有編譯器行為方面的專業知識，而這正是應用級工程師通常缺乏的專業知識。為了避免花費時間和精力來獲得所需的技能，開發團隊可以向外部尋求幫助。設計服務組織通常具有使用各種工具集的經驗，并且可以將這些經驗用于確保工具更改不會觸發軟件更改。

設計團隊應盡可能避免一些更改，例如將應用程序從舊式編程語言轉換為當前編程語言。團隊應該利用舊語言和新目標硬件的開發系統，而不是轉換。這將并發更改和風險的數量限制在兩個：開發系統和目標硬件。

改變語言涉及許多可能的陷阱。生成的應用程序將與原始應用程序不同，需要進行昂貴的重新測試和重新認證。其他因素也起作用。生成的代碼將具有不同的布局，并且可能不再適合可用內存；數據布局將不同，不再正確映射到底層硬件；性能和時間方面將發生變化。應用程序必須在源代碼級別進行修改，這將需要培訓軟件工程師使用新的編程語言以及應用程序的設計和內部工作。

盡管如果沒有一個程序員接受過應用程序編程語言的培訓，遷移到一種新語言可能很誘人，但這應該是最后的手段。在采取這條路線之前，請考慮用舊語言培訓程序員。精通 Java 或 C++ 等相對復雜的當前語言的程序員不會發現學習另一種語言是不可逾越的。

設計服務提供專家協助

另一種可能性是聘請提供必要語言專業知識的設計服務。對于針對軍事和航空電子系統的 Ada 和 JOVIAL 等專業語言，設計服務提供商通常在應用領域和語言方面擁有豐富的經驗，包括滿足安全關鍵系統設計需求的經驗。這使他們能夠快速深入了解系統軟件，并提供開發團隊所需的維護和升級支持。

如果歸根結底必須廢棄原始語言，系統設計人員可以使用翻譯工具部分更改語言。然而，沒有任何工具可以完成完整的工作，并且轉換后的源程序的可讀性可能會受到質疑。在可能的情況下，開發團隊應努力僅在絕對必要的部分更改語言。

實現此目的的一種方法是使用支持新舊目標語言并可以混合語言的工具集。這允許團隊保持原始代碼中仍然可用的部分完整，并將語言更改限制在滿足新要求所涉及的部分。

這種混合語言工具的一個關鍵部分是調試器。雖然許多編譯器可以組合不同語言的代碼段，但大多數調試器工具一次只能處理一種語言。這意味著開發人員必須同時調用多個工具來查看代碼段之間的交互，而這些工具很少以協調的方式交互或交換信息以幫助將目標代碼與多種語言源相關聯。DDC-I，??s OpenArbor等工具允許從一次啟動中進行混合語言調試，可以顯著減少調試時間并更容易檢測交互錯誤。

無論是否涉及語言更改，遷移安全關鍵系統軟件都是一項復雜的任務，存在許多潛在的陷阱。硬件、主機、目標、工具和語言的每次更改都會帶來復雜性，并可能會強制進行額外更改，從而導致后果升級。通過最大化遺留工具和代碼重用，應盡可能避免遷移中固有的成本和風險。當需要更改時，仔細選擇新工具并戰略性地使用經驗豐富的設計服務可以降低軟件遷移風險和成本。

審核編輯：郭婷