32
$\begingroup$

In a previous question, I learned that the JWST's solid state recorder (SSR) can hold at least 58.8 Gbytes of recorded science data. Which each day requires two, 4 hour downlinks with earth to empty its data buffers. In another question, I learn that the spacecraft's storage could fill up in as little as 160 minutes.

I'm curious to why the designers chose to give this $10 billion state-of-the-art satellite such a small amount of storage space?

I'm asking because I'm assuming there might be times where a transmission doesn't complete in its scheduled timeframe or where it might miss a day due to ground control issues. Or even a time where it has to stop collecting data and wait for its downlink window b/c the disk is full.

Wouldn't the spacecraft be more future-proof if it had a larger data buffer, so it also isn't affected by any "disk" sectors that have gone bad during its operation?

Or is there something I'm not considering, like a design constraint perhaps?

$\endgroup$
15
  • 63
    $\begingroup$ As an Old, the idea that 60GB of solid state storage would be considered "so small" is alternately hilarious and depressing. $\endgroup$ – Russell Borogove Jan 31 at 2:38
  • 24
    $\begingroup$ No, 2600 of your photos. $\endgroup$ – Russell Borogove Jan 31 at 2:56
  • 7
    $\begingroup$ Solid state disks have a lot of “extra” capacity built in, for wear levelling and for replacing blocks which fail - the larger the “rated” size of the storage unit, the more “extra” capacity it has. For something as critical as this, it wouldnt surprise me if the actual capacity was a lot more than double the “rated” capacity, given the expected lifetime of the telescope, its working environment, usage cycles etc. If you wanted to up the “rated” capacity, you will also want to up the redundant capacity as well. I need to research some specifics here. $\endgroup$ – Moo Jan 31 at 6:39
  • 4
    $\begingroup$ @GabrielFair JWST contract was awarded in 2003. TESS contract award was 2013, a decade later. So, TESS has much more up-to-date tech. TESS is approaching three years in space, JWST remains on the ground. Go figure. $\endgroup$ – John Doty Jan 31 at 16:28
  • 17
    $\begingroup$ @GabrielFair, your phone's storage isn't radiation-hardened. Put it on the JWST, and odds are it'll fail before the telescope even gets into position. $\endgroup$ – Mark Jan 31 at 20:11
52
$\begingroup$

Best Technology Available

By late 2002, SSDs had just reached ~80 GB capacities. Of course, JWST is not going to take a product which has never seen enterprise deployment, and plonk it into \$2 billion platform with fingers crossed, hoping the vendor did a really good job. The bleeding edge referred above is for terrestrial, consumer-grade drives. Once we factor in radiation hardening for space usage, existing product history for confidence, and whatever additional redundancy mission designers chose to hedge their $2+ billion toy for its 5-10 year lifetime, 68 GB starts to look pretty reasonable.

Timeline

Yes, it took 10 years to go from MB to GB, and another 10 to go from GB to TB. So by 2010, we already had TB standalone drives (not arrays) in a COTS 3.5" SATA form factor. But by 2007, the JWST had already passed most of the core reviews, so technology had to have been chosen years prior, using whatever was available then. By 2006, NASA had already shelled out $1 billion on the project. The prime contract was awarded in 2003. It is not hard to imagine that the data storage technology was selected within a year or two of this point in time, given that they had already burned through a billion dollars in development just 3 years later.

If we were to redesign JWST right now, we could choose something like Mercury's 440 GB space-qualified RH3440. This is bleeding-edge technology, and it's not even 1 TB. Also note that it uses more "primitive" Single-Level Cell NAND technology, rather than high-density Quad-Level Cells. Obviously, this is for robustness and part of what makes it space-qualified. This is why you cannot compare consumer-grade and space-grade products on a level basis. Obviously, we could put a few of these in the JWST, and get over 1 TB of storage, but I would imagine that putting a more than dozen of them on board would push size and power constraints. So let's say we could get up to 6 TB of storage for JWST 2.0, 2021 edition.

The exponential growth of SSD density has followed an approximate ratio of 1000x per 10 years. Rewind 10 years to 2011, and we would expect to plop a mere 6 GB on board using the cutting-edge space tech available at the time. Go back 17 years to 2003-4, and the fact that it has 60+ GB of SSD storage is actually looking pretty remarkable, given that we would extrapolate it to maybe 60 MB (space-grade!!!). There may be well more than a dozen discrete drives on board JWST (can't find design details at that level of granularity).

The real question is not: "Why is there so little storage?" but rather: "How did they get so much on board?" Perhaps they were allowed to cheat and update the storage later in the design process to newer but still mature technology. The Critical Design Review, which I imagine cemented a lot of decisions into stone, occurred in 2010. If they got to harvest 6-7 years of advances, that could explain a 100x improvement over expected capacities.

$\endgroup$
7
  • 2
    $\begingroup$ Which just goes to show that it would have been nice to design in a "plug & play" system that could easily accommodate larger memory units. So it goes. (see also 32-bit vs. 64-bit operating systems, and so on) $\endgroup$ – Carl Witthoft Feb 1 at 18:33
  • 3
    $\begingroup$ @CarlWitthoft my understanding is that VPX is the mil/space version of PCI, and provides a comparable feature set: en.wikipedia.org/wiki/VPX. The problem is not assigning IRQs or base addresses, but rather the testing and validation required to ensure that whatever part they put on board will actually deliver the promised performance. I'm sure whatever they validated could more or less be plugged into the bus without fanfare. $\endgroup$ – Lawnmower Man Feb 1 at 18:36
  • $\begingroup$ Good points. I'm painfully aware from past work projects of the effort required to qualify parts. $\endgroup$ – Carl Witthoft Feb 1 at 18:37
  • 1
    $\begingroup$ I don't expect SSD to continue scaling 1000x per 10 years by the way. It seems that SSD technology was significantly behind chip manufacturing abilities and then it caught up. By now, it's finished catching up. $\endgroup$ – user253751 Feb 2 at 11:04
  • 4
    $\begingroup$ I guess there's a limit to how much storage you'd actually want up there. If there are only 2 four hour contacts with earth per day, and it takes both of them to entirely empty 60GB, then having 120GB just means it'll take two whole days to empty instead of one. You'd sort of end up "constantly behind" because you were filling the buffer before emptying it entirely. So in some sense, the storage space is limited by the bandwidth back to earth. $\endgroup$ – Ralph Bolton Feb 2 at 11:56
32
$\begingroup$

Space hardware almost always is pretty archaic technology. The problem is the long lead time coupled with the need to certify it for flight. It wasn't archaic when it was engineered. The JWT was redesigned in 2005 so look at 2005 tech, not 2020 tech.

$\endgroup$
10
  • 14
    $\begingroup$ Look at 1995 technology instead of 2005 technology. Space avionics is at least a decade behind state of the art, and the lag is getting worse as die sizes get smaller. $\endgroup$ – David Hammen Jan 31 at 8:48
  • 2
    $\begingroup$ Avionics technology for use in space was ten years behind the time (behind state of the practice, let alone state of the art) back in 2005. It is even further behind the time now. $\endgroup$ – David Hammen Jan 31 at 15:27
  • 21
    $\begingroup$ I think this answer is implicitly assuming that you could just grab a modern CPU/Flash/RAM chip and send it to orbit, if you could cut on the certification time. That is not so; electronics without radiation hardening will not live long outside of our magnetosphere, and they will be rather untrustworthy while they're still functional. Moreover, the higher the density of an IC, the more susceptible it is - this is one of the reasons for radiation-hardened electronics using much larger process nodes like 32nm (LEON) or 150nm (RAD750). $\endgroup$ – thkala Jan 31 at 19:07
  • 2
    $\begingroup$ @thkala: Solid state storage nowadays is Flash NAND, and that's pretty high voltage electronics. The problem with RAM and CPU's is that they're low-voltage, and therefore even a low-energy event can cause a disruption. Flash would likely survive the transient, and it's default Error Correction Codes will catch some pretty big errors. You still wouldn't want TLC, as that manages to pack 3 bits per cell by lowering the voltage differences, but the same cell in 2 bits SLC mode would likely work well in space. $\endgroup$ – MSalters Feb 1 at 12:21
  • 2
    $\begingroup$ @MSalters If you mean 2 bits per cell, that's what is commonly called MLC ("multi-level". Totally some lack of foresight there, so that "multi" now always means two, compared to tri-level and quad-level cells.) SLC is one (1) bit per cell. $\endgroup$ – TooTea Feb 1 at 13:24
5
$\begingroup$

The other answers are good. I'll add that, usually due to misplaced budget constraints, project plans don't tend to expect enough iteration. A project plan is like a battle plan -- rarely survives contact with reality. Plan to throw away the first several (cheaper, partial) versions, and you'll have the flexibility of updating technology based on new information.

A great example of a project plan that had iteration built in was the Mercury/Gemini/Apollo series -- that effort would have failed horribly if we had planned to put boots on the lunar surface on the first launch.

Shuttle went the other direction -- with Enterprise the only prototype orbiter funded, we were never able to evolve that system into one that was truly safe, reliable, or cheap.

In recent years, we've finally started to see newer launch vehicles and satellite constellations that do follow more of an iterative development path -- the contrasts in schedule, cost, and capabilities are striking.

If iteration isn't built in, then early decisions get exhaustively analyzed and errors made on the side of caution, because everyone making those decisions knows there's going to be little ability to test hardware until it's too late to change. The resulting limitations have to be accepted as constraints as the project proceeds over subsequent years. These internally-generated constraints in turn tend to lead to projects running overtime, over budget, or failing completely.

It's bizarre to think that, while science is all about change based on new information, "big science" projects rarely can have that feature built into their own plans and contracts -- partners and vendors tend to be contracted to deliver complete, finished goods once, fully specified beforehand and built correctly the first time. The universe just doesn't work that way.

$\endgroup$
1
  • 5
    $\begingroup$ "In recent years, we've finally started to see newer launch vehicles and satellite constellations that do follow more of an iterative development path -- the contrasts in schedule, cost, and capabilities are striking." If only NASA was following such development paths... $\endgroup$ – Ian Kemp Feb 1 at 13:45
4
$\begingroup$

Looking backwards at tech, it necessarily looks primitive. One quote is probably just a legend, Bill Gates allegedly said back in 1981: "640K ought to be enough for anybody." And for people back then, this probably was reasonable.

Notice that in 1991,

SanDisk ships its first solid state storage drive or SSD. The SSD had a capacity of 20MB and sold for approximately $1,000.00. It was used by IBM in the ThinkPad pen computer.

The $1,000 won't be an issue here. But 20MB was the bomb. Some years ago, I bought the smallest pen drives on the market for giving away some docs, and they were much bigger than that.

In 1999, BiTMICRO made a number of introductions and announcements about flash-based SSDs, including an 18 GB 3.5-inch SSD.

For people designing the satellite around the end of XX century, the 60GB looked like 'wow, I wish I had this at home' kind of volume.

$\endgroup$
1
$\begingroup$

Because it is expected to be able to download its data between targets, so doesn't need vast amounts of space and any data it does accumulate will take time to download, so there isn't much point building up a huge buffer.

$\endgroup$
3
  • 2
    $\begingroup$ I'm pretty sure you have cause and effect backwards here $\endgroup$ – Carl Witthoft Feb 1 at 18:34
  • 3
    $\begingroup$ @CarlWitthoft could you please clarify your comment? Amount of data that can be stored for a period of time is the same that can be downloaded for the same time... So if you can download 1GB a day there is negative value to store more than that (as storage will eventually overflow)... And note that you can just pay your ISP twice next month to get faster download speed - bigger/more powerful transmitter not going to fly itself to space... Hardware (either disks or communication) compared to data has weight and the cost per kg is not free even now (was roughly 20x more expensive back then) $\endgroup$ – Alexei Levenkov Feb 1 at 21:05
  • $\begingroup$ @CarlWitthoft not quite. When you're mass and volume restricted you go with the smallest mass and volume you can get away with. If that results in a 60GB storage drive, and you can make that work within your other requirements, that's what you go for. $\endgroup$ – jwenting Feb 2 at 16:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.