As the International Space Station prepares to enter a new era of governmental (ATV, HTV, and Progress) and commercial (SpaceX’s Dragon and Orbital’s Cygnus) unmanned resupply services, the ISS Program (ISSP) is pressing ahead with three software upgrades for the Space Station – which are aimed at accommodating multiple visiting vehicles at a single time, improving visiting vehicle communications, and correcting issues identified during previous visiting vehicle missions to the orbital outpost.
General Overview:
In the 20-page MOD (Mission Operations Directorate) presentation (available for download on L2), a comprehensive overview of the three proposed software changes is outlined, as well as the MOD’s specific role in “integration of current and future visiting vehicles.”
Among the software changes – one of which will be implemented prior to the launch of JAXA’s (Japan Aerospace Exploration Agency’s) HTV automated resupply spacecraft to the ISS in the middle of next month (January 2011) – are software specific changes for the accommodation of multiple visiting vehicles (including commercial vehicles) at a single time, projected alterations to the COTS UHF Communication Unit and upgrades to HTV2’s Caution and Warning system.
Issue #1: How to Support Multiple Vehicles on ISS (Software):
Currently, the software architecture on the ISS is “static,” using shared C&C (Command and Communication) MDM (Multiplexer Demultiplexer) memory to handle visiting vehicle telemetry. Using JAXA’s HTV as an example, “two different command routing logical destination codes exist: HTV_1553 and HTV_PROX both send commands to the HTV but through different paths” – a system that will not be able to handle certain visiting vehicle requirements in the future.
Specifically, “Data routing is accomplished with two commands that have the potential to conflict with each other: Select HTV Data Path and Select Dragon (SpaceX)/Cygnus (Orbital) Data Path.”
Presently, these data paths are managed in real-time by ISE, and APID (Applications Process Identification) takes responsibility for “command routing.”
However, this “static” operation is scheduled to change in 2012 with the uplink of the CCS (Command Communication Software) R12 updates/upgrades and the introduction of “dynamic command routing to ISS for visiting vehicles.”
According to the MOD presentation from earlier this month, the 2012 CCS R12 uplink will reconfigure the handling systems on the ISS so that “Command and telemetry routing will be grouped into the same category and both will be configured with a new data path selection command.”
This will enable different “memory areas” in the ISS’s computer system to be selected and used during multiple visiting vehicle operational times. In turn, each “memory area” can be connected to/linked to a specific visiting vehicle via a visiting vehicle designator: HTV-A, Dragon-A, Dragon-B – all of which will enable data to reach its intended destination in an efficient manner.
Under the new dynamic command routing software, “Single destination code ‘HTV’ would send command to the appropriate destination based on the data mapping configuration commands.”
Furthermore, no changes to APID tables for currently operational visiting vehicles will be required for this upgrade, therefore eliminating the need to update all HTV PCS (Procedure Completion Sheet) pages and crew and joint ground procedures.
However, there maybe a need to update some ground segment architecture at visiting vehicle partner centers and MCC-H (Mission Control Center – Houston).
Moreover, there are four Ops related issues that have been raised as a result of this planned software upgrade.
“Load shed causes commands to visiting vehicles; undesirable while in free flight,” notes the MOD presentation. “Current architecture has load shed commands to power down visiting vehicle components built with the command instances that are designed to static route only to the 1553 hardline connection.”
This means that during dynamic routing, an ISS power failure/spike (or general power issue) holds the potential to send a “load shed” command to a free-flying visiting vehicle.
To work around this issue, a software inhibit will be added to allow any automated C&C MDM commands to visiting vehicles during pathway configuration to be “masked,” thus preventing any inadvertent commands from reaching the visiting vehicle while it’s in free-flight.
A second issue raised by the software change is the potential “undesired response” by the ISS computers in the event of a fire in a free-flying visiting vehicle.
“Emergency event such as fire in a free-flying vehicle may cause undesired ISS automated response,” notes the software change presentation. “Current architecture uses INT (Internal) MDM for emergency response; free-flying visiting vehicle comm systems bypass the INT.”
To counter this problem, the presentation notes that a new docking hub “may require emergency response software to be elevated to C&C since the docking hub systems will likely have their own MDM.”
Furthermore, if the CCS were to handle an emergency response, steps would need to be taken to ensure that the software could properly distinguish if a visiting vehicle was in free-flight or not. This would be necessary to determine if “automatic safing on the ISS” would be required.
The same inhibit command for the “load shed” issue would most likely be used to ensure this free-flight/non-free-flight distinction is made.
The third of four Ops issues identified relates to the unique PROX GPS data path that will not be accommodated in the new software upgrades.
“New architecture does not accommodate unique PROX GPS data path currently available in CCS. Due to CB-EXT bus bandwidth limitations, a set of “extended” PROX GPS data is available only when HTV data is turned off.”
Current thinking to mitigate this problem is to configure the software to recognize this extended GPS data as a “dummy” visiting vehicle and assign it a unique ID and specific data path.
Finally, the last Ops issue is the configuration of RMAD data to RWS. As the MOD presentation states, “Two data pipes exist to send visiting vehicle data to the RWS overlays: one for HTV and one for Dragon/Cygnus.”
Given that both the PROX and CUCU (COTS UHF Communication Unit) links could be active at the same time under the software upgrades, a new command to set the RMAD data pipes will be required since there will be no way for the software to automatically determine which path to use.
Over the coming year, ISS engineers will continue to refine the software changes planned for 2012, updating procedures for configuring data paths in rendezvous and docked phases, updated PCS to include new data path configuration commands, retesting interfaces and MCC/ops team support, and assisting with the planning for the installation of new 1553 jumper installation on Node-2 zenith to “support second visiting vehicle hardline data path.”
Issue #2: Fixing Problems with CCS Response to CUCU Failures:
As originally conceived during COTS (Commercial Orbital Transportation Services) – Dragon or Cygnus capsule – vehicle docked missions, CUCU (COTS UHF Communication Unit) RIO 1 would always be selected as the primary communications channel, with RIO 2 serving only as a backup in the event of RIO 1 failure.
However, this configuration is now out of spec with the latest operations concept for the COTS vehicles.
“Operationally may be desirable to have RIO2 as the Primary due to better comm antenna coverage. In this case, FDIR (Fault Detection Identification/Isolation and Recovery/Recognition) would not be available,” notes the MOD presentation.
As such, ISE has requested an FDIR implementation change to favor RIO 2 as the primary channel and, in a failure scenario, automatically switch to RIO 1.
While it is hoped that this change can be implemented prior to SpaceX’s Dragon C3 mission, there remains the possibility that this changeover could produce high rates of unnecessary retreat maneuvers by Dragon (either through its own software or as commanded by the ISS crew) during its approach to the ISS.
Currently, though, the MOD does not believe the RIO 1 to RIO 2 changeover prior to Dragon C3 would be a safety hazard to the ISS crew since they will still have command capability to Dragon.
Issue #3: HTV Injector Overheat Response:
“During HTV1 (September-November 2009), there was a thruster overtemp issue caused by a high duty cycle when performing 300 m hold. Team worked around this by swapping thruster strings multiple times and bypassing some demo objectives to quickly get closer to ISS where thruster duty is lower,” notes the ISS software presentation.
During post-flight analysis, it was discovered that more temperature margin existed than was baselined prior to the HTV1 mission. Therefore, “Even though the probability [was] small, there [was] a chance that if HTV [held] outside of 300 m, injector temperature might approach catastrophic limits.”
As such, ISE has coordinated an upgrade of the injector overtemp advisory. This upgrade will involve a warning event with planned crew action to abort HTV approach to ISS should the crew receive a injector overtemp warning message while the HTV is out of contact (LOS – Loss Of Signal) with MCC.
These upgrades, along with crew procedure deltas and crew familiarization with the new ops will be implemented prior to the launch of HTV2 next month (January 2011).
Meanwhile, JAXA has already updated HTV2’s software to set the warning message trigger at 320-degrees C. The previous limit was 260-degrees C.
Additionally, ground control crews will automatically switch propulsion strings – during periods of direct contact/communication with HTV2 – if the injector temperatures reach 320-degrees C.