9.4 Typical Requirements and Design Considerations

For the spaceflight mission, the CDH system must be designed to support the data and processing needs of the payload and spacecraft bus. Requirements include technical specifications for the:

• • Throughput or number of channels is the amount of information that can pass primarily between the payload and flight computer [Jeberson]. The number of channels is typically dictated by payload instruments, corresponding to the number of imagers or cameras. More formally, throughput is dictated by the frequency of the function (execs/s) and instructions per execution and cycles per instruction.
  • The computer performance depends on all the applications and functions the spacecraft mission requires. Typical functions include [Selva]:
    • Payload: pointing, on/off.
    • TT&C: telemetry and command processing, manage the downlink, accept the uplink
    • Attitude/Orbit sensor processing: gyros, sun sensors, …
    • ADCNS algorithms: Kalman filter, integration, orbit propagation
    • Attitude control (actuator) processing: thrusters, reaction wheels…
    • Fault detection: monitoring, identification, and correction
    • Power Management: charging, solar array pointing
    • Thermal Management: heaters, louvers, coolers, pointing
    • Momentum management: momentum wheels
    • Utilities: basic math functions, matrix math, time management, rotations
• Flight computer performance requirements include Central Processing Unit (CPU) capability, Graphic Processing Unit (GPU) capability, and Field-Programmable Gate Array (FPGA) capability.
  • CPUs are evaluated upon their clock speed, their processor, the number of cores, caching, and ability to integrate with the GPU [Patkar].
  • GPU requirements could be formed around clock speed, memory, and power consumption [Walton].
  • FPGAs requirements include a number of logic cells, clock speed, computation, memory bandwidth, and Input/Output (IO) bandwidth [Storaasli].
• The onboard clock drives the timing accuracy of the whole system and must be chosen based on the timing requirements from the payload or subject. Other time-related requirements include scheduling and synchronization.
• Hardware interface requirements are driven by the hardware selection in the other subsystems,
  • such as the physical connectors that communicate directly to the onboard computer or indirectly through a daughterboard. These interfaces come with inherited communication formats, like USB, I2C, or SPI.
  • The hardware outside CDH may come with manufacturer-installed software in the form of firmware or drivers that the flight computer would have to interface with on the software side.
• Software is evaluated on the basis of reliability and the availability or ease of use of development tools, COTS software, emulator, or engineering models.
• Radiation hardened electronics are “resistant to damage or malfunction caused by high levels of ionizing radiation” relevant in space environments. Radiation hardening can prevent ionizing particles from switching a bit in a data line or memory registry that sets off a chain of events that the software cannot recover from. For more information, read up on radiation effects on electronics.
  

  

• Single-Event Latchup (SEL)
  • A radiation-induced event will inject a charge that activates the feedback loop and connects VCC to GND
  • High current density results in extremely high, localized heat

• Single-Event Upset (SEU)
  • Flip the state of data by introducing enough charge to overpower the transistors holding the value of a data bit

• Single-Event Transient (SET)
  • transient pulses by momentarily turning on driver transistors that should be off

• Total Ionizing Dose (TID)
  • Cumulative long-term ionizing damage due to protons and electrons can cause devices can suffer threshold shifts, increased device leakage (& power consumption), timing changes, decreased functionality, etc.

During manufacturing and assembly, the flight computer is the only hardware you need to handle as the CDH specialist. Even then, the integration specialist or electrical power system specialist may assist you in assembling the hardware. The handling of the flight computer is much like the handling of the electrical power system components.

During testing, the software must be flexible to accommodate various testing configurations, which is not a requirement but a design consideration. Testing and verification are usually done incrementally, from a single component to a conglomerate of components as a subsystem, then to a conglomerate of subsystems into the fully integrated system. In this way, software scripts need to be compartmentalized and callable by other higher-level scripts, like the main script. To verify that the spacecraft functions as expected on the ground, software must accommodate the spoofing or emulation of data that makes the satellite think it’s receiving data from a space environment. This data is typically provided by a flight simulation that feeds the flight computer all the sensor measurements; this test is called a process-in-the-loop test. One step further is to spoof or emulate space environment conditions with a physical testbed, which receives simulated conditions and recreates lighting, magnetic, and dynamic conditions; this test is called hardware-in-the-loop. There exists an immense amount of software dedicated to testing that will never be incorporated into the as-flown flight software.

^{Jim Nicholson worked as the Chief Engineer for the Cygnus Spacecraft at Orbital ATK for the Commercial Orbital Transportation Systems (COTS). Jim describes the importance and reason to do processor in the loop tests. Spacecraft and Payloads. Avionics and Software In the Loop Testing by Jim Nicholson. Video courtesy of NASA.}

During transport and handling, the flight computer is off and self-contained within the satellite. There is no requirement the CDH specialist needs to adhere to from this phase. From the time of delivery through on-orbit deployment, the CDH specialist may have the option to power up the flight computer and upload new flight software if the previous version is out of date. If the launch providers are kind enough to allow for any testing during integration into a deployer or onto the launch vehicle, the CDH specialist may remotely conduct system checkouts and run a few test cases. The flight computer and flight software should accommodate software updates and remote testing.

Artemis Kit Specific

Suggested Activity