Why Satellites Are Programmed Differently

We Are Doomed!Most engineers never consider the weight of the firmware in their designs.  You probably are saying to yourself: “Firmware doesn’t weigh anything!”  In fact, you are wrong.

There is probably no application to which this is more important than the satellite industry.  With payloads costing $20 – $40 per gram to launch into Earth orbit the weight of firmware becomes an enormously important part of the cost of putting a satellite into orbit.

Amplify this by the fact that a growing number of hardware-based functions are being replaced by their firmware equivalents, and by the fact that modularized firmware is being used to replace smaller hand-tuned subroutines with larger general-purpose routines, and you find that the number of ones and zeros in the average satellite is ballooning at a rate of more than ten times per year.

Is this bad?  In this blog post The Memory Guy will put some numbers around the issue.

Firmware is stored as ones and zeros.  In flash memory or DRAM these ones and zeros are stored either by adding electrons onto the plate of a capacitor or by leaving electrons off of that capacitor plate.  (SRAM is different, since the electrons simply shift from one side of the cell to the other, which may impact the satellite’s balance, but that’s a different issue.)

These electrons have weight, and weight is of the utmost importance in a satellite launch.

How many electrons are we talking about?

TLC on a 15nm NAND flash process uses a minimum of 10 electrons to store a single bit.  A 128Gb NAND (which is really 2^37 or 137 billion bits) would then (with all ones) have about 10×137*10^9=1.37*10^12 electrons, not including the extra bits used for ECC.  These ECC bits add about 12% to that total.

3D NAND has more electrons per cell than does planar flash, so it’s worse, as are older generations of NAND with their larger floating gates.  Although space programs are generally known to shy away from newer technologies, in this aspect they tend to seek flash chips built using newer, smaller process nodes simply to reduce the number of extra electrons that need to be lifted into orbit.

Let’s look at the numbers.  An electron weighs about 0.00054 amu (Atomic Mass Units).  In comparison, protons are 1,837 times more massive than electrons with a weight of about one amu or 1.066 x 10^-24 grams.  These numbers can add up significantly when talking about the 16 billion bytes contained in a single 128Gb NAND flash chip.

What are space agencies doing to address this issue?  “We have tried to encourage our coders to write programs that compile to the fewest possible number of ones, but this has proven to be an extraordinarily daunting task.” said scientist Joe Snietzelberg, on condition of anonymity.  “Even worse, they need to consider whether their code will increase the number of ones stored in the ECC bits.”

Making things even more challenging is the fact that certain sequences of bits in MLC or TLC consume more electrons than others, increasing a bit’s weight depending upon the placement of the ones and zeros.  For example, while a binary 001 in TLC requires only about ten electrons, a 010 requires twenty, and a 100 requires forty, even though each of these numbers consists of a single one and two zeros.  The weight of a piece of code can be cut in half, or even a quarter, by assuring that the ones fall into locations that use the fewest electrons.

To address this issue space programs have adopted programming standards aimed at reducing the number of ones sent into space, and assuring that those ones are in bit locations that economize on the number of electrons used, and that he ECC generated by those bit sequences doesn’t offset the savings the programmers realized through other coding efficiencies.

Special compilers and libraries help programmers to achieve this goal, but an extraordinary level of training is also required.  This all falls on top of the need to code for reliability, further complicating the programmer’s job.

The problem will abate once an emerging memory technology displaces NAND flash, but these technologies haven’t been getting enough market acceptance to reach that point.

By this time next year Objective Analysis expects to see significant progress in this vein, and we hope to, once again, wish our readers a happy April Fool’s Day.

2 thoughts on “Why Satellites Are Programmed Differently”

  1. You had me there for a minute. But no doubt compact software/firmware that runs on compact (and lighter) hardware is a design consideration for these guys.

  2. All joking aside profiling and optimizing your Code makes sense.

    If your Program can execute a few times faster in less Memory you’re saving a buck across the board; size, weight, electricity, fuel, etc.

    A faster answer or an extra hour of electricity could save your life once every decade or two.

    Your story fell a bit apart when you got to the part about the “satellite’s balance” – since it would only be off a bit. 😉

Comments are closed.