[HN Gopher] Webb placed on top of Ariane 5
___________________________________________________________________
Webb placed on top of Ariane 5
Author : _Microft
Score : 235 points
Date : 2021-12-14 16:40 UTC (6 hours ago)
(HTM) web link (www.esa.int)
(TXT) w3m dump (www.esa.int)
| YossarianFrPrez wrote:
| I keep reading about how there are ~350 single points of failure
| once Webb is successfully launched. Can someone with expertise
| and chime in about why the telescope wasn't designed with more
| built-in deployment redundancies? It would seem to be good
| engineering practice to ensure that there are back-up systems,
| etc.
| bumby wrote:
| Redundancy is only one way to increase reliability. For
| example, having redundant elements can allow you to use cheaper
| components and meet the same level of reliability as a single,
| more expensive component but at the cost of mass (or vice
| versa). Most often, there are reliability requirements that are
| defined at a very high level, and a reliability engineer helps
| determine the right tradeoffs to meet those requirements. In
| addition, some of the points of failure don't lend themselves
| well to redundancy, like release mechanisms.
|
| For certain risks, like human-rated spaceflight, they may just
| have requirements like "no single-point failures", which means
| redundancy is a must.
| evgen wrote:
| Redundancy costs mass and there are a lot of deployment steps
| that simply cannot be made redundant. The trick is folding
| everything to fit into the constraints of the payload fairing.
| Good engineering is to design within these limits and but if
| you make it too safe you end up with something that is not
| worth launching.
| hollander wrote:
| Plus you don't get to send a Space Shuttle to L2 in case the
| mirrors are malfunctioning.
| pelagicAustral wrote:
| Talking about Ariane 5, it's been interesting reading parts of
| its history. Particularly:
|
| "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.
| Eikon wrote:
| Video of the incident:
| https://www.youtube.com/watch?v=gp_D8r-2hwk
| jlengrand wrote:
| I still remember that one, I was at school 80 kms away when it
| blew up. Quite the boom given the distance, but nobody scared,
| just heard a large bang.
|
| 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.
| barkingcat wrote:
| That part about the saying "well, it's not rocket science"
|
| In this case, it _is_ rocket science.
| colechristensen wrote:
| Eh, aerospace involves a lot more testing and specification and
| generally being careful in engineering practices and still
| failure for new products is expected.
|
| 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!)
| bumby wrote:
| I think this is a fair take when you're talking about
| failures of nascent designs because of unknown failure modes.
| But it's frustrating when there are failures from known
| failure modes that just had process escapes. A couple
| examples:
|
| - 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.
| hn_throwaway_99 wrote:
| > 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.
| bumby wrote:
| Yes, there is reliability analysis involved which invokes
| probability. However, that's not the case with the items
| I mentioned above.
|
| 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."
| hn_throwaway_99 wrote:
| > 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.
|
| 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.
| bumby wrote:
| Not every bug creates a failure, so there's not
| necessarily a need to be completely bug-free. The point
| is to focus efforts on the bugs that _can_ cause failure
| and design mitigations for them. If your system has a
| billion potential software failure modes, my hope is that
| a project manager will say the software is too complex
| and needs to be redesigned. I think this is where some in
| the software crowd get it wrong in their understanding of
| how software reliability in safety-critical applications
| is performed. There are a lot of project managers who
| deliberately avoid using software as a mitigation because
| of the complexity issue (see the 737Max use of software
| as a mitigation for a good example of where this practice
| can go wrong).
|
| 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.
| buran77 wrote:
| > there are specific process steps that would have caught
| those mistakes above
|
| 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.
| bumby wrote:
| I agree that there needs to be a balance between testing
| and cost. One one side, QA managers can become chicken
| littles who define the only acceptable level of risk as
| zero. On the other are project managers who let cognitive
| biases help them rationalize the answer they want in
| order to avoid cost overruns.
|
| 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.
| buran77 wrote:
| > I can think of very little reason that valve command
| mappings on a human-rated rocket were not adequately
| tested
|
| 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.
| [deleted]
| dylan604 wrote:
| >I wouldn't want any part on something as mission critical as
| getting a rocket to deliver something into orbit.
|
| I hear there's a need for 3rd party libraries to log data.
| Stevvo wrote:
| I find it interesting that bug is so normal, like it's exactly
| the type of bug we encounter all the time in terrestrial
| software. Yet the stakes are so much higher.
| jollybean wrote:
| Amazing. I wonder if given the large advances in computing
| power, that we might develop something like Ada+Rust for such
| systems where we can eliminate all sorts of error classes.
| acomjean wrote:
| I worked on radars. We used Ada. The knock on it is that its
| slow, and didn't have a huge ecosystem. but 20 years later at
| least slow is not really much of a problem. You kinda got
| used to the fact if the software compiled it probably would
| run. It had some neat features (like constraining values, eg
| this variable will be between 0 and 10. Of course you'd have
| to deal with things when you ended up outside that range.. ).
| Really quite reliable.
|
| 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...).
| jollybean wrote:
| I interned in IT on Space Systems and looking back I'm
| basically amazed we ever put 'software' in space.
|
| 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.
| MayeulC wrote:
| > were left unprotected because it was thought that they were
| "physically limited or that there was a large margin of safety
|
| 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.
| pkaye wrote:
| Looks like 95.5% success rate. I don't know if there is
| anything better with that much payload capacity and as long a
| track record.
|
| https://en.wikipedia.org/wiki/Ariane_5
| ceejayoz wrote:
| https://en.wikipedia.org/wiki/Delta_IV and
| https://en.wikipedia.org/wiki/Atlas_V have essentially
| perfect records. The IV had a lower-than-expected orbit on a
| non-payload test flight, and the V had a lower-than-expected
| orbit that the payload was able to fix.
| wumpus wrote:
| NROL-30 on Atlas 5 apparently had a shorter lifetime after
| the "fix", and that is normally considered a "partial
| failure".
| colechristensen wrote:
| You have to take statistics like this with a grain of salt.
| Sometimes less than perfect reliability is by design,
| sometimes development details (like how different the "new"
| rocket that earned that name is from previous designs) hide
| failures in earlier rockets with different names.
| ceejayoz wrote:
| Sure, but if anything, Ariane 5 is a good example of
| that; it blew up because of reused software from the
| Ariane 4.
| wumpus wrote:
| SpaceX F9 has 106 successful launches after their last
| failure.
|
| 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.
| shakezula wrote:
| Wow, that's a much better continuous success rate than I
| would've guessed on either account.
| richardwhiuk wrote:
| Success rate isn't very interesting. If a random 1/20 rockets
| fail, then that's very bad. If your first 10 rockets failed,
| and then you next 190 succeed, that's likely to be a much
| better rocket.
| qwertyuiop_ wrote:
| I hope it works up there. They dropped it
|
| https://blogs.nasa.gov/webb/2021/11/22/nasa-provides-update-...
| findalex wrote:
| > caused a vibration throughout the observatory.
|
| I hope there won't be vibrations during the launch of the
| rocket.
| zamadatix wrote:
| One means you felt something else have an bad day, the other
| means you had a bad day.
| mort1merp0 wrote:
| The launch vibrations and their resonance frequency are
| accounted for in the design.
|
| 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.
| [deleted]
| kingcharles wrote:
| After checking, it was fine.
| redis_mlc wrote:
| From your link, it doesn't sound like they dropped it.
|
| A clamp band "released" causing vibration, but that is not the
| as a 1g fall to the hard floor.
|
| This is one of the few NASA projects to actually care about,
| since the Shuttle and the ISS were flaming moneypits. Virtually
| no science has ever been done on the ISS, even compressing it's
| entire history into a single year - it's that worthless.
| (Another HN reader confirmed that by reading NASA's junk PR
| releases about ISS.)
| ceejayoz wrote:
| Could've been worse.
| https://en.wikipedia.org/wiki/NOAA-19#Damage_during_manufact...
| nabla9 wrote:
| Super exiting.
|
| - 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.
| ashton314 wrote:
| The launch is super scary, but the deployment seems even worse.
| When will we know whether or not all is working?
|
| I don't know if I could handle that much pressure to launch that
| thing.
| danielodievich wrote:
| I am there with you. I've been watching this unfold for half of
| my life, and seems like EVERYTHING must go right for it to
| happen. The unfold is scary complex. I really, really, really,
| really want it to go right and worry.
|
| 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_
| edoceo wrote:
| How about Cassini? (sp?) threw this little sensor disk to
| Saturn for information - what a cool project.
| Rebelgecko wrote:
| All the scary stuff that can go catastrophically long is within
| the next 40 days or so. However it'll take months to go through
| the calibration process, tweak the mirror positions, check out
| optics, etc
| jessriedel wrote:
| Yea, I'm having trouble finding a detailed schedule, but it
| looks like the main mechanical components are all deployed in
| the first 15 days
|
| 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.
| michielt wrote:
| Are there any onboard cams to watch the deployment after it
| reaches L2?
| pgen wrote:
| Deployment sequence: https://www.youtube.com/watch?v=RzGLKQ7_KZQ
| NikolaNovak wrote:
| I could be wrong, but I feel SpaceX has mastered how to add
| pizazz to such videos :-)
| [deleted]
| davesque wrote:
| I've found that there's a weird internal psychology I have with
| any news relating to Webb. I'm just as excited and hopeful as
| everyone else. But somehow the whole story underscores the perils
| of singular hope. It also seems to underscore the inherent issues
| with massive, carefully planned, "vertically" scaled science
| projects a la 20th century NASA. I've carved out a little nook in
| my psyche to cope with the outcome that something goes wrong
| during the Webb's incredibly complicated launch process and all
| those years of effort come to nothing.
|
| 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.
| mwattsun wrote:
| I can't even follow the news because I know how disappointed
| I'll be if the launch crashes. Wake me up when it's over.
| bumby wrote:
| I think these are large vertical projects because of the nature
| of the problem. I.e., the data we're after is inherently
| obfuscated by our earthly dwelling so we need to get our
| instruments a long ways "out-there". And to do so incurs a lot
| of risk and, generally speaking, the only institutions large
| enough to incur a risk that large without much profit upside
| are governments.
|
| 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.
| natch wrote:
| On the ESA web page... 4 likes. Come on, world! We can do better
| than that.
| lainga wrote:
| I can't find an answer to this anywhere: is there a backup JWST
| (or parts thereof) if this one fails to launch?
| kilroy123 wrote:
| No, and I think they should have made two of them.
| [deleted]
| crate_barre wrote:
| Makes me wonder if it would have been smarter to build it in a
| modular way with different pieces being sent up one at a time,
| assembled on the ISS, then launched in the direction it needed
| to go.
| dekhn wrote:
| humanity has a lot of experience building reliable one-offs,
| actually a lot more experience and a lot better experience
| than with modularity and bits and pieces. I'm a software
| engineer by trade but every time I look into industry (ship
| building, skyscrapers, etc) you realize: that aphorism about
| software engineers, woodpeckers and civilization was
| absolutely right.
| Something1234 wrote:
| "If builders built buildings the way programmers wrote
| programs, then the first woodpecker that came along would
| destroy civilization." ~ Gerald Weinberg.
|
| For those who don't know what the quote is. I found it
| here[1].
|
| [1]:
| http://www.ganssle.com/articles/programmingquotations.htm
| bumby wrote:
| Can you explain the colloquialism a bit? Is it a knock on
| modular design?
|
| Having worked both in construction and software, modular
| design seems fairly common in both.
| jandrese wrote:
| Then you have multiplied your launch risk by the number of
| launches it would take to get it up there, plus there is the
| difficulty of assembling it in orbit. The only other project
| built like that was the ISS, and it took decades and a launch
| vehicle that no longer flies.
|
| 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.
| jbay808 wrote:
| An advantage of assembling it in ISS orbit is that you have
| DEXTRE and a team of spacewalking astronauts available to
| do the unpacking and assembly!
| echelon wrote:
| Or an altogether different design: thousands of cheap,
| totally fungible sensors in an array at the L2 point.
|
| Not only would they be replaceable, but we could increase
| capacity in the future.
| petschge wrote:
| Except that interferometry at IR is still extremely hard.
| findalex wrote:
| Imagine having the replacement gold reflector dish in storage
| somewhere.
| echelon wrote:
| This is our only shot. They didn't replicate the build.
|
| https://www.quora.com/What-would-happen-if-the-James-Webb-Sp...
| [deleted]
| [deleted]
| mikepurvis wrote:
| Relatedly, I'd be curious to know what the split has been of
| the $10B "program cost" in terms of development vs
| manufacturing.
|
| 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.
| 0_____0 wrote:
| If it's anything like the hardware engineering programs I've
| been involved in, at qty=1 the cost is almost all R&D. That
| includes development of processes to build something like
| 1.3m wide ultraprecise beryllium mirror segments...
| bumby wrote:
| Aerospace isn't necessarily like that for a number of
| reasons. A large driver of cost is quality control. For
| example, when a custom part is manufactured it needs to go
| through a number of tests, some of the raw material needs
| to be kept and tracked for future testing, etc. When they
| get shipped they have to be be tracked and handled
| differently, sometimes accelerometers are placed on the
| cargo to measure any shocks, etc. They need to be stored in
| a bonded warehouse, often climate controlled throughout its
| life. All of that control, testing and documentation adds
| to the cost even after R&D is a sunk cost.
| mikepurvis wrote:
| Oh absolutely, but I still wouldn't be surprised if the
| cost for unit 2 was still another half a billion dollars.
| It would be fascinating to know.
| dgrin91 wrote:
| The answer is no for mainly two reasons:
|
| 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
| gibbonsrcool wrote:
| I would love to see a video where one of the engineers on the
| project talked about what would be different if Webb was
| started today. Materials, software, processes, everything!
| p_l wrote:
| A huge design issue that might - or might not - be pushed
| would be the power system.
|
| 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.
| dotnet00 wrote:
| It's worth considering that nowadays we don't really do backup
| copies of satellites/probes because launch is pretty reliable
| by now, especially on rockets that have been flying for a while
| (which is pretty much a requirement to be chosen to launch a
| flagship project like JWST).
|
| 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.
| ufmace wrote:
| Nope. Wouldn't be a good use of money anyways. If it fails, it
| might be because of a design or manufacturing flaw. Better to
| make the new one after we have some idea what went wrong.
| BurningFrog wrote:
| To me, this is a major dysfunction of the NASA model.
|
| 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.
| giantrobot wrote:
| > Why wasn't 5 Hubble telescopes launched? The marginal cost
| for the other 4 must have been vastly smaller than the first.
|
| 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.
| mbfg wrote:
| Is that really true? I'm guessing a big part of the cost is
| figuring out how to actually invent stuff needed for the
| project. That knowledge is now known. That cost is now 0.
| giantrobot wrote:
| > I'm guessing a big part of the cost is figuring out how
| to actually invent stuff needed for the project.
|
| 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.
| bumby wrote:
| > _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._
|
| 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.
| Quenty wrote:
| Just because the knowledge exists in the world doesn't
| mean that you know it. Consolidating knowledge is a non-
| trivial exercise.
| [deleted]
| p_l wrote:
| NASA was trying to get some form of series production for
| base system bus for long distance probes in late 1980s.
|
| 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.
| spyspy wrote:
| Even in high school robotics we built a main chassis and a
| 1:1 spare for testing and hot swapping parts.
| kevin_thibedeau wrote:
| That would require staffing up for the production run and
| then firing them when the contract was finished. There is a
| limited volume of sporadic work available for contractors to
| bid on. Increasing production capacity doesn't increase
| demand. At the end of the day public investment into science
| is always a jobs program first.
| WorldMaker wrote:
| I'd expect the largest part of why is that the marginal costs
| of launches to space unfortunately don't go down. Each launch
| is nearly as expensive as the first. The marginal cost on the
| ground is one thing, and it sounds like Nasa often builds
| things in triplicate or more on the ground, but then uses the
| parts in training exercises or for debugging purposes. Nasa
| probably made three or four equivalents to Hubble. Probably
| plenty more than that to do all the underwater training on
| the incredible repair missions for Hubble that extended its
| lifetime from a projected 5, then a sad "failed mission",
| then finally the 30+ years we should be grateful to have
| gotten at all.
|
| They just have never had the budget in launch costs to ever
| launch more than one.
| Rebelgecko wrote:
| Even in the Hubble days, launch costs were a relatively
| small piece of the pie compared to the costs of actually
| building the thing. I think for Hubble it was less than 10%
| (depending on how you count the servicing missions). For
| Webb it's significantly lower.
| JumpCrisscross wrote:
| > _the marginal costs of launches to space unfortunately
| don 't go down_
|
| Until recently, neither launch nor satellites had economies
| of scale. With reusability, launch does. And with common
| platforms and constellations, satellites are beginning to.
| bumby wrote:
| > _marginal costs of launches to space unfortunately don 't
| go down._
|
| Some aspects certainly do, like ground-support-equipment
| and basic launch infrastructure.
| sho_hn wrote:
| There was. Sort of.
|
| 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.
| thereddaikon wrote:
| Its surprising how many people don't know this all these
| years later. Hubble is repurposed spy satellite. The main
| cost of the vehicle isn't in the spacecraft itself though
| its the optics which are different from those used on
| KH-11. What is good for looking at Russian military bases
| doesn't directly translate to looking at galaxies.
| ceejayoz wrote:
| In fact, the NRO donated two Hubble-like KH-11s in 2012,
| on the condition that they not be used to observe Earth.
|
| https://en.wikipedia.org/wiki/2012_National_Reconnaissanc
| e_O...
|
| One of them forms the base of https://en.wikipedia.org/wi
| ki/Nancy_Grace_Roman_Space_Telesc....
| NikolaeVarius wrote:
| no
| Zealotux wrote:
| I'm wondering why is that, which part of the effort was
| dedicated to research and how much time and money would it
| cost to build a new JWST?
| throwaway64643 wrote:
| I'd imagine they just cannot fabricate the mirrors as many
| as they want. The mirrors, arguably the most important
| parts of any telescope or optical instrument, need delicate
| manufacture due to the required precision. At the end of
| the day, this is not automobile industry.
| guerrilla wrote:
| The reasoning that I heard (and I hope I'm relaying this
| right) was that if it doesn't work then it will most likely
| be because of something that needs to be redesigned, so
| there's no point in producing an exact replica.
| cbm-vic-20 wrote:
| It's also going out pretty far (the L2 Lagrange point on
| the other side of the moon), so they also won't be able
| to perform any manned post-launch repair missions like
| they did with Hubble.
| messe wrote:
| > so they also won't be able to perform any manned post-
| launch repair missions like they did with Hubble.
|
| 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).
| bumby wrote:
| If you consider the human to be part of that hardware,
| it's over 4x the distance that a human has ever
| travelled. There would still be a lot of technical
| problems to be figured out.
| gaius_baltar wrote:
| Having a ship and a launcher capable of reaching the
| telescope is a bit different of being able to service it.
| I understand that just planning and preparing a mission
| on this scale, with current technology and processes,
| would take more time than the service life of the
| telescope itself.
|
| 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.
| messe wrote:
| > Having a ship and a launcher capable of reaching the
| telescope is a bit different of being able to service it.
|
| 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.
| guerrilla wrote:
| Actually I have a question about this. What happens if it
| fails at L2? Is that position like occupied or more
| difficult to deal with from then on?
| huntsman wrote:
| The L2 point is unstable do energy needs to be expended
| to maintain position there.
| Out_of_Characte wrote:
| Solar wind will push it out of L2 and into an orbit
| around the sun. This is already going to happen once JWT
| runs out of fuel to maintain its position.
| bewaretheirs wrote:
| Webb is going to the Sun-Earth L2 (about 1.5 million km
| from Earth), not the Earth-Moon L2 (which is about 61,000
| km from the Moon and 445,000 km from the Earth.
|
| https://webb.nasa.gov/content/about/orbit.html
| mikepurvis wrote:
| I think this assumes a successful launch and some kind of
| issue with the deployment.
|
| The other concern is, of course, what happens if it blows
| up on the launchpad.
| guerrilla wrote:
| Presumably they've actually quantified these
| probabilities and think that the chance of that is
| relatively very low compared to the chance of something
| going wrong in the design. These things are not cheap, so
| it makes sense not to have to make three if the launch
| succeeds and design fails.
| Kaibeezy wrote:
| Ariane 5 appears to have 96% mean reliability. Source:
| _2021 Space Launch Report - Launch Vehicle by Success
| Rate (spacelaunchreport.com)_ -
| https://www.spacelaunchreport.com/log2021.html#rate
|
| https://news.ycombinator.com/item?id=29554274
| JumpCrisscross wrote:
| The footnote about Lewis Point Estimates is super
| interesting.
|
| "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."
| Kaibeezy wrote:
| Concur. You have to see this thread on it in the NASA
| Spaceflight forum -
| https://forum.nasaspaceflight.com/index.php?topic=39928.0
| mikepurvis wrote:
| Oh yes, I totally agree-- this is a very proven rocket,
| and the deployment sequence is very, very much _not_
| proven. So it absolutely makes sense to have gone this
| way.
| CamperBob2 wrote:
| That's assuming that anything that goes wrong in the
| deployment sequence necessitates a clean-sheet redesign
| of the whole thing. No reason to think that.
| mikepurvis wrote:
| But with so many things that _could_ go wrong in such a
| tightly integrated system, it 's impossible to predict
| which components or assemblies may be affected by a
| partial redesign.
| CamperBob2 wrote:
| If you say so.
| sho_hn wrote:
| I think OP means "what if the rocket fails".
|
| 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.
| revax wrote:
| Also Ariane 5 is one of the most reliable rocket capable
| of launching JWST on the correct orbit.
| _joel wrote:
| I've never been so nervous for a launch in my life.
| Mountain_Skies wrote:
| I'm more nervous about the deployment. There are so many things
| that can go wrong after the launch but before it is fully
| operational.
| fortysixdegrees wrote:
| Although I guess once it's in orbit, and major problems could
| be sorted out over the following years with manned repair
| missions, like they did with hubble
| FourHand451 wrote:
| Not really, unfortunately. Webb will be much further from
| Earth than Hubble is, so as far as I'm aware a human
| mission to go repair it isn't really considered an option.
|
| https://www.nasa.gov/topics/universe/features/webb-l2.html
| ravi-delia wrote:
| If Starship delivers on its deltaV and economic promises,
| it's at least feasible, although that's a big if.
| Besides, if you can boost something the mass of the
| telescope with twice the volume and much less money, why
| would you bother fixing the one you have?
| BbzzbB wrote:
| They've worked on the design for over 20 years AFAICT.
| Even tho Starship will enable bigger and better
| telescopes, if there's a repairable problem and it is
| within reach, would be odd to just bail on JWST when the
| whole design/build process of the next gen will likely be
| a very long endeavor.
|
| https://en.wikipedia.org/wiki/James_Webb_Space_Telescope#
| His...
| ravi-delia wrote:
| I think it's fair to say that with lower stakes you can
| definitely take less time on each telescope. The Webb is
| a miracle of engineering, but a lot of that miracle goes
| towards squeezing it into a pretty narrow fairing.
| BbzzbB wrote:
| Sure, I'd also expect (as an outsider) that new
| iterations will be quicker from this new knowledge base
| and a 9m x 18m payload rocket, I'm just saying if there
| is a way to fix broken JWST I see no reason to not even
| try and wait out the next gen. They are not mutually
| exclusive.
| NobodyNada wrote:
| > major problems could be sorted out over the following
| years with manned repair missions, like they did with
| hubble
|
| 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.
| retrac wrote:
| Even then, it's quite possible a human mission beyond LEO
| to repair the JWST would end up costing more than just
| building a replacement telescope.
| _joel wrote:
| 178 things!
| bumby wrote:
| Ohh, you optimist :-)
|
| > _" 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-...
| Ostrogodsky wrote:
| step 138: npm run
| baggy_trough wrote:
| I never thought the Mars rover sky crane would work, but it
| did!
| _joel wrote:
| I think most of the engineers on the project didn't either,
| what did Adam Steltzner, something like "It was the least
| worst option out of a lot of bad options".
|
| I'm sure there's a commentary there on modern life, but sod
| that, this far cooler than any addage :)
| remram wrote:
| When's the launch date? I couldn't find a definitive answer, as
| both December 18 and December 22 are listed.
| _Microft wrote:
| December 22, delays are always possible but it's not going to
| launch earlier than that ("no earlier than" is often
| abbreviated "NET" in that context).
|
| https://jwst.nasa.gov/content/webbLaunch/countdown.html
| stanmancan wrote:
| December 22nd; they were aiming for the 18th but there was a
| small issue that required a bit of additional testing so they
| pushed it back to the 22nd.
| gizmo385 wrote:
| Wasn't the most recent 18 -> 22 delay because they dropped
| it?
| progbits wrote:
| They didn't drop it but a clamp released unexpectedly
| during some operation and it caused vibrations in the
| telescope. At that time they didn't have sensors attached
| that would be able to confirm if the vibration was within
| specified tolerances so manual inspection of sensitive
| components had to be done again.
|
| Glad to hear it went well and we are back on track!
| gdecaso wrote:
| Yep.
___________________________________________________________________
(page generated 2021-12-14 23:00 UTC)