Consider cutting out Orchestrator and Dispatcher from SIL app

[samparent97]

There is a lot of overhead built into the HIL repo for managing multiple users accessing a single hardware resource, the HIL. These include the Orchestrator and its Dispatchers.

In SIL mode, we will not have the app persist over multiple test executions so it would make a lot more sense to create a new app under hil/cmd/silapp where we cut out these higher level objects as they are not needed to run a SIL test. In this case, we would just pass in the test run as a cli flag.

Thoughts? @TylerStAmour @langei @BlakeFreer @AndrewI26 @CameronBeneteau

[BlakeFreer]

There is a lot of overhead built into the HIL repo for managing multiple users accessing a single hardware resource, the HIL. These include the Orchestrator and it's dispatchers.

In SIL mode, we will not have the app persist over multiple test executions so it would make a lot more sense to create a new app under hil/cmd/silapp where we cut out these higher level objects as they are not needed to run a SIL test. In this case, we would just pass in the test run as a cli flag.

I like this a lot. It separates the system into a program which runs a single test and another which manages ("dispatches") these processes. It would make it easier to run individual tests locally or in a GH action. Then the pi server can have its own dispatcher to manage resources (like the socketcan iface) or HIL when we get there.

You could even take this further and completely break out the orchestrator from HIL. Does it need to have any coupling to the SIL logic or can it be replaced by an OS-like scheduler that just runs the test process with knowledge of which resources it needs?

[samparent97]

Maybe a seperate topic there on your second paragraph, but that won't be till later down the line.

[AndrewI26]

I like this a lot too. When we use the hilapp to run the sil, there is so much bloat when all we really need is the sequencer to generate our results and canlink/results processor to generate our output files. And from a users perspective, there is a lot of unnecessary boilerplate Go code that we can certainly remove for SIL tests.

Being able to run a SIL test as a CLI command makes testing simple SIL stuff much easier and allows for easier testing with GitHub actions. We can just run a cli command and verify that generated reports/can traces match expected outputs. The