通用遙感衛星基帶數據二級并行處理算法設計與實現

張人愉，李景山

(1.中國科學院遙感與數字地球研究所，北京 100094；2.中國科學院大學，北京 100049)

0 引言

衛星基帶數據的處理是衛星地面處理系統的起始部分，負責衛星下傳數據的幀同步、解擾、譯碼、解格式和解壓縮等步驟，為后續的產品生產提供基礎數據[1]。現今隨著衛星遙感技術和計算技術的不斷發展，每年都有大量遙感衛星發射，衛星遙感技術也向著高空間分辨率和高光譜分辨率的方向發展[2]。衛星傳感器產生的遙感數據量不斷增大，星上數據的下傳碼速率也隨之不斷增大。如當前我國主流的高分辨衛星高分1號、2號和資源三號1、2星等衛星的數傳碼速率為雙通道450 Mbps，要實現實時的數據處理，即地面基帶數據處理系統要有900 Mbps以上的處理能力。對處理衛星下傳數據的地面基帶數據處理系統而言，由于其處理過程需要的步驟較多，且解壓縮部分計算又過于復雜，這樣造成了系統設計的兩個主要難點，一是對設計出具有通用性和擴展性的處理系統提出了更高的要求，二是在處理速度上要達到實時快速處理必須設計高效的解壓縮處理策略。

針對衛星地面基帶數據處理中的難點，已有人對此進行過一些探討設計，比較有代表性的如何芳等[3]介紹一種基于刀片式服務器的遙感衛星基帶數據處理系統平臺，以建立滿足國內遙感衛星基帶數據處理系統的通用平臺為目標而確立。楊甲森等[4]針對衛星地面應用系統支持多星多任務的運行控制需求，通過采用調度中心與處理程序集協同的工作方式，借鑒Hadoop MapReduce的框架設計思路，設計了衛星基帶數據實時處理系統，且實踐表明在萬兆網鏈接的10臺計算機機群上，能實現對3個地面站接收的4顆衛星的實時及事后2種模式的數據處理任務，處理的實時數據碼率優于150 Mbit/s。劉莉[5]針對高速率衛星遙感數據實時處理的要求，設計了一種衛星遙感數據實時處理平臺，其平臺采用分層設計思想，自上而下分為表現與控制層、業務處理層、基礎服務層和應用支持層，結合消息傳遞接口(MPI)技術，構建了分布式實時并行處理平臺框架。

雖然有不少關于遙感衛星基帶數據處理系統的研究工作，不過在對系統的設計上大都較為宏觀，較少涉及內部算法的具體細節。在系統的通用性和可擴展性設計上，有將基帶數據的每個處理過程獨立設計成小程序然后組合調用的模式，和將每個過程設計成動態庫調用的形式，較少研究外部配置文件能否實現通用性的文章，而外部配置的方式能最大程度實現代碼的重用，無須給每一個衛星重新去實現單獨的小程序。在計算復雜的解壓縮的處理上，大多按虛擬信道號提取AOS(高級在軌系統)幀中數據，然后按照有效載荷分發到不同計算節點上進行處理，這種方式存在計算資源浪費的問題，不同載荷數據處理按節點進行了分離，使得在處理一個載荷時，另外載荷的計算節點處于等待狀態，這不利于解壓縮的快速處理。而使用MPI+OpenMP結合的方式用于基帶數據的解壓縮則能解決上述計算資源浪費的問題，而且得益于MPI在分布式計算上的優勢，在計算節點的擴展上也十分便利。

本文在研究和借鑒高性能遙感衛星數據地面處理系統機群解決方案設計[6]的基礎上，設計并實現了通用的基于高性能機群的衛星基帶數據并行處理算法。該算法在充分分析不同衛星在各處理步驟中的差異性后，基于外部配置文件的方式和軟件設計模式的思想進行了通用性和可擴展性設計；同時針對計算復雜的解壓縮部分，在合理設計壓縮數據的劃分策略和并行處理策略的基礎上，實現了計算負載均衡的MPI+OpenMP的二級并行處理。

1 算法設計與實現

遙感衛星基帶數據處理是以實時基帶數據碼流或事后基帶數據文件為處理對象，經幀同步、解擾譯碼、AOS幀格式解析分包和解壓縮等處理，生成初級產品的過程。該過程如圖1所示。

圖1 遙感衛星地面基帶數據處理流程

本文設計的通用遙感衛星基帶數據二級并行處理算法在功能上具有如下指標：

①能配置輸入源為網絡或本地文件。

②能夠對基帶數據進行幀同步，準確提取幀同步字，對傳輸過程中出現的幀頭滑位等錯誤進行糾正。

③能夠將加擾的數據區域進行解擾，能配置擾碼起始狀態參數。

④對解擾后數據進行譯碼處理，能實現常見糾錯編碼如RS碼和LDPC碼的配置。

⑤對譯碼處理后的數據進行AOS幀格式解析，提取有效數據域，根據虛擬信道號進行數據分離。能通過配置AOS幀參數來實現不同衛星的處理。

⑥對各信道數據進行快速解壓縮，能使用高性能計算技術最大程度地使用計算資源。

⑦拼接解壓縮后數據，解析相機輔助數據，生成特定格式產品。

1.1 總體設計

本文設計的算法重點主要體現在兩個方面，一個是通用性和可擴展性，一個是處理速度。這兩個方面在遙感衛星基帶數據處理中是難點。當前衛星數量不斷增加，各衛星使用技術上存在差別，要實現通用和可擴展處理具有難度，而遙感衛星下傳碼速率也不斷上升，對基帶數據處理的速度要求也越來越高，要實現快速實時的處理難度也很大。但是如果能解決這兩方面的問題，意義是重大的，解決通用性和可擴展性可以對新發射的衛星進行快速部署處理，解決處理速度問題就可以應對未來下傳碼速率的不斷提高，實現遙感衛星數據的實時處理，所以良好的通用性與可擴展性，和快速實時處理基帶數據就是本文算法想要達到的效果。

對于通用性和可擴展性的設計本文使用了外部配置和軟件模式相結合的方式。使用外部配置來達到通用處理的方式是最簡單方便的方式，因為該方式無需對程序代碼進行任何形式的修改即可實現新衛星的擴展。某些不能通過外部配置實現擴展的，可以使用合理的軟件設計模式，使代碼最大程度上實現重用，同時對原有代碼的改動達到最小。本文在設計通用性和可擴展性方面，結合了資源三號1、2號星和高分1、2號衛星的地面處理系統接口規范，對其中使用的技術、數據編排規范等進行了充分了解，總結出整個處理過程中能通過配置實現擴展的部分和需要編程解決擴展的部分，最大程度達到主流通用可擴展。

在處理速度方面，本算法選擇了MPI+OpenMP相結合的并行編程模型。當前并行編程模型中消息傳遞模型仍是大規模并行編程主流，MPI作為消息傳遞編程模型事實上的工業標準，設計方便分布式計算，具有程序性能高、擴展性好的特征[7]。OpenMP是面向共享存儲系統的主要并行編程模型和事實上的工業標準，它具有編程簡單、可移植性好等優點[8]。本文算法使用MPI和OpenMP相結合的方式進行并行編程，能將二者的優勢進行結合，MPI可以方便地進行計算節點間分布式計算編程，OpenMP方便節點內部共享內存并行計算。本文算法中選取基帶數據處理過程中計算量最大的解壓縮部分進行重點的兩級并行設計，對于其他處理步驟，由于計算量相對解壓縮而言小的多，所以只使用了線程級別的并行處理即可滿足處理的要求。

基于上面的設計原則和思路，本文算法的整體結構設計如圖2所示。

圖2 算法整體結構設計

1)在計算節點1上進行數據的接收、幀同步、解擾、譯碼和AOS幀格式解析操作，為使處理速度更快，數據的接收同步放在一個單獨的線程進行處理，解擾和譯碼通過OpenMP進行并行化處理，AOS幀格式解析和分包發送放在一個線程上處理，這3個部分之間通過2個線程安全的數據隊列進行數據傳遞，數據接收、幀同步和解擾譯碼形成一種生產者-消費者模式，同時解擾譯碼和AOS幀格式解析同樣形成生產者-消費者的模式。計算節點1上各虛擬通道的數據最終通過IB高速網絡發送到計算節點2。

2)在計算節點2上為每個虛擬信道數據的接收和解析壓縮塊開辟一個線程，解析得到的通用壓縮塊數據放入待解壓縮隊列中等待處理。計算復雜的解壓縮部分通過MPI進行多個節點間進程級別的并行計算，每次計算以計算節點的倍數個壓縮塊進行分配，保證計算任務的均衡分配，在節點的內部通過OpenMP進行線程級別的并行處理。數據在解壓縮之后的拼接寫入放在一個單獨的線程進行處理。

3)在解壓縮計算節點上只實現單純的解壓縮功能，合理設計的通用解壓縮塊數據作為節點上處理的基本單位，而節點內部可將通用解壓縮塊數據分為若干基本壓縮單元，利用OpenMP對基本壓縮單元進行并行處理，然后發送回計算節點2。

整個處理流程中的數據以一種類似流的方式在各個處理步驟間流動，在計算量大的步驟通過多線程技術和并行處理技術來增加計算資源，使之快速處理，使整個處理過程中各部分之間的等待時間盡可能的短，從而充分利用計算資源。如在解擾和譯碼部分計算量相對較大，本文算法通過OpenMP將其處理進行了并行化，并行使用的線程數目維護一個最小值和最大值，根據實際的處理情況線程在最大最小值之間浮動，實現動態的計算負載均衡，具體的線程增減策略通過對其前后的數據隊列大小進行監控設置，當幀同步后的隊列處于較滿的時候，動態增加2個線程給解擾和譯碼部分，幀同步后隊列處于快空的時候，動態減少2個線程，但增減范圍都在最大最小值之間。計算量最大的解壓縮部分通過MPI+OpenMP的二級并行進行處理，該部分是整個處理系統中性能的關鍵點，具體的處理策略將在后面單獨進行說明。

1.2 算法通用性設計與實現

整個處理過程中通用性設計是本文一個重要探討的主題，整體設計思路是通過外部的配置文件加上內部使用軟件設計模式思想實現。通用性設計的關鍵是對整個處理過程中的處理步驟在不同衛星中的異同加以分析，合理設計配置文件參數，達到在不修改或極少修改原有代碼的基礎上實現新衛星數據的處理。能通過配置文件配置的部分，主要是針對AOS幀格式解析，分析好AOS幀格式后基本能實現幀同步到AOS分包過程中的通用性設計；在使用軟件設計模式的部分，通過模板方法和工廠模式來實現，主要步驟在通用壓縮塊的解析、壓縮算法的選擇和最后拼接存檔部分。以下將就上面2種方式的具體細節設計和實現進行更詳細的說明。

1)通用AOS幀格式解析。在設計之初考慮到CCSDS高級在軌系統(AOS)標準已成為世界航天飛行器空間數據系統的新一代技術體系標準，并被絕大多數的空間組織和國家所采納[9]，我國現今的主流衛星基本上都采用這一標準進行數傳系統的數據組織格式，如資源三號系列和高分系列衛星都遵循該標準，所以本算法的通用性設計主要針對遵循CCSDS高級在軌系統標準的衛星進行。一個典型的AOS幀數據格式如圖3所示。

信道編碼/加擾區/譯碼校驗區/CRC校驗區格式編排同步字VCDU主導頭版本號VCDU標識符航天器標識虛擬信道標識VCDU計數器信號域回放標識備用域VCDU插入區VCDU數據BPDU導頭BPDU位流數據區VCDU差錯控制域譯碼校驗符號域

圖3 AOS幀數據格式

從幀同步到AOS幀格式解析分包過程中，幀同步準確地提取遙感衛星下行數據流中的幀同步字，獲取正確的幀結構，而后的幾個步驟的處理都是以幀為基本單位進行處理，所以對幀結構的通用化是實現這一部分通用化的關鍵。在圖3中描述的幀數據格式中，整個幀的數據以同步字起始，該同步字經過一定的處理用于幀同步，加擾區的數據需要進行解擾操作，譯碼校驗區需要進行相應的譯碼處理，CRC校驗區要進行CRC校驗，在AOS幀格式解析分包處理中主要需要解析虛擬信道標識、VCDU計數器和VCDU數據單元，將對應虛擬信道中的BPDU位數據流進行提取，得到壓縮的圖像數據和輔助數據。通過分析AOS幀數據格式，本文設計了用于配置AOS幀格式的外部配置文件，該配置文件能描述AOS幀中的各項參數以及參數的位置。以下使用資源三號2星正視相機虛擬信道號的設置格式進行說明，AOS幀中的其他參數的設置具有類似結構：

5

用于表示該參數在AOS幀數據中相對幀起始位置的偏移字節，是位比特掩碼，用于提取該參數在字節中的實際有效位，所有的參數提取都需要使用這2個參數進行基本定位。在虛擬信道的設置上可以根據具體衛星設置不同數目的虛擬信道，即參數可以動態設置多個，標識了虛擬信道的名字，標識了使用十六進制表示虛擬信道的具體信道號。在程序內部讀取使用時，在幀中定位到參數字節位置，使用掩碼與讀取的數據進行與操作，再與中的值進行對比即能得出該幀數據是否屬于該虛擬信道，遍歷所有虛擬信道號直到找到匹配的虛擬信道號，就將該幀的VCDU計數器和BPDU數據域提取出來放入對應虛擬信道的緩存中，準備根據VCDU計數器進行排序后將數據發送出去。

2)解壓縮的通用性設計。本文在解壓縮的通用性設計上主要使用軟件設計方法中模板方法和工廠模式方法，以及設置合理的通用數據結構。模板方法模式通過定義抽象的函數接口，使子類可根據自身情況進行方法的實現，在使用時結合工廠模式能很好地達到易擴展的目的。在衛星數據解壓縮的通用性設置上，將數據的具體解碼分為了3個層，1個是解碼器的抽象層，規定了解碼類需要實現的具體接口，然后是具體解碼器算法選擇層，該層實現具體的解碼算法，如資源三號即實現JPEGLS解碼算法，衛星層主要用于具體衛星的解碼算法選擇，不同衛星即使在壓縮數據上使用相同的壓縮算法，但實際具體實現時具有一定的差異，衛星層很好地解決了該問題。工廠模式通過衛星標識選擇對應衛星解碼器實例，新增衛星時，通過實現具體衛星層類，將衛星加入工廠模式即可實現可擴展。通用解碼器類關系圖設計如圖4所示。

圖4 壓縮數據的解碼器類關系圖

模板方法和工廠方法的使用可使得解壓縮算法擴展性變得容易，當需要處理一個新衛星的數據，只要實現該衛星自己的解碼器接口，然后將新的衛星解碼器加入工廠類即可。除了在解碼器的實現上使用了模板方法和工廠類，在解壓縮后的數據拼接和存儲上同樣使用了相同的思想，不同衛星通過繼承拼接寫入基類實現自己的拼接邏輯，從而使拼接寫入具有易擴展性。

在整個解壓縮的通用性設計上通用的數據結構同樣起著十分重要的作用，有了通用的解壓縮結構，使得在解析AOS分包后的圖像數據和輔助數據上變得容易，同時解壓縮邏輯上也變得更加清晰，無需為不同的虛擬信道數據進行單獨的處理，所有數據放入同一個處理隊列中，非常便于進行分布式并行處理，且利于計算資源的負載均衡。在得出通用解壓縮數據結構之前，需要分析一般衛星壓縮數據和輔助數據的編排格式。本文通過分析資源三號1、2星和高分1、2號衛星的壓縮數據和輔助數據編排格式，最后得出了通用的壓縮數據塊結構。圖5為資源三號1星正視相機的數據編排格式。

圖5 資源三號1星正視相機壓縮數據編排格式

在分析資源和高分衛星的過程中，發現所有這些衛星在編排數據的時候基本使用一致的格式編排，數據劃分以幅為大單位，幅的下面分為塊，塊的下面分為輔助數據和小的壓縮單元。所以本算法設計了如圖6所示的通用壓縮數據塊結構，用于放入解壓縮處理隊列中進行分布式并行解壓縮。

圖6 通用解壓縮塊數據結構

通用壓縮塊數據結構的設計解決了同一衛星中不同虛擬信道數據必須分開處理的問題，現在所有虛擬通道的數據遵循該結構進行解析就能無差別地放入解壓縮處理隊列。解壓縮處理完成后的數據同樣使用該結構儲存，只是壓縮數據變為了已經解壓縮后的數據，進行拼接的時候能根據虛擬信道號放入不同的隊列，然后根據幅序號和塊序號拼接數據還原圖像。

1.3 并行解壓縮

數據解壓縮的過程在整個基帶數據處理中屬于計算最復雜的部分，也是本文算法的一個核心部分，通常一臺機器遠遠不能滿足快速解壓縮的要求，所以本算法使用多臺機器進行分布式計算，利用MPI進行計算節點間進程級別的并行，在計算節點內部使用OpenMP進行線程級別的并行，整個并行解壓縮的流程如圖7所示。

圖7 MPI+OpenMP的并行解壓縮框架圖

從上一小節中可知，本文設計的通用壓縮塊數據結構大大方便了解壓縮的分布式并行處理，本節說明的解壓縮并行處理算法就是以該通用壓縮塊數據結構隊列為數據的輸入，經過MPI將壓縮塊數據發送到各計算節點進行粗粒度的并行處理，在計算節點內部，壓縮塊內部的壓縮單元通過OpenMP在線程級別上進行細粒度的并行處理，處理完成的數據通過MPI重新發送回源節點，然后將數據以塊的方式放入拼接類，在拼接類中維護有多個隊列用于存放各虛擬信道數據，當數據隊列滿足拼接需求時，對數據進行拼接寫入。

本文的并行解壓縮算法在理論上具有計算資源接近0等待的優點，只要前面步驟一直在處理數據，解壓縮隊列中就持續有數據進入，那么并行解壓縮就會持續進行，用于計算的節點就會全部處于計算運行狀態，直到解壓縮隊列為空。區別于將特定虛擬信道數據發送到特定節點進行處理的策略，一旦在某些時刻一些信道的數據較少，那么處理這些較少數據信道的節點會存在資源等待，從而出現計算資源的浪費。本算法設計的二級并行解壓縮很好地解決了這個問題。

2 實驗驗證分析

本文以資源三號1星在2017年5月30日由喀什站接收的軌道號為029922的2個通道的基帶數據作為實驗數據，算法處理程序運行在有5臺機器組成的機群服務器上，每臺服務器配置2顆4核的Intel Xeon E5620處理器和24 GB內存，服務器之間通過帶寬20 Gbps的IB高速網絡連接，實驗數據存儲在服務器內部署的lustre并行文件系統之上。實驗中共使用5個節點，1個節點用于幀同步到AOS幀格式解析，其余4個節點用于并行解壓縮和數據拼接寫入。將MPI并行進程數設置為4，OpenMP線程數設置為16，使計算資源最大化，得出測試結果如表1所示。

表1 資源三號1星解壓縮實驗測試結果

由實驗結果可知本文的處理算法具有較好的處理速度，滿足了資源三號1星雙通道450 Mbit/s下傳碼速率實時處理的要求，解壓縮輸出的數據率達到了4.8 Gbps。將輸出的解壓縮后圖像數據截取10 240行，得到圖像如圖8所示。

圖8 資源三號1星的解壓縮結果影像

在實驗中對并行解壓縮部分進行了并行加速比的測試，加速比S的定義如公式(1)[10]所示，為并行處理時間除以串行處理的時間。測試數據使用單通道1的數據進行，整個測試分為三個部分，一是測試MPI在節點間的并行加速比，二是測試OpenMP在節點內部線程級別的加速比，三是將MPI和OpenMP結合起來測試加速效果。

(1)

首先對解壓縮進行了節點間MPI的并行實驗，實驗的過程中每次將節點數目遞增，節點內部線程數目設置為1，來查看單純的MPI的并行處理的加速效果，實驗結果如表2所示。

表2 MPI并行實驗結果

從表2中可以看出，隨著節點數目的增加，解壓縮時間能明顯減少，通過計算并行加速比，能更加直觀地得出并行加速的效果，圖9展示了MPI并行加速比與理想加速比之間的差別。在實際中由于網絡帶寬等因素的影響，MPI并行處理的加速比不可能達到理想效果，不過本文實驗中由于節點數較少，MPI加速效果還是處于比較理想的狀態。

圖9 MPI節點間并行加速比

然后對OpenMP在節點內部線程級別并行進行測試實驗，保持整個測試在一個節點上進行處理，依次改變節點內線程的數目，得出的實驗結果如表3所示。

表3 OpenMP并行實驗結果

節點內部的OpenMP實現線程級別的并行，從結果可以看出，隨著線程數量的增加解壓縮時間能明顯減少，通過計算并行加速比，可以得出圖10所示加速比結果圖。

圖10 OpenMP并行實驗加速比

在OpenMP的并行實驗中，加速比直線并沒有按照較理想的加速比進行增長，一是OpenMP在每次并行處理時需要進行一些線程的初始化工作，二是由于并行處理時不同基本壓縮單元的處理時間不一定相同，這會導致一些無法避免的線程等待，影響并行效果。而圖10中在線程數為6時出現加速比向下波動的情況，是由于資源三號的通用壓縮塊結構由16個基本壓縮單元組成，當線程數能整除16時，并行能實現資源的負載均衡，一旦線程數不能整除16時，那么會存在一定的線程間等待，影響并行效果，這也為本文調優OpenMP并行線程數目提供一些借鑒，即將OpenMP的并行線程數設置為能整除通用壓縮塊結構中基本壓縮單元數目的值。

最后，將MPI和OpenMP進行結合進行實驗，保持每個計算節點內部8個線程并行，而計算節點的數目不斷增加，最終得出表4所示結果。

表4 MPI+OpenMP并行實驗

為直觀分析加速效果，將實驗結果的并行加速比與理想線性加速比進行對比作圖，得出圖11所示結果。

圖11 MPI+OpenMP并行實驗結果

從并行加速比的結果圖中可知，當并行的CPU核數增加到一定程度時，并行加速比增長將趨于平緩。造成這個現象的原因有很多，如網絡傳輸速度和延遲、OpenMP的線程創建開銷、CPU的調度、數據的復制和并行處理的壓縮塊之間的差異等。本文另外做了個小實驗，通過屏蔽解壓縮的解碼計算過程，即直接將解碼后的數據填充0值，保證了相同大小的數據量，但沒有解碼的計算過程，來單純的看除并行解碼計算之外的耗時。在4個節點的情況下，不管單節點的線程取1到16的任何值，所需耗時都在80±2s，在4節點8線程解壓縮時，這部分的耗時占比達到了47%左右，而這部分耗時是很難通過增加計算節點和線程數來減少的，所以表現上就是解壓縮單純的解碼計算的時間隨著節點和線程數的增加而減少，但解碼之外的耗時的占比卻在持續增加，這導致了加速比會隨著節點和線程數的增加而慢慢趨于平緩。

本文對程序的通用性和擴展性同樣進行了實驗，選取了資源三號2號星2017年10月18日密云站接收的基帶數據，通過配置資源三號2號星的處理配置文件和編寫具體解碼器類(本實驗直接使用的資源三號1號星的解碼器，對通用性的驗證沒有影響)和拼接類，可實現對資源三號2號星數據的流程處理。

3 結束語

本文針對地面基帶數據處理中處理步驟較多、通用性設計困難以及解壓縮計算復雜的特點，設計并實現了一個具有良好通用性和擴展性的地面基帶數據二級并行處理算法。文章首先對遙感衛星地面基帶數據處理系統的流程進行了介紹，設計了AOS幀通用的格式解析配置文件，實現了從幀同步到AOS幀格式分包的通用性處理，對解壓縮部分和拼接部分，通過模板方法和工廠模式以及設計通用解壓縮塊數據結構的方式，實現了可擴展性設計；其次文章對計算最復雜的解壓縮部分設計了二級并行處理模型，實現了分布式并行處理，利用MPI進行節點間粗粒度的進程級別并行處理，利用OpenMP進行計算節點內細粒度的線程級別并行處理，同時對計算資源的負載均衡進行良好的設計，保持在計算過程中具有極少的計算等待，避免了計算資源的浪費。算法的實驗結果表明，在以資源三號1星為基礎的程序上，配置資源三號2星的配置文件，然后實現資源三號2星的解碼器類和拼接寫入類即能實現資源三號2星的數據流程處理，說明算法的通用性和擴展性得到了驗證，在速度上利用5臺刀片服務器實現了資源三號1星的實時處理，說明算法具有較好的并行處理性能。下一步工作的重點是進一步驗證算法的通用性和可擴展性，實現更多衛星的驗證處理工作，以期實現高分系列衛星的快速實時處理。