-
#760
by
DanClemmensen
on 03 Jul, 2024 16:03
-
As I understand it, this flight doesn't have to be perfect to meet the milestone. There's a brilliant thread on L2 with all the issues that occurred on each Shuttle flight. The issues that occurred on this flight are far less critical than those on the notorious first flight. My guess is that this flight did enough to warrant moving forward with milestone completion, but with forward work to do to improve things - obviously contingent on safe return. I'm not an insider on this, so these are only educated guesses from outside.
I'm not objecting to the current assessment methodology: I can't, because I don't know what it is. I'm objecting to the lack of any public documentation about that methodology. I don't feel that the assessment team should be reporting on their intermediate results. I do feel that the should have told us how they intend to do the assessment.
If there is a published methodology, then I apologize and request that someone point me to it.
-
#761
by
Lee Jay
on 03 Jul, 2024 16:54
-
As I understand it, this flight doesn't have to be perfect to meet the milestone. There's a brilliant thread on L2 with all the issues that occurred on each Shuttle flight. The issues that occurred on this flight are far less critical than those on the notorious first flight. My guess is that this flight did enough to warrant moving forward with milestone completion, but with forward work to do to improve things - obviously contingent on safe return. I'm not an insider on this, so these are only educated guesses from outside.
I'm not objecting to the current assessment methodology: I can't, because I don't know what it is. I'm objecting to the lack of any public documentation about that methodology. I don't feel that the assessment team should be reporting on their intermediate results. I do feel that the should have told us how they intend to do the assessment.
If there is a published methodology, then I apologize and request that someone point me to it.
Is the contract statement of work and milestone list published?
-
#762
by
FutureSpaceTourist
on 03 Jul, 2024 17:17
-
-
#763
by
DanClemmensen
on 03 Jul, 2024 18:31
-
Is the contract statement of work and milestone list published?
Try: https://www.nasa.gov/wp-content/uploads/2019/08/cctcap_boeing_508.pdf
I think pages 363-364 talk about the Certification Review milestone.
Thanks! That section of that document lays out the top-level process: Boeing submits data and NASA reviews it, based on pre-established lists of data items. However, the actual data items and methods to evaluate them appear to be in separate documents:
DRD 106 Certification Review Milestone Data Package
DRD 112 Certification Data Package.
Are these available anywhere? They appear to be work products generated in earlier steps in the contract.
-
#764
by
Jim
on 03 Jul, 2024 21:59
-
Is the contract statement of work and milestone list published?
Try: https://www.nasa.gov/wp-content/uploads/2019/08/cctcap_boeing_508.pdf
I think pages 363-364 talk about the Certification Review milestone.
Thanks! That section of that document lays out the top-level process: Boeing submits data and NASA reviews it, based on pre-established lists of data items. However, the actual data items and methods to evaluate them appear to be in separate documents:
DRD 106 Certification Review Milestone Data Package
DRD 112 Certification Data Package.
Are these available anywhere? They appear to be work products generated in earlier steps in the contract.
no, these are propriety and likely ITAR/export controlled
-
#765
by
Kiwi53
on 03 Jul, 2024 22:18
-
All they have to do is declare the next flight a 'long duration certification flight'. So easy and problem solved. 
Sorry, no. If NASA does not certify CFT, then Boeing has not completed the CFT milestone and they don't get paid for it. This is what happened with OFT-1. If Boeing did decide to move forward to CFT-2 with a mission plan that's identical to Starliner-1, then it would still be CFT-2 and is successful the payment to Boeing would be for the CFT, not for Starliner-1.
And if NASA don't certify Starliner on the basis of the current CFT, so that a CFT-2 is required, then Boeing has another problem. They won't have enough Atlas-V boosters to complete the contracted six 'production' flights, and even if they did, they probably wouldn't have enough time to launch all six before the ISS de-orbits in 2030/31
-
#766
by
AmigaClone
on 04 Jul, 2024 06:01
-
All they have to do is declare the next flight a 'long duration certification flight'. So easy and problem solved.
Sorry, no. If NASA does not certify CFT, then Boeing has not completed the CFT milestone and they don't get paid for it. This is what happened with OFT-1. If Boeing did decide to move forward to CFT-2 with a mission plan that's identical to Starliner-1, then it would still be CFT-2 and is successful the payment to Boeing would be for the CFT, not foStarliner-1.
And if NASA don't certify Starliner on the basis of the current CFT, so that a CFT-2 is required, then Boeing has another problem. They won't have enough Atlas-V boosters to complete the contracted six 'production' flights, and even if they did, they probably wouldn't have enough time to launch all six before the ISS de-orbits in 2030/31
It might be slightly easier to get another Atlas 5 rocket (at least at the moment) than to launch 7 Starliner missions prior to the ISS being deorbited which would be the case if a second CFT mission was needed. Granted, the former would likely involve negotiations with Amazon and possibly SpaceX.
-
#767
by
FutureSpaceTourist
on 04 Jul, 2024 06:38
-
https://starlinerupdates.com/starliner-testing-continues-in-space-and-on-the-ground-to-support-future-long-duration-missions/Starliner testing continues in space and on the ground to support future long-duration missions
July 3, 2024
Starliner crew enters fourth week on orbit while teams prepare for ground testing
NASA astronauts Butch Wilmore and Suni Williams climbed into Starliner at the International Space Station and worked with Boeing flight controllers and engineers on Tuesday, July 2, during power up of the spacecraft.
The teams on-console in NASA’s Mission Control Center in Houston and Boeing’s Mission Control Center at Kennedy Space Center checked out various systems of the spacecraft with the crew, including repressurizing the propellant manifolds. They also conducted mission data loads, or MDLs, which are files for the spacecraft’s computer to understand current inertial and relative navigation states, Earth rotation, and thermal conditioning on thrusters used during Starliner’s return, and more.
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,” said Chloe Mehring, the Starliner flight director who coordinated the power-up actions with Wilmore and Williams. “Starliner is healthy and no anomalies were written against the spacecraft.”
Additional Operational Checkout Capabilities, or OCCs, that were added during Tuesday’s testing included tablet and procedure updates. Camera and tablet batteries were also charged while the spacecraft was fully powered up.
Canadian Space Agency astronaut Josh Kutryk, the CAPCOM or capsule communicator, who will fly on Starliner-1 following CFT, was also on console working with the crew. Kutryk updated crew toward end of power up that transfer of the MDLs were successful and all software updates are in a good configuration.
“Good news. Great work. Copy all,” Wilmore replied over the ISS Space-to-Ground loop.
That work took place as teams at NASA’s White Sands Test Facility in New Mexico prepared for Starliner’s Reaction Control System, or RCS, thruster testing. An acceptance test, which is standard for all new thrusters as a quality check and to gather baseline performance data, is anticipated is starting today, July 3. This thruster was planned for a future Starliner mission.
Beginning next week, teams will run the thruster through similar conditions that Starliner experienced after launch on the way to the space station. The tests will include replicating the phase of the Crew Flight Test from launch to docking. Then tests will be performed to replicate what thrusters will experience from undocking to landing.
“We really want to understand the thruster and how we use it in flight,” said Dan Niedermaier, the lead Boeing engineer for the thruster testing. “We will learn a lot from these thruster firings that will be valuable for the remainder of the Crew Flight Test and future missions.”
Wilmore and Williams have remained busy assisting the space station crew with organizing stowage on orbiting laboratory. Earlier this week, Wilmore disassembled an empty NanoRacks CubeSat Deployer in the Japanese Experiment Module in preparation of upcoming NanoRacks missions. He also prepped and viewed samples for Moon Microscope, a demonstration that allows flight surgeons on Earth to diagnose illnesses and could provide diagnostic capabilities for crews on future missions to the Moon and Mars. Williams conducted some routine orbital plumbing, then audited U.S. stowage items housed inside the Zarya module. Go here to see more work the two performed Tuesday and today.
The Crew Flight Test astronauts will also provide an update on their mission and stay at the ISS during a news conference at 11 a.m. ET on Wednesday, July 10. Media interested in participating should RSVP by 5 p.m. Tuesday, July 9, and can learn how here.
-
#768
by
SoftwareDude
on 04 Jul, 2024 07:23
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
-
#769
by
Steven Pietrobon
on 04 Jul, 2024 07:47
-
-
#770
by
dbw49
on 04 Jul, 2024 13:24
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
-
#771
by
jimvela
on 04 Jul, 2024 13:47
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
Yes, soft products.
"Products on board" AKA onboard products, aka soft products, aka tables/configs/settings. Probably not flight software (FSW), which would be referred to as such.
I think they are referring to "product documentation".
https://www.squibler.io/learn/documentation/product-documentation/
Not in this case.
-
#772
by
lrk
on 04 Jul, 2024 15:16
-
All they have to do is declare the next flight a 'long duration certification flight'. So easy and problem solved.
Sorry, no. If NASA does not certify CFT, then Boeing has not completed the CFT milestone and they don't get paid for it. This is what happened with OFT-1. If Boeing did decide to move forward to CFT-2 with a mission plan that's identical to Starliner-1, then it would still be CFT-2 and is successful the payment to Boeing would be for the CFT, not foStarliner-1.
And if NASA don't certify Starliner on the basis of the current CFT, so that a CFT-2 is required, then Boeing has another problem. They won't have enough Atlas-V boosters to complete the contracted six 'production' flights, and even if they did, they probably wouldn't have enough time to launch all six before the ISS de-orbits in 2030/31
It might be slightly easier to get another Atlas 5 rocket (at least at the moment) than to launch 7 Starliner missions prior to the ISS being deorbited which would be the case if a second CFT mission was needed. Granted, the former would likely involve negotiations with Amazon and possibly SpaceX.
They have already finished (or nearly finished) building out the final Centaur III stages. Starliner uses the Dual Engine Centaur while Kuiper uses the single engine variant. Converting between them is likely not feasible.
-
#773
by
DanClemmensen
on 04 Jul, 2024 15:27
-
All they have to do is declare the next flight a 'long duration certification flight'. So easy and problem solved.
Sorry, no. If NASA does not certify CFT, then Boeing has not completed the CFT milestone and they don't get paid for it. This is what happened with OFT-1. If Boeing did decide to move forward to CFT-2 with a mission plan that's identical to Starliner-1, then it would still be CFT-2 and is successful the payment to Boeing would be for the CFT, not for Starliner-1.
And if NASA don't certify Starliner on the basis of the current CFT, so that a CFT-2 is required, then Boeing has another problem. They won't have enough Atlas-V boosters to complete the contracted six 'production' flights, and even if they did, they probably wouldn't have enough time to launch all six before the ISS de-orbits in 2030/31
ULA has eight Atlas Vs allocated to Kuiper. Boeing can negotiate for one of these by substituting a Falcon 9 for it (Kuiper already intends to use 3 Falcon 9) or substituting a Vulcan Centaur for it if the Vulcan cadence will be high enough soon enough. Boeing's decision to continue with Starliner under these circumstances must be made fairly soon, because otherwise ULA intends to launch all remaining non-Starliner Atlas V by the end of 2025, and ULA and Kuiper would need some time to make the adjustment. Let's guess that such a deal must be made by end of 2024.
-
#774
by
SoftwareDude
on 04 Jul, 2024 16:57
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
That makes sense to me. I guess I would have said something like, "A configuration update to Starliner in order support a longer stay at ISS."
-
#775
by
laszlo
on 04 Jul, 2024 17:38
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
That makes sense to me. I guess I would have said something like, "A configuration update to Starliner in order support a longer stay at ISS."
But, since in this context "configuration" has a specific meaning different from "products" you wouldn't have been referring to the same thing or describing the same actions.
-
#776
by
SoftwareDude
on 04 Jul, 2024 17:59
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
That makes sense to me. I guess I would have said something like, "A configuration update to Starliner in order support a longer stay at ISS."
But, since in this context "configuration" has a specific meaning different from "products" you wouldn't have been referring to the same thing or describing the same actions.
I don't understand some of the language. A configuration change means to a software engineer changes to parameters in tables and files. Changes to software mean different code and different executables. Something like this happened on OFT-1, where they changed some tables to avoid a collision during separation from the Service Module, and it was termed a software change. To me that was a configuration change, a change to the parameters of the software, but maybe configuration change is loaded word for other engineers.. Existing software can be tested for all sorts of parameter changes. Actual software changes, rolling out new software to something flying people in space; I hope they are not doing that.
-
#777
by
laszlo
on 04 Jul, 2024 18:55
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
That makes sense to me. I guess I would have said something like, "A configuration update to Starliner in order support a longer stay at ISS."
But, since in this context "configuration" has a specific meaning different from "products" you wouldn't have been referring to the same thing or describing the same actions.
I don't understand some of the language. A configuration change means to a software engineer changes to parameters in tables and files. Changes to software mean different code and different executables. Something like this happened on OFT-1, where they changed some tables to avoid a collision during separation from the Service Module, and it was termed a software change. To me that was a configuration change, a change to the parameters of the software, but maybe configuration change is loaded word for other engineers.. Existing software can be tested for all sorts of parameter changes. Actual software changes, rolling out new software to something flying people in space; I hope they are not doing that.
That's because you're conflating software engineering and systems engineering.
As far as rolling out new software to something flying people in space, look up the work-around for the failed abort switch on the Apollo 14 LM. It was developed in real time and manually uploaded. It consisted of a software patch and flight procedures that the astronauts were seeing for the first time; no simulator practice. It saved the landing.
-
#778
by
SoftwareDude
on 04 Jul, 2024 19:10
-
“We updated some products on board to support the continued docked duration through the month of July and through the higher positive beta periods we are approaching,”
What are products?
I believe that these are data tables and other software updates to deal with the current and future states of the vehicle. The comment about high beta angles indicates that they need to change power management the solar cells differently from the initially planned orbital period.
That makes sense to me. I guess I would have said something like, "A configuration update to Starliner in order support a longer stay at ISS."
But, since in this context "configuration" has a specific meaning different from "products" you wouldn't have been referring to the same thing or describing the same actions.
I don't understand some of the language. A configuration change means to a software engineer changes to parameters in tables and files. Changes to software mean different code and different executables. Something like this happened on OFT-1, where they changed some tables to avoid a collision during separation from the Service Module, and it was termed a software change. To me that was a configuration change, a change to the parameters of the software, but maybe configuration change is loaded word for other engineers.. Existing software can be tested for all sorts of parameter changes. Actual software changes, rolling out new software to something flying people in space; I hope they are not doing that.
That's because you're conflating software engineering and systems engineering.
As far as rolling out new software to something flying people in space, look up the work-around for the failed abort switch on the Apollo 14 LM. It was developed in real time and manually uploaded. It consisted of a software patch and flight procedures that the astronauts were seeing for the first time; no simulator practice. It saved the landing.
Regarding terms used by system engineering versus software engineering, hmm, non-system engineers might get the wrong idea. I do remember doing stuff like that fix on Apollo. Changing a few lines of code, we called them ZAPS, where the binary code had a change zapped into the executable, no reassemble or recompile necessary. We left space in the executable so that the new code could be placed there, and branch instructions were zapped and placed over the existing code to jump to the new piece of code, and the latest piece of code jumped back into the old code. Fortunately, we know better than to do things like that now, or at least I think we do. Modern software is too complex for that.
-
#779
by
waveney
on 04 Jul, 2024 19:22
-
Drifting ever more off topic:
I once live patched (in hex) the OS of a live telephone exchange handing half of Scotland's long distance traffic. (To diagnose a hardware fault ...)
