Electronics Engineering Trends in 2005 Series

Embedded software developers have a reputation in the software world at large for being a bit slow. Not dim, you understand—everyone knows we tackle sophisticated problems—but slow to pick up on new software tools and languages.

This accusation has some truth. Today, some 77.2% of projects use some C, another 46.2% use assembly language, and 44.2% use C++. (The numbers add up to more than 100% because a project may use more than one language.) Hardly anyone in IT would think of writing in a language as close to the machine as C, let alone assembly code, these days.

We embedded developers would quickly retort that our problems have to be very efficient, very small, and in many cases, very fast too. Moreover, we need to have complete control over the generated code, and that is taken away from us by programming language compilers.

We recognize, of course, the advantages of writing code at a higher level of abstraction. After all, studies for nearly thirty years have shown that we can write the same number of lines of code per day, irrespective of the language. Since we get more functionality for a line of C++ than for a line of assembly, it stands to reason that we can increase productivity if we use a more abstract language.

Meanwhile, the IT folks are moving towards higher-level-still languages such as the Unified Modeling Language. The UML has made some headway in the embedded market, mostly as a sketching language, or as a blueprint for further software development. It is also an executable language, with state machines for modeling concurrent behavior and exploring synchronization issues, which would make the language appropriate for us, but it is so far away from the machine it seems even more unlikely than using C++ in the embedded space.

But what if you could generate small, efficient code? And what if you could have complete control over it? That would give us the advantages of a higher-level language while still meeting our performance constraints. Enter Executable and Translatable UML. xtUML is a subset of the UML with a defined execution semantics that constitutes an executable language that can be translated, according to a set of rules, into an implementation.

The rules are completely open. If you can code it, you can write a rule to code it. Moreover, any rule we write can be used on the next project too, so our model compilers get better and better, just as programming language compilers have done. You can even write rules that generate silicon. This gives the embedded engineer total control over the generated output.

This Crystal Ball sees significant uptake of xtUML over the next three years. There are efforts underway in telecommunications and in the Object Management Group (the body that brought us UML) to standardize on executable UML. These standards will make the technology accessible to more embedded engineers, and the combination of a higher level of abstraction to increase productivity, state machines to capture concurrency, and total control over the generated code make xtUML irresistible.