11.4 General Setup and Design Drivers

General setup doesn’t pertain to one subsystem at a time, but a system as a whole.

• How do we integrate and test a satellite?
• What are best practices when integrating and testing?
• What do the support equipment and environment testbeds look like and what do their capabilities need to be?

A typical testing flow looks like this:

EDU vs Flight Unit

If a project has enough money, the engineers will buy duplicate units. One unit is dedicated to engineering development (EDU) and the other to flight. The EDU is identical in hardware and software, functionally equivalent, but may not have been environmentally tested. The EDU may be cheaper during procurement due to less rigorous or complex manufacturing and testing standards. The EDU is meant to be exercised in functional tests at the component to system levels. The idea is to rigorously test this less expensive unit and reduce wear-and-tear on the unit that will actually go into space, the flight unit. Before delivery, the flight unit’s health is checked out by engineers/scientists and lightly exercised to ensure system functionality. The majority of the flight unit’s operations are reserved for in-space nominal operations.

Umbilical

In space, a spacecraft will be a free-floating object, self-contained and hopefully self-sustaining. While on the ground, the spacecraft will have an umbilical cord to supply the integrated subsystems’ power and data for testing and operations. The umbilical port typically taps right into the data bus of the satellite, allowing operators to interact with the system digitally. Interactions include monitoring signals, injecting commands, or even re-coding software! This umbilical port and associated harnessing is not necessary for flight but makes testing on the ground much, much easier.

Simulators for Functional Testing

To test the satellite in spacelike conditions on the ground, we use simulators and support equipment to mimic phenomena of space. Some examples include microgravity dynamics (ADCS testbed), LEO solar irradiance (power support equipment), and vacuum (thermal testbed). Ideally, all subsystems undergo some test on the ground analogous to space-like conditions, simulating as close to the physical phenomenon as possible.

“Electrical Ground Support Equipment (EGSE) are tools used by satellite and sub-system manufacturers and integrators to test and validate electrical functions of the satellite on the ground before launch” [Celestia]. The electrical subsystems under test are typically the payload, power, and communications. The test equipment typically consists of a way to calibrate and a method of functionally verifying the subsystem works. Calibration “quantifies and controls errors or uncertainties within measurement processes to an acceptable level. The goal of calibration is to minimize any measurement uncertainty by ensuring the accuracy” of the test sensor [LabFacility]. Functional verification for the communications system essentially requires a simulated ground station but scaled with the distance/power of the test. Examples of EGSE include power supplies, digital multimeters, signal generators, solar array simulators, battery simulators, GPS simulators, load simulators, and adaptable ground stations, etc.; all calibrated. This equipment typically measures and stores data; visualizes data for an operator; and may have capabilities of setting limits or warnings for anomalies.

The EGSE covers all subsystems except for ADCS, thermal, and structures. Metal structures are characterized well by finite element analysis, so physical simulators are not necessary unless the structure is made of a specialized material or we want to test a mechanism. For the first case of a special material, tension or compression machines can simulate expected loads in space or launch conditions. For mechanisms, gravity off-loading testbeds can simulate microgravity dynamics, like in these solar panel deployment tests.

^{GOES-R Solar Array Deployment Test at Lockheed Martin. Video by Lockheed Martin.}

The mechanisms typically simulate linear (translational) motion but for ADCS, we want to simulate rotational motion and sensor readings that pertain to attitude determination. The ADCS simulator has capabilities of at least 1 degree and up to 3 degrees of near frictionless rotation, typically supplied through an air bearing. This motion can be sensed with an onboard rate sensor or IMU and controlled with some momentum control device, like reaction wheels.

^{CubeSat Hybrid Attitude Determination and Control Through HiL Simulation. Source Youtube, Spacecraft Robotics Laboratory.}

The sensors that need to be fed some input typically include a magnetometer, sun sensor, nadir sensor, and star tracker. The magnetic field can be spoofed with a Helmholtz cage. The sun can be spoofed with a bright, directed light. Earth’s limb can be simulated with large studio light. The celestial sphere can be simulated with a black dome and precisely-placed holes (NASA’s Formational Control Testbed) or a digital screen casting white pixels against a black background to simulate stars (NASA’s Small Satellite Dynamics Testbed).

The thermal environment in space is typically simulated with a thermal vacuum chamber. On the ground, most external heat transfer is by way of convection, whereas space is dominated by radiation. Spacecraft experience conduction internally in both environments. A spacecraft within a thermal vacuum chamber experiences near-vacuum in a controlled thermal environment, where hot plates and cold shrouds are toggled to simulate the thermal cycles across an orbit. These thermal profiles aim to provide thermally and temporally realistic inputs to a spacecraft to evaluate the spacecraft’s thermal subsystem’s performance in keeping the spacecraft in a comfortable operating range.

Best Practices for Functional Testing

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. This type of testing is called bottom-up testing, seen in the figure. Initially, the software and hardware are separate, then integrated after individual module/component testing. The avionics is then integrated into the main system incrementally, one subsystem interface at a time. We also want to enable on-orbit check-out and calibration in the testing scripts, derived from ground tests. High-level testing means we are issuing commands at a high level and we do not know what problems we’re looking for! By attempting to transition from one mode to the next, you may discover that the communication protocol for the radio to the onboard computer is ill-defined and these data packets are garbled. This process usually consumes half of the development costs and time!

From the way we described testing, 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 simulation that feeds the flight computer all the sensor measurements, refer back to the Simulator section; 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. The CDH specialist collaborates with the integration and testing engineers to establish the compartmentalization, the proper interfaces and switching between simulated/emulated vs. real data.

^{Simulating and Testing TargetLink code (PIL). Vide by dSPACE.}

Testbeds for Survivability

All of the above simulators stress functionality in a space environment analog. Outside of functional testing, we need to make sure the system survives and functions in an environment with a representative amount of radiation. The test setup involves beaming radiation in a controlled line toward the device under test (DUT) and only the device under test. “Shielding of electronics that control the test setup is very necessary if they are close to the beamline. In a Total Ionizing Dose (TID) test, having a separate voltage-bias circuit board to power the DUT while in the radiation chamber is often necessary to protect control electronics. The test environment (i.e. ionizing radiation) is the primary constraint when testing and how it may affect other components on the circuit card is critical to building a good test setup” [NASA].

Suggested Reading

Other things to consider within the environment are the operating system supervisors, the physical location of software payloads (inputs) and results (outputs), the integrity of data paths, and control of electrical and thermal loads.

The following list of accessible nodes provides some high-level guidelines for where to monitor a test.

• Network
  • Heartbeat by inbound ping from the operator area
  • Heartbeat by timestamp upload via file from DUT
• Peripherals response
  • “Num lock” toggle on the keyboard
  • Blinking cursor at terminal client prompt
• Visual check
  • Remotely view screen via remote desktop application (i.e. VNC)
  • Local view of the screen via a long cable run
  • Remote viewing of the local screen using IP camera
• Electrical states
  • At the system via power supply control
  • At the DUT via interposer and monitoring circuit
• Temperature
  • At the DUT (microenvironment)
  • Around the DUT (macro environment)
  • Ambient

Another simulator that tests survivability is a vibration table, which simulates the vibration from a launch vehicle. A vibration test does not emphasize functionality but the survivability of the entire system. This testbed and test are usually reserved after every single hardware component is finalized and integrated. After a vibration test, the spacecraft’s health is rechecked to see if all components and interfaces survived the test.

^{James Webb Space Telescope Vibration Test. Video courtesy of NASA.}

Test Scripts that are Not Flight Software

To support all the physical testing previously mentioned, users must develop test scripts specific to the tests they are running that differ from the software that will go into space. Test scripts may:

• Set different configuration parameters in sensors to account for simulated ground conditions vs space conditions
• Log data more frequently or for a longer period of time
• Explore edge cases or extreme settings that won’t necessarily be seen in space operations
• Post-process and analyze the system’s performance
• Be based upon flight software with additional modifications for ground

These test scripts may be developed for the simulators and for the spacecraft. Scripts specific for testing may be loaded directly onto the spacecraft but should be steadily transitioned to flight software as delivery approaches.

Fault Testing

Adopting terminology from a secure computing paper, there are three things to consider when crafting a verification test: testing purpose, system model, and fault model [Avizienis]. There are two testing purposes: conformance testing, to see if the system is able to deliver a specific service or meet a requirement, and fault-finding testing, which reveals faults. The system model under test may be separated into the functional objects (components and subsystems themselves) and interfaces (the structure that binds the objects together). Fault model refers to the existence or absence of faults you want in your test. Do you want to test nominal operations, no faults, or faulty behavior? Given different permutations of each consideration, the resultant test is given on the far right.

The order of the testing is listed sequentially. The first test you should conduct is functional testing of a module (at the component, subsystem, or system level) in the absence of faults, the best-case scenario. Then on the second row, you can extend this test to explore cases in which you anticipate faults occur to verify their existence. The third row is the attempt to find faults in operations where faults are not anticipated to occur. The last two rows mimic fault finding but at the interfaces.