Protokół kosmiczny Cubesat

Protokół kosmiczny CubeSat
Oryginalni autorzy Johana de Claville Christiansena
Deweloperzy SpaceInventor, GomSpace
Pierwsze wydanie 26 kwietnia 2010 r
Wersja stabilna
1.6 / 17 kwietnia 2020 ; 2 lata temu ( 2020-04-17 )
Napisane w C , Pythona
System operacyjny FreeRTOS , Linux , Mac OS X , Microsoft Windows
Typ Protokół
Licencja Mniejsza Powszechna Licencja Publiczna GNU
Strona internetowa Biblioteka Github CubeSat Space Protocol

CubeSat Space Protocol ( CSP ) to mały protokół dostarczania w warstwie sieci przeznaczony dla CubeSatów . [ potrzebne źródło ] Pomysł został opracowany przez grupę studentów z Uniwersytetu w Aalborgu w 2008 roku i dalej rozwijany na potrzeby misji AAUSAT3 CubeSat, która została wystrzelona w 2013 roku. Protokół opiera się na 32-bitowym nagłówku zawierającym zarówno informacje o warstwie sieciowej, jak i transportowej . Jego implementacja przeznaczona jest dla systemów wbudowanych, takich jak 8-bitowy mikroprocesor AVR oraz 32-bitowy ARM i AVR firmy Atmel. Implementacja została napisana w C i została przeniesiona do systemów operacyjnych opartych na FreeRTOS i POSIX oraz pthreads , takich jak Linux . Trzyliterowy akronim CSP został przyjęty jako skrót od CAN Space Protocol , ponieważ pierwszy sterownik warstwy MAC został napisany dla magistrali CAN . Od tego czasu warstwa fizyczna została rozszerzona o kilka innych technologii, w związku z czym nazwa została rozszerzona na bardziej ogólny CubeSat Space Protocol bez zmiany skrótu.

Protokół i implementacja są nadal aktywnie utrzymywane przez Johana de Claville Christiansena, Space Inventor i GomSpace. Kod źródłowy jest dostępny na LGPL i hostowany na GitHub .

Opis

CubeSat Space Protocol umożliwia rozproszonym systemom wbudowanym wdrożenie topologii sieci zorientowanej na usługi. [ potrzebne źródło ] Warstwy CSP odpowiadają tym samym warstwom co model TCP/IP . Implementacja obsługuje protokół transportowy zorientowany na połączenie (warstwa 4), rdzeń routera (warstwa 3) i kilka interfejsów sieciowych (warstwa 1–2). Topologia zorientowana na usługi ułatwia projektowanie podsystemów satelitarnych, ponieważ sama magistrala komunikacyjna jest interfejsem do innych podsystemów. Oznacza to, że każdy twórca podsystemu musi jedynie zdefiniować umowę serwisową i zestaw numerów portów, na które będzie odpowiadał jego system. Ponadto zmniejsza się współzależność podsystemów, a redundancja jest łatwo dodawana poprzez dodawanie wielu podobnych węzłów do magistrali komunikacyjnej.

Kluczowe funkcje obejmują: [ potrzebne źródło ]

  • Proste API podobne do gniazd Berkeley .
  • Rdzeń routera ze statycznymi trasami. Obsługuje przezroczyste przekazywanie pakietów np. przez łącze kosmiczne.
  • Obsługa zarówno operacji bezpołączeniowych (podobnych do UDP ), jak i operacji zorientowanych na połączenie (oparte na RUDP ).
  • Program obsługi usługi, który implementuje żądania podobne do protokołu ICMP , takie jak ping i stan bufora.
  • Obsługa ruchu zwrotnego. Można to np. wykorzystać do komunikacji między procesami między zadaniami podsystemu.
  • Opcjonalna obsługa ruchu rozgłoszeniowego, jeśli jest obsługiwana przez interfejs fizyczny.
  • Opcjonalna obsługa trybu rozwiązłego, jeśli jest obsługiwana przez interfejs fizyczny.
  • Opcjonalne wsparcie dla szyfrowanych pakietów z XTEA w trybie CTR .
  • Opcjonalne wsparcie dla uwierzytelnionych pakietów HMAC z obciętym SHA-1 HMAC.

Obsługiwane systemy operacyjne

CSP powinien kompilować się na wszystkich platformach, które mają najnowszą wersję kompilatora gcc . CSP wymaga obsługi C99 , takich jak funkcje wbudowane i wyznaczone inicjatory.

Sterowniki warstwy fizycznej

CSP obsługuje kilka technologii warstwy fizycznej. Licencjonowany przez LGPL kod źródłowy zawiera implementację fragmentarycznego interfejsu CAN i sterowników dla SocketCAN oraz procesorów Atmel AT90CAN128, AT91SAM7A1 i AT91SAM7A3. Od wersji 1.1 CSP zawiera również interfejsy dla I2C i RS-232 . Interfejsy muszą tylko zaimplementować funkcję przesyłania pakietu i wstawić odebrane pakiety do stosu protokołów za pomocą funkcji csp_new_packet. CSP został pomyślnie przetestowany na następujących warstwach:

Nagłówek protokołu

Wersja 1

Zakres portów podzielony jest na trzy regulowane segmenty. Porty od 0 do 7 są używane do ogólnych usług, takich jak ping i stan bufora, i są implementowane przez program obsługi usługi CSP. Porty od 8 do 47 są używane do usług specyficznych dla podsystemu. Wszystkie pozostałe porty, od 48 do 63, są portami efemerycznymi używanymi do połączeń wychodzących. Bity od 28 do 31 służą do oznaczania pakietów z szyfrowaniem HMAC, XTEA, nagłówkiem RDP i sumą kontrolną CRC32.

Nagłówek CSP 1.x
Przesunięcie bitowe 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1  0
0 Priorytet Źródło Miejsce docelowe Port docelowy
Port źródłowy
Skryty


H M A C


X T E A

R D P

C R C
32 Dane (0 – 65 535 bajtów)

Wersja 2

Nagłówek CSP 2.x
Przesunięcie bitowe 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1  0
0 Priorytet Miejsce docelowe Źródło Port docelowy
Port źródłowy
Skryty


H M A C


X T E A

R D P

C R C
48 Dane (0 – 65 535 bajtów)

Linki zewnętrzne

Pobrano z „ https://en.wikipedia.org/w/index.php?title=Cubesat_Space_Protocol&oldid=1142288756 ”