11.1 Definition

A system specifically refers to your spacecraft but could refer to any level of system you’re interested in. You can think of a system as “a set of things working together as parts of a mechanism or an interconnecting network.” A Soyuz capsule traveling to the ISS is a spacecraft system. The ISS is a distinct spacecraft system.

The Soyuz capsule and the ISS docked together can also be considered a spacecraft system, which may be useful for calculating the dynamics of these two rigidly mounted bodies that now act as one rigid body.

Integration is the process of uniting disparate components, subsystems, or systems, typically vertically up and down a hierarchy. The final spacecraft is the product of integrating all spacecraft systems. In the previous example, the Soyuz capsule was integrated into the ISS. Integration could also refer to a component, like a reaction wheel, being joined together into an attitude determination and control module, consisting of a frame and ADCS sensors (component integrated into subsystem). Components can be integrated together to form the beginning of a subsystem. Subsystems can be integrated together to form the beginning of a system.

Testing is the verification process to ensure that the spacecraft meets requirements and the spacecraft functions as designed for aspects that are not covered explicitly by the requirements. Testing exercises a system, whereas not all verification requires that the system be exercised like static analysis or system proving. The intention of the word “testing” is to encapsulate all forms of verification.

Let’s walk through this verification tree, which I’ve borrowed from software engineers. As a reminder, verification is checking if the system does what you expected it to do or meets your predefined requirements, whereas validation is if the functionality meets the stakeholder’s needs.

Verification can first be separated into two categories, whether the system is exercised or not. Exercising a system means that you have the as-built system (software, electrical, or mechanical) in front of you and you run a test on that as-built system. We call this type of verification dynamic because the system can interact with inputs and modify its behavior. A system that is not exercised is instead verified through more abstract venues, like theoretical models. These methods of verification are static in that we take a snapshot of the system and conduct our analysis on that single instantiation without the physical system’s feedback, although we can simulate feedback. The picture of the structural verification above shows the difference between dynamic analysis (testing) and static analysis (model checking).

Static Verification

Static verification is further split into two categories: system and behavior model. System modeling can further be split into static analysis and theorem proving. Of system modeling, static program analysis is the analysis of computer software that is performed without actually executing programs. For physical systems, this verification could be inspecting the components for any mechanical or electrical defects before testing and integration. The other side of system modeling is theorem proving, which “provides mathematical reasoning on the correctness of system properties” [ScienceDirect]. Instead of looking for syntax errors in code or little nicks in a material, we are inspecting the content and analyzing theoretical guarantees given possible states of the spacecraft. An example of theorem proving for the ADCS system could be the spacecraft’s dynamics over time. We can prove that a spacecraft design with a permanent bar magnet is going to eventually damp out any tumbling, or kinetic energy, over time.

With a behavior model, we can verify with model checking. We can actually simulate the dynamics of a spacecraft and analyze the spacecraft’s behavior, the dynamics. The difference between theorem proving and model checking is a numerical simulation. With theorem proving, you can check that your feedback controller has negative real poles whereas with model checking, you can see that the controller behavior drives the spacecraft states to 0. Similar conclusions but behavior models offer more granularity.

Dynamic Verification

Dynamic verification, a verification that exercises the actual system, is broken down into symbolic execution and testing. For software, symbolic execution is the act of inputting symbols into a program and tracking the evolution of that symbol until the program produces its various outputs. There may not be a clear hardware analog for this type of verification. Testing takes in actual inputs, like actual numerical values in the place of variables for code or a physical load on a structure.

There are many, many physical tests that can be conducted on a spacecraft. Here are some examples by the subsystem:

• Payload: capture an image of an object and analyze the image with a post-processing algorithm
• Structures: compress a structure with the expected critical load to verify survivability
• Power: shine a sun simulator set to expected power intensity in orbit onto a solar cell to verify the expected voltage output
• Command and Data Handling: collect actual sensor data from the actual sensors
• Communications: transmit a command from a ground station at the defined frequency and modulation and receive this signal at the spacecraft radio
• Thermal: place integrated spacecraft into a thermal vacuum chamber and measure temperature distribution within the satellite when heaters are on
• Attitude Determination, Control, and Sensing: turn torque coils on and measure the resultant magnetic field generated

This list is not exhaustive but is representative of all the labs you did or will do with the Artemis CubeSat kit!