menu
A CubeADCS HIL simulation is enabled by changing the CubeComputer reference model in the simulation scenario to a HIL-enabled CubeComputer. (For Gen1, the HIL-enabled CubeComputer4 model should be used.)
To avoid having to recreate the entire simulation model, a script that performs the above substitution is included in the CubeSpace plugin for D2S2. The HIL Setup script will exchange the reference CubeComputer model in the currently loaded scenario with the HIL counterpart.
To run the script, press the Run Script button, 
, from the Main Toolbar. In the dialog window that appears, select the HIL Setup script from the list, and press the Run button.
Figure 1: Screen capture showing the Run Script dialog window, and selection of the HIL Setup script with default options
The CubeComputer(HIL) model object will communicate with physical CubeComputer using a hardware interface. The estimation and control processing is thus performed on the remote hardware. In absence of such a connection the satellite will simply propagate its attitude with no control signals.
For Gen1 HIL simulations, an FTDI USB/UART cable is required, connected to the CubeADCS. The CubeADCS must be powered on and running the CubeACP application. The system configuration of the CubeACP must match with the configuration in the scenario file (wheel sizes must match, magnetorquer properties must match etc.)
The hardware connection is established by changing the Connected property of the CubeComputer(HIL) model object to true (Figure 1).
Figure 1: Gen1 CubeComputer properties, showing HIL connection options
It is possible to perform a HIL simulation where the reaction wheels and magnetorquers connected to the CubeComputer in the ADCS unit are active and follow the control commands to match with the simulation. For this, the reaction wheels and CubeControl Signal must be switched on before connecting to the simulator. The Activate Actuators setting for the CubeComputer(HIL) must also be set to true.
The CubeComputer(HIL) model object will also report additional states to reflect the connected CubeADCS state:
| Model State Property | Description | Possible Values |
|---|---|---|
| ACP State | --- | --- |
| AdcsState | Current ADCS Run mode | AdcsOff, AdcsEnabled, AdcsSimulation |
| ControlModeState | Current ADCS control mode | Any of the control modes listed in the CubeADCS Firmware Reference Manual |
| EstimationModeState | Current ADCS estimation mode | Any of the estimation modes listed in the CubeADCS Firmware Reference Manual |
| ControlModeChangeNotAllowed | Status flag in ADCS state telemetry, to indicate if commanded control mode was not allowed | True or False |
| EstimatorChangeNotAllowed | Status flag in ADCS state telemetry, to indicate if commanded estimation mode was not allowed | True or False |
| HIL Setup | --- | --- |
| Is Remote ADCS connected | Flag to indicate if remote CubeACP is connected | True or False |
For Gen2 HIL simulations, either a FTDI USB/UART cable, or PCAN USB interface is required. The option (UART, CAN) is selected from the CubeComputer(HIL) model object's Interface input property.
Figure 2: Gen2 CubeComputer properties, showing HIL connection options
The hardware connection is established by changing the Connected property of the CubeComputer(HIL) model object to true.
For UART connections, the COM port may be specified prior to connecting, to match with the port where the USB/UART interface is plugged in. The COM Port setting may also be left open, in which case the connect action will iterate through all available COM ports until a CubeADCS is found.
Only the CubeSpace communications protocol is supported for CAN connections. When connecting using CAN, the CAN ID of the remote CubeComputer must be known. This is specified in the CubeComputer CAN ID property. Additionally the source CAN ID (with which D2S2 will identify itself) must be specified in the D2S2 CAN ID property. See Figure 2 as reference.
The Gen2 CubeComputer control program can run either in simulation mode, or in normal mode. In simulation mode, the remote CubeComputer control program will wait for a SimSensorRaw telecommand from the simulator before executing a single iteration of the ADCS task. In this mode, the CubeADCS thus acts as a slave to the simulator. A flowchart is presented in Figure 3 which depicts the operation of this mode.
Figure 3: Flow diagram of the sequence of processes simulated each iteration when utilizing simulation mode during HIL testing
In normal mode (the default, and preferred option), the ADCS task in the CubeComputer control program runs as normal, and the simulator synchronises itself to the control program.The control program will perform the same processing and communication to nodes as in real operation, and it is thus more representative of a real test. While using normal mode, if the actuators are connected to the CubeADCS and powered on, the wheels will spin up to the wheel speeds corresponding to the simulation values, and the magnetorquers will fire likewise.
The default mode is normal mode, however if simulation mode is required this can be enabled using the Force Simulation Mode setting in D2S2. In normal mode, if the simulator loses synchronisation with the control program, it will repeat the same simulation iteration, up to a maximum number of retries specified by the Maximum Sync Retries property. If synchronisation fails past this point, an error will be displayed, and the simulation will stop. It is important that the Run in real-time simulation setting is set to false in this mode, as the simulator needs to continuously poll the remote CubeComputer for it's execution status. Figure 4 presentes a flow diagram of this mode.
Figure 4: Flow diagram of the sequence of processes simulated each iteration when utilizing normal mode during HIL testing
The CubeComputer(HIL) model object will also report additional states to reflect the remote CubeComputer state.
| Model State Property | Description | Possible Values |
|---|---|---|
| HIL Interface | --- | --- |
| AdcsUpdateTime | Time that it takes for the simulator to synchronise to the remote CubeComputer plus the time it takes to perform communication. This value equals Sync1Time + Sync2Time + CommsTime | duration[s] |
| CommsTime | Time that it takes for communication between simulator and remote CubeComputer to conclude | duration[s] |
| D2s2UpdateTime | Time that it takes for the simulator's internal update (propagating satellite state, calculating sensor measurements) | duration[s] |
| HilUpdateMissed | Indication that the remote CubeComputer performed one iteration of the control loop, without simulator measurements | True or false |
| IsConnected | Indicates if the HIL connection has been established | True or false |
| LoopTimeDelta | Time inbetween simulation update iterations | duration[s] |
| RetryNeeded | Indicates if a simulation iteration had to be retried (either as a result of synchronisation error, or telecommand/telemetry error) | True or false |
| Sync1Time | Time that it takes for the remote CubeComputer to go from idle to busy state | duration[s] |
| Sync2Time | Time that it takes for the remote CubeComputer to go from busy to idle state | duration[s] |
| SyncError | Indicates that the remote CubeComputer did not change between busy and idle states in the expected way (or with expected timeout durations) | True or false |
It is useful for the simulator to be used in a HIL setup where the CubeADCS is commanded from an OBC (On-board Computer). This allows for verification of mission stages and operational scenarios. The OBC will typically command the CubeADCS in such a setup, to change modes and request periodic telemetry for logging. The control mode changes will cause the CubeADCS to react as if in flight, and the telemetry that is returned will be similar to what will be observed in flight.
Gen1 ADCS can only connect to the simulator through UART. The I2C or CAN (if populated) interface is available to the OBC. Gen2 ADCS can use any of the available communications interfaces to the OBC after the HIL interface is connected.
Although it is still possible to change control and estimation modes and set ADCS configuration and reference commands through the D2S2 graphical user interface in such a setup, it is logical that the OBC would perform such commanding instead. The D2S2 model object for the HIL CubeComputer will report the control and estimation modes that are currently used on the remote CubeADCS, regardless of which entity commanded the state change.
As it is neccessary to allow the CubeACP time to service OBC communications, it is important that the simulation settings has the Run in real-time option set when using a Gen1 ADCS or a Gen2 ADCS with Force Simulation Mode set to true. In the Gen2 normal mode the Run in real-time simulation setting should remain off.