how NASA writes space-proof code

learn to code in C at lowlevel.academy/ ! 😎

It is very similar with the rules used in the embedded development for automotive industry.

I am a software engineer working on the mars helicopter with JPL. Most of these concepts are already familiar to me, but a couple are new as well. The ban on using heap memory is one that I very strongly adhere to and a lot of new embedded developers are often surprised by. When the IDE supports it, I set the heap size to 0 right away.

rule nr. 11: always annotate the unit of measurement wherever applicable. private aerospace contractors could otherwise introduce imperial units into your code without noticing 🙈

That's honestly how almost all embedded code should be written. The code base I worked on recently (inherited from another company), breaks almost every single of these rules, it's a miracle it doesn't crash more often

I went to college in Huntsville Alabama where a lot of the aerospace engineering companies are contracted for NASA so many of my computer science professors had worked on live code for many major space projects like the James Webb Space Telescope. They used a lot of Ada and Fortran. Ada because it's so strict on typing and helps eliminate many mistakes, and Fortran because the routines and functions have been tested for decades to eliminate any bugs. They have to know everything in the code is deterministic and will never deviate from the designed logic.

I would also add, when an error occurs in your code, error recovery should bring back the code in a "predictable state".

On additional issue with heap usage is memory fragmentation. Repeated allocation and freeing of different sized blocks of memory can leave gaps of free memory between allocated chunks that are too small to be used in any following allocations. This memory is effectively lost until the program restarts. Usually there is a cyclical pattern to allocations that generates more and more of these gaps the longer the program runs. Normally this is not a big issue, but when your program runs continuously for years without restart, these unusable gaps can slowly accumulate until you run out of memory.

No need to use pointers and recursion, that's the dream job

When dealing with extreme scenarios is necessary to implement extreme measures. Not feasible on regular projects however it is a rock solid approach for coding.

00:00 Introduction 00:44 #01 Simple Control Flow 01:08 #02 Limit All Loops 01:40 #03 Don't use the Heap 02:15 #04 Limit Function Size 03:01 #05 Practice Data Hiding 03:27 #06 Check Return Values 04:17 #07 Limit the Preprocessor 04:57 #08 Restrict Pointers Use 05:33 #09 Be Pedantic 05:47 test test test 05:55 Interaction Reminder

I'm an electronics engineer at NASA GSFC. As a hardware guy, I am not familiar with the software design standards, but these that you list in this video seem to be functionally similar to the ones I experience in electronics design, in that, they are aimed at making the sure the system is reliable beyond a shadow of a doubt. Given we work on space systems, it would obviously be catastrophic to have an undetected failure or bug show up mid-flight. One example of a relevant electronics design standard, would be our part derating. All electronic components that are bound for spaceflight, must have their maximum power/voltage/current requirements derated to some level below what the manufacturer states. Ceramic capacitors, for example, must have their maximum voltage derated to half the manufacturers level. So if we have a ceramic capacitor that is rated for 10 volts by the manufacturer, then we are only allowed to apply 5 volts maximum across it as part of our design process. This helps guarantee reliability and the lifetime of the mission.

I love how for every rule, you give the most palatable example that also best illustrates what the problem with not using the rule is. And you got through this in 6 minutes 🤯 Bravo!

They call it the Power of Ten, but only 9 are listed. #10 - Off-by-one errors 😀

1. Simple Control Flow - don't use goto, setjmp, longjmp, recursion 2. Limit All Loops - hard limit the number of iterations in all loops 3. Don't Use the Heap - use only stack memory, don't use malloc or free 4. Limit Function Size - function should be no longer than 60 lines 5. Practice Data Hiding - declare variables in the lowest scope required 6. Check Return Values - explicitly cast all ignored return values to a void type 7. Limit the Preprocessor - limit the use of the C preprocessor to file inclusions and very simple conditional macros, don't use conditional compilation 8. Restrict Pointers Use - pointers should not be able to be dereferenced more than one layer at a time, also don't use function pointers 9. Be Pedantic - compile with all warnings enabled and in pedantic mode, analyze the code with multiple static code analyzers with different rulesets, also unit test the code

A colleague of mine worked on VxWorks for many years writing OS code - it's the operating system that the mars rover uses. It's quite fun hearing about his stories. Apparently there was a bug in the code for the rover, but he determined it wasn't an OS bug but rather the programmers at NASA who had introduced it ;)

1:58 Another classic problem of using the heap is that it makes the code non-deterministic, because the base locations of, well, everything, change from run-to-run.

Sounds like sound advice. Making a medical thingy nowadays and since we've decided to have MISRA shout at us we're compliant with most of these rules :) Very annoyed at GCC not enabling all warnings with `-Wall` or even with `-Wextra`. A buuunch of extra warnings to enable.

Something in embedded systems that generally doesn't come up when creating normal programs, and that I was very fascinated to discover, is the watchdog timer. A "wdt reset" instruction is periodically placed in the code in non-looping sections (hence the upper limit on loops), places where the execution is expected to revisit if things are fine. If the execution gets stuck anywhere, the wdt isn't reset, and once the timer runs out, it reboots the device. Pulling it out of the potential softlock

All of these things are valid in aeorspace and automotive. Safety is the first principal for the code development in these areas. Interesting thing is whenever you apply for a job they ask you recursion :D