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