-
#1260 by clongton on 28 Feb, 2020 18:14
-
Every single vehicle you've ever ridden in is developed to some kind of safety standard. Latitude is given on NON-safety functions, ...
In my opinion there are no non-safety functions wrt a human rated spacecraft. Everything must be as close to perfection as is humanly possible. All the other vehicles you mentioned, if they failed, at least failed on earth, where there is air to breath and atmospheric protection from radiation and plasma. If your automobile fails, you can always get a tow truck and a taxi to take you home. If your spacecraft fails in some way on orbit and can't get back, you die. If your module separation software fails because someone couldn't be bothered to check the code, you die. If you die you don't get to come back and give it another go. What bothers the blazes out of me is that Boeing has given the appearance, true or untrue, that profits are a higher consideration, and they don't seem to care about that perception. Personally I want to see total systems integration testing, using an actual flight worthy Atlas-V, followed by a 2nd OFT, and I want Boeing to pay for it with absolutely NO financial compensation from NASA. -
#1261 by Vettedrmr on 28 Feb, 2020 18:19
-
Chuck,
I don't know that I would go so far as to say "None" (maybe backup lighting, for example?), but the number is surely going to be small. An example on an aircraft would be the cockpit voice recorder/flight data recorder. Surely important, but if they fail the plane won't crash.
Have a good one,
Mike -
#1262 by mooie74 on 28 Feb, 2020 19:13
-
Likewise just followed on Twitter- any indication on (if NASA requests a re-flight of OFT) whether that is cost plus or if Boeing will pay for it?
-
#1263 by Lars-J on 28 Feb, 2020 19:14
-
Likewise just followed on Twitter- any indication on (if NASA requests a re-flight of OFT) whether that is cost plus or if Boeing will pay for it?
This suggests it could be on Boeing's dime... They are preparing for the possibility:
https://spacenews.com/boeing-takes-410-million-charge-to-cover-potential-additional-commercial-crew-test-flight/
But that would not stop them from seeking additional funds from NASA, presumably. -
#1264 by dglow on 28 Feb, 2020 20:10
-
Every single vehicle you've ever ridden in is developed to some kind of safety standard. Latitude is given on NON-safety functions, ...
In my opinion there are no non-safety functions wrt a human rated spacecraft. Everything must be as close to perfection as is humanly possible. [...]
That strikes me as a dangerous approach. Every set of subsystems exists within a hierarchy of risk, and time is finite. If we treat everything as equivalent and accept nothing less than "perfection" we end up shortchanging critical areas that demand our greater attention. A suboptimal allocation of resources follows resulting in less safety overall.
TL;DR: Nothing is absolute.
edit: typo -
#1265 by groknull on 28 Feb, 2020 20:57
-
Every single vehicle you've ever ridden in is developed to some kind of safety standard. Latitude is given on NON-safety functions, ...
In my opinion there are no non-safety functions wrt a human rated spacecraft. Everything must be as close to perfection as is humanly possible. All the other vehicles you mentioned, if they failed, at least failed on earth, where there is air to breath and atmospheric protection from radiation and plasma. If your automobile fails, you can always get a tow truck and a taxi to take you home. If your spacecraft fails in some way on orbit and can't get back, you die. If your module separation software fails because someone couldn't be bothered to check the code, you die. If you die you don't get to come back and give it another go. What bothers the blazes out of me is that Boeing has given the appearance, true or untrue, that profits are a higher consideration, and they don't seem to care about that perception. Personally I want to see total systems integration testing, using an actual flight worthy Atlas-V, followed by a 2nd OFT, and I want Boeing to pay for it with absolutely NO financial compensation from NASA.
My bold above.
The Boeing Mission / Vision / Values statement explicitly includes value to shareholders. In three places, no less. "Top-quartile Performance and Returns", "reward investors with increasing shareholder value", "Deliver Superior Value to Customers, Employees, Shareholders, Communities and Partners":
https://www.boeing.com/principles/vision.page
Northrop Grumman mentions shareholder value once. "We believe that putting our values into practice creates long-term benefits for shareholders, customers, employees, suppliers and the communities we serve." That sentence references the list of values, but shareholder benefit is not explicitly in the list of values:
https://www.northropgrumman.com/corporate-responsibility/ethics-and-business-conduct/
The Lockheed-Martin Mission / Vision / Values statement does not reference shareholder value at all:
https://www.lockheedmartin.com/en-us/who-we-are.html
SpaceX has a mission statement on the website, but it does not explicitly include vision and value statements on that page. Nothing about shareholder value:
https://www.spacex.com/about
The IBM Mission / Vision / Values are listed a little more obliquely. No reference to shareholders:
https://www.ibm.com/ibm/us/en/?lnk=fai-maib-usen
https://www.ibm.com/ibm/values/us/?mhsrc=ibmsearch_a&mhq=mission%20statement
Raytheon. Does not explicitly include shareholder value:
https://www.raytheon.com/ourcompany/ourculture/vv
The caveat in all of this is that companies don't always adhere to their stated mission, vision, and values.
e.g. "Respect, Integrity, Communication, Excellence"... on the lobby wall at Enron.
The question then becomes one of asking if and how well a particular company adheres to their mission, vision and value statements.
In reference to the quoted post, what is interesting to me is that Boeing explicitly (with intent) included shareholder value in their statement more than once, and prominently.
-
#1266 by mme on 28 Feb, 2020 20:57
-
Even the test they ran seems to have been incomplete from a validation standpoint. According to at least one source the MET is suppose to be read during the terminal count. So they either didn't test the state of the MET at the end of the test (it should be 0-ish) or they got lucky and it was always in the expected range.Can somebody with industry knowledge describe more precisely what would/should have been involved in "full integration testing" between the Starliner and Atlas?
Coming from a software perspective, I cannot fathom why any interaction crossing such disparate hardware boundaries wouldn't have been tested with full production code running on full production hardware.
So please, disabuse – or abuse – me of my misunderstanding: does this report imply that Boeing did not bother to park an Altas V nav computer next to the Starliner and run through mission simulations? And barring that could they not have done so after stacking? (late IMO, but nonetheless an opportunity for 'fully integrated' testing)
Not only were simulation run but keep in mind in November they had the full hardware matted and went through a full count down. Up to but to liftoff. Doh! -
#1267 by leovinus on 28 Feb, 2020 21:45
-
While we all want Boeing to succeed, the talk in the event today ( and the previous one) of more checking, more simulation, more everything makes me very nervous. I sure hope Boeing has read “ The mythical man-month” by Fred Brooks. One takeaway “adding more manpower to a late project makes it later”. With the emerging evidence pointing to the use of software processes more like the 80s “waterfall”, which do not scale and are never formally complete, I hope they see the light and add more Silicon Valley. Innovate
-
#1268 by ThePonjaX on 28 Feb, 2020 23:37
-
And, sorry, but I almost laughed when you said Starliner "is close to working like it should." Other than the latent fault that would have likely lost the vehicle (and crew if they were on board) if the original fault hadn't occurred. Other than the main chute that wasn't connected on the pad abort test article. How about not testing easily testable things? How expensive would it have been if Starliner had been lost? Look at the impact to SpaceX when DM-1 exploded, and that WAS a test.
I think you are missing the forest for the trees. Nothing has indicated any failure of the design. In fact, in many ways the design (e.g., the prop system that was heavily over used) did quite well. What you are pointing out are PROCESS problems. Not testing the software. Not double checking the parachutes properly. Launch, navigation, maneuvering, on board systems, reentry, landing bags...all worked extremely well. Boeing will have to address those process issues - but that can all be done on the ground and will have an incredible amount of oversight now. And that is why I strongly suspect the next mission will be crewed. Remember, OFT was a test, soup to nuts. Boeing decided how much risk they were willing to take.
(Bolding mine)
Sorry but I need to pickup this because this is a big misconception about the importance of software on modern industry.
A lot of people thinks the hardware is the important thing, the software is just "something extra".
Sorry but you're missing totally the point. A good software can compensate for a "bad" hardware not the other way around.
The best hardware can be turned on a pile of trash for a bad software.
As a common example the same computer on your house has very differently capabilities when it run Microsoft Windows or a Linux distribution.
You have the example of Tesla, which the same card with better software is a better car. Another example is Fuji with photographic cameras. They keep updating the software and very old cameras for our standards are still improving.
Which is the conclusion: Software is hard and takes time and money develop it right. A lot of time and money. The importance of write the good code was highlighted for Elon recently on a interview: 1 point for write a line of code, 2 points for take away a line. Less lines of code are good.
At this point of Starliner troubles and after the conference I think the difference is in the way both companies develop software. For Boeing the software is "something extra" which control the hardware, for Spacex is the heart of the product and has to be tightly integrated with the hardware. It's something which is often mentioned as an advantage of Tesla over the traditional car companies.
About the Nothing has indicated any failure of the design well I don't think so. Why? For example the Starliner has to push herself to the right orbit and the Dragon no. Why is this important? Well they have to write thousands of line of code to control that part of the flight. A decision of design which probably implies a lot of more of code has to be written, controlled and tested. I'd love to know how many lines of code the software of Dragon has.
PD: Sorry for my English, I'm not a native English speaker I hope you understand. -
#1269 by SteveU on 28 Feb, 2020 23:51
-
ThePonjaX
I had highlighted the same text-but you stated your case and concerns about erioladastra’s statement much more politely and eloquently than I did. Thanks for making such a strong case.
BTW, don’t ever feel the need to apologize for your english writing skills. You’re better than a lot of us, myself included.
Besides, when reading a well framed argument, errors such as typos, grammar, spelling tend to matter little. -
#1270 by erioladastra on 28 Feb, 2020 23:57
-
(Bolding mine)
And, sorry, but I almost laughed when you said Starliner "is close to working like it should." Other than the latent fault that would have likely lost the vehicle (and crew if they were on board) if the original fault hadn't occurred. Other than the main chute that wasn't connected on the pad abort test article. How about not testing easily testable things? How expensive would it have been if Starliner had been lost? Look at the impact to SpaceX when DM-1 exploded, and that WAS a test.
I think you are missing the forest for the trees. Nothing has indicated any failure of the design. In fact, in many ways the design (e.g., the prop system that was heavily over used) did quite well. What you are pointing out are PROCESS problems. Not testing the software. Not double checking the parachutes properly. Launch, navigation, maneuvering, on board systems, reentry, landing bags...all worked extremely well. Boeing will have to address those process issues - but that can all be done on the ground and will have an incredible amount of oversight now. And that is why I strongly suspect the next mission will be crewed. Remember, OFT was a test, soup to nuts. Boeing decided how much risk they were willing to take.
That did make me laugh out loud.
The software was absolute crap. Couldn’t figure out where it was because of one clock issue. Proceeded to almost destroy the RCS system until ground control intervened.
Then, to put icing on the cake, they were going to pull data from the wrong lookup table, a mistake that could have resulted in LOV. This last one is the most grievous to me. With a modicum of documentation (like a descriptive name for the table) this issue should have been found long before the the software ever left the lab.
(Edit - spelling]
OK - thought about this over night - and NO - I don't want to change it!
(Edit to fix - LOV not LOM - LOM had already happened - Thanks - kdhilliard )
Again you are still conflating process with design. If the software had actually matched the design then things would have worked much better. Errors in the process of developing the software and errors in the process of testing said software are different. -
#1271 by erioladastra on 28 Feb, 2020 23:58
-
And, sorry, but I almost laughed when you said Starliner "is close to working like it should." Other than the latent fault that would have likely lost the vehicle (and crew if they were on board) if the original fault hadn't occurred. Other than the main chute that wasn't connected on the pad abort test article. How about not testing easily testable things? How expensive would it have been if Starliner had been lost? Look at the impact to SpaceX when DM-1 exploded, and that WAS a test.
I think you are missing the forest for the trees. Nothing has indicated any failure of the design. In fact, in many ways the design (e.g., the prop system that was heavily over used) did quite well. What you are pointing out are PROCESS problems. Not testing the software. Not double checking the parachutes properly. Launch, navigation, maneuvering, on board systems, reentry, landing bags...all worked extremely well. Boeing will have to address those process issues - but that can all be done on the ground and will have an incredible amount of oversight now. And that is why I strongly suspect the next mission will be crewed. Remember, OFT was a test, soup to nuts. Boeing decided how much risk they were willing to take.
(Bolding mine)
Sorry but I need to pickup this because this is a big misconception about the importance of software on modern industry.
A lot of people thinks the hardware is the important thing, the software is just "something extra".
Sorry but you're missing totally the point. A good software can compensate for a "bad" hardware not the other way around.
The best hardware can be turned on a pile of trash for a bad software.
As a common example the same computer on your house has very differently capabilities when it run Microsoft Windows or a Linux distribution.
You have the example of Tesla, which the same card with better software is a better car. Another example is Fuji with photographic cameras. They keep updating the software and very old cameras for our standards are still improving.
Which is the conclusion: Software is hard and takes time and money develop it right. A lot of time and money. The importance of write the good code was highlighted for Elon recently on a interview: 1 point for write a line of code, 2 points for take away a line. Less lines of code are good.
At this point of Starliner troubles and after the conference I think the difference is in the way both companies develop software. For Boeing the software is "something extra" which control the hardware, for Spacex is the heart of the product and has to be tightly integrated with the hardware. It's something which is often mentioned as an advantage of Tesla over the traditional car companies.
About the Nothing has indicated any failure of the design well I don't think so. Why? For example the Starliner has to push herself to the right orbit and the Dragon no. Why is this important? Well they have to write thousands of line of code to control that part of the flight. A decision of design which probably implies a lot of more of code has to be written, controlled and tested. I'd love to know how many lines of code the software of Dragon has.
PD: Sorry for my English, I'm not a native English speaker I hope you understand.
Another factor is that Boeing knowingly accepted more risk because they, by choice, used the flight control team as their backstop. -
#1272 by dalek on 29 Feb, 2020 00:38
-
Re MET- He says near the end that because of a software bug the MET was read at around T-17 HOURS on launch day and the simuation wasn't ran long enough to notice the bug!!! Sounds like they don't have any sanity checks in their code!
-
#1273 by lonestriker on 29 Feb, 2020 03:51
-
(Bolding mine)
Sorry but I need to pickup this because this is a big misconception about the importance of software on modern industry.
A lot of people thinks the hardware is the important thing, the software is just "something extra".
Sorry but you're missing totally the point. A good software can compensate for a "bad" hardware not the other way around.
The best hardware can be turned on a pile of trash for a bad software.
As a common example the same computer on your house has very differently capabilities when it run Microsoft Windows or a Linux distribution.
You have the example of Tesla, which the same card with better software is a better car. Another example is Fuji with photographic cameras. They keep updating the software and very old cameras for our standards are still improving.
Which is the conclusion: Software is hard and takes time and money develop it right. A lot of time and money. The importance of write the good code was highlighted for Elon recently on a interview: 1 point for write a line of code, 2 points for take away a line. Less lines of code are good.
At this point of Starliner troubles and after the conference I think the difference is in the way both companies develop software. For Boeing the software is "something extra" which control the hardware, for Spacex is the heart of the product and has to be tightly integrated with the hardware. It's something which is often mentioned as an advantage of Tesla over the traditional car companies.
About the Nothing has indicated any failure of the design well I don't think so. Why? For example the Starliner has to push herself to the right orbit and the Dragon no. Why is this important? Well they have to write thousands of line of code to control that part of the flight. A decision of design which probably implies a lot of more of code has to be written, controlled and tested. I'd love to know how many lines of code the software of Dragon has.
PD: Sorry for my English, I'm not a native English speaker I hope you understand.
Another factor is that Boeing knowingly accepted more risk because they, by choice, used the flight control team as their backstop.
And we saw how spectacularly this approach failed when that flight control team failed to contact the spacecraft as a backstop. I had actually never heard this aspect of the Starliner design. That part of it's architecture was to have humans in the loop as standard operating procedure to fix issues? Boeing made the excuse initially that had astronauts been onboard, they could have fixed the first MET thruster misfirings. If they're going to rely on crew or ground-based human actions as SOP, they need to do a lot more certifications than SpaceX. It seems like cheating to me that you just add "a human will fix this" as a solution to your spacecraft misbehaving.
-
#1274 by Torbjorn Larsson, OM on 29 Feb, 2020 14:05
-
(Bolding mine)
Sorry but I need to pickup this because this is a big misconception about the importance of software on modern industry.
A lot of people thinks the hardware is the important thing, the software is just "something extra".
Sorry but you're missing totally the point. A good software can compensate for a "bad" hardware not the other way around.
The best hardware can be turned on a pile of trash for a bad software.
As a common example the same computer on your house has very differently capabilities when it run Microsoft Windows or a Linux distribution.
You have the example of Tesla, which the same card with better software is a better car. Another example is Fuji with photographic cameras. They keep updating the software and very old cameras for our standards are still improving.
Which is the conclusion: Software is hard and takes time and money develop it right. A lot of time and money. The importance of write the good code was highlighted for Elon recently on a interview: 1 point for write a line of code, 2 points for take away a line. Less lines of code are good.
At this point of Starliner troubles and after the conference I think the difference is in the way both companies develop software. For Boeing the software is "something extra" which control the hardware, for Spacex is the heart of the product and has to be tightly integrated with the hardware. It's something which is often mentioned as an advantage of Tesla over the traditional car companies.
About the Nothing has indicated any failure of the design well I don't think so. Why? For example the Starliner has to push herself to the right orbit and the Dragon no. Why is this important? Well they have to write thousands of line of code to control that part of the flight. A decision of design which probably implies a lot of more of code has to be written, controlled and tested. I'd love to know how many lines of code the software of Dragon has.
PD: Sorry for my English, I'm not a native English speaker I hope you understand.
Another factor is that Boeing knowingly accepted more risk because they, by choice, used the flight control team as their backstop.
And we saw how spectacularly this approach failed when that flight control team failed to contact the spacecraft as a backstop. I had actually never heard this aspect of the Starliner design. That part of it's architecture was to have humans in the loop as standard operating procedure to fix issues? Boeing made the excuse initially that had astronauts been onboard, they could have fixed the first MET thruster misfirings. If they're going to rely on crew or ground-based human actions as SOP, they need to do a lot more certifications than SpaceX. It seems like cheating to me that you just add "a human will fix this" as a solution to your spacecraft misbehaving.
This "software can compensate" [this is a quote out of its proper context, but I think the new meaning is reflected below] and "rely on crew or ground-based human actions" reminded me of the Boeing 737 MAX problems (yes, what else?):QuoteThe revised design allowed MCAS to trigger on the inputs of a single sensor, instead of two factors considered in the original plan. Boeing engineers considered that lack of redundancy acceptable, according to proprietary information reviewed by The Seattle Times, because they calculated the probability of a “hazardous” MCAS malfunction to be virtually inconceivable.
As Boeing and the FAA advanced the 737 MAX toward production, they limited the scrutiny and testing of the MCAS design. Then they agreed not to inform pilots about MCAS in manuals, even though Boeing’s safety analysis expected pilots to be the primary backstop in the event the system went haywire.
In the wake of the two crashes, despite an outcry from the public and from some pilot and airline industry officials, Boeing has defended the processes behind its MCAS design decisions and refused to accept blame.
[ https://www.seattletimes.com/seattle-news/times-watchdog/the-inside-story-of-mcas-how-boeings-737-max-system-gained-power-and-lost-safeguards/ ]
Of course these two complicated system's failures could randomly match in some aspect or other, but the intent, outcome and reaction are arguably eerily alike. Despite suggestions these companies are fairly independent. -
#1275 by SoftwareDude on 29 Feb, 2020 19:37
-
Some thoughts about Boeing's Feb. 28th News Conference.
1. The CST-100 news conference reminded me of the early news conferences concerning the 737 Max crisis that was slowly blowing up in their faces. The reason I say that is Mulholland had this news conference ahead of the final IRT conference next Friday. Why? To emphasize the good news ahead of the not so good news? This is a preemptive damage control moment.
2. No Agile, no continuous development, no continuous testing, or no continuous builds, Boeing using the 1970s Software Engineering method. Boeing finds mistakes too late, causing huge delays because the waterfall program management emphasizes testing after code-complete. In this far worse case, Boeing discovers their problems after launch because they did not discover inadequate testing which is one of the many benefits of continuous testing.
3. Lots of talking around issues. For example, there is not an explanation why having the hardware propulsion controller would identify a bad valve mapping vs the emulator. How does a propulsion controller tell them they have the wrong mapping? It makes little sense.
4. Mulholland gives an explanation that seems to say inadequate testing is not a mistake. I am not talking about an end-to-end test though that is standard procedure for any software system. It is the rest of it.
BTW: What does $410 million for the next test launch buy? Four SpaceX manned launches. Boeing should be stripped of this contract. They are more than a year away from manned launch.
-
#1276 by Lars-J on 29 Feb, 2020 19:53
-
BTW: What does $410 million for the next test launch buy? Four SpaceX manned launches. Boeing should be stripped of this contract. They are more than a year away from manned launch.
Four F9 launches, but NOT with crew dragon. Don’t compare apples and oranges. -
#1277 by MattMason on 29 Feb, 2020 20:51
-
(snip)
As soon as DM-2 is successful, NASA should end the Boeing contract.
Hold on.
The whole point of Commercial Crew is redundant and reliable crew transport to the ISS. SpaceX could do it alone. The question is, "should they?"
My answer: No way.
Justification: The CRS 1 contract. It had only SpaceX and then-Orbital ATK to provide US ISS resupply and some redundancy.
And that didn't work quite well were it not for two other ISS resupply partners -- one which was also losing spacecraft and LVs.
-October 2014: ORB-3 is destroyed. NASA is reliant on SpaceX CRS Dragon resupply, Russian Progress and Kounotori.
-April 2015: Progress M27-M falls out of control and deorbits. NASA has only the Dragon and Kounotori for resupply.
-June 2015: CRS-7 destroyed on ascent. NASA is reliant on Progress returning to service and Kounotori.
-July 2015: Progress return-to-flight. Progress M28-M reaches the ISS.
-August 2015: Kounotori-5 reaches the ISS.
-October 2015: Progress M29-M reaches the ISS.
-December 2015: OA-4 Cygnus reaches the ISS using a ULA Atlas V.
-December 2015: Progress MS-01 reaches the ISS.
-March 2016: OA-6 Cygnus reaches the ISS using an ULA Atlas V.
-March 2016: Progress MS-02 reaches the ISS.
-April 2016: Falcon 9 return to flight - CRS-8 reaches the ISS.
-July 2016: Progress MS-03 arrives at the ISS.
-July 2016: CRS-9 arrives at the ISS.
-September 2016 - Falcon 9 grounded - Amos-6 pad anomaly. NASA reliant on restored Antares/Cygnus, Progress and Kounotori.
-October 2016: Antares return to flight - Cygnus OA-5 arrives at the ISS.
-December 2016: Progress MS-04 launch anomaly; vehicle lost. NASA has only Cygnus as resupply with Kounotori.
-December 2016: Kounotori-6 reaches the ISS.
-February 2017: Falcon 9 return to flight - CRS-10 reaches the ISS.
Now, these are just supplies that were needed. Every ISS resupply option except the periodic Kounotori was grounded during a roughly 3 year period.
And NASA was very fortunate to keep a minimum 6-month padding of supplies in case of such failures. But no one saw successive failures of this kind. This is why redundancy kept the ISS crewed. And we lucked out that ULA could come to the rescue or the heavy upmass of Cygnus could not have been in play.
If SpaceX were to suffer a failure of its booster on a CC flight, the Atlas V is capable of flying a Crew Dragon, if I recall properly.
If the Crew Dragon itself were to suffer a failure that grounded it with no Starliner in existence, that's trouble in all the worst ways.
I don't like how Boeing has behaved, either. But let's not throw out the baby with the bathwater.
Commercial Crew's dual partners are NASA's useful effort to idiot-proof itself against crap like this with either partner to keep people flying.
Soyuz is our only backup, and THAT didn't look too good after October 2018 with Soyuz MS-10. -
#1278 by ThePonjaX on 29 Feb, 2020 22:02
-
Some thoughts about Boeing's Feb. 28th News Conference.
2. No Agile, no continuous development, no continuous testing, or no continuous builds, Boeing using the 1970s Software Engineering method. Boeing finds mistakes too late, causing huge delays because the waterfall program management emphasizes testing after code-complete. In this far worse case, Boeing discovers their problems after launch because they did not discover inadequate testing which is one of the many benefits of continuous testing.
Exactly. As I say in my previous post: software is something "extra" to control de hardware. You add it at the end.
They are "old school" and that's the problem.
I think they show it on the Starliner instrumental panel: full of buttons and switches. It's necessary control by human, they don't trust the software to do the automation.
The opposite to the Dragon which is a autonomous robot, so autonomous than they are thinking to send 4 tourists without a pilot to orbit.
-
#1279 by Comga on 29 Feb, 2020 23:20
-
(snip)
As soon as DM-2 is successful, NASA should end the Boeing contract.
Hold on.
The whole point of Commercial Crew is redundant and reliable crew transport to the ISS. SpaceX could do it alone. The question is, "should they?"
My answer: No way.
(snip)
Soyuz is our only backup, and THAT didn't look too good after October 2018 with Soyuz MS-10.
Way
That’s a well researched history but it doesn’t convince me.
Soyuz after MS-10 didn’t look good, but was adequate.
Soyuz and Dragon will be enough redundancy.
Boeing was asked how much money they wanted for capsule development and they didn’t include adequate test systems, integrated system testing, or modern software methodology at 1.5X SpaceX’s contract.
Allowing Boeing to continue will only reinforce their habit of wringing money out of NASA.
There should be real consequences for inexcusable failure.
Granted SpaceX has not yet flown their crewed mission.
They may still have a “tungsten” problem.
But after DM-2, Starliner will have served enough of its risk reduction purpose.
