當前位置：首頁 > 科技創(chuàng)新 > 智庫研究
空基信息系統(tǒng)協(xié)同計算架構(gòu)研究
摘 要：文中分析了多平臺協(xié)同場景下空基信息系統(tǒng)的計算特點和協(xié)同計算需求，并針對以預警機為中心的空基多平臺協(xié)同，設計了一種協(xié)同計算架構(gòu)，探討了該架構(gòu)下空基信息系統(tǒng)的協(xié)同計算模式，分析了架構(gòu)實現(xiàn)過程中需要解決的關(guān)鍵技術(shù)問題。基于文中所設計架構(gòu)，可實現(xiàn)空基信息系統(tǒng)任務軟件的高可用和平臺間計算任務的按需部署、遷移和協(xié)同計算，為構(gòu)建高可靠、高效能的空基信息系統(tǒng)提供基礎計算環(huán)境支撐。
關(guān)鍵詞: 空基信息系統(tǒng)；機載任務電子系統(tǒng)；協(xié)同計算；空基信息系統(tǒng)軟件架構(gòu)
引 言
空基信息系統(tǒng)是以空基平臺和網(wǎng)絡為基礎，通過傳感器、決策者和射手之間的信息共享和行動協(xié)同，實現(xiàn)打擊鏈路閉環(huán)的網(wǎng)絡化作戰(zhàn)信息系統(tǒng)[1-2]。空基信息系統(tǒng)由空基預警探測系統(tǒng)和空基指揮控制系統(tǒng)組成[3-4]，典型的空基信息系統(tǒng)以預警機為中心，協(xié)同干擾機、戰(zhàn)斗機、無人機等多型空基裝備，實現(xiàn)預警探測、情報偵察、指揮控制以及協(xié)同打擊等各種功能。
近年來，隨著各型空基裝備的長足發(fā)展，尤其是各類無人裝備的不斷涌現(xiàn)，空基信息系統(tǒng)的參與要素日益豐富，其數(shù)據(jù)處理需求產(chǎn)生了很大變化。與此同時，深度學習等智能化技術(shù)在各類信息系統(tǒng)中的應用日漸豐富，這為空基信息系統(tǒng)大規(guī)模數(shù)據(jù)的智能化處理提供了有力支撐。為此，有必要分析空基信息系統(tǒng)新的計算需求及特點，設計相適應的基礎架構(gòu)，提升空基信息系統(tǒng)的綜合效能。
1.空基信息系統(tǒng)計算特點及發(fā)展趨勢
空基信息系統(tǒng)的計算資源具有相對有限且分布不均的特點。具體來說，與地面各類信息系統(tǒng)不同，空基信息系統(tǒng)受其所依托空基平臺在載重、供電等方面限制，計算硬件總量受限，往往無法通過增加物理設備等方式對計算資源進行按需擴展。另一方面，各類空基平臺的計算資源分布也不夠均衡。以預警機為代表的大型裝備在飛行平臺的容納能力上具有優(yōu)勢，其計算資源相對充裕；而以無人機為代表的平臺容納能力相對小得多，其計算資源也更加短缺。
空基信息系統(tǒng)對計算可靠性和計算效率有著極高的要求。從預警探測、情報偵察開始，空基信息系統(tǒng)需要快速處理各類數(shù)據(jù)，以有效支撐指揮控制指令的產(chǎn)生，最終完成各類任務。流程中任何一個環(huán)節(jié)的計算失效都可能導致任務的失敗。
隨著無人化、智能化等新興技術(shù)的不斷發(fā)展成熟，其在空基信息系統(tǒng)的應用也愈發(fā)廣泛和深入。以智能化為例，從特定傳感器的目標識別等數(shù)據(jù)處理領(lǐng)域，到信息融合、輔助決策等指揮控制領(lǐng)域，智能化技術(shù)正大幅提升著空基信息系統(tǒng)的數(shù)據(jù)處理能力。伴隨這些新技術(shù)而來的是空基信息系統(tǒng)在計算方面的一些發(fā)展趨勢：
1.1 空基信息系統(tǒng)的計算對象呈現(xiàn)出規(guī)模化的特點
隨著裝備的不斷發(fā)展，預警探測的內(nèi)涵不斷擴大。來自各類主動、被動傳感器的數(shù)據(jù)均可作為預警探測的數(shù)據(jù)來源。這使得空基信息系統(tǒng)要處理的數(shù)據(jù)形式十分多樣，也不可避免地導致了數(shù)據(jù)體量的增長。另一方面，隨著近年來無人裝備的迅速發(fā)展普及，空基信息系統(tǒng)需要能夠處理來自各類無人裝備乃至無人裝備集群的數(shù)據(jù)。這進一步增大了空基信息系統(tǒng)的數(shù)據(jù)處理壓力，空基信息系統(tǒng)的數(shù)據(jù)處理體量越發(fā)規(guī)模化。
1.2 空基信息系統(tǒng)對數(shù)據(jù)通信效率的要求越來越高
空基信息系統(tǒng)參與要素的擴展使得要素之間的協(xié)同越發(fā)重要，數(shù)據(jù)通信正是平臺間相互協(xié)同的基礎。因此，空基信息系統(tǒng)對數(shù)據(jù)通信的需求是不斷增長的。空基環(huán)境中，各物理平臺間通過各種類型的數(shù)據(jù)鏈相互通信，數(shù)據(jù)鏈的通信帶寬本身是很有限的。此外，空中環(huán)境復雜多變，空基信息系統(tǒng)還需要考慮各類通信干擾等因素，這更加大了數(shù)據(jù)的傳輸限制。以上就要求空基信息系統(tǒng)的數(shù)據(jù)通信能夠在有限的通信帶寬和質(zhì)量下，盡可能提升通信效率，進而提升協(xié)同效率。
1.3 無人裝備的廣泛應用更加凸顯空基信息系統(tǒng)可靠計算的重要性
在很大程度拓寬空基信息系統(tǒng)預警探測覆蓋范圍的同時，相對更加前出的無人裝備自身也面臨相對更大的生存威脅。因此，有必要從基礎計算架構(gòu)上確保系統(tǒng)的高可靠，在出現(xiàn)由物理損傷等造成的平臺失能情況下仍要實現(xiàn)任務的接替，確保任務的完成。
2.空基信息系統(tǒng)協(xié)同計算需求
以空基協(xié)同態(tài)勢感知為例，預警機與其他各類特種機、無人機相互分工協(xié)作，預警機外各平臺擔負特定方面的探測和偵察任務，預警機平臺則在自身探測偵察的同時，擔負整體態(tài)勢感知和指揮控制任務。處于中心位置的預警機平臺與各平臺建立通信連接，接收來自各平臺的探測和偵察數(shù)據(jù)，并向各平臺下發(fā)綜合態(tài)勢信息及指揮控制指令。當預警機之外的各平臺間存在相互直接協(xié)同需求時，可根據(jù)需要建立直接通信。該場景下平臺的典型組成如圖1所示。
圖 1 典型空基信息系統(tǒng)協(xié)同場景
多平臺協(xié)同可克服單一平臺在探測、計算等方面的能力局限，有效提升戰(zhàn)場態(tài)勢感知的范圍和靈活度。不同平臺通過在探測區(qū)域、探測方式等方面分工協(xié)作，共同完成探測偵察任務；特定平臺所執(zhí)行的任務可根據(jù)總體任務執(zhí)行和態(tài)勢感知的需要而靈活變化，實現(xiàn)按需切換；當特定平臺出現(xiàn)計算資源不足時，可通過“計算卸載”將計算任務傳遞至具備相應計算資源的其他平臺，協(xié)同完成計算；在特定平臺失效的情況下，可將失效平臺的計算任務快速遷移至其他具備相應能力（如特定傳感器）的平臺，保障整個系統(tǒng)的可用性。
空基多平臺協(xié)同對各平臺任務計算的架構(gòu)提出了新的要求，主要體現(xiàn)在以下三個方面。
1）計算任務方面
多平臺協(xié)同要求計算任務具備跨平臺部署和動態(tài)遷移的能力，這就要求包括嵌入式硬件在內(nèi)的各類異構(gòu)計算硬件向上層計算任務提供統(tǒng)一的運行環(huán)境，實現(xiàn)任務部署和遷移過程中運行環(huán)境的一致。
2）任務數(shù)據(jù)方面
多平臺協(xié)同要求在節(jié)點間按需建立通信關(guān)系的基礎上，面向核心數(shù)據(jù)提供多平臺分布式能力，實現(xiàn)關(guān)鍵任務數(shù)據(jù)在多平臺間的分布式同步。此外，為有效降低協(xié)同過程中的數(shù)據(jù)通信需求，需要支持對計算任務運行過程中的動態(tài)數(shù)據(jù)和靜態(tài)數(shù)據(jù)進行有效區(qū)分，通過任務規(guī)劃，將可能存在協(xié)同需求的靜態(tài)數(shù)據(jù)進行預先部署，降低任務執(zhí)行過程中的數(shù)據(jù)傳遞需求。
3）計算資源方面
多平臺協(xié)同要求中心平臺具備對各平臺計算資源的整體管理能力，要能夠根據(jù)任務需求和實時態(tài)勢，在各平臺間進行計算資源的動態(tài)管理以及計算任務和計算資源的動態(tài)匹配。計算任務和計算資源匹配過程中，要能夠充分利用數(shù)據(jù)采集端的計算能力，盡可能在末端進行全部或部分的數(shù)據(jù)處理或預處理，從而降低協(xié)同過程中的數(shù)據(jù)通信需求。
3.空基信息系統(tǒng)協(xié)同計算架構(gòu)
結(jié)合上述對空基信息系統(tǒng)計算特點和協(xié)同需求的分析，設計如圖2所示的空基信息系統(tǒng)計算架構(gòu)。
圖 2 協(xié)同計算架構(gòu)示意圖
架構(gòu)中，自頂向下分別為應用軟件（各類計算任務）、統(tǒng)一組件環(huán)境、硬件資源虛擬化和操作系統(tǒng)/各類硬件。其中，硬件資源虛擬化層是本架構(gòu)的基礎，通過該層對各平臺的不同類別硬件進行統(tǒng)一的虛擬化，形成抽象的虛擬化資源池；統(tǒng)一組件環(huán)境是本架構(gòu)的核心，它基于虛擬化資源池，為上層應用軟件提供統(tǒng)一的運行環(huán)境，并進行各類管理、提供各類基礎服務。本架構(gòu)的主要特點如下。
3.1 軟件狀態(tài)分離
應用軟件層面，本架構(gòu)對其進行組件化封裝。邏輯角度，封裝后的組件細分為程序、數(shù)據(jù)和狀態(tài)。其中，程序?qū)浖目蓤?zhí)行指令集合，其本身是靜態(tài)的；數(shù)據(jù)對應程序執(zhí)行過程中從外部存儲器讀寫的靜態(tài)／動態(tài)內(nèi)容；狀態(tài)則對應程序執(zhí)行過程中在內(nèi)部存儲器讀寫的動態(tài)內(nèi)容[5]。組件的運行過程可視為靜態(tài)程序被計算硬件加載之后執(zhí)行指令、讀取處理數(shù)據(jù)、改變自身狀態(tài)并輸出數(shù)據(jù)的過程。將組件靜態(tài)程序和動態(tài)狀態(tài)進行分離，并將數(shù)據(jù)和狀態(tài)進行分別處理，從架構(gòu)上提供數(shù)據(jù)和狀態(tài)的統(tǒng)一管理，可實現(xiàn)單平臺內(nèi)計算任務的高可靠保障，并為實現(xiàn)依托于組件的計算任務在平臺間的遷移和協(xié)同奠定基礎。
3.2 計算環(huán)境統(tǒng)一
應用軟件之下，設計“統(tǒng)一組件環(huán)境”層。該層連接應用軟件和操作系統(tǒng)，面向各平臺各類軟件的運行提供一致的基礎運行環(huán)境。該層功能可細分為資源管理、數(shù)據(jù)管理、狀態(tài)管理、服務管理、組件管理、任務管理、數(shù)據(jù)協(xié)同管理、狀態(tài)協(xié)同管理和任務協(xié)同管理。
資源管理綜合上層應用的資源需求和硬件資源池內(nèi)的各類資源占用，依據(jù)任務模型中預先設定的分配策略，進行資源的分配和動態(tài)調(diào)整；并對資源和資源的占用進行實時監(jiān)控管理，為跨平臺的資源協(xié)同提供依據(jù)。
數(shù)據(jù)管理和狀態(tài)管理分別為上層應用提供相互隔離的數(shù)據(jù)和狀態(tài)訪問服務。應用軟件通過數(shù)據(jù)管理和狀態(tài)管理兩類服務，將程序運行過程中的數(shù)據(jù)和狀態(tài)集中托管至統(tǒng)一組件環(huán)境。統(tǒng)一組件環(huán)境在數(shù)據(jù)和狀態(tài)集中管理過程中，則可采用分級、分布式等策略[6]，實現(xiàn)集中托管數(shù)據(jù)的高效率和高可靠。
組件管理為上層組件的運行提供基礎管理功能，包含組件生命周期管理、運行狀態(tài)監(jiān)控、健康狀態(tài)識別等。同時，在組件管理的基礎上，針對面向服務的架構(gòu)（SOA）等架構(gòu)的服務化設計需求提供服務管理功能，該功能為服務接口的描述和表達提供統(tǒng)一標準，支持基于統(tǒng)一資源定位符的全系統(tǒng)服務定位，并為服務接口的調(diào)用提供數(shù)據(jù)消息的路由轉(zhuǎn)發(fā)。
任務管理為系統(tǒng)內(nèi)各平臺提供統(tǒng)一的任務模型定義，并基于定義的模型，產(chǎn)生并應用相應的組件、服務、資源、數(shù)據(jù)、狀態(tài)管理策略。
數(shù)據(jù)協(xié)同管理和狀態(tài)協(xié)同管理面向跨平臺協(xié)同需求，基于分布式一致性等方法，通過網(wǎng)絡通信實現(xiàn)數(shù)據(jù)和狀態(tài)在平臺之間的分布式管理。任務協(xié)同管理則為數(shù)據(jù)和狀態(tài)的協(xié)同過程提供基于任務模型的統(tǒng)一管理。3.3硬件資源虛擬化
統(tǒng)一組件環(huán)境之下，通過“硬件資源虛擬化”層適配對接各平臺的各類計算硬件——包含CPU、內(nèi)存等計算硬件、存儲硬件和網(wǎng)絡硬件，向上層提供統(tǒng)一的計算、操作接口，實現(xiàn)硬件資源的虛擬化。標準計算硬件可直接通過操作系統(tǒng)內(nèi)核的相應特性實現(xiàn)虛擬化；對于非標準硬件，如各類FPGA設備[7]，可通過單獨設計的虛擬化適配器，將資源納入硬件資源虛擬化層。
4.空基信息系統(tǒng)協(xié)同計算模式
4.1 計算協(xié)同方式
本文所述計算架構(gòu)下，應用軟件基于統(tǒng)一設計框架進行設計和實現(xiàn)，并運行于統(tǒng)一組件環(huán)境中。該設計使得軟件具備在不同平臺間、平臺內(nèi)部不同硬件設備間的通用能力，這與FACE[8]等架構(gòu)在應用層所瞄準的目標是相似的。該能力確保不同來源的軟件可免適配地部署在環(huán)境內(nèi)任一平臺、任一設備上，并實現(xiàn)動態(tài)遷移。
為了滿足第2節(jié)所述空基信息系統(tǒng)協(xié)同計算需要，組件還需具備不同平臺、不同設備間動態(tài)遷移的過程中業(yè)務功能延續(xù)的能力。本計算架構(gòu)中，通過數(shù)據(jù)和狀態(tài)的跨平臺協(xié)同滿足該需求。當數(shù)據(jù)和狀態(tài)分布存儲于單平臺內(nèi)時，程序可在不同硬件間自由遷移而不影響程序的運行結(jié)果；當數(shù)據(jù)和狀態(tài)分布存儲于多個平臺時，通過數(shù)據(jù)和狀態(tài)在平臺間的協(xié)同實現(xiàn)平臺間數(shù)據(jù)與狀態(tài)的一致，從而實現(xiàn)程序和業(yè)務功能的跨平臺遷移。
一般的信息系統(tǒng)中，相較于計算資源，存儲資源往往相對充沛。在此背景下，在本架構(gòu)的實際應用中，可在組件設計時對數(shù)據(jù)和狀態(tài)進行精心設計和劃分。根據(jù)可能的任務協(xié)同需要，將組件程序和靜態(tài)數(shù)據(jù)預先部署至存在潛在協(xié)同需求的節(jié)點。空基信息系統(tǒng)運行過程中，只針對狀態(tài)等動態(tài)數(shù)據(jù)進行分布式協(xié)同，從而降低功能遷移過程中的通信帶寬需求。
4.2 協(xié)同計算應用形式
在多平臺構(gòu)成的空基信息系統(tǒng)中，通過本架構(gòu)可實現(xiàn)以下幾種典型協(xié)同計算應用形式。
（1）計算任務平臺內(nèi)協(xié)同
隨著任務執(zhí)行過程中戰(zhàn)場態(tài)勢的不斷變化，單一平臺內(nèi)部的任務計算需求同樣是動態(tài)變化的，計算任務在平臺內(nèi)同樣存在協(xié)同的必要。上述架構(gòu)下，計算資源的虛擬化可為計算任務在平臺內(nèi)的協(xié)同并發(fā)提供資源保障，而狀態(tài)數(shù)據(jù)的分離和統(tǒng)一管理則可為計算任務在平臺內(nèi)的協(xié)同并發(fā)提供數(shù)據(jù)保障。
（2）計算任務跨平臺協(xié)同
以第2節(jié)中空基信息系統(tǒng)多平臺協(xié)同場景下的組成為例，預警機中心單元在任務執(zhí)行前進行任務和數(shù)據(jù)的規(guī)劃，并將內(nèi)容同步至外部協(xié)同平臺；任務執(zhí)行中，中心單元根據(jù)任務模型進行的任務調(diào)整，以指令形式通過無線通信分發(fā)至各協(xié)同平臺；協(xié)同平臺依據(jù)接收的任務，基于本地傳感器進行數(shù)據(jù)采集，利用本地計算硬件進行數(shù)據(jù)處理，并將數(shù)據(jù)處理結(jié)果發(fā)送出去；各平臺的本地處理結(jié)果作為狀態(tài)信息，根據(jù)任務協(xié)同模型，按需同步至其他平臺；中心節(jié)點采集同步來的各類數(shù)據(jù)，并基于此進行指揮控制、任務管理等相關(guān)計算。
（3）計算任務卸載傳遞
當出現(xiàn)特定平臺（稱為需求平臺）計算資源無法滿足任務需要時，系統(tǒng)進行平臺間協(xié)同計算。此時，中心平臺在需求平臺物理位置附近匹配具備一致的計算環(huán)境、通信帶寬和通信質(zhì)量能夠保障協(xié)同需要且有富余計算能力的平臺（稱為協(xié)同平臺），形成相應指揮控制指令并通過“任務、數(shù)據(jù)、狀態(tài)”協(xié)同管理模塊下發(fā)至各相關(guān)平臺。與此同時，可根據(jù)需求建立點對點的高速通信，以更好地保障協(xié)同計算。在實際應用中，部分計算任務不可避免地需要特定與平臺相關(guān)的硬件設備提供計算支持。這類情況下，需求平臺和協(xié)同平臺必須具備一致的計算環(huán)境，才能實現(xiàn)計算的協(xié)同。如上文所分析，針對此類情況，可通過事先的規(guī)劃，預判可能的協(xié)同需求，并將協(xié)同需要的靜態(tài)數(shù)據(jù)在任務執(zhí)行前同步存儲至各平臺，以降低任務執(zhí)行時協(xié)同的響應時間。
（4）計算任務遷移接替
當出現(xiàn)特定平臺失效時，系統(tǒng)進行計算任務的跨平臺遷移。此時，中心平臺在失效平臺物理位置附近規(guī)劃和匹配具備一致硬件環(huán)境的平臺（稱為目標平臺），并形成相應指揮控制和任務管理指令，使目標平臺承接失效平臺的計算任務。通過任務前的規(guī)劃，可保障具備相互遷移能力的平臺（如配置有相同類別傳感器的平臺）在任務執(zhí)行前具備組件程序等靜態(tài)數(shù)據(jù)的一致性。另一方面，由于跨平臺協(xié)同的存在，各類關(guān)鍵動態(tài)數(shù)據(jù)被分布存儲于系統(tǒng)中。基于此，可實現(xiàn)任務在平臺間的平滑遷移，從而保障空基信息系統(tǒng)的高可靠。
5.空基信息系統(tǒng)協(xié)同計算架構(gòu)的關(guān)鍵技術(shù)問題
上述空基信息系統(tǒng)協(xié)同計算架構(gòu)的實現(xiàn)和有效運行，需要解決以下四個關(guān)鍵技術(shù)問題。
1）對系統(tǒng)任務和計算任務的有效建模。通過任務模型，對任務中各個關(guān)鍵環(huán)節(jié)、各類關(guān)鍵數(shù)據(jù)進行細顆粒度的劃分和定義，并借助組件化、服務化等設計方法，將任務具象成為具備一定通用性的組件/服務及其相互關(guān)系的集合。
2）面向細顆粒度組件/服務的精細規(guī)劃和優(yōu)化。組件和服務的細顆粒度劃分給系統(tǒng)帶來靈活性的同時，也帶來了更大的管理編排壓力。只有具備精細化管理能力才能使組件/服務有機協(xié)同，實現(xiàn)資源管理效能和空基信息系統(tǒng)運行效能的整體提升。
3）數(shù)據(jù)鏈等網(wǎng)絡通信的發(fā)展。空基信息系統(tǒng)跨平臺的信息交互依賴于通信基礎設施，通信的帶寬、靈活性、穩(wěn)定性、安全性等因素直接影響系統(tǒng)通信效能，也直接影響協(xié)同效能。平臺間通信能力的提升必然可為跨平臺的協(xié)同計算帶來更多的空間和可能。
4）跨平臺的動態(tài)數(shù)據(jù)分布策略和實現(xiàn)方法。在復雜空基環(huán)境中構(gòu)建數(shù)據(jù)分布式冗余存儲，可以為計算任務的高效協(xié)同奠定基礎，也是另一個有待解決和驗證的關(guān)鍵技術(shù)問題。
結(jié) 語
本文分析了空基信息系統(tǒng)的計算特點和協(xié)同計算需求，并基于此設計了一種協(xié)同計算架構(gòu)，滿足空基信息系統(tǒng)的協(xié)同計算需求。在裝備無人化、計算智能化的當前，該架構(gòu)可針對性地提供一種空基信息系統(tǒng)協(xié)同計算實現(xiàn)思路，滿足日益增長的協(xié)同計算需求，提升新環(huán)境下空基信息系統(tǒng)作戰(zhàn)效能，使空基信息系統(tǒng)的各參與平臺和要素圍繞作戰(zhàn)任務，將各自資源充分整合并形成有機整體。
【參考文獻】
[1] 陸軍,張昭,胡瑞賢.空基預警探測系統(tǒng)技術(shù)發(fā)展趨勢[J].現(xiàn)代雷達,2015,37(12):1-5.
[2] 范鵬,曹晨,葛懷寧.預警機指揮控制功能的作戰(zhàn)使用及其發(fā)展[J].現(xiàn)代電子技術(shù),2014,37(16):83-86.
[3] 吳永勝,姜邵巍,劉曉敏.面向空基信息系統(tǒng)的公共操作環(huán)境研究[J].中國電子科學研究院學報,2018,13(3):247-253.
[4] 吳永勝,李博驍.空基信息系統(tǒng)分層模型及數(shù)據(jù)互操作研究[J].鄭州大學學報(理學版),2015,47(3):55-58.
[5] Philip A L. Dictionary Of Computer Science, Engineering And Technology[M].NW Boca Raton: CRC Press Inc， 2000.
[6] Bohannon P, Parker J, Rastogi R, et al.Distributed multi-level recovery in main-memory databases[C]//Fourth International Conference on Parallel and Distributed Information Systems.Miami Beach: IEEE Press, 1996: 44-55.
[7] Vaishnav A, Pham K D, Koch D.A survey on FPGA virtualization[C]//2018 28th International Conference on Field Programmable Logic and Applications (FPL). Dublin: IEEE Press, 2018:1311-1317.
[8]Brabson S , Anderson T . Evolution of the US Navy’s collision avoidance systems (CAS) to future airborne capability environment (FACE)[J]. IEEE Aerospace & Electronic Systems Magazine, 2015, 30(6):16-23.
