Untitled - MRTC

Intern realtidskommunikation i framtida Svenska satelliter sid 5 

Martin Normark 

MMK 

Master Project MMK 2003:29 MDA 197 

Internal Real-Time Communication in future Swedish 

satellites. 

Machine Design KTH 

Mechatronics Martin Normark 

Approved 

2003-03-11 

Examiner 

Martin Törngren 

Commissioner 

Swedish Space Corporation 

Supervisor 

Martin Törngren 

Contact person 

Gunnar Andersson 

Abstract 

The Swedish Space Corporation, SSC, or Rymdbolaget as it is called in Swedish recently designed 

and delivered a satellite named SMART-1. The satellite will be launched in July 2003 and will be the 

first satellite in the world using CAN, Controller Area Network, for its internal communication. 

However, SSC now wishes to compare the CAN-bus to other potential future networks in order to find 

out if any of those handles real-time communication in a satellite better than CAN does. The 

investigated networks are: 

• CAN 

• TTCAN 

• FlexRay 

• MOST 

• Spacewire 

• TTP/C 

• USB 2.0 

Of the networks listed above, FlexRay is the best suited to fulfil the demands defined in collaboration 

with- the SSC. FlexRay and TTP/C are the only two networks that are believed to get approval for 

steer-by-wire usage, but TTP/C does not pass the SSC demands due to its inflexible TDMA, Time 

Division Multiple Acces. 

Steer-by-wire means that, for example a car or an airplane is not steered with the steering wheel or the 

steering stick mechanically attached to the wheel or the rudder via a steering column but rather 

through a digital network communicating with a microprocessor, controlling a steering servo on its 

part. One problem with FlexRay is that it has not yet been commercialised. 

FlexRay will probably be commercialised earliest in 2004 or 2005, and the SSC will then need to 

evaluate FlexRay concerning functionality, whether it will fulfill its specification or not, and how 

widely spread it has become; something that is of importance for SSC. Until then the CAN-bus is the 

best alternative. The CAN-bus should however be upgraded with better protection against babbling 

idiots, i.e. malfunctioning nodes that destroys all other traffic on the network, a method for 

synchronizing the nodes and desirable is also a EDF function. 

EDF, Earliest Deadline First, is a method that gives the message closest to its deadline access to the 

network. By using a simplified version of EDF, every node can be guaranteed a certain bandwidth, a 

maximum access delay and can also be offered spare bandwidth if any node choose not to use all its 

allocated bandwidth. This thesis shows, by the use of computer-aided simulations and production of a 

prototype EDF-CAN-controller implemented in a FPGA, not only that the simplified EDF method 

works in a CAN network but also that EDF can be included inside an SSC-designed CAN-controller 

as well. 

Beside the studied networks, recommended as steer-by-wire networks, USB and Spacewire are also 

very potential communication links between two nodes. The great benefit with USB is its wide 

commercial spread. What makes Spacewire a good choice is that it is ESA-approved for space usage. 

Spacewire is also already integrated in some components as DSP´s, cameras and mass-memories for 

space use.


Martin Normark



Innehållsförteckning 

1 INLEDNING................................................................................................................................. 9 

2 EX-JOBBSBESKRIVNING...................................................................................................... 11 

2.1 MÅL...................................................................................................................................... 11 

2.2 METOD.................................................................................................................................. 11 

2.2.1 Intervjuer med Rymdbolaget-personal ......................................................................... 11 

2.2.2 Skapande av kravspecifikation ..................................................................................... 11 

2.2.3 Studie av befintliga nätverksprotokoll.......................................................................... 11 

2.2.4 Val och implementation av nätverksprotokoll .............................................................. 11 

3 INTERVJUER MED RYMDBOLAGET-PERSONAL.......................................................... 13 

3.1 INTERVJU MED SYTZE VELDMAN .......................................................................................... 13 

3.2 INTERVJU MED BENGT HOLMQVIST ...................................................................................... 13 

3.3 INTERVJU MED GUNNAR ANDERSSON ................................................................................... 13 

4 KRAV PÅ NÄSTA SATELLITGENERATIONS 

INTERNKOMMUNIKATIONSNÄTVERK................................................................................... 15 

4.1 SYSTEMBUSSEN .................................................................................................................... 15 

4.2 PAYLOADBUSSEN.................................................................................................................. 15 

4.3 TIDSSTYRDA RESPEKTIVE HÄNDELSESTYRDA NÄTVERK OCH NODER .................................... 16 

4.4 TESTNING OCH UTVECKLING................................................................................................. 16 

4.5 RYMDENS KRAV.................................................................................................................... 16 

4.5.1 Vakuum......................................................................................................................... 16 

4.5.2 Strålning.......................................................................................................................16 

4.5.3 Rymdskrot..................................................................................................................... 17 

4.6 REDUNDANS OCH FELHANTERING ......................................................................................... 17 

4.7 ELEKTRISKT GRÄNSSNITT ..................................................................................................... 18 

4.8 SAMMANFATTNING AV KRAV................................................................................................ 18 

5 KORT BESKRIVNING AV BEFINTLIGA NÄTVERK SOM KAN KOMMA IFRÅGA . 19 

5.1 CAN ..................................................................................................................................... 19 

5.1.1 Protokoll.......................................................................................................................19 

5.1.2 Elektriskt interface ....................................................................................................... 20 

5.2 USB...................................................................................................................................... 20 

5.2.1 Protokoll.......................................................................................................................20 

5.2.2 Elektriskt gränssnitt...................................................................................................... 21 

5.3 SPACEWIRE ........................................................................................................................... 21 

5.3.1 Protokoll.......................................................................................................................22 


5.4 TTP/C................................................................................................................................... 23 

5.4.1 Protokoll.......................................................................................................................23 


5.5 TTCAN ................................................................................................................................ 24 

5.5.1 Protokoll.......................................................................................................................25 


5.6 FLEXRAY .............................................................................................................................. 27 

5.7 MOST................................................................................................................................... 28 

5.7.1 Protokoll.......................................................................................................................28 


6 VAL AV NÄTVERK..................................................................................................................31 

6.1 BEDÖMNINGSMALL............................................................................................................... 31 

6.2 GALLRING AV NÄTVERK ....................................................................................................... 31 

6.3 SLUTLIGT NÄTVERKSFÖRSLAG FÖR STEAM......................................................................... 31 

6.4 SLUTLIGT GENERELLT NÄTVERKSFÖRSLAG FÖR KOMMANDE SATELLITER ............................ 32



7 TESTIMPLEMENTATION AV CAN SOM ANVÄNDER EARLIEST DEADLINE FIRST 

33 

7.1 KORT BESKRIVNING AV EDF ................................................................................................ 33 

7.2 BESKRIVNING AV ANVÄND EDF-ALGORITM ......................................................................... 34 

7.3 MÅL MED TEST...................................................................................................................... 35 

7.4 SIMULERING AV CAN MED EDF........................................................................................... 36 

7.5 IMPLEMENTATION I VHDL ................................................................................................... 37 

7.6 SIMULERING AV FUNKTION HOS KOD SKRIVEN I VHDL ........................................................ 38 

7.7 PRODUKTION AV TESTHÅRDVARA IMPLEMENTERAT I EN FPGA........................................... 41 

7.8 TEST AV FPGA ..................................................................................................................... 42 

7.8.1 Testprocedur................................................................................................................. 44 

7.8.2 Testresultat................................................................................................................... 45 

8 RESULTAT ................................................................................................................................ 49 

8.1 REKOMMENDERAT NÄTVERK I FRAMTIDA SATELLITER ......................................................... 49 

8.2 TEST AV FÖRBÄTTRAD CAN-BUSS........................................................................................ 49 

8.2.1 Simulering av EDF-CAN-buss ..................................................................................... 49 

8.2.2 Simulering av funktion hos EDF-CAN-Shellet ............................................................. 50 

8.2.3 Test av EDF-CAN-controller implementerad i FPGA ................................................. 50 

9 SLUTSATS ................................................................................................................................. 51 

10 DISKUSSION OCH MÖJLIGHETER FÖR FRAMTIDA UTREDNINGAR................. 53 

11 TACK TILL............................................................................................................................ 55 

12 BEGREPP OCH FÖRKORTNINGAR SOM ANVÄNDS I DENNA RAPPORT............ 57 

13 REFERENSER....................................................................................................................... 59 

13.1 MUNTLIGA KÄLLOR OCH INTERVJUER................................................................................... 60 

13.2 LITTERATURTIPS ................................................................................................................... 60 

APPENDIX A SIMULERING AV EDF-ALGORITM................................................................... 61 

APPENDIX B INTERVJUER AV RYMDBOLAGSPERSONAL ................................................ 71 

FRÅGOR ............................................................................................................................................ 71 

Svar på frågor Sytze Veldman...................................................................................................... 71 

Svar på frågor Bengt Holmqvist................................................................................................... 72 

Svar på frågor Gunnar Andersson ............................................................................................... 73 

APPENDIX C VHDL-KOD I CAN-SHELL.................................................................................... 75 

TRANSMISSION_STATE_MACHINE.................................................................................................... 75 

RETRANSMISSION_BUFFER ............................................................................................................... 79 

APPENDIX D VHDL-KOD FÖR TEST 5.1 OCH 6.1.................................................................... 81 

APPENDIX E……………………………………….…………………………………………Se utvikbar bild



1 Inledning 

Rymdbolaget, eller Swedish Space Corporation, SSC, som bolaget heter på engelska, jobbar precis 

som namnet antyder, med tjänster och produkter inriktade mot rymdindustrin. Som exempel kan 

nämnas: Kommunikationslänkar till satelliter, service på rymdbasen Esrange strax utanför Kiruna, 

experiment som utförs i viktlöst tillstånd samt utveckling av satelliter. Rymdbolagets huvudsakliga 

kunder är Svenska Rymdstyrelsen och ESA, European Space Agency, men många andra kunder 

förekommer. 

Den senaste satelliten heter SMART-1 och får betraktas som en försökssatellit. SMART-1 är utrustad 

med en nyutvecklad solcellsdriven jonmotor som skall föra satelliten från en bana nära jorden ut till 

månen för att där placeras i en bana kring densamma. SMART-1 är även unik på ett annat sätt, den är 

nämligen den första satellit som utrustats med CAN-bussen för sin interna kommunikation mellan 

instrument och datorer ombord. 

CAN, Controller Area Network, utvecklades av BOSCH 1989 och var i första hand tänkt som ett 

tvåtråds-nätverk mellan diverse mikrokontrollers i bilar. Dock har standarden spridits till ett flertal 

olika industriella tillämpningar och har nu även tagit steget upp i rymden. En elektronisk 

nätverksstandard utvecklad för bilindustrin måste vara mycket robust och okänslig för störningar, då 

en bil är en mycket svår miljö med avsevärda vibrationer, smuts, fukt och inte minst elektroniska 

störningar. Dessa egenskaper har CAN, som inbyggt i protokollet har funktioner för såväl 

feldetektering som felhantering, där felaktiga meddelanden automatiskt sänds om m.m. 

CAN-protokollet är, i sitt grundutförande, dock behäftat med ett antal svagheter som kan medföra 

problem och/eller begränsningar ombord på en satellit. Som exempel kan nämnas att CAN är ett så 

kallat händelsestyrt protokoll, vilket innebär att varje nod i nätet kan försöka sända när som helst och 

en på förhand fastställd prioritering avgör vilken nod som skall få sända först. Detta passar inte så bra 

i ett realtidsstyrt reglersystem där det är viktigt med väl synkroniserade noder som kräver tillgång till 

ett deterministiskt nätverk där det i förhand är känt vilken nod som i en given tidpunkt har tillgång till 

nätverket. Vidare erbjuder CAN-protokollet endast en begränsad bandbredd, 1 Mbps, vilket kan vara 

för lite för instrument som kontinuerligt sänder mycket information, t.ex. en kamera. CAN-protokollet 

erbjuder heller ingen inbyggd redundans, vilket är nödvändigt ombord på en satellit. Det skall dock 

tilläggas att CAN-protokollet genom att det har funktioner på en låg nivå tillåter den enskilde 

designern att själv lägga till funktionalitet såsom exempelvis sändscheman, det är bland annat denna 

strategi som lett till CAN´s stora framgång. 

Rymdbolaget har fått i uppdrag av Rymdstyrelsen att presentera ett förslag till design för en eventuell 

framtida satellit, STEAM, vars uppgift kommer att bli att mäta växthusgaser i atmosfären i en cirkulär, 

solsynkron bana 700 km över jordytan. Rymdbolaget avser att i STEAM uppgradera CAN-bussen till 

en buss som inte bara passar STEAM´s mission samt eliminerar ovan nämnda svagheter, utan även 

kan tänkas i framtida generationer av satelliter. 

Detta examensarbete avser utreda huruvida det är möjligt att delvis eller helt ersätta nuvarande CANbuss 

med en alternativ buss, alternativt komplettera CAN-bussen med mjukvara, i syfte att tillgodose 

framtida behov.


Martin Normark



2 Ex-jobbsbeskrivning 

2.1 Mål 

Målet med examensarbetet är att finna den lämpligast möjliga designen för de interna nätverken 

ombord på Rymdbolagets framtida satelliter. Med framtida satelliter avses främst STEAM som 

projekteras just nu. Men nätverket bör även designas på sådant sätt att det kan användas i framtida, i 

dagsläget ej planerade, satelliter. Nätverket skall vara så robust att funktionen kan garanteras under 

satellitens hela livslängd, vidare skall det uppfylla kraven på nästa satellitgenerations 

internkommunikationsnätverk, närmare beskrivet i kap 4. 

2.2 Metod 

2.2.1 Intervjuer med Rymdbolaget-personal 

Arbetet inleds med intervjuer av Rymdbolaget-personal. Intervjuerna fokuseras kring följande 

punkter: 

• Systemkrav 

• Bandbreddsbehov 

• Behov av tidsstyrda respektive händelsestyrda nätverk och noder 

• Synkronisering av noder 

• Redundans och felhantering 

• Rymdens krav 

• Skillnader mellan Systembussen och Payloadbussen 

• Dagens design i SMART-1 

• Vikten av återanvändning av tidigare nätverk 

• Elektriskt gränssnitt 

2.2.2 Skapande av kravspecifikation 

Intervjuerna syftar dels till att skapa förståelse för designen hos framtida sateliter men framför allt till 

att formulera kraven på nästa satellitgenerations internkommunikationsnätverk (se kap 4). 

Kravspecifikationen skall styra in studierna av befintliga nätverk åt rätt håll samt ligga till grund för 

eventuella mjukvarutillägg till det nätverksprotokoll som slutligen väljs. 

2.2.3 Studie av befintliga nätverksprotokoll 

Följande nätverk kommer att studeras: 

• USB 

• Spacewire 

• TTP/C 

• CAN/TTCAN 

• FlexRay 

• MOST 

Inledningsvis inriktas studierna mot en översiktlig förståelse av protokollens huvudsakliga 

egenskaper, vilka sedan jämförs i en jämförelsemall (se bilaga). Därvid sker en första gallring, 

varefter de återstående 2-3 nätverksprotokollen studeras närmare. 

2.2.4 Val och implementation av nätverksprotokoll 

I samråd med Rymdbolaget-personal väljs det lämpligaste nätverksprotokollet. Detta implementeras 

sedan i syfte att visa att kravspecifikationen efterlevs. Vikt läggs därvid att implementera de nya 

egenskaperna och då framför allt de som eventuellt måste läggas till mjukvarumässigt.


Martin Normark



3 Intervjuer med Rymdbolaget-personal 

Intervjuformulär, samt de intervjuades svar på frågorna finns utskrivet i sin helhet i Appendix B. 

3.1 Intervju med Sytze Veldman 

Sytze Veldman [16] arbetar med systemutveckling inom Space Systems på Rymdbolaget. 

Enligt Sytze finns planer på att separera satellitplattform och instrumentering varvid instrumenten 

förses med eget mass-minne. 

Veldman är mycket nöjd med CAN-bussen som den används i SMART-1. 

Om endast radioskopet används räcker CAN-bussen gott och väl. Detta under förutsättning att 1 

Mbps-länk finnes mellan mass-minne och TMTC. 

3.2 Intervju med Bengt Holmqvist 

Bengt Holmqvist [17] jobbar bl.a. med kommunikation mellan GS (ground station) och satellit. 

Han skulle gärna se en kommunikationsmetod i satelliten som är kompatibel med vanliga 

kommunikationsmetoder på jorden t.ex. USB 2.0 eller TCP/IP. Fördelen med det är att den enskilde 

forskaren kan använda samma protokoll vid testning på jorden samt vid kommunikation med det 

enskilda experimentet i realtid, via exempelvis Internet, då satelliten ligger i sin bana. Bengt menar 

dock att en sådan förändring kan bli alltför stor, såtillvida att den tar för lång tid och kostar för mycket 

att implementera, och kan ställa för höga krav på såväl mjuk- som hårdvara ombord på satelliten. 

Bengt betonar att ett nätverk som erbjuder god testbarhet för såväl instrument som nätet självt sparar 

mycken tid i utveckling och testning. 

Bengt tycker även att USB 2.0 kan vara intressant, främst med tanke på utveckling och testning, då 

USB 2.0 är så pass kompatibel med en vanlig PC på jorden. 

Han gör bedömningen att en trolig överföringshastighet, inom en överblickbar framtid, mellan GS 

och Rymdbolaget-tillverkad satellit med banhöjder motsvarande STEAM blir ca 1 Mbps. 

Ett framtida de facto standard-gränssnitt på rymdinstrument och avancerade komponenter kan tänkas 

bli TCP/IP eller Spacewire. 

CAN-bussen är ett bra alternativ, såtillvida att den uppfyller de krav som ställs. Dock kan 

felhanteringen förbättras. En bättre synkronisering av noderna kan dock vara önskvärd, detta medför 

även att nuvarande sekund-tick som idag sänds, i SMART-1, på en enskild förbindelse kan läggas 

över nätet istället. 

3.3 Intervju med Gunnar Andersson 

Gunnar Andersson [18] arbetar med systemdesign och har bl.a. designat CAN-bussen på SMART-1. 

Gunnars många men relativt kortfattade riktlinjer för ett nätverk är att det skall vara: 

• Säkert 

• Redundant 

• Standardiserat på något sätt 

• Tillräckligt EMC-tyst 

• Effektsnålt 

• Tillräckligt bredbandigt 

• Avlyssningsbart i en punkt 

Gunnar anser att det som borde förbättras/läggas till jämfört med nuvarande CAN-buss är 

• Redundansen, använd två linor kontinuerligt 

• Global klockdistribution 

• Synkronisering av noder, 0,1 ms 

• Om bandbredden skall ökas skall den minst tiofaldigas


Martin Normark



4 Krav på nästa satellitgenerations 

internkommunikationsnätverk 

Generellt kan sägas att det finns ett självändamål med att återanvända så mycket som möjligt av 

tidigare design, då detta sparar tid och pengar framför allt i utvecklingsfasen. Samtidigt måste givetvis 

kraven som ställs på nätverket uppfyllas. Dock är vissa krav mer att betrakta som önskemål även om 

gränsen är tämligen flytande. Vissa kombinationer av krav kan också vara mer eller mindre omöjliga 

att realisera samtidigt. Sedermera kommer alltså krav att ställas mot återanvändning, men även krav 

som ställs emot andra krav kommer att förekomma, på samma sätt som det är svårt att bygga en 

fjäderlätt pansarvagn med gott skydd. Det skall tilläggas att ingen idag vet hur nästa satellit eller 

satellitgeneration ser ut. Därför får kraven en ganska allmän karaktär och många grundläggande 

designdrag, varav många givetvis från SMART-1 [1], såsom den av Rymdbolaget ganska flitiga 

uppdelningen mellan last, (payload) som ofta består av instrument och kameror, och satellitens egna 

system. 

4.1 Systembussen 

Systembussens uppgift är som namnet antyder att erbjuda kommunikation mellan alla delar i 

satellitens systemdelar, t.ex. de delar som sköter kommunikationen med jorden, positionsangivning, 

attitydstyrning, elkraftreglering, huvuddator. Systembussens meddelandekaraktär är således till större 

delen av typen periodiskt återkommande kontrollmeddelanden. Perioden ligger idag kring 1 Hz. I 

framtida satelliter där det kan komma att ställas allt högre krav på positions- och attitydstyrningen 

kommer periodfrekvensen att öka, en ökning med tio gånger ska nog inte ses som orealistisk, även om 

detta är spekulationer. Detta gäller dock inte den/de närmaste i tiden kommande satelliterna. Trots en 

ökad periodicitet, kommer inte mängden information per cykel att minska, dock kan tänkas att 

noggrannheten, d.v.s. antalet databitar, i kontrolldatameddelandena ökar varför även mängden data per 

cykel kan tänkas öka med upp till 50%. I dagens CAN-buss lösning används 3,25 % av tillgänglig 

bandbredd, en framtida satellit kan därför tänkas använda: 

10 ⋅ ( 1, 

5⋅ 

3, 

25%) 

= 48, 

75% 

≈ 50% 

av tillgänglig bandbredd. 

Att i princip 50 % av tillgänglig bandbredd används kan tyckas ligga på den övre gränsen av vad som 

bör allokeras i ett nätverk. Dock kan i ett tidsschememässigt uppstyrt nätverk höga nätlaster tillåtas, då 

inga toppar och dalar i kommunikationen tillåts. Det är dock stor risk att systemet växer ur nätverket 

om ytterligare funktionalitet läggs till. Därför kan en bandbreddshöjning tänkas vara klok då nästa 

nätverksgeneration skall designas. 

Med större noggrannhet i position och attityd följer ett större noggrannhetskrav vad gäller 

synkroniseringen noderna emellan och att en distribuerad global tid med hög noggrannhet når alla 

noder. Ett minsta krav, enligt Gunnar Andersson på Rymdbolaget [18], på noggrannheten är 100µs, 

gärna bättre. Styrsystem med hög prestanda kräver dessutom att tiden det tar att sända ett meddelande 

på förhand är känd och kan garanteras för viktiga meddelanden. Detta kräver alltså ett tämligen 

deterministiskt nätverk. 

Nätverket bör dessutom vara distribuerat, d.v.s. att alla noder skall höra samtliga meddelanden, detta 

då flera noder än en sannolikt behöver ta del av information som position, tid och globala uppgifter 

vid en given tidpunkt. 

Systembussen är idag skild från payloadbussen av två skäl: Framför allt ökas säkerheten, såtillvida att 

ett instrument som ”löper amok” inte saboterar trafiken på systembussen utan istället kan stängas av, 

genom att strömmen till enheten kopplas bort med hjälp av ett kommando från jorden eller från 

huvuddatorn ombord. Det andra skälet är att en högsta fördröjning av viktiga meddelanden lättare kan 

garanteras. Kan säkerheten på ett framtida nät höjas, genom att t.ex en busguardian bevakar varje nod 

och stänger av en skenande dylik, samt den garanterade sändningstiden för viktiga meddelanden hålls 

låg, kan de både näten slås samman. 

4.2 Payloadbussen 

Syftet med satelliten är i allmänhet att bära en nyttolast. Lasten består ofta av diverse instrument 

och/eller sambandsutrustning. Payloadbussen erbjuder dessa typer av noder 

kommunikationsmöjligheter instrumenten emellan men framför allt med controllern, satellitens 

huvuddator. Då det i själva verket är nyttolasten som ställer de allt högre kraven på satellitens position



och attityd, är det rimligt att anta att nyttolasten kräver tillgång till samma distribuerade globala tid 

med samma noggrannhet som systemenheterna d.v.s. 100 µs, gärna bättre. Vad beträffar determinism i 

kommunikationen ställs inte samma krav som på systemsidan. Ett flexibelt sätt att få tillgång till 

nätverket kan i själva verket vara att föredra. Ett av skälen är att vissa instrument t.ex. en kamera 

kanske bara ibland, typiskt när ett foto precis har tagits, vill ha tillgång till bussen och snabbt tömma 

sin minnesbuffert för att tillåta fler bilder att tas. Flexibiliteten kan lösas antingen genom att 

arbitrering avgör vilken nod som får sända vid vilket ögonblick, alternativt genom att tidsschemat kan 

byta mode såtillvida att olika noder får olika tillgång till nätet beroende av vilken huvudsaklig uppgift 

satelliten löser vid ett givet tillfälle eller genom att bandbredden är så pass stor att alla noder ständigt 

har tillgång till sin toppbelastning. Den senare av dessa lösningar kan av andra skäl, såsom EMC, 

effektförbrukning och störningskänslighet, dock vara mindre lämplig 

Bandbredden är svår att sia om då den är helt beroende av lasten, alla de intervjuade på rymdbolaget 

är dock överens om att en för liten bandbredd inte får tillåtas begränsa verksamheten. Då 

payloadbussen ofta utsätts för punktlaster kan det vara lämpligt att dimensionera efter dessa och en 

bandbredd uppemot 10 Mbps kan vara lämpligt även om 1Mbps räcker gott och väl för SMART-1 och 

för STEAM. 

4.3 Tidsstyrda respektive händelsestyrda nätverk och noder 

Även om trenden inom inbäddade system går mot mer och mer tidsstyrda noder, planeras systemet 

bestå av både tidsstyrda- och händelsestyrda noder. Därför bör nätverksprotokollet stödja såväl 

schemalagd- som spontan sändning av meddelanden. Nätverket skall distribuera global tid samt 

synkronisera noderna med en noggrannhet om minst 100 µs. Om ett nätverk med endast schemastyrd 

tilldelning till bussen ändå väljs, måste det ha tillräcklig bandbredd för att de noder som bara behöver 

sända ibland ändå tilldelas minst en tidslucka i varje TDMA-omgång. Dessutom kan dessa noder 

behöva ett gränssnitt mellan applikation och nätverk som säkerställer att applikationen använder sina 

egna tidsluckor även om applikationen i sig inte "känner till" att dessa finns, då applikationen är helt 

händelsstyrd. 

4.4 Testning och utveckling 

Vikt skall läggas vid att nätverksprotokollet redan tidigare är väl använt och spritt, då detta medger att 

kringutrustning och kunnig personal är lättare att få tag på. 

All trafik på en buss skall gå att avlyssna från en punkt i nätet, i syfte att möjliggöra testning och 

diagnostisering. 

4.5 Rymdens krav 

Att sateliten skall skickas upp i rymden ställer mycket höga krav på utrustningen. Inte bara förhåller 

det sig så att reparationer i praktiken är helt otänkbara för de flesta satelliter, rymdmiljön i sig är 

mycket krävande. Nedan tas de ur elektronikutvecklingshänseende besvärligaste aspekterna upp. 

4.5.1 Vakuum 

Elektronik påverkas av vakuum på sådant sätt att komponenter som i vanliga fall använt luft för 

kylning inte kan göra det. Detta kan leda till överhettning och det problemet löses lättast genom att 

använda energisnåla komponenter. Värmet kan även ledas till radiatorer där det strålas ut i rymden. 

Vakuum leder även till att många material, däribland många plaster, gasar ur. Det vill säga att det 

obefintliga omgivande trycket får materialet att sakta men säkert förgasas. Detta är givetvis inte 

önskvärt, utan material som klarar vakuum måste användas till isolering, kretskort, 

komponentinneslutningar m.m. 

4.5.2 Strålning 

Det finns, enligt Leif Granholm [19] på Rymdbolaget, många sorters strålning och de kan delas upp i 

Gamma- och partikelstrålning. Partikelstrålningen kan i sin tur delas upp i protonstrålning, 

elektronstrålning och tunga joner. 

Gammastrålningen, som består av högenergetiska fotoner, skapar bl.a. dislokationer i 

komponenternas kiselstrukturer, varför komponenterna degenererar vilket leder till ökade 

läckströmmar, minskade förstärkningar och allmänna defekter. Gammastrålningens intensitet kan 

minskas med blysköldar men det är knappast aktuellt inom rymdindustrin, med tanke på sköldarnas 

vikt.



Protonstrålning orsakar inte bara samma skador som gammastrålning utan dess elektriska laddning 

kan dessutom leda till att databitar, d.v.s. logiska ettor resp. nollor, kan byta värde i såväl kablar, 

processorer som minnen. Detta fenomen kallas ibland för bit-flip. Ett centimetertjockt aluminiumhölje 

utgör dock ett gott skydd mot protonstrålning. 

Tunga joner är elektriskt laddade och har höga energier, ibland över 1GeV. De orsakar i stort sett 

samma skador som gammastrålning och protonstrålning, d.v.s. degenerering och bit-flips. De tunga 

jonerna är p.g.a. dess höga energier, i praktiken omöjliga att skärma av rent fysiskt. 

Uppladdning av dielektrikum förekommer också, detta orsakas av alla laddade partiklar och kan 

leda till elektriska överslag i och mellan kretsar. 

Även s.k. Latch-up kan förekomma, detta kan liknas vid en kortslutning i chipet som mycket 

snabbt leder till haveri i kretsen om inte strömmen bryts mycket snabbt. En strömåtgångsövervakare 

kan dock användas för att i förekommande fall bryta strömmen till den felande kretsen. Efter att 

strömmen brutits kan kretsen startas upp igen på normalt sätt. 

Stråldoser mäts i rad eller gray (100 rad = 1 gray) där gray är en SI-enhet [J/kg]. Strålningen 

varierar med avståndet till jordytan och generellt kan sägas att den ökar med höjden, då jordens 

magnetfält minskar. Men även andra faktorer spelar in, som t.ex. strålningsbälten runt jorden, solens 

aktivitet, dag- respektive nattsida av jorden m.m. Den närmast, i tiden, planerade svenska satelliten 

STEAM skall cirkla runt jorden i en cirkulär solsynkron bana, 700 km över jordytan i 4 år. STEAM 

beräknas då exponeras för en strålningsdos om högst 100 Gray. I sammanhanget kan nämnas att 4 

Gray betraktas som en dödlig dos för en människa. 

Då ett normalt mikrochip av kisel klarar en dos om cirka 20 Gray kan dessa inte nyttjas utan 

strålningståliga komponenter måste användas. Strålningståliga komponenter finns och de klarar 

strålning i olika klasser mellan 30 och 10.000 Gray. Komponenterna tillverkas dock i små serier och 

endast ett fåtal olika komponenter och kretsar ges ut i strålningstålig modell. Att ta fram en ny 

strålningstålig modell är mycket kostsamt, varför detta sällan sker. Detta leder till att till synes triviala 

komponentval kan bli relativt komplexa. Dock finns strålningsklassade FPGA:er på marknaden. 

FPGA:er är logiska programmerbara grindnätverk i vilka det är möjligt att programmera instruktioner, 

kod och information. Dessa kan sedan användas som mikrokontrollers. Storleken och hastigheten på 

dessa är dock begränsade. En rimlig storlek för en nätverkskontroller är, enligt Gunnar Andersson på 

Rymdbolaget, kring 100 000 grindar. 

Då det är svårt att skärma alla kablar mot protonstrålning och omöjligt att begränsa tungajonstrålningen 

är bit-flippar inte möjliga att undvika. I stället måste datorerna ombord vara 

programmerade för att upptäcka och rätta till skadad information. 

4.5.3 Rymdskrot 

I jordens närhet finns en mängd partiklar från dammkornsstorlek och uppåt. En del av dessa partiklar 

är rester av tidigare mänsklig rymdverksamhet. En satellit som ligger i STEAM´s bana rör sig med ca 

7 km/s, det är troligt att en partikel i dess närhet håller minst samma hastighet. Det innebär att 

hastighetsskillnaden mellan två kolliderande föremål med stor sannolikhet är flera tusen m/s, detta kan 

jämföras med en gevärskula vars hastighet, när den träffar målet, sällan överstiger 900 m/s. Att 

resultatet av en dylik träff är förödande inses lätt -minst det delsystem som direktträffas kan slås ut. 

Det finns i praktiken bara två sätt att minska risken för katastrofer av detta slag: Genom att undvika 

banor där mycket rymdskrot förekommer samt att bygga in redundans i systemet. Redundansen 

innebär ofta att varje delsystem finns duplicerat. 

4.6 Redundans och felhantering 

Med tanke på rymdens krav är i stort sett hela satelliten redundant. Det vill säga, att om en komponent 

(single point of failure) eller, i de flesta fall, ett delsystem faller bort av någon anledning, finns minst 

ett alternativt sätt att lösa den bortfallna komponentens uppgift. Detta gäller även nätverket, som 

därför alltid skall sända över två parallella, av varandra oberoende linjer. Controllern skall sedan, om 

så är fallet, sortera bort det felaktiga meddelandet. 

Protokollet skall ha funktioner för att finna och automatiskt rätta till enskilda fel som beror av sändfel 

eller störningar. Systemet skall vidare kunna identifiera samt stänga av och/eller möjligöra 

avstängning av en nod, en så kallad babbling idiot, som kontinuerligt skapar sändfel och på så sätt stör 

ut bussen.



4.7 Elektriskt gränssnitt 

CAN-bussen i SMART-1[1] använder RS-485, ett standardiserat, differentierat elektriskt gränssnitt 

som erbjuder ca 10Mbit/s i överföringshastighet och förbrukar ca 0,3 W per nod. Ett snabbare och 

säkrare nät kan tillåtas förbruka något mer men effektuttag över 1 W bör undvikas. Vidare skall 

bussen vara tålig mot kortslutning och ESD och ej heller stråla ut för mycket EMC. 

4.8 Sammanfattning av krav 

Nedan sammanfattas de krav som redovisats i detta kapitel i fallande prioritetsordning. 

• Alla komponenter ingående i nätverket skall vara rymdklassade eller rymmas i en FPGA med 

högst 100 000 grindar. 

• Feldetektion samt felhantering skall vara minst lika bra som i CAN. 

• En babbling idiot, eller ”död nod” skall gå att identifiera och åtgärder vidtagas. 

• Bandbredden på systemsidan skall vara minst 1Mbps, gärna mer, med mindre än ca 50 % 

overhead,. 

• Bussen geografiska totala längd skall kunna uppgå till minst 5m. 

• Nätverken skall kunna distribuera global tid och kunna synkronisera noderna noggrannare än 100µs. 

• Nätverket skall stödja såväl tidsstyrda som händelsestyrda applikationer. 

• Nätverket skall kunna allokera bandbredd till den nod som anses behöva den mest, alternativt 

erbjuda samtliga noder toppbelastning vid varje tillfälle. 

• Hela nätverket skall vara redundant, såtillvida att all information ständigt sänds över två linor 

alternativt ha möjlighet att byta lina om det går ner. 

• All nätverkstrafik skall vara avlyssningsbar i en punkt. 

• Alla noder på respektive buss skall kunna sända meddelanden till varandra, om så krävs via en 

bussmaster 

• Nätverket skall vara väl spritt. 

• Payload bussen kan ha en bandbredd om 1Mbps men bör ha en bandbredd om minst 10 Mbps. 

Även här med ca 50 % overhead. 

• System- och payloadbuss kan, men måste inte vara separerade. 

Vidare skall stor vikt läggas vid att finna en robust lösning där tillförlitlighetstänkande dominerar.

NOD 

A 



5 Kort beskrivning av befintliga nätverk som kan komma 

ifråga 

5.1 CAN 

Can används idag i satelliten SMART-1 [1] och utgör såväl payload- som systembuss. CAN som är 

utvecklat av BOSCH som ett inbäddat nätverk för bilar, sprids nu mycket snabbt även bland 

användare utanför bilindustrin. Anledningarna till dess stora användning är dess robusthet, felsäkerhet 

och enkelhet. CAN-controllers finns numera inbyggda i många av de microcontrollers som säljs på 

marknaden, varför dessa kan kopplas ihop till ett nätverk utan alltför stort besvär. CAN implementerar 

OSI-modellens lager 1-2 och passar bra för korta frekventa kontrollmeddelanden. 

5.1.1 Protokoll 

CAN är [3] ett distribuerat nätverk, d.v.s. alla noder ingående i nätverket hör vad alla andra noder 

sänder. 

NOD 

B 

Figur 5.1 CAN´s topologi 

NOD 

C 

NOD 

D 

All information sänds i paketform, paketen kallas meddelanden. Meddelandet har ingen explicit adress 

utan snarare en ID-kod som beskriver dess innehåll. De noder som är programmerade att läsa en viss 

typ av meddelanden gör det, de andra låter bli. En nod kan både lyssna på och sända iväg flera olika 

meddelandetyper. ID-koden som är 11 (CAN 2.0A) eller 29 bitar (CAN 2.0B) beskriver även 

meddelandets prioritet om flera noder önskar sända samtidigt. Då sker en så kallad arbitrering där 

meddelandet med högst prioritet får sända först. Av den anledningen kallas den del av meddelandet 

som innehåller ID-koden för arbitreringsfält. Efter arbitreringsfältet följer ett kontrollfält som anger 

meddelandets typ och längd, följt av ett datafält. Datafältet innehåller 0-8 bytes data. Efter datafältet 

följer en 15 bitars CRC-checksumma som används för feldetektering. Sist kommer en lucka som heter 

ACK-slot, i den meddelar de noder som uppfattat -och inte hittat något fel på- meddelandet, detta. 

Med andra ord räcker det med att en nod uppfattar meddelandet för att sändarnoden skall uppfatta 

meddelandet som uppfattat av alla. Det finns dock ingen garanti för att den tilltänkta noden verkligen 

uppfattat meddelandet. 

Figur 5.2 Meddelandepaketets utseende för CAN 

Vilken nod som helst kan, om den uppfattar något fel, avbryta pågående sändning varvid sändande 

nod avbryter och automatiskt sänder om. Om ingen nod uppfattar meddelandet sänds det också om. 

CAN HI 

CAN LOW



Arbitreringen ställer krav på samtidighet bland noderna, därför är den högsta tillåtna hastigheten 

1 Mbps och då måste bussens sammanlagda längd understiga 40 m. Med ökande fysisk längd, på 

bussen, minskar den högsta möjliga hastigheten. 

CAN har inget inbyggt stöd för tidsscheman eller synkronisering av noder, det finns heller ingen 

inbyggd funktion för att identifiera, och tysta, en så kallad babbling idiot. 

5.1.2 Elektriskt interface 

ISO 11898, 5 V differentierad tvinnat par terminerad med två 120 ohms motstånd i vardera änden, 

rekommenderas av CAN-standarden. RS-485 eller motsvarande går också att använda. 

5.2 USB 

USB 2.0 har på kort tid blivit mycket populär inom hemdatorindustrin, detta framför allt på grund av 

dess stora spridning bland kringkomponenter, dess höga bandbredd samt att den är mycket enkel att 

använda för slutanvändaren. USB 2.0 [4] synkroniserar alla noder varje 1 ms (125 µs för USB High 

Speed) men är detta till trots inte lämpad för schemastyrda realtidsapplikationer. Dock kan USB 2.0 

tänkas vara ett bra alternativ på payloadsidan då det får betraktas som mycket flexibelt och erbjuder 

hög bandbredd. 


USB [4] kan beskrivas som en pyramid-hierarki med stjärnnät, där en master i toppen pollar upp till 

127 noder anslutna till högst 7 hubbar. Varje nivå i pyramiden ytgörs av minst en hub, men flera 

hubbar kan ligga på samma nivå. 

Figur 5.3 Topologin hos USB 

Protokollet stödjer in- och urkoppling av noder och hubbar utan att nätverket behöver stängas ned. 

Det finns tre hastighetsstandarder: 

- USB Low Speed: 1,5 Mbps 

- USB Full Speed: 12 Mbps, vanligt i PC 

- USB High Speed: 480 Mbps



Feldetektering erbjuds med hjälp av CRC för både controll- och datafält, enligt tillverkaren skall 

CRC:n upptäcka 100% av alla enkel- eller dubbelbitsfel. Då ett fel upptäcks erbjuder standarden 

automatisk omsändning och/eller rapport om fel. 

Det finns fyra dataflödestyper: 

- Control Transfers: Används då en ny nod kopplas in eller då nätet startas upp. En applikation 

kan tillåtas välja att använda Control Transfers till ytterligare inställningar även efter att den 

blivit inkopplad. 

- Bulk Transfers: Överföring av en större mängd data t.ex. en bild eller motsvarande. Bulk 

Transfer använder automatisk feldetektion. Hur stor del av den totala bandbredden som används 

regleras automatiskt med hänsyn till annan trafik på bussen d.v.s. ej allokerad bandbredd tilldelas 

Bulk transfers. 8, 16, 32 eller 64 bytes kan sändas per paket. 

- Interupt Transfers: Litet meddelande som kan skjutas in när som helst av vem som helst med 

en garanterad högsta fördröjning. Max 64 bytes (1024 bytes för USB High Speed) kan överföras 

i en transfer. 

- Isochronous Transfers: Kontinuerlig realtidssändning t.ex. audio eller video. Helt utan 

feldetektering och felkorrigering. Högst 90% av bandbredden kan allokeras för Interupt- och 

Isochronous Transfers. 

När ett device eller en function (USB-termer för nod) ansluts till nätet upprättas en pipe, en virtuell 

ledning mellan host och device. En device kan kopplas in när som helst, även då andra sändningar 

pågår på bussen. Det finns två sorters pipes: 

- Streampipe, ett flöde av paket, på vilka det inte ställs några krav att följa några USBstrukturregler, 

till en eller flera mottagare som inte kommer att synkroniseras. Streampipe 

används av Bulk-, Interupt- och Isochronous Transfers. 

- Message pipe, är mer uppstyrd till sin natur och kommunicerar på följande sätt: Applikationens 

mjukvara, på mastersidan, skickar ett IRP (I/O Request Packet). Detta följs av dataöverföring i 

önskad riktning, för att slutligen avslutas med ett statusmeddelande. Message pipen används för 

Control transfers. 

Bussens tid delas sedan upp i 1ms långa timeframes (125 µs i USB High Speed). I varje timeframe 

kan flera olika transfers sändas. 10% (20 % i USB High Speed) av bandbredden i varje timeframe 

reserveras för Control transfers, denna andel minskas dock om behovet minskas och ökas om 

utrymmet på bussen tillåter detta. Maximalt antal controlltransfers, innehållande 8 bytes, som kan 

sändas inom en timeframe är 28 (32 st 64 bytes för USB High Speed). USB-protokollet är inte 

deterministiskt i det avseendet att antalet transfers av olika slag alltid kan förutsägas 

5.2.2 Elektriskt gränssnitt 

USB använder differentierade skärmade tvinnade kablar terminerade av ett 45Ω motstånd. 

Fördröjningen i kabeln får ej uppgå till mer än 26 ns och den differentierade spänningen över 

termineringsmotståndet skall vara +/- 400 mV. 

5.3 Spacewire 

Spacewire är en blivande standard som tas fram av ECSS (European Cooperation for Space 

Standardization) [5] som i sin tur opererar under ESA (European Space Agency). Standarden är så 

gott som helt fastställd, utkast 3 håller i skrivande stund på att korrekturläsas. Standarden 

implementerar skikt 1-2 i OSI-modellen. Redan idag finns rymdkvalificerade noder, "SMCS332" eller 

"SMCS lite", implementerade i kameror, massminnen och DSP-kort. Vissa av dessa är operativa i 

missioner idag. Även rymdkvalificerade routrar, liksom tranceiver-receiver-par med kabel finns att 

köpa idag. 

Spacewire är en full-duplex, seriell, punkt-till-punkt datalänk. Om routrar används bildar Spacewire 

ett nätverk. Spacewire erbjuder dataöverföringshastigheter mellan 2-400 Mbps.



Figur 5.4 Nätverkstopologin hos Spacewire 

Spacewire erbjuder synkronisering av noderna med en noggrannhet av ca 10 µs vid 100 Mbps. Dock 

stöder standarden i sig ingen tidsschedulering. Spacewire skulle kunna ersätta payloadbussen, om 

tidsschedulering läggs till kan ett spacewirenätverk ersätta såväl system- som payloadbuss. 


Definierat i protokollet finns två teckentyper: 

- Datatecken, består av totalt tio bitar, varav en paritetsbit, en data-kontroll-flagg och åtta 

databitar. Paritetsbiten ser till att antalet ettor alltid är udda och data-kontroll-flaggen indikerar 

huruvida tecknet är ett datatecken eller ett Kontrolltecken. 

- Kontrolltecken, består av fyra bitar. En paritetsbit, en data-kontroll-flaggsbit och två 

värdetecken. De fyra kombinationerna blir då: FCT (Flow Control Token), EOP (normal End Of 

Packet), EEP (Error End of Packet) samt ESC (Escape). Escape kan sedan byggas på i syfte att 

skapa tecknet NULL (totalt 8 bitar) som används för handskakning eller Time-Code-tecken 

(totalt 14 bitar) som används för synkronisering av noderna i nätet. 

Spacewire använder paketstrukturer som består av tre delar: 

= där adressen kan delas upp i följande: 

= … 

Paketet innehåller ingen CRC. Vilket innebär att dubbla bitfel i ett datatecken eller kontrolltecken inte 

nödvändigtvis upptäcks. Paketen kan enligt tillverkaren ganska enkelt göras om till TCP/IP. 

Spacewire-nätverket byggs upp av minst två noder, noll eller flera routrar samt länkar mellan dessa. 

Ett nätverk utan router använder inte adressdelen i meddelandepaketet, då det endast existerar en 

mottagare. Adresseringen i ett routat nätverk är dock tämligen enkel till sin natur; deladresserna består 

helt enkelt av ett heltal som talar om genom vilken utgång respektive router skall skicka vidare 

meddelandet. 

Då ett paket skall sändas genomförs en handskakning mellan noderna, följt av sändning av paketet, 

efter paketslut skickas ett statusmeddelande tillbaka. För att mottagarnoden inte skall drabbas av 

överfull minnesbuffert meddelar mottagaren sändaren då denne är redo att ta emot ytterligare åtta 

byte. Skulle förbindelsen brytas eller störas under en sändning upptäcks detta varvid meddelandet 

termineras och en ny handskakning, anpassad för återupprättande av förbindelse, inleds och 

meddelandet sänds om. 

På ett tämligen enkelt sätt skapas redundans genom att lägga upp parallella routrar, som möjliggör 

flera vägar för meddelandet. Meddelandet kan då skickas genom en eller flera ledningar samtidigt för 

att sedan jämföras, mjukvarumässigt, när det kommer fram.



Tidssynkronisering stöds av protokollet. Vid varje "tidstick" sänds en 6-bitars tidskod ut, denna kod 

kan ses som systemtidens lägst signifikanta bitar. Vid varje tick räknas värdet upp med ett (modulo 

64). Tidsmeddelandet har förtur gentemot andra meddelanden i nätet, dock måste tidsmeddelandet 

vänta på att ett eventuellt tecken som håller på att sändas skall sändas klart, samt självt sändas klart. 

Detta upprepas sedan genom varje routerlager. Tillverkaren anser inte att en användare skall räkna 

med att få en större noggrannhet än 10 µs. 

Tidsschedulering stöds ej av Spacewire-protokollet. 


Det elektriska gränssnittet utgörs av Low Voltage Differential Signalling (LVDS ANSI/TIA/EIA- 

644). Kabeln har fyra tvinnade par, totalt 8 trådar. Detta för att full duplex skall uppnås. LVDS 

använder spänningsnivåer på 350 mV, vilket erbjuder en hastighet upp till 400 Mbps i upp till 10 m 

långa kablar. Varje tranceiver-receiver-par förbrukar 50mW. LVDS är ESA-godkänd beträffande 

EMC,ESD,EMI. 

Även RS-422 eller RS-485 kan användas, men erbjuder då endast 10 Mbps. 

5.4 TTP/C 

TTP/C står för Time Triggered Protokoll och tros [20] bli/vara en av kombattanterna som konkurrerar 

om att bli nästa de facto standard inom området "mycket säkra inbäddade nätverk". Denna typ av 

nätverk planeras att inom bl.a. bil och flygindustrin användas som s.k. Steer-By-Wire protokoll. 

TTP/C är operativt sedan 1998 och har nyligen kommit ut i en andra version. TTP/C [7] stödjer 

sändning med bithastigheterna 5 respektive 25 Mbps och reglerar skikt 2 i OSI-modellen. Nätverket 

stöds av ett flertal stora företag såsom: Airbus, Wolksvagen, Audi med flera. TTP/C är ett tänkbart 

alternativ som systembuss men skulle även kunna användas som payloadbuss. 


TTP/C implementerar OSI modellens skikt 2-3. Detta sker medelst sammankopplade noder i ett 

broadcastat redundant nätverk. Nätverket är redundant såtillvida att varje nod sänder, respektive tar 

emot över två, av varandra oberoende, parallella fysiska nätverk, den emottagna informationen 

jämförs sedan i syfte att upptäcka eventuella fel. Olika information kan också sändas i syfte att öka 

bandbredden, denna information blir dock inte redundant. En annan mycket viktig aspekt inom 

säkerhetstänkandet är vad som händer då en komponent slås ut av olika skäl. I TTP/C garanteras 

nätverkets fortlevnad, oavsett vilket enskilt hårdvarufel som inträffar. Detta löses bl.a. genom dubbla 

sändningskanaler, multipla klockor, membership service, skuggnoder som kan ta över om en viktig 

nod faller ifrån. TTP/C-noderna kan kopplas ihop till en buss eller med hjälp av en stjärnkopplare 

kopplas ihop till stjärnnät eller kombinationer av dessa.



Figur 5.5 Möjliga topologier hos TTP/C 

Ett tidsschema, vid namn TDMA (Time-Division Multiple Acces), reglerar vilken nod som sänder 

när, vilket innebär att inga krockar sker på nätet utan detsamma kan användas effektivt. Detta 

kontrolleras även av en busguardian som har möjlighet att tysta ned en nod som försöker sända då den 

inte skall göra det. En annan följd av tidsschemat är att användaren redan i förväg känner till, och kan 

bestämma, när meddelandet sänds, hur lång tid det kommer att ta och med vilken fördröjning det 

kommer att ske. Detta är givetvis en stor fördel vid reglersystemdesign. Minst fyra av varandra 

oberoende klockor finns utspridda bland noderna och definierar tillsammans nätverkets tid, som 

synkroniseras mellan noderna i storleksordningen 1 µs. 

Membership service är en funktion där varje nod en gång under varje TDMA-runda, 

storleksordningen 1-10ms, med hjälp av en Membership vector informeras om alla andra noders 

status. Med hjälp av detta kan därför åtgärder, t.ex. att systemet går in i felsäkert läge eller att en 

skuggnod tar över den trasiges plats, vidtas inom högst 2-3 TDMA-rundor från det att en nod fallit 

ifrån. 

Sänd- och mottagningsfel upptäcks inom en TDMA-runda av alla noder eftersom den sändande noden 

inte kommer att ingå i membership vektorn. Applikationen kan då omedelbart avgöra vilken åtgärd 

som vidtas. All applikationsdata och alla kontrolldata sänds i paketform. Applikationspaketen kan 

innehålla 0-239 bytes data och kontrollpaketens storlek varierar med uppgiften. 


Det elektriska gränssnittet regleras inte av TTP/C [7] standarden men för asynkron sändning 

rekommenderas ISO-11898 (samma som CAN-standarden förordar) för hastigheter 1-2 Mbps och RS- 

485 för hastigheter upp till 5Mbps. 

TTP/C stöder även synkron sändning över 100 Mbit/s Ethernet (IEEE 802.3) medium. 

Maxhastigheten är då 25 Mbps. 

5.5 TTCAN 

TTCAN [9] är en utveckling av CAN 2.0, där ett logiskt lager lagts ovanför den fortfarande orörda 

CAN-standarden. Tilläggen syftar till att göra CAN mer deterministiskt genom att tidsschemastyra 

alla sändningar samt synkronisera noderna. TTCAN får trots sitt tidsschema betraktas som tämligen 

flexibelt då tidsluckor kan läggas in där alla CAN-noder kan arbitrera på samma sätt som i CAN 2.0. 

TTCAN är i skrivande stund i princip färdigutvecklat och provkretsar finns att tillgå. Spridningen är 

ännu inte särskilt stor men mycket av den testutrustning som finns för CAN 2.0 fungerar även för



TTCAN. TTCAN´s svaghet ligger i dess något låga bandbredd (1 Mbps) samt dess bristande förmåga 

att identifiera och tysta ned en babbling idiot. TTCAN kan tänkas användas där CAN används idag, 

d.v.s. som systembuss och ev. som payloadbuss. 


Utöver att erbjuda allting (med vissa undantag, som omsändning av felaktiga meddelanden) som CAN 

2.0 erbjuder, delar TTCAN [8] in tiden i cykler, som kallas basic cycle. I varje cykel finns av 

användaren fördefinierade separerade tidsfönster. Verksamheten inom varje tidsfönster är reglerad av 

användaren under utvecklingen av nätverket. Möjliga verksamheter inom ett tidsfönster är exklusiv 

sändning från en viss nod, arbitrering mellan alla noder, eller ett tomt fönster där ingen nod är tillåten 

att sända. Syftet med tomma fönster är att kunna reservera bandbredd till kommande applikationer. 

Flera ”basic cycles” av samma längd, men innehållande olika långa- med olika typer av tidsfönster, 

kan läggas efter varandra. Dessa bildar då en systemmatris. 

Alla noder inom nätverket är programmerade med systemmatrisen, vilket innebär att de vet när de 

skall sända respektive kan tänkas få ett meddelande. 

För att tidsscheduleringen skall fungera korrekt måste noderna synkroniseras noggrant. 

Synkroniseringen sker kring en tidsmasternod som backas upp av en eller flera redundanta noder som 

omedelbart tar över om mastern faller ifrån. Början av varje basic cycle definieras av att tidsmastern 

skickar ett tidsreferensmeddelande. 

Figur 5.6 Synkronisering av nod 

Varje nod är försedd med en klocka som anger lokal tid (local Time). Vid varje mottaget eller sänt 

meddelandes synkroniseringsbit sparas automatiskt värdet på den lokala tiden undan i ett register som 

heter Sync_Mark (se fig 5.6 ovan). Om meddelandet visar sig vara ett giltigt tidsreferensmeddelande 

sparas värdet i Sync_Mark undan till ett register vid namn Ref_Mark. En variabel vid namn Cycle 

Time (Cycle Time=Local Time-Ref_Mark) visar sedan hur lång tid som, vid ett givet tillfälle, förflutit 

i den aktuella cykeln. Noden jämför sedan värdet i Cycle Time mot systemmatrisen i syfte att se vad 

den förväntas vidta för åtgärder. 

TTCAN kan också distribuera en global tid. Mastern skickar då ett meddelande vid namn 

Master_Ref_Mark, som är en kopia av tidsmasterns lokala tid då Ref_Mark skickades. I den enskilda 

noden jämförs sedan (se fig 5.7 nedan) nodens egna Ref_Mark med Master_Ref_Mark varefter felet 

(Local_Offset) läggs till/dras ifrån den lokala tiden, vilken sedan kommer att visa samma tid som 

tidsmastern.



Figur 5.7 Synkronisering av global tid 

Dessvärre gäller detta endast för synkroniseringsögonblicket. Då klockor i allmänhet alltid går olika 

fort, kommer synkroniseringen att bli felaktig med en okänd tidsdifferans intill nästa 

Tidsreferensmeddelande. Detta löser dock TTCAN medelst en driftkompensation. 

Kompensationskoefficienten (Time Unit Ratio) skapas (se fig 5.8) genom att differensen mellan den 

aktuella och den tidigare Master_Ref_Mark divideras med differensen mellan den aktuella och den 

tidigare Ref_Mark. Genom att ta den lokala klockans hastighet multiplicerat med 

kompensationskoefficienten erhålles en klockhastighet som väl överensstämmer med tidsmasterns. 

Figur 5.8 Klockdriftskompensation i TTCAN 

Om kompensationskoefficienten varierar kraftigt är detta ett tecken på att den lokala klockan är 

mycket ostadig, varför controllern flaggar upp detta för datorn som styr densamme. För att tidschemat 

skall hålla tillåts ingen omsändning av skadade eller felaktiga meddelanden, denna funktion är därför 

avstängd i TTCAN. Dock flaggas även detta fel upp för datorn som själv får vidta åtgärder.




TTCAN använder samma elektriska gränssnitt som CAN 2.0 d.v.s. ISO 11898 eller RS 485. 

5.6 FlexRay 

Även FlexRay gör anspråk på att bli den nya de facto standarden inom området "mycket säkra 

nätverk" [20]. Många nätverksprotokoll, t.ex. TTP/C, tar hjälp av determinism, som ett sätt att 

undvika krockar och detektera felaktigheter, i syfte att nå upp till önskad säkerhetsnivå. Även FlexRay 

[10], som ännu inte är färdigutvecklat, avser göra detta till viss del men har även ambitionen att 

tillföra en rejäl dos flexibilitet. En flexibilitet som är hett efterlängtad av vissa användare, medan 

andra hävdar att säkerhet och flexibilitet inte kan kombineras och att säkerheten alltid måste sättas 

först. Skulle FlexRay lyckas, vilket på intet sätt får anses orealistiskt, nå upp till nödvändig säkerhet 

utan att för den skull bli för krånglig, kan flexibiliteten bli den avgörande faktorn som gör att FlexRay 

tar hem vinsten i striden om en framtida de facto standard, åtminstone i bilindustrin. 

Konsortiet FlexRay har många stora medlemmar t.ex. BMW, DaimlerChrysler, BOSCH och General 

Motors för att nämna några. 

Tillverkarna räknar med att nätverket skall finnas tillgängligt på marknaden i slutet av 2004 och att 

den första serietillverkade bilen som innehåller FlexRay skall säljas 2006. 

FlexRay skulle i en framtid mycket väl kunna agera som en sammanslagen payload- och systembuss i 

nästa generation av satelliter. Ett problem vid utvärdering av FlexRay är att tillverkarna är tämligen 

tystlåtna och inte gärna delar med sig av algoritmer och metoder som används i protokollet. 

- Lager i OSI-modellen: FlexRay definierar lager 1-3 i OSI-modellen 

-Topologi: Tre topologier stöds, nämligen passiv buss, passivt stjärnnät samt aktivt stjärnnät med eller 

utan passiv buss. FlexRay stödjer dessutom samtidig sändning över en parallell redundant buss eller 

ett stjärnnät. Nätverket kan konfigureras för att innehålla endast statiska meddelanden, endast 

dynamiska meddelanden eller en godtycklig blandning av de båda typerna. 

-Paketutseende: Det finns två pakettyper, dels FlexRay Frame Format som används för såväl statiska 

som dynamiska meddelanden och dels Byteflight Frame Format som endast används för dynamiska 

meddelanden och då krävs dessutom att nätverket är konfigurerat för endast dynamiska meddelanden. 

FlexRay-paketet (se fig 5.9) innehåller en header om 5 bytes, som beskriver bl.a. identiteten och 

storleken på paketet. Identiteten beskiver även paketets prioritet då det sänds. Därefter följer 0-246 

bytes data som är skyddat av 24 bitars CRC. Det är även möjligt att använda de två första byten i 

datafältet som ytterligare ett ID-fält men i det här fallet mer av formen meddelande-ID. 

Figur 5.9 FlexRays meddelandepaket 

Byteflight-paketet (se fig 5.10), som finns med för att skapa bakåtkompabilitet med just det BMWägda 

nätverket Byteflight, är något enklare till sitt utförande och innehåller i princip bara ett 8-bitars 

ID-fält, ett 0-12 bytes datafält samt en 15-bitars CRC. 

Figur 5.10 Byteflight´s meddelandepaket



-Klocksynkronisering och schedulering av meddelanden: Metoderna för synkroniseringen går 

tillverkarna inte särskilt djupt in på, i den senaste specifikationen. Dock dikteras ett antal krav, 

däribland att synkroniseringen av den globala tiden mellan noderna skall vara minst 1µs. Vidare skall 

nätverket vara feltolerant såtillvida att den/de noder som distribuerar tiden skall kunna haverera utan 

att nätverkets trafik eller synkronisering gör det. Synkroniseringsmeddelandet är ett vanligt FlexRaypaket 

där SYNC-biten sätts till 1. Synkroniseringen i den dynamiska delen skall följa rutinerna för 

Byteflight. Så mycket mer är svårt att få fram, om såväl FlexRay´s som Byteflight´s dynamiska delar, 

i nuläget. 

-Arbitrering: Den statiska delen använder en TDMA för att avgöra vilken nod som skall sända när, 

noderna kontrolleras av en bus-guardian. Den dynamiska delen är ännu något höljd i dunkel, men 

skall garantera en högsta fördröjning för vissa meddelanden och även använda sig av en 

prioriteringsordning mellan meddelandetyperna. 

-Feldetektering och felhantering: FlexRay-paketet har ett tämligen kraftfullt CRC-skydd, bestående 

av 9+24 bitar. Andra typer av feldetekteringar som planeras är på media-, bit-, topology-, 

synkroniserings- och tidsnivå. Vidare skall en FlexRaycontroller genast meddela mikrocontrollern 

som styr noden om ett meddelande inte sänts, eller mottagits korrekt. 

-Elektriskt gränssnitt: Det fysiska gränssnittet är inte helt definierat ännu, men skall stödja såväl 

elektriskt som optiskt media. Vidare får nätverkscontroller, med tillbehör, inte dra mer ström än 60mA 

vid kontinuerlig användning. 

5.7 MOST 

MOST (Media Oriented Systems Transport) [12] är ett nätverk främst framtaget för överföring av 

digitala media såsom audio och video. Samtidigt skall nätverket även transportera 

kontrollmeddelanden mellan dessa digitala enheter som kan bestå av datorer, video, DVD, CD, 

mobiltelefoner och displayer i ett fordon eller hem. MOST kan maximalt överföra 24.8 Mbps 

(tillräckligt för 15 st stereoöverföringar av CD-kvalitet), varav 700 kbps är dedikerat till 

kontrollmeddelanden. MOST är framtaget för att använda optisk fiber som medium men koaxialkabel 

eller twisted pair går också att använda. MOST får i första hand betraktas som ett alternativ till 

payloadbuss men kan tänkas ersätta även dagens systembuss tack vare förmågan att överföra 

kontrollmeddelanden. Mer information om MOST finns på deras hemsida: http://www.mostnet.de/ 

eller http://www.mostcooperation.com 


MOST implementerar alla lager i OSI-modellen men en applikationsutvecklare kan själv välja på 

vilken nivå gränssnittet mot den egna applikationen skall ligga. Endast nivå 1-3 kommer att beskrivas 

här. 

Nätverket styrs av en master som delar upp tiden i block. Blocken håller en frekvens motsvarande 

samplingshastigheten på en audio-CD, nämligen 44.1 kHz (kan dock ställas in mellan 30-50 kHz). 

Dessa block delas sedan upp i 16 MOST-paket (frames) om vardera 64 bytes. Detta paket är i sig 

uppdelat i en administrativ del om 2 bytes, en datadel om 60 bytes samt en kontrolldel om 2 bytes. 

Datadelen består dels av synkron data och dels av asynkron data, proportionerna dessemellan (kan) 

ändras efter hand. MOST-paketet i sig skyddas endast av en paritetsbit. 

De administrativa byten används för synkronisering av noder, bestämning av proportionerna mellan 

asynkron- och synkron data samt distribution av TDM; tidsschemat som bestämmer när respektive 

nod skall sända. 

De två kontrollbyten från varje MOST-paket bildar, tillsammans inom ett block, ett 16*2 bytes stort 

kontrollpaket. Kontrollpaketet innehåller bl.a. arbitrering, avsändar- samt mottagaradress, CRC samt 

17 bytes data. Vid sänd eller mottagarfel meddelas applikationen. 

Den synkrona delen är till för att i en jämn ström skicka över data från t.ex. en CD-spelare till en 

högtalare eller en förstärkare och är inte skyddat på något sätt, är ett paket skadat accepteras det felet 

och lyssnaren märker antagligen inget ändå. Det skickas typiskt 44 100 samples per sekund och nod 

eller färre. 

De asynkrona delarna bildar paket på ett sätt som liknar kontrollpaketens, datamängden varierar dock 

mellan 24 och 1014 bytes. De asynkrona paketen har samma CRC-skydd och adressering som 

kontrollpaketen. De asynkrona paketen är tänkta att snabbt kunna transportera datamängder som inte 

sänds kontinuerligt t.ex. datafiler eller bilder från en kamera eller motsvarande. Den faktiska databandbredden 

för asynkron sändning ligger, beroende på inställningar och data paketstorlek, mellan 1- 

11,8 Mbps.



Då dessa paket sätts samman av hårdvaran i MOST-controllern är det svårt om inte omöjligt att 

förutse exakt när ett meddelande sänds och i vilka MOST-paket det kommer att delas upp i. Vid hög 

nätbelastning är det dessutom svårt att garantera sändning av prioriterade meddelanden inom en viss 

tidsram. 

Figur 5.11 Diverse noder i MOST-ring 

Nätverket kopplas i en ring, eller två ringar om redundans önskas, där alla medlemmar känner till sin 

egen fördröjning i förhållande till mastern. På så sätt kan noderna synkroniseras. Om en nod havererar 

går oftast tranceivern in i bypassmode vilket innebär att informationen bara passerar den trasiga 

noden. Skulle den dock misslyckas med detta kommer informationen att stanna vid den trasiga noden 

och nätverket är trasigt. Dock kan en controller som tidigare varit slav gå in som master på den 

eventuella del som saknar master då nätet gått sönder, varvid nätet eller de olika nätdelarna kan 

fortsätta leva. 


MOST är ursprungligen designat för att använda POF (Plastic Optical Fiber) [11] med rött laserljus, 

men även koaxialkabel eller twisted pair kan användas.


Martin Normark



6 Val av nätverk 

Med hjälp av en grafisk bedömningsmall (Appendix E), konsultation av Håkan Sivencrona [20]på 

Sveriges Provnings- och Forskningsinstitut och dialog med Gunnar Andersson [18] på Rymdbolaget 

väljs här ett nätverk ut för vidare tester. 

6.1 Bedömningsmall 

I syfte att skapa en överblick skapas en grafisk bedömningsmall där de viktigaste 

kraven/egenskaperna hos nätverken sammanställs (se Appendix E). I fälten för egenskaperna har 

tillgänglig information lagts in. Dock är vissa fält tomma, detta beror på att informationen med en 

rimlig arbetsinsats inte gått att finna. Vissa fält är färgkodade, detta för att enkelt påvisa huruvida 

egenskaperna klarar av de krav som ställs på nätverket. Ett grönt fällt skall tolkas som att nätverket 

klart klarar det aktuella kravet och ett rött som att nätverket alls icke klarar tidigare ställda krav. Ett 

gult fält innebär att kravet i fråga inte uppfylls men att det går att gå runt problemet eller genom 

tillägg lösa detsamma. 

6.2 Gallring av nätverk 

Följande nätverk kommer av nedanstående skäl inte i fråga som controllnätverk i kommande svenska 

satelliter: 

MOST: Av bedömningsmallen syns tydligt att MOST inte är lämpligt för Rymdbolagets ändamål, 

vilket inte är så konstigt då det ursprungligen är tänkt att operera som transportör av media och inte 

som kontrollnätverk i känsliga och dyrbara system. 

USB lämpar sig heller inte särskilt bra för ett nätverk till ett distribuerat styrsystem, då det är toppstyrt 

snarare än distribuerat. Dessutom är det svårt att avlyssna all trafik på ett enkelt sätt för en utvecklare. 

Programvara och drivrutiner bedöms ta stor plats i varje nod och i huvuddatorn. Dock tycks USB vara 

ett bra alternativ till Payloadbussen i de fall mycket data skall flyttas från ett ställe till ett annat. 

Särskilt som det har en mycket stor spridning och många tillämpningar kommersiellt. 

Spacewire: Är fortfarande endast i sin linda med begränsad uppbackning från stora kommersiella 

användare/utvecklare. Spacewire definierar endast en tämligen låg nivå av kommunikationen, vilket 

innebär att en stor del av utvecklingen kvarstår för användaren. Spacewire är i grunden till för 

kommunikation mellan endast två punkter och där kan det i framtiden lämpa sig mycket väl för 

Rymdbolaget då kretsarna redan finns för rymdbruk och även är integrerade i vissa komponenter 

såsom kameror, minnen och datorer för rymdbruk. 

TTCAN: Är mycket flexibelt och tycks minst lika säkert som CAN. TTCAN erbjuder en god 

tidssynkronisering men ärver de svagheter, såsom låg bandbredd och dålig övervakning av babbling 

idiots, som CAN redan från början har. Det har i skrivande stund ej heller synts några tecken på något 

kommersiellt genomslag något som Rymdbolaget anser vara viktigt. 

Kvar som förslag till framtida nätverk är därför FlexRay, TTP/C och ett egenhändigt förbättrat CAN. 

6.3 Slutligt nätverksförslag för STEAM 

För att få en uppfattning om säkerhetsnivåerna hos FlexRay, TTP/C och CAN kontaktas Håkan 

Sivencrona på SP, Sveriges Provnings- och Forskningsinstitut. Håkan har genomfört omfattande tester 

på TTP/C, medelst felinjektioner i syfte att testa tillförlitligheten. Håkan har också en god uppfattning 

om FlexRay´s kommande kapacitet. Han menar att TTP/C, idag, är ett mycket tillförlitligt 

kontrollnätverk, det säkraste på marknaden. Han menar också att FlexRay´s tillförlitlighett kommer att 

komma upp i motsvarande nivå den dag det lanseras. Detta kommer enligt Håkan ske tidigast 2004. 

Enligt Håkan kommer såväl TTP/C som FlexRay, med stor sannolikhet, kunna godkännas för 

högkritiska tillämpningar såsom steer-by-wire applikationer i bilar och flygplan, vilket varken CAN 

eller TTCAN kommer godkännas för. Det enda befintliga nätverk som uppfyller den säkerhet som 

efterfrågas är alltså TTP/C. Då FlexRay inte är operativt kan detta dessvärre inte användas. 

TTP/C är dock behäftat med en svaghet; TDMA, d.v.s. schemat som styr vilken nod som sänder när, 

till stor del helt saknar flexibilitet. Detta innebär att en nod som önskar sända mer än normalt



förhindras göra detta. Detta medför att satelliten hindras arbeta inom olika arbetsmoder, då detta 

sannolikt innebär olika användningsmönster för noderna på bussen. Efter en dialog med Gunnar 

Andersson på Rymdbolaget konstateras att försök har gjorts tidigare med liknande TDMA. Resultatet 

av dessa tester var att dylikt schema ej skall användas på svenska satelliter på grund av dess dåliga 

flexibilitet. Gunnar Andersson föreslår därför att nuvarande CAN-buss vidareutvecklas och förses 

med tillägg för att synkronisera noderna samt med ett köhanteringssystem vars namn är EDF, Earliest 

Deadline First, vilket skall tjäna till att öka användningsgraden på bussen samt se till att det för 

stunden viktigaste meddelandet får sända först. 

Det slutliga Nätverksförslaget för STEAM blir därför ett CAN-nätverk med tillägg av EDF och 

tidssynkronisering. CAN-bussen 

6.4 Slutligt generellt nätverksförslag för kommande satelliter 

För kommande satelliter rekommenderas dock FlexRay, då detta nätverk väntas bli mycket spritt [20] 

och dessutom uppfylla Rymdbolagets krav.



7 Testimplementation av CAN som använder Earliest 

Deadline First 

I SMART-1 används ett pollat CAN-nätverk [2]. I STEAM kan dock ett Earliest Deadline First (EDF) 

baserat sändschema komma att testas. I detta kapitel beskrivs teorin bakom EDF. Dessutom undersöks 

huruvida detta är möjligt att använda i ett CAN-nätverk. 

Testerna inleds med en datasimulering där ett tiotal noder simuleras i syfte att kontrollera att alla 

noder ständigt får sända inom sin garanterade sändtid och att överbliven bandbredd kan utnyttjas av 

noder som önskar sända mer än garanterad bandbredd. 

Därefter skall ett riktigt CAN-nät testas i syfte att visa att teorin fungerar även i praktiken. Till det 

kommer SMART-1´s CAN-nät att förses med tillägg i de CAN-controllers som ingår i nätet. Genom 

att göra förändringen i CAN-controllern är inga förändringar i övriga datorer i satelliten nödvändiga. 

Controllern består idag av en FPGA, ACTEL A54SX32PQ208, i vilken VHDL-kod implementeras. 

Det är alltså denna VHDL-kod som skall förses med tillägg, för att sedan brännas ned i en ny FPGA 

av samma typ som den tidigare. Den nya FPGAń ersätter därefter den ordinarie controllern i de 

prototypdatorkort som finns kvar sedan SMART-1-utvecklingen. De slutliga hårdvarutesten 

genomförs sedermera på ett av dessa protypdatakort, närmare bestämt GRWRTU-kortet (Gyro and 

Reaction Wheel Real Time Unit), försett med den nya EDF-CAN-controllern.. 

7.1 Kort beskrivning av EDF 

Earliest Deadline First eller EDF är, precis som det låter, en tämligen enkel teori som bygger på att 

ingen process skall bli försenad genom att helt enkelt exekvera den process som har mest bråttom 

först. EDF kan tillämpas i en mängd sammanhang men här kommer främst kommunikation på en 

broadcastad kommunikationsbuss med arbitrering, i det här fallet CAN, att behandlas. 

För enkelhetens skull antas i det här exemplet att alla meddelanden har samma längd. Alla noder eller 

meddelandetyper erhåller en på förhand bestämd, individuellt garanterad bandbredd, exempelvis kan 

nod A garanteras en bandbredd UA=1/6 av bussens totala kapacitet, nod B kan garanteras UB=1/8 

o.s.v. Detta innebär att en given nod, t.ex. Nod A, i genomsnitt och om behov finnes, får sända minst 

var sjätte meddelande på bussen. Den längsta accesstiden för noden kan också garanteras men kan 

givetvis inte bli kortare än tiden mellan två garanterade meddelanden, i det här fallet alltså tiden det 

tar att sända 6 meddelanden på bussen. Detta gäller endast för en nod, alla de övriga erhåller en längre 

garanterad accesstid, mer om accesstider för EDF i kap 7.2. 

Ju närmare tidpunkten för nodens deadline ju högre prioritet erhåller noden ifråga. Omedelbart före 

deadline, erhåller därför noden den högsta just då, på bussen, förekommande prioriteten och får sända. 

Teorin om Earliest Deadline First presenterades första gången 1973 i artikeln ”Scheduling Algorithms 

for Multiprogramming in a Hard-Real-Time Environment” av C. L. LIU, MIT Massachusetts Institute 

of Technology, och James W. Layland, California Institute of Technology [14]. Enligt artikeln ställs 

ett antal krav på systemet, nämligen att den högsta prioriteten delas ut till den nod som har närmast till 

deadline, att meddelandena är oberoende av varandra, att de sänds periodiskt samt att den totalt 

garanterade bandbredden Utot inte överstiger bussens maximala bandbredd, det vill säga: 

U tot = ∑U 

i ≤ 1 (1) 

i= 

A, 

B, 

C... 

Att vid varje tillfälle jämföra alla noders kvarvarande tid till deadline kräver antingen en central 

övervakning eller en hög upplösning i prioritetsangivningen. Det finns dessvärre varken utrymme för 

någon av dessa funktioner ombord på den satellit som skissas, det enda tillgängliga medel för att ändra 

prioriteten på meddelandena är en enda prioritetsbit i CAN-meddelandets ID-fält (se även kap. 7.2). 

Därmed uppfylls inte det första kravet för att EDF skall fungera. Det finns dock en metod som heter 

”Dual Priority Assignment” [15] som beskrivs i en artikel med samma namn, skriven av Alan Burns, 

University of York. Grundförutsättningarna för Dual Priority Assignment är desamma som för EDF, 

dock räcker det, enligt Burns, att n-1 noder i ett system innehållandes n noder kan växla mellan en 

standardprioritet och en högre prioritet, för att alla noder skall få sända i tid. Den n:te noden behöver 

endast en prioritet. Vidare finns det för varje system där (1) uppfylles minst en konfiguration, av 

kombinationer mellan grundprioriteter, högre prioriteter och när noden skall växla mellan dessa, där 

alla noderna får sända i tid. Vid höga garanterade laster, där U är nära ett, kan det dock vara svårt att 

finna denna kombination. Den rätta kombinationen kan dock bli betydligt enklare att finna om en 

periodicitet används där alla meddelanden kan sändas inom en periodtid, vars längd är en multipel av



den minsta gemensamma nämnaren hos alla Ui. Om en nod avstår från att sända innebär detta i sig 

inget problem, det är däremot inte säkert att noden senare kan ta igen de missade sändtillfällena. 

Detta kan låta avskräckande men fördelarna med EDF är stora. Dels kan en större del av bandbredden 

scheduleras, med statisk prioritet går den högsta möjliga utnyttjandegraden mot U ≤ Ln2 ≈ 0,69 då 

många noder används [14] och dels kan eventuell överbliven bandbredd enkelt utnyttjas av övriga 

noder. 

7.2 Beskrivning av använd EDF-algoritm 

Alla noder erhåller en garanterad minsta tillgång Ui till den totala bussbandbredden enligt ovanstående 

resonemang. Därefter kontrolleras att den totalt garanterade bandbredden Utot inte överstiger 1. 

Som beskrivet i kapitel 5.1 om CAN-protokollet, använder sig CAN av ett 29 bitars ID-fält i början av 

varje meddelande. Dessa 29 bitar används dels för att identifiera meddelandetypen men även för att 

avgöra meddelandets prioritet. Vilken nod som får sända avgörs genom arbitrering där den nod med 

det lägsta binära värdet på de 29 ID-bitarna har högst prioritet och får sända först. D.v.s. ett 

meddelande med ID-fältet ”00101…” får sända före ett meddelande med ID-fältet ”01101…”. 

I Rymdbolagets satellit SMART-1 används ID-fältet enligt figur 7.1 nedan. 

Originator Destination Message type S P 

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 

Figur 7.1 ID-fältets utseende i SMART-1 

Som synes finns två bitar markerade med P respektive S. P står för ”paritetsbit” och skyddar resten av 

ID-fältet mot enkelbitsfel. S är en s.k. spare-bit, dvs den är reserverad för senare bruk. Denna spare-bit 

flyttas nu längst fram och används som en EDF-bit som går från 1 till 0 då den sändande noden 

kommer nära sin deadline. Nodens prioritet höjs alltså då den närmar sig deadline. Upplösningen blir 

dock inte så hög och det blir endast två prioritetsområden: hög och normal. Inom dessa gäller dock 

ordinarie prioritetsordning där den nod med högst tilldelad bandbredd också tilldelas högst prioritet. 

Det nya ID-fältet får således utseendet enligt figur 7.2 nedan: 

EDF Originator Destination Message type P 

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 

Figur 7.2 ID-fältets framtida utseende i STEAM 

-Metod för att avgöra huruvida deadline är nära: Noden/Meddelandetypen (varje nod kan ju sända 

flera meddelandetyper) förses med en räknare, vars initialvärde är lika med det inverterade värdet av 

Ui , i fallet nod A (där UA=1/6) i kap 7.1 blir initialvärdet alltså 6. Vid varje arbitrering, då noden 

försöker sända minskas värdet på räknaren med 1, varje gång arbitreringen lyckas ökas värdet på 

räknaren med initialvärdet. I samband med varje arbitrering jämförs värdet på räknaren med dess 

initialvärde; om värdet är mindre eller lika med initialvärdet sätts den första biten (EDF-Biten) i IDfältet 

till 0 (högprioområdet) annars till 1 (lågprio). Se även flödesschema, figur 7.3, nedan.



Figur 7.3 Flödesschema för räknare i EDF 

-Garanterad Accesstid: Högsta värdet på räknaren begränsas till 2*initialvärdet i syfte att hålla ned 

den garanterade accesstiden. Då noden är garanterad att få sända senast då räknaren nått noll, blir 

således den högsta accesstiden, generellt, just tiden det tar att sända 2*initialvärdet st meddelanden. 

För Nod A, som har högre prioritet än B, i exemplet alltså maximalt tiden det tar för tolv meddelanden 

att sändas. Detta gäller dock generellt, för noder med hög ordinarie prioritet minskar accesstiden ända 

ned till 1*initialvärdet för den högst prioriterade noden. Med hänsyn tagen till detta sänks den 

garanterade accesstiden för nod A (UA=1/6) till 6 meddelandetidsrymder och för nod B (UB=1/8) till 9 

meddelandetidsrymder. Att det för nod B blir 9 tidsrymder beror på att nod A kommer att tränga sig 

före Nod B , vid ett och endast ett sändtillfälle, om de båda noderna befinner sig i respektive 

högprioritetsområde. På samma sätt kommer den garanterade accesstiden att fortsätta öka för de lägre 

prioriterade noderna. Detta gäller dock endast för periodiskt återkommande meddelanden. För 

meddelanden som sänds spontant kan den minsta accesstiden bli mycket komplex och tämligen lång. 

Aperiodiska meddelanden påverkar även de periodiska meddelandena med lägre prioritet om sådana 

finnes. För värdena ovan förutsätts även att bussen är ledig, om så inte är fallet tvingas den nod som 

önskar sända vänta intill dess det meddelande som sänds har sänts klart. Detta oavsett vilken prioritet 

de olika meddelandena har. 

-Överbliven bandbredd: Det är ju inte nödvändigtvis så att all tillgänglig bandbredd på bussen 

allokeras till noderna, det kan ju också tänkas att vissa noder avstår från att sända sin garanterade 

andel. Båda dessa fall leder till överbliven bandbredd. Denna bandbredd kan givetvis nyttjas av de 

noder som så önskar, dock kommer den nod med högst ordinarie prioritet få exklusiv rätt att nyttja 

den överblivna bandbredden, därefter erbjuds den i fallande prioritetsordning till lägre prioriterade 

noder. Med en högre upplösning i prioritetsförändringarna kan överbliven bandbredd fördelas mer 

”rättvist” mellan alla noder, detta är dock inte möjligt med endast en bits upplösning, som i 

Rymdbolagets fall. 

7.3 Mål med test 

Om EDF-funktionaliteten kan implementeras i CAN-controllern slipper CPU:n i varje nod ägna sig åt 

att räkna ut när och hur noden i fråga får sända, utan kan ägna sig åt viktigare saker. Vidare skall 

EDF-CAN-controllern ha samma gränssnitt som den ordinarie CAN-controllern mot CPU:n i syfte att 

nätverket skall kunna uppgraderas utan att övriga systemet byggs om. 

Målet med testet är med andra ord att utröna huruvida det är möjligt att komplettera en CANcontroller 

med med en EDF-funktion. Vidare skall testet visa om EDF-algoritmen fungerar i 

praktiken, hur stor plats funktionaliteten tar på en FPGA samt visa om gränssnittet mellen FPGA och 

övrig hårdvara behöver förändras eller inte.



7.4 Simulering av CAN med EDF 

I syfte att visa att det är möjligt att det är möjligt att tillämpa EDF i ett CAN-nätverk skapas ett 

simuleringsprogram i C (se Appendix A). Programmet simulerar ett nätverk med 8 noder, nod A till 

nod H. Nod A har en garanterad bandbredd UA motsvarande 1/3 av total bandbredd, vilket med andra 

ord innebär att nod A får initialvärde 3 på sin räknare. För att förenkla hanteringen av grundprioriteten 

erhåller nod A grundprio=0 som är den högsta möjliga prioriteten, för de övriga noderna noderna 

stegas grundprioriteten upp med 1 för varje nod. Den garanterade bandbredden samt övrig data för 

samtliga noder är: 

UA=1/3. Grundprio=0. Initialvärde för räknare=3. 

UB=1/6. Grundprio=1. Initialvärde för räknare=6. 

UC=1/10. Grundprio=2. Initialvärde för räknare=10. 

UD=1/13. Grundprio=3. Initialvärde för räknare=13. 

UE=1/22. Grundprio=4. Initialvärde för räknare=22. 

UF=1/23. Grundprio=5. Initialvärde för räknare=23. 

UG=1/24. Grundprio=6. Initialvärde för räknare=24. 

UH=1/25. Grundprio=7. Initialvärde för räknare=25. 

Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

= 

0. 

848 

≤ 1 

Vilket uppfyller villkoret om maximalt garanterad bussbandbredd. 

Vid simuleringen testas tre varianter, den första där värdet på räknaren förhindras att anta värden 

högre än dubbla initialvärdet, en andra variant där värdet tillåts gå högre men där noden avstår från att 

sända då värdet på räknaren är dubbelt så högt som initialvärdet eller högre samt en tredje där 100 

procent av tillgänglig bussbandbredd garanteras. 

Syftet med de två första varianterna är dels att kontrollera om det ställer till problem då accesstiden 

begränsas (jfr kap 7.2) medelst en övre gräns för räknaren, respektive att studera hur tillgänglig 

bandbredd kan röra sig nedåt i hierarkin då de högst prioriterade noderna avstår från att sända. 

Simuleringen nedan visar på komplexiteten då U går mot 1. Där ändras värdena till: 









Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

= 

0. 

998 

Då prioriteterna tydligen inte är rätt ordnade noderna emellan blir resultatet av körningen ovan 

katastrofalt med totalt 897 missade deadlines efter 2000 sändomgångar. De missade sändningarna 

beror alltså på operiodicitet och ickeharmoniska perioder. 

≤ 1



Med relativt små ändringar kan dock en lyckad konfiguration finnas, test nr 2 av samma simulering 

har värdena: 









Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

Med denna fördelning syns tydligt att sändningarna kommer att delas in i perioder om 20 

meddelanden inom vilka alla meddelanden kommer att kunna sändas. Simuleringen ger också ett gott 

resultat med inga missade deadlines. Detta trots att bussen nyttjas i en högre grad. 

Simuleringskörningarna, som finns utskrivna i Appendix A, visar att ingen nod missar sin deadline 

vid någon av tidigare beskrivna körningar om prioriteterna ställs in rätt mellan noderna. Simuleringen 

visar även att 100% av bussens kapacitet kan allokeras till noderna då all garanterad bandbredd kan 

användas av de noder som blivit tilldelad denna, vidare kan all övrig tillgänglig bandbredd som 

uppstår av att en nod inte utnyttjar sin tilldelade bandbredd eller inte är allokerad till någon nod, 

användas. Dock kommer de högst grundprioriterade noderna att få tillgång till detta extra utrymme på 

bussen i första hand. 

7.5 Implementation i VHDL 

Som CAN-controller används på Rymdbolaget en FPGA (Field Programmable Gate Array) i vilken 

BOSCH´s CAN-kärna tillsammans med, för övrig hård- och mjukvara, lämpliga skal, logik och 

gränsnitt programmerats. Alla dessa komponenter programmeras i VHDL (Very high speed integrated 

circuit (VHSIC) Hardware Description Language ). Vid programmeringen av tilläggen i den nya EDF- 

CAN-controllern sker de flesta förändringarna i den modul som Rymdbolaget kallar CAN-Shell. 

CAN-Shellet ligger som ett skal kring CAN-Kärnan, se fig 7.4, och hanterar input och output av 

kommandon och data till kärnan. CAN-Shellet utgör därför en bra plats för implementering av EDFtilläggen. 

Då den garanterade bandbreddstilldelningen är individuell för varje CAN-controller samt att 

denna kan komma att behöva ändras måste dock samtliga lager utanför CAN-Shellet designas om 

något för att tillåta transport av denna information från de fysiska pinnarna på FPGAńs utsida in till 

CAN-Shellet. 

I denna rapport kommer av copyright-skäl endast de större förändringarna i CAN-Shellet att 

redovisas, det skall dock tilläggas att de redovisade förändringarna är de som i stora drag förändrar 

karaktäristika hos CAN-controllern. 

= 1



Figur 7.4 Delar av CAN-Shellet. 

Figur 7.5 Transmission_State_Machine ombyggd för EDF 

7.6 Simulering av funktion hos kod skriven i VHDL 

Rymdbolaget tog i samband med utvecklingen av SMART-1 fram en testbänk vars syfte var att testa 

funktionaliteten hos CAN-Shellet. Även testbänken är skriven i VHDL och körs tillsammans med 

koden för CAN-Shellet i simuleringsprogrammet Modelsim PE. Efter att testbänken modifierats för



att passa EDF-CAN-controldesignen kördes samtliga tester med lyckat resultat. Dessutom skapades 

nya tester (test 5.1 och test 6.1) vars syfte var att testa funktionen hos initialvärdet (här kallat ”PRIO”), 

räknaren (”counter”) och EDF-ID-biten (här kallat”ID_bit_28”). VHDL-koden för testerna 5.1 och 6.1 

finns återgivna i Appendix D. 

Test 6.1 

Nedan (fig 7.6 och 7.7) visas urklipp ur testet 6.1 där CAN-Shellets beteende vid övergång från 

nodens lågprio- till högrio-område testas: 

Figur 7.6 Simulering av CAN-Shell 

• Vid tiden 59300 ns laddas samtliga ID-, Kontroll- och databitar från CAN-Shellet till CAN- 

Kärnan i och med att signalen ”load_shift_reg_int” går hög. Observera att vid detta tillfälle är 

EDF-biten (”ID_bit_28”) hög vilket innebär att noden jobbar i sitt lågprio-område. Detta 

illustreras även med att ”send_identfiier” har värdet ”1000011…”. 

• En klockcykel senare vid tiden 59450 beordras CAN-Kärnan, medelst ”tx_request” =1, att 

försöka sända det nyss laddade meddelandet på CAN-bussen. 

• Vid tiden 60200 är bussen ledig och CAN-Kärnan går ut och arbitrerar på CAN-bussen. Detta 

indikeras med att insignalen ”transmitter” sätts hög av CAN-Kärnan. 

• ”transmitter” =1 triggar CAN-Shellet att byta state till ”cur_state” = ”0010” – 

”Sending_or_Receiving”. Detta leder till att räknaren, ”counter”, räknas ned ett steg till 

”0001100b”. Observera att räknarens värde numera överensstämmer med initialvärdets (”PRIO”) 

”01100b”



Figur 7.7 Simulering av CAN-Shell. Vid tiden 62050 går noden in i sitt 

högprio-område 

• Vid tiden 62050 ns går ”transmitter” låg vilket innebär att CAN-Kärnan förlorat arbitreringen. 

Vid samma tillfälle jämförs också värdet för ”counter” och ”PRIO”, då dessa numera har samma 

värde går ”ID_bit_28” låg. Därmed går noden in i sitt högprio-område enligt EDF-algoritmen 

(kap 7.2). 

• Vid tiden 62100 ändras därför ”send_identifier” till ”0000011…”. 

• Därefter påbörjas en ny sändcykel där samma meddelande sänds om. Numera dock med den 

högre prioriteten. 

Test 6.1 får därmed betraktas som lyckat. 

Test 5.1 

I test 5.1 testas CAN-Shellets beteende vid en vunnen arbitrering där meddelandet sänds iväg på 

bussen. Nedan (Fig 7.8) visas ett urklipp även ur detta test.



Figur 7.8 Vid tiden 11100 ns går noden in i sitt lågprio-område 

• Vid urklippets början (10250 ns) har CAN-kärnan redan beordrats att sända iväg ett meddelande 

(jfr Fig 7.8 ovan). Noden var då i sitt högprio-område och befinner sig i state ”0010” –” 

Sending_or_Receiving ” och väntar på besked från CAN-kärnan som skall tillkännage huruvida 

arbitreringen vunnits eller förlorats. 

• Vid tiden 10600 ns meddelar CAN-kärnan genom att sätta signalen ”tx-complete” hög att 

arbitreringen vunnits samt att meddelandet är sänt. 

• CAN-Shellet byter state till ”0100” –”Counter_addition” där räknarens (”counter”) värde räknas 

upp (jfr EDF-algoritm kap 7.2) med initialvärdets (”PRIO”). Räknarens nya värde blir därför 

0001010b + 01100b = 0010110b. 

• Vid tiden 11100 ns leder detta till att att ”ID_bit_28” går hög och noden går in i sitt lågprioområde. 

• Detta bekräftas vid tiden 11150 ns genom att ”send_identifier” ändras till ”0000011…”. 

• Därefter är CAN-Shellet redo att sända ett nytt meddelande. 

Även Test 5.1 får därmed betraktas som godkänt. 

7.7 Produktion av Testhårdvara implementerat i en FPGA 

Vid produktion av FPGA måste VHDL-koden koden syntiseras till nätlistor, nätlistorna sättas ihop 

(merge), en chipdesign skapas och integreras med en beskrivning av FPGAńs fysiska pinnplaceringar 

och slutligen brännas ned i en tom FPGA. 

Syntetisering: 

När VHDL-koden är testad och befunnits kodkänd kan syntetisering av hårdvaran ske. Syntetisering 

innebär att en koden kompileras och en nätlista över alla ledningar och grindar skapas. Till detta 

används i detta projekt programmet Synplify 7.0.



De moduler som syntiseras är: 

CAN-Core innehåller CAN-Kärnan, designad av BOSCH 

CAN-Shell servar kärnan med kommandon, data och EDF-logik för sändning, omsändning och 

mottagning 

CAN-Shell-int Kopplar ihop de två ovanstående modulerna 

GRWRTU Innehåller logik för Gyro Reaction Wheel Real Time Unit meddelanden. 

GRWRTU_Can Kopplar ihop samtliga ovanstående moduler och utgör gränssnitt mot de fysiska 

pinnarna på FPGAń. 

Mergning: 

De syntiserade modulerna slås ihop med hjälp av ett program som heter Merge. ”Mergningen” 

innebär att nätlistorna sätts ihop till en stor lista som beskriver hela chiparkitekturen. 

Nätlistorna sätts ihop i följande ordning: 

CAN-Core + CAN-Shell + CAN-Shell-int => CAN-Shell-int_merged 

CAN-Shell-int_merged + GRWRTU + GRWRTU_can => GRWRTU_can_merged 

Design av hårdvaran: 

Hårdvaran designas i ett program avsett för aktuell chiptyp, i det fallet ACTEL Designer v. 4. I 

designern placeras de fysiska grindarna och ledningarna på så sätt att dragning av dessa blir möjlig, 

dessutom optimeras chipets egenskaper på så sätt som önskas, idet här fallet för storlek. Detta är 

nödvändigt då ytterligare logik är tillförd varför det annars inte får plats på chipets yta. Detta medför 

dessvärre att designen inte är lämpat för rymdbruk då denna optimering ökar risken för problem 

orsakade av strålning (jfr kap 4.5.2). 

Utöver detta kopplas alla signaler ihop med de pinnar som finns beskrivna i pin-filen. Samma pin-fil 

används till EDF-CAN-chipet som till det ordinarie chipet, använt i SMART-1. Detta medför att EDF- 

CAN-chipet kan testas och användas i befintlig testhårdvara framtagen vid utvecklingen av SMART-1. 

Chipdesignen är en omfattande process och kräver mycket datakraft, med en modern PC tar 

processen, som är automatisk då den väl startats, ca 2 timmar i anspråk. 

Bränning av FPGA: 

Då designen är klar kan logiken slutligen brännas ned på en FPGA.. Detta sker med hjälp av såväl 

hård- som mjukvara från ACTEL. 

FPGAń som används heter ACTEL A54SX32PQ208 och är en vanlig, kommersiell, kiselkrets, ej 

lämpad för rymdbruk. De chip som används i rymden är 50-100 gånger dyrare och används därför inte 

vid prototyptillverkning och tester. 

FPGAń innehåller 20 000 st vippor och en stor mängd ledningar mellan dessa. Genom att belasta 

dessa ledningar med högre strömmar än de nominella bränns de oönskade ledningarna bort, varefter 

endast de önskade ledningarna kvarstår. Om brännprocessen lyckas, vilken den oftast gör, och 

designen är rätt erhålles därefter ett chip med den logik som designern skapat. 

Bränningen är irreversibel, d.v.s. efter att bränning är genomförd kan chipegenskaperna inte förändras 

igen. Detta innebär att om chipets egenskaper behöver ändras, exempelvis efter ett mindre lyckat test, 

måste alla moment fr.o.m. implementation i VHDL (kap 7.5) göras om. 

7.8 Test av FPGA 

Vid test av EDF-CAN-controllern används en testrigg bestående av: 

• Controllerkort till SMART-1 styrt via JTAG från en PC. Detta är en kopia på SMART-1´s 

huvuddator. Controllerkortet är utrustat med sin ordinarie CAN-controller. 

• Ett GRWRTU-kort från SMART-1 utrustat med ett ordinarie CAN-Controllerchip och ett EDF- 

CAN-controllerchip. GRWRTU-kortet innehåller en nominell arkitektur och en i stort sett 

identisk redundant del. Vid test hålls båda delarna aktiva, vilket förklarar varför två CANcontrollers 

finns på samma kort. 

• Ett oscilloscope som lyssnar på bussen samt på sändpinnen på EDF-CAN-controllern. 

• Samt en test-PC med avlyssnar/sändarutrustning anpassad för tester på SMART-1, bestående av 

en PC med ett CAN-kort, som utgör en egen nod i nätverket. 

Totalt finns alltså 4 noder i testnätverket varav 1 utgörs av en ny EDF-CAN-controller.



Som synes förekommer i stort sett enbart utrustning designad för SMART-1. Detta innebär vissa 

komplikationer, dels måste EDF-CAN-controllern anpassas så att den förstår SMART-1´s ordinarie 

ID-fält och sänder meddelanden som har relevans för testutrustningen. Dessutom måste en förståelse 

för SMART-1´s användning av ID-fälten skapas i syfte att förstå hur resultaten skall tolkas. 

Tabellen nedan visar hur ID-fältet används i SMART-1 [2] 

Bit No of bits Function Note 

ID28 - ID24 5 Originator 

ID23 – ID9 15 Destination 

ID8 – ID2 7 Message Type 

ID1 1 Spare bit = 1 

ID0 1 ID field destination 

sub-field (ID23-ID9) 

parity bit 

En del av de avsändare (Originators) som förekommer i SMART-1 är följande: 

Addresses 

ID28-ID24 

Node abbr. Node name 

Even parity = number 

of ones even 

00000 CON1 Spacecraft controller 

00001 CON2 

00010 GRWRTU1 Gyro/reaction wheel remote terminal unit 

00011 GRWRTU2 

… 

… 

För testet ovidkommande adresser mellan 00100- 

01111 

10000 PCDU1 Power control and distribution unit 

10001 PCDU2 

10010 PCDU3 

En del av de i SMART-1 förekommande mottagare, där en nolla i destinationsbiten adresserar noden 

ifråga: 

Destination bit Node name Node type 

ID23 CON1 and CON 2 Bus master 

ID22 GRWRTU1 AOCS 

ID21 GRWRTU2 AOCS 

… ID 20-ID 11 är för testet 

… ointressanta mottagare 

ID12 TMTC1 and TMTC2 TMTC 

ID11 PCDU1 Power 



Ett meddelande med godtyckligt innehåll från CON2 till GRWRTU1 och PCDU1 skulle därför ha 

följande utseende: 

Originator Destination Message type S P 

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 0 0 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 X X X X X X X 1 1



I ett EDF-CAN-meddelande har ju dock, som tidigare beskrivet i kap 7.2, spare-biten tagits bort och 

ersatts av EDF-biten som flyttats till Bit 28. Motsvarande EDF-meddelande får därför följande 

utseende: 

EDF Originator Destination Message type P 

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 

X 0 0 0 0 1 1 0 1 1 1 1 1 1 1 1 1 1 0 1 1 X X X X X X X 1 

Där EDF-biten är en nolla då noden befinner sig i sitt högprio-område och en etta då den befinner sig i 

sitt lågprio-område. 

En CAN-nod i Smart-1, liksom de som används i testutrustningen, skulle dock uppfatta meddelandet 

som antingen ursprunget från CON1, vid högprio-mode, eller från PCDU1 vi lågprio-mode. Resten av 

ID-fältet skulle också uppfattas fel, sannolikt skulle pariteten bli vanställd och meddelandet kastas 

bort. Därför specialtillverkas en EDF-CAN-controller där bit 28 fortfarande utgör EDF-bit, bit 27-24 

är satta till noll och bitarna 23-0 har samma egenskaper som i övriga ID-fält förekommande i 

SMART-1. Initialvärdet hos EDF-CAN-controllerns räknare är satt till 4. Därmed kan EDF-CANchipet 

kommunicera med de andra noderna i testnätverket. 

7.8.1 Testprocedur 

EDF-CAN-controllern testas enligt följande testschema: 

Testnr Beskrivning av test Förväntad respons 

1 Ett godtyckligt meddelande skickas iväg 

på bussen från test-PCń. 

2 Meddelandet RIBUS* sänds, av test- 

PCń, periodiskt (1 gång per sekund) på 

den nominella bussen. Avsändare: CON1 

3 PING** skickas till GRWRTU1 från test- 

PCń. Avsändare: CON1 

4*** Kontroll att EDF-CAN-controllern går 

från hög- till lågprio-område. POLL- 

GRWRTU**** sänds från test-PCń med 

avsändare CON1 

5 Kontroll att EDF-CAN-controllern går 

från låg- till högprio-område. Ingen 

åtgärd; GRWRTU-noderna är redan 

engagerade i att besvara POLLen från test 

4. 

6 Samma som test 1, dock sänder 

Controllerkortet till SMART-1 ständigt 

meddelanden med avsändare CON2 på 

bussen. Bussen fylls till 100%. 

Meddelandet har ingen destination. 




EDF-CAN-controllern sänder en ACKnoledgebit 

vid rätt tillfälle. 

EDF-CAN-controllern uppfattar meddelandet 

och stannar kvar på den nominella bussen. 

EDF-CAN-controllern besvarar PINGet, dock 

torde avsändaren tolkas som CON1 eller 

PCDU1. 

EDF-CAN-controllern svarar som CON1, går 

därefter in i lågprio område. Där förloras 

arbitreringen mot GRWRTU1 som svarar 3 

gånger… 

…varefter EDF-CAN-controllern åter går in i 

sitt högprio-område och vinner arbitreringen 

med ett, och endast ett, meddelande från 

CON1. EDF-CAN-controllern går därefter 

återigen in i sitt lågprio-område varvid 

GRWRTU1 sänder 3 meddelanden. Följt av 

CON1 och GRWRTU1 med sina 2 sista 

meddelanden. Slutligen sänder EDF-CANcontrollern 

sina sista 5 meddelanden, varav ett 

som CON1 och därefter som avsändare 

PCDU1 då controllern är i sitt lågprio-område. 

EDF-CAN-controllern sänder ACKnoledgebitar 

vid rätt tillfälle, vid varje meddelande. 

EDF-CAN-controllern uppfattar RIBUSmeddelandet 

och stannar kvar på den nominella 

bussen.




















EDF-CAN-controllern besvarar PINGet, som 

CON1 

EDF-CAN-controllern svarar som CON1, går 

därefter in i lågprio-område. Där förloras 

arbitreringen mot Controllerkortet för SMART- 

1 som sänder 3 gånger… 

EDF-CAN-controllern går in i sitt högprioområde 

och sänder ytterligare ett meddelande 

som CON1. Detta beteende fortsätter cykliskt 

intill dess att CON1 sänt 8 meddelanden. 

GRWRTU1 kommer inte in med sina 

meddelanden förrän controllerkortets 

sändningar som CON2 avbryts. 

* RIBUS= RIght BUS. Ett meddelande som i SMART-1-sytemet sänds av controllern varje sekund 

och upplyser RTU-noderna att de lyssnar på rätt buss. Upffattas inget RIBUS inom 4 sekunder byter 

noden buss till den redundanta CAN-bussen. 

** PING är ett meddelande som beordrar samtliga noder att svara som ett bekräftande att de är 

operativa. 

*** Inför test nr 4 startas GRWRTU-noden om i syfte att sätta räknaren i sitt initialvärde. 

**** . POLL-GRWRTU beordrar GRWRTU-noden att sända data om nodens status. Datat uppgår till 

8 st CAN-meddelanden. Under testet är såväl GRWRTU1 och GRWRTU2 aktiverade varför båda 

försöker svara. GRWRTU2 är dock utrustad med ett EDF-CAN-controllerkort och kommer därför att 

identifiera sig som CON1 eller PCDU1. 

7.8.2 Testresultat 

Testnr Respons Godkänt/icke godkänt 

Kommentarer 

1 EDF-CAN-controllern ACKar samtliga meddelanden Godkänt 

2 EDF-CAN-controllern stannar kvar på bussen intill dess att RIBUS 

meddelandena upphör då noden efter fyra sekunder byter buss 

Godkänt 

3 EDF-CAN-controllern besvarar pinget som CON1 eller PCDU1. Godkänt 

4 EDF-CAN-controllern svarar som CON1 och går sedan in i låg- Godkänt såtillvida att EDFpriomode 

där tillåts dock GRWRTU sända 4 gånger i stället för CAN-controllern faktiskt går 

förväntade 3 gånger. Se även fig. 7.9 

in i sitt låg-prioområde, dock 

beter sig inte räknaren som 

förväntat. 

5 EDF-CAN-controllern går åter in i sitt hög-prioområde. Fortsätter Godkänt. Se dock kommentar 

dock att bete sig enligt kommentar i test 4. 

ovan. 

6 EDF-CAN-controllern ACKar samtliga meddelanden Godkänt 

7 EDF-CAN-controllern stannar kvar på bussen intill dess att RIBUS 

meddelandena upphör då noden efter fyra sekunder byter buss 

Godkänt 

8 EDF-CAN-controllern besvarar pinget som CON1 Godkänt 

9 EDF-CAN-controllern svarar som CON1 och går sedan in i låg- Godkänt, se dock kommentar 

priomode där tillåts dock controllerkortet sända 4 gånger i stället för 

förväntade 3 gånger. Se även diagram i fig. 7.10 

test 4. 

10 EDF-CAN-controllern går åter in i sitt hög-prioområde, där den Godkänt, se dock kommentar 

sänder ett meddelande som CON1. Därefter sänder den var femte, 

istället för förväntade var fjärde, meddelande intill dess att samtliga 

åtta meddelanden sänts. Då controllerkortets sändningar avbryts 

sänder GRWRTU1 sina 8 meddelanden i tät följd. 

test 4.



Figur 7.9 EDF-CAN-controllern sänder ett meddelande som CON1 varje 

gång den går in i sitt högprio-område. 

Figur 7.10 Bussen är helt fylld med meddelanden (övre 

diagrammet), dock kommer EDF-CAN-controllern (undre 

grafen) in vid var femte meddelande. Det syns tydligt att EDF- 

CAN-controllern ACKar samtliga meddelanden.



Testerna visar tydligt att CAN-kärnan i EDF-CAN-controllern är operativ samt att gränssnittet mot 

GRWRTU-kortet fungerar tillfredställande. Vidare visar testet att det är möjligt att ” i farten” ändra 

prioritet på meddelandet, något som inte är möjligt med alla kommersiella CAN-controllers. 

Dock sker förändringen av prioriteten senare än tidigare simuleringar visat. Anledningen till detta är 

ännu okänd men skulle kunna ha sitt ursprung i att den nya prioriteten helt enkelt inte hinner laddas in 

i eller att koden i blocket ” Sending_or_Receiving ” i VHDL-koden inte exekveras på så sätt som 

önskas och därför inte räknar ned räknaren de gånger som arbitreringen vinns.


Martin Normark



8 Resultat 

Resultaten från den här utredningen kan delas upp i två delar: 

8.1 Rekommenderat nätverk i framtida satelliter 

FlexRay är det enda nätverk som både bedöms bli ett godkänt X-by-wire nätverk [20] och är 

tillräckligt flexibelt för att passa i Rymdbolagets satelliter[18]. FlexRay uppfyller dessutom så gott 

som alla krav som Rymdbolaget ställer på ett framtida nätverk. De kraven som inte uppfylls är att 

nätverket inte bedöms kommersialiseras förrän tidigast 2004 och därför av naturliga skäl inte heller 

idag har någon spridning bland användare. Dock väntas nätverket bli ordentligt spritt och väl använt 

då stora bolag som t.ex. BMW, DaimlerChrysler, BOSCH och General Motors alla ger sitt stöd till 

nätverksstandarden. 

FlexRay rekommenderas därför som framtida nätverk, dock måste innan FlexRay används en 

utvärdering beträffande dess verkliga förmåga och spridning i praktiken genomföras. Det är med 

andra ord knappast sannolikt att FlexRay kan ingå i något tillverkningsprojekt före 2006. 

TTP/C har efter tester genomförda av SP, även det visat sig vara ett mycket tillförlitligt nätverk [20], 

dock lämpar sig TTP/C mindre väl för användning av Rymdbolaget i dess satelliter [18]. Den 

huvudsakliga anledningen till det är TTP/C´s TDMA som bedöms alltför inflexibelt. 

Fram till dess bör därför CAN fortsätta att användas. Anledningarna till att CAN bör användas även i 

den närmaste framtiden är att en stor del av tidigare design kan återanvändas, varför det sannolikt kan 

bli både säkrare och billigare än andra, aldrig av Rymdbolaget använda, koncept. Vid sidan av detta 

finns det inga tecken på en omedelbar mycket stor förändring i mängden information som skall 

spridas i näten. Möjligen kan tänkas ett stort informationsflöde mellan ett instrument och en dator men 

detta kan i sådana fall lösas med en informationslänk mellan dessa två enheter. CAN-bussen bör dock, 

om så är möjligt, kompletteras med tidsdistribution, bättre bevakning mot babbling idiots och ett 

system för att bättre utnyttja tillgänglig bandbredd samtidigt som de viktigaste meddelandena får 

sändas först. Det senare skulle kunna lösas med s.k. EDF (Earliest Deadline First). 

Ett annat tekniskt bra sätt att uppgradera CAN-bussen kan vara att byta ut den mot TTCAN. Dock 

bedöms den ekonomiska och tidsmässiga kostnaden alltför stor i förhållande till de tekniska 

förbättringar som de facto erhålles vid en dylik uppgradering. 

Vid sidan om de rekommenderade nätverken har framkommit att såväl USB som Spacewire kan 

utgöra mycket kraftfulla kommunikationslänkar mellan två noder. Där den stora fördelen med USB är 

dess stora kommersiella spridning, medan det som talar för Spacewire är att rymdkretsar redan finns 

framtagna samt också finns integrerade med diverse komponenter, såsom DSP´s, Kameror och 

massminnen, som används i rymdsammanhang. 

8.2 Test av förbättrad CAN-buss 

Efter dialog med Gunnar Andersson på Rymdbolaget bestämdes att försök med att utveckla en CANbuss 

med EDF (Earliest Deadline First) skulle genomföras. Försöken kan delas upp i tre delmoment: 

8.2.1 Simulering av EDF-CAN-buss 

Simuleringskörningarna, som finns utskrivna i Appendix A, visar att ingen nod missar sin deadline 

vid någon av tidigare beskrivna körningar. Simuleringen visar vidare att all garanterad bandbredd kan 

användas av de noder som blivit tilldelad denna, vidare kan all övrig tillgänglig bandbredd som 

uppstår av att en nod inte utnyttjar sin tilldelade bandbredd eller inte är allokerad till någon nod, 

användas. Dock kommer de högst grundprioriterade noderna att få tillgång till detta extra utrymme på 

bussen i första hand. 

Nedan visas en sammanställning av resultatet från en simuleringskörning där noderna hela tiden sände 

så mycket de kunde:



number of transmissions rounds: 6360 

node 0: 0.485 used bandwidth, 0.333 guaranteed bandwidth 








guaranteed bus utilisation = 0.848 

actual bus utilisation = 1.000 

number of missed deadlines 0 

Vidare en sammanställning av resultatet från en simuleringskörning där noder ibland avstod från att 

sända då de blev erbjudna mer bandbredd utöver den garanterade. 













Simuleringarna visar att det är möjligt att använda EDF i ett CAN-nätverk och att genom att endast 

dedicera en bit från ID-fältet få tillräcklig upplösning för att alla noder skall hinna sända innan dess 

deadline nåtts. Simuleringen visar vidare att överbliven bandbredd fördelas, nedåt genom hierarkien, 

på så sätt att den nod som har högst prioritet först får chansen att nyttja den. 

8.2.2 Simulering av funktion hos EDF-CAN-Shellet 

Det nya EDF-CAN-shellet testades först i Rymdbolagets testbänk för CAN-Shell, skriven i VHDL. 

Simuleringsprogrammet som användes var Modelsim PE. Samtliga av Rymdbolagets tester lyckades. 

Därefter kompletterades testbänken med ytterligare tester, test 5.1 samt test 6.1, vars uppgift är att 

kontrollera att räknaren och EDF-priobiten i ID-fältet uppförde sig som de skulle, se även kap 7.6. 

Simuleringen visar att det är möjligt att integrera en EDF-funktion i Rymdbolagets CAN-Shell. 

Simuleringen visar dessutom att EDF-shellet är rätt programmerat såtillvida att räknare och EDF-IDbiten 

beter sig som den skall då noden vinner resp. förlorar en arbitrering och därmed på ett 

tillfredsställande sätt växlar mellan låg- och hög-prioområde. 

Test 5.1 och Test 6.1 finns återgivna i sin helhet i Appendix D 

8.2.3 Test av EDF-CAN-controller implementerad i FPGA 

Testerna, som finns beskrivna i kap. 7.8, visar tydligt att CAN-kärnan i EDF-CAN-controllern är 

operativ samt att gränssnittet mot GRWRTU-kortet fungerar tillfredsställande. Vidare visar testet att 

det är möjligt att ” i farten” ändra prioritet på meddelandet. Dock sker ändringen av prioriteten upp till 

nodens hög-prioområde ett meddelande senare än tidigare simuleringar visat. Vilket får till följd att 

EDF-noden endast sänder var femte meddelande istället för var fjärde. Anledningen till detta är ännu 

okänd men skulle kunna ha sitt ursprung i att den nya prioriteten helt enkelt inte hinner laddas in i 

eller att koden i blocket ”Tranceiver_or_receiver” i VHDL-koden inte exekveras på så sätt som önskas 

och därför inte räknar ned räknaren de gånger som arbitreringen vinns. Detta ses dock inte som något 

större problem utan kan lösas med lite traditionell debuggning, något som dock inte är aktuellt för 

denna prototypcontroller.



9 Slutsats 

CAN-bussen, på det sätt den används i SMART-1, är inte idealisk i en framtida satellit. Anledningen 

till detta är dels att bandbredden är begränsad till 1Mbps men framför allt därför att CAN-bussen 

saknar teknik för att hantera bortfallna noder, noder som stör ut bussen, s.k. babbling idiots, på olika 

sätt samt teknik för synkronisering av noderna ingående i nätverket. Avsaknaden av inbyggt stöd för 

tidssynkronisering leder till att en separat kommunikationsväg för tidssynkronisering användas på 

SMART-1, vilket tar upp onödig vikt och datakraft. Avsaknad av teknik för att hantera babbling idiots 

kan i värsta fall leda till systemkollaps där inga i satelliten ingående noder kan kommunicera med 

varandra. 

Ett framtida nätverk skulle kunna utgöras av FlexRay, ett nytt nätverk med stort stöd från bilindustrin. 

FlexRay hanterar ovanstående problem på ett säkert sätt, så säkert att det bedöms bli ett av de första 

nätverk i världen som godkänns för säkerhetskritiska X-by-wire applikationer. Säkerheten till trots är 

FlexRay, till skillnad från andra lika säkra nätverk, tillräckligt flexibelt för att passa i en satellit 

tillverkad av Rymdbolaget. FlexRay uppfyller Rymdbolagets alla tekniska krav på ett framtida 

nätverk men är dock inte färdigutvecklat för kommersiell användning ännu. Tidigast år 2004 beräknas 

FlexRay ha nått dit. Därefter återstår att återigen utvärdera FlexRay innan det kan komma till bruk 

inom Rymdbolaget. 

Fram till dess framstår CAN-bussen som det bästa alternativet, då om möjligt med förstärkt skydd mot 

babbling idiots, tidssynkronisering och gärna EDF. 

EDF, Earliest Deadline First, är en metod där det meddelande som mest skyndsamt måste levereras 

vid varje tillfälle erhåller högst prioritet på bussen. Dessutom har EDF de fördelarna att alla noder kan 

garanteras en viss andel an bussens totala kapacitet med en garanterad maximal fördröjning. EDF är 

möjligt att använda i ett CAN-nätverk. Det är dessutom möjligt att integrera i Rymdbolagets CANcontroller, 

vilket leder till att EDF kan användas utan förändringar i datorerna och gränssnitten hos 

satelliten. Detta visas genom framgångsrika datasimuleringar samt produktion av en fungerande 

prototyp-CAN-controller med EDF.


Martin Normark



10 Diskussion och möjligheter för framtida utredningar 

I efterhand frågar jag mig gärna varför inte fler, eller ibland också andra, nätverk studerades. Svaret är 

helt enkelt, och riktigt, att tiden inte bedömdes räcka till, respektive okunnighet från min sida då 

projektet startades och nätverken valdes. Några av de nätverk som hade varit intressanta att studera är 

ju TCP/IP, tänk själv att enkelt kunna accessa satelliten från Internet, med intressanta 

tillförlitlighetsjämförelser mot TTP/och FlexRay men även Firewire som kunnats jämföras mot såväl 

USB som Spacewire. Firewire hade varit extra intressant då Honeywell i dagarna släppt en ny 

strålningstålig krets för just Firewire. Vad som heller inte framgår av rapporten är det formidabla krig 

som pågår mellan FlexRay och TTP/C. Båda parter slåss om den åtråvärda titeln som de facto 

standard inom x-by-wire industrin. Ett krig där TTP/c har tagit täten genom att redan nu ha ett 

operativt, kommersiellt nätverk som av erkänd testare som exempelvis SP anses vara säkert. Många 

anser dock att FlexRay kan gå om TTP/C då de dels har en flexiblare lösning på sin schedulering, 

något som var värdefullt för exempelvis Rymdbolaget, och dels har fler och större företag som backar 

upp dem. 

Näten har också kommit till på lite olika sätt, där TTP/C tämligen kompromisslöst skapats på ett 

universitet i Österrike för att sedan erbjudas marknaden designat och klart. Tvärtom har FlexRay 

tillkommit på initiativ från ett antal aktörer inom biltillverkningsmarknaden, där de tillsammans 

försöker att tillgodose de krav och önskemål som inkommer från olika håll. Rykten säger till och med 

att FlexRay uppkom på grund av att tillverkaren av TTP/C vägrade tillgodose vissa biltillverkares 

krav på förändringar av TTP/C. Det är alltså på intet sätt självklart vilket nätverk som faktiskt kommer 

att bli bäst, det vetenskapligt strikta nätverk, TTP/C, som kanske inte passar någon eller det av 

kompromisser, mellan flexibilitet, säkerhetskrav och övriga tillverkarkrav ihoppusslade nätverk som 

heter FlexRay. 

Det kunde också vara intressant att undersöka CANopen som inte blev undersökt. Det verkar kunna 

bli riktigt spritt och har ju därför en stor potential, extra synd eftersom CANopen under resans gång 

dessutom utsågs till en rymdstandard av ESA.


Martin Normark



11 Tack till 

Leif Granholm, utan vars hjälp, med VHDL-programmeringen, detta examensarbete inte skulle ha 

varit möjligt att genomföra. 

Mats Rehnström, för hjälp med hårdvara, inspiration och nya intressanta teorier rörande det mesta. 

Håkan Sivencrona och Per Johannessen för att ni låtit mig ta del av såväl Sveriges Provnings- och 

Forskningsinstituts som delar av VOLVO´s erfarenheter beträffande säkerhet och användning av 

TTP/C, FlexRay och CAN. Detta trots mitt morgonhumör… 

Martin Törngren för en föredömligt genomförd handledning. 

Gunnar Andersson som trots en, särskilt inledningsvis, kraftig tidspress hjälpte mig på rätt väg. 

Sist men inte minst min förtjusande flickvän Jenny Sperens som stått ut med mig och dessutom 

korrekturläst denna rapport.


Martin Normark



12 Begrepp och förkortningar som används I denna rapport 

Busguardian Separat hårdvara som kontrollerar att en nod endast sänder då den 

skall sända. 

CAN Controller Area Network 

CON1, CON2 SMART-1´s två huvuddatorer 

DSP Digital Signal Processor 

EDF Earliest Deadline First 

ESA European Space Agency 

ESD Electro Static Discharge 

FlexRay Namn på ett nätverk 

FPGA Field Programmable gate array 

GRWRTU-kort Gyro and Reaction Wheel Real Time Unit 

GS Ground Station (vid radiokommunikation) 

Mbps Mega bits per second 

MOST Media Oriented Systems Transport 

NTU Node Timer Unit 

Payloadbussen Databuss för transport av information till och från intrument ombord 

på SMART-1 

RIBUS You are on the right bus 

SMART-1 Rymdbolagets senaste satellit 

SP Sveriges Provnings- och Forskningsinstitut 

Spacewire Namn på ett datanätverk 

SSC Swedish Space Corporation (Rymdbolagets engelska namn) 

STEAM Arbetsnamn på en eventuell framtida satellit hos rymdbolaget 

Systembussen Databuss för transport av information till och från systemdelar 

ombord på SMART-1 

TMTC Transponderenheten på en satellit 

TTCAN Time Triggered CAN 

TTP/C Time Triggered Protocoll version C 

USB Universal Serial Bus 

VHDL Very high speed integrated circuit (VHSIC) Hardware Description 

Language 

x-by-wire Samlingsnamn för bl.a. steer-, throttle-, och brake-by-wire.


Martin Normark



13 Referenser 

1. SMART-1 CAN Bus Hardware Architectural Description 

Document ID: S1-SU-HAD-26 Version 1.3 Swedish Space Corporation 

2. SMART-1 CAN controller user manual 

Document ID: S1-SU-MA-1 Version 3.5 Swedish Space Corporation 

3. CAN Specification 2.0B från http://www.can.bosch.com/content/Literature.html den 14/10-02 

4. Universal Serial Bus Specification Revision 2.0 från http://www.usb.org/developers/docs.html den 

25/9-02 

5. Space engineering, SpaceWire -Links, nodes routers and network. ECSS-E-50-12 Draft 3 

Utgiven av ESA Publication Division 22 april 2002 

http://www.estec.esa.nl/tech/spacewire/ den 24/8 -02 

6. Time-Triggered Protocol TTP/C Bus-Compatibility Specification 

Document number D-032-S-10-032 

TTTech Computerrechnik AG 

http://www.tttech.com 

7. TTP/C-C1 Communications Controller 

Austriamicrosystems 

http://www.tttech.com 

8. TTCAN IP Module User´s Manual Revision 1.5 

BOSCH 

http://www.can.bosch.com/content/Literature.html den 23/8 -02 

9. CAN Network with Time Triggered Communication 

av B. Müller, T Führer, F. Hartwich, R. Hugel och H. Weiler 

http://www.can.bosch.com/content/Literature.html den 23/8 -02 

10. FlexRay Requirements Specification ver.2.0.2 

http://www.flexray.com/ 

11. OS8104 MOST Network Tranceiver, final data sheet, Dec 2000. 

Utgiven OASIS SiliconSystems AG 

http://www.mostnet.de/downloads/Specifications/ den 7/10 -02 

12. MOST Specification Rev 2.1 02/2001 

Utgiven av MOST Cooperation 

http://www.mostnet.de/downloads/Specifications/ den 7/10 –02 

13. EDF applied to CAN 

Gunnar Andersson 

Swedish Space Corporation 

14. ”Scheduling Algorithms for Multiprogramming in a Hard-Real-Time Environment” 

C. L. LIU, MIT Massachusetts Institute of Technology, och James W. Layland, California Institute of 

Technology 

Kan laddas ned från: http://www.vmars.tuwien.ac.at/courses/betriebssysteme/artikel_liu73.pdf 

15. Dual Priority Assignment 

Alan Burns, University of York 

Kan laddas ned från: ftp://ftp.cs.york.ac.uk/pub/realtime/papers/dual.ps.Z



13.1 Muntliga källor och Intervjuer 

16. Sytze Veldman, Rymdbolaget den 2/9 -02 

17. Bengt Holmqvist, Rymdbolaget den 4/9 -02 

18. Gunnar Andersson, Rymdbolaget 10/9 -02 

19. Leif Granholm, Rymdbolaget 8/9 -02 

20. Håkan Sivencrona SP, Statens Provningsinstitut 

13.2 Litteraturtips 

End-to-end arguments in system design 

J.H. Saltzer et. al. 

Laboratory for Computer Science, MIT. 

Från http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf 

Bus Architectures For Safety-Critical Embedded Systems 

John Rushby, Computer Science Laboratory 

SRI International. 

Probabilistic End-to-End Delay Bound for Earliest Deadline First Scheduling. 

Matthew Andrews, Bell Laboratories. 

Från www.ieee-infocom.org/2000/papers/483.pdf 

Schemaläggning. 

Peter Loborg 

Institutionen för Datavetenskap, Universitetet i Linköping. 

Från www.ida.liu.se/~m_reap/TDDI80/OH-Fo5.ps samt 

www.ida.liu.se/~m_reap/TDDI80/OH-Fo6.ps 

SMART-1 System Unit Hardware Architectural Design Description 

Document ID: S1-SU-HAD-33 Version:1.2 Swedish Space Corporation 

CAN-skola på nätet: 

www.kvaser.com 

Information om Spacewire 

http://www.estec.esa.nl/tech/spacewire/ 

Time Triggered Communication on CAN 

Timing in the TTCAN Network 

Fault tolerant TTCAN network 

Ovanstående artiklar är författade av B. Müller, T Führer, F. Hartwich, R. Hugel och H. Weiler från 

BOSCH och kan laddas ned från http://www.can.bosch.com/content/Literature.html 

TTCAN Testchip på http://www.can.bosch.com/content/TTCAN_TC.html 

Advantages with a global clock in CAN system av Lars-Berno Fredriksson, Kvaser AB



Appendix A Simulering av EDF-algoritm 

Nedan återfinns utdrag ur simuleringskörningarna, varje rad motsvarar ett meddelande och under 

nodernas respektive kolumn finns räknarens värde samt aktuell prioritet redovisat som (räknarens 

värde : grundprio + lågprio/högprio) värdet för låg- resp högprio är 0 resp. 64. Sist i varje rad 

redovisas vilken nod som fick sända under aktuell runda, dvs den nod med lägst aktuell prioritet. Av 

praktiska skäl är en stor del av sändingarna ej redovisade, dock finns alla med i den sammanfattning 

som avslutar varje körning. 

De två första körningarna har följande inställningar: 









Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

= 

0. 

848 

≤ 1 

Körning där räknaren värde begränsas till dubbla initialvärdet. 

setting up initial conditions 

nod-A nod-B nod-C nod-D nod-E nod-F nod-G nod-H s„ndare 

-------------------------------------------------------- 

2: 0 5: 1 9: 2 12: 3 21: 4 22: 5 23: 6 24: 7 tx = 0 

4:64 4: 1 8: 2 11: 3 20: 4 21: 5 22: 6 23: 7 tx = 1 

3:64 9:65 7: 2 10: 3 19: 4 20: 5 21: 6 22: 7 tx = 2 

2: 0 8:65 16:66 9: 3 18: 4 19: 5 20: 6 21: 7 tx = 0 

4:64 7:65 15:66 8: 3 17: 4 18: 5 19: 6 20: 7 tx = 3 

3:64 6:65 14:66 20:67 16: 4 17: 5 18: 6 19: 7 tx = 4 

2: 0 5: 1 13:66 19:67 37:68 16: 5 17: 6 18: 7 tx = 0 

4:64 4: 1 12:66 18:67 36:68 15: 5 16: 6 17: 7 tx = 1 

3:64 9:65 11:66 17:67 35:68 14: 5 15: 6 16: 7 tx = 5 

2: 0 8:65 10:66 16:67 34:68 36:69 14: 6 15: 7 tx = 0 

4:64 7:65 9: 2 15:67 33:68 35:69 13: 6 14: 7 tx = 2 

3:64 6:65 18:66 14:67 32:68 34:69 12: 6 13: 7 tx = 6 

2: 0 5: 1 17:66 13:67 31:68 33:69 35:70 12: 7 tx = 0 

4:64 4: 1 16:66 12: 3 30:68 32:69 34:70 11: 7 tx = 1 

3:64 9:65 15:66 11: 3 29:68 31:69 33:70 10: 7 tx = 3 

2: 0 8:65 14:66 23:67 28:68 30:69 32:70 9: 7 tx = 0 

4:64 7:65 13:66 22:67 27:68 29:69 31:70 8: 7 tx = 7 

3:64 6:65 12:66 21:67 26:68 28:69 30:70 32:71 tx = 0 

5:64 5: 1 11:66 20:67 25:68 27:69 29:70 31:71 tx = 1 

4:64 10:65 10:66 19:67 24:68 26:69 28:70 30:71 tx = 0 

5:64 9:65 9: 2 18:67 23:68 25:69 27:70 29:71 tx = 2 

4:64 8:65 18:66 17:67 22:68 24:69 26:70 28:71 tx = 0 

5:64 7:65 17:66 16:67 21: 4 23:69 25:70 27:71 tx = 4 

4:64 6:65 16:66 15:67 42:68 22: 5 24:70 26:71 tx = 5 

3:64 5: 1 15:66 14:67 41:68 44:69 23: 6 25:71 tx = 1



2: 0 10:65 14:66 13:67 40:68 43:69 22: 6 24: 7 tx = 0 

4:64 9:65 13:66 12: 3 39:68 42:69 21: 6 23: 7 tx = 3 

3:64 8:65 12:66 24:67 38:68 41:69 20: 6 22: 7 tx = 6 

2: 0 7:65 11:66 23:67 37:68 40:69 43:70 21: 7 tx = 0 

4:64 6:65 10:66 22:67 36:68 39:69 42:70 20: 7 tx = 7 

3:64 5: 1 9: 2 21:67 35:68 38:69 41:70 44:71 tx = 1 

2: 0 10:65 8: 2 20:67 34:68 37:69 40:70 43:71 tx = 0 

4:64 9:65 7: 2 19:67 33:68 36:69 39:70 42:71 tx = 2 

3:64 8:65 16:66 18:67 32:68 35:69 38:70 41:71 tx = 0 

5:64 7:65 15:66 17:67 31:68 34:69 37:70 40:71 tx = 0 

5:64 6:65 14:66 16:67 30:68 33:69 36:70 39:71 tx = 0 

5:64 5: 1 13:66 15:67 29:68 32:69 35:70 38:71 tx = 1 

4:64 10:65 12:66 14:67 28:68 31:69 34:70 37:71 tx = 0 

5:64 9:65 11:66 13:67 27:68 30:69 33:70 36:71 tx = 0 

5:64 8:65 10:66 12: 3 26:68 29:69 32:70 35:71 tx = 3 

4:64 7:65 9: 2 24:67 25:68 28:69 31:70 34:71 tx = 2 

| 

| 

| 

| 













Körning där nod avstår från sändning då räknaren överstiger dubbla initialvärdet 



-------------------------------------------------------- 

2: 0 5: 1 9: 2 12: 3 21: 4 22: 5 23: 6 24: 7 tx = 0 

4:64 4: 1 8: 2 11: 3 20: 4 21: 5 22: 6 23: 7 tx = 1 

3:64 9:65 7: 2 10: 3 19: 4 20: 5 21: 6 22: 7 tx = 2 

2: 0 8:65 16:66 9: 3 18: 4 19: 5 20: 6 21: 7 tx = 0 

4:64 7:65 15:66 8: 3 17: 4 18: 5 19: 6 20: 7 tx = 3 

3:64 6:65 14:66 20:67 16: 4 17: 5 18: 6 19: 7 tx = 4 

2: 0 5: 1 13:66 19:67 37:68 16: 5 17: 6 18: 7 tx = 0 

4:64 4: 1 12:66 18:67 36:68 15: 5 16: 6 17: 7 tx = 1 

3:64 9:65 11:66 17:67 35:68 14: 5 15: 6 16: 7 tx = 5 

2: 0 8:65 10:66 16:67 34:68 36:69 14: 6 15: 7 tx = 0 

4:64 7:65 9: 2 15:67 33:68 35:69 13: 6 14: 7 tx = 2 

3:64 6:65 18:66 14:67 32:68 34:69 12: 6 13: 7 tx = 6 

2: 0 5: 1 17:66 13:67 31:68 33:69 35:70 12: 7 tx = 0



4:64 4: 1 16:66 12: 3 30:68 32:69 34:70 11: 7 tx = 1 

3:64 9:65 15:66 11: 3 29:68 31:69 33:70 10: 7 tx = 3 

2: 0 8:65 14:66 23:67 28:68 30:69 32:70 9: 7 tx = 0 

4:64 7:65 13:66 22:67 27:68 29:69 31:70 8: 7 tx = 7 

3:64 6:65 12:66 21:67 26:68 28:69 30:70 32:71 tx = 0 

5:64 5: 1 11:66 20:67 25:68 27:69 29:70 31:71 tx = 1 

4:64 10:65 10:66 19:67 24:68 26:69 28:70 30:71 tx = 0 

6:64 9:65 9: 2 18:67 23:68 25:69 27:70 29:71 tx = 2 

5:64 8:65 18:66 17:67 22:68 24:69 26:70 28:71 tx = 0 

6:64 7:65 17:66 16:67 21: 4 23:69 25:70 27:71 tx = 4 

5:64 6:65 16:66 15:67 42:68 22: 5 24:70 26:71 tx = 5 

4:64 5: 1 15:66 14:67 41:68 44:69 23: 6 25:71 tx = 1 

3:64 10:65 14:66 13:67 40:68 43:69 22: 6 24: 7 tx = 6 

2: 0 9:65 13:66 12: 3 39:68 42:69 45:70 23: 7 tx = 0 

4:64 8:65 12:66 11: 3 38:68 41:69 44:70 22: 7 tx = 3 

3:64 7:65 11:66 23:67 37:68 40:69 43:70 21: 7 tx = 7 

2: 0 6:65 10:66 22:67 36:68 39:69 42:70 45:71 tx = 0 

4:64 5: 1 9: 2 21:67 35:68 38:69 41:70 44:71 tx = 1 

3:64 10:65 8: 2 20:67 34:68 37:69 40:70 43:71 tx = 2 

2: 0 9:65 17:66 19:67 33:68 36:69 39:70 42:71 tx = 0 

4:64 8:65 16:66 18:67 32:68 35:69 38:70 41:71 tx = 0 

6:64 7:65 15:66 17:67 31:68 34:69 37:70 40:71 tx = 1 

5:64 12:65 14:66 16:67 30:68 33:69 36:70 39:71 tx = 0 

6:64 11:65 13:66 15:67 29:68 32:69 35:70 38:71 tx = 1 

5:64 12:65 12:66 14:67 28:68 31:69 34:70 37:71 tx = 0 

6:64 11:65 11:66 13:67 27:68 30:69 33:70 36:71 tx = 1 

5:64 12:65 10:66 12: 3 26:68 29:69 32:70 35:71 tx = 3 

4:64 11:65 9: 2 24:67 25:68 28:69 31:70 34:71 tx = 2 

3:64 10:65 18:66 23:67 24:68 27:69 30:70 33:71 tx = 0 

5:64 9:65 17:66 22:67 23:68 26:69 29:70 32:71 tx = 0 

6:64 8:65 16:66 21:67 22:68 25:69 28:70 31:71 tx = 1 

5:64 12:65 15:66 20:67 21: 4 24:69 27:70 30:71 tx = 4 

4:64 11:65 14:66 19:67 42:68 23:69 26:70 29:71 tx = 0 

6:64 10:65 13:66 18:67 41:68 22: 5 25:70 28:71 tx = 5 

5:64 9:65 12:66 17:67 40:68 44:69 24:70 27:71 tx = 0 

6:64 8:65 11:66 16:67 39:68 43:69 23: 6 26:71 tx = 6 

5:64 7:65 10:66 15:67 38:68 42:69 46:70 25:71 tx = 0 

6:64 6:65 9: 2 14:67 37:68 41:69 45:70 24: 7 tx = 2 

5:64 5: 1 18:66 13:67 36:68 40:69 44:70 23: 7 tx = 1 

4:64 10:65 17:66 12: 3 35:68 39:69 43:70 22: 7 tx = 3 

3:64 9:65 16:66 24:67 34:68 38:69 42:70 21: 7 tx = 7 

2: 0 8:65 15:66 23:67 33:68 37:69 41:70 45:71 tx = 0 

4:64 7:65 14:66 22:67 32:68 36:69 40:70 44:71 tx = 0 

6:64 6:65 13:66 21:67 31:68 35:69 39:70 43:71 tx = 1 

| 

| 

| 

| 



node 1: 0.240 used bandwidth, 0.167 guaranteed bandwidth












Körning där 100% av bussbandbredden allokeras och fördelas på ett dåligt sätt 

Inställningar: 









Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

= 

0. 

998 

≤ 1 



-------------------------------------------------------- 

2: 0 4: 1 5: 2 10: 3 12: 4 21: 5 22: 6 23: 7 tx = 0 

4:14 3: 1 4: 2 9: 3 11: 4 20: 5 21: 6 22: 7 tx = 1 

3:14 7:13 3: 2 8: 3 10: 4 19: 5 20: 6 21: 7 tx = 2 

2: 0 6:13 8:12 7: 3 9: 4 18: 5 19: 6 20: 7 tx = 0 

4:14 5:13 7:12 6: 3 8: 4 17: 5 18: 6 19: 7 tx = 3 

3:14 4: 1 6:12 16:11 7: 4 16: 5 17: 6 18: 7 tx = 1 

2: 0 8:13 5: 2 15:11 6: 4 15: 5 16: 6 17: 7 tx = 0 

4:14 7:13 4: 2 14:11 5: 4 14: 5 15: 6 16: 7 tx = 2 

3:14 6:13 9:12 13:11 4: 4 13: 5 14: 6 15: 7 tx = 4 

2: 0 5:13 8:12 12:11 16:10 12: 5 13: 6 14: 7 tx = 0 

4:14 4: 1 7:12 11:11 15:10 11: 5 12: 6 13: 7 tx = 1 

3:14 8:13 6:12 10: 3 14:10 10: 5 11: 6 12: 7 tx = 3 

2: 0 7:13 5: 2 20:11 13:10 9: 5 10: 6 11: 7 tx = 0 

4:14 6:13 4: 2 19:11 12: 4 8: 5 9: 6 10: 7 tx = 2 

3:14 5:13 9:12 18:11 11: 4 7: 5 8: 6 9: 7 tx = 4 

2: 0 4: 1 8:12 17:11 23:10 6: 5 7: 6 8: 7 tx = 0 

4:14 3: 1 7:12 16:11 22:10 5: 5 6: 6 7: 7 tx = 1 

3:14 7:13 6:12 15:11 21:10 4: 5 5: 6 6: 7 tx = 5 

2: 0 6:13 5: 2 14:11 20:10 25: 9 4: 6 5: 7 tx = 0 

4:14 5:13 4: 2 13:11 19:10 24: 9 3: 6 4: 7 tx = 2



3:14 4: 1 9:12 12:11 18:10 23: 9 2: 6 3: 7 tx = 1 

2: 0 8:13 8:12 11:11 17:10 22: 9 1: 6 2: 7 tx = 0 

4:14 7:13 7:12 10: 3 16:10 21: 5 0: 6 1: 7 tx = 3 

3:14 6:13 6:12 20:11 15:10 20: 5 -1: 6 0: 7 tx = 5 

2: 0 5:13 5: 2 19:11 14:10 41: 9 -2: 6 -1: 7 tx = 0 

4:14 4: 1 4: 2 18:11 13:10 40: 9 -3: 6 -2: 7 tx = 1 

3:14 8:13 3: 2 17:11 12: 4 39: 9 -4: 6 -3: 7 tx = 2 

2: 0 7:13 8:12 16:11 11: 4 38: 9 -5: 6 -4: 7 tx = 0 

4:14 6:13 7:12 15:11 10: 4 37: 9 -6: 6 -5: 7 tx = 4 

3:14 5:13 6:12 14:11 22:10 36: 9 -7: 6 -6: 7 tx = 6 

2: 0 4: 1 5: 2 13:11 21:10 35: 9 15: 6 -7: 7 tx = 0 

4:14 3: 1 4: 2 12:11 20:10 34: 9 14: 6 -8: 7 tx = 1 

3:14 7:13 3: 2 11:11 19:10 33: 9 13: 6 -9: 7 tx = 2 

2: 0 6:13 8:12 10: 3 18:10 32: 9 12: 6-10: 7 tx = 0 

4:14 5:13 7:12 9: 3 17:10 31: 9 11: 6-11: 7 tx = 3 

3:14 4: 1 6:12 19:11 16:10 30: 9 10: 6-12: 7 tx = 1 

2: 0 8:13 5: 2 18:11 15:10 29: 9 9: 6-13: 7 tx = 0 

4:14 7:13 4: 2 17:11 14:10 28: 9 8: 6-14: 7 tx = 2 

3:14 6:13 9:12 16:11 13:10 27: 9 7: 6-15: 7 tx = 6 

2: 0 5:13 8:12 15:11 12: 4 26: 9 29: 8-16: 7 tx = 0 

4:14 4: 1 7:12 14:11 11: 4 25: 9 28: 8-17: 7 tx = 1 

3:14 8:13 6:12 13:11 10: 4 24: 9 27: 8-18: 7 tx = 4 

2: 0 7:13 5: 2 12:11 22:10 23: 9 26: 8-19: 7 tx = 0 

4:14 6:13 4: 2 11:11 21:10 22: 9 25: 8-20: 7 tx = 2 

3:14 5:13 9:12 10: 3 20:10 21: 5 24: 8-21: 7 tx = 3 

2: 0 4: 1 8:12 20:11 19:10 20: 5 23: 8-22: 7 tx = 0 

4:14 3: 1 7:12 19:11 18:10 19: 5 22: 6-23: 7 tx = 1 

3:14 7:13 6:12 18:11 17:10 18: 5 21: 6-24: 7 tx = 5 

2: 0 6:13 5: 2 17:11 16:10 39: 9 20: 6-25: 7 tx = 0 

4:14 5:13 4: 2 16:11 15:10 38: 9 19: 6-26: 7 tx = 2 

3:14 4: 1 9:12 15:11 14:10 37: 9 18: 6-27: 7 tx = 1 

2: 0 8:13 8:12 14:11 13:10 36: 9 17: 6-28: 7 tx = 0 

4:14 7:13 7:12 13:11 12: 4 35: 9 16: 6-29: 7 tx = 4 

3:14 6:13 6:12 12:11 24:10 34: 9 15: 6-30: 7 tx = 6 

2: 0 5:13 5: 2 11:11 23:10 33: 9 37: 8-31: 7 tx = 0 

4:14 4: 1 4: 2 10: 3 22:10 32: 9 36: 8-32: 7 tx = 1 

3:14 8:13 3: 2 9: 3 21:10 31: 9 35: 8-33: 7 tx = 2 

2: 0 7:13 8:12 8: 3 20:10 30: 9 34: 8-34: 7 tx = 0 

4:14 6:13 7:12 7: 3 19:10 29: 9 33: 8-35: 7 tx = 3 

3:14 5:13 6:12 17:11 18:10 28: 9 32: 8-36: 7 tx = 7 

2: 0 4: 1 5: 2 16:11 17:10 27: 9 31: 8-13: 7 tx = 0 

4:14 3: 1 4: 2 15:11 16:10 26: 9 30: 8-14: 7 tx = 1 

3:14 7:13 3: 2 14:11 15:10 25: 9 29: 8-15: 7 tx = 2 

2: 0 6:13 8:12 13:11 14:10 24: 9 28: 8-16: 7 tx = 0 

4:14 5:13 7:12 12:11 13:10 23: 9 27: 8-17: 7 tx = 7 

3:14 4: 1 6:12 11:11 12: 4 22: 9 26: 8 6: 7 tx = 1 

2: 0 8:13 5: 2 10: 3 11: 4 21: 5 25: 8 5: 7 tx = 0 

4:14 7:13 4: 2 9: 3 10: 4 20: 5 24: 8 4: 7 tx = 2 

| 

| 

| 

| 

number of transmissions rounds: 18324














Körning där 100% av bussbandbredden allokeras och fördelas på ett bra sätt 

Inställningar: 









Vilket ger 

U 

tot 

= ∑U 

i 

i= 

A, 

B, 

C... 

= 1 

Som synes ger detta en tydlig periodicitet som är markerad med tjockare stil. 



-------------------------------------------------------- 

3: 0 3: 1 4: 2 9: 3 19: 4 19: 5 19: 6 19: 7 tx = 0 

6:64 2: 1 3: 2 8: 3 18: 4 18: 5 18: 6 18: 7 tx = 1 

5:64 5:65 2: 2 7: 3 17: 4 17: 5 17: 6 17: 7 tx = 2 

4:64 4:65 6:66 6: 3 16: 4 16: 5 16: 6 16: 7 tx = 3 

3: 0 3: 1 5:66 15:67 15: 4 15: 5 15: 6 15: 7 tx = 0 

6:64 2: 1 4: 2 14:67 14: 4 14: 5 14: 6 14: 7 tx = 1 

5:64 5:65 3: 2 13:67 13: 4 13: 5 13: 6 13: 7 tx = 2 

4:64 4:65 7:66 12:67 12: 4 12: 5 12: 6 12: 7 tx = 4 

3: 0 3: 1 6:66 11:67 31:68 11: 5 11: 6 11: 7 tx = 0 

6:64 2: 1 5:66 10:67 30:68 10: 5 10: 6 10: 7 tx = 1 

5:64 5:65 4: 2 9: 3 29:68 9: 5 9: 6 9: 7 tx = 2 

4:64 4:65 8:66 8: 3 28:68 8: 5 8: 6 8: 7 tx = 3 

3: 0 3: 1 7:66 17:67 27:68 7: 5 7: 6 7: 7 tx = 0 

6:64 2: 1 6:66 16:67 26:68 6: 5 6: 6 6: 7 tx = 1



5:64 5:65 5:66 15:67 25:68 5: 5 5: 6 5: 7 tx = 5 

4:64 4:65 4: 2 14:67 24:68 24:69 4: 6 4: 7 tx = 2 

3: 0 3: 1 8:66 13:67 23:68 23:69 3: 6 3: 7 tx = 0 

6:64 2: 1 7:66 12:67 22:68 22:69 2: 6 2: 7 tx = 1 

5:64 5:65 6:66 11:67 21:68 21:69 1: 6 1: 7 tx = 6 

4:64 4:65 5:66 10:67 20:68 20:69 20:70 0: 7 tx = 7 

3: 0 3: 1 4: 2 9: 3 19: 4 19: 5 19: 6 19: 7 tx = 0 

6:64 2: 1 3: 2 8: 3 18: 4 18: 5 18: 6 18: 7 tx = 1 

5:64 5:65 2: 2 7: 3 17: 4 17: 5 17: 6 17: 7 tx = 2 

4:64 4:65 6:66 6: 3 16: 4 16: 5 16: 6 16: 7 tx = 3 

3: 0 3: 1 5:66 15:67 15: 4 15: 5 15: 6 15: 7 tx = 0 

6:64 2: 1 4: 2 14:67 14: 4 14: 5 14: 6 14: 7 tx = 1 

5:64 5:65 3: 2 13:67 13: 4 13: 5 13: 6 13: 7 tx = 2 

4:64 4:65 7:66 12:67 12: 4 12: 5 12: 6 12: 7 tx = 4 

3: 0 3: 1 6:66 11:67 31:68 11: 5 11: 6 11: 7 tx = 0 

6:64 2: 1 5:66 10:67 30:68 10: 5 10: 6 10: 7 tx = 1 

5:64 5:65 4: 2 9: 3 29:68 9: 5 9: 6 9: 7 tx = 2 

4:64 4:65 8:66 8: 3 28:68 8: 5 8: 6 8: 7 tx = 3 

3: 0 3: 1 7:66 17:67 27:68 7: 5 7: 6 7: 7 tx = 0 

6:64 2: 1 6:66 16:67 26:68 6: 5 6: 6 6: 7 tx = 1 

5:64 5:65 5:66 15:67 25:68 5: 5 5: 6 5: 7 tx = 5 

4:64 4:65 4: 2 14:67 24:68 24:69 4: 6 4: 7 tx = 2 

3: 0 3: 1 8:66 13:67 23:68 23:69 3: 6 3: 7 tx = 0 

6:64 2: 1 7:66 12:67 22:68 22:69 2: 6 2: 7 tx = 1 

5:64 5:65 6:66 11:67 21:68 21:69 1: 6 1: 7 tx = 6 

4:64 4:65 5:66 10:67 20:68 20:69 20:70 0: 7 tx = 7 

3: 0 3: 1 4: 2 9: 3 19: 4 19: 5 19: 6 19: 7 tx = 0 

6:64 2: 1 3: 2 8: 3 18: 4 18: 5 18: 6 18: 7 tx = 1 

5:64 5:65 2: 2 7: 3 17: 4 17: 5 17: 6 17: 7 tx = 2 

4:64 4:65 6:66 6: 3 16: 4 16: 5 16: 6 16: 7 tx = 3 

3: 0 3: 1 5:66 15:67 15: 4 15: 5 15: 6 15: 7 tx = 0 

6:64 2: 1 4: 2 14:67 14: 4 14: 5 14: 6 14: 7 tx = 1 

5:64 5:65 3: 2 13:67 13: 4 13: 5 13: 6 13: 7 tx = 2 

4:64 4:65 7:66 12:67 12: 4 12: 5 12: 6 12: 7 tx = 4 

3: 0 3: 1 6:66 11:67 31:68 11: 5 11: 6 11: 7 tx = 0 

| 

| 

| 

| 











actual bus utilisation = 1.000




C-Kod för simulering av EDF-noder i CAN-nätverk 

#include 

#include 

#include 

#define max_nodes 8 

#define low_prio_base 80 

#define sparebit 64 //High or low prio 

char deadline[max_nodes] = {3,6,10,13,22,23,24,25}; 

char basic_prio[max_nodes] = {0,1,2,3,4,5,6,7}; 

char prio[max_nodes]; 

int counter[max_nodes]; 

int number_of_transmissions[max_nodes] = {0,0,0,0,0,0,0,0}; 

char over_active_node[max_nodes] = {1,1,1,1,1,1,1,1}; 

char tx_request[max_nodes] = {0,0,0,0,0,0,0,0}; 

int missed_deadlines = 0; 

long number_of_rounds = 0; 

/*********************NYA 

KONSTANTER************************************/ 

char rescent_tx[max_nodes] = {0,0,0,0,0,0,0,0}; 

/******************************************************************* 

****/ 

/******************************************************************* 

****/ 

void handle_prio(int node) 

{ 

if (counter[node] > 2*deadline[node]) 

{ 

tx_request[node] = 0; 

counter[node] = 2*deadline[node]+1; 

} 

else tx_request[node] = 1; 

if (counter[node]



// prio[node] = low_prio_base + basic_prio[node]; //basic 

idea 

// #endif 

// } 

// } 

//} 

/******************************************************************* 

****/ 

void next_round(void) 

{ 

int i,j; 

char next_to_transmit = 0; 

char earliest_deadline = 127; 

number_of_rounds++; 

for(i=0;i



float actual =0; 

float utilisation = 0; 

printf("setting up initial conditions\n"); 

printf(" nod-A nod-B nod-C nod-D nod-E nod-F nod-G nod-H 

s„ndare\n"); 

printf("-------------------------------------------------------- 

\n"); 

for(i=0;i



Appendix B Intervjuer av Rymdbolagspersonal 

Frågor 

Genom att intervjua SSC-personal måste följande frågor få svar: 

1. Framtida bandbreddsbehov 

2. Behov av redundans, parallella sändningar på flera linor med röstning eller gå över till redundant 

bus vid problem eller helt annan typ av lösning 

3. Kan det finnas anledning att endast förändra system bussen och inte payload bussen. 

4. Fysiska avstånd -kabellängder 

5. Felhantering??? Krävs det mer än det CAN erbjuder idag 

6. Feldetektion??? Idag och i framtiden? 

7. Hur övervakas nätet 

8. Robusthet??? Hur bedöms det??? 

9. Måste ACKet komma från den nod som meddelandet skall till eller kan det som i CAN komma 

från vilken som helst av noder. 

10. Önskas ett routat nät, typ Spacewire, eller är CAN-varianten att föredra 

11. Hur synkroniserade måste noderna vara 

12. Hur lång tid får det ta att skicka ett meddelande 

13. Hur är noderna programmerade, eventstyrda eller tidsstyrda med deadlines eller… 

14. Kan meddelanden skickas spontant eller skall varje meddelandetyp erhålla en tidslucka 

15. Eller skall både och tillåtas 

16. Med hur många Hz jobbar en framtida reglerloop 

17. Förekommer det olika modes med vitt skilda typer av kommunikationsmönster på rymdskeppet 

18. Vilka kända problem, ej av Bug-karaktär men som drabbar vår tillämpning, finns i dagens CAN 

och hur allvarliga är dessa 

19. Vilka kända buggar finns i CAN. 

20. Finns det ett självändamål med en fortsättning med CAN (uppgraderat till TTCAN), om så är 

fallet kan någon av punkterna ovan stryka på foten 

21. Är vissa nätverk enklare/snabbare/billigare att implementera än andra och hur mycken vikt skall 

läggas därvid 

22. Är vissa nätverk mer flyttbara (än andra nätverk)mellan olika FPGA och i såfall vilka 

23. Kan det vara viktbesparande att sända informationen i nätverket på t.ex en kraftkabel eller är detta 

en befängd idé 

Svar på frågor Sytze Veldman 

1. Bandbredd 

Systembuss: < 1 Mbps med undantag för modes då t.ex. stjärnsensor skickar hel bild eller då GPS 

skickar all möjlig information om alla GPS-satelliter. Detta förekommer sällan och behöver ej 

tilldelas, på förhand, exklusiv tillgång till bussen. 

Payloadbuss: I nuläget, i samband med STEAM-studien, 50 kbps med radiometer och optisk 

spektrograf. Kommande fas A studier på STEAM ska ge en mer detaljerad bild av instrumentens 

bandbreddsbehov. Dock kan andra instrument såsom radar eller kamera tänkas varvid trafiken 

kommer att överstiga 1 Mbps 

Länk mellan mass-minne och TMTC: >= 1Mbps för downlink av mätdata i fallet av STEAM. 

2. Redundans 

Ja, allt måste vara redundant. 

3. Förändring av endast en buss 

Ja, men inte i onödan. 

Länk mellan mass-minne och TMTC måste vara snabbare än CAN, kan tänkas integreras med 

övriga payloadbussen. 

4. Längd på kablar



Upp till 2m 

8. Acknowledge 

Säkrare med ACK från adresserad nod 

12. Noders programmering 

System t.ex. attityd är tidsstyrd 1Hz. 

Payload kan vara eventstyrd 

15. Olika modes 

Systembuss: GPS och stjärnsensor, se fråga 1. 

Payloadbuss: Sändning av mass-minnes innehåll till GS via TMTC >=1 Mbps. 

16. Kända problem med CAN-buss 

Liten bandbredd 

18. Självändamål med CAN-buss 

Ja (se svar på 23), men bandbredden kan inte kompromissas bort 

23. Allmän spridning av protokoll 

CAN är ett ”buzz-word” i branschen, det är bra. 

Allmän spridning innebär att en lösning ej behöver säljas in till kund. 

Lättare att få tag på- och, till underleverantör, tillhandahålla testutrustning. 

Lättare att specificera- samt billigare att beställa instrument till rymdfarkosten. 

Svar på frågor Bengt Holmqvist 

1. Bandbredd 

Mindre än 1 Mbps, förutom mellan mass-minne och TMTC 

2. Redundans 

Redundansen som CAN-bussen i SMART-1 erbjuder är tillräcklig. Åtminstone på linjesidan, 

dock kan det faktum att den nominella och den redundanta bussen använder samma kontroller 

ställa till problem, om just buss-kontrollern fallerar. 

3. Förändring av Payloadbuss och/eller Systembuss 

Det är inte nödvändigtvis enklare att förändra båda bussarna. Kräver endast en av bussarna 

ytterligare egenskaper kan denna ändras. 

4. Kabellängd 

Sällan över två meter. 

5. Feldetektion 

Behöver inte bli bättre än i SMART-1 

6. Felhantering 

Kan behöva förbättras. T.ex. kan idag en "babblande idiot" förstöra all kommunikation på en 

buss. Då kontrollern byter till den redundanta bussen kan den defekta noden uppfatta detta, byta 

buss även den, varvid den förstör trafiken även där. Avstängning av den defekta noden kan 

dessutom omöjliggöras då ett kommando till power-enheten, över den redan utstörda bussen, att 

stänga av den defekta noden kanske inte uppfattas . Detta kan leda till systemkollaps. 

7. Nätövervakning 

Nätet övervakas idag av kontrollern, vilket kan vara lämpligt även i framtiden då en separat 

övervakare för varje nod, vilket stöds i vissa protokoll, kan ta för mycket plats hårdvarumässigt 

sett. 

8. Acknowledge 

Spelar inte så stor roll varifrån ACK:et kommer.



9. Routat eller broadcastat nät 

Broadcastat är bättre av flera anledningar. En del meddelanden är avsedda för flera noder, mindre 

åtgång av komponenter, kan vara enklare att implementera. 

10. Synkronisering av noder 

Någonstans mellan 0.1-1 ms. 

14. Frekvens på reglerloop 

ODIN har en reglerfrekvens på 16 Hz, denna storleksordning verkar rimlig även för framtida 

projekt 

15. Olika moder 

Ja, mass-minne till TMTC 

16. Nätverkets allmänna spridning 

Mycket viktigt, förenklar implementation, testning och beställning av instrument. 

17. Överlagring av information på kraftkabel 

Kan låta intressant vid en första anblick. Dock är det alltför riskabelt med tanke på potentiella 

kortslutningar m.m. Den eventuella viktbesparingen skulle antagligen ätas upp av de 

skyddsåtgärder som krävs. 

Svar på frågor Gunnar Andersson 

1. Bandbredd 

1-2 Mbps för telemetrin 

2. Redundans 

Sändning över två linor 

3. Förändring av endast en buss 

Endast en buss kan förändras, men även hopslagning är möjlig 

4. Fysiska avstånd 

< 5m 

5. Feldetektion 

Viktigt att kunna identifiera babbling idiots… 

6. Felhantering 

…och kunna stänga av dem 

7. Övervakning 

Idag: Platform supervisor tittar på health-meddelanden 

8. ACK:et 

Då noderna pollas idag, spelar detta ingen större roll 

9. Routat eller Broadcastat nät 

Broadcast medger enkel avlyssning 

10. Synkronisering 



21. Stor fördel med samma elektriska interface som CAN 

Nej, egentligen inte 

23. Är allmän spridning viktig 

Ja, jätteviktigt. Lättare att hitta folk och utrustning 

24. Information på kraftkabel 

Befängd idé, då olika kraftnät används



Appendix C VHDL-kod i CAN-shell 

Transmission_State_Machine 

--------------------------------------------------------------------------- 

-- Entity declaration of 'Transmission_State_Machine'. 

--------------------------------------------------------------------------- 

LIBRARY ieee, synplify ; 

USE ieee.std_logic_1164.all ; 

USE ieee.std_logic_arith.all ; 

USE ieee.std_logic_unsigned.all ; 

USE synplify.attributes.ALL ; 

ENTITY Transmission_State_Machine IS 

PORT( 

LOAD_SHIFT_REG : OUT std_ulogic_vector(12 DOWNTO 0) ; 

TX_REQUEST : OUT std_ulogic ; 

Clk : IN std_logic ; -- Clock 

Reset_n : IN std_logic ; -- Reset 

LOAD_ENABLE : IN std_ulogic_vector(1 DOWNTO 0) ; 

New_Frame_Tx : IN std_logic ; 

TRANSMITTER : IN std_ulogic ; 

TX_COMPLETE : IN std_ulogic ; 

Tx_Buffer_Empty : OUT std_logic ; 

BUSOFF_EVENT : IN std_logic ; 

INIT : OUT std_ulogic ; 

INIT_Request : IN std_logic ; 

BUSOFF : IN std_logic ; 

Message_Lost : OUT std_logic ; 

ID_Bit_28 : OUT std_ulogic ; 

PRIO : IN std_logic_vector(4 DOWNTO 0) := "00100" ) ; 

END ENTITY Transmission_State_Machine ; 

--------------------------------------------------------------------------- 

-- Architecture 'a0' of 'Transmission_State_Machine' 

--------------------------------------------------------------------------- 

ARCHITECTURE a0 OF Transmission_State_Machine IS 

-- State Machine Options: 

-- State assignment : Gray code. 

-- State decoding : Case construct. 

-- Actions on transitions: Combinational. 

-- Actions on states : Combinational. 

CONSTANT Configure : std_logic_vector(3 DOWNTO 0) := "0000" ; 

CONSTANT Idle : std_logic_vector(3 DOWNTO 0) := "0001" ; 

CONSTANT Check_Load_Status : std_logic_vector(3 DOWNTO 0) := "0011" ; 

CONSTANT Sending_Or_Receiving : std_logic_vector(3 DOWNTO 0) := "0010" ; 

CONSTANT Load_Register : std_logic_vector(3 DOWNTO 0) := "0110" ; 

CONSTANT Request_Transmission : std_logic_vector(3 DOWNTO 0) := "0111" ; 

CONSTANT Check_Bus_Off : std_logic_vector(3 DOWNTO 0) := "0101" ; 

CONSTANT Initialisation : std_logic_vector(3 DOWNTO 0) := "0100" ; 

CONSTANT Counter_addition : std_logic_vector(3 DOWNTO 0) := "1100" ; 

SIGNAL cur_state : std_logic_vector(3 DOWNTO 0) ; -- Current State 

SIGNAL next_state : std_logic_vector(3 DOWNTO 0) ; -- Next State



SIGNAL LOAD_SHIFT_REG_INT : std_ulogic; 

shared variable Counter : std_logic_vector(6 DOWNTO 0); 

shared variable check : bit := '1'; 

BEGIN 

LOAD_SHIFT_REG '1') WHEN LOAD_SHIFT_REG_INT='1' ELSE 

(OTHERS=>'0'); 

next_state_decoding: PROCESS (cur_state, LOAD_ENABLE, New_Frame_Tx, 

TRANSMITTER, TX_COMPLETE, BUSOFF_EVENT, INIT_Request, BUSOFF) IS 

BEGIN 

next_state



END IF ; -- Global transition 

END PROCESS next_state_decoding ; 

state_transition: PROCESS (Clk, Reset_n) IS 

BEGIN -- State transition 

IF (Reset_n='0') THEN 

cur_state



IF Counter



Message_Lost



SEND_IDENTIFIER



Appendix D VHDL-kod för test 5.1 och 6.1 

when 51 => -- Test 5.1 

-- After reset 

wait for 0 ns; 

LOAD_ENABLE '1', 

INIT_exp => '1', 

Message_Lost_exp => '1' 

); 

wait until clk_int = '1'; 

-- Step 3) 

Compare_Outputs( 

Tx_Buffer_Empty_exp => '1' 

); 

losing_arbitration; 

re_win_arbitration; 


for J in 0 to 18 loop 

re_losing_arbitration; 

end loop; 






-- Step 17) 

ID_Field_Standard_Tx



SEND_CONTROL_exp => Frame_Type_Tx_c2(0) & NOT Frame_Type_Tx_c2(1) & 

Data_Length_Tx_c2, 

SEND_DATA_exp => Data_Field_Tx_c2 

); 

WAIT UNTIL clk_int='1'; 

-- Step 19) 


LOAD_SHIFT_REG_exp => "1111111111111", 

SEND_IDENTIFIER_exp => ID_Bit_28 & ID_Field_Standard_Tx_c2 & 

ID_Field_Extended_Tx_c2, 




); 


-- Step 20) 


TX_REQUEST_exp => '1', 






); 

WAIT ON LOAD_SHIFT_REG, TX_REQUEST, Tx_Buffer_Empty, INIT, Message_Lost, 

SEND_IDENTIFIER, 

SEND_CONTROL, SEND_DATA FOR 8*period; 


TX_REQUEST_exp => '1', 






); 







); 

-- Step 22) 








); 

WAIT ON LOAD_SHIFT_REG, TX_REQUEST, Tx_Buffer_Empty, INIT, Message_Lost, 

SEND_IDENTIFIER, 

SEND_CONTROL, SEND_DATA FOR 10*period;









); 

LOAD_ENABLE ID_Bit_28 & ID_Field_Standard_Tx_c2 & 





); 



LOAD_SHIFT_REG_exp => "1111111111111", 






); 

REPORT "************** Test Result ***************"; 

IF Test_OK = '0' THEN 

REPORT "Test 5.1 Failure"; 

ELSE 

REPORT "Test 5.1 Success"; 

END IF; 

REPORT "********** End of test 5.1 ***************"; 

Disable_Clock -- Test 6.1 

-- After reset 

wait for 0 ns; 


INIT_exp => '1', 

Message_Lost_exp => '1' 

); 


-- Step 3) 


Tx_Buffer_Empty_exp => '1' 

); 




re_win_arbitration;





wait for 10*period; 


START_OF_FRAME

Untitled - MRTC

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?