Why are Space Stations so Hard? Bill Dwyer, NASA-JSC ISS Command and Data Handling System Hardware System Manager Ex-Space Station Freedom Data Management System Integration Manager Ex-Space Station Freedom SW Functional Area Manager Ex-Space Station Freedom Mode Team Chairman (Level-II) 8 th Military and Aerospace Programmable Logic Devices (MAPLD) International Conference 8 Sept. 2005

Development Environment Extended development phase – some articles are on-orbit while others that will interface to it are still in an early phase such as PDR or in some cases not started yet Makes interface definition very challenging Requiring extensive on-ground integration testing is a large complex test rig Widely distributed development sites – International world site distribution Directly contradicting “co-location” axiom for project development Again makes interface definition and testing very difficult After the first two or three element launches, a system can be in multiple lifecycle stages at one time Sustaining, on-orbit troubleshoot and root cause work and upgrade development This multiple-lifecycle-at-one-time state does not allow the post-development resource phase out that is the standard model International export-import regulations serve to extend time required for testing and some aspects of development 1

On-Orbit Operations Coordinating flight control across International boundaries To date, ISS has had a great deal of success in International operations Substantial planning and agreements required On-orbit troubleshooting and repair of failures has not been done to the scale it is being accomplished on ISS Earlier Mir experience very valuable Command and Control computational systems failures during 6A flight timeframe Turns the crew into multi-skilled “mechanics” On-orbit assembly and checkout of major components, including multi-national assembly Attaching new element such as truss element S1 and P1 to existing configuration Upgrading to a new integrated command and data handling system with the addition of multiple new computational systems On-orbit change-out of hardware, especially external hardware Example: CMG failure and change-out on recent flight LF-1 (STS-114) New, unforeseen requirements/needs that must be implemented on-orbit with minimal if any integration testing on the ground External storage platforms such as Z2-truss and External Storage Platform-3 2

On-Orbit Operations Installation of major software systems on-orbit with no operational fidelity sacrifice A “design for” requirement that is ops intensive Fixing “whoopses” – requirements that were not anticipated but need arises during ops For example the 6B box “bowing” problem for C&T and C&DH HW Relocation of major systems due to operations or safety needs For example the Acvanced ECLSS in the U.S. Lab Emergent behavior of large complex systems – sometimes things behave in an unanticipated manner For example restarting large networks after flight 6A command and control computational system failures Difficulty in determining operational life of electronic hardware makes logistical planning very difficult Some good: the ISS computational systems, multiplexer-demultiplexers (MDMs) have proven to be extremely robust, some operating nearly 8 years with no problems Some not-so-good: laptop inventory needs complete replacement 3

Conclusion 1.“The devil is in the details” 2.“The devil is in the integration” 3.“The devil is in the magnitude of the undertaking” 4.“The devil is resource intensive and costs a lot” Building a large multi-element, multi-national space station is indeed hard and expensive. If we underestimate the magnitude of the task, it can, will and has given us more than one “negative surprise”. 4