Concepts for vehicle and payload avionics architectures for future NASA programs, including the Assured Shuttle Access program, Space Station Freedom (SSF), Shuttle-C, Advanced Manned Launch System (AMLS), and the Lunar/Mars programs are discussed. Emphasis is on the potential available to increase payload services which will be required in the future, while decreasing the operational cost/complexity by utilizing state of the art advanced avionics systems and a distributed processing architecture. Also addressed are the trade studies required to determine the optimal degree of vehicle (NASA) to payload (customer) separation and the ramifications of these decisions

Creasy, Susan L.

Levy, C. D.

English

NASA Technical Reports Server

PRESENTATION 3.3.2
N91-17046
AVIONICS PAYLOAD SUPPORT ARCHITECTURE
637
https://ntrs.nasa.gov/search.jsp?R=19910007733 2020-03-19T19:58:04+00:00Z

SPACE TRANSPORTATION AVIONICS TECHNOLOGY SYMPOSIUM
PAYLOAD ACCOMMODATIONS
AVIONICS PAYLOAD SUPPORT ARCHITECTURE
JSC/SUSAN L. CREASY/HEAD, PAYLOAD SUPPORT OPERATIONS SECTION
MMAG/C.D.LEVY/ MANAGER OF HOUSTON OPERATIONS
NOVEMBER 1989
OVERVIEW
This paper addresses concepts for vehicle and payload avionics architectures
for future NASA programs, including the Assured Shuttle Access program, Space
Station Freedom (SSF), Shuttle-C, Advanced Manned Launch System (AMLS), and
the Lunar/Mars programs. Emphasis is on the potential available to increase
payload services which will be required in the future, while decreasing the
operational cost/complexity by utilizing state of the art advanced avionics
systems and a distributed processing architecture. Also addressed are the
trade studies required to determine the optimal degree of vehicle (NASA) to
payload (customer) separation and the ramifications of these decisions.
MAJOR OBJECTIVES
The avionics payload support architecture for future NASA space programs is
designed to meet several major objectives. The typical customer vehicle
avionics requirements include reliable provision for command, telemetry,
video services, onboard data storage capability, and the capability to access
vehicle data (e.g., attitude, state vehicle, timing, etc.) through some sort
of "gateway". The extent and requirement for these services depends upon the
type of payload (deployable, attached, scientific experiment, etc.) and the
type of mission (e.g., short versus long duration). A deployable payload
which only resides in the NSTS orbiter for a few hours on-orbit typically
requires different services than will attached SSF scientific experiments.
From the NASA budgetary perspective, it is important to utilize an avionics
payload support architecture which reduces the labor intensive integration,
flight to flight reconfiguration process, mission operations support and
crew/controller training.
In order to accomplish this, it is desirable to reduce the interdependence of
the vehicle and payload where practical. By selectively designing the
payload architecture to include a separate distributed payload data
management system, including separate data storage as well as processing
equipment, the payload capabilities are not limited by competition with the
vehicle's requirements and the payload schedule is not tled to a mature
vehicle's reconfiguration schedule. (See figure I.) It would also be
desirable to have a separate upllnk and downlink capability for the same
reasons as outlined above. This capability may be more of a cost impact and
must be weighed as such.
An additional consideration in the design of the avionics payload support
architecture is the utilization of government or industry standards such as
the 80386 processor, the 1750A processor, the 1553 data bus, etc. This will
enhance the budgetary aspect of the program by allowing the use of commercial
off-the-shelf (COTS) hardware and software, as well as providing the customer
with standards for their design and software development that match those
PRE'CEDII'_G P_GE BLANK NOT FILMED
639
available on the open market. Additionally, a customer could then transition
easily from host program to host program (e.g., Shuttle to Space Station
Freedom) without major electronic redesign. Other benefits to this approach
would be derived if the system was designed to allow provision for program
interchangeability of components and the capability to easily upgrade the
system as new capabilities are developed.
MAJOR MILESTONES
The concept of the use of a distributed avionics support architecture for
payload applications is not a new one. It was proposed in the 1970's during
the design phase for the NSTS orbiter. It was not implemented due to
philosophical and budgetary considerations. As a result, the STS currently
assumes an increased cost for payload reconflguration flight to flight, does
not provide sophistication in payload software control, provides minimal
payload data storage capability, provides only minimal vehicle data to major
payloads, and provides no vehicle avionics services to the scientific
experiments flown in the middeck. In order to alleviate some of these
concerns, and with the advent of the microcomputer technology, the STS is now
providing customers with the option of using the STS payload and general
support computer (PGSC), which is a modified GRID 1530. The STS-provided
PGSC is flight qualified. Its utilization is under configuration control by
the STS relative to the user interface. This insures standardization in
order to reduce crew/ground training and simplify procedure development. The
Interface Control Document (ICD) and user guidelines for the PGSC were
published in 1989 and the system flew on STS-30 and STS-34 for the Fluids
Experiment Apparatus (FEA) and Polymer Morphology (PM) payloads,
respectively. Numerous other payloads have requested its use. Most notable
is the Tethered Satellite System (TSS).
The PGSC does not directly have a llnk to the orbiter communication system
which limits ground control of experiments. This, in turn, potentially
limits scientific return from payloads and also places a greater burden on
the flightcrew (training and timeline impact). In some applications, such as
TSS, this is overcome by use of the STS smart flexible
multlplexer/demultiplexer (SFMDM) which is connected to both the orbiter
communications system, as well the PGSC.
Another major milestone toward the recommended payload support architecture
was the original SSF payload support architecture definition. It included a
distributed processing architecture, standardized testing, checkout, and
training, and, in general,a decoupllng of vehicle and payload services.
Unfortunately, the 1989 budgetary scrub exercise resulted in the potential
deletion of many of the distributed payload avionics capabllltles at the
Permanent Manned Configuration (PMC) such as a separate payload local area
network (LAN), separate payload data storage capability, and separate payload
command uplink capability. It was proposed that this configuration would be
eventually upgraded with the later full-up configuration. Of concern is that
the full-up configuration is not funded and will itself probably be
confronted with a stringent budget. In addition, the cost and labor required
to upgrade the system by the astronauts will be time consuming and complex.
The Shuttle-C payload services definition served as another milestone.
Although the proposed payload services provided by the Shuttle-C are somewhat
64O
minimal, it did propose placing the majority of the payload services
responsibility on the payload customer and thus simplifying the payload
integration and operations costs.
TECHNOLOGY ISSUES
Some technology issues exist for the above mentioned programs. For the STS
orbiter, the issues and work that are ahead as part of the Assured Shuttle
Access program include replacing certain components such as the pulse code
modulator master unit (PCMMU)/payload data interleaver (PDI) due to parts
obsolescence. This opens the opportunity to enhance the downlink data
capability as well as provides redundancy in the payload PDI link. Cost,
schedule impacts to vehicles in the flow, and compatibility with the orbiter
communications system are issues being worked in this area. Another item
under investigation is the replacement of the orbiter payload recorder with
one more suitable to the typical payload's bit rates and data recording
requirements. Another technology issue relates to the need for further
advances in connector and cabling design in order to reduce both volume and
weight. This is, of course, a concern with all of the programs. Another
area that needs further work is to develop a capability, via modem or a
separate SFMDM type "black box", to provided communication services to
orbiter payloads, such as middeck scientific experiments.
The major technology issues for the SSF program, relative to avionics payload
support architecture, are in the integration of existing avionics
technologies to control multiple real-time systems and limited vehicle
resources, such as power, communication, assets, etc.
The Lunar/Mars programs require more sophisticated avionics capabilities in
order to meet the expected needs of these payloads over extended periods of
time and with a greater communication lag between the ground operation team
(including scientists) and the vehicle. This will lead to an increased
requirement for automation and expert systems capability. In addition, it is
estimated that the data storage capability required for some payloads which
are proposed for the Mars mission would be on the order of 1X10E12 bytes,
which is two orders of magnitude greater than what is currently available.
In addition to this need for increased onboard data storage, it is
anticipated that there will be a requirement for some level of
pretransmission data compression for the Mars mission which has historically
been a concern to the vehicle and scientific communities.
Another area which warrants further exploration for each of the NASA programs
Is advancement in technology to increase the operational efficiency of the
above programs in areas such as automation, robotics, expert systems, voice
recognition, speaker independent systems,enhanced video display capability,
etc.
TRADE STUDIES
Perhaps more important than the technology issues mentioned above are the
trade studies that are required to determine the NASA position relative to
the payload community. The overall concern is the appropriate degree of
NASA/user separation. This lies at the heart of many policy decisions
relative to the handling of payloads. The question concerns the balance of
641
common services provided by the vehicle (NASA responsibility) versus those
provided by the customer (user responsibility). For example, If the Agency
were to provide an industry standard architecture (ISA) processor with
display capability, an I/O consisting of MIL-STD-1553B data busses, storage
medium, and access to vehicle system data vla a gateway, should the Agency
provide the real-time ADA operating system with the application software
being the responsibility of the user? If so, what is the interface criteria
between the operating system and the application programs? Where does the
responsibility lie between NASA and the customer? Would NASA supply the
background display structure and the customer provide the dynamic fill to
reduce and minimize crew training, whether ground or flight? Is there some
interface llne that can be drawn between host vehicle and user
responsibilities that is beneficial to both In cost and integration schedule
flexibility? If this type of standardization is used (in the example), the
customer can utilize relatively inexpensive ground versions of the flight
hardware for software development, validation, and payload checkout. When
drawing this "line", developing a policy, or developing a criteria, serious
deliberation and consideration should be given to safety (i.e., when can
closed loop control not be implemented by the customer), mission success,
reliability and/or redundancy, minimizing crew training, integration of the
cargo complement (i.e., multiple payloads), and data processing security
(i.e., protection of customer proprietary information).
SUMMARY/RECOMMENDATIONS
In summary, It is important to keep in mind that the major goal of the
operational NASA missions is related to payload/experiment activity, be It
deployment of a satellite or a long-range scientific experiment. It is
important to insure that the NASA programs provide services to make those
programs, whether it is Shuttle-If, SSF, or some advanced upper stage,
accessible to users. In addition, it Is important for NASA to make
responsible decisions In the design of its programs to insure that they have
not cut costs for DDT&E, which will result in increased costs in the out-
years that significantly exceed what would have been the initial DDT&E cost
investment. It Is time for the Agency to address commonality between
programs to reduce DDT&E cost and "redesign the wheel" tendencies. It is
equally important that these designs provide the user a low cost means to
utilize the host vehicle capabilities without complex, tlme consuming
integration processes, which is a major complaint of shuttle users. Program
commonality and simplified integration processes with respect to payload
accommodations provides the same cost and labor benefits to the customer that
could be realized by NASA. Commonality provides options to the user for
access to space. In simple terms, more programs and more experiments could
be started, developed, and flown for the same budget, if cross program
avionics commonality is imposed In the out years. However, DDT&E monies must
be expended now to realize such a benefit.
In order to further pursue these areas, several things must be accomplished.
Development of a payload/host vehicle policy Is required to distribute
responsibility, when practical and cost effective, to the user. It may be
necessary to rearrange these responsibilities based on the type of host
vehicle (i.e., Shuttle-II versus Shuttle-C). Whatever the result, this
policy should provide a framework for avionics hardware and software
642
commonality between a11 host vehlcle programs and should dellneate the
separation of responsibilities between host vehicle and user.
An avionics payload support architecture must then be developed to support
the resultant policies. Paramount to this design Is addressing
standardization-use of those industry or government standards that impose
program cross utilization, a means of technology evolution to resolve parts
obsolescence concerns. The final system should also include functions that
minimize the out years operating base, such as built in test and checkout.
It is in NASA's best interest to develop such a payload support architecture
for use across programs to use new avionics technology to increase operations
efficiency and thus reduce recurring operations costs.
KEY CONTACTS
Other sources of information on these areas are as follows:
Stan Blackmr/JSC/TJ2 (STS)
8111Mallary/JSC/EH (SSF)
Ned Trahan /JSC/EH
Charlte Price /JSC/EF
C. O. Levy/@CHC, Houston
Steve [lrod/HSFC (Shuttle-C)
643
!
!
_w
u.I
0
1:;
0
.m
&.
<
0
Q.
Q.
"0
m
0
m
m
A_
,m
e_
o
el
>
0
m
>
<
"0
0
Q.
0
L_
a.
m
o
m
E
m
x
L_
*m
644
PRESENTATION 3.3.3
SATELLITE SERVICING SUPPORT
_5



Payload accommodations. Avionics payload support architecture

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server