-
#560 by meberbs on 10 Jan, 2020 00:01
-
(Good thing we aren't in L2, since your misinformation certainly does not belong there.)This appears to repeat the erroneous assumption that the leading surfaces of the ISS are at greater risk from MMOD.
In fact, they are some of the safest.
There is almost nothing at 400 km going slower than the ISS. More than 100 m/s less and it will reentry immediately.
Do you have a reference for the leading edge of the ISS taking fewer impacts? This statement doesn’t make sense to me. The idea of things “going slower” than the ISS assumes items in precisely the same orbital track, the issue is presumably not items in precisely the same orbital path, it is items in distinct orbital paths that intersect.
Any Orbital Mechanics 101 textbook or online tutorial.
No it does not make that assumption.
If something has a perigee as low as the ISS but coming from a substantial angle, a different inclination orbit, the sides have much higher chance of impact.
The only things being overtaken are exoatmospheric air constituents.
But this is no longer L2.
SMAD, which is often considered THE spacecraft design textbook lists has a table called "common sense design guidelines" in a section on orbital debris. It includes "Orient sensitive objects that must be exposed to space on the spacecraft's trailing edge or facing the Earth to decrease particle strikes." It does not list the front since this is an obviously bad idea. The issue is not things being "overtaken" but things travelling in the opposite direction, which is also the worst case for impact energy.
You apparently didn't finish thinking through your thought experiment on a different inclination orbit. For a baseline case take a perfectly perpendicular intersection, with equal orbital velocity. Given equal area, there is an equal probability of an impact on the front or the side in this circumstance, as easily seen by transforming to a reference frame where the ISS is stationary, as the debris would then be approaching from a 45 degree angle.
The link you provided for an early ISS config shows that things with greatest risk are the progress and soyuz modules hanging down with the large exposed area to the direction of motion. You are however completely misrepresting the results, as it clearly states that the reason for the high risk is not the probability of impact, but "The reason for this result is simply that low-weight and relatively low-performance shields protect areas of these elements." That paper is tracking the wrong metric to even contribute to this discussion since it accounts for shielding levels rather than providing raw rate of impacts.
And if that wasn't enough evidence that your assertions are not supported by textbooks as you claim, here is a NASA model that shows impact risk vs location for the ISS, be sure to read the description below the animation.
https://www.flickr.com/photos/nasa_appel/8047497398
(Also, do not take this as me agreeing with OM72's claims that MMOD is the reason propellant needs to be burnt off, as not only do I see no way for us to know this, it doesn't make sense, since a hole in a partially empty fuel tank shouldn't be any less of a catastrophic issue than if the tank was somewhat more full. And doesn't even start to address the original question of if prop needed to be burned off before docking (for whatever reason) why not do so in one of a dozen other ways than doing a sub-orbital insertion) -
#561 by TheRadicalModerate on 10 Jan, 2020 04:38
-
This appears to repeat the erroneous assumption that the leading surfaces of the ISS are at greater risk from MMOD.
In fact, they are some of the safest.
There is almost nothing at 400 km going slower than the ISS. More than 100 m/s less and it will reentry immediately.
Do you have a reference for the leading edge of the ISS taking fewer impacts? This statement doesn’t make sense to me. The idea of things “going slower” than the ISS assumes items in precisely the same orbital track, the issue is presumably not items in precisely the same orbital path, it is items in distinct orbital paths that intersect.
You guys are pretty far down the rabbit hole. Let's just stipulate that it might be a good idea to burn off some prop. Docking moment problems? MMOD mitigation? Nothing? Who knows?
My point was that even if there's a real reason to burn off prop, there are much better ways of doing it than a perigee raise, so this doesn't explain the low perigee at insert. -
#562 by woods170 on 10 Jan, 2020 07:28
-
Those are not requirements. (Well, to an extent #2 is but all that is contained in what is called the ICD)
In my opinion, you're really looking at this in too fine a matter. Concept of Operations are a set of just that, concepts, on how to achieve the overall mission within the various *INTEGRATED* vehicle design requirements, constraints, objectives, etc of any given flight.
So in other words, both Starliner and D2 ConOps work. They just skinned-the-cat differently for their own reasons in the various trade space each company respectively worked.
In the case of Starliner, yes, you get a free entry if you want to take it. But the ConOps assumes that is not going to be the case. LAS is no longer required but all the prop is still there. This vehicle will be docked and in-orbit for approximately 6 months and generally facing the forward velocity vector. It was CHOSEN to burn off as much prop that would not be required for the *entire* mission duration for potential MMOD reasons.
This appears to repeat the erroneous assumption that the leading surfaces of the ISS are at greater risk from MMOD.
In fact, they are some of the safest.
There is almost nothing at 400 km going slower than the ISS. More than 100 m/s less and it will reentry immediately.
The recent ASAP report confirms that they consider MMOD the most likely cause of LOC, so it remains a critical issue. It’s just that the Starliner prop tank locations are not the worst of it and you don’t have any information to support it as THE reason to burn off propellants.
Also, if MMOD is an issue Boeing could have opted to go for a solution similar to the one applied on Crew Dragon: Kevlar-stuffed Whipple Shield. -
#563 by eeergo on 10 Jan, 2020 08:12
-
This appears to repeat the erroneous assumption that the leading surfaces of the ISS are at greater risk from MMOD.
In fact, they are some of the safest.
Any Orbital Mechanics 101 textbook or online tutorial.
edit:a quick Google search on my iPhone pulls up. The node up front is way down the list.
Not good to rely on a quick on-the-move search, although an even quicker one might have shown you this: https://commons.wikimedia.org/wiki/File:ISS_impact_risk.jpg
So, as common sense dictates, on average the leading surfaces will be more exposed to MMOD hits (obviously in +XVV attitude)
-
#564 by Comga on 10 Jan, 2020 13:11
-
This appears to repeat the erroneous assumption that the leading surfaces of the ISS are at greater risk from MMOD.
In fact, they are some of the safest.
Any Orbital Mechanics 101 textbook or online tutorial.
edit:a quick Google search on my iPhone pulls up. The node up front is way down the list.
Not good to rely on a quick on-the-move search, although an even quicker one might have shown you this: https://commons.wikimedia.org/wiki/File:ISS_impact_risk.jpg
So, as common sense dictates, on average the leading surfaces will be more exposed to MMOD hits (obviously in +XVV attitude)
Yeah
Please excuse my silly error.
Bad day
(Nice graphic there) -
#565 by SWGlassPit on 10 Jan, 2020 14:17
-
Orbital debris guy for ISS here.
The highest risk areas are indeed on the ram-facing surfaces. The lowest risk areas are on the wake and nadir surfaces.
The majority of the orbital debris threat comes in from two vectors, in the local horizontal plane, thirty degrees to the left and right of the velocity vector. -
#566 by SoftwareDude on 10 Jan, 2020 16:03
-
A normal hiccup in software? I've never heard of such a thing. My fear is Boeing hires newbees to do the software, which is something they do, and that costs NASA an extra $100 million.I wonder if NASA requires Boeing to launch another unmanned test, will NASA pay them to do it?
IMO it likely depends on the final root cause for OFT Mission Fail and Boeing's degree of culpability for it.
Was it a normal hiccup in new software that displayed itself in a spectacular way, or was it a screw up that no way in hell should have happened? Only time will tell. -
#567 by Vettedrmr on 10 Jan, 2020 16:21
-
New hires developing software for safety-critical systems has been going on for decades. I had just as many issues with experienced engineers making mistakes as I did new ones. It's about the processes in place, and the culture implementing those processes. Not SW, but the issue with the pilot chute not being attached to the main, and a hi-res photo taken, supposedly used to verify the pin installation NOT BEING LOOKED AT that shows processes in place that were apparently not implemented.
I truly hope Starliner's next flight is a total success, just like I hope DM-2 goes off without a hitch. USA has been way too long without a way to get crews to orbit.
Have a good one,
Mike -
#568 by SoftwareDude on 10 Jan, 2020 19:10
-
New hires developing software for safety-critical systems has been going on for decades. I had just as many issues with experienced engineers making mistakes as I did new ones. It's about the processes in place, and the culture implementing those processes. Not SW, but the issue with the pilot chute not being attached to the main, and a hi-res photo taken, supposedly used to verify the pin installation NOT BEING LOOKED AT that shows processes in place that were apparently not implemented.
I hope they are successful too. However, I am a very experienced software engineer and I know what happens when someone throws the troop of inexperienced people at a problem. It's called creating a rewrite or going out of business.
I truly hope Starliner's next flight is a total success, just like I hope DM-2 goes off without a hitch. USA has been way too long without a way to get crews to orbit.
Have a good one,
Mike
There are hints of conflicting information in what Bridenstine and Boeing say about the Starliner's test. There is no way for me to know for sure, but it is possible that Starliner's software, regardless of timer setting, has a poor architecture. For example, the RCS eliminates dead-space as OMT is in a burn. but the OMT is not in a burn, supposedly confused about the time.
This is what we software engineers call a bad smell. Either NASA and Boeing are telling a partial truth, or there is a real mess in the software architecture. -
#569 by Svetoslav on 10 Jan, 2020 19:31
-
I have a kinda offtopic question.
Do you think the latest scandal concerning the MAX could have an impact to the space program or Starliner? -
#570 by SWGlassPit on 10 Jan, 2020 20:06
-
I have a kinda offtopic question.
Do you think the latest scandal concerning the MAX could have an impact to the space program or Starliner?
No. -
#571 by laszlo on 10 Jan, 2020 20:10
-
..This is what we software engineers call a bad smell.
In 42 years of professional software engineering in 9 different companies in 5 states, I've never heard anyone refer to something like this as a bad smell. Please don't make unsupported generalizations of an entire profession.
The other thing bothering me about the software discussions in this thread is that most of the criticisms are not even based on hearsay, let alone actual facts. There's an awful lot of criticism of how the system was implemented with no provable facts and no knowledge of the overall system engineering.
For example, all that up-thread ripping of "the state machine" and we don't even know if there actually is one. They may have implemented a stateful system, but not as a state machine. Or not. The point is, we don't know.
If we haven't seen the source code, haven't seen the design documents and haven't been part of the group carrying out the procedures, then all we're doing is ignorant gossiping. How about we decide that we're better than that and stick to the documented facts?
-
#572 by SoftwareDude on 10 Jan, 2020 20:12
-
I have a kinda offtopic question.
Yes, the MAX has an impact. It puts NASA in a risky situation. Suppose NASA goes ahead with a manned Starliner flight because they honestly believe that the data from the failed test suffices to move to manned flight. Then there is an accident on the manned mission. Fair or not, everyone will blame NASA.
Do you think the latest scandal concerning the MAX could have an impact to the space program or Starliner? -
#573 by Svetoslav on 10 Jan, 2020 20:18
-
Yes, the MAX has an impact. It puts NASA in a risky situation. Suppose NASA goes ahead with a manned Starliner flight because they honestly believe that the data from the failed test suffices to move to manned flight. Then there is an accident on the manned mission. Fair or not, everyone will blame NASA.
That's a fair point.
However, let's imagine something else. Boeing needs a success right now. The first crewed orbital flight since the Space Shuttle program ended, especially if it comes before Crew Dragon, would be a huge boon for the company.
Plus Starliner already proved that it can safely go to space and back, so... -
#574 by SoftwareDude on 10 Jan, 2020 20:34
-
That is exactly what they will accuse NASA of doing if something goes wrong ie, trying to help Boeing instead of protecting the safety of astronauts.Yes, the MAX has an impact. It puts NASA in a risky situation. Suppose NASA goes ahead with a manned Starliner flight because they honestly believe that the data from the failed test suffices to move to manned flight. Then there is an accident on the manned mission. Fair or not, everyone will blame NASA.
That's a fair point.
However, let's imagine something else. Boeing needs a success right now. The first crewed orbital flight since the Space Shuttle program ended, especially if it comes before Crew Dragon, would be a huge boon for the company.
Plus Starliner already proved that it can safely go to space and back, so... -
#575 by TheRadicalModerate on 10 Jan, 2020 20:44
-
For example, all that up-thread ripping of "the state machine" and we don't even know if there actually is one. They may have implemented a stateful system, but not as a state machine. Or not. The point is, we don't know.
Pardon my design-pattern prejudice, but implementing a stateful software system as anything other than a formal FSM is a recipe for an untestable wad of spaghetti code that's eventually going to bite you. And if you say Moore over Mealy, I'm prepared to give you a stern talking-to.
Fair point on the speculation, but you're not being very fun. -
#576 by SoftwareDude on 10 Jan, 2020 20:56
-
Well, their code has to be stateful even if they wrote it in the 1970s to emulate a 1960s era paper tape run by a mechanical timing mechanism that activates electro-mechanical switches (don't be surprised). Player pianos are the ultimate rocket controllers. A formal software state machine would be fine by me but too much to hope for.
-
#577 by ulm_atms on 10 Jan, 2020 20:59
-
That is exactly what they will accuse NASA of doing if something goes wrong ie, trying to help Boeing instead of protecting the safety of astronauts.Yes, the MAX has an impact. It puts NASA in a risky situation. Suppose NASA goes ahead with a manned Starliner flight because they honestly believe that the data from the failed test suffices to move to manned flight. Then there is an accident on the manned mission. Fair or not, everyone will blame NASA.
That's a fair point.
However, let's imagine something else. Boeing needs a success right now. The first crewed orbital flight since the Space Shuttle program ended, especially if it comes before Crew Dragon, would be a huge boon for the company.
Plus Starliner already proved that it can safely go to space and back, so...
Off topic to a degree but you are absolutely correct. The FAA is going through this exact thing right now. -
#578 by gongora on 10 Jan, 2020 21:06
-
737 is offtopic for this thread.
-
#579 by clongton on 10 Jan, 2020 21:35
-
A normal hiccup in software? I've never heard of such a thing.
"Normal" hiccup in the sense that there are almost always some pieces of code that misbehave in it's FIRST real-world testing. Testing in the lab will only test those scenarios that the software engineers can think of. It does not test those scenarios that they didn't think of. Those only get tested when it actually flies for the very 1st time. And there is almost always some test scenario that the engineers didn't think of. At which time the optimum phrase becomes "oh crap, we didn't think of that".