1
⎯⎯⎯⎯⎯⎯⎯⎯
* The work described here has been supported by various government agencies including DARPA, NSF, NASA, and various industrial partners, including Boeing, Lockheed-Martin, DuPont.
Abstract
The model-driven development of embedded com-puting systems is different from general purpose MDA, and it necessitates various capabilities from the tools. The paper gives an overview of the prob-lems, the distinguishing features of embedded soft-ware, and outlines the needs of a development process in support of the model-driven engineering of this class of systems.
1. Introduction
The field of embedded information processing sys-tems is clearly the next frontier in computing. While the early decades of computing were characterized by the mainframe computer that was followed by the revolution of the PC and the Internet, in the 21st cen-tury computation will be tightly integrated with the physical environment, giving rise to new generation of devices and industries.
Historically, computing evolved from the mainframe paradigm to the networked desktop and laptop com-putting, but the next stage, that of deeply embedded computing devices brings about a paradigm shift: computing becomes an inseperable part of the envi-ronment, and could potentially cause a major trans-formation in the industry.
Of course, embedded computing is not new (it has been used to land on the Moon, about 40 years ago), and existing examples are numerous. Automotive engineering and aerospace vehicles today are per-haps the most ubiquitous places for using embedded computers, but every consumer electronics device today has some sort of stored-program computer in it. Healthcare, medical systems, industrial automa-tion, and defense systems are also significant end-users that rely on embedded computing devices. Embedded computing became the universal ap-proach to system integration. In traditional systems
engineering we dealt with physical interfaces be-tween subsystems where interactions were governed by physical laws. Today, system integration often means putting a software layer on top of existing and diverse physical devices to achieve some end-to-end functionality. Many functionalities are implemented in hardware and software; e.g. traction control in cars involves both hardware devices and algorithms. It is instructive to see how the role of software has changed over the past forty years in aircraft avio-nics[1]. In the 1960s dedicated, primarily analog subsystems were used, with computing applied in specific, isolated cases (e.g. navigation). In the 1970s federated susbsystems appeared, with func-tionally integrated data processing, fly-by-wire con-trol systems being the prime example. This was the first time embedded computing started to appear in all avionics subsystems, although they were rarely integrated from a software point of view. From the 1980s aircraft-wide information integration started to appear, with on-board computing networked to im-plement various end-to-end functions impossible before. In the past ten years advanced avionics is increasingly being designed following a ‘system of systems’ paradigm, with embedded software being the primary integrator. In the mean time, the sheer size of the code has increased from 64 kbytes to Gigabytes. It is safe to say, that modern aircraft does not fly without software.
2. Some essential problems
There seems to be three, major, non-orthogonal, essential problem with embedded software as ap-plied in the monitoring and control of physical sys-tems.
1. The disconnect between physical and computa-tional design. Computing, by tradition, is inhe-rently mathematical: it deals with and manipu-lates (the physical manifestations of) symbols
Model-based Embedded Systems:
Past and Future, Challenges and Opportunities
*Gabor Karsai
Institute for Software-Integrated Systems
Vanderbilt University
according to the rules of logic[2]. But embed-ded computing has to interact with the physical world, and suddenly symbols become physical entities like voltages and forces that cause changes in a physical environment. In turn, the physical entities become data that influence the computing part. In order to achieve some de-sired functionality, the design of the physical and computational part cannot be separated, they have to be done together.
2. Interactions between software engineering deci-sions and their impact on physical (e.g. control quality) properties. When the software for an embedded control system is designed, we use an ideal control law design and make decisions about the software architecture, the real-time scheduling policies used, the datatypes used, etc., that will directly influence (physical) prop-erties of the controller implemented by the em-bedded computer. These properties include jit-ter, accuracy, latency, etc., and they could lead to noise, limit-cycle oscillations, etc. in the con-trol loop. To manage these effects we have to go back to our control law, redesign it, and then start the cycle again. Obviously, we need a bet-ter way of managing this cycle.
3. Interoperability and integration. As indicated by the avionics example above, embedded compu-ting devices are not separated from each other, rather they operate in an integrated framework. Hence the problem of system integration, where devices from various vendors must interoperate. The existing practice today is to use a shared communication entity (e.g. a communication bus) and assign its time-slots to specific func-tions (supplied by different subsystems). How-ever, this leads to very brittle designs and in it-self does not prevent detrimental interactions across subsystems. System integration is often verified via testing, but we need better tech-niques, as ad hoc testing may not discover all potential situations for failure.
The problems listed above are just the main chal-lenges facing the designers of embedded systems today, and the list is not comprehensive. Because of the integrated nature of embedded systems, the chal-lenges interact: for instance a powerful systems inte-gration technology (e.g. web services) could be an disastrous failure in solving the another problem (e.g. interactions between software design and the quality of control loops).
3. Model-driven Engineering for
Embeded Systems
Model-driven development has been used for em-bedded systems since the mid 1980s, when graphical tools for designing control systems started to appear. The general software engineering community dis-covered model-driven development and OMG codi-fied its mantra in the form of MDA since mid 1990s. However there were significant differences between the two, and this discrepancy has only broadened over time.
When model-based development was used in con-trol system design and development, the primary abstractions were that of the control systems engi-neer: signal flow diagrams, finite-state controllers, etc. In MDA, abstractions are more closely tied to the concepts of object-oriented analysis and design, as captured in the form of UML diagrams, and ap-plied to general purpose software. However, there are other differences as well, as indicated on the table below.
In summary, MDE for embedded systems seems to be a different process from MDA altogether: de-signers are not merely software engineers, but sys-tems engineer who (need to) understand cross-cutting issues.
The two major, widely used model-based tool-suites today that embedded systems engineers use are Matrix-X1 and Simulink/Stateflow™2. Both in-clude a graphical modeling tool that supports model-ing via dataflow diagrams and statechart diagrams, a simulation engine that allows execution of the dia-grams using some predefined model of computation, and code generators that produce code for embedded platforms.
While the tools are powerful, enhance engineering productivity, and are widely used, existing expe-rience indicates that further improvements are needed. Automatically generated code could be hard to understand if subjected to traditional code re-views. Furthermore, some specific constructs in the modeling language could lead to unbounded recur-sion in the generated code, that is not allowable in safety critical systems. Additionally, several aspects of development are not covered by the tools. For example safety analysis, fault analysis, test genera-tion, and many other activities are necessary, but currently only independent tools support them.
⎯⎯⎯⎯⎯⎯⎯⎯
1 Product of National Instruments, Inc. 2 Product of Mathworks, Inc.
3
Systems built using conventional MDA Embedded SystemsSystem “merely” computes with data System interacts with a physical environment Logical correctness is sufficient Correctness and timeliness are mandatory Dynamics is secondary Dynamics is primary
Resources are plentiful Resources are scarce Robustness is desirable Robustness is essential
Modeling covers software Modeling also covers physical world Formal analysis is desirable, not essential Formal analysis is required for certification “Small” design changes rarely have physical
effects
“Small” design changes may have major physical effects
Predictability/dependability is desired Predictability/dependability is essential Can be restarted May have to run for long periods without restart
4. An outline for MDE for embedded
systems
Below, we give an outline for an advanced MDE process for embedded systems. The outline follows the tradition development flow from models to im-plementation, and it lists a number of challenging problems.
4.1 Modeling
The primary issue to be addressed is modeling. Gen-eral purpose MDA uses the models as a ‘programs’ in a higher-level language to describe primarily the de-sign of the components and the architecture of the system. The modeling is based on UML, and it covers the static and dynamic aspects of the system, includ-ing the behavior of the components (on some level of abstraction).
We claim that for embedded systems we need at least two additional sets of models: models of the infra-structure (the ‘platform’) as well as models of the environment: both the physical hardware part of the system, and the external environment interacting with the system.
The environment of the system needs to be modeled, as the embedded software always runs in a physical context that has its own dynamics. In order to study and understand the impact of software design deci-sions in that context, we need a model for it. Argua-bly, the support for such integrated modeling is one of the reasons for the success of commercial tools: engi-neers are used to the fact the embedded system is tried out in a simulator first where the environment is mod-eled and simulated. Recent activities in the OMG, specifically the SysML effort point in the same direc-tion.
The infrastructure used by the embedded software needs to be modeled as well, because the overall
be-havior of the component-based system is influenced and ultimately determined by the platform it runs on. Whether a platform uses rate monotonic scheduling or a cyclic executive will influence the overall jitter, thus the effect of the platform cannot be ignored. In plat-form-based design we try to abstract away low-level platform properties, but in embedded systems it is often not possible.
There are several challenges related to modeling. First, we need to use heterogeneous paradigms. The most obvious example for such heterogeneity is the continuous time model typically used in the models of physical systems and the event-driven finite state models of computational activities, but there are many other examples. Even within one software system we often use heterogeneous modeling approaches be-cause various aspects of the design require different modeling approaches.
Such heterogeneity necessitates model integration: the understanding of how the various modeling languages ‘fit together’, i.e. how models expressed in languages with different, but possibly related semantics can be related to each other, and how they represent interac-tions between different aspects or partiinterac-tions of the system. We need conceptual frameworks and technol-ogies to solve problems like tracking dependencies across heterogeneous models, and determining trade-offs among design choices made and expressed in different models.
Second, the increasing complexity of embedded sys-tem designs necessitates support for design spaces in modeling. This means that the modeling technology should be prepared to represent not only ‘point’ de-signs, but also ‘sets’ or ‘spaces’ of dede-signs, where the particular elements are selected based in criteria like performance, power consumption, cost, etc. We need tools to represent and manipulate such spaces. In summary, modeling is done with languages and tools, that determine what can and cannot model. Arguably, MDE for embedded system requires a
mul-titude of modeling languages and approaches, but this diversity imposes novel requirements on the tools.
4.2 Platforms
Embedded systems involve an extremely wide variety of platforms, ranging from hardware devices like FPGS-s, general purpose CPU-s, DSP-s, through var-ious software platforms like RTOS-s and network protocols, to higher level component frameworks like Real-time CORBA. As advocated in platform-based design, each platform provides a set of abstractions and implements a set of services that the application running ‘on the platform’ can use. Simultaneously, it isolates the applications from the physical details of the platform implementation.
In the context of embedded systems, there is a prob-lem with this approach: the effects of platform im-plementation details cannot be ignored. In other words, a simple syntactic platform service interface is not sufficient anymore: the interface must be much richer.
Designers expect services from platforms, but also composition techniques that allow integrating compo-nents and allow reasoning about the composition it-self. Interfaces of platforms merely specify the syntax to use for accessing services but they rarely specify the resources consumed when an interface is used, or what the correct sequencing of operations on the in-terface is. We need formally described, semantically rich interfaces that capture what a platform does, what it costs, and how it impacts the entire system. In short, we need rich interface models.
To give an illustration [10] how current interface specifications are deficient: on an industrial project, a small change in an real-time system code lead to deadline misses, never seen before. The system was built using an ARINC 653/APEX RTOS that supports strict time-space partitioning. As the analysis showed, a low priority, non-critical task has started long DMA transactions on a PCI-bus, which did not finish until the end of the time partition, but when it did finish, already the new partition was running, with high-criticality tasks, that were seriously disrupted by the end of bus transaction. Obviously, we need models and analytical tools to detect and prevent such situa-tions which could have been missed by mere testing.
4.3 Analysis issues
Analysis is an inaliable part of the design process of engineering systems and the same applies to MDE of embedded systems. However, in MDE analysis could be done on the final artifact (i.e. the running system, as built), on the design models it was built from, or on
the specifications from which the design was de-rived. In all cases, the analysis process should yield results about the system, as it is implemented on a platform, and as it is executed in the context of an environment.
In an ideal case, analysis is automatic, and one only has to express the analysis questions (e.g. is this con-troller implementation stable?) and the tool answers. Unfortunately, this cannot be completely achieved yet. The problems are manifold. Analysis tools often use a different modeling approach than the modeling tools, hence the two modeling languages need to be reconciled. Analysis techniques often have scalability problems, and we need tool automation for automati-cally creating abstractions of models that are simpler, yet of the required fidelity. Finally, analysis results need to be re-expressed in terms of the original speci-fication, design or implementation, so the designer can take the necessary corrective action.
Another issue is that analysis techniques themselves could be heterogeneous, and they should be applied in an integrated manner. For instance, some part of the design could be analyzed using model checking very efficiently, while some parts are best analyzed using simulation. We need techniques to identify which parts are best handled by model checking and which by simulation, and how results from the two should be combined[4].
4.4 Generation and synthesis
In MDE, implementations are often automatically derived from (higher-level) models, not unlike as in the Electronic Design Automation (EDA) community. However, while the (hardware) EDA community has made great strides towards automating significant portions of the design process, the (software) MDA has not made similar advances yet.
The specific, distinguishing factor between MDA and EDA is that MDA has not addressed the ‘synthesis’ problem fully. Existing generation approaches advo-cated in MDA are typically ‘transcription-based’, i.e. imput models are rewritten into code, in a rather straightforward manner. The recently accepted OMG standard for model transformations [5] clearly reflects this point.
Synthesis, in MDE for embedded systems should indeed ‘synthesize’ an implementation based on the model. This activity is more complex than simple transformation, as it produces a platform-specific implementation that is optimized with respect to some criteria. In other words, synthesis merges ‘transforma-tion’ with ‘search’ to find an implementation that satisfies requirements.
5
Synthesis of embedded systems could also involve exploration of the design space. Here we assume that design models represent not only individual, specific (‘point-‘) designs, but also alternatives, over choices for components or subsystems. Such design models could easily represent product-lines, where each indi-vidual product is a reached by making specific choic-es. Now the synthesis can proceed by searching for the right set of choices such that the resulting artifact satisfies some non-functional requirement (like power consumption, or latency). This has been shown in [6]. In order to enhance MDE with synthesis capabilities, we need high-performance synthesis algorithms that rapidly produce high-quality, optimized designes. One way to implement synthesis is to use constraints to direct the search process; in essence the desired outcome (e.g. ‘latency is less than X’) should drive the model transformation process.
Synthesis introduces its own correctness problems: the result produced by the synthesis (search) may not be desirable with respect to some safety criteria. This can be handled two ways: either the synthesized arti-fact should undergo a post-verification process (and it that fails, constraints need to be added to the search), or synthesis process itself should be constrained, from the beginning, in such a way that it cannot produce an incorrect result.
When the embedded system produced by an MDE process is placed in a high-consequence application, it typically needs to undergo an independent certifica-tion process. Today, we don’t have a certificacertifica-tion process that is compatible with any sort of MDE. However, it is conceivable that the genera-tion/synthesis process could be augmented to auto-matically produce artifacts in support of certification arguments. For example, the DO-178B standard re-quires traceability from requirements to code – a model transformation component can automate part of this by explicitly constructing the traceability links from design models to implementation code.
4.5 Integration
Arguably the most challenging stage in the develop-ment of any complex system is the integration. This is especially true for embedded systems because of the inherently interlinked nature of the system: the inte-gration between the physical and the computational. In practice, we often face the problem that the hard-ware of the embedded system is concurrently devel-oped with the software, and it is unclear what the software developer can do while the hardware is not ready.
One promising approach here is model-based inte-gration, carried through in every phase of the MDE process. The key observation in model-based integra-tion is that if the models are valid and the system is built accordingly, the result will work as required. However, this can be achieved only if the models are complete, in the sense that they (also) model the com-ponent integration machinery used.
One can envision a continuous system integration process that starts with a collection of models that are executable and represent the entire system being de-signed. The architecture modeled this way should have the major elements and components of the final system (in the form of models), and the interfaces between the models are similar to the interfaces used in the final system. (In other words, we need to pay attention to high-fidelity interface modeling, early on.) Note that this early model-prototype could be used as a vehicle to refine the design and experiment with design decisions. As the design and implementa-tion progresses, elements of the model-prototype ar-chitecture are incrementally replaced by ‘real’ com-ponents, platforms, hardware elements, etc. as they become available. Eventually, the entire system is built from real ingredients only. We always have a system: in the early phase a full simulation, in the late phases a real implementation, and a mixture in be-tween. Note that the we should not abandon the early model-prototypes or the intermediate, mixed configu-rations. Rather, they should be maintained, used, and evolved as the evolution of the product dictates it, in a spiral-like fashion.
This model-based integration approach hinges on the availability of hybrid execution platforms that allow the mixing of simulations and real components, in a heterogeneous manner. While such execution plat-forms are the subject of ongoing research, approaches based on discrete-event systems seem like promising directions.
Another key element of such a model-based system integration technology is the tooling for maintaining, synchronizing, and managing design models, imple-mentations, configurations, tests, etc.; all of which can be considered as ‘models’ with complex, yet in-terlinked semantics. This recognition leads to the next topic: toolchains.
4.6 Toolchains
Commercially available tool chains usually provide a proprietary, closed tool platform and tools that cover all aspects of the development process. Naturally, the interest is to lock-in users, and offer as little integra-tability with other tools as possible. The practical
needs of MDE developers is quite the opposite: they need open, modifiable, and customized toolchains that could be adapted to the needs of the development effort, and it could evolve as the project grows. Both viewpoints have advantages. A single-vendor toolchain is clearly easier to manage, because the vendor takes up the responsibility for integration, while the completely open approach could be much more flexible. The open approach has the disadvan-tage that completely ad hoc integration could lead to chaos in the MDE process. There are some architec-tural solutions to mitigate the dangerous flexibility of completely open tool integration, as discussed in [7]. For building toolchains, we need a reusable, robust software infrastructure for solving the syntactic inte-gration problem. Tools should have open interfaces, preferably specified in the form of metamodels, and precisely defined semantics.
Arguably, the syntactic problem of tool integration is not a challenge anymore, with the availability of po-werful model transformation technology. However, tool integration on the model semantics level is still a major problem. Experience with different variants of the Statechart modeling approach and tools clearly indicates the need for the deep understanding of ‘tool semantics’ (more precisely: the semantics of the mod-eling language used in the tool). Unfortunately, the unambiguous, concise, yet analyzable specification of semantics (even for restricted domain-specific model-ing languages) is not a solved problem. Early expe-rience with semantic anchoring Error! Reference
source not found. shows an approach for describing
the semantics, but it is an open question how the au-tomatic semantic translation between models of ‘slightly’ different semantics could be derived (if at all).
4.7 Verification and certification
Verification and certification of embedded systems (and thus their software) is mandatory in safety-critical settings, but it is desired for quality and de-pendability in all embedded systems. Here, we should use the strong, mathematical meaning of verification: constructing an irrefutable logical proof that the sys-tem satisfies certain desired and specified properties under given assumptions.
In MDE, verification is performed on the models, and rarely on the actual implementation (i.e. the binary code). This immediately raises a challenge: how can we show that what the analysis tools ‘show’ about the models, does get carried over to the real system? Ex-isting requirements for safety critical applications (e.g. DO-178B) proscribe ‘verification’ on the code
level, which clearly does not scale, and it is an open question how model verification/analysis could be carried over to the code. Additionally, the verification tools (e.g. model checkers) should generate arguments (i.e. safety cases) for the certification process. The methods for doing this is an active area of research [9].
Interestingly, in industrial and safety-critical settings, the tools used to build a safety critical product should be subjected to the same rigorous certification as the end-product itself. For example, there are two sorts of ‘certified’ compilers for embedded systems: C and Esterel. This means that a safety-critical MDE tool-chain should be verified and certified as well — an open challenge to the research community.
5. The next 10 years
It is probably safe to say that embedded computing and smart devices that integrate the physical with the computational will continue to play an ever greater role among industrial products. One of the reasons is that such a mixture of the physics and computation offer new functionalities that we can’t achieve in any other way. Hence, there is a need to better design and development approaches, and MDE for embedded systems could well provide the answers.
It is probably also safe to say that model-driven ap-proaches today have not yet achieved their full poten-tial. With the exception of a few, commercially avai-lable model-based tool suites the embedded systems industry is not using model-driven techniques yet. One reason for this could be that often embedded systems include integrated hardware/software design : a territory where MDA has not been applied yet. On the other hand, there are a number of interesting re-search results and a lot of industry interest, but there are still very few industrial-strength, quality tool-chains available that would be competitive with the current ones on the market.
Open standards and platforms have proven their worth in the industry, and it seems the MDE tools and tool-chains could be benefit from similar efforts. The ques-tion is what level of standardizaques-tion is reasonable such that IP rights of tool vendors could be protected. Meta-model based tool integration and precise des-cription of tool semantics are probably the first steps towards such standardization, but one can expect new techniques in this area in the near future.
Other essential questions remain : what is a major challenge problem in the CS community (the veri-fying compiler) can be found in MDE for embedded systems, i.e. the verifiable model transformation tools
7
that ensure the correctness of the generated system based on the (verified) correctness of models. It is probably safe to say that these, and other, yet unk-nown problems will drive the research in the next decade.
References
[1] Personal communication with several aerospace engi-neers.
[2] Herbert A. Simon (1969). The Sciences of the Artificial (First Edition), MIT Press
[3] Personal communication with automotive engineers. [4] This concept is due to Prof. Bruce Krogh of CMU. [5] OMG standard on Queries,Views, and Transforms
(QVT), www.omg.org
[6] Neema S., Sztipanovits J., Karsai G.: Design-Space Construction and Exploration in Platform-Based De-sign, Technical Report, ISIS-02-301, June 24, 2002.. [7] Karsai, G., Lang, A., Neema, S.: Design Patterns for
Open Tool Integration, Vol 4. No1, DOI: 10.1007/s10270-004-0073-y, Journal of Software and System Modeling, 2004..
[8] Chen K., Sztipanovits J., Neema S.: Compositional Specification of Behavioral Semantics, Technical Re-port, ISIS-06-705, June 1, 2006.
[9] Rushby, J. : Just-in-Time Certification, 12th IEEE International Conference on the Engineering of Com-plex Computer Systems, pp. 15-24, 2007, Auckland, New Zealand.
[10] Personal communication with avionics software engi-neers.
