Realizacja Komputera Pokładowego OBDH Satelity SSETI ESEO

REALIZACJA KOMPUTERA POKŁADOWEGO OBDH SATELITY SSETI ESEO
Kacper Bąk, Andrzej Cichocki
Studenckie Koło Inżynierii Kosmicznej, Politechnika Warszawska
[email protected]
[email protected]
Streszczenie: Artykuł przedstawia krótką charakterystykę modułu przetwarzania i zarządzania
danymi (komputera pokładowego) studenckiego satelity ESEO, w budowie którego Studenckie
Koło Inżynierii Kosmicznej Politechniki Warszawskiej uczestniczy w ramach organizacji SSETI.
Opisane zostały tu dwa podstawowe aspekty modułu: część sprzętową i oprogramowanie, pod
kątem zastosowania w aplikacji kosmicznej.
1.
WSTĘP
Studenckie Koło Inżynierii Kosmicznej działa przy Instytucie Radioelektroniki
Politechniki Warszawskiej od 2004 roku. Niedługo po rozpoczęciu działalności stało się ono
częścią stowarzyszenia SSETI (Student Space Exploration and Technology Iniative),
wspieranego przez Departament Edukacyjny Europejskiej Agencji Kosmicznej. Jednym
z przedsięwzięć SSETI jest projekt, budowa i wystrzelenie minisatelity ESEO (European
Student Earth Orbiter) [1].
2.
SATELITA SSETI ESEO
2.1. Przeznaczenie i zadania satelity
ESEO to nazwa sztucznego satelity ziemskiego budowanego przez studentów
z uniwersytetów europejskich. Zgodnie z nomenklaturą standardów kosmicznych jest on
minisatelitą, ponieważ jego masa nie przekracza 120kg (wymiary 60x60x70 cm). Docelowo
ma znaleźć się na orbicie geotransferowej (eliptycznej o wysokości perygeum 163km oraz
apogeum – 35843km). Ponieważ będzie wystrzelony jako tzw. ładunek pomocniczy rakiety
wynoszącej (Ariane 5), musi spełniać wymogi interfejsu ASAP 5 [2]. Zadania jakie stoją
przed ESEO to między innymi:
-
robienie zdjęć różnych obszarów Europy,
fotografowanie Księżyca i innych ciał niebieskich,
pomiary promieniowania kosmicznego,
pomiary natężenia pola magnetycznego Ziemi.
2.2. Ogólna struktura
Schemat blokowy satelity ESEO jest przedstawiony na Rysunku 1.
Rys. 1. Schemat blokowy satelity ESEO
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
1
W uproszczeniu, satelita składa się z dwóch zasadniczych części: platformy i ładunku
użytecznego (payload) [3]. W skład pierwszej z nich wchodzi między innymi system kontroli
położenia i orientacji (AOCS - Attitude and Orbit Control System), system sterujący (OBDH On-board Data Handling), system komunikacyjny (COMM - Communications) [3]. Moduły
te są potrzebne to prawidłowego funkcjonowania większości satelitów (utrzymanie
komunikacji z Ziemią, dostarczenie zasilania, korekcja orbity, itd.). W skład ładunku
użytecznego wchodzą m.in: miniaturowy aparat fotograficzny (uCAM - Micro Camera),
aparat fotograficzny o wąskim polu widzenia (NAC - Narrow Angle Camera), sonda
Langmuira do pomiarów plazmy (LMP - Langmuir Probe), dzięki którym będzie możliwa
realizacja eksperymentów przewidzianych dla ESEO [4]. Podzespoły komunikują się ze sobą
za pośrednictwem magistrali CAN (Controller Area Network). Zastosowana została podwójna
redundancja magistrali.
2.3. Komputer pokładowy OBDH
Komputer pokładowy (OBDH) jest jednym z kluczowych modułów satelity ESEO.
Przewidziane zostały dla niego poniższe zadania:
- zapewnienie stacji naziemnej (ang. ground station) możliwości kontrolowania
satelity, poprzez wykonywanie rozkazów zwanych telekomendami;
- umożliwienie stacji naziemnej monitorowania stanu satelity za pomocą telemetrii
oraz odbieranie danych pochodzących z przeprowadzanych eksperymentów;
- zbieranie danych z innych podzespołów na poziomie sprzętowym, przy użyciu
magistrali CAN (przykładowe dane: obraz z aparatu fotograficznego, temperatura,
napięcia, natężenia prądów, aktualna pozycja);
- kontrola przepływu danych – komputer jest jednostką nadrzędną, która zleca
podsystemom realizację komend, raportowanie aktualnych parametrów itp.
Podsystem, ze względu na swoją specyfikę, posiada dosyć złożone oprogramowanie
wymagające starannego zaplanowania i implementacji. Aby oprogramowanie to mogło
funkcjonować właściwie, konieczne jest zapewnienie odpowiedniej platformy sprzętowej –
systemu komputerowego.
3.
OPROGRAMOWANIE
3.1. Wymagania
W pierwszej kolejności zostaną opisane wymagania systemowe, które są specyficzne dla
danej misji, a następnie wymagania ogólne charakteryzujące oprogramowanie krytyczne
(ang. mission-critical software) [5].
Systemowe
Do wymagań systemowych zaliczamy takie, które są ściśle związane z przeprowadzaną
misją i mogą się znacznie różnić między satelitami. Dla SSETI ESEO są one następujące:
-
odbiór telekomend, możliwość programowania misji (planista telekomend),
raportowanie telemetrii tylko na żądanie stacji naziemnej,
zbieranie i gromadzenie danych z podsystemów oraz sterowanie nimi,
robienie oraz składowanie zdjęć,
możliwość trwałego zapisywania telemetrii,
używanie magistrali CAN do komunikacji z innymi podzespołami,
automatyczne wykrywanie awarii szyny CAN oraz przełączanie magistrali,
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
2
- dwie wersje działające na komputerze głównym OBDH – moduł nominalny,
- działający na komputerze AOCS (ang. Attitude and Orbit Control System) moduł
zapasowy (krytyczny),
- automatyczne uruchamianie modułu zapasowego oprogramowania,
- możliwość uaktualniania oprogramowania w trakcie trwania misji,
- odporność na pojedyncze błędy (ang. single point failure),
- powiadamianie stacji naziemnej o czynnościach wykonywanych autonomicznie.
Ogólne
Ten typ wymagań skupia się na samym oprogramowaniu, a nie jego funkcjonalności. Jest
to pewien zbiór przymiotów mówiący o tym, w którym kierunku należy podążać, aby
otrzymać produkt wysokiej jakości.
- poprawność (ang. correctness) –związana z właściwym wykonywaniem zadań.
- odporność (ang. robustness) – odporność na błędy oraz ich tolerowanie jest jedną
z cech oprogramowania krytycznego.
- pełna funkcjonalność (ang. full functionality) – polega na spełnieniu wszystkich
wymagań na poziomie systemowym oraz podsystemowym.
- „czysta” implementacja (ang. clean implementation) – koncentruje się na prostocie
i odpowiedniej strukturze kodu.
- czytelność (ang. readability) – jest związana z odpowiednim (jednolitym) stylem
kodowania oraz tworzeniem bogatej dokumentacji.
3.2. Architektura
Architektura oprogramowania jest w dużej mierze wymuszona poprzez wyspecyfikowane
wymagania, a zatem jest ściśle związana z rozpatrywanym problemem. Oprogramowanie
komputera pokładowego będzie składało się z 11 modułów programowych stanowiących
jednostki autonomiczne.
Model logiczny
AOCS safe
CAN Packet
12.
AOCS safe*
10.
TM Reporter**
Outgoing
CAN Packet
1.
CAN Driver
CAN Packet
2.
CAN Router
Routed
CAN Packet
Outgoing
TM
3.
Large Data
Unit Transport
Receives
data from
all modules**
TC
Scheduled TC
4.
TC AcceptanceRouted TC
5.
&
TC Scheduler
Release
Routed TC
Legend
Foreign module*
Incoming IMG
8.
Acquisition of
Parameters
6.
Functions
Management
11.
Watchdog**
7.
Status
9.
Image
Acquisition
Outgoing
CAN Packet
Rys. 2. Model logiczny oprogramowania komputera OBDH Core
Rysunek 2 przedstawia model logiczny obrazujący strukturę oprogramowania komputera
pokładowego wraz z połączeniami umożliwiającymi interakcję między modułami.
Ze względu na czytelność, na powyższej ilustracji nie zostały zaznaczone połączenia między
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
3
TM (telemetry) Reporter i Watchdog, a innymi modułami, ponieważ te dwie jednostki mogą
otrzymywać dane od wszystkich pozostałych części oprogramowania.
- Sterownik CAN (CAN Driver)
Ten niskopoziomowy moduł jako jedyny ma bezpośredni dostęp do magistrali CAN,
zatem otrzymuje i wysyła wszystkie pakiety CAN wędrujące między komputerem OBDH
Core, a innymi podsystemami. Komunikacja z komputerem pokładowym odbywa się
za pomocą pliku urządzenia /dev/isacan przy dodatkowym użyciu protokołu SLIP [6].
- Router pakietów CAN (CAN Router)
Router pakietów CAN kieruje pakiety nadchodzące ze sterownika (CAN Driver)
do docelowych modułów programowych. Potrafi działać również w drugą stronę, to znaczy
odbiera dane wysyłane z modułów OBDH Core przeznaczone dla innych podsystemów
satelity. Celem eliminacji błędów na jak najwcześniejszym etapie, CAN Router sprawdza
poprawność wszystkich obsługiwanych pakietów – w razie błędu powiadamia TM Reporter.
- Transfer dużych danych (Large Data Unit Transfer)
Przeznaczeniem LDUT jest budowanie dużych zbiorów danych na podstawie wielu
pakietów CAN. Główne wykorzystanie wiąże się danymi telemetrycznymi (TM Reporter),
telekomendami (TCAR) oraz zdjęciami (Image Acquisition), które mogą mieć długość rzędu
kilkudziesięciu kilobajtów. Jako, że poprawność danych jest kwestią kluczową LDUT
zapewnia mechanizmy liczenia sum kontrolnych oraz potrafi pracować równolegle z wieloma
sesjami.
- Akceptacja i wykonywanie telekomend (TC Acceptance and Release)
Każda telekomenda, zanim zostanie wykonana jest sprawdzana pod względem
poprawności, a następnie dostarczana do odpowiedniego modułu wykonawczego – za to
odpowiedzialny jest TCAR. Ponadto pośredniczy w generowaniu danych telemetrycznych
zawierających rezultat wykonania określonej funkcji.
- Planista telekomend (TC Scheduler)
Jedno z wymagań systemowych dotyczy możliwości programowania misji kosmicznej
przy pomocy telekomend. Planista telekomend oferuje dwie metody pozwalające na
nieliniowe działanie:
- ustalanie czasu wykonania – pozwala zaplanować datę uruchomienia wskazanej
funkcji,
- wykonanie warunkowe – zezwala na niesekwencyjne realizowanie zadań.
- moduł planisty nie wywołuje zadanych procedur sam z siebie, ale zleca ich
wykonanie modułowi TCAR po zajściu określonego zdarzenia.
- Zarządzanie funkcjami (Functions Management - FM)
Każdy z podsystemów satelity SSETI ESEO potrafi wykonywać określone zadania
na polecenie komputera OBDH (lub stacji naziemnej wysyłającej telekomendy). Moduł FM
pośredniczy w wywoływaniu tych funkcji (wysyłając pakiety CAN z komendą), a także
zwraca rezultaty ich wykonania (na podstawie dostarczonych pakietów PDO).
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
4
- Status (Status)
Rolą Statusu jest gromadzenie oraz udostępnianie aktualnych danych zbieranych
z podsystemów satelity. W skład danych wchodzą: wartości podawane z czujników, tryb
pracy podzespołu, informacje o anomaliach i błędach. Wysyłając pakiet CAN z komendą,
Status otrzymuje w zamian pakiet PDO przechowujący najświeższe dane na temat danego
komponentu.
- Konfiguracja telemetrii (Acquisition of Parameters)
Stacja naziemna jest w stanie określić jakie dane chce otrzymywać z satelity.
Konfiguracją odpowiednich filtrów zajmuje się moduł Konfiguracji telemetrii, który jest
sterowany telekomendami dostarczanymi z modułu TCAR. Raz zdefiniowany raport jest
generowany podczas każdego przesłania telemetrii.
- Przechowywanie zdjęć (Image Acquisition)
Na pokładzie SSETI ESEO znajdzie się aparat, którego zadaniem będzie robienie zdjęć
Ziemi oraz Księżyca. Moduł IMA będzie zlecał wykonanie zdjęcia, a także zajmie się jego
przechowaniem. Na żądanie GS fotografie zostaną udostępnione i wysłane razem z telemetrią.
- Moduł raportowania telemetrii (TM Reporter)
Raportowaniem i gromadzeniem telemetrii zajmuje się osobny moduł, który udostępnia
te dane na żądania płynące ze stacji naziemnej. Wszelkie dane są zapisywane do pamięci
trwałej. Do danych telemetrycznych zaliczamy raportowane błędy, anomalie, wydarzenia,
autonomiczne operacje, wartości dostarczane przez sensory oraz obrazy.
- Watchdog (Watchdog – WD )
Watchdog monitoruje wszystkie procesy uruchamiane w ramach komputera OBDH Core.
Każdy moduł programowy powinien wysyłać sygnał informujący o prawidłowej pracy
(heartbeat - HB) co 5 sekund. Gdy minie ten czas, a sygnał nie zostanie dostarczony, WD
czeka kolejnych 5 sekund. Jeżeli nadal nie otrzymuje pakietu, wysyła sygnał systemowy
polecający zrestartowanie modułu (sygnał powinien być obsługiwany przez ten moduł).
W razie braku sygnału po następnych 5 sekundach, moduł jest restartowany przez system
operacyjny.
Tab. 1. Algorytm działania modułu Watchdog
Całkowity czas
5s
10 s
15 s
20 s
Czas operacji
5s
5s
5s
5s
Akcja
Brak
HB
pakietu Oczekiwanie
na Miękki
restart Twardy
restart
drugi komunikat HB (wykonuje moduł) (wykonuje WD)
- Moduł krytyczny AOCS (AOCS safe)
Jest to jedyna część oprogramowania stworzona przez zespół inny niż OBDH Core.
AOCS safe pełni rolę modułu zapasowego zespołu stabilizacji i jest aktywowany tylko
na wypadek awarii komputera głównego AOCS. Aktywacja modułu krytycznego następuje
automatycznie na podstawie braku pakietów typu HB.
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
5
3.3. Oprogramowanie krytyczne
Moduł zapasowy (zwany również krytycznym) jest tą częścią oprogramowania, która
działa na fizycznie innym komputerze i uaktywnia się automatycznie w razie awarii
komputera głównego. Funkcjonalność tego modułu będzie zbliżona do funkcjonalności
nominalnej, jednakże sposób komunikacji ze światem zewnętrznym będzie nieco inny –
z powodu braku bezpośredniego dostępu do sterownika CAN. Wszelkie pakiety CAN będą
kierowane przez oprogramowanie zewnętrzne (czyli podsystem stabilizacji – AOCS)
za pomocą kolejek systemowych.
Tworzeniem oprogramowania krytycznego zajmuje się osobny zespół programistów,
który nie powinien mieć styczności z oprogramowaniem komputera głównego OBDH.
3.4. Implementacja
Omówione poniżej cechy oprogramowania są dosyć specyficzne dla systemów
krytycznych i mają istotny wpływ na działanie i bezpieczeństwo całego systemu.
Projektowane oprogramowanie będzie zgodne z POSIX.
Procesy
Każdy z uprzednio opisanych modułów programowych będzie osobnym procesem
w systemie operacyjnym. Ponadto, każdy proces będzie złożony z co najmniej kilku wątków
obsługujących wymianę komunikatów, wykonujących określone zadania, a także
monitorujących pracę modułu. Ze względów bezpieczeństwa moduły będą odpowiednio
odseparowane od siebie, tak aby nieprawidłowa praca jednego z nich nie miała
bezpośredniego wpływu na pozostałe. Wiąże się to z właściwą ochroną dostępnych zasobów.
Alokacja pamięci
Ważną cechą oprogramowania stosowanego w systemach krytycznych jest jego
deterministyczne działanie. Z tego względu dostępne są tylko dwie metody alokacji pamięci:
statyczna oraz automatyczna. W oprogramowaniu OBDH Core nie stosujemy dynamicznej
alokacji pamięci, ponieważ to prowadzi do fragmentacji samej pamięci oraz rosnącej
złożoności obsługi błędów.
Kolejki komunikatów
Systemowe kolejki komunikatów służą do wymiany danych między procesami –
obrazują to połączenia zawarte w modelu logicznym. Każda wysyłana wiadomość jest
opakowywana protokołem SLIP [6], dzięki czemu przesyłanie informacji jest bezpieczniejsze.
Ochrona danych
W wielu miejscach mamy informację o dokładnym rozmiarze przetwarzanego obiektu,
jednak istnieje możliwość pojawienia się pewnych danych o innej (niepoprawnej) długości.
Taki pakiet mógłby popsuć cały strumień danych i aby temu zaradzić stosujemy protokół
SLIP wyznaczający początek i koniec każdego pakietu. Ten sposób ochrony obiektów ma
zastosowanie w kolejkach systemowych, a także na styku Sterownik CAN <-> Router
pakietów CAN.
Składowanie telemetrii
Dane telemetryczne będą przechowywane w plikach. Ten sposób składowania informacji
charakteryzuje się prostotą działania, pewnością, łatwością testowania oraz elastycznością.
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
6
3.5. Narzędzia
Narzędzia stosowane do tworzenia oprogramowania są z reguły szeroko dostępne
i dobrze przetestowane.
System operacyjny
Zarówno komputer OBDH jak i AOCS będą działały pod kontrolą systemu Linux 2.6.9
wraz z RTAI (RealTime Application Interface), które tworzą system operacyjny czasu
rzeczywistego.
Język programowania
Do napisania oprogramowania komputera głównego zostanie użyty język Embedded C++
(EC++) [7], który jest „bezpiecznym” podzbiorem języka C++. Paradygmat obiektowy
bardzo dobrze modeluje nasze zadanie, a poza tym pozwoli na stworzenie kodu
bezpieczniejszego i ukrywającego detale.
Zespół tworzący moduł zapasowy zdecydował się na język C, który jest językiem
klasycznym w systemach wbudowanych.
Kompilator
Język EC++ jest obsługiwany przez kompilator firmy Green Hills. Niestety produkt nie
jest darmowy i obecnie prowadzimy rozmowy na temat sponsorowania go przez firmę. Kod
pisany w C będzie kompilowany przez darmowy kompilator GCC. Warto podkreślić,
iż podczas kompilacji biblioteki są łączone statyczne, dzięki temu procesy są mniej narażone
na nieprawidłowe działanie.
Statyczne sprawdzanie kodu
W przypadku języka C można poprawić bezpieczeństwo kodu poprzez jego statyczną
analizę. Ta kwestia jest obsługiwana przez narzędzie splint.
Dokumentacja
Dokumentacja programisty jest tworzona w Doxygen i generuje się automatycznie
na podstawie kodu.
4.
PLATFORMA SPRZĘTOWA
Implementacja stosownego oprogramowania wymaga właściwej platformy sprzętowej.
Dla zachowania zgodności z modułem AOCS (realizowanym przez zespół z Portugalii) użyto
do jej realizacji standardu PC/104. Odgórnym założeniem projektu było wykorzystanie
jedynie elementów komercyjnych, ze względu na dostępność i cenę. Sprzęt OBDH stanowią
cztery płytki drukowane ułożone w stos, połączone elektrycznie (standard ISA)
i mechanicznie (tulejki dystansowe) [4] (Rysunek 3):
-
Płyta Zasilająca (Power Supply Board),
Płyta Procesora (CPU Board),
Płyta Kontrolera CAN (CAN Board),
Płyta Pomocnicza (Auxiliary Board).
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
7
Rys. 3. Połączenie płyt drukowanych OBDH w stos PC/104
Płyta Zasilająca (Power Supply Board)
Zawiera przetwornicę impulsową rodziny SMHF w standardzie wojskowym, zdolną
zamienić w sposób efektywny (do 82% skuteczności) napięcie z niestabilizowanej szyny
głównej zasilania satelity (20V-40V) do stabilizowanego 5V (konieczne dla standardu
PC/104). Na płycie tej znajduje się również filtr EMI rodziny SMFC, co zapewnia ochronę
systemu przed zakłóceniami, redukując interferencje elektromagnetyczne. Pozostałe płyty są
zasilane z magistrali ISA (linia VCC), na którą dostarczana jest moc z Płyty Zasilającej. Płyta
zdolna jest dostarczyć OBDH co najmniej 12W. Zawiera wbudowany ogranicznik prądowy
(>2.4A) oraz zabezpieczenie przed zbyt niskim lub zbyt wysokim napięciem na wyjściu
i skutkami wystąpienia w którymkolwiek z zasilanych układów efektu tyrystorowego.
Ponadto użyte elementy posiadają cechy odpowiednie dla aplikacji kosmicznej – ekranowanie
klasy K (standard MIL-PRF-38534), odporność na promieniowanie klasy R oraz zakres
temperatury pracy od -55° do +125°C.
Płyta Procesora (CPU Board)
To główny komputer, przemysłowa wersja (szerszy zakres temperatury) MIP405 –
zintegrowanego komputera z procesorem PowerPC i urządzeniami peryferyjnymi (RAM,
RS232, 16-bitowy interfejs ISA itd.). Użyta architektura Power PC (PPC405GPr) pozwala na
uruchomienie systemu Linux z rozszerzeniem czasu rzeczywistego (608 Dhrystone MIPS
przy 400Mhz) oraz charakteryzuje się niskim poborem mocy (<3W przy 400Mhz) i małą
masą (110g) [8]. Użyta wersja MIP405 ma rozszerzony zakres temperatury, w której może
pracować, tj. -40 do 85 st. C. Ponadto wykorzystana platforma została przetestowana przez
NASA na odporność na warunki środowiskowe (w tym te wiążące się z promieniowaniem
kosmicznym). Procesor PPC405GPr został wykonany w technologii SOI (Silicon on
Insulator) co zapewnia odporność na zjawisko tzw. efektu tyrystorowego wyzwalanego przy
pochłonięciu odpowiedniej energii dostarczonej przez wysokoenergetyczną cząstkę - SEL
(ang. Single Event Latchup).
Rys. 4. Inżynieryjny model Płyty Procesora
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
8
Wyniki testów pozwoliły dopuścić platformę do użytku na niskiej orbicie okołoziemskiej
dla krótkich czasów trwania misji. Zdjęcie modelu inżynieryjnego płyty widoczne jest
na Rysunku 4.
Płyta Kontrolera CAN (CPU Board)
Stanowi interfejs CAN/ISA który pozwala na komunikacje komputera z wszystkimi
modułami satelity za pośrednictwem magistrali CAN. Moduł ten jest 8-bitowym urządzeniem
wejścia/wyjścia magistrali ISA. Używa dwóch (dla zapewnienia redundancji) scalonych
kontrolerów AN82527 firmy Intel do porozumiewania się z urządzeniami CAN. Posiada on
także wbudowane proste zabezpieczenie przed SEL za pomocą układu monitorującego
natężenie prądu zasilania. Kiedy przekroczy ono ustaloną wartość, układ jest odłączany
od zasilania na określony i konfigurowalny okres czasu. Diagram blokowy widoczny jest
na Rysunku 5.
Rys. 5. Diagram blokowy Płyty kontrolera CAN
Płyta pomocnicza (Auxiliary Board)
Płyta ta stanowi rozszerzenie zasobów pamięci nieulotnej komputera oraz interfejs
do pomiaru temperatury w różnych miejscach na płytkach drukowanych w stosie PC/104.
używa ona 16-bitowego interfejsu ISA oraz szeregowego RS232 (przy zastosowaniu
poziomów napięć TTL), aby mogła być możliwa wymiana danych z Płytą Procesora. Ponadto
płyta jest wyposażona w układ zapobiegania konsekwencjom efektu tyrystorowego
(identycznie jak Płycie Kontrolera CAN). Płyta pomocnicza działa na zasadzie pamięci
masowej na ciele stałym, zapewniając 32MB przestrzeni adresowej zorganizowanej
w 16 megasłów, za pośrednictwem magistrali ISA.
Rys. 5. –Diagram blokowy Płyty Pomocniczej
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
9
Dodatkową funkcjonalnością płyty jest gromadzenie i przetwarzanie danych z pomiarów
temperatury w stosie PC/104 i ilości zjawisk SEL, które udało się odnotować oraz
raportowanie ich do Płyty Procesora. Płyta jest wyposażona w kontroler zrealizowany
z zastosowaniem układu programowalnego FPGA firmy Actel (A3P250), który
charakteryzuje się wysoką odpornością na całkowitą dawkę jonizującą [50krad(Si)],
w którym zaimplementowany został rdzeń własności intelektualnej, wykorzystujący
kodowanie korekcyjne (korygowanie przekłamań bitowych związanych z Single Event
Upsets) oraz redundancję z zastosowaniem układów głosujących [4]. Do pomiaru temperatury
użyto czujników inteligentnych DS18S20 firmy Dallas Semi., które również cechują się
wysoką odpornością ma zjawiska związane z dużą pochłoniętą, skumulowaną energią
promieniowania jonizacyjnego. Diagram blokowy płyty widoczny jest na Rysunku 5.
5.
PODSUMOWANIE
Wykonane symulacje i testy [4][8] pozwalają stwierdzić, że możliwe jest zbudowanie
wiarygodnej platformy komputerowej o dużej niezawodności, przy wykorzystaniu elementów
komercyjnych. Przy zastosowaniu odpowiednich technik zabezpieczeń, założenia
odpowiednio krótkiego czasu trwania misji i stosownego ekranowania przed
promieniowaniem (w tym wypadku jest to 3mm warstwa aluminium) oraz implementacji
oprogramowania spełniającego wymagania dotyczące niezawodności, uzyskuje się tani,
dostępny i nowoczesny system komputerowy do realizacji zadań przetwarzania danych oraz
sterowania dla małych satelitów.
Politechnika Warszawska złożyła wniosek projektu edukacyjnego w ramach konkursu
PECS (Plan for European Cooperating States) Europejskiej Agencji Kosmicznej (ESA)
na realizację w pełni funkcjonalnego modelu lotnego OBDH oraz studium uzyskania
podobnej funkcjonalności i niezawodności przy implementacji struktury OBDH w układzie
programowalnym jako kod źródłowy rdzenia własności intelektualnej w języku opisu sprzętu,
np. VHDL. Projekt został pozytywnie zaopiniowany przez Ministerstwo Gospodarki RP oraz
ESA do realizacji wspólnie z Politechniką Wrocławską. Po ratyfikacji traktatu PECS, zostanie
on zrealizowany, gdyż pojawią się na ten cel znaczące fundusze ze strony ESA.
LITERATURA
[1] M. Olak „Studenckie Koło Inżynierii Kosmicznej”, „VII Seminarium z cyklu
Radiokomunikacja i Techniki Multimedialne”, Fundacja Wspierania Rozwoju
Radiokomunikacji i Technik Multimedialnych, Warszawa 2006
[2] Arianespace, “Ariane 5 Auxiliary Payload User manual”, www.arianespace.com
[3] K.Kurek, “Wpływ zastosowania anteny kierunkowej na dokładność – technologie dla
małych satelitów”, „VII Seminarium z cyklu Radiokomunikacja i Techniki
Multimedialne”, Fundacja Wspierania Rozwoju Radiokomunikacji i Technik
Multimedialnych, Warszawa 2006
[4] A. Cichocki „Zintegrowana karta rozszerzenia komputera pokładowego OBDH satelity
SSETI ESEO”, Praca dyplomowa inżynierska, Instytut Systemów Elektronicznych
Politechniki Warszawskiej, Warszawa 2007
[5] M. Gehler, „SSETI ESEO System Requirements”, 2007
[6] J. Romkey, „A nonstandard for transmission of IP datagrams over serial lines: SLIP”,
1988
[7] the Embedded C++ Technical Committee, The Embedded C++ specification, 1999
[8] MPLAG, „MIP405 datasheet”,www.mpl.ch
[9] M. Olak, A. Cichocki, R. Graczyk., T. Cedro „OBDH Core Technical Hardware
Description”, Student Space Exploration and Technology Initiative, 2007
VIII SEMINARIUM - RADIOKOMUNIKACJA I TECHNIKI MULTIMEDIALNE
10