NASA ENGINEERING NETWORK
Follow this link to skip to the main content
+ Contact LLIS
Go
ABOUT NASALATEST NEWSMULTIMEDIAMISSIONSMyNASAWORK FOR NASA

+ NASA Home
FIND ENGINEERING RESOURCES BY
LLIS HOME
NASA CENTERS
MISSION DIRECTORATE
TOPICS
BY YEAR


Public Lessons Learned Entry: 0731

Lesson Info:

  • Lesson Number: 0731
  • Lesson Date: 1999-02-01
  • Submitting Organization: GSFC
  • Submitted by: Wilson Harkins

Subject:

Spacecraft Data System (SDS) Hardware Design Practice

Description of Driving Event:

This Lesson Learned is based on Reliability Practice No. PD-ED-1248; from NASA Technical Memorandum 4322A, NASA Reliability Preferred Practices for Design and Test.

This practice enhances reliability of the SDS and the probability of mission success by simplifying the design and operation of the SDS system and providing capability to work-around spacecraft and instrument problems.

Implementation:

The first SDS system described in this practice was successfully flown on the SAMPEX mission that was launched in 1992. This SDS system is being used on a number of later missions such as the X-Ray Timing Explorer (XTE), the Earth Observing System (EOS), and the Tropical Rainfall Measuring Mission (TRMM).

The SDS is a dual-redundant command and data handling system which functions as a command decoding and distribution system, a telemetry/data handling system, and a data storage system. It provides on-board computational capability for processing attitude sensor data and generating commands for the attitude control actuators in a closed loop fashion. It also provides stored command processing and monitoring of the health and safety functions for the spacecraft and instrument subsystems. The system design allows for modularity and flexibility in adapting the system for many different spacecraft. The use of standard interfaces and space qualified versions of widely used processors and related software, translates into higher reliability and major cost and schedule reductions not possible with the use of spacecraft unique interfaces, processors and software. The higher reliability results from widespread experience with the standard hardware and software in both space and nonspace related applications. The following are design practices incorporated into the SDS to improve reliability.

1) Use of MIL-STD-1773 Protocol For Data Bus Interfaces: The use of the MIL-STD-1773 fiber optic data bus and associated standard processors and operating systems significantly simplifies the design of command and data handling systems and the test and integration of spacecraft systems. This approach also significantly reduces the number of failure prone wires and electrical connections previously needed in the discrete wiring method. The fiber optics also reduces the probability of upsets and other radiation problems due to the radiation environment. A SDS for a typical spacecraft, such as the X-Ray Timing Explorer (XTE),will provide three data buses, namely Attitude Control, Spacecraft, and Instruments. Figure 1 is a block diagram of the XTE SDS system architecture.

refer to [D] description[D]

2) Redundancy and Cross-strapping: The reliability of the SDS system is significantly enhanced by the total redundancy of the system with each unit provided an identical backup unit to the other. The SDS units are cross-strapped to their respective data buses which provide the interconnections between them. All bus connected subsystems, components, and instruments are cross-strapped to their respective data buses. The cross-strapping of the SDS with the up and down links is shown in Figure 2. This figure does not show the cross-strapping of the transponders with their antennas. The SDS receives both primary and redundant power lines.

refer to [D] description[D]

3) Error Detection and Correction (EDAC): An EDAC capability designed into the SDS system improves reliability by preserving the integrity of data and protecting against induced errors. The backplane for the SDS is based on a modified PC-AT 386 backplane design which has been optimized by the GSFC for use in a space environment. A significant modification is the addition of an 8-bit wide check bit bus to the PC-AT design to support the EDAC function.

4) Uplink Board: The reliability of spacecraft operations and control are enhanced by ensuring that the uplink board is the sole avenue by which commands and data are received by the spacecraft from ground support systems during orbital operations. The design for this board is modeled after the SAMPEX uplink board design, but incorporates a number of design modifications unique to the SDS design. The primary command link circuitry and operation is fundamentally unchanged, but a capability to accept hardware decoded uplink commands (bypassing the SDS system software) and cross-strapping between dual transponders has been added. A power converter has been added to the board design in order to permit the board's power supply to always remain on and independent from the rest of the SDS system power. The input to this power converter is unswitched power from the essential SDS power bus. The uplink board interfaces to the SDS and the rest of the spacecraft primarily through communication on the SDS MIL-STD-1773 data bus, on which it is designated as a remote terminal. There are 64 discrete hardware decoded command lines from the uplink card to various spacecraft subsystems.

5) Bulk Memory Boards: The reliability of the Bulk Memory Boards is increased by memory isolation circuitry which isolates a failed segment of the memory board and keeps it from affecting the entire data system. The SDS bulk memory board is modeled after the SAMPEX memory board design, but incorporates the memory isolation as well as a number of other SDS design modifications.

6) Low Voltage Power Converter Boards (LVPC): The design of the 2 redundant LVPCs in the SDS system are similar to the SAMPEX Recorder/Packetizer/Processor (RPP) power converter board except for two significant SDS changes to enhance reliability by providing capability for improved control of discrete RESET commands. One change was the addition of a redundant power line. The other change was the addition of a hardware-decoded discrete RESET input command which allows commanding of an 80386 reset independent of the SDS MIL-STD-1773 data bus and system software.

7) Reliability Related Command Execution Capabilities:

  1. Every SDS autonomous function is capable of being enabled or disabled by command.
  2. The SDS by command can perform preplanned diagnostic and operations checkout of itself.
  3. No single command can place the SDS into a configuration from which it cannot recover.
  4. The SDS can supply telemetry data such as configuration and health and safety status, indications of anomalous conditions, and performance monitoring data to enable ground controllers to assess the operational state of the SDS and its software.
  5. The SDS will execute only ground commands to exit from "safe" modes.

8) Failure Tolerance: The reliability of the SDS is significantly enhanced by its capability to tolerate single failures including the failure of spacecraft harnesses servicing the SDS. The SDS design does not permit a single failure to cause another failure or the loss of a redundant critical function path.

Technical Rationale:

The redundancy and cross-strapping features of the SDS and its data bus provide a wide range of fault isolation and work-around capabilities that can significantly increase the reliability and the useful life of spacecraft missions. In addition, a number of other design features minimize the impact of component failures and prevent the execution of false or inappropriate commands.

References

  1. MIL-STD-1773: Fiber Optic Mechanization of an Aircraft Internal Time Division Command/Response Multiplex Data Bus
  2. Individual Project C&DH Specification and Interface Control Documents


Lesson(s) Learned:

If these design practices are not incorporated into the design of the SDS, early, partial, or complete curtailment of the mission could occur due to component failure or to false or inappropriate commands. SDS performance data may not be available for failure analyses and the capability for work-around procedures may not be available.

Recommendation(s):

Use a standard SDS in spacecraft where possible which utilizes a standard data bus and space flight qualified versions of widely used hardware and operating software systems.

Evidence of Recurrence Control Effectiveness:

This practice has been used on Solar, Anomalous, and Magnetospheric Partial Explorer (SAMPEX).

Documents Related to Lesson:

N/A

Mission Directorate(s):

  • Exploration Systems
  • Science
  • Space Operations
  • Aeronautics Research

Additional Key Phrase(s):

  • Computers
  • Flight Equipment
  • Hardware
  • Information Technology/Systems
  • Launch Vehicle
  • Payloads
  • Software
  • Spacecraft

Additional Info:

    Approval Info:

    • Approval Date: 2000-03-31
    • Approval Name: Eric Raynor
    • Approval Organization: QS
    • Approval Phone Number: 202-358-4738


    FirstGov - Your First Click to the US Government
    + 2004 Vision for Space Exploration
    + FY 2005 Budget Request
    + 2003 Strategic Plan
    + Freedom of Information Act
    + The President's Management Agenda
    + FY 2003 Agency Performance and Accountability Report
    + NASA Privacy Statement, Disclaimer,
    and Accessibility Certification

    + Freedom to Manage
    NASA
    Curator:Celeste Merryman
    NASA Official: Gregory Robinson
    + Contact LLIS