{"id":19289,"date":"2024-12-18T15:06:10","date_gmt":"2024-12-18T13:06:10","guid":{"rendered":"https:\/\/www.btc-embedded.com\/?p=19289"},"modified":"2025-06-03T12:38:28","modified_gmt":"2025-06-03T10:38:28","slug":"cloud-friendly-testing-for-of-model-based-software-components-with-docker","status":"publish","type":"post","link":"https:\/\/www.btc-embedded.com\/zh-hans\/cloud-friendly-testing-for-of-model-based-software-components-with-docker\/","title":{"rendered":"Cloud-friendly testing for of model-based software components with Docker"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

Toolchains in model-based automotive development projects<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

No doubt, model-based development (MBD) projects offer a lot of benefits for automotive embedded software development, especially in the mechatronics-focused domains. However, compared to classic software development which mostly relies on a compiler, maybe a build tool plus some libraries for testing, checks, etc., MBD is guaranteed to come with a heavy Windows-based toolchain from the vast MATLAB Simulink ecosystem.<\/p>

To complicate things even further, these toolchains are usually entirely different for each company:<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\"Cloud-friendly\t\t\t\t\t\t\t\t\t\t\t
Fig.01: Model-based Development Toolchain<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Consequently, there is no standard toolchain package or standard CI pipeline, let alone an off-the-shelf Amazon EC2 or AzureVM template. But we still don\u2019t want to be forced to install 10 different tools whenever we provide a CI runner or developer VM. We need a solution that is easy to use, easy to rollout to CI runners, and easy to maintain.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

\n\t\t\t\t
\n\t\t\t\t\t

Using Virtual Machines to ensure a consistent environment<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Virtual machines seem to be the perfect fit. They provide a nice, sandboxed environment and \u2013 when working in a managed solution like Amazon EC2 or AzureVM or applying tools like Chef, Puppet, Ansible or Terraform \u2013 you can prepare VM templates that can be rolled out at scale.<\/p>

This provides a huge benefit, as VM templates can be prepared by a central team \u2013 even allowing manual adaptions \u2013 and then be rolled out both as developer VMs and as CI unners. Keeping both worlds identical is a great advantage, especially when developers need to debug failed CI runs.<\/p>

However, the flexibility of VMs is also a big weakness: humans naturally seek the path of least resistance and if something can be solved by a manual tweak, we will utilize that. Consequently, it\u2019s hard to know the cause when the VMs suddenly act up after a roll out. Has someone forgotten an essential manual step? Or was the VM corrupted after the rollout \u2013 permanently modified by an application running inside it?<\/p>

Broken access rights, missing or modified environment variables, or a full disk due to missing clean up routines are just some of the many things that tend to go wrong when VMs are deployed at scale.<\/p>

This can be mitigated partially by applying a strict configuration-as-code approach; however, this usually requires additional management solutions. I\u2019ve worked in projects where the solution was a nightly reset of VMs, to ensure that their state doesn\u2019t stray too far from the original state, but in my opinion, those nightly resets were causing more problems than they solved.<\/p>

A system should either stay the way that I left it or be entirely ephemeral. But a mix of these concepts leads to situations where it\u2019s sometimes working great, sometimes slightly off, and at other times completely broken.<\/p>

And to make things worse, having VMs constantly active in the cloud is very costly, with an especially bad cost-benefit ratio at times where they are idling, as Windows tends to make sure that the CPU doesn\u2019t get bored. On the other hand, treating VMs for CI runners as entirely ephemeral (start on demand and discard after use) solves most of those problems, but also comes at a high price:<\/p>

  • Big delays due to slow startup times (usually over 1 minute)<\/li>
  • High resource consumption on startup (unrelated to the actual workload)<\/li>
  • Compute, Memory and storage footprint increased by OS<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t

    Solving the pain-points with Docker Containers<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    The pain-points described above are not entirely new. For these exact reasons, containers have emerged as a leading solution.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    If you\u2019ve never heard of a container, feel free to google for a textbook explanation or consider the following perspective:<\/p>

    You can think of a virtual machine as a house. An application can run inside a VM the same way you can live in a house. The house has its own foundation, driveway, plumbing, central heating and utilities. If you run applications at scale using virtual machines, you duplicate all of that.<\/p>

    Similarly, you can think of a container as an apartment. You can also live in it, but not every apartment needs its own foundation, driveway, plumbing, central heating and utilities. When running applications at scale in containers, you basically operate a big student residence. The cheap rent this concept offers is directly reflected on your cloud bill \ud83e\udd13<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\t

    This already mitigates the problem of costly resource consumption overheads. But containers can do so much more! They are built from a text file recipe (the Dockerfile), which is kept in source control (configuration-as-code). This is important: changing the container means changing the Dockerfile and that means a commit to your git repository. In other words: it\u2019s very easy to track changes and roll back a working state in case something breaks.<\/p>

    From the Dockerfile an immutable container image is built and stored in a container registry from where it can be accessed when needed. It starts up in a second, as the container shares the host\u2019s kernel instead of having its own full-fledged operating system. This enables pretty much native performance and a minimal resource overhead while providing a well-defined sandbox environment for apps running in the container.<\/p>

    The only disadvantage: container technology was designed for Linux-based operating systems. While it\u2019s also available on Windows, the experience is much smoother on Linux: This makes it harder to achieve environmental parity between CI and developer VMs (which are mostly Windows-based in automotive). But if anything, I would argue that a Linux-based container running your code using GCC is closer to your hardware target than a Windows server equipped with a Visual Studio compiler.<\/p>

    The only real deal-breaker can be the fact that your company\u2019s toolchain includes tools that only run on Windows. But there\u2019s a good chance that this doesn\u2019t affect you: given the rising demand, most tool vendors in the industry have added Linux support in the last five years.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

    \n\t\t\t\t
    \n\t\t\t\t\t

    Putting it all together in an example<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t\t\tNow that we\u2019ve established the benefits, let\u2019s try it out with an example! Let\u2019s consider a toolchain for a model-based CI workflow with MIL+SIL tests using:\n