Over the years, a highly popular feature at the annual Embedded Systems Conference has been classes on advanced system modeling tools. The tradition continues this week in Boston, with a list of classes and product offerings from the likes of Artisan Software Tools, I-Logix, Pathfinder Solutions, Popkins Software, Project Technology and Rational Software, to name a few.
The reason for their continuing popularity is simply that there has always been a core group of designers involved in projects at the leading edges of embedded design. Because of the complexity of the system they are working on, the size of the code or the need to ensure reliability, these designers needed the capacity of such tools to accurately model complex systems and all the interrelationships among diverse processing elements, software processes and physical interfaces.
Now, however, many of these challenges are being faced by developers in the mainstream of embedded design, and such tools should become increasingly popular, according to Alan Moore, vice president of software development at Artisan Software Tools Ltd. (Cheltenham, England), especially as their capabilities are enhanced to reflect today's software development realities.
Such models did not in all cases result in automatic code generation from a model of a system and thus correct by design. But their creation at least eliminated one possible reason that complex embedded designs would not work: improper and inadequate understanding of the system requirements and inaccurate modeling of complex systemsand all of the key interrelationships. "If you do not have a good idea of the various elements in a design and their interrelationships you are almost assured of writing code that will not work," said Mike Willey, vice president of engineering at Paragon Software Inc. (Plano, Texas).
And as any embedded designer knows, the best way to define the nature of a problem, the boundaries of the problem domain and the possible sources of error or incompatibilities is to draw a picture or diagram of the problem. However, the nature of the problem set is becoming much more complex, so much more is needed to define the nature of the system being designed than drawing on the back of a napkin or on a blackboard. Also, with the advance of 32-bit CPU into the embedded space, the kind of design that embedded developers can take on is almost an order of magnitude larger in terms of code size. The complexity of the programming has also increased, as has the possibility of both making errors in writing the code and through misdefinition of the system to be designed.
There is also the problem of creating code for designs in which system-on-chip technology is being considered, said Ross Ortega, vice president and chief technology officer of Consystant Design Technology Inc. (Kirkland, Wash.). Not only have system definition hurdles at the board or multiboard level now moved down to the chip level, he said, but the pressure to get the definition of the system correct the first time before actually committing to silicon has increased. So has the problem of hardware-software co-verification.
There is a real need on the part of the engineer or developer to be sure that he or she understands completely the nature of the system definition and relationships among the various nodes, said Bran Selic, senior methodologist at Rational Software Corp. (Kanata, Ontario). That's in order to know what algorithms and subroutines to commit to code in VHDL or System C or Handl C for generation of the silicon, and what to retain of traditional software form running on standard processors.
Many designs are also committing to multicores in the same silicon or on the same board, which creates the problem of proper system definition. Even in the ubiquitous cell phone, at least two processors — and two different kind of processors, at that — are becoming common, enormously increasing the system design complexity.
And in network processing applications, where SoCs with multiple processors and multiple boards running multiple SoCs are the norm, traditional methods of defining and mapping and then generating code are stretched beyond their limits, said Atash Desponde, chief technical officer and founder of Teja Technologies Inc. (San Jose, Calif.).
In such environments, he said, there are usually multiple process threads active at any one time for handling events in the data stream, in the management and supervisory planes and in the switching management environment. The only methodology capable of handling the job of mapping and testing such software environments and then generating the appropriate code, he said, are state-chart-based alternatives.
In all these applications a common theme is emerging, said Chris Kobryn, chief technologist at Telelogic North America Inc. (San Jose). It is that as important as is the process of writing the code, more so is the ability to correct definition and express it correctly in both hardware and software. This means engineers and developers really need to spend their time arriving at the correct definition and modeling of the system and ensuring that the code generated from that is correct.
Into this milieu of conflicting needs and requirements a number of modeling languages are being pushed to maturity. Some specific ones, such as MatLab, are becoming the lingua franca of some particular applications, such as in automotive and in mixed DSP-RISC designs in the wireless infrastructure, both for handheld devices and in the base stations. In their contribution to this week's In Focus software engineers, Dmitri Khijniak and Chirag Shah at Visteon Corp. — which supports the development activities of most of the major automobile companies — survey many of the alternative state chart approaches, their strengths and weaknesses, deriving some common "best practices" to derive maximum benefits from such modeling.
It is in this environment that momentum is being gained by industry-wide efforts to standardize on a common modeling language that works for both hardware and software, for enterprise applications as well as for embedded and small-footprint designs and for both nonreal-time and real-time deterministic systems.
Next stage for UML
Many of these pressures are finding expression in the efforts to move the one common modeling language specification, UML 1.0, to the next stage in its evolution after it started life as an effort to provide developers in the large system enterprise computing environment with better tools. Currently, through proprietary add-ons and formalized profiles, it has been extended to meet the requirements of a much wider range of engineering applications.
As some of the contributions to this week's In Focus illustrate, these include real time extensions to incorporate precise timing models and methods for modeling hardware and software; extensions to make what the state charts generate more testable; and additions that generate executable code directly from the models.
Due out early next year is the final draft of the UML 2.0 standard, which incorporates many of the elements of the proprietary add-ons and formalized profiles directly into the specification, according to John Hogg, embedded evangelist at Rational. "Right now it is pretty much of a balancing act," he said. "On the one hand, there is a need to provide a modeling tool that meets the current critical development needs of the engineering community. On the other hand, there is a need to not stretch the specification beyond the limits of its natural capabilities and make it virtually useless."
Artisan's Moore agrees, saying he has seen previous standardization efforts end up with something that virtually no one used, either because it was so ambitious and so broad it lost its effectiveness, or was caught up in internecine warfare between companies pushing to have their particular point of view dominate.
"From an environment in which there were half a dozen competing voices trying to bend the standard one way or another, things have become a bit more focused," said Moore. "There are now essentially two major groups vying for representation in the new standard. On one side there are those who want UML to add capabilities that address the critical needs of the developer community. On the other are those who want the new specification to be more rigorous and precise. "
In many ways, said Selic of Rational, these two groups have come together and have eliminated the dozens of proposed modifications to a much smaller subset of changes that are common to all of the critical user communities for real-time, precision, testability and direct code generation from model descriptions.
"I think the result will be a new UML specification that will truly be a useful tool to a wide range of embedded and enterprise computing developers," said Jim McElroy, director of product marketing at iLogix Inc. (Andover, Mass.). "It will also be a significant milestone on the way to an all-encompassing Model Driven Development methodology, as is being promoted by the organizations such as the Object Modeling Group."
