Realizacja Komputera Pokładowego OBDH Satelity SSETI ESEO
Transkrypt
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