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

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

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

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

對開發環境的更改也可能導致遷移系統軟件的需要。開發和維護應用程序的主機的過時（如 VAX/VMS 主機所發生的情況）可能會在難以找到故障硬件的備件時強制將系統軟件遷移到新的開發工具。開發工具本身的過時或應用程序工具或語言專業知識的喪失可能會啟動向新工具的遷移，以確保開發人員可以繼續支持已安裝的系統。同樣，RTOS 的過時可能會促使軟件遷移到新平臺。

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

降低成本和風險

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

移徙因素

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

性能：新處理器/實時操作系統/平臺能否滿足系統“??s”的實時截止時間要求？

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

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

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

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

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

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

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

遷移期間所做的更改越多，起作用的因素就越多。風險最低的遷移是僅更改系統的一個方面，例如主機開發平臺。如果原始軟件開發系統和軟件工具在當前主機平臺（如運行微軟Windows的PC）上可用，這是可行的。僅更改開發主機對系統和軟件的其余部分的影響最小。

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

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

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

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

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

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

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

設計服務提供專家協助

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

如果最終必須廢棄原始語言，系統設計人員可以使用翻譯工具部分更改語言（如圖 1 所示）。但是，沒有任何工具可以完成完整的工作，并且轉換后的源程序的可讀性可能值得懷疑。如果可能，開發團隊應努力僅在絕對必要的部分更改語言。

圖1

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

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

圖2

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

審核編輯：郭婷