I recently listened to the November 21, 2023, episode of The Agile Embedded Podcast. In this episode hosts Jeff Gable and Luca Ingianni interviewed their guest Max Kolesnikov about Model Based Development (MBD). If you’re interested in the development of embedded systems and haven’t listened to The Agile Embedded Podcast before, I highly recommend it. Jeff and Luca do a great job.
Early in the episode, Max made a key statement about model-based development: “model-based software development is a practice of leveraging virtual models in the software development process.” Put another way in model-based development, the model becomes a first-class design artifact. In my view, that has several implications:
- The team will develop a formalized model or models of the system or key portions of the system.
- The team agrees that the developed model(s) are the shared source of understanding of the system.
- There will be no talk of “my model”. It’s “our model”, and the team iterates and refines the shared model(s) together.
- These models will be part of the team’s design deliverables.
- As such, they’ll be formally controlled in a revision control system, product data manager (PDM) or some other document control system.
- As Max notes, for software systems portions of the design (i.e. source code) will be generated directly from the model.
It’s Not Just About Software
The podcast is about embedded software development, the discussion focused on code generation as it should. However, I would like to point out that model-based design is not limited to software development.
- First of all, I would argue all design is based on models. You have to have some concept of how a system will work in order to design it. Typically, this is limited to an informal mental model. Each team member will have their own mental model, and those models will all be different. MBD is about moving those models out of our heads, formalizing them, and getting everyone to agree on them.
- Design architecture is one form of model-based development that is not specific to software. When we architect a product or system, we develop high-level, simplified models that inform the rest of the design. These are typically in the form of block diagrams. The architect or lead typically develops and documents these models, shares them with the team, and uses them to define interfaces and the structure of the system. Because these diagrams are low fidelity, they’re easy to generate and understand, but can’t be used to automate things like simulation or testing.
- The field of mechanical design engineering is particularly good at model-based development. Once that field moved from 2D drawings to 3D models, they moved to true model-based development. With 3D CAD models, mechanical engineers:
- Have an agreed upon, shared model of the system, typically stored in a PDM. In assemblies, a new part typically is designed with explicit mates to existing parts, formalizing the model and interactions between components.
- Automatically generate a considerable amount of the 2D drawing content directly from the 3D model.
- Use the 3D model for additional analyses such as:
- Finite element analysis (FEA) of stress in the parts
- FEA for heat transfer
- Generation of mass properties for the geometry that can be imported into kinematic analysis and simulation packages and used for simulation of motion. For example, the Robot Operating System (ROS) provides tools to import CAD and simulation your robot’s control algorithms with models of your robot’s mechanics.
Professional Grade Tools for Model Based Design of Software
Getting back to MDB and embedded software, the discussion in the episode centered on state machines, in particular the QP Framework from Miro Samek’s Quantum Leaps, and the suite of MATLAB, Simulink and StateFlow from the MathWorks, utilizing the Simulink Coder or the Embedded Coder toolboxes. These are some of the most widely used model development and model-based code generation systems in industry. Jeff, Luca and Max did a great job discussing these tools and all the benefits that they bring. I’m a big believer in Miro’s message about event driven programming and state machines for machine control, and I’ve used MATLAB since the DOS days. Of particular importance in the discussion is the use of models in embedded software development, specifically for prototyping and testing of machine control software without requiring physical machine hardware. Please do listen to the podcast for a good discussion of these tools.
Open-Source Tools for Model Based Design of Software
I work for an engineering services firm. As such, we have to be very careful about our toolset, because we deliver designs to our customers. For our startup customers, giving them models that require a $5k to $10k set of licenses from The MathWorks is a non-starter. If they have two developers that need to use the model, as well as a continuous integration server, that’s as sizable financial commitment. I think that’s the main reason that you don’t often see these tools commonly used outside of automotive and aerospace.
To round out the discussion of MBD and embedded software, I think it’s important to step back from the big industrial packages and think about what other sorts of tools might be used. Directly using physical constants and equations to generate coding constants is a simple form of MBD that is very useful. The Python COG module by Ned Batchelder is a great tool to integrate Python code into other languages. I’ve used it to generate stepper motor acceleration ramps directly from the motor step angle, the driver micro-stepping configuration and the mechanical design parameters (gear ratio, etc.). If the gear ratio changes, you change one number and voila, the stepper ramp table is updated. I’ve done similar for other portions of my control system firmware that are predicated on physical constants in the system. We’ve pretty much replaced MATLAB with Python for all of our technical computing, and COG allows us to extend this environment into code generation.
Simplexity Product Development, has recently moved from using Simulink as our dynamic simulation tool to using OpenModelica. OpenModelica is like having Simulink and the different “Sim” toolbox add-ons for Simulink all in one. While OpenModelica provides a graphical editor similar to Simulink, Modelica itself is a standardized language with implementations from many top suppliers like Wolfram, Maplesoft, Siemens, ANSYS, and Dassault Systems. Modelica provides a powerful simulation tool. It’s easy to interface with C source code, and the output model can be either a library or stand-alone executable, which simplifies integration with other tools like continuous integration pipelines to support automated, model based testing.
On Graphical Programming Tools
The final point I’d like to make is about graphical programming. Max made one comment that I found myself disagreeing with: “we specifically mean using a graphical modeling language because you can also create mathematical models with equations and without using any graphics. But in this context, it is about the visual representation of your algorithm”.
Graphical representations are in many cases the best way to communicate our thinking to other humans. Something like 50% of our brain participates in processing visual information, so providing a visual representation is very powerful. However, there’s a difference between visualizing something and using that visual medium as the programming language. There are various tools that can parse your code and generate the required visualization. I’ve done this for a proprietary state machine implementation to output Graphviz based visualizations and used those to visually verify state coverage in testing. I personally prefer to code in a language I’m already used to (C, C++, Python) instead of learning a new visual language, but then using visualization tools to help me make sure I’ve gotten it right.
Model Based Design is a great tool to have in your toolbox. By formalizing our thinking about our product, we can bypass a lot of potential misunderstandings that lead to costly rework and redesign, increase the speed of design and iteration, and eliminate error sources. If you’re interested in talking more about model based design concepts and how they could be integrated into your development process, contact us to learn more.