jlucas9
commented
1 year ago Notes from 20220824 internal JSTAR brainstorm on hardware in the loop (HWIL) in NOS3
- HWIL
- What does this get us?
- Nothing obvious
- Test on hardware or test on software, mixing and matching causes timing and various other issues that will likely not reduce risk in any way or benefit the project
- Does the NOS3 component lifecycle (inspection, standalone checkout, flatsat, flight) resolve the concerns that drove this request?
- What do we lose moving to the implementations below?
- Options to implement
- HWLIB on the FSW side to link specific component applications up to hardware with others to simulator
- Currently only one target level flag exists which determines which HWIL version is built
- HWLIB still operates in simulator mode, but NOS3 simulated hardware simply forwards commands do the provided device on the actual hardware
- This may add some overhead, but enables possible NOS3 logging and manipulation of the data
- Let assume a simple scenario - UART device that's speak when spoken to:
- NOS3 Sim opens and maintains link
- FSW sends sim commands like usual
- Sim forwards commands to hardware, then returns response
- Need ability to configure for this or another option
- ^ Is that part of the boiler plate code you get making a new sim?
- More complex scenario - UART device streaming data:
- Simulator child task maintaining latest information in simulator
- Another scenario - NOS3 on a MiniZ (Zybo) trying to HWIL to an I2C device:
- Doesn't really make sense to use a C&DH board to run NOS3 since you can't debug or really trace issues out
- Timeouts
- Can we assume no "man-in-middle" components and does that fix it?
- What about components like the Cubic EPS that requires polled for ready first?
- Can we catch that data in sim before forwarding along?
- Somethings may just not be supported in HWIL
- Why do big missions do this?
- It's typically the other direction, actual flight computer talking to "emulated" components that provide data and do interface checkouts verifying timing, loading, etc.
- This is the FlatSat in the traditional SmallSat workflow
- Should follow up with Justin and Scott
- Middleware
- NOS Engine vs. ZMQ vs. other
- Complaints from some power users about closed source in NOS Engine
- Moving to something else means writing our own plugins or coordination tools
- NOS Engine Server, NOS Time Driver, etc.
- Should revisit speed tests that were done on NOS Engine
- May not need to ever change
- Just may need to patch as operating systems and packages change
- QEMU
- How does this help?
- This help with time sync across processor to simulated components
- Lower level emulation of the processor as well
- Does this cause more complexity than reduces risk?
Summary
- HWIL
- There is no obvious benefit without significant funding to develop emulators of components that are timing accurate and connect to the environmental data provider
- Recommend using a standalone checkout test to ensure development C&DH board can communicate before moving to a cFS application
- Middleware
- No reason to change this from NOS Engine
- QEMU
- Lower level processor emulation is always nice to have, but currently expansion of NOS3 is to streamline usability and this would only make things more complicated
- Still should be on the backburner for future improvements
How can NOS3 run with Hardware in the loop?
This may involve the HWLIB. Here is a diagram from Matt Grubb's Thesis:
Let's brainstorm some options here:
HWLIB on the FSW side to link specific component applications up to hardware with others to simulator
HWLIB still operates in simulator mode, but NOS3 simulated hardware simply forwards commands do the provided device on the actual hardware