Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 31
4 Issues Related to Systems Requirements and Design The committee devoted considerable time during the workshop to the identification of issues pertaining to the major systems of the Space Station. Those issues are discussed in this chapter. As was noted earlier, this is not an exhaustive set of issues; the time available did not permit that level of review. Furthermore, the presence of expressions of approval for particular system and subsystem design decisions and their absence for others should not be taken as overall evaluations of a subsystem's acceptability in the eyes of the committee. In the course of its review of subsystem requirements and design approaches, the committee identified a number of issues related to the interactions and interdependencies of Space Station subsystems. It believes that more attention needs to be given to such overall Architectural considerations. The committee's concerns are summarized below, followed by a discussion of specific subsystem issues. SYSTEMS ARCHITECTURAL CONCERNS Systems Reouirements Requirements for systems and subsystems should be traceable to their source. In this phase of the Space Station Freedom design process, many things are changing, and there will likely be experiments or operations in the future that are not well defined at present. Therefore, some requirements will be based on well-understood needs and others will be present to insure flexibility for the future. Nonetheless, there should be a clear basis for why size, weight, power, or other design requirements have been specified and an understanding of how 31
OCR for page 32
32 systems might be simplified, reduced in size, or changed in a favorable way if other systems or experiments change. The committee did not find as ready an awareness of these considerations as it believes is desirable at this stage in the Space Station development program. Systems Interactions As an example of the interactions encountered at the system level, consider the controls, structural dynamics, and propulsion systems. These systems have each been successfully planned to meet the initial design requirements. The next step should be to see in what ways the experience obtained in the design process can be used to improve the engineering of each system to simplify the designs or help in overcoming any problems that remain. Attitude control and structural dynamics always interact. In the Space Station, there will be disturbances, the response to which will be influenced by structural dynamics. For example, astronauts will be exercising and moving around in the Space Station; the Stationts response to their movements will be amplified by the structural resonances, thus causing disturbances to the microgravity experiments that may be two orders of magnitude above the desirable level of 10-6 g. The baseline design control bandwidths are quite low--about a factor of 10 lower than the lowest structural mode frequency of 0.2 Hz. This permits relatively simple control laws. Structural damping is expected to be sufficient to give the significant modes a damping ratio of 0.5 percent. This ratio is said to be adequate to insure control behavior that meets the requirements. However, increased damping would permit further simplification and accommodate future configuration changes without requiring major control system changes. Increased damping also would reduce the response in the microgravity laboratory areas to astronauts" movements. Thus, structural changes should be considered an available design option to further simplify control of the Station and to partially attenuate the effect of a disturbance. The resolution of the astronaut exercise problem will probably require other measures as well, such as isolation of the exercise equipment, changes in the orientation or position of the exercises, possibly a modification of the type of exercise or how it is performed, and an increase in the allowable
OCR for page 33
33 microgravity levels in the laboratory, but structural damping will improve the situation and is an important part of the overall solution. The difficulty the committee has observed is that parameters such as damping and stiffness appear to have been taken as fixed, with control techniques then developed that would be acceptable under the specified conditions. Alternatively, one could have a range of control capabilities being used to specify structural parameters. Damping, stiffness, and mode slopes at the location of the integrated sensors and control moment gyros are examples of parameters that could be specified as goals that would let the design of the structure simplify or improve the total control/structural resonance/vibration excitation picture. It appears currently that each system and subsystem designer is simply accepting a model and proving it can meet requirements. The committee believes that better communication between designers with a common goal of improving the overall system would! produce a better design. They should be required to find parameters such as damping that have beneficial effects on several other systems and to learn quantitatively what the cost would be across systems of achieving improvements. In the present technical management environment there does not seem to be any way of getting a system designer (e.g., for structures) to make a change unless a requirement is not met. There are precedents for such an approach. One European contractor has intentionally introduced damping in the joints of a spacecraft structure to provide such conservative design margins that a costly structural analysis is not needed each time there is a configuration change. Proposals have been made to include clamping in each strut used in the Space Station, but since these proposals apparently have not been funded, their cost in weight, volume, and dollars is not known. By analogy, the committee believes that other parameters that affect several systems should also be evaluated. Allocation of Systems Reguirement ImDacts The workshop committee is concerned that the impacts of specific system requirements have not been clearly allocated. For example, sizing of control and propulsion components was not always traceable. It would be helpful to know what disturbances or maneuvers have determined the control authority. In some cases a single experiment may have been the
OCR for page 34
34 determinant, and in others the need to assure flexibility. In each case, an experiment or a general requirement should be ~charged" in the overall design process with the escalation in size, weight or power, and so on, it requires. For example, waste disposal of a noxious gas requires storage, with the gas then used as a propellant for a resistojet. Continuous release of waste gas would be possible except for the requirements of some experiments with special viewing needs. These experiments need to be charged for the extra mass, complexity, and increased risk associated with having to store the noxious gas. Modeling The Space Station will be larger and of a different technology than previous spacecraft. Initial mathematical models are not likely to be accurate representations of the Space Station'sbynamic structural behavior. Each stage of construction should be used to learn how to better model the behavior. More than a dozen successive spacecraft (protostation elements)--each an extension of the previous one--will be instrumented to provide help in understanding the nonlinearities and damping (typically not well modeled) as well as mode shapes and frequencies. Assumed Space Station damping is 0.5 percent, for example, whereas some estimates of what may be found have been as low as 0.003 percent. All modes are assumed to have the same damping, although this is never true. This characterization is important for robust control (i.e., providing a control system that will work based on a design model different from the behavior of the actual vehicle) of an evolving spacecraft during construction, when the configuration changes with the arrival of a transport vehicle (initially the Shuttle), and when an experimental payload or module is added or deleted. Controls and structures engineers plan to utilize the data from the interim spacecraft and are developing analytical tools to assist in the data reduction. For the data to be useful, the allowable turnaround time must be very short. The committee believes that special attention should be paid in the development schedule to optimizing the use of each spacecraft so that data can be applied to the next launch package.
OCR for page 35
35 Growth Flexibility Future configurations are being considered for the Space Station. Accommodations for future growth are included in the design. However, the evaluation of system and subsystem changes required to accommodate this growth does not appear to have proceeded apace. Each future configuration need not have detailed system and subsystem designs, but the committee recommends that flexibility for future modification and growth be given adequate weight in the design process. SPECIFIC SYSTEMS ISSUES The following sections identify issues and concerns raised by the committee with respect to specific Space Station systems. Software and Data Management Overview The Space Station software and data management systems are highly complex. This complexity appears to be necessary to meet the many requirements placed on the Station. These requirements in turn dictate that the Space Station will have many systems and subsystems, with many interactions between them (ranging from preventing any interactions between specific systems to allowing high-bandwidth access). The on-board software will constitute the largest on-board space software and data processing system ever developed. Likewise, the ground systems will be among the most complex ever designed and developed. Major software risk factors include the following: · The scope of the software is unprecedented (at least at NASA), and no prototypes exist. · A new software architecture is being proposed for flight software. · A "waterfall" methodology has been inherited (i.e., first write volumes of requirements, then implement, then integrate, test, etc.) but not evaluated. · The requirements will not be clear until much later in the Space Station's development.
OCR for page 36
36 · The flight software, for example, is quite large (about 800,000 lines of code). · The software is being developed by multiple (approximately ten) noncollocated contractors. · The schedule calls for rapid development. · No risk management plan exists. · The software is of a high level of criticality. In general, NASA is to be commended for recognizing the criticality of software and data management to the Space Station program, and for taking a proactive approach to addressing software-related issues. Some particularly good examples of this proactive approach include the following: · The investment in a program-wide Software Support Environment (SSE) and a Technical and Management Information System (TMIS). The proactive stimulation of SSE user groups, Data Management System (DMS) working groups, and early software requirements analysis. · The open system architecture for the DMS, and the early definition of key standard DMS elements (Ada, Intel 80386 instruction set architecture, ISO/OSI network protocols). · The definition and development of the Multi-System Integration Facility and the Data -Management System Kits to aid in hardware-software integration and verification. Nonetheless, the committee is concerned about a number of aspects of the Space Station software and data management capabilities. Successful software development is characterized by well-understood, well-defined, and stable software requirements; elimination of high-risk software items; precisely defined interfaces between the software components; and a mature, in-place SSE. As mentioned above, NASA is cognizant of these conditions, and has initiated a number of commendable efforts to achieve them. However, the current process model, early schedule, and available resources early in the development activity are not well matched to the challenge. The most significant software and data management issues and concerns identified by the committee during the workshop are discussed below.
OCR for page 37
37 Software Risk Management The most effective technique for achieving the above conditions is development of a software risk management plan, which identifies the key software risk items and establishes the necessary schedules and resources for resolving the risk items by the software Preliminary Design Review. Aspects of Space Station software likely to have risk associated with them include the following: · Real-time performance, particularly in crisis mode when there are more active users, more transactions per user, and more complex transactions. · Distributed operating system and Data Management System development, particularly in the areas of reliability and fault tolerance, efficiency, deadlock avoidance, and database integrity (e.g., design of database locking mechanisms). · Information security and privacy assurance. · Use of Ada features. The committee believes Ada is the right language to use for programming, with the caveat that Ada not be mandated for possibly inappropriate parts of the life cycle, such as requirements, specifications, and prototyping. There are particular potential risk items to address, including use of tasking in distributed, performance-critical, secure processing; use of exceptions and elaboration in reliability/ availability-critical situations; adequacy of compilers and run-time support capabilities for very large software programs. Selective nonuse of Ada in some special programming situations (e.g., artificial intelligence) should be considered. O User interfaces. Besicles user-friendliness and user interface consistency across applications, this also includes hardware/software systems engineering to avoid equipment overkill (e.g., CRTs that soak up large quantities of scarce electrical power). Software development schedules. A particularly effective risk resolution capability for software design uncertainties is rapid prototyping. Early use of rapid prototyping in such areas as user interface systems, distributed processing, and critical algorithms should be much more strongly emphasized.
OCR for page 38
38 Software Development Schedules and Uncertainties in Application Software Requirements The review of most of the Space Station systems (communications and tracking, fluid management, thermal control, electrical power, life support, crew operations) indicates that major uncertainties will exist for quite some time in the operational requirements that the software is intended to support. In such a situation, an early target for baselined software requirements is unrealistic. A preferable approach is to have the software organizations prepare draft designs and prototypes of the critical software applications support capabilities, and iterate these with the applications designers in order to converge on a set of realistic and well-matched software requirements somewhat later in the development cycle. This approach would also provide more time for SSE- and TMIS-support capabilities to mature, as discussed next. In general, the current software schedule emphasizes early completion of software requirements documents, which then become baselined and more difficult to modify. The early schedule preferably should emphasize execution of risk management plans and resolution of risk items before software requirements are "cast in concrete. Finally, it appears that the first item in the critical path for the software is the DMS. As discussed earlier, it is necessary to begin the prototyping process for Space Station software as soon as possible, in order to allow convergence of design, to satisfy safety and supportability needs, and to keep costs in line. Two concerns arise. First, a decision on the DMS operating system might not be made until the third quarter of 1989, which would be a serious problem since it potentially delays by one year many of the software prototyping efforts. Second, criteria for making the decision were not evident to the committee from discussions with the NASA briefers. The committee believes that the major criteria should include early and wide availability to software developers (including experiment developers). This availability would allow all developers to begin as soon as possible, reduce training costs, increase the likelihood of reliability, and so forth. An effort should be made to establish the operating system, or at least the baseline from which it will evolve, as soon as possible so that prototyping can begin.
OCR for page 39
39 Software Support Environment Given that the SSE is on the critical path of all software development, it is particularly important to avoid risks of SSE functionality, schedule, performance, and robustness problems. Among the key candidate risk items that need to be defined and monitored in an SSE risk management plan are the following: ~ Performance scaling of the SSE to support the development of very large software complexes. · Consistency of separately developed rules and tools (e.g., object-oriented and Yourdon-De Marco approaches). · Provision of tools to support design, development, and testing of distributed Ada software. · Structure and performance of the project data base and data base manager. · Configuration management and version management models and support. · Prioritization of incremental capabilities to project needs. · SSE proliferation control. · Consistent user interface across dissimilar workstations. Even if the SSE is fully successful, that should not be taken to mean that the Space Station software problems are thereby solved. Other software risk items such as requirements definition and stability, design insight, and software management effectiveness are orthogonal to the SSE's contributions. The committee would also point out that allocation of adequate early resources is critical to ensuring that the SSE and the TMIS are capable of supporting the early software development phases' thus ensuring the commitment of software projects to full and effective use of SSE and TMIS. Particular needs are Ada-compatible requirements and design aids and applications-level TMIS data definitions. Software Design for Supportability It does not appear that supportability is being adequately emphasized in the Space Station software design approach (e.g., having software requirements documents include a section on primary sources of requirements growth and change). Given the
OCR for page 40
40 dominance of software support costs over development costs, techniques for enhanced supportability should be emphasized. An example of one of the most effective techniques is Parnas's "information hiding. technique, which involves identifying in advance the primary sources of change in the software requirements, and encapsulating or hiding these sources of change (e.g., changes in display devices) within single software modules (e.g., display driver module). Software Integration and Verification The committee believes that the emphasis on commonality for the Space Station is good, but that it will create additional complications and schedule pressures during integration and validation (for both software and hardware). Specifically, any time a fault or inadequacy is identified in a common component, it will need to be traced back to all systems using the component; any changes made to the component must then be fully coordinated with all of the systems using it and the appropriate regression tests established and executed. This could become a cumbersome, time-consuming, and error-prone morass without appropriate change management channels and effective information system support. The change management information support capability needs to address issues involving support of common components. Similarly, resolving concerns on export control of U.S. software capabilities (e.g., SSE) and international noncommonatities (e.g., European Space Agency's separate Software Development Environment) could consume an inordinate amount of management and calendar time. It may be better to press for a conservative but early and definitive set of international software working arrangements--perhaps use of separate SSEs--that would support a common set of requirements and design specification languages, programming standards, problem report formats, ant! reusable software component descriptors. Finally, current Space Station software integration plans emphasize postcoding activities. The Ada programming language enables software developers to begin integration during the design phase, by thoroughly defining Ada package specifications and verifying their consistency with other Ada package specifications via the Ada compiler. This capability can be a major source of improvement in software productivity and quality, and should be emphasized in Space Station software plans.
OCR for page 41
41 Space Station Information System Services In the committee's opinion, the coordination of the Space Station Information System (SSIS) with the other data distribution systems proposed by the NASA user organizations (i.e., by the Office of Space Operations and the Office of Space Science and Applications) does not appear to be very well defined. The SSIS will take Space Station data and transmit it to the ground. From there it would be up to the user to distribute the data and/or archive it. The Office of Space Science and Applications has plans to provide a Space Applications Information System, and the Office of Space Operations has plans for a Customer Data Operations System. The plans for these systems are still being discussed. In order for a data distribution system to be truly user friendly, it must serve its users. For example, it must make the data available to the users at their home laboratory. Current public networks work mostly on packetized data transmission. This does not always produce the most rapid routing or time-synchronized data. It will be especially important during the conduct of an experiment to have both timely data and command relays (within a time frame of seconds) as well as time-synchronized data. Although technically not an Office of Space Station responsibility, the implications of not coordinating the different data distribution systems are great. The committee also is concerned about how the Customer Data Operations and Space Applications Information Systems will interact, either with each other or with the SSIS. It will be very important to insure that users are supported at their home institutions. For example, video data will be downlinked in digital format and apparently restored to an analog signal on the ground. It is not clear how those data will either be sent to users or be recorrelated with other digital data. The additional complexities of having a single clearinghouse for commands, command checking, or transaction management underscore the need for continued emphasis on coordination in this area.
OCR for page 42
42 Communications and Tracking End-to-End Considerations The following comments are directed at steps that need to be taken in the near future in the area of communications and tracking, as opposed to being a criticism of past steps that have or have not been taken. The early state of development of the Space Station makes it inevitable that gaps exist, but it would be of concern if the principal ones were not closed soon. In communications and tracking, no end-to-end perspective was evident or presented to the committee. No analyses of end-to-end paths, link capacities, availability, blocking, queuing delays, and reliability were presented or referenced. The complexity of the Space Station program requires continuing analyses of all links from their origin to their final destination, inclucling command and control as well as experimenter data links. For example, signals should be traced from the source through the Space Station's internal processing steps and channels, Tracking and Data Relay Satellite System (TDRSS) space segment, and the TDRSS ground segment to the final data destination (whether a NASA Center, an investigator, or some other domestic or foreign site). Furthermore, the committee recommends that the Design Reference Missions should be used to test the complete communications and data system concepts to ensure end-to-end compatibility and performance. The full utility of the Space Station can obviously be gained only through the establishment of an environment rich in communications and computational capabilities for crew, operators, and investigators. Another issue of concern to the committee is that all communications to and from the Space Station will flow via the TDRSS. While it is expected that the system will be fully operational in the Space Station era, there is a lingering concern that an alternative data path to and from the ground should be provided. At a minimum, this path should permit voice transmission and computer up- and down-Ioads under all circumstances. Many communications facilities around the world could be used in an emergency. They operate at UHF, S-, and X-band frequencies and can readily respond to the narrowband communications requirements mentioned above. The Space Station international partners would be obvious allies in such a venture, as would the foreign Landsat ground stations, which
OCR for page 43
43 have long had ties to the United States. U.S. military stations could be used as well. The committee believes that robust system operations require that interoperability of U.S. and foreign space and ground segments must be assured in both primary and backup modes. With respect to radio frequency compatibility, the Space Station is almost entirely dependent on the TDRSS. Many ground stations are available that could provide emergency backup communications directly to and from the Space Station. However, the planned foreign data relay satellites, which have not yet been manufactured, are already planned to be incompatible with the U.S. system. Assuring compatibility would be the most economic means to backup the TDRSS, enhance the total transmission capability, more efficiently deliver data to foreign partners, and close the zone of exclusion. A radio frequency compatibility plan should be developed with each of the foreign partners. The plan should include current elements, as well as proposed elements such as the European and Japanese data-relay satellites. Furthermore, in the conduct of experiments on the Station, it is important to retain the option to transmit uncompressed, full-motion video signals to the ground. The currently proposed field/frame deletion compression technique is an unrecoverable approach suitable for broadcast television' but not for scientific research. Rather than requiring the users to supply their own digitization equipment to circumvent this difficulty, the Space Station equipment should provide either option. Electromagnetic Interference The Space Station obviously is dependent on many communication links for its successful operation; it is equally obvious that the vulnerability of these links to deliberate or inadvertent interference or access will be a continuing concern. Similarly, the various connected components of the Space Station contain many potential sources of interference that must be shielded from one another. Many of the communication links on which the Station will depend operate at Ku-band frequencies.. These frequencies are also used by terrestrial networks, telecommunication satellites, and high-power direct broadcast satellites. Further, it is projected that hundreds of thousands of very small aperture terminals (VSATs) will be deployed for business
OCR for page 44
44 communications. All of these sources raise potential interference issues. It should be noted that the Stationts use of these frequencies is on a secondary, as opposed to a primary, basis. History shows that many unexpected electromagnetic interference problems are first encountered when a new spacecraft is assembled. Eliminating these problems is often a tedious and difficult task, even when it is done on the ground with the benefits of considerable assistance by technical staff and sophisticated test equipment. However, the manned base cannot be tested as a complete assembly until it is in orbit. The relative inaccessibility of the Station and the relatively meager resources that will be available to the crew heighten the need for special attention to this potential problem. One of the more troublesome forms of electromagnetic interference is the generation of passive intermodulation products. While this traditionally is an antenna design problem when the transmitter and receiver share the same aperture, it can also occur when there are nearby elements beyond the antenna that are illuminated by high-power sidelobes. The extended nature of the Space Station and the more than hemispheric coverage of its Ku-band antennas raise the possibility of this problem. Again, because full-scale tests cannot be done prior to on-orbit assembly, this problem must be avoided through simulation, partial testing, and planning. The committee believes that a number of things should be done to address the above-mentioned issues. One of the highest priorities is a theoretical--and, where sensible, experimental--examination of the vulnerability of all communication links to interference from space or terrestrial sources, including the possibility of intentional interference or unauthorized access. In addition, a similar examination is needed of the element-level (module, node, etc.) electromagnetic interference and of the element-to-element levels. It is important that a test and verification plan be developed to assure that the electromagnetic interference environment of the Station will remain satisfactory as it is assembled on orbit. Finally, a design and operations plan should be developed to assure that high-power transmissions (including antenna sidelobes) do not impinge on surfaces that may radiate passive intermodulation products back into the receiver.
OCR for page 45
45 Automation _ Robot The committee believes that the current Space Station approach to automation and robotics is commendable in its proactive approach to identification, exploration, and application of advanced automation technology capabilities to improve Space Station and crew effectiveness. Some good candidates for exploration and application have been identified in NASA's Space Station Advanced Automation Study Final Report, May 1988. The committee has, however, identified some issues and concerns, which are discussed in the following paragraphs. Premature Flight Telerobotic Servicer Launch As was discussed earlier, the rush to launch a demonstra- tion flight of the FTS concept and then to place it in service very early in the Space Station assembly process likely will have just the contrary effect to achieving the advancement in the state of automation and robotics desired by the users. Moreover, there is no clear vision of the spectrum of applications to be supported by the FTS, particularly given the existence of the Canadian Mobile Servicing System. Early establishment of the FTS product focus is essential to effective FrS design and development. Solution-Driven Versus Problem-Driven Approaches to Automation Initiatives While the improvement of Space Station and crew efficiency and productivity was given as the rationale for exploring advanced automation opportunities, a NASA briefer indicated to the workshop committee that "finding effective applications for artificial intelligence (AI) technology was a higher priority than~improving efficiency ant! productivity. However, most successful AI applications to date have used AI techniques as parts of an automation solution, rather than as ends in themselves. The Space Station program should press forward strongly with its advanced automation initiative and foster a synergy with the NASA Office of Aeronautics and Space Technology automation technology efforts, but with a more problem-c~riven approach. Some important criteria for early AI applications to the Space Station are that they be low cost and low risk with high payoffs. Some attractive candidate areas in
OCR for page 46
46 this regard are safety monitoring, housekeeping reduction, and testing. Advanced Automation Targets and Products The current focus of the advanced automation initiative is on providing tools and capabilities for improving crew efficiency and productivity in handling Space Station system operations. However, Space Station program functional breakouts of crew time indicated that three times as much crew time will be spent on user operations as on system operations. From a productivity-leverage standpoint, more emphasis should be directed toward advanced automation tools and capabilities to improve efficiency of user operations, and toward training designers of Space Station user applications and experiments in the use of such tools and capabilities to make their applications more crew efficient. Advanced Automation and Robotics Plan The Office of Space Station presented to the committee a modest plan for advanced automation and robotics, but the committeets major concern with that plan is that the total effort appears too small to address the magnitude of problems that the Space Station will likely encounter. In advanced software technology, very little effort appears to be directed toward advanced automation assistance in the software life cycle. Other Space Station programs appear not to provide much help, since SSE primarily addresses acquisition of conventional software engineering technology. Similarly, SSIS, DMS, TMIS, and the Operations Management System are directed toward the short term. Particular issues that should be addressed include development of advanced tools for management of the software process, focussed especially on the problem of software interaction control, design capture, prototyping, risk assessment, and testing. In other areas such as prototyping, the technology-base support is developing in the Department of Defense, but adequate technology acquisition appears lacking in the Space Station automation and robotics effort. Finally, a related organizational issue is that the focal point of responsibility for advanced software technology development and acquisition in the Space Station program was not clear to the committee.
OCR for page 47
47 Electrical Power System The design approach of the electrical power system briefed to the committee calls for the conversion of the DC output from the photovoltaic panels to 20-kHz power. The 20-kHz electrical power would feed battery chargers for storage and go directly to loads through a variety of converters depending on the load. The electronic controls would consume about 15 percent of the electricity' with battery efficiency being about 85 percent. As designed, the system would be approximately 70 percent efficient from photovoltaic-generated DC power to load. The Japanese and European programs have strongly suggested a 120-V DC power system. NASA's analysis of the All DC" system, including DC isolation, shows losses equivalent to the 20-kHz design. There are international political concerns involved in this issue that are independent of the engineering issues. A useful objective might be to center on the power efficiency issue and work with the international engineers to gain consensus on a power control strategy that reduces power loss gp~ fills the users' needs. The objective should be to reduce power control losses to 5 percent. This 10 percent gain would increase the average effective power of the system from 75 kW to 85 kW. [A decision was made subsequent to the time of the workshop to convert to 20 kHz and then reconvert to 120 V DC at each of the three laboratory modules. The Space Station Program Office feels that the associated efficiency losses are acceptable in the interests of fostering science compatibility across modules. The committee has not had an opportunity to meet again to assess the merits of the decision.] The committee understands that the electrical power and thermal control systems are being developed by at least two NASA sites. A total Space Station cross-cutting analysis of all power requirements (electrical and thermal) is needed. In addition, an emergency power analysis needs to be completed. It was not clear from the briefings presented to the committee what the minimum power requirements are for crew survivability or how resilient the power system will be under various failure modes. Power adequacy is another of the committees concerns. Current plans call for the Phase 1 Space Station to provide 75 kW of electrical power to all toads, with the objective of providing 45 kW to the experimenters. The present design of
OCR for page 48
48 the Station requires at least 50 kW for systems operations. Moreover, all briefers indicated that system power requirements may increase beyond the 50-kW level. The photovoltaic panel deployment schedule for the 75-kW system has some major periods (6 to 9 months) in the installation phase during which the power installed is inadequate for the planned loads. If 75-kW ~budgets" and 100-kW ~requirements" continue much longer, the committee is concerned that Space Station mission objectives will not be met. This issue appears to have both engineering and management components. One possible way of addressing the issue might be by means of a "power czar," who would review, approve, and allocate all electrical demands in the Space Station. More generally, the committee believes that there is need for a management review of all utilities: electricity, heat, water, and so forth. The Space Station will be a small, remote community. One person in the program should be responsible for utility requirements, supply, specifications, and so on. Management needs to develop a cross-cutting utilities oversight program with authority to raise real-time issues. Thermal Control System radiator, The thermal control system uses a series of closed-loop heat exchangers to control the environment on the Space Station for both equipment and people. One of the requirements on the thermal control system is that nearly 40 kW of heat from the power conditioners and batteries must be radiated into space. The committee believes that the impact of a DC electrical supply versus 20 kHz AC with its 10- to 15-kW power loss should be analyzed from a thermal control point of view. The thermal control system programs for the thermal management of the photovoltaic power and space conditioning systems are presently at two locations: the NASA Lewis Research Center and the Johnson Space Center. Better coordination or even combination of the programs should be considered. In addition, the committee suggests that analyses be performed to address whether the photovoltaic radiators can be eliminated by one or more of the following measures: 1. moving DC/AC converters and batteries to the main
OCR for page 49
49 2. going to an all-DC system with load-specific power conditioning, or 3. using load partitioning (DC, AC). The committee also notes that it was indicated during the briefings that the 50-ft photovoltaic radiator will not fit in the Shuttle payload bay for the first flight. Environmental Control and Life SUPDOrt System. Man Systems. and Extravehicular Activity System Overview The function of the Environmental Control and Life Support System (ECLSS), Man Systems, and Extravehicular Activity (EVA) System is to insure that crew members work and live in surroundings conducive to maintaining good health and performance. The success of this complex is judged by the health and happiness of the crew members as well as their effectiveness and efficiency in the accomplishment of mission objectives. The ECLSS, Man Systems, and EVA System are intimately interdependent and also are closely related to the Fluid Management System, which will be discussed subsequently. The committee identified a number of issues related to these systems that warrant attention. Microbial and Toxin Control in the Space Station The crew's health, and therefore the achievement of operational objectives, may be jeopardized if one or more crew members are overcome by infection or toxins. For instance, there are persisting problems in ground-based experimentation on microbes, whereby a species of Pseudomonas cannot be removed from water. Also, biocides used to cleanse the interior of space vehicles actually encourage the growth of bacteria. Another example is the heightened awareness of the Space Station as a Tight buildings with the risk of accumulating indoor pollutants over the course of decades. Perhaps insufficient attention has been given to anticipating this problem and adjusting the engineering designs. If it is technically possible, a backup plan might be to exchange air by using existing interior air as a propellant. NASAts current approaches regarding this issue are robust and tenacious. Nevertheless there seem to be sufficient
OCR for page 50
50 warning signals to indicate that more must be done to alleviate the committee's concerns. In-Space Testing of Life Support Systems In-space testing of life support systems will help address the issue discussed above. At a fundamental level, however, more flight experimentation will be an important factor in assuring that reliability requirements for the ECESS are met. Some components of the system are novel and untested in space. Because of the critical nature of the ECLSS, the committee recommends that key subsystem elements, such as CO2 reduction, O. generation, and molecular sieves, be tested on Shuttle flights to demonstrate and refine their operation. One current approach by NASA includes a plan for a 1991 simulated closed module. This is commendable but does not alter the need to do some sort of testing in space. NASA's approach necessarily places great emphasis on use of the early man-tended operations phase of the Space Station as an ECLSS test bed. Careful attention and periodic reassessments of risk during ECLSS development will be needed to make this approach viable. Medical Evacuation Situations are likely to arise in which Station personnel need to be evacuated after an initial medical stabilization by fellow crew members. NASA has considered the possibilities for evacuation from the Space Station under a variety of circumstances. Medical evacuation remains an issue. Medical evacuation from space imposes special logistical, training, and technical problems that will have to be solved since there is no direct experiential base on which to build. At a minimum, NASA should continue to study this issue and decide whether to prepare for a medical evacuation capability early in the life cycle of the Space Station. HumaD Factors and Habitability While not specifically an engineering concern, the committee believes that attention should be paid to the quality and quantity of time when a crew member is not at work. This attention is needed because crew members' use of free time under conditions of confinement, stress, and isolation may be a
OCR for page 51
51 significant determinant of health maintenance in a situation in which crew must face heavy, important, and highly structured demands. It is extremely important that habitability provisions, especially those that offer comfort, privacy, and autonomy relative to crew members' use of space and time, should never be sacrificed or minimized. As an example, the findings that proper illumination may decrease depression in some people should be factored in as a consideration in the engineering design of the modules. Similarly, artificial means of designating perspective for up, down, right, and left must be incorporated in all parts of the Space Station, and indeed, NASA appears to be planning for such designations. In addition, the committee believes that the crew's efficiency over time aboard the Space Station is an impor~t issue. Based on experience from Antarctic research stations and the Soviet space stations, aggressive operational time lines and crew schedules may not be sustainable over long periods. The committee encourages NASA to continue its efforts to better understand this area. Radiation Surprisingly, there was little mention of radiation protection during the presentations to the workshop committee. Although it appears that radiation monitoring and assessment is well handled in terms of engineering design, the committee believes that it is important to continue to emphasize the need to better understand the radiation environment and the degree of protection required. Extravehicular Activity Besides the continuing work on decontamination (for gases and infectious agents) and consideration of astronauts' requests for a smaller EVA backpack, more development efforts are needed on monitoring for nitrogen bubbles in the bloodstream and on a means for handling vomiting while an astronaut is engaged in an EVA. FLUID MANAGEMENT SYSTEM The plans for an integrated fluid management facility need to be carefully developed. Although an integrated system might
OCR for page 52
52 reduce weight cost and complexity, the critical nature of the ECESS water and atmosphere systems requires that no contamination from the Fluid Management System (FMS) can be tolerated. The current design utilizes a single water and nitrogen supply system going to both the ECLSS and EMS systems. Although the design calls for check valves, the committee believes that a thorough analysis of this concept should be conducted prior to baselining an integrated system. The committee agrees with the design concept that recycled water from urine be used only for hygienic activities and that it not be connected to the potable water system. It also agrees that the Orbiter-provided water (from the Orbiter's fuel cells) should go into the potable system as a first priority. The issue of controlling waste liquids and gases is an important one in the committee's view. The EMS will have to contain a variety of gases and waste liquids from experiments as well as normal housekeeping wastes. The committee was told that neither the Columbus nor Japanese Experiment Module incorporate a system analogous to the Process Materials Management System planned for the U.S. modules. This situation needs to be addressed vigorously and resolved so that a safe internal and external (limited venting) environment is maintained throughout the Space Station. Finally, further investigation is needed to identify the most appropriate means of measuring and controlling trace constituents and microbial contaminants in the atmosphere.
Representative terms from entire chapter: