技術摘記

1999-06-03 Telemetry簡介

建立於 2010-12-06, 週一

Packet Telemetry概要



cube1 簡介



主要的目的在於定義適當的資料結構(data structures)﹐用以傳遞太空載具上的資料源(data sources)至地面的資料終端(data sinks)﹐如圖一所示。

 

19990603_fig01

 

圖一 、 CCSDS Packet Telemetry Data system

 

 

其具備以下的特點:


允許多個應用程序(Application Process)可以依本身的任務需求來產生適合的資料單元,並藉由太空載具上的資料處理系統,以高可靠度的方式,經由太空—地面的通訊管道,將這些不同的應用程序所產生的資料傳送回地面接收站。而後,地面控接收站可以回復每一個別應用程序的資料以提供給後續的處理程序。CCSDS定義兩種資料結構—資料封包(Source Packets)傳輸框架(Transfer Frames)。為了共享傳輸資源(Sharing Transmission Rsource),使用多工程序(multiplexing process),以便將多個不同的應用程序所產生的資料封包(Source Packets),依序地安插進傳輸框架(Transfer Frames)中。

 

ball 資料封包(Source Packet)


資料封包(Source Packet)是一種由太空載具上的應用程序以固定或可變的時間間隔所產生的資料結構,其長度可以是固定或可變的。除了格式化的封包標題(Packet Head)之外,封包(Packet)中的資料內容可以完全由個別的應用程式所主導。資料封包主標題(Source Packet Primary Header)包含了應用程序辨識碼(Application Process Identifier),用以將不同應用程序所產生的資料送至適當的地面處理單元。這個標題(Header)亦包含了如資料長度、順序和其它與封包相關的訊息。


資料封包旳資料結構中亦提供了一個選擇性的資料封包的次標題(source packet secondary header)欄位,可以提供資料封包時間的標籤(time-tagging),及傳遞和應用程序相關的輔助資訊。資料封包的分割(Source Packet Segmentation)亦是一種選擇性的機制,可以分割較長的封包,使其成為一系列較短的封包。如此一來可以避免某一傳輸用來頻道由單一的資料源(Source)所獨佔。

 

ball 傳輸框架(Transfer Frame)



傳輸框架(Transfer Frame)是一種資料結構,經由充滿雜訊的太空—地面的通訊管道(Space-to-Ground Channel),來傳送經過封裝後的資料。傳輸框架主標題(Transfer Frame Primary Header)中包含了一些重要的資訊,使得地面的資料處理系統可以將每一個傳輸框架送至其預定的目地的。傳輸框架亦提供必要的機制可以以不同的速率來處理不定長度(varialbe-length)的資料封包(Source Packet),而這些資料封包可以經由多工程序結合成一個具固定的長度同步資料傳輸框架(synchronous stream of fixed-length coded transfer frames)。由於傳輸框架的長度是固定的,所以較小的資料封包可以包含於一個傳輸框架中,但是較長的資料封包則可能跨越兩個以上的傳輸框架。所以,一個資料封包可以在一個傳輸框架中的任何一位置開始或結束。因此,傳輸框架中的資料區塊可以整個用來傳輸資料封包,不用再刻意調整資料封包的長度或是次序,來滿足傳輸框架的長度。

當沒有足夠的封包資料(Packet Data)可以填滿整個傳輸框架,但又必須傳送時,一個閒置封包(Idle Packet)的機制可以用來填補不足的資料封包。其目的在於當資料不足時,可以維持傳輸端和資料擷取端間的傳輸同步。除了傳送封包資料(Packets)之外,傳輸框架亦可以傳遞兩個選擇性的欄位—傳輸框架次標題(Transfer Frame Secondary Header)操作控制欄位(Operational Control Field)。傳輸框架次標題可以用來傳遞固定長度任務特有的資料(Mission-Specific data),而操作控制欄位可以用於回應Telecommand的狀態和傳遞太空載具的活動訊息。除了傳送格式化的封包資料之外,傳輸框架還可以用來傳遞非標準的資料(Privately Defined Data)

 

ball 共享傳輸資源(Sharing Transmission Rsource)



Telemetry定義了兩種共享傳輸資源的方式:一者為虛擬頻道(Virtual
Channlization)
,另一者為資料封包分割(Source Packet segmentation)


虛擬頻道(Virtual Channlization)是一種允許不同的應用程序所產生的資料封包,可以"虛擬"的獨佔實體頻道(Physical Channel)之機制,每一個傳輸框架都被標示屬於編號一到八的虛擬頻道(Virtual Channel)。虛擬頻道通常是用於分隔具有不同特性的資料源(Source)或目的地(Destination)的資料封包。

資料封包分割(Source Packet segmentation)是利用載具上的資料系統將較長的資料封包分割成一系列具固定長度、較小的資料封包片段(Souorce Packet Segment)。來自不同來源的資料封包片段可以經由多工程序,和其它較小的資料封包一起進入單一的虛擬頻道。藉此提供共享此一虛擬頻道的能力。

Telemetry 的資料流程如圖二所示。

 

19990603_fig02

圖二、Telemetry 的資料流程

 

cube1 資料封包格式(Source Packet Format)




資料封包是由兩個主要的欄位,連續不間斷的以下列之順序所組成:

 

dot2 封包主標題(Packet Primary Header),有48個位元(bits)。

dot2 封包資料欄位(Packet Data Field),其長度不定(variable)。


資料封包的長度至少為7個位元組(Otets),最長不超過65542個位元組。
當一個資料封包其資料欄位中含有閒置資料(Idel Data)時,稱之為閒置封包(Idle Packet)
若單一程序連續地產生一系列的資料封包,這一系列的資料封包可以設計成資料封包群組(Group of Source Packets)。 資料封包的格式如圖三所示。

 



19990603_fig03a

 

19990603_fig03b

圖三、 資料封包的格式

 

 

ball 封包主標題(Packet Primary Header)



封包主標題有四個欄位,以下列順序所組成

pr_diam 版本號碼(Version Number)


此一欄位有3個位元(bits),用以表示其資料單元為資料封包。目前只有一個版本,此一欄位之值應設為"000"。其目的有二:第一、用以分辨資料封包(Source Packet)和資料封包片段(Source Packet Segment)。第二、保留引入其它資料結構的擴充性。

 

pr_diam 封包識別(Packet Identification)欄位


此一欄位佔有13個位元(bits),此一欄位又可以細分為以下三個次欄位:

 

dot1 型態指示(Type Indicator)欄位


佔有1個位元,其中"0"表示此封包為Telemetry Packet,"1"則代表此封包為Telecommand Packet。

 

dot1 封包次標題旗標(Packet Secondary Header Flag)

 

佔有1個位元,"0"表示封包中沒有包次標題,"1"則表示封包中含有封包次標題

 

dot1 應用程序識別(Application Process Identifier)欄位



佔有11個位元,在同一個主頻道(Master Channel)中,應用程序識別欄位的值應隨著不同的應用程序而不同。對於閒置封包(Idel Packet)而言,應用程序識別欄位的值應為"11111111111"。

 

pr_diam 封包順序控制(Packet Sequence Control)



此一欄位佔有16個位元,可以細分為兩個次欄位:

dot1 群組旗標(Group Flag)


佔有2個位元,其意義如下:

"01"表示資料封包群組的第一筆資料。

"00"表示資料封包群組中接續傳遞的資料。

"10"表示資料封包群組的最後一筆資料。

"11"則表示此封包不屬於資料封包群組,是獨立的封包。

dot1 資料順序計數(Source Sequence Count)



佔有14個位元。對於由不同應用程序所產生,標示著不同程序識別碼(Application Process Identifier)的資料封包,提供順序計數的功能。其計數範圍是連續的,為1到16384的循環計數。但對於閒置封包則不加以計數。當計數值未達16384之前,除非萬不得以,應避免重置計數值。若在計數值未達16384之前重置計數值,則無法保證資料傳輸的完整性。此一欄位的目的在於維持資料封包的順序,避免因多工程序使得接收到資料封包的順序產生錯誤。

 

pr_diam 封包資料長度(Packet Data Length)



此一欄位佔有16個位元,表示封包資料欄位(Packet Data Field)的長度,其值為實際資料長度的位元組(Otets)減1。此一欄位的數值是依據實際資料長度而變的,但正確的值應介於0到65536之間。

 

ball 封包資料欄位(Packet Data Field)



此一欄位應不間斷的接續著封包主標題(Packet Primary Header),且應至少應包含封包次標題(Packet Secondary Header)原始資料欄位(Source Datat Field)此二者其中的一個。封包資料欄位至少要包含一個位元組(Octet)的資料。

 

pr_diam 封包次標題(Packet Secondary Header)



此一欄位的長度是可變的。此一欄位的存在與否可由封包主標題中,封包次要標題旗標(Packet Secondary Header Flag)來決定。當這個封包資料欄位中不包含原始資料欄位(Soure Data Field)時,則此欄位則是必要的。若封包資料欄位中包含原始資料欄位,則此欄位則是選擇性的。若封包中存在此一欄位,則其應由以下的幾種組合所構成:

dot1 封包次標題資料欄位(Packet Secondary Header Data Field)

dot1 封包次標題時間碼欄位(Packet Secondary Header Time Code Field)

dot1 封包次標題資料欄位接續著封包次標題時間碼欄位




這個欄位是用來放置符合CCSDS定義的輔助資訊,如時間、太空載具的位置、姿態及高度等訊息,與資料封包(Source Packet)一起傳送。

 

 

pr_diam 原始資料欄位(Source Data Field)



此欄位的長度是可變的。其中包含由應用程序(Application Process)所產生的原始資料(Source Data)或是閒置資料(Idle Data)

 

 

cube1 資料封包片段(Source Packet Segment)

 


資料封包分割(Source Packet Segmentation)程序是應用於原始資料封包(Orginial Source Packet),將其封包資料欄位(Packet Data Field)中的資料分割成較小片段,並用兩個或兩個以上的資料封包片段來傳送這個資料封包。資料封包片段的格式相似於資料封包格式,其包含兩個主要的欄位:片段標題(Segment Header)片段資料欄位(Segment Data Field)。其中,片段資料欄位的長度除了資料序列中的最後一筆資料外,其餘的資料片段長度是固定的,以符號LSEGMENT來表示。LSEGMENT的值可以是256、512或是1024個位元組,由傳輸框架(Transfer Frame)中的片段長度辨識碼(Segment Lenght Identifier)來決定。

資料封包分割程序不可以用於資料封包群組(Group of Source Packets),因為這兩種資料格式使用相同的欄位來標記被分割的資料片段的順序。這意味著資料封包群組中的每一個資料封包的長度,應受到傳輸框架(Transfer Frame)的限制。再者,資料封包分割程序亦不可以用於閒置封包(Idle Packet),因此,在一個虛擬頻道(Virtual Channel)中閒置封包的長度也應受傳輸框架的限制。

 

ball片段標題(Segment Header)



此一欄位佔有6個位元組(Octets),並分成以下的三個次欄位:

 

pr_diam 版本號碼(Version Number)



此一欄位佔有3個位元,其值應為"100",用以代表此封包為資料封包片段(Source Packet Segment),以便和資料封包加以區分。除此之外,並保留引入其它資料結構的擴充性。

 

pr_diam 片段識別(Segment Identification)欄位



此一欄位佔有13個位元,其值應和原始的資料封包中的內容完全一致。

 

pr_diam 封包順序控制(Segmet Sequence Control)



此一欄位佔有32個位元。可以細分為三個次欄位:

dot1 片段旗標(Segment Flag)


佔有2個位元,其意義如下:

"01"表示資料封包片段的第一筆資料。

"00"表示資料封包片段中接續傳遞的資料。

"10"表示資料封包片段的最後一筆資料。

dot1 資料順序計數(Source Sequence Count)


佔有14個位元,其包含原始資料封包中的資料順序計數

 

dot1 剩餘封包長度(Residual Packet Length)


佔有16個位元,其值代表原始資料封包中的資料封包欄位裏,還剩下待傳送的位元組(Octets)的數目減一,這個數目包括本身這個資料片段所傳送的資料數目。

 

ball 片段資料欄位(Segment Data Field)



這個欄位的長度,除了片段序列中的最後一筆資料外,其長度應為LSEGMENT,而最後一筆資料的長度則為原始資料封包中所剩餘的資料長度,以符號R表示。對於在一個虛擬頻道中傳遞的資料片段而言,LSEGMENT的長度是由傳輸框架(Transfer Frame)中的片段長度辨識碼(SegmentLenght Identifier)所決定,其值可以為256、512或是1024。

資料封包片段的格式如圖四所示。

 

19990603_fig04

圖四、 資料封包片段的格式


圖五為資料封包分割(Source Packet Segmentation)程序的操作示意圖。

 

19990603_fig05

圖五、資料封包分割(Source Packet Segmentation)程序操作示意圖

 

 

cube1 傳輸框架(Transfer Frame)



傳輸框架提供了一個資料結構用以傳送:

dot2 資料封包(Source Packet)

dot2 資料封包片段(Source Packet Segment)

dot2 閒置封包(Idle Packet)

 

dot2 非標準的資料(Privately Defined Data)



傳輸框架由以下的欄位所組成:傳輸框架主標題(Transfer Frame Primary Header)傳輸框架次標題(Transfer Frame Secondary Header)傳輸框架資料欄位(Transfer Frame Date Field)操作控制欄位(Operational Control Field)框架錯誤控制(Frame Error Control Field)

傳輸框架的長度在整個任務階段(Mission Phase)中,必須保持不變。在1992年發行的Telemetry Channel Coding Blue Book中定義傳輸框架的長度為8920個位元(bits)。

所有具有相同傳輸框架版本號碼(Transfer Frame Version Number)及相同的太空載具辨識碼(Spacecraft Identifier),並共用相同的實體頻道(Physical Channel)的傳輸框架,組成所謂的主頻道(Master Channel)。一個主頻道通常是由一至八個虛擬頻道(Virtual Channel)所組成。

傳輸框架的格式如圖六所示。

 

19990603_fig06

圖六、傳輸框架格式

 

 

ball 傳輸框架主標題(Transfer Frame Primary Header)



此欄位佔有2 個位元組(Octets),並由以下的幾個欄位所組成:

 

pr_diam 傳輸框架版本號碼(Transfer Frame Version Number)

 

佔有2個位元,其值應設為"00"。

 

pr_diam 傳輸框架識別(Transfer Frame Identification)

 

此14個位元的欄位可以細分為以下的三個次欄位:

dot1 太空載具辨識碼(Spacecraft Identifier)

dot1 虛擬頻道識別碼(Virtual Channel Identifier)


此欄位含有3個位元,代表八個不同的虛擬頻道。

 

dot1 操作控制欄位旗標(Operational Control Field Flag)

 

此旗標(1個位元)用以決定操作控制欄位是否存在,"0"表示沒有操作控制欄位,"1"表示含有操作控制欄位

 

pr_diam 主頻道計數(Master Channel Count)

 

佔有8個位元(Bits),為0到255循環計數,用以記錄在一個指定的主頻道中所傳送之傳輸框架的順序。當計數值到達255之前要避免重置此計數值,若因不可避免的情況重置計數值,則就無法得知所傳送之傳輸框架的完整性。

 

pr_diam 虛擬頻道計數(Virtual Channel Count)

 

佔有8個位元(Bits),為0到255循環計數,用以記錄在一個指定的虛擬頻道中所傳送之傳輸框架的順序。當計數值到達255之前要避免重置此計數值,若因不可避免的情況重置計數值,則就無法得知所傳送之傳輸框架的完整性。此一欄位的目的在於提供每一個虛擬頻道獨立計數的能力,可以用系統化的方式將資料封包片段傳輸框架資料欄位中擷取出來。

 

pr_diam 傳輸框架欄位狀態(TransferFrame Field Status)

 

此欄位可細分成以下的五個次欄位:

 

dot1 傳輸框架次標題旗標(Tramsfer Frame Secondary Header Flag)

 

這個旗標用來指示傳輸框架中是否包含傳輸框架次標題,"0"表示沒有傳輸框架次標題,"1"表示含有傳輸框架次標題。在整個任務階段(Mission Phase)中,傳輸框架次標題旗標的值要維持不變(static),因為傳輸框架次標題所含的訊息是和主頻道(Master Channel)相關的,對於一個指定的主頻道而言,傳輸框架中是否包含這一欄位應固定不變。

 

dot1 同步旗標(Synchronization Flag)

 

這個旗標用以標示插入傳輸框架資料欄位(Transfer Frame Data Field)中的資料型態。"0"表示插入框架中的是位元同步(Octet-Synchronoized)、遞增順序(Forward-Ordered)的資料封包(Source Packet)/片段(Segment)或是閒置封包(Idle Packet),"1"則代表插入框架中的是非標準資料(Privately Defined Data)型態。同樣地,在任務階段(Mission Phase)中,對於一個指定的虛擬頻道(Virtual Channel)而言,這個旗標的值應維持不變。

 

dot1 封包順序旗標(Packet Order Flag)

 

若同步旗標(Synchronization Flag)的值為"0",則CCSDS保留此一旗標給未來擴充之用。若同步旗標(Synchronization Flag)的值為"1",則此旗標是無定義的(Undefined)。

 

dot1 片段長度辨識碼(Segment Lenght Identifier)

 

若一個虛擬頻道不支援資料封包分割(Source Packet Segmentation),則片段長度辨識碼(Segment Lenght Identifier)應設為"11"。若虛擬頻道支援,則其代碼之意義為:

dot2 "00"表示LSEGMENT=256 位元組(OCtets)。

dot2 "01"表示LSEGMENT=512 位元組(OCtets)。

dot2 "10"表示LSEGMENT=1024位元組(OCtets)。

對於封包資料片段中的最後一筆資料而言,其片段資料欄位(Segment Data Field)的長度可能小於LSEGMENT。在一個虛擬頻道中,資料封包(Source Packet)中封包資料欄位(Packet Data Field)的長度不可以大於LSEGMENT。同樣地,在整個任務階段(Mission Phase)中,對於一個指定的虛擬頻道(Virtual Channel)而言,這個辨識碼的值應維持不變。若同步旗標(Synchronization Flag)的值為"1",則此辨識碼是無定義的(Undefined)。

 

dot1 首位標題指標(First Header Pionter)

 

在傳輸框架資料欄位(Transfer Frame Data Field)中的位元組(Octets)是以漸升(Ascending)的數字來表示,第一個位置以0來表示,然後依序增加。若同步旗標(Synchronization Flag)的值為"0",則首位標題指標(First Header Pionter)包含了在傳輸框架資料欄位(Transfer Frame Data Field)中第一個資料封包(Source Packet)片段(Segment)中的主標題(Primary Header)的起始位置。

若在同一個傳輸框架資料欄位中仍含有其它的資料封包(Source Packet)片段(Segment)時,其位置可以由封包資料長度欄位(Packet Data Lenght Field)位或是片段長度辨識碼(Segment Lenght Identifier)所含的訊息得知。對於資料封包片段的最後一筆資料而言,則可利用剩餘封包長度(Residual Packet Length)這個欄位的資訊來求得。

同一個擬虛頻道中,若是資料封包或是片段第一個主標題起始於在傳輸框架 (Transfer frame)N的傳輸框架資料欄位(Transfer Frame Data Field)的未端,並延伸至下一個傳輸框架M,則在傳輸框架N中的首位標題指標將指示資料封包或是片段第一個主標題起始位置。而對於傳輸框架M而言,首位標題指標將忽略這一個分開的主標題,而指向下一個資料封包或是片段的主標題起始位置。

若在傳輸框架 (Transfer frame)的傳輸框架資料欄位(Transfer Frame Data Field)中並不含有任何資料封包或是片段的主標題,則首位標題指標之值應設為"11111111111"。若在傳輸框架資料欄位中含有置閒封包(Idle Packet)時,則首位標題指標之值應設為"11111111110"。若同步旗標(Synchronization Flag)的值為"1",則此指標是無定義的(Undefined)。



ball 傳輸框架次標題(Transfer Frame Secondary Header)

 

此欄位含有和虛擬頻道或主頻道相關的的資訊。不管是對於虛擬頻道或主頻道,在整個任務階段,其長度都應保持定值。其由以下的兩個欄位所組成:

 

pr_diam 傳輸框架次標題識別欄位(Transfer Frame Secondary Header Identification Field)

 

此欄位又可再細分為兩個次欄位:

 

dot1 傳輸框架次標題版本號碼(Transfer Frame Secondary Header Version Number Field)

 

佔有兩個欄位其,值應設為"00"(目前只有一個版本)。

 

dot1 傳輸框架次標題長度欄位(Transfer Frame Secondary Header Length Field)



其值為傳輸框架次標題長度的位元組數目減一。

 

pr_diam 傳輸框架次標題資料欄位(Transfer Frame Secondary Header Data Field)

 

ball 傳輸框架資料欄位(Transfer Frame Date Field)



所有的資料封包(Source Packet)片段(Segment)將以連續不間斷、遞增順序(Forward order)的方式插入傳輸框架資料欄位中。若不是以此種方式加入傳輸框架資料欄位,則就是屬於非標準資料(Privately Defined Data)型態,必須設定好其相關的旗標。不同應用程序所產生的封包或片段(其中含有不同的應用程序識別碼(Application Process Identifier)),可以應用多工方式,以任意的組合插入傳輸框架資料欄位中。

傳輸框架資料欄位的長度受限於傳整個輸框架的總長度(8920 bits, 1992 CCSDS)。資料封包(Source Packet)或片段(Segment)可以分別在不同的虛擬頻道中傳送,或是混合於同一個虛擬頻道中,但是資料封包(Source Packet)或片段(Segment)則不可以和非標準資料(Privately Defined Data)混合在同一個虛擬頻道中傳送。

當沒有資料封包或片段可以填入傳輸框架資料欄位時,傳輸框架將會傳送其資料欄位中只含有閒置資料(Idle Data)的框架。傳送只含有閒置資料(Idle Data)的框架的目的在於和地面接收站維持同步(Synchronization),或者是為了資料的正確性而必須要傳送傳輸框架次標題(Transfer Frame Seconday Header)操作控制欄位(Operational Control Field)。含有閒置資料(Idle Data)的框架可以在一個傳遞資料封包(Source Packet)或片段(Segment)的虛擬頻道中傳送,但最好是用另一個獨立的虛擬頻道來傳送。

ball 操作控制欄位(Operational Control Field)



這個欄位的前導位元(Leading Bit)是型態旗標(Type Flag),其意義如下:

dot2 若型態旗標為"0",則表示此欄位為回報型態一(Type-1-Report),其中含有命令鏈結控制指令(Command Link Control World)。

 

dot2 若型態旗標為"1",則表示此欄位為回報型態二(Type-2-Report)。回報型態二的第一個位元顯示這個回報的用途,若第一個位元為"0"則表示為計畫相關的回報,若第一個位元為"1"則保留給CCSDS,以作為未來其它的應用。



ball 框架錯誤控制欄位(Frame Error Control Field)



若傳輸框架的傳送是採用Reed-Soloman編碼,則框架錯誤控制欄位是選擇性的。若不是採用Reed-Soloman編碼方式傳送,則框架錯誤控制欄位是必須的。此欄位的目的在於提供偵測出在傳送過程中產生錯誤的能力。

 

Wednesday the 17th. ISUAL. All rights reserved.