Onboard computers and software standards Juraj Slačka

Space for Education, Education for Space ESA Contract No. 4000117400/16NL/NDe

Specialized lectures Onboard computers and software standards Space for Education, Education for Space Content

• 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

Onboard computers and software standards 2 Space for Education, Education for Space Main functions of Onboard Computers

• Assistance with computationally intensive tasks • Continuous monitoring • Display necessary data and alarms • Automatic safety functions • Radio communication • Command system

• Data storage and handling CubeSat Onboard Computer

Onboard computers and software standards 3 Space for Education, Education for Space Onboard Computer parameters

• Power consumption • Price / capability • Safety and continuous operation (reliability) – Hardware redundancy – Radiation Hardening • Weight and dimensions • Performance • (MIPS, Data storage)

Onboard computers and software standards 4 Space for Education, Education for Space Hardware Main design problems • 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 Van Allen Belts

Onboard computers and software standards 5 Space for Education, Education for Space

Hardware Error types • 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

Onboard computers and software standards 6 Space for Education, Education for Space Hardware CTOS vs Radiation hardened • 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

Onboard computers and software standards 7 Space for Education, Education for Space Hardware Chip technology • 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

Onboard computers and software standards 8 Space for Education, Education for Space Hardware Static vs Dynamic architecture

Static CMOS Dynamic CMOS

Onboard computers and software standards 9 Space for Education, Education for Space Hardware Data storage • 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)

Onboard computers and software standards 10 Space for Education, Education for Space Hardware Data storage • 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

Onboard computers and software standards 11 Space for Education, Education for Space Hardware Data storage protection • Hardware – ECC hardware – Dual/Triple backup – Radiation hardening – Parity • Software – Parity – Bit inverted code – Software ECC (Reed-Solomon) – CRC, Checksums

Onboard computers and software standards 12 Space for Education, Education for Space

Hardware redundancy Voting system • 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

Onboard computers and software standards 13 Space for Education, Education for Space Hardware redundancy CPU Swap • Hot swap • Cold swap – Less power efficient – Power efficient (only (both CPUs are running one CPU at a time) in parallel) – Swap causes jitter. Time – Swap can be done is needed to wake CPU without glitch up – Used in most – Used in critical but not critical/time critical real time applications applications

Onboard computers and software standards 14 Space for Education, Education for Space Hardware redundancy skCube Coldswap example

Onboard computers and software standards 15 Space for Education, Education for Space Hardware Electrical and performance testing • Proper algebraic operations have to be chosen in terms of optimization (qaternions instead of goniometric, etc.) • Consumption on load

Onboard computers and software standards 16 Space for Education, Education for Space Hardware Radiation testing • 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

Onboard computers and software standards 17 Space for Education, Education for Space Software Program protection

• 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

Onboard computers and software standards 18 Space for Education, Education for Space Software Programming languages

• 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)

Onboard computers and software standards 19 Space for Education, Education for Space Software Programming languages

• 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

Onboard computers and software standards 20 Space for Education, Education for Space Software Programming languages

• 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);

Onboard computers and software standards 21 Space for Education, Education for Space Software Operating systems • 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

Margaret Hamilton, foto NASA

Onboard computers and software standards 22 Space for Education, Education for Space Software Operating systems • 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 Margaret Hamilton, foto NASA

Onboard computers and software standards 23 Space for Education, Education for Space Software skCube RTOS • 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

Onboard computers and software standards 24 Space for Education, Education for Space Software Simple RTOS

Onboard computers and software standards 25 Space for Education, Education for Space Software Boot sequence example

Onboard computers and software standards 26 Space for Education, Education for Space Software Cooperative multitasking

Onboard computers and software standards 27 Space for Education, Education for Space Software Cooperative multitasking

Onboard computers and software standards 28 Space for Education, Education for Space Software Stack Monitoring

Onboard computers and software standards 29 Space for Education, Education for Space Software Stack Monitoring

Onboard computers and software standards 30 Space for Education, Education for Space Software Command Handling • 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

Onboard computers and software standards 31 Space for Education, Education for Space Software Safety critical • 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

Onboard computers and software standards 32 Space for Education, Education for Space Software Safety critical • 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.

Onboard computers and software standards 33 Space for Education, Education for Space Software Safety critical • 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.

Onboard computers and software standards 34 Space for Education, Education for Space Software Safety critical • 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

Onboard computers and software standards 35 Space for Education, Education for Space Software Safety critical • 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

Onboard computers and software standards 36 Space for Education, Education for Space Software FMFA Analysis example

Onboard computers and software standards 37 Space for Education, Education for Space Software 1202 program alarm • During Apollo 11 moon landing was a program alarm • The computer was overloaded with data • Basic task priority scheduler allowed astronauts to DsKy, foto NASA continue moon landing

Onboard computers and software standards 38 Space for Education, Education for Space Software Spirit software bug • 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 39 Space for Education, Education for Space Software Ariane V bug • 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 Ariane V payload, foto ESA overflow

Onboard computers and software standards 40 Space for Education, Education for Space Thank you for you attention

Onboard computers and software standards 41 Space for Education, Education for Space