Onboard computers and software standards - stuba.sk · · 2017-04-06Onboard computers and...

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


• 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


• Power consumption

• Price / capability

• Safety and continuous operation (reliability)

– Hardware redundancy

– Radiation Hardening

• Weight and dimensions

• Performance • (MIPS, Data storage)

Onboard Computer parameters

4


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


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


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


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


Hardware Static vs Dynamic architecture

9

Static CMOS Dynamic CMOS


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


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


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


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


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


Hardware redundancy skCube Coldswap example

15


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


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


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


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


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


20


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


21


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


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


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


Software Simple RTOS

25


Software Boot sequence example

26


Software Cooperative multitasking

27


Software Cooperative multitasking

28


Software Stack Monitoring

29


Software Stack Monitoring

30


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


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


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


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


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


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


Software FMFA Analysis example

37


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


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


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


41

Thank you for you attention

Onboard computers and software standards - stuba.sk · · 2017-04-06Onboard computers and...

Documents

Transcript of Onboard computers and software standards - stuba.sk · · 2017-04-06Onboard computers and...