Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
5 Equipment Upgrades, Software, and Communications Although the ISS has changed character many times, it retains many of the features of its predecessors, Space Station Alpha and Space Station Freedom, and includes design ele- ments representative of 1970s and 1980s technology. By the time the ISS is operational in 2004, much of the technology and some of the hardware will be 20 to 30 years old. Consid- ering the rapid growth in technology, upgrades to the opera- tional ISS subsystems, hardware, and software could almost certainly increase the efficiency of the crews onboard and on the ground. The committee suggests that NASA establish a metric for determining the cost effectiveness of improvements. The metric could be included in evaluations, along with other factors, such as safety and reliability. The following is an example of a simplified formula for evaluating cost effec- tiveness: (tS sacs + tg *cg)/Bt, where tg and tS represent savings in ground and space crew hours, respectively, and cg and Cs represent the hourly cost of ground and space crews. Bt is the budget requirement for the improvement, adjusted for the time value of money for the interval between the investment and the midpoint of the expected savings. Improvements that have the highest value according to this metric should be considered first, and im- provements with lower values should be considered only if they are required for safety or some other overriding reason. This type of metric, or an equivalent cost-effectiveness criterion, should be applied wherever possible. COMMUNICATIONS Communications with the ISS will be provided via the tracking and data relay satellite system (TDRSS) constella- tion of communications satellites. As currently configured, this system will provide for 42 Mbps downlink and 48 KBS uplink for science communications, with an availability of 24 only 46-percent (i.e., the percentage of communication time, through TDRSS,when the e-band antennae are not being occluded by ISS structure) (Arena, 1998~. Availability is constrained, at present, by the location of the antennae and the configuration of the surrounding elements of the ISS. NASA is considering upgrading the TDRSS to increase up- link bandwidth and is considering placing the ISS antennae on a boom to increase ISS-TDRSS mutual antennae visibility time. An upgrade to increase the downlink bandwidth to 150 Mbps at UF-5 is already in progress (Hall, 1999~. When upgraded to 150 Mbps, the downlink bandwidth should be adequate for sending telemetry and experimental data, but the uplink capability could be severely constrained because the signal availability of only 46-percent will affect both the downlink and the uplink communications. Signifi- cantly greater uplink bandwidth, with near continuous avail- ability, will be necessary during the operational phase of the ISS program for the following reasons: If PIs control their experiments by teleoperation, they could attempt to control experiments while other com- munications are in progress, including ISS commands. Shared communications would be acceptable if band- width were adequate, but competing with other com- munications, under bandwidth constraint limitations, is not advisable. Mir experience with scientific experiments suggests that the ability to send drawings and pictures to the crew greatly increases their ability to respond to un- anticipated experimental conditions or to make repairs. The ability to send real-time or near real-time video can significantly improve crew training, refresher training, and real-time repairs of flight hardware and experiments. Recommendation. The National Aeronautics and Space Administration should make increasing the uplink bandwidth
EQUIPMENT UPGRADES, SOFTWARE, AND COMMUNICATIONS a high priority and should evaluate the importance of video communications. Recommendation. The International Space Station anten- nae should be relocated in a configuration that allows con- tinuous communication through the tracking and data relay satellite system. PAYLOAD COMPUTING SUPPORT The current approach to computer support for scientific experiments on the ISS is based on computing autonomy for each experiment (i.e., each experiment must provide its own unique computing capability). This arrangement is neither efficient nor sufficient. If each experiment provides its own dedicated computer, the variety in computing devices and software could significantly add to the complexity of the operation and increase the workload of the crew. For experiments that do not require extensive or dedi- cated computing, NASA proposes providing a laptop inter- face via a 1553 bus to the payload computing module. The laptop would be selected from the commercial technology available at the time and would use commercial software. Experimenters would be able to send along a disk with the programs to be loaded for their experiments. Any computers (including those labeled as timers, controllers, or "smart sensors") that are not fully space qualified could malfunc- tion due to space radiation thereby adding to the workload of the crew (Davidson, 1999~. All computers will have to conform to standard interface specifications (i.e., ISS NSTS 21000-IDD-ISS). Recommendation. The National Aeronautics and Space Administration should continue to refine the payload control/telemetry computing architecture in collaboration with the scientific community to ensure that the best tech- nology is used and that computing devices are fully space qualified so as not to increase the workload of the crew. HOUSEKEEPING COMPUTING-HARDWARE PLATFORMS The ISS hardware architecture consists of a collection of federated processing modules on a 1553 bus. Each process- ing module is dedicated to a specific function. Communica- tion between modules is managed through a synchronous message-passing protocol over the bus, which has been used extensively by the military and NASA avionics community (NASA CDH-TM Manual, 1999~. The major advantage of this architecture is that it simplifies software integration. (Davidson, 1999) U.S. Component The hardware for the U.S. component, inherited from the 25 Space Station Freedom program, uses the Intel 386 proces- sor. The processors and circuit cards used to create the mod- ules, which are at least a decade old, have enough power to perform the intended functions (and there is adequate reserve on the bus to add functions). Thus, they will not inherently add risk to the software. However, replacing hardware may be difficult. NASA has instituted a policy of buying processing modules to repair failed units by replacing cards. Also, fund- ing requirements for the Preplanned Product Improvement Program (P3I) to replace the processors with more current 32-bit processors have been defined. Although this change will increase cost and add some risk, it would greatly improve the maintainability of the hardware. Recommendation. The National Aeronautics and Space Administration should proceed with the Preplanned Product Improvement (P3I) upgrade of the processor, even though this will require some changes in the software and will require that a new code generator be developed for the compiler. Russian Component The hardware for the Russian component consists of Intel 386-based modules provided by NASA and 32-bit SPARC processors provided by the European Space Agency. There are no plans to upgrade this hardware (Clubb, 1999~. SOFTWARE The ISS housekeeping software architecture is dictated by the hardware architecture. As processing modules are dedicated to specific functions, the software is similarly allocated to the appropriate modules according to function. Software integration within a processing module is limited to the functions of that module, and software integration between modules is controlled by the synchronous message- passing protocol. The combination of functional decompo- sition and message-passing reduces, but does not eliminate, the complexity of integration (Panter, 1999~. U.S. Component NASA has significant experience with the federated architecture, and mature processes are in place to manage the development and evolution of the software. These pro- cesses include detailed specifications by domain experts implemented by software experts. In addition, NASA has a mature and capable independent verification and validation procedure in place. Software changes can be tested on the ground and uploaded via communication links without waiting for a Space Shuttle mission. In the current plans, no major changes are anticipated in the systems supported and managed by the software (Panter, 1999~. Software maintenance
26 ENGINEERING CHALLENGES TO THE LONG-TERM OPERATION OF THE INTERNATIONAL SPACE STATION would be limited to fixing bugs and repairing or replacing failed or degraded system components. Software testing for the ISS is necessarily dependent on simulations of the systems, such as a propulsion system to boost the station into higher orbit and computer hardware to test software integration. Although NASA has considerable experience with this approach, it carries significant risks. The committee recognizes that no alternative is available to the use of systems simulations, but reliance on hardware module simulations could be reduced by building a more complete ground system facility. The decision must be based on a present cost/future cost trade-off and safety assessment. The committee is concerned that software development is currently behind schedule (Panter, 1999~. Some of the schedule slippage can be attributed to the same system change flow-down that plagues most complex software. An initial build has been completed for all software to support the ISS through Flight 7A and software maintenance after Assembly Complete appears to be manageable. Although P3I funding requirements have been defined for upgrading the Ada Compiler to full compliance with language features in fiscal year 2000, P3I funds have not yet been allocated for the development of a code generator and run-time operating system for the 32-bit replacement pro- cessor and subsequent software modifications. Although a strongly typed high-level language such as Ada will reduce the effect of conversion from a 16-bit processor to a 32-bit processor, the change will undoubtedly have some impact on cost and schedule. Recommendation. The National Aeronautics and Space Administration should review its Preplanned Product Improvement (P3I) plans to ensure that funds will be avail- able for the development of a code generator and run-time operating system for the new processor and for subsequent software changes. Russian Component The Russian software is being developed under condi- tions drastically different from U.S. software development (Clubb, 1999~. The Russians are using two different types of processors and two different run-time systems, one based on the European Space Agency's operating system devel- oped in Ada language for the SPARC processor using the C language for applications, the other based on the Ada language run-time for the 386-based processing modules. Domain experts, who usually operate with much looser specifications, are writing the code. Domain experts also typically build more complex, less structured software with embedded assumptions that complicate changes. Although the Russians have very capable programmers, they are not experienced with large complex systems, the languages and compilers being used, and high-level integra- tion with U.S. software for important functions, such as guidance and navigation, commanding, telemetry, and support of ISS modes after Flight 5A. In the later stages of assembly and after Assembly Complete, maintenance of the Russian software could pose significant risks, which could be complicated by the dynam- ics of the Russian economy. If the commercial software industry continues to develop rapidly in Russia, the people who write the code may move on to other jobs and may not be available to maintain ISS software. Recommendation. The National Aeronautics and Space Administration should develop a risk mitigation strategy for the maintenance of Russian-developed software. TELECOMMUNICATIONS SECURITY The safety of the ISS and its crew and the success of the experiments will depend, in part, on secure communications. Software upgrades must be uploaded, and commands issued to control a variety of station-keeping activities. The tele- communications system for the ISS is necessarily complex because of the number of international participants who will have to communicate with their respective segments. The system is further complicated by the possibility that some in the scientific community may manage their experiments through teleoperations and by the needs of some research organizations and commercial enterprises to protect propri- etary information. The safety of the ISS and crew, and the integrity of the experiments, will require a sophisticated security scheme to protect communications and information systems. Security is especially important in the current environment in which networks and systems are under constant attack by amateur and professional intruders. The ISS will be a highly visible target for people who would consider "cracking" its security wall the ultimate challenge. NASA has a well conceived security architecture based on experience with previous systems, and the agency under- goes an independent security evaluation every year. The security architecture has multiple levels of protection, including encryption. The initial encryption is based on the DES algorithm, which is known to have been broken. The P3I plan is to upgrade the algorithm to the triple-DES algo- rithm, which is a more robust 128-bit system. Although that would be a significant improvement, recent developments suggest that even greater security (i.e., 256-bit or greater) encryption will be necessary. Despite NASA's careful attention to security, other potential vulnerabilities must still be remedied. Recommendation. The National Aeronautics and Space Administration should accelerate the upgrading of the encryption to triple-DES, continue to plan aggressively for fur- ther upgrades as the technology develops, and should perform a thorough analysis of the system to identify vulnerabilities.
EQUIPMENT UPGRADES, SOFTWARE, AND COMMUNICATIONS SUMMARY Despite conscientious planning by the ISS Program Office and the Engineering Directorate at the NASA Johnson Space Center to identify systems and procedures that need upgrading to support NASA's vision of a world-class research facility on orbit, many upgrades and improvements are being deferred. The committee believes that the funda- mental improvements cited in this report can and should be introduced into the ISS as soon as possible and that special management oversight is warranted in the following critical areas: the P3I program to ensure that P3I continues to be a responsible advocate for important ISS upgrades and that it is adequately funded changes to ISS provisioning and planning techniques to ensure that proper consideration is given to program parameters that affect the acquisition of spare parts and logistics planning for the ISS operational phase the implementation of communications system up- grades to improve critical uplink communications for the mutual benefit of crew members, PIs, and inter- national partners · the continued development of capable robotic aids, especially systems that will facilitate EVAs and make certain EVA tasks easier, or even unnecessary the reassessment of traditional detailed mission plan- ning and control procedures with the goal of sig- nificantly reducing the numbers of ground controllers supporting the long-term operations by allowing long- term crew members aboard the ISS, who have unique experience with the ISS equipment and the scientific experiments, to participate in planning day-to-day activities the reassessment of traditional mission control proce- dures and staffing to take advantage of improved com- munications technologies that will enable access to key . . 27 personnel from remote locations, thereby reducing the requirement that a large contingent of mission control personnel be continually on site in the mission control center. Recommendation. The National Aeronautics and Space Administration should designate a senior member of the International Space Station (ISS) staff to assemble, review, and approve budgets and implementation plans for post Assembly Complete, to facilitate improvements in ISS systems, and ISS operations, and to maintain a high degree of management visibility for this important activity. REFERENCES Arend, J. 1998. ISS Post-Assembly Traffic Planning and On-Orbit Resource Assessments. Presentation by J. Arend, Mission Integration Office, International Space Station, to the Committee on the Engineering Chal- lenges to the Long-Term Operation of the International Space Station, NASA Johnson Space Center, Houston, Texas, December 17, 1998. Clubb, J. 1999. Russian Software. Presentation by J. Clubb, Avionics Integration Office, International Space Station Program to L. Druffel, member of the Committee on the Engineering Challenges to the Long- Term Operation of the International Space Station, NASA Johnson Space Center, Houston, Texas, March 25, 1999. Davidson, C., 1999. Support of Science With Computers. Presentation by C. Davidson, Vehicle Office, International Space Station Program, to L. Druffel, member of the Committee on the Engineering Challenges to the Long-Term Operation of the International Space Station, NASA Johnson Space Center, Houston, Texas, March 26, 1999. Hall, V. 1999. Communications. Presentation by V. Hall, Space Operations Management Office, to the Committee on the Engineering Challenges to the Long-Term Operation of the International Space Station, NASA Johnson Space Center, Houston, Texas, March 24, 1999. NASA CDH-TM Manual. 1999. ISS Command and Data Handling Train- ing Manual. CDH-TM-21109. February, 1999. Houston, Texas: National Aeronautics and Space Administration, Johnson Space Center. Panter, B., 1999. ISS Software. Presentation by B. Panter, Manager, Avionics Integration Office, International Space Station Program, to the Committee on the Engineering Challenges to the Long-Term Operation of the International Space Station, NASA Johnson Space Center, Houston, Texas, March 25, 1999.
