Upload
trinhhuong
View
215
Download
1
Embed Size (px)
Citation preview
Onboard computers and software standards Space for Education, Education for Space
Space for Education, Education for Space ESA Contract No. 4000117400/16NL/NDe
Specialized lectures
Onboard computers and software standards
Juraj Slačka
Onboard computers and software standards Space for Education, Education for Space
• Onboard Computers in general
• Hardware – Key concepts of hardware design and testing
– Chip architectures
– Multi computer systems
• Software – Programming languages
– Operating systems
– Software development and testing, safety standards
– Glitches and bugs in space software
Content
2
Onboard computers and software standards Space for Education, Education for Space
• Assistance with computationally intensive tasks
• Continuous monitoring
• Display necessary data and
alarms
• Automatic safety functions
• Radio communication
• Command system
• Data storage and handling
Main functions of Onboard Computers
3
CubeSat Onboard Computer
Onboard computers and software standards Space for Education, Education for Space
• Power consumption
• Price / capability
• Safety and continuous operation (reliability)
– Hardware redundancy
– Radiation Hardening
• Weight and dimensions
• Performance • (MIPS, Data storage)
Onboard Computer parameters
4
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Design is dependant on mission – LEO, Deep Space, Cubesat
• Biggest concern is reliability – Electronic failure – Radiation (van Allen Belts)
• <20KRad per year on LEO
• Power usage • Heat dissipation • Computational power
– FPU? – MMU?
• Price
Main design problems
5
Van Allen Belts
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Soft Error
– Upset in data which is temporary
– In planes Soft Error is 300 times more likely than in computers on ground
– Every 1km above sea level Soft Error possibility increases by factor 2.2
– Caused by radiation, noise, inductive and capacitive crosstalk
• Hard Error
– Permanent damage in hardware
Error types
6
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Radiation hardening – Hardware protection against soft and hard errors is usually
done by radiation hardening – Usually it is done by increasing capacitance at selected
circuit nodes – It is often accomplished by increasing the size of transistors – This technique is often applied selectively to nodes which
have highest probability to encounter a soft error. – Expensive
• Commercial of the shelf – Non radiation hardened components used in industrial
grade electronics – Often used in low budget missions like CubeSats
CTOS vs Radiation hardened
7
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Dynamic CMOS – Better performance – Higher power consumption – Needed clock signal – N+2 transistors – ½ lower radiation hardness compared to static CMOS
• Static CMOS – Lower power consumption – 2N transistors => bigger die – Higher capacitance => slower speed – Better radiation hardness – Problem to find fully static CMOS chip in CTOS market
Chip technology
8
Onboard computers and software standards Space for Education, Education for Space
Hardware Static vs Dynamic architecture
9
Static CMOS Dynamic CMOS
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Biggest concern is data corruption and storage malfunction
• PROM
– Uses diodes or fuses
– Reliable
– Mostly used for bootloader
• Core rope memory (LOL)
– Heavy and big dimensions
– Hard to program (impossible for modern software)
Data storage
10
Onboard computers and software standards Space for Education, Education for Space
Hardware
• FRAM
– High radiation resistance
– Only small size commercially available
– Write/Read access as a RAM but volatile
• Flash Memory
– Used in many applications
– Better than EEPROM
– Charge pump is sensitive
– Block corruption
Data storage
11
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Hardware – ECC hardware
– Dual/Triple backup
– Radiation hardening
– Parity
• Software – Parity
– Bit inverted code
– Software ECC (Reed-Solomon)
– CRC, Checksums
Data storage protection
12
Onboard computers and software standards Space for Education, Education for Space
Hardware redundancy
• Three or more computers are performing the same task
– Majority result is considered as correct
– Computers with “bad” result have to reboot
– Task can continue after reboot of all “bad” Computers
• Space X
– Uses this technique incorporating 5 computers
– If two of them fail, the system can still operate
– No need to wait for “bad” computer to perform reboot
Voting system
13
Onboard computers and software standards Space for Education, Education for Space
Hardware redundancy
• Hot swap
– Less power efficient (both CPUs are running in parallel)
– Swap can be done without glitch
– Used in most critical/time critical applications
• Cold swap
– Power efficient (only one CPU at a time)
– Swap causes jitter. Time is needed to wake CPU up
– Used in critical but not real time applications
CPU Swap
14
Onboard computers and software standards Space for Education, Education for Space
Hardware redundancy skCube Coldswap example
15
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Proper algebraic operations have to be chosen in terms of optimization (qaternions instead of goniometric, etc.)
• Consumption on
load
Electrical and performance testing
16
Onboard computers and software standards Space for Education, Education for Space
Hardware
• Testing was done on medical X-ray
• Testing of critical components:
– ALU, Registers, Ram, Flash, I2C and SPI buses
– Testing was done every 2s
– The results were transfered via UART bus
Radiation testing
17
Onboard computers and software standards Space for Education, Education for Space
Software
• When considering single upset events, it is harder to protect program instructions than data.
• Program protection can be done in different ways:
– Hardware or software Lock step execution
– Hardware watchdog timers
– Periodic checksum check
– Bit inverse code
– Block program organization
Program protection
18
Onboard computers and software standards Space for Education, Education for Space
Software
• C and C++
– They were not specifically designed for this type of application
– Core run time libraries are well documented, understood and are relatively simple to use
– Lot of tool chains for different hardware architecture
– As a High level programming language it is still close to hardware (compared to python, matlab, java)
Programming languages
19
Onboard computers and software standards Space for Education, Education for Space
Software
• ADA and Spark
– Mostly used in aerospace applications
– Object oriented high level language extended from Pascal
– Targeted on embedded and real time systems
– Strong type language with runtime error detection, parallel processing (tasks) and message passing
– Allows garbage collection – but mostly it is not supported by default
Programming languages
20
Onboard computers and software standards Space for Education, Education for Space
Software
• ADA and Spark
– Ada has language support for task-based concurrency
– Ada type system is not based on a set of predefined primitive types but allows users to declare their own types:
• type Day_type is range 1 .. 31;
• type Year_type is range 1800 .. 2100;
• type Hours is mod 24;
• type Weekday is (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday);
Programming languages
21
Onboard computers and software standards Space for Education, Education for Space
Software
• For most applications jitter is critical
• Soft or hard real time operating systems
• Safety critical
• NASA JPL uses WxWorks (Spirit, Curiosity)
• SpaceX uses modified Linux
Operating systems
22
Margaret Hamilton, foto NASA
Onboard computers and software standards Space for Education, Education for Space
Software
• Not all operating systems use MMU => micro kernels compiled together with applications
• Preemption often causes problems (atomic operations)
• In skCube we have designed simple cooperative preemptive real time operating system build from scratch
Operating systems
23
Margaret Hamilton, foto NASA
Onboard computers and software standards Space for Education, Education for Space
Software
• Fully preemptive real time operating system
• Cooperative mode
• Scheduler is running in Lock step mode
• Only one static pointer which is known during compilation
• Single stack is used for all tasks
• Stack is static with permanent size
• Kernel + Drivers + One task <1KB
• Fully Misra C compatible
skCube RTOS
24
Onboard computers and software standards Space for Education, Education for Space
Software Simple RTOS
25
Onboard computers and software standards Space for Education, Education for Space
Software Boot sequence example
26
Onboard computers and software standards Space for Education, Education for Space
Software Cooperative multitasking
27
Onboard computers and software standards Space for Education, Education for Space
Software Cooperative multitasking
28
Onboard computers and software standards Space for Education, Education for Space
Software Stack Monitoring
29
Onboard computers and software standards Space for Education, Education for Space
Software Stack Monitoring
30
Onboard computers and software standards Space for Education, Education for Space
Software
• Commands are executed as simple precompiled programs in sequence usually without program flow control or loops
• In skCube a single command has size of 23Bytes – 100,2,>,15,vysun_anteny,0,0,0,0
Command Handling
31
Onboard computers and software standards Space for Education, Education for Space
Software
• In commercial application safety critical certification is very expensive
• Space industry safety critical guidelines (like NASA JPL C coding guideline) developed from automotive industry
• Vide use of Misra C standard (Motor Industry Software Reliability Association)
• To improve software reliability against radiation bit-flips a simple bit inverted storage method is often used
Safety critical
32
Onboard computers and software standards Space for Education, Education for Space
Software
• Few NASA JPL C Guideline examples:
– Restrict all code to very simple control flow constructs. Do not use GOTO statements, setjmp or longjmp constructs, or direct or indirect recursion.
– All loops must have a fixed upper bound. It must be trivially possible for a checking tool to statically prove that a preset upper bound on the number of iterations of a loop cannot be exceeded.
– Do not use dynamic memory allocation after initialization.
Safety critical
33
Onboard computers and software standards Space for Education, Education for Space
Software
• Few NASA JPL C Guideline examples:
– The use of pointers should be restricted.
– Preprocessor use must be limited to the inclusion of header files and simple macro definitions.
– All code must be compiled, from the first day of development, with all compiler warnings enabled at the compiler’s most pedantic setting. All code must compile with these setting without any warnings.
Safety critical
34
Onboard computers and software standards Space for Education, Education for Space
Software
• Critical parts of software could be run in lock-step mode. In our RTOS design we run scheduler in lock-step
• Vide use of standard SAE ARP 4761 – FMEA and FTA analysis
• Vide use of military standards – fe. MIL-STD 1553
• All software must pass through Static analysis
– For example PC Lint software with MISRA C
• All software must pass through Unit testing
Safety critical
35
Onboard computers and software standards Space for Education, Education for Space
Software
• MIL-STD-1553 (1973)
– Military standard for electrical, mechanical and functional characteristics of serial bus
– Firstly used in F-16 Falcon fighter aircraft (F-18 Hornet and F-15 Eagle)
– Speed of 1Mbit/s
– Uses Manchester code
– Easily galvanically isolated by using network isolator
Safety critical
36
Onboard computers and software standards Space for Education, Education for Space
Software FMFA Analysis example
37
Onboard computers and software standards Space for Education, Education for Space
Software 1202 program alarm
38
• During Apollo 11 moon landing was a program alarm
• The computer was overloaded with data
• Basic task priority scheduler allowed astronauts to continue moon landing
DsKy, foto NASA
Onboard computers and software standards Space for Education, Education for Space
Software Spirit software bug
39
• Because of rushed development there was a DOS related software bug
• No telemetry was received (only Beep that the rover is alive)
• On right is first picture from Spirit after memory malfunction
Spirit on Mars, foto NASA
Onboard computers and software standards Space for Education, Education for Space
Software Ariane V bug
40
• Integer overflow destroys cluster of 4 satellites
• After launch the guidance computer tried to convert 64 bit float to 16bit signed integer which caused an overflow
Ariane V payload, foto ESA
Onboard computers and software standards Space for Education, Education for Space
41
Thank you for you attention