Nice presentation Ari. Your concept of Hardware In the Loop (HIL) is a little different than the typical use of the term but that's OK. (I'm used to the term HIL as it is applied to model based design and systems like those made by dSPACE that run in real time). Anyway, the concept of using containers for running the tests is already in use at some companies for running unit tests on embedded code. I can see how running containers directly on the target could be advantageous when the target is running an OS capable of running the container. Thanks for the effort you put into presenting this.

I like the idea of using containers for setting up the environment and there is this problem of repetitiously installing environments.

I still have problems seeing the benefit on separating hardware access using containers on the embedded device though.
I think software has to be written the way you suggest (seperate modules working together so the development team can work independently). This also has the benefit that it is well known which modules are affected in case of bugs.

But when the system is put together I need a fixed bundle for two reasons:
1) QA can not test all possible versions of different modules.
2) I do not want to answer questions like "Can I use this version of module A with this version of module B"

Where is the downside of compiling a modularized software for changing a component compared to working on the software in a container? In both cases I have a test bed for the component and usually I do not have to compile the whole application.

I still need all the cross compilers etc. for the container version don't I?

Great presentation, I think this trend from the software world into the firmware domain is definitely the future for embedded. I really like the idea of using micro-services instead of a single monolithic code base.

Thanks Ari