This data point is not useful without knowing the failure rate for each of them.
For example, the Sun is a single point of failure for us each day. ...but the odds of the Sun being destroyed per day are so infinitesimally small, that it's not meaningful to say I have a single point of failure each day for the next 20,000 days.
That’s a logical albeit unhelpful argument. My observation of how engineering is done and the economic pressures involved make me think that such cost cutting is inevitable. So the short term “we’ll just make this single point of failure component more reliable” is not an effective strategy as “design in depth” that assumes any single component will fail. It can be more expensive but in some ways (maintenance, up-front cost) but can also be cheaper since the individual components don’t need as much testing/validation/reliability.
That being said, engineering is all about trade offs so the takeaway I have from something like this is blind faith/hope that the domain experts make these decisions better than an outsider (me) and that when mistakes are made they’re corrected in the longer-term. I don’t know a better way than that.
This is fair. Single point of failures denote a severity (loss of mission) but risk is defined as severity x probability. To extend your example to the extreme, everything on the JWST has a failure probability > 0, even the systems with redundancies.
What ends up happening is each failure is plotted on a severity x probability matrix with a resulting score. Depending on the requirements, the exact probability category thresholds may be defined quantitatively (e.g. 1/10,000 chance) or they may be more qualitative (e.g., ‘likely’ vs. ‘may happen’ vs. ‘improbable’). The resulting risk has to accepted by someone (usually a program or project manager). To your point, they have obviously found each to be an acceptable (but perhaps uncomfortable) risk. Some projects will define the acceptable level of risk at the requirements stage to drive design (e.g., no single points of failure that can result in loss of crew). With all that said, it is still an abnormally high number of single point failures in a complex system and reliability is generally not linearly related to complexity (just think about what happens to cyclomatic complexity as you add more variables and the resulting number of test cases you need for full coverage)
In my opinion, the real dangerous part of this process is that humans are notoriously poor at thinking in probabilistic terms. Challenger, Columbia, EVA 23 etc. are all attributable, in part, to bad assessments of probability. Human biases are all but guaranteed to affect these probabilities and thus affect our understanding of the associated risk.
I happen to know someone working in the area of reliability and testing on JWT. Personally, I couldn't take the stress. The design as you point out seems to be unlike other missions where the very design limits failures. My understanding is the people who made these decisions are long gone, leaving the current team to make it work or $20B and two decades will be flushed down the drain. I think people on this team are aging at 5x real-time.
I am quite skeptical that it will take place this year. The project is already 14 years late and ~20x over the original budget. I expect them to announce a shocking delay later this year, blaming COVID.
14 years "late" is not exactly accurate as the initial time projections were based upon full funding from the initial moments of the project - which was never a realistic goal.
Similarly, the 20x budget overrun number makes two errors - 1. that the initial numbers were in today's inflation adjusted dollars (which they were not), and that project scope remained exactly the same - which it has not. Numerous aspects of the telescope have been enhanced/improved to accommodate additional science.
The project was supposed to take 10 years and is already at 24! That's simply atrocious, and saying that they didn't get everything they wanted to is a poor excuse.
I ran the numbers for inflation adjustment, and 500MM in 1997 is equivalent to ~811MM today. That means the project is between 12x-20x over budget... not much of an improvement in my mind.
I am looking so much forward to this. Hubble has been launched in 1990 and look what insane amount of great science and pictures it brought. JWT should be a huge step upwards from this, especially as it looks into different wavelengths. This could deliver an amazing amount of science.
I also hope, that if the Starship becomes operational, it could deliver much larger telescopes to space and start a new era of astronomy.
I really feel space tech is gonna be the next big thing going forward, but I have zero clue about how to get involved. It seems like one of those things where you really need to either be some government agency or have a PhD in it or something.
Insanely hard - from an engineer prospective - because there is a big gap between software disciplines and, ughm, "the real world". When you're pushing bits, today it's easy to forget about the times when computers were quite unreliable, from the hardware point of view. Bad contacts? Unreliable memory bits? Overheating parts? Magnetic tape which loses data and paper media which breaks? Today most of this is factored away and engineers largely operate with logic. Try to do hardware projects - even easy Arduino-based designs will give you a glimp of difficulties you're going to get with space technology, and if you're trying something modestly interesting...
Pretty easy is because "rocket science isn't rocket science". It's technology invented more than a century ago - converging-diverging nozzle was invented about 150 years ago, about 120 years ago Tsiolkovsky wrote about liquid hydrogen fuel and multistage rockets, more than 90 years ago Goddard flew his first rockets, almost 80 years ago von Braun was already working on V-2, and this year we're celebrating 60th anniversary of Spootnik. A great deal of efforts went into perfection of rocketry, and now we know a lot - that's a big part of the reason why SpaceX moves so fast - and can do a lot.
Now you can have a nano-launcher startup for less than 100 million dollars - may be way less - which just couple of decades ago is unheard of. More, there are competitions - X Prize for flight 100 km up, Northrop Grumman Lunar Lander Challenge, Google Lunar Prize, and now, say, NASA's https://breaktheicechallenge.com/ - where you can participate with much smaller barrier to entry. The webinar from this last challenge - https://www.youtube.com/watch?v=UXgdEDBTPJE - contains references on other competitions NASA is hosting.
So, to conclude, if you're an engineering mind, especially capable of working outside of applied math of programming, the possibilities are certainly there to try in growing space industry.
There's still going to be a lot of room at the bottom, e.g. the people building the (say) Control algorithms for the rocket need to have testing infrastructure run for them.
A PhD isn't as necessary as you might think, it really depends whether you're doing front-line engineering or a more abstract work - e.g. I would assume the people specifying SpaceX's self-landing system will have PhDs in control theory or similar but the people making it happen beneath are mere mortals.
That being said, I am currently applying to do what I believe would be referred to as a paid-internship in the US, and it's quite difficult breaking into traditional engineering roles from my background as it's quite difficult to prove you'll be useful as a Theoreticsl Physics student (/ Compiler person) because I don't have any formal credit in a lot of the things I do have non-trivual knowledge about.
Jim Keller doesn't have a PhD, and he "only" went to Penn State and he is now a god amongst men, so there's hope for us all (hopefully).
Want to get into the applied side and build/test aerospace equipment? You don’t even necessarily need an advanced degree. Don’t discount how many contractors do this work for the government either. Lockheed, Boeing, Honeywell, Jacobs, etc. all need engineers to do the applied science. Don’t overlook tangential roles like quality either because the industry is littered with them.
If you want to do research, you’ll probably need an advanced degree and possibly time in academic research.
Bear in mind space tech isn’t all about the rockets, it’s also about what they take up there. If Starship pans out, the market for satellite hardware, orbital habitats, space probes and associated software and services is going to explode.
In a lot of threads about this people seem to think Boeing, Lockheed, etc are finished because they can’t compete with SpaceX. On the contrary, the demand for their skills at building payload hardware is about to expand massively. Somebody’s going to need to build all the infrastructure and systems for these Moon and Mars cities.
Basically all space companies (oldspace, newspace) hire software folks. Some specific jobs might require PhDs, but most don't. Flight software sometimes has requirements for certain experience (e.g. Embedded). However, flight software is a surprisingly small sliver of all the space related software that gets written. Even though it's outer space they still need GUIs for ground systems, CRUD apps for handling downlinked data, WebGL people to build fancy visualizations, etc
As mentioned above and below, software development skills are always in demand. If you are really that interested, you can get involved with our company :)
It’s not for the faint of heart. The consequences of failure are equivalent to setting off a bomb. You can’t just tweak a line of code and recompile. You have to know how to manage the risk.
Advanced degrees help. Operational experience helps. I have a master’s and flight hours, for example.
If you’re serious about aerospace, you’ll make your own way. Piece of advice though: don’t tell an interviewer you’re getting into this field just because it’s the next big thing.
One notable omission is the launch of Landsat 9 [0]. Landsat 9 is expected to be launched by NASA in September 2021 and will hopefully continue the Landsat program's uninterrupted, nearly 50-year remote sensing history [1].
The orbital debris problem mentioned at the end is really scary in the medium-long term. We're used to mistakes being relatively self correcting down here. A bridge falls over, and it's terrible, but when it hits the ground, it's "stable" again. Then you can learn from your mistakes and try again. With orbital debris, on the other hand, if there was some day a chain reaction, could take ages to sufficiently deorbit, like a building that keeps falling for years or decades (or even generations! https://en.wikipedia.org/wiki/Kessler_syndrome)
When really scares me is how easy it would be for a malicious actor to kickstart the process. Imagine a cylinder filled with ball bearings painted black and an explosive device in the middle. Launch that to a mega-constellation altitude and at the very least that orbital altitude is no longer inhabitable.
Yup, magnetic drag is a definitely a thing, see https://agupubs.onlinelibrary.wiley.com/doi/full/10.1029/202... . To have a real effect the magnet would need to be ginormous, specifically effectiveness would be proportional to a ratio of distance between magnet poles and the target object. The distance between poles is important because if both poles are equidistant to an object the net effect would be 0.
So with that constraint in mind I doubt anything we can do at our current Kardashev scale can top Earths magnetic field. (Note the above is for a permanent magnet, it is possible that electromagnet would fare better. However given that magnetic force strength decays proportionally to distance squared, a magnet powerful enough to be effective would mess up real satellites too.
The ball bearings would suck for optical tracking but, most stuff is tracked by radar so the black paint really wouldn't do much more than add to the debris field as radiation would eventually cause it to flake off the metal and solar bleaching would turn it back to white.
As a tangent, that's something that I found interesting and understated about the movie "Gravity". You get drawn into the story of the main character, but in the background you're seeing the end of human access to space (at least for the foreseeable future).
Hi Everyone. I am the co-founder of Payload. We are a free weekly newsletter covering the business and policy of space. We cover topics like this all the time in our writing.
43 comments
[ 1.8 ms ] story [ 144 ms ] threadhttp://spaceref.com/news/viewsr.html?pid=51617
For example, the Sun is a single point of failure for us each day. ...but the odds of the Sun being destroyed per day are so infinitesimally small, that it's not meaningful to say I have a single point of failure each day for the next 20,000 days.
That being said, engineering is all about trade offs so the takeaway I have from something like this is blind faith/hope that the domain experts make these decisions better than an outsider (me) and that when mistakes are made they’re corrected in the longer-term. I don’t know a better way than that.
What ends up happening is each failure is plotted on a severity x probability matrix with a resulting score. Depending on the requirements, the exact probability category thresholds may be defined quantitatively (e.g. 1/10,000 chance) or they may be more qualitative (e.g., ‘likely’ vs. ‘may happen’ vs. ‘improbable’). The resulting risk has to accepted by someone (usually a program or project manager). To your point, they have obviously found each to be an acceptable (but perhaps uncomfortable) risk. Some projects will define the acceptable level of risk at the requirements stage to drive design (e.g., no single points of failure that can result in loss of crew). With all that said, it is still an abnormally high number of single point failures in a complex system and reliability is generally not linearly related to complexity (just think about what happens to cyclomatic complexity as you add more variables and the resulting number of test cases you need for full coverage)
In my opinion, the real dangerous part of this process is that humans are notoriously poor at thinking in probabilistic terms. Challenger, Columbia, EVA 23 etc. are all attributable, in part, to bad assessments of probability. Human biases are all but guaranteed to affect these probabilities and thus affect our understanding of the associated risk.
https://en.wikipedia.org/wiki/James_Webb_Space_Telescope#Cos...
https://xkcd.com/2014/
Similarly, the 20x budget overrun number makes two errors - 1. that the initial numbers were in today's inflation adjusted dollars (which they were not), and that project scope remained exactly the same - which it has not. Numerous aspects of the telescope have been enhanced/improved to accommodate additional science.
I ran the numbers for inflation adjustment, and 500MM in 1997 is equivalent to ~811MM today. That means the project is between 12x-20x over budget... not much of an improvement in my mind.
I also hope, that if the Starship becomes operational, it could deliver much larger telescopes to space and start a new era of astronomy.
Insanely hard - from an engineer prospective - because there is a big gap between software disciplines and, ughm, "the real world". When you're pushing bits, today it's easy to forget about the times when computers were quite unreliable, from the hardware point of view. Bad contacts? Unreliable memory bits? Overheating parts? Magnetic tape which loses data and paper media which breaks? Today most of this is factored away and engineers largely operate with logic. Try to do hardware projects - even easy Arduino-based designs will give you a glimp of difficulties you're going to get with space technology, and if you're trying something modestly interesting...
Pretty easy is because "rocket science isn't rocket science". It's technology invented more than a century ago - converging-diverging nozzle was invented about 150 years ago, about 120 years ago Tsiolkovsky wrote about liquid hydrogen fuel and multistage rockets, more than 90 years ago Goddard flew his first rockets, almost 80 years ago von Braun was already working on V-2, and this year we're celebrating 60th anniversary of Spootnik. A great deal of efforts went into perfection of rocketry, and now we know a lot - that's a big part of the reason why SpaceX moves so fast - and can do a lot.
Now you can have a nano-launcher startup for less than 100 million dollars - may be way less - which just couple of decades ago is unheard of. More, there are competitions - X Prize for flight 100 km up, Northrop Grumman Lunar Lander Challenge, Google Lunar Prize, and now, say, NASA's https://breaktheicechallenge.com/ - where you can participate with much smaller barrier to entry. The webinar from this last challenge - https://www.youtube.com/watch?v=UXgdEDBTPJE - contains references on other competitions NASA is hosting.
So, to conclude, if you're an engineering mind, especially capable of working outside of applied math of programming, the possibilities are certainly there to try in growing space industry.
Gagarin's flight, of course.
A PhD isn't as necessary as you might think, it really depends whether you're doing front-line engineering or a more abstract work - e.g. I would assume the people specifying SpaceX's self-landing system will have PhDs in control theory or similar but the people making it happen beneath are mere mortals.
That being said, I am currently applying to do what I believe would be referred to as a paid-internship in the US, and it's quite difficult breaking into traditional engineering roles from my background as it's quite difficult to prove you'll be useful as a Theoreticsl Physics student (/ Compiler person) because I don't have any formal credit in a lot of the things I do have non-trivual knowledge about.
Jim Keller doesn't have a PhD, and he "only" went to Penn State and he is now a god amongst men, so there's hope for us all (hopefully).
Want to get into the applied side and build/test aerospace equipment? You don’t even necessarily need an advanced degree. Don’t discount how many contractors do this work for the government either. Lockheed, Boeing, Honeywell, Jacobs, etc. all need engineers to do the applied science. Don’t overlook tangential roles like quality either because the industry is littered with them.
If you want to do research, you’ll probably need an advanced degree and possibly time in academic research.
In a lot of threads about this people seem to think Boeing, Lockheed, etc are finished because they can’t compete with SpaceX. On the contrary, the demand for their skills at building payload hardware is about to expand massively. Somebody’s going to need to build all the infrastructure and systems for these Moon and Mars cities.
[1] https://www.reddit.com/r/spacex/comments/gxb7j1/we_are_the_s...
https://youtu.be/t_3bckhV_YI
Advanced degrees help. Operational experience helps. I have a master’s and flight hours, for example.
If you’re serious about aerospace, you’ll make your own way. Piece of advice though: don’t tell an interviewer you’re getting into this field just because it’s the next big thing.
[0]: https://landsat.gsfc.nasa.gov/landsat-9/landsat-9-overview [1]: https://landsat.gsfc.nasa.gov/landsat-1-3/landsat-1
When really scares me is how easy it would be for a malicious actor to kickstart the process. Imagine a cylinder filled with ball bearings painted black and an explosive device in the middle. Launch that to a mega-constellation altitude and at the very least that orbital altitude is no longer inhabitable.
So with that constraint in mind I doubt anything we can do at our current Kardashev scale can top Earths magnetic field. (Note the above is for a permanent magnet, it is possible that electromagnet would fare better. However given that magnetic force strength decays proportionally to distance squared, a magnet powerful enough to be effective would mess up real satellites too.
How else to clean a vacuum but with a vacuum cleaner? :-)
If you are interested, sign up here: https://www.payloadresearch.com/