Webb placed on top of Ariane 5
esa.int
esa.int
It's also made me wonder if there's a way for humanity to pivot to more "horizontally" scaled science. I'm imagining a kind of science conducted by aggregating the data collected by many cheap, easily produced instruments instead of a few incredibly fragile, extremely difficult to build contraptions. I have an intuition that we'll increasingly run up against practical limitations in undertaking ever more complex projects of this kind in the coming years.
Now maybe we'll find clever ways to get different data cheaply that meets similar ends, but that seems to be hinged on hope at the moment.
One, commoditize your complements. The complement of satellites is rockets, make rockets cheaper and you simplify the process of getting to space.
Second, build towards economies of scale. A one-off is going to be ludicrously expensive, even the Apollo program saved money by reusing technology from military missiles. SpaceX has built more than a hundred rockets and launched more than a thousand satellites. Asteroid barons launching megatons to orbit would certainly make launching a 6.5 ton payload a non-issue. The complexity in the smartphone in my pocket boggles the imagination, I bought it for $200 but if it was a one off you'd have to be Bruce Wayne to afford it.
JWST is going to revolutionize our understanding of cosmos, but only because it's target spectrum, which requires operating temperatures around 45K(-228°C!), to completely eliminate blackbody radiation. Which means that tender layers of sunshield must... OHMY panic attack ...
Today with F9 (and Starship not too far) yes. Launch costs are a fraction of what they were just a few years ago.
When Webb was planned? No way. Keep in mind that it's the same agency that gave us the SLS.
No being afraid of failure allow to simplify, accelerate the process and reduce the cost by an order of magnitude
I mean it'd be awesome to have many, but not realistic in any real sense.
But I 100% agree w/ the cost overruns being a massive problem.
I much rather have reusable rockets than having ISS.
I much rather have in-orbit construction infrastructure than having either hubble or JWST.
I much rather have remote repair and maintenance satellites/crafts than having a robot rover on Mars.
If you keep doing what you barely can do, you'll keep doing it for the highest price possible. Instead you can invest in the infrastructure, and do things as they get cheaper with your current infrastructure.
That time and money should instead be spent on reducing the cost per kg to orbit, as well as in-orbit manufacturing. Then engineers would spend the bulk of their time on actual science goals, not on tangents of fragile deployment sequences or shaving few grams from there and there.
With space debris, come debris cleaning bots, with those bots come more space debris, and next generation of cleaning bots ad infinitum. The net profit/benefit will scale in the meantime, which is what really matters.
I'm not smart enough to know if something like Webb can be horizontally scaled into 100 or 1000x small sats to produce the same result.
My guess is not.
I think we need a super sharp knife and it's worth the investment.
We've basically maxed out what Hubble can do. While a sharper visible light telescope would be nice, we need longer wavelengths to see "further back" in history. i.e. Webb
Another thing Hubble did was kick off Dark Energy, but then we needed different instruments to know more about the things that Hubble started. GAIA, Plank satellites are doing nutso things in that space.
All to say, Hubble is f'ing great, let's bring it home and put it in a museum to help inspire the next generation.
My understanding is that all major observatories, and certainly Hubble, are overbooked by a factor of 3 or more for months, and sometimes years, in advance.
Which implies that having 3 Hubbles would allow us to do more research than we can do today. It's not ready for the museum while astronomers still battle over who gets to use it.
An instrument doesn't have to be cutting edge in order to be useful and produce valuable results. Even today, amateur astronomers are still making discoveries (asteroids, sometimes comets) with telescopes that major observatories would have laughed at 100 years ago already.
"The telescope that ate astronomy" (Webb) will undoubtedly make important discoveries. Whether it will be worth its cost considering what we could have built for the same price (such as 10 ELTs!) remains to be seen.
I do have to believe that any satellite designed specifically for one type of measurement would be more robust and cost less than something that did more than one, but I suppose that's not really true. Sometimes multiple measurements simply complement each other too much not to use.
Usually with telescopes you need a huge aperture to see dim things, unless you're willing to wait a long time for an image to resolve. Not everything is super dim, though, so maybe having telescopes with an aperture much smaller than 6.5 meters would make sense for those tasks.
I don't know if there's some other reason James Webb needs a huge aperture than being able to resolve and image quickly. (Maybe the lower wavelengths don't behave on small mirrors?) If that's it, though, it seems like having backup would be good.
Fun fact for dimness: We are pretty much at “we can count every photon that comes” so if you want to pick up far away things, increasing the aperature is also one of the few things you can do. But at that point you’d probably prefer multiple telescopes if you can align them properly
From a physics point of view there really isn’t much difference between light and radio waves. Both is just em radiation. But the absorption by matter (well really gas, there is nothing else) changes with wavelength too. And you’d optimize the ccds for whatever you want to look at. So that would be the primary consideration and keep in mind these things tend to also be build as tech demos (which also means you typically don’t get to realize all design capabilities in action). So “because it’s the most we could get away with” is a reasonable reason
But you can use many separate mirrors with artifacts to replicate a perfect mirror, as long as you are able to do some post-processing on the array of mirrors with artifacts. And with proper post-processing you may even be capable of extracting additional information which a single perfect mirror would not be able to deliver.
> But you can use many separate mirrors with artifacts to replicate a perfect mirror
It is theoretically possible, but is it practically so? My argument/usage of the analogy is that it isn't today. That as the analogy says, if we put up 100x small mirrors we just get 100 dull knives and blurry science[0].
[0] https://images.ctfassets.net/cnu0m8re1exe/3grbH0eWtw0AxG3MUT...
Some examples: https://www.dragonflytelescope.org/gallery.html is an array of telescopes (long off the shelf photographic lenses) to achieve exactly that. Photographic lenses tend to give higher image quality, but don’t gather enough light. Solution? Stack many of them and point in the same direction. It’s not just a flight of fancy, they made some breakthrough science with this.
A somewhat less relevant case is ALMA - millimetre wave array in the Atacama. Millimetre waves are a bit longer than IR, somewhat between IR and microwave, and telescopes look like radio dishes, not optical devices. Anyway, the array stacks many tens of such receivers to produce one antenna with a massive effective diameter. In this case, the key advantage is in fact resolution: by spreading the dishes around, you get much higher overall resolution than one massive dish, something we probably couldn’t achieve with IR (too computationally expensive).
Whether launching 10 satellites with 1/3 mirror diameter is cheaper is a whole different question.
If that's the case Webb has been done many times and is super easy.
Not to mention, each of these 100 units would require the same shielding from radiation as the giant one does for the same reasons. We chose L2 for a very good reason; where are these 100 going to go? What are the odds that each one will end up where it needs to be x100 attempts?
We do a lot of that already.
The purpose of flagship observatories is to do what can't be done with many cheap, easily produced instruments.
This is already happening - Webb took 7 years longer than expected and cost $10b instead of the projected $5b.
Specifically for space telescopes, I am optimistic for the future because launching mass into orbit is getting cheaper and cheaper. One main reason Webb has to be extremely expensive is that it also has to be extremely lightweight. If it becomes 10x cheaper to stick things in orbit then we can save money on construction too because we won't have to optimize weight as much.
Of course, once space telescopes become cheap and normal, it'll be time to think about constructing a radio telescope array on the far side of the moon.... :D
"Ariane 5's first test flight (Ariane 5 Flight 501) on 4 June 1996 failed, with the rocket self-destructing 37 seconds after launch because of a malfunction in the control software. A data conversion from 64-bit floating point value to 16-bit signed integer value to be stored in a variable representing horizontal bias caused a processor trap (operand error)because the floating point value was too large to be represented by a 16-bit signed integer. The software was originally written for the Ariane 4 where efficiency considerations (the computer running the software had an 80% maximum workload requirement) led to four variables being protected with a handler while three others, including the horizontal bias variable, were left unprotected because it was thought that they were "physically limited or that there was a large margin of safety". The software, written in Ada, was included in the Ariane 5 through the reuse of an entire Ariane 4 subsystem despite the fact that the particular software containing the bug, which was just a part of the subsystem, was not required by the Ariane 5 because it has a different preparation sequence than the Ariane 4"
I wouldn't want any part on something as mission critical as getting a rocket to deliver something into orbit.
Ariane 5 has 106 launches since their last full failure. (1 partial failure in there.)
Of course, F9 is a little smaller, everything other than Delta IV Heavy is a little smaller, so your statement including "with that much payload capacity" is true by construction.
>SpaceX F9 has 106 successful launches after their last failure. Ariane 5 has 106 launches since their last full failure.
Worth noting given these rockets' history (and also your mention of cargo), both have had a number of major variants (as well as minor evolutions). The only operational F9 is the current Block 5 (first launched in 2018) and for the Ariane 5 the ECA (first flown in 2005). F9 Block 5 has flown 75 times and all have been successful. Ariane 5 ECA has flown 77 times with 1 failure. They're reliable rockets, though the F9 has obviously had a higher cadence as well as the distinction of human flight.
>Of course, F9 is a little smaller, everything other than Delta IV Heavy is a little smaller
It's a little more complicated in terms of cargo. F9 expended (which I think is fair given the Ariane 5 is expended) actually does slightly more mass to LEO (22.8t vs 22t). But the A5 is more optimized given its staging around mass to GTO, where it beats out F9 (8.3t vs 10.9t). F9 of course loses quite a bit when reused (LEO: 15.6t, GTO: 5.5t), but at massively less cost so not quite the same thing.
Also when you say "everything other" you've completely forgotten about Falcon 9 Heavy :). That does 63.8t to LEO and 26.7t to GTO, and of course vastly outmasses either the F9 or A5.
You probably know all of this already. Please, let's stop deconstructing my grammar, and instead start communicating.
BTW the two Falcon Heavy launches I witnessed were extremely cool.
You launch your first few rockets expecting them to explode because even with all of the care, it's just not reasonable to expect that you got everything right in simulation, test, and design.
This is why the public response to "failures" from SpaceX, NASA, etc. etc. are so frustrating, people don't understand the nature of product testing. You don't get to see a washing machine or microchip or car or whatever else do its equivalent of exploding on the pad, but they all do and much worse.
The first flight of a rocket not exploding is like spending days writing code, compiling it once without errors and running it in production with no issues. It's basically unimaginable and when it does happen you sit and wonder what's actually going wrong that you don't know about yet.
Once you do get a working configuration, you don't change it or make only very safe changes. You rely on what's worked before because things are actually exactly the same, not constantly changing like so much software today. This leads to a lot of conservatism that people don't understand (why is military hardware using X, it's so outdated!)
- CST-100 was sent into orbit with software mapped to valves incorrectly. There is no credible reason this shouldn't have been tested thoroughly on the ground first.
- Falcon 9 had a failure due to a tank support strut that had strength characteristics a fraction of its design spec. Good supplier quality control should have vetted the material prior to its use. (SpaceX has since added material tests).
Finding unknown causes of failures help us learn more about the science of the industry. But not catching known failure modes due to lack of process control is a different animal.
I agree, but for any complicated product like a rocket launch there are probably many many tens of thousands/hundreds of thousands/millions of things like this where one small uncaught error can cause mission failure. At some point it's just statistics, you'd expect to see some catastrophic failures across some percentage of products early in their lifecycle, regardless of how good your process control is.
It would be one thing if SpaceX tested the material coupon and found it within specs, but by sheer probability, the strut had a portion of its material structure that was anomalous. That's what you're talking about. What I'm talking about is there are specific process steps that would have caught those mistakes above, and those processes were just not performed. Neither of the cases mentioned above are the result of "We did everything right, but the probability gods were just not on our side."
Actually, that's not what I'm talking about. What I'm talking about is lessons from QA processes and the chance that any particular bug escapes from one QA process to the next.
The idea being, suppose you have:
* one million different "components" in a system
* each of those components have, say, 10 possible failure modes
* There are 100 of these new complex products a year.
Obviously the numbers above are all made up, but the idea would be in that example you'd have a billion (1,000,000 X 10 X 100) possible failure modes. Any QA filter, might be expected to catch, say, 95% of remaining bugs.
So you run as many filters as you can, but at some point you're still left with the small probability for new bugs, and they only way to remediate those bugs is to figure out what went wrong after the fact.
So take the software example from above on CST-100. The valve mapping error should have been a known failure mode ("We command valve A and it doesn't respond." or "We command valve X and valve A responds"). Those failures are very straightforward to test for with simulations on the ground, yet somehow those errors made it into a flight configuration. Arguably, the software timer issue on that flight falls into a similar category, but the mitigations there are a bit more complex.
Overestimating the risks can bury a project just as quickly as underestimating them. If you test for every possible failure mode you may never get off the ground. There's always a test or check that can catch something before the risk is realized. Every nut and bolt can be X-rayed, every line of code and possible combination can be tested, it's just a balancing act. Sometimes the risk doesn't justify all the tests, sometimes a test is accidentally omitted, or poorly defined because someone made a mistake or misunderstood the explanations behind it, or someone misread the result, or the risk was considered avoided because the code was tried and tested tech on Ariane 4.
Rockets are so complex that there are millions of situations where a mistake can be made and later amplified.
But the issues above aren't that. I can think of very little reason that valve command mappings on a human-rated rocket were not adequately tested. The larger point is there needs to be good testing on credible risks, not that risk needs to be driven to zero.
I would say someone who thinks "the risk was considered avoided because the code was tried and tested tech on Ariane 4." doesn't actually know the nature of the risk in order to determine if it's credible. The risk was not mitigated because changing configuration added an untested interaction risk.
The procedure and checks were probably repeated multiple times during earlier preparations with no issues. God only knows how many potentially critical problems exist in every system on a code path never taken, or with a component that's never used. It's one thing to test everything for the design of the system and call it complete, and another to test everything for operations. Human error caused an operational misconfiguration on a system that was otherwise validated.
Think of aviation where the entire plane design and the technology used are fully tested and known to meet all the requirements. But every time you operate that plane you have a shorter pre-flight check to confirm operational worthiness. Some things that can cause a disaster won't be covered, and some items on the the checklist will be mistakenly marked as OK, which may or may not cause a problem.
I'm not saying it's normal just that statistically speaking at some point you'll miss something for one reason or another, and eventually the proper conditions will be met for a disastrous outcome. Might as ell be a valve control check.
Those issues were caught by luck, due to the way follow on testing was conducted after the timer failure. The result indicated they were not adequately tested previously.
I get that not everything can be tested. But those unknown errors that go untested should be relegated to those low probability events. Neither of the examples I gave fall in that category. Hell, NASA even requires testing for random bit flips due to radiation, there’s no excuse to let a valve command mapping error slip through the cracks.
The last few levels have been dealing with CST-100, not SpaceX so I'll try to continue that thread to be more coherent and then touch on the SpaceX example.
Here's all that's really needed to capture the CST-100 issue:
1) Valve A is listed a "must" requirement. E.g., "Valve A must work when commanded".
2) As a "must" requirement, there is a test plan that covers that operation (again, another requirement).
Safety-critical development is driven by formal requirements more than many other types of software. Requirement #2 can happen any number of ways. If they decide to meet that requirement via simulator, they need to ensure the simulator is of sufficient fidelity to ensure #1 is met. This fidelity would mean that the simulator valves are mapped to the correct simulator commands. To answer your question directly, I would expect every "must" and "must not" requirement to be tested; any that aren't would be suspect for potential failure. If you can get me a list of requirements (ideally, with a failure modes effects analysis or hazard analysis) and associated test plans, then I can give you a list of potential failures.
So the question becomes: would you be okay with a test plan that doesn't check that a software command is received to meet a simple but critical high level requirement? Do you think a test plan that misses such a simple test is within an acceptable risk envelope? This isn't some low-probability event, but a test error that can be traced to a very simple requirement that wasn't tested.
With SpaceX, supplier quality has been a major point in aerospace for decades. I've worked in organizations that have rigorous procurement processes that check for such things, including audits of manufacturing facilities for critical items. Could the supplier forge the certifications and the system fail because of it? Sure, but that's not the case here. The checks just didn't happen. Materials checks are extremely common, even on small items like bolts let alone large structural components. Likewise, I would expect any non-checked critical procurement to have a higher level of risk in producing a failure.
This isn't about predicting some random, unheard of failure or ex ante stock prediction. It's about due-diligence on well-understood risks.
Every time that happens I'm terrified and overcome with a quiet, pervasive sense of existential dread.
https://learn.adacore.com/courses/intro-to-ada/chapters/stro...
They tested a lot (some of the testing was delivered with the software even, to run anytime...).
There were some organizational attempts to control for such issues, but there were no real solutions other than a bunch of guidelines.
Some of the code written for the space station was done in long, sleepless 'power-coding' binges. I thought that was 'cool' now I think it's 'insane'.
I do remember learning a bit about Ada, but it's been so long, and it's probably out of the range for most things today.
Even Rust is a bridge to far for most projects, I really wish there were ways to 'back off' from Rusts ultra-hard principled approach because I think what most projects need is '65% Rust', not '100%' which is the only current option.
> the space station was done in long, sleepless 'power-coding' binges
Yikes.
I grew to appreciate Ada. We would disable the interupts on some cpus and the software had to be reliable as if the code crashed or got stuck, you were rebooting the machine.
Go has a garbage collector, which fundamentally introduces nondeterminism. Due to implicit interfaces, it can't enforce exhaustive typeswitching. Every pointer type is nullable, which means entire classes of runtime bugs which can't be caught at compile time. And the type system requires far too many escape hatches (resorting to `interface{}` and typeswitching) to have the kinds of type safety guarantees necessary. And lack of sum types means functions return errors and values instead of errors or values which—in my experience—has been an unending source of foot-guns in production code.
OTOH, Rust has none of these drawbacks and many, many other strengths that enforce static guarantees about safety at compile time. It's not perfect, but it's an extremely worth successor to Ada and just about the only feature from Ada I wish it had was the ability to specify tighter domains on types (for instance, numeric ranges on integer types).
In fact, in my experience, there's not even any dynamic memory allocation!
You allocate your memory on boot and work from it.
Rust has some nice pointer advantages, but it's not specifically suited to those kinds of system, and would have some big cultural baggage to overcome.
Rust has performance and perfect non-null safety in mind, not necessarily perfect logical safety.
Space systems would be 'totally ok' with extra overhead that checked parameters, pointers, memory etc. before certain operations.
That said, I can see Rust happening in space some day.
You didn't mention it, but IIRC what made the overflow possible was the increased performance of Ariane 5. Such values couldn't physically be reached with Ariane 4.
Now, the real irony is that indeed that computation and whole subsystem wasn't needed. It tells you something about removing unneeded parts. On the other hand, the aerospace sector is traditionally very conservative and reluctant to change things. Have a look at the superstition surrounding launch processes: http://stevenjohnfuchs.com/soyuzblue/yes-they-pee-on-the-tir...
I can picture code being included whole for fear of breaking something by mistake.
In this case, it is rocket science.
Most launches were at night, and we could watch the trail of flames pass by but 501 was launched during the day. Impressive to watch how wrong it went, how fast. There's even still the dude saying "all parameters and trajectory normal" literally as the thing explodes.
Good times and nice memories.
I hear there's a need for 3rd party libraries to log data.
I'm sure there's a commentary there on modern life, but sod that, this far cooler than any addage :)
https://en.wikipedia.org/wiki/James_Webb_Space_Telescope#His...
A few hundred million for each launch; heck, the long-term ground support is probably more expensive than the flights and the hardware after a while.
Not anytime soon. The Hubble is in low-earth orbit at an altitude of 540 Km, whereas JWST is at the Earth-Sun L2 point at an altitude range of 370 Mm to 1.5 Gm; further than the Moon. No spacecraft capable of carrying humans beyond LEO has been built since the Apollo missions.
Starship and SLS will change the game, but both are still years away from manned flights.
>"There are 344 single-point-of-failure items on average," Menzel said about the Webb mission, adding that "approximately 80% of those are associated with the deployment
https://www.space.com/james-webb-space-telescope-deployment-...
I don't think SLS will be in a position to be able to do this any time soon. Starship, well, let's hope so!
- JWST costs ̃$8.8B USD, about the same as aircraft carrier, or Large Hadron Collider and it goes into a rocket!
- JWST has 344 single-point-of-failures, 80% of them related to deployment. Mars landers have significantly less If I remember correctly.
If each single-point failure has 0.0001 failure probability, the mission fails with 3.4% probability.
If each single-point failure has 0.0002 failure probability, the mission fails with 6.6% probability.
The other concern is, of course, what happens if it blows up on the launchpad.
"Lewis Point Estimate Determined as Follows.
Maximum Liklihood Estimate (MLE)= x/n
where x=success, n=tries
For MLE<=0.5, use Wilson Method = (x+2)/(n+4)
For MLE Between 0.5 and 0.9, use MLE = x/n
For MLE>=0.9, use Laplace Method = (x+1)/(n+2)
Lewis, J. & Lauro, J., "Improving the Accuracy of Small-Sample
Estimates of Completion Rates", Journal of Usability Studies,
Issue 3, Vol. 1, May 2006, pp. 136-150."The answer is that building another telescope specimen would be quite expensive, even without any changes to the design. The supply chains aren't set up for volume and integration and testing is very involved. I can't put a number on "the second telescope would be x% cheaper", but it would be very disappointing.
In terms of hardware that's readily or soon to be available, it is technically possible. Starship, if it gets off the ground, is the obvious choice. Orion could do it, but it would mean dumping another two billion into JWST.
If it really came down to it, Falcon Heavy launched with a Crew Dragon sitting on top of it could probably reach it, although it might need an additional kick stage (I haven't done the maths), and it would need to be crew rated first (and SpaceX don't currently have an interest in doing that).
Also, AFAIK, Crew Dragon does not have airlocks or other resources for EVAs. Not sure it the capsule can be evacuated for that too. But I would like more information in this issue ... could not find too much from reliable sources for now.
True. But generally when people bring up the statement that we can't service it, they usually back that up by citing the distance. There would still be a lot of hurdles to overcome, but none are insurmountable with relatively small investment.
All of that said, if Starship works, then the economics change drastically anyway. You could probably launch an entire fleet of less reliable, but much cheaper telescopes, for less than the cost of servicing.
The biggest problem would be that it would be in the ISS orbit, which would require a lot of delta-V to get it to its final orbit.
Not only would they be replaceable, but we could increase capacity in the future.
For those who don't know what the quote is. I found it here[1].
[1]: http://www.ganssle.com/articles/programmingquotations.htm
Having worked both in construction and software, modular design seems fairly common in both.
https://www.quora.com/What-would-happen-if-the-James-Webb-Sp...
I assume that like with most things, the vast majority of the cost has been in the design and documentation over its 30 years of development. At the same time, there's obviously a ton of extremely high precision bespoke components in there, so "building another one" would definitely not be trivial.
Why wasn't 5 Hubble telescopes launched? The marginal cost for the other 4 must have been vastly smaller than the first. Observation time on the original Hubble is still, after 30+ years a scarce resource. With 5 of them, we could have gotten vastly more science done at smaller cost.
I don't have a fully fleshed out theory for why, but part of it is that NASA as a government organization is ultimately a political endeavour, and it will have to optimize for what makes politicians look good in the press, rather than what gives the most science bang per buck.
https://en.wikipedia.org/wiki/KH-11_KENNEN
In particular some of the manufacturing tooling for the mirrors were shared, leading to the HST mirror being downsized to 2.4 meters.
https://en.wikipedia.org/wiki/2012_National_Reconnaissance_O...
One of them forms the base of https://en.wikipedia.org/wiki/Nancy_Grace_Roman_Space_Telesc....
It's a little odd how people re-tell that story, but ok.
Hubble's optics also weren't easy to produce and notoriously were faulty which had to be later corrected in orbit with a Shuttle mission. The bid being lower than expected could just as easily be explained by the contractor massively under bidding to win the contract. I've never heard anyone claim the Perkin-Elmer also made the optics for the KH series before now. Its not outside the realm of possibility but unless you have some compelling proof then I have no reason to believe that. I think the fact they screwed up indicates they probably weren't because if they had done the optics for the KH-11 series then they would have been well practiced at making mirrors that size by the time Hubble was built.
They just have never had the budget in launch costs to ever launch more than one.
Until recently, neither launch nor satellites had economies of scale. With reusability, launch does. And with common platforms and constellations, satellites are beginning to.
Some aspects certainly do, like ground-support-equipment and basic launch infrastructure.
Economies of scale only apply at, well, scale. Five Hubbles would cost 5x one Hubble to construct. There's very little in the way of savings because most parts are custom fabricated. The parts need to be tested, integrated, then tested after integration. The testing and verification of each subsystem takes the same number of person-hours. So testing 5x the systems requires 5x the time.
You can't just accept a high failure rate of something the size of Hubble just because you've built five of them. If you launched a Hubble and it failed in some Loss of Vehicle fashion after inserted into orbit you've got a big uncontrollable mass of telescope flying around the Earth.
Even if we still had the Space Shuttle (or a fantasy version of the SpaceX Starship) flying an uncontrollable Hubble couldn't necessarily be retrieved. If it wasn't accepting commands and was spinning on some axis it would be too dangerous to approach with another vehicle. Even an unmanned vehicle couldn't necessarily approach it without a collision that causes even more problems. See the recent idiotic Russian ASAT test for an object lesson in what could happen.
This is all to say you don't want some large satellite in a long lived orbit to fail. So there's no savings on testing and verification. Even though at launch Hubble's mirror had problems the satellite itself was fully under control and operable.
Something like Starlink is very different. All the satellites in a given block are functionally identical and fungible. If one fails it's easily replaced by another. They also deploy to a low unstable orbit. If a Starlink satellite fails and is uncontrollable it will de orbit by itself quickly. They must be functional to enable the onboard engines that get them to a stable intended orbit. A Starlink satellite then needs far less testing and verification than a Hubble or JWST, not that they can be poor quality but they don't need to function Or Else Bad Things.
To piggy back on the the GP's point, the fabrication research is only one small cost center. Quality control costs much more in aerospace than many people realize. The reason why a bolt may cost $150 is because it has to be tracked, material coupons kept/tracked/tested, held in bonded storage etc. and not because we had to figure out how to make a bolt. Those costs don't come down as much with scale as, say, raw material.
If it were all about knowledge costs, many designs today would be dramatically cheaper because many use technology (and even refurbished rockets) from 50 years ago.
We're talking about marginal costs, not development costs. So the cost to invent a component is already out of the equation. The high production cost of something like Hubble comes from testing and validation more than materials or fabrication.
The failure modes for something big in space can be extremely dangerous. Even a tiny "cheap" cubesat requires a lot of relatively expensive testing so there's a reasonable assurance it won't fail in some catastrophic fashion and destroy the entire rocket.
Testing space hardware is additionally difficult because you can only just approximate the hardware's operating environment on the ground. Space hardware also can't be easily repaired or repaired at all once launched. So you've got to test actual flight hardware and if it fails possibly rebuild it from scratch testing and validating the entire way.
Developing space hardware and high precision science instruments is expensive and difficult. But it's just a small portion of the overall mission cost for something like Hubble or JWST.
> The testing process would have to be more streamlined or efficient, i would think.
Why do you automatically assume testing for a complicated and delicate machine is inefficient or not streamlined? That's a pretty bold assumption with zero evidence.
Understanding failure modes doesn't help test and validate something any faster. There's a finite number of hours in a day and components need some proscribed amount of testing.
What happened was that pretty soon the budget got slashed, and the out of the prototype two units they barely scrambled to have one of them flown, with very complex process to balance the budget in face of constant attempts to cut it by Congress.
Maybe if NASA's budget was allocated in different process, things would be different. As it is now, the people controlling the purse strings care about their reelection so they will at best jerk projects around to send money to their states, or to place their own spin on things, etc.
Ariane 5 has a long flight record with very few failures and the design has been further carefully reviewed specifically for JWST, with the previous two launches having served as verification for any fixes that needed to be made prior to flying this mission.
Basically, the chance of JWST being lost due to a rocket issue is much lower compared to the chance of it being lost due to design issues with the telescope itself.
1. Prohibitive costs. Its extremely expensive (both in money and time) to manufacture many of the parts of the telescopes, such as the reflector dishes. Its even more expensive to do all the testing & certification of the manufactured parts.
2. Its all outdated anyways. The JWST project has been ongoing for literally decades (starting in '96 if I remember). If we were to start from scratch today we would make a lot of different design choices based on more recent technological developments
Solar panels require that JWST stays in the sun while conducting observations, while at the same time being critically dependant on the observing equipment to be cool - and being unable to just keep it inside bigger structure like with Hubble.
This means that there's a huge problematic sun shade structure which is considerable part of the SPOFs still endangering JWST even if it is inserted into orbit correctly.
For certain risks, like human-rated spaceflight, they may just have requirements like "no single-point failures", which means redundancy is a must.
I don't know if I could handle that much pressure to launch that thing.
On other hand, NASA has done this amazing thing with landing rovers on Mars flawlessly and those were incredibly complex processes with sophisticated pieces of engineering.
biting my nails here
https://upload.wikimedia.org/wikipedia/commons/6/6a/JWSTDepl...
https://webbtelescope.org/contents/media/images/4180-Image
After that they still need to a do a ton of checks, wait for outgassing, etc. The first "science-quality images" are expected by the end of the third month.
>By June 2022, if all goes well, Webb will finally be ready for science.
Glad to hear it went well and we are back on track!
Ever since I heard about JWST (I feel like it's been 8 years ago now), I was looking forward for an answer to this question. All the delays have been so painful...
https://www.nature.com/articles/d41586-021-03620-1
30 days to achieve orbit.
Six months to settle, synchronise, allign, and calibrate.
https://blogs.nasa.gov/webb/2021/11/22/nasa-provides-update-...
I hope there won't be vibrations during the launch of the rocket.
The unplanned vibrations due to this mishap was not planned for.
I understand they ran some tests and calculations after the accident and believe that the instruments are good to go.