RAPORTUL
DE CERCETARE
PROIECT: Contributii la Misiunea
Spatiala Euclid (CEM)
Etapa de executie nr. 1/14.12.2012
Definirea cerintelor
Activitatea 1.2: Definirea cerintelor si strategiei pentru algoritmul de
comprimare.
Introducere
Prezentul
contract CEM (Contribution to the Euclid Mission) se refera la contributia
Institutului de Stiinte Spatiale la realizarea misiunii spatiale Euclid.
Misiunea spatiala Euclid este o misiune stiintifica a Agentiei Spatiale
Europene, aprobate in Octombrie 2011 si programata sa fie lansata in spatiu in
anul 2019, in jurul punctului Lagrangean L2 din sistemul Soare-Pamant.
Institutul de Stiinte Spatiale (ISS) din Bucuresti este membru al consortiului
Euclid din iunie 2011.
Contibutia
ISS la proiectul Euclid prezentata in acest contract se refera la realizarea,
testarea si validarea unui program software pentru compresia blocurilor masive
de date (lossless compression) furnizate de cele doua instrumente ale misiunii
spatiale Euclid. Euclid este dotat cu doua instrumente de achizitie a
imaginilor bidimensionale in domeniul vizibil (VIS – Visual Instrument) si infrarosu
apropiat (NISP – Near Infrared Spectro-Photometer). Cele doua instrumente isi
iau imaginile de la un singur telescop cu diametrul de 1,2 m, telescop cu care
este dotata platforma experimentului stiintific Euclid. Deoarece sursa datelor
este comuna (telescopul), secventele de achizitie a celor doua instrumente sunt
sincronizate. Succesiunea achizitiilor de date se face la un interval de 803
secunde pentru fiecare instrument, desi rezolutia, timpul de achizitie si
numarul de inregistrari difera pentru fiecare instrument in parte. Astfel,
instrumentul VIS realizeaza o singura achizitie de imagine in vizibil, cu o
rezolutie spatiala inalta (o singura secventa de achizitie) in timpul unei etape
de inregistrare. Instrumentul NISP realizeaza in infrarosu, pe durata unei
etape de inregistrare, 4 secvente de
achizitie: o inregistrare spectroscopica (in banda 1100-2000 nm) si trei secvente
de achizitii fotometrice in domenile spectrale Y (939-1146 nm), J (1146-1372
nm) si H (1372-2000 nm).
Alegerea algoritmului
In figura
1 este aratat canalul de achizitie al instrumentului VIS. Senzorul acestuia
este echipat cu 36 detectoare CCD,
fiecare detector avand rezolutia impresionanta de 4000 x 4000 pixeli. Blocul de
date brut, necomprimat, este preluat apoi in unitatea CDPU (Control and Data
Processing Unit), care receptioneaza blocul de date primar, il comprima, impacheteaza
datele obtinute in blocuri de date stiintifice (finale) si le transmite mai
departe unitatii S/C-MM (Memoria de masa a navei cosmice). Numarul total de
pixeli a unei secvente inregistrate este de 576 x 106. Avand in
vedere ca electronica de citire a senzorului S converteste semnalul analogic al
fiecarui pixel in semnal digital cu rezolutia de 16 biti, rezulta un bloc de
date cu volumul de 9.216 x 106 biti. Tinand cont de preambulul
fiecarui bloc de date (ce cuprinde numarul secventei, coordonatele directiei de
vizare, timpul, etc), blocul de dat brut, receptionat de CDPU va avea un volum
de 9.664 Mb (sau 1.208 MBy).
Fig. 1. Schema bloc a lantului de achizitie date pentru
instrumental VIS
In figura
2 este reprezentat canalul de achizitie a datelor in infrarosu pentru instrumentul
NISP. Detectorul S al acestuia este echipat cu 16 detectori HgCdTc, fiecare cu
o rezolutie de 2000 x 2000 pixeli. Tinand cont ca rezolutia de conversie
analog-numerica este tot de 16 biti si avand in vedere si preambulul blocului
de date, volumul blocului de date pentru o imagine receptionata la intrare de
unitatea CDPU a instrumentului NISP este de 1.073,76 Mb (sau 134,22 MBy).
Fig. 2. Schema bloc a lantului de
achizitie date pentru instrumental NISP
Datele ce
sunt furnizate de cele doua instrumente Euclid sunt imagini digitalizate
bidimensionale de mare rezolutie. Unitatatatea CDPU a fiecarui instrument va
trebui sa efectueze comprimarea datelor brute cat mai mult posibil si dupa
formarea blocurilor de date stiintifice (finale) sa le transmita mai departe.
Compresia volumului mare de date este imperios necesara, pentru a putea micsora
timpul de transmitere a datelor de telemetrie prin canalele de comunicatie. In
acelasi timp se micsoreaza volumul memoriei necesare imbarcate si volumul
datelor stocate in arhive.
Compresia
datelor se bazeaza pe reducerea datelor redundante (care se repeta) din sirul
de date supuse procesului. O cerinta expresa impusa algoritmului de compresie
folosit in lantul de transmisie a datelor stiintifice este ca, dupa decompresia
datelor sa se obtina blocul de date initial, fara pierdere de informatie. Cu
alte cuvinte, algoritmul de compresie utilizat va trebui sa fie de tipul „fara
pierdere de informatie”. In literatura de specialitate se numeste „lossless
compression”. Cele mai cunoscute tehnici de compresie lossless folosite in
aparatura spatiala sunt: Huffman code, aritmetic coding, Ziv-Lempel coding si
variante ale acestora. Comitetul Consultativ pentru Sistemele de Date Spatiale
(CCSDS – The Consultative Commitiee for Space Data Systems) a selectat pentru
compresia datelor tehnica numita „Rice algorithm”. Tipul acesta de algoritm a
fost utilizat in numeroase misiuni spatiale ale NASA si si-a dovedit eficienta
in timp. El se bazeaza pe impartirea sirului de date de intrare in mai multe sub-blocuri
mici, iar acestor sub-blocuri de date li se aplica diverse coduri de compresie,
adaptate entropiei sub-blocului de date, in vederea cresterii eficientei
compresiei si maririi coeficientului de compresie global (CR – Compression ratio).
In fata fiecarui sub-bloc compresat se va introduce ID-ul tipului de compresie
aplicat sub-blocului, necesar la decompresia datelor, inainte de utilizare.
Schema
bloc a algoritmului ce va fi implementat este data in figura 3. Algoritmul
cuprinde doua blocuri software succesive, distincte. Primul bloc este blocul
pre-procesor, urmata de blocul codor adaptiv de entropie. Sirul de date de la
intrarea codorului de compresie este format din esantioane (16 biti) de date xi.
Acest sir de date este impartit in sub-blocuri a cate J esantioane fiecare.
Deci sub-blocul de date de intrare poate fi notat cu x = x1, x2,
.... xJ. Valoarea numarului J este aleasa 8, 16 sau 32. Uzual a fost
aleasa ca valoare optima valoarea 16. Rolul acestei preprocesari este de a face
o decorelare a semnalelor de intrare in vederea inbunatatirii procesului de
compresie in codorul adaptiv. Un algoritm de decorelare poate fi o scadere a
valorilor succesive (xi – xi-1). Algoritmul de decorelare
aplicat in blocul preprocesor poate fi insa diferit, el depinzand de tipul de
imagine-sursa pentru blocul primar de date. La iesirea pre-procesorului rezulta
sub-blocuri a cate J date: δ = δ1, δ2,
.... δJ. Aceste sub-blocuri de date vor fi aplicate la intrarea
celui de al doilea bloc software numit „codor adaptiv de entropie”.
Fig. 3. Diagrama bloc a codorului de compresie
Functie de continutul sub-blocului de J date de la
intrare, subrutina „Selectare Cod-Optiune” alege una din optiunile pentru
algoritmul de compresie care se incarca in blocul software „Cod Optiune Selectata” si opereaza
asupra sub-blocului de date δ de lungime J, de la intrare, rezultand la iesire o secventa de biti codata, y . Optiunea
se alege astfel, incat gradul de compresie sa fie cat mai ridicat. In fata
fiecarei secvente rezultate din sub-blocul de J esantioane se introduce ID-ul
optiunii de compresie selectata de subrutina „Selectare Cod-Optiune”.
Optiunea de baza este FS (Fundamental Sequence code).
Algoritmul de codare FS presupune asocierea unui simbol de lungime minima
secventei de biti cu probabilitatea maxima de aparitie in cadrul sub-blocului
de date J. Cu cat probabilitatea de aparitie a unei secvente este mai mica, cu
atat simbolul asociat acesteia are o
lungime mai mare. De aici si posibilitatea de compresie a sirului de biti de la
intrare.
In optiunile k = ... , sunt luate cele J esantioane de la
intrare, se indeparteaza din fiecare esantion ultimii k biti cei mai putini
semnificativi, iar sirului astfel rezultat din cei mai semnificativi biti i se
aplica algoritmul de compresie FS. La sfarsit se adauga cei k biti indepartati
de la fiecare din cele J esantioane de date.
Optiunea „Bloc-zero” se aplica atunci cand unul sau mai
multe sub-blocuri consecutive de J esantioane au valoarea zero. Numarului de sub-blocuri
adiacente zero i se aplica algoritmul FS la nivel de sub-bloc.
Optiunea „Extindere de ordinul 2” se aplica atunci cand
valorile esantioanelor sunt mici. Algoritmul consista in preprocesarea
esantioanelor din sub-blocul de J esantioane, in perechi, dupa o anumita
formula, dupa care se aplica algoritmul FS sirului de date rezultat.
Optiunea „fara compresie” presupune pastrarea sub-blocului
de date de la intrare nemodificat si introducerea ID-ului corespunzator in
fata, pentru ca acesta este necesar in procesul de decodare.
La sfarsitul procesului de compresie se obtine un pachet „y”
de biti, cu lungimea mai mica decat sirul initial de la intrare. Lungimea
pachetului de biti rezultat este insa variabila, ca de altfel si in cazul altor
metode de compresie, cum ar fi metoda Huffman. Lungimea pachetului rezultat dupa compresie depinde de continutul
imaginii sursa pentru blocul de date brut, de la intrare.
Definirea cerintelor si strategiei pentru algoritmul de
comprimare
Se poate
observa ca intr-o secventa de 803 sec. pentru achizitia datelor, instrumentul
VIS va trebui sa proceseze un bloc de date de 9.664 Mb. In acelasi timp
instrumentul NISP proceseaza 4 blocuri de date a cate 1.073,76 Mb (in total 4.295,04
Mb).
Tinand
cont de cele expuse pana acum, putem sa conturam cerintele impuse viitorului
algoritm de compresie a datelor:
1.
Volumul blocului de date
initial: max. 9.664 Mb;
2.
Tipul surselor de date: bidimensional;
3.
Durata compresiei pentru
un bloc: < 800 sec;
4.
Gradul de compresie: >= 2, pentru
imaginile fotometrice;
5.
Procesor utilizat: mare putere de calcul, cu
varianta calificata pentru misiuni spatiale;
6.
Tip algoritm de
compresie: algoritmul
Rice;
7.
Rezolutia de digitizare a
esantioanelor: 16 biti;
8.
Dimensiunea sub-blocurilor
de lucru: J=16 esantioane;
9.
Autotest: posibilitate
de autotestare;
10. Verificare: algoritm
de decompresie.
In etapele de lucru viitoare se va trece la elaborarea succesiva a
subrutinelor pentru algoritmul de compresie. Apoi se va elabora algoritmul de
decompresie. Cu ajutorul blocurilor de date simulate pentru experimentul Euclid
se va testa algoritmul de compresie elaborat si se va masura durata de
procesare a blocurilor maxime de date pentru instrumentele Euclid.
Resursele pentru realizarea algoritmului de compresie
In vederea realizarii procesului de comprimare a datelor in intervalul de timp impus de catre modul de operare al experimentului EUCLID este necesar sa se utilizeze un procesor cu mare putere de calcul si cu viteza de lucru deosebita. Avand in vedere ca programul software de
compresie va fi utilizat pe un satelit artificial, a fost ales unul dintre cele mai bune componente realizate astazi la nivel ESA pentru experimente imbarcate, procesorul LEON3. Pe langa puterea de calcul si viteza de procesare deosebite, procesorul va fi calificat pentru lucrul in mediu de radiatii cosmice intense si va avea facilitati de protectie la fenomenele Single Event Upset sau Single Event Latchup.
Acest procesor este fabricat de Tower Semiconductors Ltd., pe baza tehnologiei CMOS de 180nm si se preteaza in mod deosebit aplicatiilor spatiale datorita protocoalelor de interfata avansate, rezistentei superioare la incidenta radiatiei cosmice si consumului redus de putere. Pentru implementarea
algoritmului de compresie a fost achizitionata o placa de dezvoltare GR712RC
pentru procesorul Leon 3, realizata de firma Aeroflex. Placa are incorporata o matrice de interconectare programabila, cu ajutorul careia aceiasi pini de intrare/iesire pot fi folositi pentru diverse operatii, putandu-se astfel realiza configurari multiple ale aceleiasi placi (figura
4).
Fig. 4. Placa de
dezvoltare GR712RC
In continuare, prezentam cateva caracteristici ale placii de dezvoltare GR712RC:
-
Procesor LEON3-FT SPARC V8, dual-core pe 32 de biti.
-
Memorie: modul SDRAM SODIMM; SRAM, NOR FLASH PROM
-
Circuite de power, reset, clock si auxiliare.
-
Interfete:
-
o interfata folosita pentru debug de tip JTAG
-
sase interfete de tip SpaceWire
-
doua interfete de tip CAN (controller area network)
-
o interfata de tip Ethernet 10/100 Mbps RMII
-
doua interfete seriale de tip UART
-
doua interfete de comunicare MIL-STD-1553
-
doua interfete de tip master SPI si I2C
In figura 5 prezentam o schema bloc a placii GR712RC
Fig. 5. Schema
bloc a placii GR712RC
Aeroflex Gaisler ofera un pachet de drivere/utilitare suport pentru placa de dezvoltare GR712RC si pentru procesorul Leon 3. Pachetul VXWORKS-6.7-LEON BSP (board support package) contine driverele sistemului de operare VxWorks de la WindRiver, pentru toate cipurile de pe placa de dezvoltare GR712RC. Acest pachet ofera:
-
suport MMU(Memory Management Unit),
-
drivere pentru perifericele UART, Timer, IrqCtrl,
-
suport pentru interfata SpaceWire GRSPW, USB1.2/2.0,
-
suport pentru Workbench 3.x si pentru VXTEST2.
Fig. 6. Interfata
grafica Wind River - Workbench
Pentru a dezvolta algoritmul de compresie cu ajutorul procesorului Leon3, se foloseste Workbench-ul de la firma Wind River (figura 6). Acest pachet contine:
-
Mediul de programare Eclipse 3.5
-
Compilator C++ pentru VxWorks, versiunea 7.0
-
Performance Profiler
-
Data Monitor
-
alte componente software necesare dezvoltarii de aplicatii profesionale pentru sistemul Leon 3.
Tot de la firma Wind River, s-a achizitionat si sistemul de operare de tip RT(real time), VxWorks 6.7, care va rula pe placa de dezvoltare GR712RC. Acest sistem de operare este cel mai folosit sistem de operare de tip RT din
industrie, datorita calitatiilor sale in ce priveste fiabilitatea precum si
posibilitatea de a rula intr-un mediu “run-time” deterministic. Platforma
VxWorks suporta procesarea pe 64 de biti, oferind suport pentru sistemele
'multi-core' atat pentru AMP(Asymmetric
Multiprocessing) cat si pentru SMP(Symmetric Multiprocessing).
Printre alte caracteristici ale
sistemului de operareVxWorks enumeram:
-
protectia superioara a memoriei
-
tehnologia avansata de retelistica (Wind River
Advanced Networking Technologies)
-
managementul erorilor.
Un sistem de operare de tip RTOS (real-time operating system) este
proiectat astfel incat sa raspunda cerintelor aplicatiilor intr-un timp foarte
scurt. Trebuie sa fie capabil sa proceseze datele, de indata ce acestea sunt
disponibile si sa nu apara intarzieri datorate stocari in buffer. Timpul de
procesare in care este inclus si intarzierile datorate sistemului de operare,
nu trebuie sa depaseasca zecimi de secunda. O caracteristica importanta a
sistemului de tip RTOS, o reprezinta nivelul de consistenta al timpului necesar
acceptarii si executarii unui task al aplicatiei. Acest sistem de operare are
un algoritm avansat pentru programarea task-urilor, permitand o buna organizare
a prioritatiilor proceselor.
Imaginea finala a proiectului poate fi descarcata pe sistemul Leon3 folosind programul Grmon, dezvoltat de Aeroflex Gaisler. Acest program, instalat pe un PC obisnuit, comunica cu placa de dezvoltare GR712RC, prin intermediul interfetei JTAG, accesand unitatea DSU (debug support unit) a procesorului Leon3. Conexiunea dintre calculator si placa de dezvoltare se realizeaza prin intermediul portului mini-USB, iar conversia semnalului USB in semnal de tip JTAG este efectuata de circuitul integrat de conversie FT2232H (figura 7).
Fig. 7. Conexiunea intre
calculator si DSU
Astfel, folosindu-se programul Grmon, se pot executa aplicatii pentru procesor si investiga eventualele erori de programare pentru intregul sistem hardware. Printre caracteristicile programului se numara:
-
accesul la scrierea si citirea registrilor si memoriei procesorului
-
descarcarea si executia aplicatiilor, suport pentru comunicarea cu Eclipse IDE
-
interfete de tip 'debug' pentru porturile USB, JTAG, Ethernet, Serial si PCI.
In figura 8 se observa interfata grafica principala a programului, GrmonRCP, care se bazeaza pe o platforma Eclipse Rich Client (RCP). Este o interfata care se preteaza necesitatilor utilizatorului, oferind
un suport complet pentru toate functiile Grmon.
Fig. 8. Interfata grafica GrmonRCP
Programul Grmon poate
opera in modul 'standalone' sau in modul GDB (GNU Debugger). In primul mod de
operare, aplicatiile Leon sunt incarcate si diagnosticate (debugged) folosind
fie o interfata de tip 'command line', fie o interfata grafica GUI (Graphical
User Interface). O multitudine de comenzi sunt disponibile pentru examinarea
datelor, pentru oprirea controlata a executie aplicatiei (breakpoints), cat si pentru rularea aplicatiilor folosind
optiuni suplimentare.
In
modul GDB (GNU Debugger), programul Grmon se
comporta ca un port (gateway) convertind
comenziile GDB in comenzi de tip 'debug' specifice sistemului Leon 3.
GDB (GNU Project debugger) este un
program de tip 'debugger', cu ajutorul caruia se poate 'vedea' ce este in
interiorul altui program cand acesta ruleaza. Se poate afla astfel, ce facea
programul chiar inainte de aparitia unei eventuale erori. Aplicatiile Leon sunt
incarcate si investigate folosind GDB-ul; orice utilitar care suporta
protocolul GDB poate fi folosit ca interfata pentru GRMON.
Concluzii
.....................................................................................................
Prezentul contract se refera la contributia Institutului
de Stiinte Spatiale la realizarea misiunii spatiale Euclid. Contributia consta
in implementarea unui algoritm de compresie a datelor stiintifice obtinute de
la cele doua instrumente ale experimentului Euclid.
In
prezenta etapa a fost analizata documentatia instrumentelor de achizitie a
datelor stiintifice si au fost determinate dimensiunile blocurilor de date
primare furnizate de instrumente. Dupa o
analiza a metodelor de comprimare de tip „lossless compression” si tinand cont
de recomandarile Comitetul Consultativ pentru Sistemele de Date Spatiale –
CCSDS, a fost aleasa metoda de compresie Rice. Dupa analiza metodei, tinand
cont de caracteristicile blocurilor de date initiale si de modul de operare al
experimentului Euclid, au fost definite cerintele impuse algoritmului de
compresie si strategia de urmat pentru realizarea acestuia. Au fost
identificate apoi resursele hardware si software necesare pentru proiectarea
algoritmului de compresie si s-a facut o scurta descriere a caracteristicilor
lor principale, precum si a interfetelor programelor care urmeaza a fi folosite
in procesul de implementare a programului de compresie.
................................................................. ....................................
Tinand cont de toate cele
mentionate pana acum, putem trage concluzia ca obiectivele prezentei etape a
proiectului au fost realizate in totalitate si la termen.
Bibliografie:
- Euclid Definition Study Report,
ESA/SRE(2011)12
- NISP Instrument Operation Concept Document,
EUCLID-IIO-NPS-PL-077 (internal)
- VIS Instrument Operation
Concept Document, EUCL-MSS-VIS-PL-00020 (internal)
- Lossless data
compression, Informational report, CCSDS 120.0-G-2, 2006
- A Rice-Based Lossless
data Compression System for Space Applications, Salvatore Coco, Valentino
D’Arrigo, Domenico Giunta
- GR712RC
development board product sheet
- GR712RC
development board User Manual
- Aeroflex Gaisler
- GRMON User’s Manual - http://www.gaisler.com/doc/grmon.pdf
- http://www.gaisler.com/index.php/products/operating-systems/vxworks?task=view&id=241
- http://www.gaisler.com/index.php/products?option=com_content&task=view&id=39