基于SOIS EDS的實例化設計

張煦冬，呂良慶，安軍社

(1.中國科學院復雜航天系統電子信息技術重點實驗室 國家空間科學中心，北京 100190；2.中國科學院大學 計算機與控制學院，北京 100049)

0 引 言

針對不同的任務需求，航天器設計出現了種類繁多的接口方式和通信方案，工程項目中的星上數據管理系統往往是個性化設計，使得跨項目重用設備、部件、軟件的難度增大。為解決這一問題，特別是跨組織的互聯互通，空間數據系統咨詢委員會(consultative committee for space data systems, CCSDS)開展了航天器接口業務(space onboard interface services, SOIS)領域的研究工作[1]。SOIS領域主要解決的是航天器數據管理的接口服務問題。SOIS架構針對航天器系統設計提出了標準的層次劃分，使得個性化設計的設備、部件可以在幾乎不更改軟件的情況下連入系統。為此SOIS工作組提出了基于SOIS架構的EDS(SEDS)的相關建議標準。

1 SEDS簡介

為解決異構部件的兼容使用問題，每個部件需要一個自描述EDS，內容是數據格式、接口、功能、協議等[2]。當一個部件要接入一個系統時，系統通過解析這個部件的EDS，獲得它在系統中運行所需要的信息，實現對部件的識別和配置。符合CCSDS SOIS 876.0[3]規定的EDS稱為SOIS EDS(SEDS)。在SEDS文件中按照SOIS的層次劃分描述部件的信息，支持SOIS架構的實現。SEDS所使用的元素和類型的抽象概念及其之間的關系如圖1所示。

圖1 SEDS的關鍵元素和抽象類型[3]

SEDS文件使用可擴展標記語言(eXtensible Markup Language, XML)[4]按照圖1描述系統定義，構建XML文件。

圖1中，SEDS以Datasheet元素為根元素，Package元素包含Data Type、Interface、Component這3部分，其中Data Type包括9種數據類型的定義：兩種復雜數據類型，數組類型、容器類型；6種標量類型變量，整型、二進制型、枚舉型等；一種范圍數據類型，表示變量的取值范圍。

SEDS元素類型分為兩類，語法類型和語義類型。語法類型指SEDS元素的拼寫語法規則，比如特定的字符串、變量的比特數、變量的編碼方式等。語義類型指SEDS元素代表的行為和含義[1]。在SEDS XML文件中使用的元素和屬性的標簽所對應的這兩類類型在術語字典(dictionary of terms, DoT)[5]中定義。DoT以XML Schema的形式供用戶使用。

文件對象模型(document object model, DOM)[6]是解析XML文件的方法之一。XML和DOM都是萬維網聯盟(world wide web consortium, W3C)的推薦標準。DOM解析文件的方法是將XML文件的元素作為節點組成樹形數據結構[7]，通過對樹的通用訪問，實現對信息的歸納。很多程序設計語言(如java，python)都支持DOM方法。

2 基于SEDS的系統設計

采用EDS進行星載軟件設計的路線需要解決工具鏈的建設和EDS的設計問題。

EDS的編輯、傳遞和解析，以及系統內部的管理信息庫(management information base, MIB)[8]配置過程應該是工具化的，即工具鏈設計。異構系統之間交換EDS需要的轉換工具如圖2所示。

異構系統是由不同機構組織按照自身的需要設計的，在需要進行互聯互通時，異構系統及其軟件系統提供的功能業務都需要繼承使用，而不是重新設計。這也是引入EDS概念的應用背景之一。為此，異構系統之間傳遞的EDS應遵循統一的標準(如CCSDS由space assigned numbers authority(SANA)統一管理的、用XML描述的SEDS[9])。通常設備方將自身的信息(requirement list, RL)按照系統要求的實現一致性聲明(implementation conformance statement, ICS)的規則，使用ICS編輯工具或手工填寫數據表單。876.0中有ICS的推薦內容，可以根據需要補充設計，類似于接口數據單(interface data sheet, IDS)。設備方可以通過SEDS編輯工具，或直接手工編輯，生成SEDS的XML文件。

系統方接收的個性化EDS文件用以繼承系統內部的數據設計。道理上EDS文件是對外的數據隔離墻，可以進行統一設計。但是由于繼承系統內部原有的設計未必是規范化的，而且不同業務的MIB和使用的EDS內容千差萬別，使得EDS文件難以統一設計。因此這一點只能通過規范化ICS來針對性、逐一、積累完成。其設計的有限性則取決于系統架構的規范性，如規范的CCSDS SOIS架構和歐空局的包應用標準(package utilization standard, PUS)業務[10]。

數據解析工具的作用是將SEDS XML文件解析成系統可以識別的個性化EDS文件。這一解析過程是按照SEDS的XML編輯語法進行的，包括提取信息、綜合屬性和組織數據對象等過程，可以采用常規的XML解析工具軟件(函數)來完成。最后按照系統內部的數據設計生成實例化EDS文件，供系統直接使用，實現對系統已有部分的繼承。而在進行系統新增業務設計時，直接按照個性化ICS、SEDS XML文件和實例化EDS的思路進行規范化設計，從而實現新增部分和繼承部分在EDS表達方式上的統一，方便系統業務的積累。

在EDS設計方面，EDS的產生可以來自于模型化業務需要的數據結構，包括業務的輸入、輸出，以及內部的MIB管理的信息，因服務模型不同而不同。其主要思路是服務模型的MIB應有明確的格式，內容可以配置。EDS在格式設計上應具有可修改性和可擴充性，以允許同屬一個服務模型的不同實例業務的設計，從而實現業務的即插即用，適應不同系統的不同配置需要。

圖2 異構系統之間的EDS轉換過程

圖2中有兩種工具使用場景。一種是互聯雙方是對等機構組織，則以SEDS XML文件為界，各自開發各自的工具。這種情況下，雙方各自有自己的ICS編輯工具、SEDS編輯和解析工具，輸出的SEDS XML文件是對外表達的自描述信息，就如同個人的名片那樣，可以被任何可識別這種信息的系統所接納。另外一種是單純的設備接入系統的場景。這種情況下，設備方可以直接使用系統方提供的ICS和SEDS編輯工具，規范ICS表單和SEDS XML文件的生成，也可以直接手工編寫SEDS XML文件，從而最大限度地降低了設備方使用EDS的難度和工作量，也不改變約定IDS的工作習慣。通過這一基于工具的過程，互聯雙方可以表達自身的需求，了解對方提供的服務能力，達到需求自動匹配的效果。而上述兩種場景既有利于接口標準化，也有利于非標準化設備繼承使用。

3 基于SEDS的工具鏈設計

3.1 從ICS到SEDS XML

表1將CCSDS 876.0推薦的ICS表進行補充和整理，這些內容所使用的數據元素和圖1中SEDS規定的內容對應。

表1 在CCSDS 876.0推薦的ICS基礎上的補充設計

表1(續)

在ICS的基礎上，經過編輯過程，將用戶填寫好的個性化需求ICS轉化為SEDS的XML文件。編輯過程依據SEDS和DoT的規則進行。這一過程可以手工完成，也可以建造相關的編輯工具，以方便項目使用。

3.2 SEDS XML文件的解析工具

SEDS XML文件解析工具實現從SEDS個性化XML文件到實例化EDS文件的轉化，即二者之間的映射過程。它的轉化過程和使用的數據結構如圖3所示。

圖3 SEDS XML文件的解析過程

圖3中使用DOM方法讀入XML文件中的元素數據作為節點，形成樹形數據結構，稱為文檔樹。文檔樹和XML文件之間有嚴格元素數據的對應關系。通過文檔樹可以添加、更改、刪除、查找XML文件中的元素。

XML文件中的所有元素標簽都要在解析工具中識別，相同標簽的節點組成鏈表。在SEDS規則下，標簽相同的元素具有一致的屬性，為下一步提取元素屬性的值，形成SEDS數據對象做準備。每種數據類型定義所需的元素構成一個SEDS數據類型定義實體。圖3中以數組類型為例，數組類型包含2種元素，ArrayDataType元素和Dimension元素，后者是前者的子元素，因此SEDS數組類型定義包括2個鏈表，是由這2種元素節點組成的。從SEDS元素、ICS到解析過程的對應關系見表2。從表中可以看出解析過程需要對所有的SEDS元素進行針對性處理，而ICS的填寫只關心內容。

圖3中的SEDS數據對象是對SEDS XML元素定義的實現，例如，SEDS對數組數據對象的定義是標簽為ArrayDataType的元素，其中的屬性定義了每個數據單元的數據類型，它的子元素Dimension定義了數組的長度。相同SEDS XML元素定義對應的SEDS數據對象是同一類型的，它們的集合對應于圖3中的SEDS對象鏈表。

表2 SEDS標簽對應關系

一個SEDS數據對象中包含對應的SEDS XML元素的所有信息，但輸出文件是根據系統需要，對ICS中填寫的數據值選擇輸出后的實例化EDS，可以直接提供給系統使用。因此從ICS的內容開始反映的就是用戶的個性化需求，此后的XML文件中的數據與ICS內容是等價的，而實例化EDS則是針對某個系統的輸出。這種針對性表現在某個系統的特定數據格式和選擇的內容上。(例如4.2節所舉示例)

4 1553B EDS的實例設計

4.1 1553B EDS的應用背景

EDS的概念源于即插即用技術。在網絡環境下，首先需要在鏈路協議層解決EDS的傳送交換問題，然后是反映傳輸需求的EDS內容設計，即插即用的傳輸協議設計。在此以1553B總線為例進行說明。

1553B總線是總線型、主從式的單工通信方式，總線上的總線控制器(bus controller, BC)控制著全部的通信協議過程[11]。為不影響接入的設備終端(remote terminal, RT)原有的通信設計，1553B總線即插即用協議[12]是在已有的鏈路層通信協議基礎上，增加在初始階段交換RT EDS的協議過程，由BC根據RT EDS動態配置和調度總線，實現RT的自動加入和撤出，并滿足其通信需求，系統仍然能夠穩定運行。而RT方只需要遵守初始握手協議要求，其設計重點放在了RT EDS的內容設計上[13,14]。

4.2 1553B總線的ICS設計

根據1553B總線通信協議的特點，BC方需要了解的RT傳輸需求包括兩個部分，即如何握手和子地址消息配置需求。這兩部分通過RT EDS定義，首先反映在用戶填寫RL完成后的ICS中，見表3。

4.3 1553B總線的RT SEDS XML文件

根據用戶填寫的1553B總線ICS，可以編輯相應的1553B總線的RT SEDS XML文件，如圖4所示。

圖4中，第6行至10行定義了矢量字數據域是數組類型。第11至19行定義了子地址定義的第1個字為容器類型。第20至25行規定了子地址定義是容器類型。第26至30行為子地址定義數組規定了發送子地址定義和接收子地址定義這2個域的格式。第31行至第144行定義了矢量字和子地址消息定義的各個字段的值。

圖5為1553B總線SEDS實例的文檔樹結構，元素的屬性數據作為元素節點的葉子節點。解析過程是將XML文檔樹的節點轉化為SEDS數據對象的過程。例如，圖5中的ArrayDataType節點是SEDS定義的數組類型變量，該節點及其所有子孫節點所構成的分支樹對應于SEDS的數組類型數據對象。需要說明的是圖3中的節點鏈表是元素節點組成的鏈表，不包含屬性節點，因為通過元素節點即可訪問屬性節點，不需要將屬性節點組成鏈表。

表3 1553B總線即插即用協議所需的ICS

圖4 1553B總線RT SEDS XML文件

圖5 1553B實例的文檔樹結構

4.4 1553B EDS的實例化輸出

在收到圖4的XML文件后，系統根據自身使用的RT EDS的格式定義(見表4)，進行針對性的信息提取和轉換，生成實例化的EDS文件(如圖6所示)。

本文設計的SEDS解析工具輸出的結果如圖6所示，為了方便理解增加了注釋。

表4 RT EDS格式[13-15]

圖6 二進制文件結果

圖6中矢量字定義數組的前5個值，發送子地址定義數組前2個值,以及接收子地址前3個值見表5。

5 結束語

在航天器數據系統中使用EDS，使系統能夠對個性化需求做出通用性設計。通用性表現在處理方法上，是指對每個部件的數據設計上，都要包括3個數據對象(ICS、SEDS XML文件、EDS)，以及對它們進行轉換的工具鏈設計思路。3個數據對象內容是系統針對性選擇的信息結果。正因為如此，EDS技術可以解決異構系統之間的信息傳遞和互聯互通問題，以及新增設計和原有設計的兼容、繼承、重用等問題。工具鏈的設計和使用能夠進一步擴充EDS內容和應用范圍，并方便使用。本文介紹的1553B總線即插即用SEDS實例設計說明了這一思路的可行性。

由于星上和地面EDS都可以采用XML進行描述，因此SEDS與XML Telemetric and Command Exchange (XTCE)[15]可以銜接。XTCE主要描述遙測遙控，這恰與PUS的請求與報告可以掛鉤，應作為EDS內容的一部分，加入EDS工具鏈中的數據庫，供通用設計使用。當積累的標準服務、請求、報告的內容足夠多時，可以支持重用、數據挖掘，作為深度學習的數據源使用。再擴展，可以支持星地一體化智能信息系統的設計和建設。

表5 實例化EDS結果含義