-
#600
by
TheRadicalModerate
on 14 Jan, 2020 06:56
-
In my old line of work an Interface Control Document is used to define all of the interfaces, both analog and digital, between systems. ASSUMING that ULA and Starliner's team have something similar, one possible explanation could be that there were different versions of the document that changed the interface addresses (a big no-no unless VERY WELL coordinated). Or, perhaps the scaling of the parameter was changed and it wasn't communicated to the software engineers.
In either case, system integration testing between Atlas and Starliner should have caught this. It's not feasible to test all paths through a piece of software, BUT we always tested ALL of the interfaces between safety-critical systems.
Not saying this is what happened, but it does fit with what has been stated, to my knowledge.
HTH, and have a good one,
Mike
This is my pet theory as well. All it takes is ULA doing one extra build without Boeing's knowledge and you could have a problem.
-
#601
by
edzieba
on 14 Jan, 2020 11:32
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
-
#602
by
Vettedrmr
on 14 Jan, 2020 12:17
-
All it takes is ULA doing one extra build without Boeing's knowledge and you could have a problem.
It's not a ULA build issue; it would have to be a change in the interface that either wasn't documented (which is bad) or wasn't validated by Boeing (which is bad). That's assuming Atlas isn't *using* anything from Starliner's interface.
I put the majority of risk mitigation (i.e. system integration testing) on Boeing. Starliner was launched and released just fine, so it seems apparent
from the outside looking in that Atlas doesn't use anything critical from the payload.
Have a good one,
Mike
-
#603
by
TheRadicalModerate
on 14 Jan, 2020 14:11
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
I'm not really suggesting "blame ULA". It's more a coordination issue between ULA and Boeing.
-
#604
by
gongora
on 14 Jan, 2020 14:15
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
I'm not really suggesting "blame ULA". It's more a coordination issue between ULA and Boeing.
I haven't heard any indication of a coordination issue between ULA and Boeing, and this isn't the first time this issue has been discussed in the thread.
-
#605
by
clongton
on 14 Jan, 2020 14:42
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
I'm not really suggesting "blame ULA". It's more a coordination issue between ULA and Boeing.
I haven't heard any indication of a coordination issue between ULA and Boeing, and this isn't the first time this issue has been discussed in the thread.
I'm guessing that a better wording for what he said is "It's more a
coordination integration issue"
-
#606
by
gongora
on 14 Jan, 2020 15:32
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
I'm not really suggesting "blame ULA". It's more a coordination issue between ULA and Boeing.
I haven't heard any indication of a coordination issue between ULA and Boeing, and this isn't the first time this issue has been discussed in the thread.
I'm guessing that a better wording for what he said is "It's more a coordination integration issue"
I haven't heard any indication of an integration issue from the ULA side. I haven't heard any indication that ULA changed their interface without informing their customers. I haven't heard any indication that anyone but Boeing was at fault for the incident.
-
#607
by
SoftwareDude
on 14 Jan, 2020 17:08
-
ULA would not change its interface because that would spread risk to all of its customers. Interfaces are a contract.
If I am not mistaken, Northrup built its own payload-adapter for Zuma and the F9 interface was a binary signal "Arrived". I can't imagine that ULA's interface is much different.
-
#608
by
abaddon
on 14 Jan, 2020 18:52
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
Has as much credibility as Starliner being delayed due to lack of Atlas V availability / launch slot did. Zero.
-
#609
by
SoftwareDude
on 14 Jan, 2020 19:59
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
Has as much credibility as Starliner being delayed due to lack of Atlas V availability / launch slot did. Zero.
Does anyone know how many RD-180 engines are available to ULA? How many more Atlas Vs can they build?
-
#610
by
gongora
on 14 Jan, 2020 20:04
-
The "blame ULA" theory just doesn't die. If it were that simple an issue, no way Boeing would not have said so to throw the heat off of them by now. Boeing pulls ULA's strings rather than vice versa.
Has as much credibility as Starliner being delayed due to lack of Atlas V availability / launch slot did. Zero.
Does anyone know how many RD-180 engines are available to ULA? How many more Atlas Vs can they build?
Plenty. (There is no restriction for non-DoD missions, and plenty left for DoD missions.)
-
#611
by
Jkew
on 15 Jan, 2020 01:24
-
This is obviously pure speculation but I would put my money on an enum being changed on either the ULA or Boeing interface definition side and two separate builds of the software being used. This sort of thing happens all the time, particularly in C/C++ where there there’s a lack of a coordinated continuous integration system or clear boundaries on how those enums can be modified.
It’s an easy and naive mistake to make and it happens more times than it should in modern languages. I wouldn’t mention it if I had not seen it cause more than three or four major problems in my career.
-
#612
by
clongton
on 15 Jan, 2020 03:37
-
I'm guessing that a better wording for what he said is "It's more a coordination integration issue"
I haven't heard any indication of an integration issue from the ULA side. I haven't heard any indication that ULA changed their interface without informing their customers. I haven't heard any indication that anyone but Boeing was at fault for the incident.
Oh I agree with you completely. Just suggesting a more appropriate wording for his question.
-
#613
by
Semmel
on 15 Jan, 2020 07:39
-
This is obviously pure speculation but I would put my money on an enum being changed on either the ULA or Boeing interface definition side and two separate builds of the software being used. This sort of thing happens all the time, particularly in C/C++ where there there’s a lack of a coordinated continuous integration system or clear boundaries on how those enums can be modified.
It’s an easy and naive mistake to make and it happens more times than it should in modern languages. I wouldn’t mention it if I had not seen it cause more than three or four major problems in my career.
Could be. And to add speculation topping on speculation cake: it didnt show up in simulations because the simulations were started to simulate the flight. So the Atlas "startup" clock was virtually identical to the "launch" clock. The simulation just started with the launch, which makes sense simulation wise.
The other arguments though, that Starliner didnt detect the error of its ways, still stands. No matter how the data got wrong, if there is no consistency check on any step in a system like that, its time to go back to the drawing board.
-
#614
by
Yellowstone10
on 15 Jan, 2020 15:33
-
Boeing has released a few minutes of onboard video from the Starliner OFT mission:
-
#615
by
Lars-J
on 15 Jan, 2020 17:00
-
Beautiful footage!
Too bad Snoopy did not get to visit ISS.
-
#616
by
Lars-J
on 15 Jan, 2020 18:23
-
I saw this on image the mission update thread:
Looks like the back side got scorched (see the black streaks on the left side almost out of view). Boeing has not let the press take pictures of that side, it seems. Nor released pictures themselves.
Which is odd, it is nothing to be ashamed of. Dragon capsules look pretty streaked and burned on the back side too.
-
#617
by
thirtyone
on 15 Jan, 2020 18:45
-
ULA would not change its interface because that would spread risk to all of its customers. Interfaces are a contract.
If I am not mistaken, Northrup built its own payload-adapter for Zuma and the F9 interface was a binary signal "Arrived". I can't imagine that ULA's interface is much different.
To be clear - I don't think we really know who to fault at this point, and it seems unlikely it'd be ULA - but this particular human-rated Atlas V is substantially different than most other Atlas V LVs. At the very least, there's an entirely new Emergency Detection System for detecting abort conditions (apparently disabled for OFT), among other changes for the human rating. So it would not be unreasonable to think maybe the interface is substantially different than most other Atlas V flights.
https://spaceflightnow.com/2019/11/06/ula-begins-stacking-unique-atlas-5-rocket-for-starliner-test-flight/
-
#618
by
thirtyone
on 15 Jan, 2020 18:47
-
Could be. And to add speculation topping on speculation cake: it didnt show up in simulations because the simulations were started to simulate the flight. So the Atlas "startup" clock was virtually identical to the "launch" clock. The simulation just started with the launch, which makes sense simulation wise.
The other arguments though, that Starliner didnt detect the error of its ways, still stands. No matter how the data got wrong, if there is no consistency check on any step in a system like that, its time to go back to the drawing board.
This has been one of my biggest suspicions to date as well. While I was looking up some info about changes to the Atlas flight computer for this launch, I came across an incredibly suspicious number which *really* makes me suspect this is exactly what happened (from
https://spaceflightnow.com/2019/11/06/ula-begins-stacking-unique-atlas-5-rocket-for-starliner-test-flight/):
The Atlas 5 countdown typically lasts nearly seven hours for a satellite launch. For Starliner missions, the countdown will run nearly 11 hours.
There's that magical 11 hour offset...
-
#619
by
Vettedrmr
on 15 Jan, 2020 19:06
-
That's quite an interesting article, sorry I missed it earlier. Found this little nugget up towards the top of the article:
“Electrically, one of the unique things about this mission is that the launch vehicle and spacecraft are going to be talking to each other,” Weiss said in a recent interview. “We normally don’t have that. They will be sharing data throughout (the) flight.”
Things to think about, while we wait on the facts to be released.
Have a good one,
Mike
