Prove that any of this has stemmed from "poor corporate/managerial culture".
I've had good and bad management. One thing I do is write control software. The quality of my control software has nothing to do with the quality of my management. In fact, management has exactly nothing to do with any of it. I don't know if that's the case inside Boeing, and neither do you.
Exactly. You and ONLY you are responsible for the quality of the product you provide. Blaming lousy product quality on bad management says less about management than it does about your own character.I also write software for a living, and strongly disagree with this. I do the best I can, but I make mistakes. Fortunately, the software goes to others to be tested before it is released. The quality of these tests, and the feedback from them, has a huge function on the quality of the final results.
Here is where management comes in. Management can assign really good folks to QA, who creatively think of ways to stress your software, or they can assign folks who will just test precisely what you fixed. They can think of QA as an asset that helps them maintain quality (and pay them well), or treat them as an overhead that should be minimized. If there is a workforce reduction, they can decide whether to fire a QA person or a coder. If a QA person finds a problem, they can reward them for preventing a customer failure, or castigate them as nit-pickers who are impacting the schedule. They can consider a move from (say) QA to coding as a promotion, or as a lateral move. There are any number of ways management can affect QA, and hence quality.
Writing software might seem like an activity where you and only you determine quality. But it's not - every programmer has blind spots and makes mistakes. It's a team effort to create quality software, and management has a big impact on the effectiveness of the team.
I’m also a software developer in a large organization, and I had to quote all of this because it is 100% true. Management priorities make a huge difference. My opinion about the quality of my work is just that - my opinion - until it has been thoroughly tested by QA.
Yep, the other thing bugging me. Why is there a need to communicate with Earth at all? ... so why can't they have fully autonomous flight control software that would monitor and manage the flight?
There is no "need" to communicate with earth (for flight control). Starliner does have fully autonomous flight control software, but it failed. The communication that was attempted was to override the autonomous flight control software that had failed and take manual control of the spacecraft. But the communications dropout prevented that until too much fuel had been expended to make reaching ISS tenable. Had crew been aboard they would have done exactly what ground control attempted, but without the comm dropout, they would have succeeded where ground control did not. There would not have been the time lapse where excessive propellant got burn off. Crew would have taken control, oriented the spacecraft and executed the insertion burn, long before any comm gap had finished. By the time the spacecraft had come out of the comm drop the spacecraft would have been well on its way to the ISS,
I really don't see it this way -
Starliner has an autonomous system that relies upon NASA/Boeing to tell it where it is - they specifically referenced the fact that at the time the Starliner did not "have its eyes open" and it relies upon the ground to provide altitude. Of course because it wasn't where it was expected, the ground couldn't provide that data due to misalignment of TDRSS.
NASA Administrator Bridenstine has said that an uncrewed docking mission to the ISS is not required for a crewed mission to be launched. But will that crewed mission then have to dock manually? I don't think you would want an automated docking to take place for the first time with crew on board. And since all subsequent missions of Starliner to the ISS would be crewed, that would mean Starliner could never use it's automated docking system.
No, Starliner relied on the launch vehicle for its initial state. That's very different from relying on comms from the ground. There was an error reading the correct information from the launch vehicle.
That timer problem also affected the spacecraft’s propulsion system. The heavy use of attitude control thrusters shortly after the spacecraft separated from the Centaur, caused by the spacecraft having the wrong time and thus thinking it was in a different phase of the mission, put a lot of “duty cycles” on those thrusters, Chilton said. Sensors in those thrusters started reporting errors or providing intermittent data.
Controllers confirmed that the problems were with the sensors, and not the thrusters themselves, by turning off the sensors and performing thruster burns, using the spacecraft’s guidance system to determine if the thruster performed as expected. “So far, they’re all working, so we think we heated up some sensors by stepping on the gas hard,” he said.
There is no reason you couldn't do the first automatic docking with crew on board. They can supervise the process and disengage it if there is a problem.
There is no reason you couldn't do the first automatic docking with crew on board. They can supervise the process and disengage it if there is a problem.
There are some highly unsafe conditions that can arise:
1) The oldie-but-goodie, the "stuck thruster". Ramming the ISS probably isn't fatal to the ISS crew, which can be buttoned up in the return vehicle or even in another module, but it sure could kill the Starliner crew.
2) You could also get a hung undocking. There's a pyro fail-safe to mitigate this, but it'd be kinda hair-raising.
Neither of these is a particularly high-probability event, but one would think that a spacecraft with a messed-up MET interface and instrumentation errors coming off of the thrusters would be pretty low probability, too.
There is no reason you couldn't do the first automatic docking with crew on board. They can supervise the process and disengage it if there is a problem.
There are some highly unsafe conditions that can arise:
1) The oldie-but-goodie, the "stuck thruster". Ramming the ISS probably isn't fatal to the ISS crew, which can be buttoned up in the return vehicle or even in another module, but it sure could kill the Starliner crew.
2) You could also get a hung undocking. There's a pyro fail-safe to mitigate this, but it'd be kinda hair-raising.
Neither of these is a particularly high-probability event, but one would think that a spacecraft with a messed-up MET interface and instrumentation errors coming off of the thrusters would be pretty low probability, too.
There is no reason you couldn't do the first automatic docking with crew on board. They can supervise the process and disengage it if there is a problem.
There are some highly unsafe conditions that can arise:
1) The oldie-but-goodie, the "stuck thruster". Ramming the ISS probably isn't fatal to the ISS crew, which can be buttoned up in the return vehicle or even in another module, but it sure could kill the Starliner crew.
2) You could also get a hung undocking. There's a pyro fail-safe to mitigate this, but it'd be kinda hair-raising.
Neither of these is a particularly high-probability event, but one would think that a spacecraft with a messed-up MET interface and instrumentation errors coming off of the thrusters would be pretty low probability, too.
I really don't see how either of your hypothetical situations affects whether to put crew on board for the first automatic docking. The second one doesn't even have anything to do with whether it was automatic or manual docking.
Less management is better management.
No, Starliner relied on the launch vehicle for its initial state. That's very different from relying on comms from the ground. There was an error reading the correct information from the launch vehicle.
There's now also thisQuoteThat timer problem also affected the spacecraft’s propulsion system. The heavy use of attitude control thrusters shortly after the spacecraft separated from the Centaur, caused by the spacecraft having the wrong time and thus thinking it was in a different phase of the mission, put a lot of “duty cycles” on those thrusters, Chilton said. Sensors in those thrusters started reporting errors or providing intermittent data.
Controllers confirmed that the problems were with the sensors, and not the thrusters themselves, by turning off the sensors and performing thruster burns, using the spacecraft’s guidance system to determine if the thruster performed as expected. “So far, they’re all working, so we think we heated up some sensors by stepping on the gas hard,” he said.
How is there a test regime where you didn't put "a lot of duty cycles" on the RCS system?
No, Starliner relied on the launch vehicle for its initial state. That's very different from relying on comms from the ground. There was an error reading the correct information from the launch vehicle.
A simulation. One of the catches with running simulations as a major part of your testing regime is that you can only test for interactions that you have programmed into the system. It doesn’t do as well with unexpected interactions.
I listened to the media call (minute 26) and it was very clear that Starliner has no idea where it is orbit wise initially unless its told by the ground ('This is a point in the mission where we tell the spacecraft where it is, not where it opens its eyes and looks" "it was not where it expected to be" and "because the vehicle wasn't where it thought it was the antennas were not pointing in the right direction").
It gets mission time from the launch vehicle to execute its insertion.
This wouldn't be a problem if it was where it was supposed to be, but since it was not where it was supposed to be, it was a big problem in calibrating TDRSS and telling it where it is orbitwise. I think that's a big problem for autonomous system. It can't be an autonomous system if it only works when everything goes perfectly.
How is there a test regime where you didn't put "a lot of duty cycles" on the RCS system?
A simulation. One of the catches with running simulations as a major part of your testing regime is that you can only test for interactions that you have programmed into the system. It doesn’t do as well with unexpected interactions.
How is there a test regime where you didn't put "a lot of duty cycles" on the RCS system?
How is there a test regime where you didn't put "a lot of duty cycles" on the RCS system?
You don't test too far beyond your design criteria.
Let's say, for sake of argument, that you design the thrusters for a duty cycle of 25% for no longer than 2 minutes. Maybe you test them at 40% for 4 minutes and, if they're fine, you say they meet the design criteria. Then you operate them at 80% for 10 minutes and they fail. Well, that was outside the design - and testing - criteria.
In case it's not clear, I made up all those numbers for illustration purposes.
Sounds like a bug that may have not cropped up until the vehicle was integrated with the LV as it cropped up when it grabbed the time reference from the Atlas flight computers.
One advantage Spacex has is they manufacture both the capsule and the LV.
Though it should be an easy fix.
How is there a test regime where you didn't put "a lot of duty cycles" on the RCS system?
You don't test too far beyond your design criteria.
Let's say, for sake of argument, that you design the thrusters for a duty cycle of 25% for no longer than 2 minutes. Maybe you test them at 40% for 4 minutes and, if they're fine, you say they meet the design criteria. Then you operate them at 80% for 10 minutes and they fail. Well, that was outside the design - and testing - criteria.
In case it's not clear, I made up all those numbers for illustration purposes.
If they didn't test this many cycles because it was beyond the design criteria, the control software should have been designed not to push it beyond its design limits.
Sounds like a bug that may have not cropped up until the vehicle was integrated with the LV as it cropped up when it grabbed the time reference from the Atlas flight computers.
One advantage Spacex has is they manufacture both the capsule and the LV.
Though it should be an easy fix.
The bug is only the proximate cause. The root cause needs to explain how Starliner ended up with an architecture that (from what we know, which admittedly isn't much) was sufficiently fragile to allow a single, very simple error to cascade into problems with guidance, navigation and communications. How was the decision to take such an apparently fragile approach made? What culture allowed the vehicle to fly without first performing the kind of hardware-in-the-loop, end-to-end test that would have picked the very simple bug up? Or to write a hardware-in-the-loop, end-to-end test that *didn't* pick up the very simple bug?
That's where the fix is (may be) needed - and fixing that is generally not trivial.