Question SSU Inter-communications thread

[DaveS]

Also the SSU specific user interface is rather clunky, but its open-source, so its possible to improve it, for example to include feedback from mission control (Needed since the crew doesn't have full authority over the spacecraft). Also, there is the Space Shuttle Vessel fork of SSU, with ongoing development by GLS, which might see a first release in the closer future.

Yes, ideally we would have the proper sound coverage (we do for the Terminal Countdown), but for now you have to know your systems and timing. The GLS is (or at least should be) very picky. The first launch attempt of STS-88 ended in a scrub at T-23 seconds due to a late pick-up of held count at T-31 seconds due to need to further troubleshoot a Master Alarm generated by hydraulic system 1 when APU 1 was started. Turned out be caused by a "switch tease" by the APU 1 START/OPR switch on panel R2 and not system fault. The switch tease caused a automatic T-4 minutes due to the Master Alarm. It was decided after a few minutes of discussion to resume the countdown but have CGLS insert and manual hold at T-31 where they would hold the countdown again, if the problem was not resolved at that point.

The CAPU, CISL, CHYD and CGLS engineers in the launch team just took a bit too long on the outbrief to the OTC and NTD for the NTD to give CGLS the clearance to resume the count. By the time CGLS had hit the "RESUME" button, it was too late and the launch window had expired leading to a manual cut-off command direction to CGLS from the NTD.

 

[Urwumpe]

Yes, ideally we would have the proper sound coverage (we do for the Terminal Countdown), but for now you have to know your systems and timing.

And technically, its the gold-plated solution. Keep it simple, text-based. Somebody younger than me can add audio call-outs or text-to-speech features later, I know I have neither the time nor the skills to work on such a feature.

The GLS is (or at least should be) very picky. The first launch attempt of STS-88 ended in a scrub at T-23 seconds due to a late pick-up of held count at T-31 seconds due to need to further troubleshoot a Master Alarm generated by hydraulic system 1 when APU 1 was started. Turned out be caused by a "switch tease" by the APU 1 START/OPR switch on panel R2 and not system fault. The switch tease caused a automatic T-4 minutes due to the Master Alarm. It was decided after a few minutes of discussion to resume the countdown but have CGLS insert and manual hold at T-31 where they would hold the countdown again, if the problem was not resolved at that point.

The CAPU, CISL, CHYD and CGLS engineers in the launch team just took a bit too long on the outbrief to the OTC and NTD for the NTD to give CGLS the clearance to resume the count. By the time CGLS had hit the "RESUME" button, it was too late and the launch window had expired leading to a manual cut-off command direction to CGLS from the NTD.

Also you need to differ between the various flight rules in place at different time. Especially before the last hold ends, there are many decisions possible - often with many different stakeholders pushing for their own interests there.

Technically speaking, we need a rule-based expert system like engine there in the background to implement the various actors there. The good news, they are human, they act and think slow - it should be possible to simulate a lot of the decision process without slowing down the single CPU core running Orbiter. The bad news: When there is a lot of freedom to discuss and decide creatively, this approach will get to its limits. Maybe to the point, that human input is needed that can break immersion and/or realism. I can imagine, that there could be a "simple" linear algebra solution (huge sparse matrix, enormous vectors, joyful mathematicians) possible to model a utility function for the very special and restricted case of a Space Shuttle launch. But I can be wrong.

Also, we still need to solve the architecture issues left in SSU one day.

 

[DaveS]

It isn't really the human aspect that makes things slow, but the technological. It all comes down to what your instrumentation can tell you. In the case of STS-88, the problem was that nothing other than a brief Master Alarm was generated.

The C&W matrix on F7 was blank, and there wasn't anything in the omboard FAULT SUM either. The PLT reported no unexpected error messagws when he did the standard clearing of it per the OTC request.

You may think that the launch team wpuld have access to far more detailed data, but they don't especially during the Terminal Countdown. The event was so brief that the GLS which usually logs what caused the HOLD flag to be set, only recorded the Master Alarm triggering but not the actual MA trigger event itself.

 

[Urwumpe]

It isn't really the human aspect that makes things slow, but the technological. It all comes down to what your instrumentation can tell you. In the case of STS-88, the problem was that nothing other than a brief Master Alarm was generated.

We are talking about different things there.

 

[DaveS]

We are talking about different things there.

Maybe. My point was that the length it takes the launch team to clear any issue is related to how well instrumented the system is. One example of this is the unplanned hold at T-31 seconds for STS-135 when the two GOX Vent Arm (GVA) Retract switches failed to indicate "ON" at T-37 seconds (GLS one-shot verification of GVA retract). To the GLS team it was immediately clear that the GVA element is what caused the hold and it was the two Retract switches that was the components that was out of the expected configuration.

And they then identified the LCC that controlled the GVA retract configuration(GSE-13) and executed the pre-planned contingency procedure to manually verify the GVA status using one of the many cameras at the pad (they elected to use OTV-062 on the FSS to verify that the GOX Vent Hood was over the maintenance platform). Once they had visually verified a good retract of the GVA, they had satisfied the waiver of GSE-13 and could proceed with the launch by having GLS masked from seeing the two faulty switches.

 

[Urwumpe]

Maybe. My point was that the length it takes the launch team to clear any issue is related to how well instrumented the system is. One example of this is the unplanned hold at T-31 seconds for STS-135 when the two GOX Vent Arm (GVA) Retract switches failed to indicate "ON" at T-37 seconds (GLS one-shot verification of GVA retract). To the GLS team it was immediately clear that the GVA element is what caused the hold and it was the two Retract switches that was the components that was out of the expected configuration.

And they then identified the LCC that controlled the GVA retract configuration(GSE-13) and executed the pre-planned contingency procedure to manually verify the GVA status using one of the many cameras at the pad (they elected to use OTV-062 on the FSS to verify that the GOX Vent Hood was over the maintenance platform). Once they had visually verified a good retract of the GVA, they had satisfied the waiver of GSE-13 and could proceed with the launch by having GLS masked from seeing the two faulty switches.

My perspective is simpler technically, that such a decision process takes multiple hundred timesteps to take place, and thus, can also be executed really slow, even at 10x time warp. It just needs to be broken up into small enough rules.

 

[DaveS]

Well, we still do have the old communications system that is enabled with the Tab key. CommModeHandler is what it is currently called. Right now it only has one real function and that is to display the text "[MCC]:Atlantis, Houston, go for launch." with the use of oapiAnnotationSetText();.

For prelaunch, it would have be changed to transmit/receive on KSC-OIS channel 212 (Main Orbiter team communications channel, everyone goes to 212 after the T-20 minute hold) and the two A/G's. OIS-212 is broadcast through the T0 umbilicals on both ICOMs.