Modeling complex embedded system designs - Embedded.com

Modeling complex embedded system designs

This week's Tech Focus Newsletter is on modeling complex embedded systems. High level modeling and visualization tools are of critical importance as today's embedded systems become more complex internally and must operate in ubiquitously connected environments that are complex in the extreme. In addition to these recent articles on modeling complex embedded systems, here are my Editor's Top Picks of other articles I have referred to often on this topic:

Device tree partitioning for multicore, multi-OS embedded software designs
Using application modeling and mapping for system-level performance analysis
Explore multicore power management with modeling
Tracing of the event flow in state-based designs
Using finite state machines to design software

If you are looking at using tools such as the Unified Modeling Language to help you look for the useful patterns and structures in your application environment and use them as a guide in your software development, I recommend Miro Samek’s article series: “A crash course in UML state machines.”

I find this topic a compelling one not only for its usefulness in complex designs, but because I am a sucker for any sort of high level graphical or other tool that allows you to map out a problem domain visually. I have used them since I was in grade school and through college to scope out the nature of any problem in math, engineering, physics, biology and even human relations.

This bias was further reinforced when I worked at California Institute of Technology as the staff technical writer and editor. I used that role as a way to get into classes and seminars from Dr. Richard Feynman as often as I could.

He was the Nobel Prize-winning physicist who came up with “Feynman Diagrams ” as a way of first mapping complex quantum particle pathways before applying equations to predict their behavior. In those seminars he always emphasized the importance of finding the underlying patterns in a system’s behavior before trying to solve a problem. Once you could diagram out the relationships, he would say, you were more than halfway to finding a solution.

But in case you are one of those who feel you do not need any such aids, I suggest you read “Trends in embedded software design,” by Michael Barr. He is a past editor of ESD Magazine and Embedded.com who was called in as a software programming expert to testify in a recent court trial against Toyota in relation to a Camry auto accident that caused the death of the driver.

“C is simply not up to the task of building systems requiring over a million lines of code,” he writes. “Nonetheless, million-plus lines 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. … A new programming language is probably not the answer either, across so many CPU families and with so many other languages already tried.”

Thus he predicts that that tools that are able to reliably generate those millions of lines of C code automatically for us, based on system specifications from modeling tools such as UML and state machines, will ultimately take over.

“You may not like the idea of auto-generated code today,” he writes, “but 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.”

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. If you want to see a calendar of topics for the weekly Tech Focus newsletter or have a topic you would like to see covered, 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 © 2015 UBM–All rights reserved.

7 thoughts on “Modeling complex embedded system designs

  1. “Generating C code is less than ideal for real-time systems, because there is no way to predict the execution time of a given statement. For real-time systems, it would be far better to generate assembly code where the worst-case execution time is known. I

    Log in to Reply
  2. “BobSnyder is right. While any one approach to modeling code has some problems, they all get some other things right. The bits and pieces of an ultimate solution are out there in the variety of tools and methodologies. Rather than some brilliant innovator

    Log in to Reply
  3. “@BobSnyder: I think that the concerns you raise about the generated C code are a bit exaggerated. I would highly recommend the article “The Pragmatics of Model-Driven Development” [1] by the modeling veteran and guru Bran Selic. Among others, he address

    Log in to Reply
  4. “I'm really glad to see the Tech Focus Newsletter devoted to modeling. The subject has been my main interest and focus for many years now (thank you Bernard for mentioning my “Crash course in UML state machines”).nnUnfortunately, I think that there is

    Log in to Reply
  5. “@Miro.Samek Interestingly I see the trend opposite: more and more code is been generated from models of various kinds. Even some industries, like e.g. automotive, rely more on generators, so do automation software with various kind of block diagrams etc.

    Log in to Reply

Leave a Reply

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