Command and Data Handling (C&DH) AERSP 401A

C&DH Principal Function Other Names References Processes and distributes commands; processes, stores, and formats data Other Names Spacecraft Computer System Spacecraft Processor References 10.4.4, 11.3, Chapter 16

Sizing the C&DH Subsystem Step What’s Involved Reference Prepare Command List Prepare a complete list of commands for the payload and each spacecraft bus system. Include commands for each redundancy option and each commandable operation. 10.4, 11.3 Prepare Telemetry List Analyze spacecraft operation to select telemetry measurement points that completely characterize it. Include signals to identify redundancy configuration and command receipt Analyze Timing Analyze spacecraft operation to identify time-critical operations, and timeliness needed for telemetry data. 10.3, Chapter 16 Select Data Rates Choose data rates that support command and telemetry requirements and time-critical operations. 13.3 Identify Processing Requirements Examine need for encryption, decryption, sequencing, and processing of commands and telemetry. 11.3 Identify Storage Requirements Compare data rates of payload and spacecraft to the communications subsystem’s ability. Select Equipment Configure the subsystem and select components to meet requirements

Typical Characteristics of Basic Components for C&DH Mass (kg) Power (W) Comments Command Unit 5.0 5.4 standby 1.4 operating Redundant unit, 9 user addresses capacity, 18,892 commands Pulse Code Modulation Encoder 5.5 Redundant unit, 250 or 1,000 bits/sec 64 word, 8 bit frame 5 subcommunicated channels

Space Computer System Key Concerns More on-board processing is desirable and inevitable Can increase functionality with major savings in weight, power, and cost Can significantly reduce operations and, therefore, lifecycle costs Can dramatically increase system flexibility – software is, but far, the least expensive “on-orbit replacement unit” Formally correct approach is to decide on the appropriate software and then size the computer to meet the need Not a realistic alternative in today’s environment for most functions Net result is a major performance, cost, and schedule risk Key computer system trades On-board vs. ground processing What to automate Selection and sizing of hardware Language selection Software selection or development

Computer Systems Development Process Define Requirements Develop System Baseline Expand Baseline Concepts Evaluate System Effectiveness Evaluate Mission Objectives Perform Functional Partioning Evaluate Candidate Architectures Perform Functional Flow Analysis Establish Block Diagram for System Evaluate and Select Hardware Instruction Set Architecture Evaluate and Select Software Language Define Processing Tasks Establish Computer Size and Throughput Estimates Verify Requirements Traceability Evaluate Baseline Against Design Drivers Assess Development Issues for System Baseline Evaluate System Testability

Candidate Architectures Centralized Architecture Earth Sensor Thrusters GPS Central Processor Star Tracker Gyros Wheels Accelerometer

Candidate Architectures Ring Architecture Earth Sensor Thrusters GPS Central Processor Star Tracker Gyros Wheels Accelerometer

Candidate Architectures BUS Architecture Earth Sensor Central Processor Accelerometer Gyros Thrusters Wheels Star Tracker GPS

Physical Characteristics Economic Characteristics Architecture Trades All architectures must meet mission requirements to be considered in architecture trades Typically, architecture trades are somewhat subjective, although standard discriminators exist: Physical Characteristics Economic Characteristics Size Weight Power Design for Instability Complexity Risk/Maturity Cost/Schedule Maintainability Reliability Others Fault Tolerance Reconfiguration Use of “enabling technologies” Proof-of-concept Final processing architecture is frequently a hybrid – optimizing all aspects of the design

Architecture Selection If mission requirements strongly emphasize weight and power and those budgets are fixed, some reliability and fault tolerance must be sacrificed to meet needs. If mission life is critical and payload operation is the highest requirement, some additional weight and power may be needed to enhance reliability.

Summary Software offers major advantages in performance, recurring cost, “lifecycle”, flexibility, and reliability High autonomy offset by significant disadvantages High non-recurring cost Development risk is large – only way to know the requirements is to write the software in advance Difficult process to manage and measure progress In the near term, computers will become most important in: LightSats where needed performance cannot be achieved without them Constellations or recurring applications, where non-recurring cost can be amortized

Command Decoder Block Diagram Command Outputs Pulse Data Clock Enable High-Level Discrete Uplink Command Source Arbitration Command Message Validation Command Message Decoding Onboard Computer Low-Level Discrete Hardline Test Serial Digital Over/Under Voltage Detect Command Decoder Prime Power

Data Handling Unit Block Diagram Multiplexed Signal Inputs High-Level Analog Analog to Digital Converter Data Formatter and Control Logic Downlink Low-Level Analog Onboard Computer Passive Analog Hardline Test Bi-Level Serial Digital