-
#340 by deadman1204 on 06 Jun, 2022 13:49
-
There may be a way to satisfy the desire for dissimilar redundancy whilst avoiding some of the costs of Starliner missions vs. competitors: pay Boeing to maintain readiness of their existing fleet of Starliners, but do not actually pay them to launch unless needed.
Are you a Boeing lobbyist? This is EXACTLY what used to happen to ULA. They were paid piles of money "to be ready" which functionally did nothing. -
#341 by tssp_art on 06 Jun, 2022 14:31
-
Not a good idea, IMHO. Starliner has had many flaws that have been revealed *only* by actual flights.
Not flying starliner is a recipe for disaster
Starliner issues to date have been design flaws. Not flying may create issues with manufacturing and operations consistency and quality but doesn't cause corrected design flaws to creep back in.
That's correct (or should be). But the engineering culture that allowed those design flaws to exist all through pre-launch testing may well have other surprises in store - and they may only be revealed by future flights that extend the operational envelope. For example, Starliner is expected to maintain its readiness for departure from ISS for six months and, so far, it hasn't had to demonstrate that for more than a few days. -
#342 by DanClemmensen on 06 Jun, 2022 17:58
-
There may be a way to satisfy the desire for dissimilar redundancy whilst avoiding some of the costs of Starliner missions vs. competitors: pay Boeing to maintain readiness of their existing fleet of Starliners, but do not actually pay them to launch unless needed. That means a longer lead time before launch than if Boeing were regularly launching, but likely not as much longer as one would expect given the normal lead times for a crew launch. Boeing PHBs get a nice consistent revenue stream to keep them happy about keeping the programme alive in the face of potential unprofitability, and commercial station operators have a fallback option they hope to never use but can if needed - and at a lower cost then buying actual launches.
One problem: NASA has already committed to pay for an additional seven Starliner launches (CFT plus Starliner-1 through Starliner-6) , and ULA has allocated exactly seven of the remaining 23 Atlas V vehicles to Starliner. The only way Boeing can create a contingency backup would be to qualify Starliner to fly on a different launcher. I don't think the economics of paying for that just be be a contingency backup will make any sense. Somewhere there are seven Atlas Vs sitting in a warehouse (or something), and somewhere Boeing will build (or has built) seven service modules. I suppose NASA and Boeing could agree to keep the last two full stacks on the ground as contingency backups. Seems like a logistical nightmare, but I guess they did this for liquid-fueled ICBMs. Probably cheaper overall to get Crewed Dream chaser or crewed Starship operational. -
#343 by Surfdaddy on 06 Jun, 2022 18:29
-
Dissimilar human flight options are there for contingencies.
If Starliner were to be unavailable, I don't doubt that Dragon could cover.
If Dragon became unavailable, could Starliner cover? Seems like they'd have to be flexible with the schedule, possibly moving up launches. We do know that there is only a fixed number of missions remaining available (unless man-rating some other launcher). -
#344 by Jim on 06 Jun, 2022 18:43
-
Starliner issues to date have been design flaws.
Not true. More misinformation -
#345 by Jim on 06 Jun, 2022 18:49
-
There may be a way to satisfy the desire for dissimilar redundancy whilst avoiding some of the costs of Starliner missions vs. competitors: pay Boeing to maintain readiness of their existing fleet of Starliners, but do not actually pay them to launch unless needed.
Are you a Boeing lobbyist? This is EXACTLY what used to happen to ULA. They were paid piles of money "to be ready" which functionally did nothing.
wrong -
#346 by greybeardengineer on 06 Jun, 2022 19:37
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
-
#347 by Jim on 06 Jun, 2022 19:50
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
-
#348 by mgreb on 06 Jun, 2022 20:34
-
from a layman prospective, Isn't software part of the design?
-
#349 by shark0302 on 06 Jun, 2022 20:39
-
High level sure. But most code is an implementation thing. And there's a lot of ways to implement time.
Sent from my SM-T860 using Tapatalk
-
#350 by king1999 on 06 Jun, 2022 20:42
-
"Dissimilar redundancy" is only needed when a system is unproven. The Russians only have Soyuz. When Craw Dragon is proven sufficiently, there is less incentive to have another system.
-
#351 by deadman1204 on 06 Jun, 2022 20:43
-
ummm... software IS the product too. Its not just some little add on. I have trouble believing you really think software ISN'T part of the product, because thats a very troublesome view.
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws -
#352 by Lee Jay on 06 Jun, 2022 20:59
-
ummm... software IS the product too. Its not just some little add on. I have trouble believing you really think software ISN'T part of the product, because thats a very troublesome view.
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
There are many steps between blank sheet of paper and final working complex product, even if the product is software. Not all of them are "design". There can be implementation errors, testing errors, and even operating errors (as examples). -
#353 by whitelancer64 on 06 Jun, 2022 21:24
-
"Dissimilar redundancy" is only needed when a system is unproven. The Russians only have Soyuz. When Craw Dragon is proven sufficiently, there is less incentive to have another system.
.... a monopoly doesn't have any incentives for pursuing efficiency or innovation. e.g., well, the Soyuz. -
#354 by king1999 on 06 Jun, 2022 23:09
-
You are right in general about that. By less incentive, I mean that other providers are less capable of blackmailing NASA into just paying for redundancy, like B..g did a few years ago for "faster" work."Dissimilar redundancy" is only needed when a system is unproven. The Russians only have Soyuz. When Craw Dragon is proven sufficiently, there is less incentive to have another system.
.... a monopoly doesn't have any incentives for pursuing efficiency or innovation. e.g., well, the Soyuz. -
#355 by edzieba on 06 Jun, 2022 23:46
-
from a layman prospective, Isn't software part of the design?
A "design flaw" would be if there was no way to set the MET timer. That would be a faulty design, where successful operation was precluded by the design.
The MET issue was an implementation issue: the timer was settable, but set incorrectly. -
#356 by baldusi on 07 Jun, 2022 00:19
-
Starliner has not shown and design flaw. It did showed a lot of implementation and process errors, though. But design errors require a significant redesign. And when you talk about a whole spaceship design, to qualify as a project design error, not a subcomponent error, it would have to be something like if the clamshell turned up to be unworkable, or deploying the heatshields and land landing was impossible to do right or so. Nothing of that showed. Everything can be corrected with a "relatively simple" design change. What took a lot of work was to redo the whole design and certification process. Changing the organizational culture, if you will. That was a waterfall that precipitated a lot of small design corrections and errata solutions. But nothing major, really. If you follow the history of any flying or gliding machine, Starliner did it pretty well (after NASA went there with a comb).
-
#357 by meekGee on 07 Jun, 2022 03:58
-
Starliner has not shown and design flaw. It did showed a lot of implementation and process errors, though. But design errors require a significant redesign. And when you talk about a whole spaceship design, to qualify as a project design error, not a subcomponent error, it would have to be something like if the clamshell turned up to be unworkable, or deploying the heatshields and land landing was impossible to do right or so. Nothing of that showed. Everything can be corrected with a "relatively simple" design change. What took a lot of work was to redo the whole design and certification process. Changing the organizational culture, if you will. That was a waterfall that precipitated a lot of small design corrections and errata solutions. But nothing major, really. If you follow the history of any flying or gliding machine, Starliner did it pretty well (after NASA went there with a comb).
That's a very narrow definition.
To me, if the design says "use alloy X" and QA misses the fact that alloy Y was used that's a non-design issue. Or if the design says "torque to X", and the assembler torqued to Y instead.
But if the designer didn't calculate the bolts right, that's a design problem, even if it's just a sub component that was affected.
How do you tell? Check if the problem will recur under the same circumstances. (Or recur statistically, to be more correct)
So if the software reads the timer wrong, or reads the wrong register, those are design issues.
That they weren't caught in simulation is a verification issue as well.
-
#358 by Vettedrmr on 07 Jun, 2022 10:24
-
So if the software reads the timer wrong, or reads the wrong register, those are design issues.
That they weren't caught in simulation is a verification issue as well.
1.) Whether OFT-1's software errors were design (meaning the coding team got bad design information) or implementation (meaning the coding team had good design information but made a mistake writing the code), we'll never know
2.) The REAL OFT-1 problem was the lack of testing. If Boeing had found the MFT clock mistake (and the other 80-odd mistakes) prior to OFT-1 we'd never have this thread. -
#359 by woods170 on 07 Jun, 2022 11:08
-
Starliner issues to date have been design flaws.
Not true. More misinformation
So incorrect initialization of the MET timer and erroneous thruster mapping tables were part of the original functional spec? Fascinating.
incorrect initialization of the MET timer is a input error. Also, software errors are not design flaws
Emphasis mine.
No, it is was NOT an input error. ULA's Atlas V gave the correct inputs.
The INcorrect initialization of the MET timer was in fact a design error, just as GreyBeardEngineer had correctly indicated.
The software requirement for MET initialization was that Starliner would initialize its MET timer by "grabbing the time from Atlas during the terminal count phase".
Unfortunately, when those requirements were translated into the design of the software, PART of this particular requirement was overlooked. Boeing's software design team failed to properly translate the part, about grabbing during the terminal count phase, into the design of the software.
The result was that the Starliner OBC software grabbed the time from Atlas (per the first part of the requirement), but failed to do so in the "terminal count phase". Instead, Starliner grabbed the time from Atlas upon activation of the Starliner OBC, almost 12 hours before launch. (Mind you: almost 12 hours before launch is not "terminal count phase". Atlas V terminal count phase is usually polled for around L-30 minutes, with terminal count phase actually entered around L-4 minutes).
This is a poster-boy example of how many software errors come into existence. Translating software design into functional software (in other words: coding) is prone to producing software errors in itself. But translating software requirements into software design (in other words: desigining the software) is an even bigger source of software errors. The latter is what happened. And that is a software design error. Nothing more, nothing less.
Starliner was supposed to grap the MET initial time less than 5 minutes before launch, but actually grabbed the MET initial time almost 12 hours before launch.
Now, that was bad in itself. But what was even worse is that the software quality team, managed to overlook this design error not once, but at least twice.
A good software development process is equipped with activities to catch errors early. Once such activity is to review the software design. It is is intended to determine to what extent the software design correctly captures the required functionality. Basically: it checks if the software requirements are correctly translated into software design.
That review is when Boeing's software team first overlooked that the "grab during terminal count" requirement had not been translated correctly into the software design.
OK, then came coding, which resulted in functional software. Starliners software package is big, so it is tested first in separate functional blocks. Once those are found to be OK, the software is tested as an integrated whole. And if said software package deals with other systems withing a chain a systems, an integrated end-to-end test is usually performed as well.
It is this integrated end-to-end test where Boeing's software team managed to screw up its testing for a second time.
Instead of simulating the entire routine in one go - from waking up Boeing's OBC around 12 hours prior to launch, all the way to Starliner docking at the ISS (a full 3 day timeline) - Boeing chose to cut up the end-to-end test in temporal blocks. The first block (from activation of Starliner's OBC) until T-0/L-0) ended at the moment of launch.
And now comes the error: the next temporal block (from T-0/L-0) to 12 hours after launch, DID NOT USE the frozen state of variables from the first temporal block.
Had they done so, the second temporal block would have started with the MET timer already running over 11 hours ahead of schedule. The integrated end-to-end test would then have exposed that error.
But that is not how Boeing's software team chose to test that next block. At the start of that next temporal block, they reset all variables to values that they EXPECTED to be the start values for that next block. So, that next temporal test block started with a MANUALLY set initial value for the MET timer.
Needless to say that THAT manually set value was a correct value. It was not 11 hours early. And that is how the integrated end-to-end testing managed to miss the software design error for a second time.
