-
Notifications
You must be signed in to change notification settings - Fork 0
Home
The hysim repository, short for hybrid simulator, is a way to model the hybrid control system interfaces in advance of
building the entire system on real hardware.
This emulator will model the three types of nodes on the hybrid control system:
- Telemetry clients
- Control clients
- Pad server
An emulation will allow developers to test:
- Network communications
- Arming logic
- Control logic input/output logic
- Telemetry display/logging
All in advance of having a working system, with nothing but a laptop running a POSIX OS. They'll also be able to develop interfaces/abstractions for actuators so that real drivers can just be bent to fit those interfaces.
The goal of the emulator is to create working business logic without requiring real hardware. The emulated system can be used for any further prototyping, and also be given to propulsion members for verification testing (have them use and tell us if it does what they want).
Just a consumer of telemetry data. There can be an infinite number of these on the network and they can all consume the same data sent by the pad server.
Telemetry clients might do something simple like log data to a file or physical medium, or they can be more complicated and display telemetry visually/send alerts to other devices based on incoming telemetry, etc. The key point is that they consume telemetry data.
Control client nodes are able to issue commands to the pad server over the network. Only one controller is allowed to be connected to the pad server to prevent conflicting commands or malicious command centres that try to join the network after the system is set up.
Control clients can issue arming commands or actuate actuators. They are quite simple in that they only send commands over the network to the pad server and wait for a response indicating the success or failure of the command.
Control clients do not maintain any state about the actuators they control, or the current arming state. They only blindly issue commands and receive success or failure indicators. All state is maintained on the pad server so that there is only one source of truth and it becomes impossible to get out of sync.
The most complicated of the nodes. The pad server produces telemetry data which it must multicast over UDP so that all telemetry clients can receive it (and only one "send" operation is required). The pad server must also simultaneously handle commands from the control client and respond with success or failure. The pad server is responsible for maintaining system state, such as the current arming level, and checking if arming permissions are sufficient for incoming commands, etc. It does all the error handling/permission checking.
Pad servers should prioritize handling control commands before doing anything else. If dangerous pressure spikes are detected, it should also immediately abort the system by dumping the oxidizer. These are safety-critical events and must meet deadlines and have priority. In the example application it might be hard to implement this (since we can't really emulate interrupts), but a best attempt should be made. When the example is ported to NuttX, it should also make use of the RTOS features to achieve this.
It is theoretically possible to combine a telemetry client and a control client into one single node. This might be useful for control units which have a display, or perhaps LED/buzzer indicators at certain arming stages or at certain pressure/temperature ranges. This is the approach that should be taken in such a case. Please resist the temptation to implement a control client which itself maintains state about the current arming level or actuator states. Instead implement a telemetry client interface to get that information. This will make sure your control unit is always synced with the real control system state regardless of power issues or unstable connections.