將舊軟體遷移到現代計算機的歷程

在神盾系統現代化、虛擬化的過程中，如何把從1970年代累積下來的CMS-2語言撰寫的AN/UYK-7/43軍規電腦的指令集遷移到X86架構電腦上，是一項重要工作。在1990年代神盾Baseline 6到Baseline 7時期，雖然商規現成計算機硬體被引進神盾系統，但原本神盾系統最核心的程式如指揮與決策（C&D）、武器控制（WCS）仍然是跑在原本UYK-43軍規電腦上。1980年代推出的UYK-43軍規電腦的硬體組件生產廠商，進入2000年代以後基本消失，美國海軍只能從除役舊艦上回收堪用的軍規計算機組件，以支持仍在現役的美軍與盟邦系統裝備持續運作。因此，美國海軍終究必須把這些CMS-2撰寫的軟體遷移到現代商規電腦下。 

 這些CMS-2代碼加起來有上千萬行，要程式開發者直接以現代語言全部重寫並不可行，耗時太長且風險巨大。因此，美國海軍前後透過分階段的方式，先在維持舊軟體結構的情況下遷移到現代計算機上， 接著逐步將舊原始碼轉換成主流商規語言，並以現代資訊系統的方式「拆解」一個個龐大的舊軟體功能，轉型為現代的「微服務」形式。

神盾Baseline 7：模擬器出現

轉移CMS-2的源碼的最初方式是軟體模擬器（Emulator）。工程師透過撰寫軟體中間層，在現代電腦處理器架構上建立一個模仿UYK-43電腦的底層行為的「沙盒」（sandbox）， 包括UYK-43暫存器、內存定址方式和輸入/輸出（I/O）頻率，並以二進制翻譯器(Binary Translator)把當年UYK-7/32電腦的32 位元指令轉換成x86指令；如此，原有的CMS-2程式二進制執行檔（binary）不經任何修改，就能直接跑在現代處理器上。

最早約在神盾Baseline 7的階段，美國海軍就曾經開發基於VME總線的處理單元，以解決老舊UYK-43電腦商源消失的問題。這是一種特殊機櫃，裡面插滿基於商規處理器 （通常是 PowerPC 或早期 Intel 架構）的SCB處理板，上面的處理器運行UYK-43電腦 的模擬器，然後執行神盾核心邏輯的舊CMS2執行檔。如此，一部佔用龐大機櫃空間的UYK-43電腦，就被機櫃裡一張SCB處理板取代。此種較早期的UYK-43模擬方案也曾 出口到盟邦，用來執行艦載標準SM-2防空飛彈的WDS MK14射控軟體（舊型軍規電腦時代撰寫），例如加拿大部落級（Iroquois class）的TRUMP升級項目，或韓國KDX-2驅逐艦。

神盾Baseline 8/TI-08：大規模遷移的開始 

神盾Baseline 8/T-08 時期，美國海軍引進純商規的刀鋒伺服器組，正式開始將UYK-7/43軍規電腦運行的舊有程式邏輯全面搬遷。為了讓軟體遷移作業盡量平順且快速地完成， 工程師使用前述的模擬器（Emulator）與跨編譯（Cross-Compilation）兩種策略。

1.模擬器（Emulator）：由於TI-08時代引進的商規伺服器的處理器頻率（GHz 等級）遠高於當年UYK-43（僅有MHz級），且暫存器、記憶體容量等資源也更豐富，因此這些軍規時代的舊程式在現代CPU 執行一個模擬循環的速度，比在真實UYK-43硬體快上千倍。這意味著舊程式碼在模擬器裡跑得比在原生機器更快更平順。

2.跨編譯器(Cross-Compilers)：如果全部用模擬器跑舊機器上的Binary檔雖然最省事，但這麼做會浪費掉TI-08伺服器90%以上的算力，包括模擬層的額外開銷（overhead）， 且無法平行運算，浪費現代伺服器CPU的多核心優勢。 因此，美國海軍開發了專門的CMS-2跨編譯器，能將CMS-2程式語言編譯成可在現代Intel x86處理器、Linux作業系統的二進位（binary）執行檔，不需要透過模擬器， 以「原生速度」在現代CPU上執行。由於CMS-2是一種相對高階的語言（相對於組合語言），跨編譯器可以將其邏輯精確地映射到C語言或x86指令集上。在TI-08時代的跨編譯器是將舊的CMS-2程式邏輯一一對應來轉換，不作任何結構變更。

在當時，對於運算密集，且與硬體關連度低的程式如軌跡追蹤（Tracking）、複雜彈道計算，就以跨編譯器編譯成現代計算機的執行檔，直接跑在TI-08伺服器的Linux 環境中，效能比先前跑在UYK-43相比提升了數百倍。而某些與舊硬體（如特定的顯示介面或過時的通訊協定）高度綁定的邏輯，因為重寫或編譯後的調整成本太高， 所以不作任何更動，直接以UYK-43的模擬器執行原本執行檔。

神盾Baseline 9/TI-12：將CMS-2原始碼轉換成現代語言/先進跨編譯

作為過渡時期的應急措施，模擬器與跨編譯轉換證實能穩定平順地運行舊程式，然而TI-12/16進入全開放架構與全商規伺服器時代，就面臨三個瓶頸：

1.模擬器只能以原本UYK-43的方式執行軟體，無法利用現代處理器的技術如多核心（Multi-core）平行處理，或者針對深度學習（ML）領域的GPU或進階向量擴充指令集（Advanced Vector Extensions，AVX）。

2.用模擬器代表跳過原始檔而直接執行原本的編譯檔，萬一發現原始邏輯仍然有Bug，則很難在二進位層級進行修正，逃不過需要在現代機器上重新以商規語言（C++等）撰寫的步驟。

3.舊的程式只能對接當年的AN/SPY-1相位陣列雷達，而新的AN/SPY-6雷達的數位數據量龐大，負責處理雷達信號的舊程式邏輯根本跑不動。

因此，當美國海軍建立通用原碼庫（Common Source Library，CLS）之後，也花費時間將過去累積、為UYK-7/43軍規電腦撰寫的數百萬行CMS-2程式進行重構，使之充分融入現代的計算機架構中。 這並不是單純地以人工把舊的CMS2代碼改寫成現代高階語言C++，而是大量自動化的轉換。這些作業大致分成

1.代碼轉譯重構 (Transpilation)：工程師開發先進的語言轉譯器，將原本的 CMS-2 原始碼轉換為C++ 或ADA 95/2005語言。 然後針對現代Intel Xeon (x86_64)處理器架構進行原生編譯。轉譯器完全繼承 UYK-43時代經過實戰驗證的演算法邏輯（例如預測反艦飛彈彈道等），並重新封裝成現代物件導向的類別（Classes）與物件（Objects） 。

2. 原生編譯(Native Compilation) 先前在TI-08時，跨編譯器只能將原本CMS-2程式邏輯一一對應地編譯成目標機器的執行；而到TI12、TI16時，更新型的跨編譯器不僅編譯代碼， 還能協助進一步將原本CMS-2的邏輯重構成現代C++ 類別。

在這些策略下，原本CMS2時代的程式碼能以最高效能直接在現代處理器硬體上跑，不再需要虛擬UYK-43的解釋層。 以上兩種轉譯，就是把舊程式納入CLS的起點。

神盾Baseline 9C2/TI-16：軟體功能拆分/微服務化 

到神盾Baseline 9C2、TI-16硬體架構時，神盾軟體進一步微服務化 (Microservices)。例如，原本一個巨大的指揮決策（C&D）程式邏輯， 被拆分成數百個各自獨立的微服務（如目標追蹤、威脅分析，或者針對某種新型態威脅如無人機的功能，都個別封裝成一個微服務），每個微服務封裝在輕量級虛擬容器（Container）上在虛擬層執行。利用類似Docker和 Kubernetes (K8s) 的容器編排器管理技術，TI-16架構下的虛擬軟體層具備彈性的自動擴縮容 （Auto-scaling）管理能力； 一旦當下戰場環境需要（如雷達探測大量目標），系統能自動啟動更多對應微服務的容器實體（instances）來處理這些突然湧現的接戰需求，並且裁減當下情況不需要的容器實體。

所以在TI-16，已經完全沒有任何CMS-2時代的舊二元執行檔殘存，原本CMS-2的邏輯都已經全部轉成現代C++ 代碼。雖然經過現代程式語言的包裝， 但許多源於UYK-7時代初期神盾系統中的核心數學公式依舊存在，並以比當年軍規電腦上快得多的速率精確運行著。

而虛擬化最大的隱憂是延遲（Latency）」。如果飛彈導引指令因為虛擬機的排程而慢了0.1秒，攔截就會失敗。在TI-16硬體架構上，使用一些技術來在虛擬環境上達成關鍵任務所需的即時（Real Time）能力，例如單一根源I/O虛擬化(Single Root I/O Virtualization，SR-IOV）技術，通過透過創建輕量級虛擬功能(VF)，讓I/O傳輸的封包繞過虛擬交換器而直接與實體通信裝置（如艦上的萬兆級網卡）溝通，消除了網路層的延遲，使運行在虛擬機的火控軟體仍能與實體的SPY-1/6雷達進行直接通信。此外，艦上的虛擬化環境也經過深度客製化，確保如「火控虛擬機」等程序擁有絕對的優先權，即使其他虛擬機在進行繁重的地圖渲染工作時，火控指令也絕對不會被延遲。

通用源碼庫（CLS）

在神盾系統現代化、商規化與虛擬化的過程中，美國海軍為神盾系統創建通用通用原碼庫（Common Source Library，CLS）。在過去軟體與硬體高度綁定的時代，由於每一級船艦的作戰系統計算機硬體都不盡相同，甚至同一級船艦裡不同的次型（如神盾系統每個Baseline）都有硬體差異，因此過去的戰鬥系統軟體往往得為每種構型的戰系分別開發與維護。

一個具體的例子是，神盾巡洋艦與神盾驅逐艦的軟體是分開維護的；如果要在巡洋艦與驅逐艦引進相同的升級（例如反彈道飛彈能力），就得分別為雙方各寫一個版本的程式碼，在雙方的硬體平台上各測試一次；這部僅浪費資源，還容易導致相同功能在不同艦種上執行的戰術表現不一致，而且增加了軟體出錯以及版本管理的難度。

而當美國海軍進行神盾系統現代化、包括實現軟體與硬體層脫鉤的虛擬化時，讓不同船艦、硬體版本有差異的各型神盾戰系執行同一種通用程式碼終於成為可能。

從2008，洛馬集團啟動共同程序庫（Common Source Library，CSL），希望最終實現再不同戰系平台上執行同一套軟體代碼，從2012年起在美國海軍正式上線。於是從神盾Baseline 9起，美國海軍正式將神盾巡洋艦的軟體庫合併，使得經過升級的伯克級（Baseline 9C/D）與提康德羅加級（Baseline 9A）在應用軟體運作層面上幾乎沒有區別。

美國海軍戰系虛擬化的努力不限於神盾系統，還包括兩棲船艦與航空母艦使用的船艦自衛系統（Ship Self-Defense System，SSDS）；因此，CSL不僅納入原本神盾系統上執行的各種軟體，也包括SSDS。而2000年代才出現的較新系統如LCS濱海戰鬥艦的COMBATSS-21戰鬥系統，也能引用CLS來使用先前為神盾系統開發的軟體程式。

CLS研發階段的主承包商是雷松科技（Raytheon Technologies），但之後的管理維護合約由神盾系統主承包商洛馬集團取得。

為了實現在不同戰系平台上實現相同代碼，CSL建立了一套核心機制與基礎設施。首先就是虛擬化的工作平台，需要在底層計算機硬體與上層戰術應用程式之間，建立了一個強大完善的硬體抽象層（HAL），包含軟體中介層 (Middleware) 。實現這樣的基礎設施後，上層應用軟體只需要存取公定的物件，而不需要實際碰觸底層的硬體。

例如，無論是計算機較多的提康德羅加級神盾巡洋艦（有兩個戰情中心）還是空間與設備較精簡的伯克級神盾驅逐艦，對CSL軟體看到的都是標準化的處理資源池（Processing Pool）；而不同的CLS程序協同作業或相互溝通，也不需要直接存取通信硬體（如網卡），而是使用基於資料分佈服務（Data Distribution Service，DDS）的方式溝通。例如上層火控程式需要發射一枚防空飛彈時，就向DDS網路發佈一個「交戰需求」信息，中介層就會根據該艦的硬體資源配置（包括垂直發射系統數量、防空雷達型號、火控照射器數量、計算機資源等）來執行任務。

另外，雖然CSL讓不同船艦共用同一套原始碼，但不同船艦的任務需求不同（例如神盾巡洋艦還包括防空指揮功能）；因此，CSL透過「條件式編譯」與「動態加載」，使不同平台的戰系可以實際編譯與載入所需的軟體構型。例如對於神盾巡洋艦與驅逐艦，所有核心的功能如雷達處理、目標追蹤、威脅評估邏輯都完全相同，巡洋艦系統會多加載區域防空指揮（AAWC）程式模組；而如果是需要擔負反彈道飛彈（BMD）任務的神盾驅逐艦，則會選擇加載彈道飛彈處理模組。

以神盾艦搭配的相位陣列雷達為例，從Baseline 1~9使用的AN/SPY-1被動式相位陣列雷達跟Baseline 10引進的AN/SPY-6主動式相位陣列雷達，無論是物理硬體或資料量都有極大不同。但是在CSL架構下，這兩種雷達對於戰系中上層應用程式而言，只是兩種不同的「探測物件」；CLS的中介層能充分將雷達底層硬體以及與上層應用相關的邏輯隔離，應用程式不需要直接控制雷達的波束指向，而只需要下達高階指令（如指定波束的方位與俯仰角度等），而雷達回傳的數據都被CSL轉換成統一的格式，因此應用層邏輯完全不需要管雷達硬體的差別。例如，第一艘搭載神盾Baseline 10系統、AN/SPY-6相位陣列雷達的柏克Flight 3飛彈驅逐艦傑克.盧可斯號（USS Jack H. Lucas ，DDG-125），運行的核心軟體以及人機介面（如顯示在戰情中心的共同作戰圖像(COP)）幾乎與先前（Baseline 9）的船艦完全一樣。

在CLS架構下，每個新增或擴充現有軟體功能乃至於修復瑕疵，提交一次之後就會自動套用到所有船艦上，使整個艦隊都同步升級；而不像以前需要為不同級船艦分別維護代碼的時代，得一一在每個版本的軟體庫裡實作並分別進行測試。

當然，如果CSL的核心代碼中出現了一個錯誤，理論上全美軍所有神盾艦隊都會受到影響；因此，美國海軍在發布新的CSL 版本前，會對變更的功能進行嚴苛的「回歸測試」（Regression Testing）。

而透過將美國海軍所有戰系軟體資源整合到CLS裡，也為將來美國海軍發展所有船艦通用、大一統的共同作戰系統，奠定了必要的基礎。