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:
advanced automation
