Model-driven design (MDD) of complex embedded systems is currently based on successive cycles of model changes, analysis and simulation. This iterative process suffers from a delay between applying changes on the model and knowledge about the resulting properties of the system. Current research on Architecture Discription Languages (ADL) in general, and AADL in specific, focuses primarily on tools and support for analysis and simulation, as distinct phases during design. We give an overview of existing work on AADL, and illustrate though a case study the opportunities for a novel, integrating research domain on ADL.
Model-driven design (MDD) helps system architects master the complexities
associated with the development of large and multi-concern embedded systems.
Architecture Description Languages (ADL) are hereby a primary way to model
the system components and their interactions. ADL specific analysis and
simulation tools applied on these models can estimate the properties and the behavior
of the final system, and thus predict if the system will meet its requirements.
Deviations between analysis and simulation results on the one hand, and
expected properties and behavior on the other, lead to model changes. As such,
the design follows an iterative scheme. Changing the model implies changing
the properties of the system, be it functional or non-functional. However, the
relation between a model change and the resulting properties is often unclear
until the subsequent analysis and simulation phase, making this iterative cycle
unnecessarily long. There is a clear need for tools able to seamlessly integrate
the modeling, analysis and simulation phases as to assist the architect in
decision making through direct feedback on model changes. Formalization of domain
knowledge and architectural patterns are prime concerns in this context. This
paper identifies the need for research addressing these concerns, and does so in
This work has been carried out as a part of the Condor project (http://www.esi.nl
Projects->Condor) at FEI company under the responsibilities of the Embedded
Systems Institute (ESI). This project is partially supported by the Dutch Ministry
of Economic Affairs under the BSIK program.
2
the concrete context of the Architecture Analysis and Design Language (AADL)
[
This paper is organized as follows. Section 2 gives an overview of the current work on AADL. Section 3 introduces an example used to pinpoint the current technical barriers, and is a first incite towards more intelligent tool-support. In section 4, we discuss our current ideas and provide a possible roadmap for future research. Conclusions are drawn in the final section. 2
Four research domains applicable to AADL are currently under active
development: front-end processing, code generation, analysis and simulation. Figure 1
shows a classification of the most important initiatives, which are discussed next.
OSATE [
Only minor integration between the different domains is noted. Intelligent integration of the available work to assist the system architect during the actual act of modeling is absent, and is why we suggest a fifth domain on design support (see figure 1). Intelligent in this context refers to the availability of formalized knowledge and patterns specific to the embedded domain. Reasoning algorithms could apply this knowledge on the concrete, but potentially incomplete, models to deduct architectural suggestions, warnings and optimal properties. A more concrete discussion can be found under section 4. We present the extension of an existing OSATE plugin as an illustration of more integrated modeling support. It also identifies current problems with analysis on unfinished, declarative AADL models. AADL differentiates between system specification and instantiation. A system is defined as completely instantiable if: “the system implementation being instantiated is completely specified and completely resolved”. The tools presented in section 2 almost exclusively work on instantiated models, and thus complete with respect to the compositional and legality rules of AADL. They are incapable of gathering information from, and act on, declarative models.
(a) (b) 4 3.2
Dries Langsweirdt, Yves Vandewoude and Yolande Berbers
The case study extends OSATE’s bin-packing and scheduling plugin, which is an
implementation of the work done on partitioned bin-packing algorithms by de
Niz et al. [
Although the case study is limited, we noted the following four interesting
problems. First, the API of OSATE with respect to extensive manipulations of
declarative models could be much improved upon. One example is the asymmetry
between addition and removal of component types or implementations. For
removal, the programmer needs to rely directly on the Eclipse Ecore infrastructure.
Second, because of the AADL semantics, information can be scattered
throughout the declarative model in complex ways. Instantiated models do not have this
problem as such, because the relations between components are fixed and their
properties can be referenced directly. Gathering information on the declarative
model quickly results in multiple model scans, potentially leading to a
scalability issue in the current OSATE implementation. Finally, two forms of ambiguity
in the use of the AADL standard (first noted by Delanote in [
As mentioned in section 2, key to assisted modeling is formalization and embedding of domain specific knowledge and architectural patterns, together with appropriate reasoning algorithms, in the tools the system architect uses to construct ADL models. Concrete properties and interconnections of model components can as such be linked with corresponding analysis and simulation routines. The results of these routines, automatically invoked on each incremental model change, can be fed back to the architect in the form of suggestions on architectural changes. If appropriate, changes can be performed automatically by the tool, already illustrated in the case study. Note that, as stated in section 3.1 and 3.3, analyzing an incomplete model is a non-trivial task making analysis and simulation adaptation, or virtual model completion, a necessity. The first challenge, formalization, is in principle ADL-agnostic, and depends on the RT/E domain in general. Harvesting model properties and performing model changes on the other hand, depend on the legality and compositional rules of the concrete ADL. Both challenges are interesting tracks that can be addressed by the proposed domain on design support. 5
This paper discusses the need for more research focusing on support for the embedded systems architect during modeling, compared to analysis of a certain made choice. Through an AADL case study, we identified some of the existing barriers and defined a roadmap for future research.