The role of modeling tools in future embedded systems - Embedded.com

The role of modeling tools in future embedded systems

For most of my life I have used graphics as a way to model a problem facing me and working through, if not to a solution, to an organized structure that allows me to see a pattern that in turn leads me to an answer. It is something I used in elementary and high school to solve algebra and trigonometry problems and in college in virtually every subject: statistics, physics, biology, mathematics and engineering. As a writer I often create tree structures to sort through ideas and topics as I work on finding the best way to write an article. And on the World Wide Web – which at best is like a book with an index but no table of contents – I use such techniques to bring order out of chaos.

In most of my life as a technical journalist – and sometimes programmer and hardware DIYer – I have been surrounded by embedded hardware and software engineers I worked with who developed – as I did – their own personal ways of modeling the design problem facing them: component placement on a printed circuit board, gate-level blocks on an FPGA, software code structure on a microprocessor, or transistor level logic on an ASIC or system on chip.

Many of these techniques have become formalized, first in the form of simple state machine diagrams, and now with model-based development tools such as Simulink and Labview, and model-driven frameworks such as the unified modeling language (UML), the open source Quantum Platform and a variety of proprietary and domain-specific tools. .

Surprisingly, while most engineers have their own personal and often idiosyncratic ways of modeling problems, they’ve resisted these more sophisticated and standardized approaches and stuck to hands-on C programming. This has been possible in a world of world of 8-, 16-, and even some 32-bit dedicated, limited resource designs where code sizes and the complexity of the designs were modest in size and where interactions with external devices were limited.

But that is no more, according to Michael Barr, who will be the keynote speaker at the 2014 ESC/EELive! March 31 to April 4. He points out in “Trends in Embedded Software, ” that the trend is away from hands-on programming and toward more model-driven auto-generated code.

C is simply not up to the task of building systems requiring over a million lines of code,” he writes. “Nonetheless, million-plus line-of-code systems is where the demanded complexity of embedded software has been driving our programs for some time. Something has to give on complexity. Thus I predict that tools that are able to reliably generate those millions of lines of C code automatically for us, based on system specifications, will ultimately take over.”

This is an idea many embedded developers still do not like. But as Barr points out, “I guarantee that once you program for a state machine framework, you'll see the benefits of the overall structure and be ready to move up a level in programming efficiency.”

If you would like to get up to speed on some of the various model-driven development languages and their auto-code generation tools, register to attend 2014 ESC/EELive! There, Stephen Mellor and Bruce Douglass, two of the pioneers in the application of modeling languages and tools to embedded design, will be part of two wide-ranging conference tracks: “Software Architecture, Development and Design,” and “Embedded Systems Engineering.” Classes that I can recommend and which I plan to attend include:

Modeling Behavior with UML: Interactions and Statecharts
Dependencies in Adaptive Development
Adaptive Requirements Engineering

Both Mellor and Douglass have been contributors to Embedded.com, where we regularly cover the evolution and use of such modeling tools. To read more on this topic, check out theUML article archive on Embedded.com, as well as this week's Tech Focus newsletter on “ Taking on nextgen design challenges with modeling . ” Among the many contributions, several that are my Editor's Top Picks i nclude:

State machine shortcuts
From UML to embedded system: Is it possible?
Effective UML mapping for modeling state machines
Using model-driven development for agile embedded apps
Model-based testing of a state-machine-based PLC design

I would like to hear from you and see your ideas about contributing on this topic to Embedded.com. Do you totally reject the use of such tools in your work? Why? What tools are you using, not using and why? What is needed to improve their capabilities? Are the days of hands-on embedded C programming dead? Or do you agree with Michael Barr who expects “…there to be continued demand for those of us with the skills and interest to fine tune the performance of the generated code or write device drivers to integrate it more closely to the hardware.”:

Embedded.com Site Editor Bernard Cole is also editor of the twice-a-week Embedded.com newsletters as well as a partner in the TechRite Associates editorial services consultancy. He welcomes your feedback. Send an email to , or call 928-525-9087.

See more articles and column like this one on Embedded.com. Sign up for s ubscriptions and newsletters . Copyright © 2014 UBM–All rights reserved.

15 thoughts on “The role of modeling tools in future embedded systems

  1. Modelling is great for some applications, but it adds yet another layer of abstraction over what compilers, assemblers and CPUs are already doing.

    This is increasingly making it very difficult to verify anything.

    Today I was working with a multi-k-byte

    Log in to Reply
  2. While you may treat the code similarly regardless if it is generated or created manually, one main difference in modeling approaches is the generator itself: may I change the generator or is it fixed. Modern tools allow me to modify the geneators – so if t

    Log in to Reply
  3. Are you suggesting the use of custom generators rather than standardised generatation languages?

    The problem with custom generators is that they kill code reuse. Unless someone else uses the same tools you do, and the same specification language, they can

    Log in to Reply
  4. Yes, custom generators and then you have all the control.

    Sorry, but I don’t understand the argument on killing code reuse. With models and generators we can then reuse the models.

    (I basically follow here analogy to compilers; they killed reuse of assem

    Log in to Reply
  5. What about code sharing? For example there is all this open source stuff you have probably heard about.

    Code you write will not work on my custom generators and code I write will not work on yours. The only way sharing can happen is if we have standards f

    Log in to Reply
  6. (there was no reply button under the last comment so this comment is related to “Cdhmanning POSTED: Mar 11, 2014 4:27 PM EDT below)

    Yes, there are both open source and commercial modeling tools and code generators, a couple of good lists covering these to

    Log in to Reply
  7. That kills portability, makes more hard work and introduces more places for the generation tool to mess up.

    If you generate C then it is easy to test with tools like valgrind etc.

    C compilers are very good at generating code properly. Toolchain teams hav

    Log in to Reply
  8. If the model includes hard real-time constraints, and if the MCU's clock frequency is known, then it should be possible (but not necessarily easy) to generate ASM code that is guaranteed to meet the timing constraints. This would not be possible with C cod

    Log in to Reply
  9. An embedded system model need not be represented graphically. Any system composed of graphical objects and properties can also be represented in tabular format, where each table represents a type of object, each row represents a specific object, and each c

    Log in to Reply
  10. It seems to me that most of the comments so far corroborate the observation made in the article, that unfortunately “most engineers have their own personal and often idiosyncratic ways of modeling problems, that they resist the more sophisticated and stand

    Log in to Reply
  11. “…how to combine the generated code with hand-crafted code.”

    “…graphical modeling and code generation are mature technologies”

    I agree that modeling and code generation are the future, but it seems to me that if the modeling tools were FULLY mature,

    Log in to Reply
  12. I enjoy the commentary that results after I put together a package on topics like modeling tools almost as much as I do the initial work. This time especially I have found all of your comments useful in giving me more ideas about what to do on the site not

    Log in to Reply
  13. For an additional perspective on modeling, you might want to look at the history of CNC programming. The most widely-used NC programming language is G-code. But solid modeling tools such as Pro-Engineer, Inventor, Catia, and SolidWorks are now being used t

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.