Home >

Hardware in the Loop in Containers: Why Docker is Hardware's Best Friend

Ari Mahpour- Watch Now - Duration: 27:43

Hardware in the Loop in Containers: Why Docker is Hardware's Best Friend
Ari Mahpour
Have you ever tried to set up a second or third test machine only to discover you forgot to document the first one? Are you one of those people who spend hours installing drivers and configuring settings on your test machine? With containerization we can set up our second or millionth computer in less than a few seconds. Containerization has become ubiquitous among software developers but barely known to the embedded community, let alone hardware engineers. In this talk we will review how to use containers to solve your automation frustration (and tackle world peace if time permits).
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

davek
Score: 0 | 6 months ago | no reply

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.

Oliver
Score: 0 | 6 months ago | no reply

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?

daveyboy17
Score: 0 | 6 months ago | no reply

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.

LeroyL
Score: 0 | 6 months ago | no reply

Thanks Ari