![\"\"](\"https:\/\/www.nasaspaceflight.com\/wp-content\/uploads\/2010\/12\/A413.jpg\" "\\"A4\\"")
Specifically, \u201cData 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.\u201d<\/p>\nAs the International Space Station prepares to enter a new era of governmental (ATV, HTV, and Progress) and commercial (SpaceX\u2019s Dragon and Orbital\u2019s Cygnus) unmanned resupply services, the ISS Program (ISSP) is pressing ahead with three software upgrades for the Space Station \u2013 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.<\/p>\n
General Overview:<\/p>\n
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\u2019s specific role in \u201cintegration of current and future visiting vehicles.\u201d<\/p>\n
Among the software changes \u2013 one of which will be implemented prior to the launch of JAXA\u2019s (Japan Aerospace Exploration Agency\u2019s) HTV automated resupply spacecraft to the ISS in the middle of next month (January 2011) \u2013 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\u2019s Caution and Warning system.<\/p>\n
Issue #1: How to Support Multiple Vehicles on ISS (Software):<\/p>\n
Currently, the software architecture on the ISS is \u201cstatic,\u201d using shared C&C (Command and Communication) MDM (Multiplexer Demultiplexer) memory to handle visiting vehicle telemetry. Using JAXA\u2019s HTV as an example, \u201ctwo different command routing logical destination codes exist: HTV_1553 and HTV_PROX both send commands to the HTV but through different paths\u201d \u2013 a system that will not be able to handle certain visiting vehicle requirements in the future.<\/p>\n
Specifically, \u201cData 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.\u201d<\/p>\n
Presently, these data paths are managed in real-time by ISE, and APID (Applications Process Identification) takes responsibility for \u201ccommand routing.\u201d<\/p>\n
However, this \u201cstatic\u201d operation is scheduled to change in 2012 with the uplink of the CCS (Command Communication Software) R12 updates\/upgrades and the introduction of \u201cdynamic command routing to ISS for visiting vehicles.\u201d<\/p>\n
According to the MOD presentation from earlier this month, the 2012 CCS R12 uplink will reconfigure the handling systems on the ISS so that \u201cCommand and telemetry routing will be grouped into the same category and both will be configured with a new data path selection command.\u201d<\/p>\n
Company News (adsbygoogle = window.adsbygoogle || []).push({});<\/p>\n This will enable different \u201cmemory areas\u201d in the ISS\u2019s computer system to be selected and used during multiple visiting vehicle operational times. In turn, each \u201cmemory area\u201d can be connected to\/linked to a specific visiting vehicle via a visiting vehicle designator: HTV-A, Dragon-A, Dragon-B \u2013 all of which will enable data to reach its intended destination in an efficient manner.<\/p>\n Under the new dynamic command routing software, \u201cSingle destination code \u2018HTV\u2019 would send command to the appropriate destination based on the data mapping configuration commands.\u201d<\/p>\n 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.<\/p>\n However, there maybe a need to update some ground segment architecture at visiting vehicle partner centers and MCC-H (Mission Control Center \u2013 Houston).<\/p>\n Moreover, there are four Ops related issues that have been raised as a result of this planned software upgrade.<\/p>\n \u201cLoad shed causes commands to visiting vehicles; undesirable while in free flight,\u201d notes the MOD presentation. \u201cCurrent 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.\u201d<\/p>\n This means that during dynamic routing, an ISS power failure\/spike (or general power issue) holds the potential to send a \u201cload shed\u201d command to a free-flying visiting vehicle.<\/p>\n 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 \u201cmasked,\u201d thus preventing any inadvertent commands from reaching the visiting vehicle while it\u2019s in free-flight.<\/p>\n \u201cEmergency event such as fire in a free-flying vehicle may cause undesired ISS automated response,\u201d notes the software change presentation. \u201cCurrent architecture uses INT (Internal) MDM for emergency response; free-flying visiting vehicle comm systems bypass the INT.\u201d<\/p>\n To counter this problem, the presentation notes that a new docking hub \u201cmay require emergency response software to be elevated to C&C since the docking hub systems will likely have their own MDM.\u201d<\/p>\n 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 \u201cautomatic safing on the ISS\u201d would be required.<\/p>\n The same inhibit command for the \u201cload shed\u201d issue would most likely be used to ensure this free-flight\/non-free-flight distinction is made.<\/p>\n 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.<\/p>\n \u201cNew architecture does not accommodate unique PROX GPS data path currently available in CCS. Due to CB-EXT bus bandwidth limitations, a set of \u201cextended\u201d PROX GPS data is available only when HTV data is turned off.\u201d<\/p>\n Current thinking to mitigate this problem is to configure the software to recognize this extended GPS data as a \u201cdummy\u201d visiting vehicle and assign it a unique ID and specific data path.<\/p>\n Finally, the last Ops issue is the configuration of RMAD data to RWS. As the MOD presentation states, \u201cTwo data pipes exist to send visiting vehicle data to the RWS overlays: one for HTV and one for Dragon\/Cygnus.\u201d<\/p>\n 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.<\/p>\n 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 \u201csupport second visiting vehicle hardline data path.\u201d<\/p>\n Issue #2: Fixing Problems with CCS Response to CUCU Failures:<\/p>\n As originally conceived during COTS (Commercial Orbital Transportation Services) \u2013 Dragon or Cygnus capsule \u2013 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.<\/p>\n However, this configuration is now out of spec with the latest operations concept for the COTS vehicles.<\/p>\n 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.<\/p>\n While it is hoped that this change can be implemented prior to SpaceX\u2019s 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.<\/p>\n 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.<\/p>\n Issue #3: HTV Injector Overheat Response:<\/p>\n \u201cDuring 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,\u201d notes the ISS software presentation.<\/p>\n 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 \u2013 Loss Of Signal) with MCC.<\/p>\n 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).<\/p>\n Meanwhile, JAXA has already updated HTV2\u2019s software to set the warning message trigger at 320-degrees C. The previous limit was 260-degrees C.<\/p>\n Additionally, ground control crews will automatically switch propulsion strings \u2013 during periods of direct contact\/communication with HTV2 \u2013 if the injector temperatures reach 320-degrees C.<\/p>\n","protected":false},"excerpt":{"rendered":" As the International Space Station prepares to enter a new era of governmental (ATV, HTV, and Progress) and commercial (SpaceX\u2019s Dragon and Orbital\u2019s Cygnus) unmanned resupply services, the ISS Program (ISSP) is pressing ahead with three software upgrades for the Space Station \u2013 which are aimed at accommodating multiple visiting vehicles at a single time, improving […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":"","_links_to":"","_links_to_target":""},"categories":[2],"tags":[1839,233],"class_list":["post-40569","post","type-post","status-publish","format-standard","hentry","category-news","tag-htv","tag-iss"],"acf":[],"_links":{"self":[{"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/posts\/40569"}],"collection":[{"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/comments?post=40569"}],"version-history":[{"count":0,"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/posts\/40569\/revisions"}],"wp:attachment":[{"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/media?parent=40569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/categories?post=40569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/starpath.global\/blog\/wp-json\/wp\/v2\/tags?post=40569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}See Also<\/h4>\n
\n
![\"\"](\"https:\/\/www.nasaspaceflight.com\/wp-content\/uploads\/2010\/12\/A85.jpg\" "\\"A8\\"")
A second issue raised by the software change is the potential \u201cundesired response\u201d by the ISS computers in the event of a fire in a free-flying visiting vehicle.<\/p>\n![\"\"](\"https:\/\/www.nasaspaceflight.com\/wp-content\/uploads\/2010\/12\/A59.jpg\" "\\"A5\\"")
\u201cOperationally 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,\u201d notes the MOD presentation.<\/p>\n![\"\"](\"https:\/\/www.nasaspaceflight.com\/wp-content\/uploads\/2010\/12\/HT3.jpg\" "\\"HT3\\"")
During post-flight analysis, it was discovered that more temperature margin existed than was baselined prior to the HTV1 mission. Therefore, \u201cEven though the probability [was] small, there [was] a chance that if HTV [held] outside of 300 m, injector temperature might approach catastrophic limits.\u201d<\/p>\n