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

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

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

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

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

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

降低成本和風險

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

移徙因素

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

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

資源限制：軟件是否適合系統(tǒng)內(nèi)存和寄存器可用性的限制？

RTOS 影響：更改 RTOS 或?qū)?RTOS 添加到曾經(jīng)裸露的板環(huán)境中可能會改變代碼執(zhí)行順序或時序。它還可能增加系統(tǒng)復雜性并改變內(nèi)存要求。

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

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

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

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

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

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

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

工具更改需要編譯器專業(yè)知識

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

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

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

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

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

設計服務提供專家協(xié)助

另一種可能性是聘請?zhí)峁┍匾Z言專業(yè)知識的設計服務。對于針對軍事和航空電子系統(tǒng)的專用語言，如Ada和JOVIAL，設計服務提供商通常在應用領(lǐng)域和語言方面擁有豐富的經(jīng)驗，包括安全關(guān)鍵系統(tǒng)設計需求的經(jīng)驗。這使他們能夠快速深入了解系統(tǒng)軟件，并提供開發(fā)團隊所需的維護和升級支持。

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

圖1

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

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

圖2

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

審核編輯：郭婷