113 DAY IN THE LIFE: “BRAIN TRANSPLANTS” ON THE INTERNATIONAL SPACE STATION CHAPTER 6 “rollback” to the old configuration if a problem is encountered. Generally, the C&C MDMs are swapped to invoke the new software. The crew connects the upgraded PCS laptops that are loaded with that software. The ground evaluates data to ensure everything is operating properly. If all is as it should be, the next pair of MDMs is swapped— usually the Internal MDM, followed by other pairs. The computers with the old software are not immediately reloaded. An extensive amount of testing is performed before the computers on orbit are reloaded however, there is always a chance that something is missed within the simulated environment, which is not 100% identical to the real vehicle. Therefore, the operations team typically waits about day to make sure everything is working properly. If everything works, the computers with the remaining old software are reloaded and that portion of the transition is completed. If not, the old software can be rolled back quickly by swapping it with the computer that is still running the old software. The team then determines the best configuration for the software until the issue can be resolved. The real- time timeline for the R14 load is shown in Figure 1. Load R14 into Backup & Standby C&C MDMs Load, transition LAB-3 MDM to R6, Node 2-2 MDM to R4 Load, transition S3-1, S3-2, P3-1, P3-2 MDMs to R5 Transition Backup C&C MDM to Primary Load R17 into half of PCSs Transition Standby C&C MDM to R14 Load, transition Prime & Backup HCZ to R4 • Connect PCS • Standby C&C MDM still R13 Day 1 Day 2 Day 3 Day 4 Day 5 Figure 1. Graphic illustrates the day-by-day process over 5 days of loading all the computers for the R14, as defined in Table 1. Each block represents a set of activities performed on a given day. Each step-up is done in small steps to allow for time to assess how the software is working. If everything was transitioned at once, it might be hard to identify a problem. Flight controllers, under the direction of the flight director and working with the engineers, figure out the transition plan, which is then reviewed by the engineering team. For example, do the systems need to be put in a certain configuration prior to the transition? Which operations must be stopped during the transition and which can safely continue? Once the plan is worked out, the procedures are written, including some for likely contingency scenarios. At that point, the procedures are operationally tested. In these tests, the flight control team in Mission Control executes the procedures with the ISS Software Development and Integration Laboratory in what are called flight-like operations readiness tests. These tests include configuring the simulated systems into a known ISS-like state for the actual swap, sending all the new code to the computers, executing the switchover, and reconfiguring all equipment back to the normal operating setup. Multiple tests are performed to ensure everything is properly evaluated. Once any issues are worked out, a test that uses a flight-like mission configuration is performed. Note that this describes only the process to develop the transition procedure. New software means new operations of generic procedures, and possibly new flight rules. Therefore, the transition team will also lead the development of all the procedure updates—typically on the order of 150 updates. Each procedure has to be revised and tested in an operations readiness test. The flight director oversees the flight rule modifications. Planning the Transition Once the uplink procedure has been developed and tested, it is ready for the transition. The increment team tries to find a time to perform the upgrade (see Chapter 1) while the testing is taking place. In an ideal world, the software is ready at a given time and the team performs the uplink. In the dynamic world of the ISS, this is rarely the case. For example, visiting vehicle software needs to be tested with the version of the ISS software that will be