This trade is concerned with the selection of a controller component for the test harness. The controller is responsible for managing the various spacecraft protocols accessible via the spacecraft test interface, and enabling automated integration testing. The test harness architecture diagram visualizes the role of the controller:
Identify the key requirements that will be used to evaluate and compare the different options being considered and how they will be weighed against one another. These criteria might include factors such as cost, performance, schedule, risk, and other relevant considerations.
The requirements driving the selection of the controller are listed below. The interface requirements are pulled from the FINCH-Spacecraft-TestInterface
| ID | Requirement |
|---|---|
| HostBoardCompatible | SHALL be able to be integrated into a host board, to allow for the host board to route the signal lines from the umbilical and offer additional connectors for external power supply units, as opposed to using a complex wire harness |
| InterfaceSWD | SHALL be able to interface via SWD to remotely program and debug at least one MCU on the spacecraft, as verified through the datasheet. Two is better |
| InterfaceUART | SHALL be able to interface via UART to use a command shell on at least one MCU on the spacecraft, as verified through the datasheet. Two is better |
| InterfaceCAN | SHALL be able to interface via CAN to sniff telemetry on the spacecraft CAN bus |
| InterfaceUSB | SHALL be able to interface via USB to the host computer |
| GPIOAvailable | SHALL possess GPIO that can be used to control hardware mounted to the host board such as external power supplies and visual indicators |
| Familiarity | SHOULD enable the use of tooling already familiar to the team |
The candidates that are considered are listed below (in no particular order):