[dotnet00]

It isn't that they removed autonomous undocking. IIRC autonomous docking/undocking were part of the requirements for the commercial crew program. Starliner even did attempt an autonomous docking to the station.

The issue is that of fault handling. If the software detects a malfunction when a crew is onboard, the best option is to switch to manual control. But if a crew is not onboard, the craft should handle the failure on its own in the safest possible way.

So, what happened is that they loaded in software which expects the crew to be available. Now, obviously with thruster malfunctions already happening, they can't assume that a fault won't be detected after undocking, so they have to switch the software over to the configuration where it can no longer rely on the crew as a fallback.

[pennomi]

Right, but “switch the configuration” isn’t trivial, they’re estimating something like 4+ weeks of work. IIRC it’s essentially equivalent to reflashing the whole thing and revalidating the install was correct.

[dotnet00]

I agree, what I'm trying to emphasize is that the current software is able to undock autonomously, it isn't able to handle failures autonomously. Many people seem to be thinking that Starliner had been capable of autonomous docking/undocking and the functionality had been removed for seemingly no legitimate reason. But, if we understand that autonomous undocking is present, but autonomous error handling is not, the engineering reason becomes obvious, that when you have a crew available, they're the better option for error handling than the software.

I'm not trying to make the excuse that's going around about how they don't need to change the software, just the configuration. It's absurd that they need 4 weeks for this change when switching from manual to automatic fault handling should be a basic safety contingency (it'd be necessary if the crew had become incapacitated for any reason).

[bunderbunder]

I'm still not convinced this is sound engineering? Shipping two different versions of the software, instead of having some sort of switch you can flip, seems sub-optimal precisely because it increases your exposure to risks like this where you're less able to adapt to unforeseen circumstances because as soon as you wander off the happy path you're in completely uncharted waters. This feels more to me like yet another example of Boeing cutting corners without the benefit of a full understanding of the implications of the decision because their left, right, top, bottom, front, back, charm and strange hands all have no idea what the others are doing.

[skissane]

> Shipping two different versions of the software, instead of having some sort of switch you can flip, seems sub-optimal precisely

Someone on X was saying that NASA's definition of "flight software" includes config files. So it isn't actually the code that needs to be changed, just the config.

I think the need for 4 weeks for a config change is the requirement to test the new config in a simulator (against a long list of scenarios) and have it reviewed and approved by various engineering teams, both Boeing and NASA. Plus likely some margin added.