CHAPTER 6 DAY IN THE LIFE: “BRAIN TRANSPLANTS” ON THE INTERNATIONAL SPACE STATION 116 is currently operating. After the software has been loaded, the team archives any products associated with the previous version of software and performs a lessons-learned review to identify any improvements to the process for the next transition. Lessons Learned Over the years of operating the ISS, many of the lessons learned have helped craft more-efficient software transitions and corrected items that caused issues in earlier transitions. An early example of this came during the first major CCS transition. The operations team is responsible for developing certain configuration files for the MDMs. In this case, NASA developed a Load Shed Table—i.e., a list of commands used to deactivate electrical loads in off-nominal situations for CCS R1. When the planning process started for CCS R2, it was determined that the commands listed in the Load Shed Table did not need to be updated at that time. A default Load Shed Table built by software developers was used during CCS R2 testing. The operations team commanded the incorporation of its CCS R1 Load Shed Table after the real-time transition to CCS R2. When this happened, the primary C&C MDM failed. When the backup C&C MDM took over, ground software automatically attempted to complete the load of the Load Shed Table, which caused that C&C MDM to fail. Luckily, the third C&C MDM was not configured for Tracking and Data Relay Satellite communications. When the third C&C MDM took over, the ISS did not have communications with the ground. This allowed the operations team to abort the attempted Load Shed Table uplink. Upon investigation of the issue, NASA determined that the updated CCS software had been recompiled, which had caused the memory address for the Load Shed Table data to change. The Load Shed Table overwrote critical software when the CCS R1 Load Shed Table was loaded to a C&C MDM that was running R2, thereby causing the MDM to fail. Although the intended content and function of the Load Shed Table did not need to be changed, the actual file needed to be updated to match the recompiled software. Multiple actions were taken to update the transition process as a result of this incident. First, the transition test procedures were updated to assure that the flight versions of all files were tested. Second, the ground commanding software was updated to abort any attempt to load a file if a C&C MDM transition occurred, thus preventing a bad uplink from taking down multiple MDMs. Third, the Load Shed Table (and similar files) are now being rebuilt for each software load, even if the intended function does not change. As occurs with visiting vehicle operations, spacewalks, and other dynamic events, the combined operations, engineering, and management teams apply lessons learned from software transitions to future plans. This improves the overall process of upgrading ISS software, which keeps the crew and vehicle safe and ultimately increases scientific output. Conclusion Despite the complexity of the space station, some aspects of its operations are familiar to the average person on Earth, especially when it comes to the need to periodically upgrade software. Due to the scale and critical nature of the software on the ISS, however, the planning and testing process takes about a year. As with any other system, the flight control team needs to adapt and respond to unexpected surprises that can occur, even within a well-orchestrated process.