111 DAY IN THE LIFE: “BRAIN TRANSPLANTS” ON THE INTERNATIONAL SPACE STATION CHAPTER 6 performed in space. The process took about a year to plan and execute. Since then, similar software upgrades have become “routine,” having been performed more than a dozen times since. To reduce cost and assist with scheduling, large-scale ISS software upgrades are now planned to take place once a year. The entire process of identifying changes, developing and testing code, and planning and executing the transition is ongoing. Once a change has been approved and implemented in the code, it is included in the next scheduled upgrade. The ISS hosts three types of computers (see Chapter 5). All critical ISS functions are controlled by the Multiplexer/DeMultiplexers (MDMs). The MDMs, and the Portable Computer System (PCS) that controls them, were designed for regular updates. This chapter discusses how the operations team prepares for and executes this critical task. The crew’s Station Support Computers are upgraded similarly to laptops on Earth and are not discussed here. Major upgrades are scheduled about once a year due to the complexity of the software controlling the ISS. It takes many months of planning and training to accomplish a software upgrade. This schedule allows careful development of the transition. In many ways, a software transition is just as complicated as the execution of a spacewalk or the docking of a new vehicle. The flight director and his or her team work closely throughout the year to prepare for the upgrade. This chapter describes the process of updating the software: changing the code, developing the complicated plan for installing it, testing the plan, executing the plan, and recovering from problems during the upgrade, as sometimes happens. The Life Cycle of Code During the design phase of the ISS, engineers determined which functions the software needed to control. For example, consider the operation of the massive solar arrays, which generate the critical power needed to run the space station. The arrays can articulate at the Solar Alpha Rotary Joint and the Beta Gimbal Assembly (see Chapter 9) to ensure they are always pointed in the direction of the sun. Software tells the arrays where the sun is positioned, and the motion of the ISS as it orbits the Earth. Thus, the arrays will slowly move throughout the orbit to maximize power generation. The arrays are parked and locked in a position during the arrival of docking vehicles to minimize thruster loading on the delicate surfaces of the arrays. The software needs to know how to move the panels to the required position and then use the gears to lock them in a fixed position. Software will respond if, for some reason, the gears have a problem and cannot lock properly (similar to the way a car’s transmission gears crash instead of mesh smoothly). If the power controlling these motors is lost, software will use alternate power or motors to complete the critical task. This is just one example of how engineers will define all the needed software functions and then write detailed requirements to describe how each function will operate. Flight controllers play a part in developing these requirements since they are the ones who will be operating the software that is on the ISS. Software engineers then take the requirements and generate the code. The logic of the code is carefully reviewed with other programmers to ensure it does what is intended. During this phase, the flight control team works closely with the programmers to understand and influence the design. During the assembly of the ISS, the flight controllers were extremely involved in the development of the vehicle software. Once completed, the software undergoes various levels of testing to ensure that it correctly meets the requirements and interfaces with other software code properly. Testing culminates with a flight qualification test where the software is put through its paces under realistic situations. In a perfect world, a complete second space station would exist on the ground to run the software to ensure it works correctly however, such an approach is cost prohibitive. Instead, testing is done on a combination of flight-like items and simulation or emulations. A flight-like unit may be an exact copy of a unit flown on the space station, or it might be a flight equivalent unit—something very close to the real hardware but with cheaper parts that replicate the behavior of the real unit. A simulator or emulator is essentially a software program that will react the same as the real system. For example, software controls the pump speed in the Thermal Control System loop, perhaps increasing water flow if more cooling is needed (see Chapter 11). The simulation will reveal the temperature to the MDM. The MDM will send a command back to the simulation, telling it to increase the pump speed. The revised pump speed and the resulting cooler water temperature are echoed back to the MDM. In this way, the control software inside the MDM is executed