CC BY-NC-ND
0Available online at www.sciencedirect.com
DIRECT«
ELSEVIER Electronic Notes in Theoretical Computer Science 152 (2006) 175-190
www.elsevier.com/locate/entcs
Case Study: Model Transformations for Time-triggered Languages
Tivadar Szemethy
Institute for Software Integrated Systems Vanderbilt University Nashville, TN, USA
Abstract
In this study, we introduce a model transformation tool for a time-triggered language: Giotto. The tool uses graphs to represent the source code (Giotto) and the target (the schedule-carrying code) of the transformation, and has been implemented entirely using graph rewriting techniques. The meta-models of the input and the output were specified using standard (UML) technology, and the transformation itself as a programmed graph rewriting system (in GReAT). The approach illustrates how a non-trivial model transformation can be implemented using graph transformations, and how the results obtained here could be used for the formal verification of embedded systems models. The transformation developed here forms the first step towards translating high-level, domain-specific models (that use concepts of the time-triggered language) into analysis models (that use concepts from the language of the analysis, e.g. timed automata). Using a formal approach such as graph transformation helps ensure the correctness of this transformation process.
Keywords: Model Transformation, Graph Transformation, time-triggered, Giotto,GReAT
1 Introduction
Model-based development relies on models to describe the structure or behavior of the system under construction, as well as generators that synthesize applications from the models.
Models help the designer to understand and describe the system by focusing on different aspects and abstracting away the rest. Generators replace (or reduce) the tedious and error-prone task of hand-coding. Using model-based
1 Email: tiv@isis.vanderbilt.edu
1571-0661/$ - see front matter © 2006 Elsevier B.V. All rights reserved. doi:10.1016/j.entcs.2005.10.024
approaches has the additional benefit of having the system described in a mathematically precise formalism. This enables arguing about key properties in a formal manner, and proving the correctness of the design through formal verification. Note that models are naturally expressed as graphs, and thus many results from graph theory could be applied in the context of models.
However, ensuring the correctness of a model is only the first step: in order to preserve the properties established through modeling, the process of generating the end system must also be free of errors. In other words, the way the generators are specified should also be formal and suitable for verification.
This argument underlines the importance of model transformations, which could be realized via graph transformations, if the models are represented as graphs. Model transformation is an area receiving significant interest within and beyond the research community. This is illustrated by the ongoing standardization efforts lead by the OMG [1].
The ultimate practical goal is to provide methodology and tools for engineers, who will use it to design and produce reliable systems. Naturally, every engineering method has to prove itself in practice. This question is especially interesting for methodologies influenced by theoretical results.
The following paper describes an experiment for modeling and transforming a particular language for time-triggered embedded systems using graph-based techniques. Specifically, it introduces a compiler for this language that uses model transformations represented in terms of graph rewriting operations.
It is believed that the area this language is intended for (high-confidence embedded systems) is a prime target for the above formal approaches, and important lessons will be learned by such experiments.
In the course of this project, the following steps were taken:
(i) (Meta-)Modeling the input and output languages using UML
(ii) Identifying the problem to be solved by the compiler
(iii) Formulating the graph transformation to solve the problem
2 Modeling the input and output languages
The GME [2] environment was used to create metamodels for the source and target models. GME is a meta-configurable visual modeling toolkit: the metamodel (or paradigm in GME terminology) for each domain-specific modeling language (DSML) is specified using the UML-based MetaGME language. Then, models according to these metamodels can be manipulated via the GME user interface. Additionally, GME provides an API to access and manipulate the models as a network of objects and links. Each model element (object and
link) has a specific, corresponding type (class and association) defined in the meta-model.
Defining a meta-model for GME consists of the following steps:
(i) Define the elements and structure of the models in UML using MetaGME
(ii) Define visualization rules for the GME user interface through model aspects and assign graphics representations (icons) to model elements
(iii) Formulate OCL constraints enforcing well-formedness and consistency rules within the DSML
In the following sections the metamodels for the two languages used in this experiment (Giotto and E-code) are briefly described.
2.1 The Giotto time-triggered language
Giotto [5] is a time-triggered language for programming embedded systems. Giotto is designed for systems with periodic and multi-modal operation, e.g. control applications requiring periodic sensor readings, control law computations and actuator updates. Giotto systems might have multiple operational modes. In each mode, a different (possibly overlapping) subset of system activities (sensors reads, actuator updates, computation tasks) is executed. According to the time-triggered paradigm, all activities of the system must be strictly periodic, with possibly different frequencies in different modes.
Due to its time-triggered nature, Giotto achieves timing predictability, making it suitable for safety-critical real-time systems.
A Giotto system consists of the following entities:
Tasks are the basic functional entities. The behavior of a task is implemented in some external code (written in some procedural language). Tasks read sensors (and other tasks' output ports), perform computations and update their output ports and actuators.
Drivers copy data between task ports and physical devices (sensors and actuators). Drivers satisfy the synchrony assumption: they execute in zero logical time (i.e. they can be executed before the environment changes).
Ports are (typed) memory locations carrying the system's state and facilitating inter-task communication.
Modes are collections of periodic task invocations and actuator updates, along with their associated driver calls. Each periodic activity might have a guard condition, which is associated with its driver. Transitions between modes are enabled by (periodic) evaluations of mode switch driver guards.
Functionality (driver and task implementation) is provided in the form a ref-
erence to external code (e.g. C or Java).
A Giotto program describes timing constraints for the execution of its tasks: the definition of tasks and their rates in each mode, but carries no explicit scheduling information. It is the task of the Giotto compiler to find a suitable schedule satisfying the above constraints.
2.1.1 Modeling Giotto
We have created a visual modeling language for representing Giotto programs. A model in this paradigm represents a Giotto program, that can be viewed through 3 different aspects:
Physical (or environment): contains the sensor, actuator and task output port definitions along with their drivers. Port entities (sensors, actuators and task output ports) are atomic elements and have name and type. Drivers are represented as models (i.e. container entities) and they hold references to their input and output ports.
Tasks : container objects holding references to their input, output and private ports.
Modes : contain references to each periodic activity (sensor reading, actuator update or task invocation) and their drivers. Modes can contain mode switch driver calls with the mode switch guard conditions and destination modes specified.
Giotto's well-formedness rules are enforced using OCL constraints in the metamodel. For example, in Giotto a periodic activity's (e.g. task invocation) frequency within a mode must be a divisor of the mode's period. (in other words, each entire invocation period must fall within the mode). This can be formulated by the following constraint:
(self.parent()->oclAsType(Mode).period mod self.frequency) =0
Attaching the constraint expression to meta object Periodic in GME resolves the self reference. Periodic is a child of Mode, and they have integer attributes frequency and period, respectively.
Figure 1 shows two aspects of the model for the hovercraft03 example from the Giotto distribution.
2.2 The E-code schedule-carrying code
E-code is the language of the E-machine [6], which is a virtual machine mediating real-time interactions between software processes and the environment. The E-machine guarantees predictable timing and behavior, and it can be implemented as a lightweight virtual machine over real-time operating sys-
(a) The Physical Giotto model
aspect of a
(b) Mode definition from the model
Fig. 1. Example Giotto model
tems (RTOS). The basic concepts of Giotto and the E-machine are closely related, although the scope of the E-machine is much wider and not restricted to time-triggered systems only.
The E-machine defines the following entities:
Task a piece of application-level code implementing a computation. Its execution takes nonzero amount of real time, may take arguments from and writes results to task ports. A task can be preempted, but has no internal synchronization points.
Drivers are practically the same as Giotto drivers. In the E-code they are specified as two entities, a guard and a driver.
Ports are memory locations facilitating inter-task and task-environment communication.
E-machine entities are very similar to Giotto entities. The main difference is that instead of a set of timing constraints (the mode definitions in Giotto) an E-code program defines a strict task/driver execution sequence given by a series of E-code instructions:
Evaluate guard the if instruction provides conditional branching according to the evaluation of the associated guard.
Driver call the call instruction executes a driver, and the E-machine blocks until the driver finishes.
Schedule task the schedule instruction hands a task instance over to the OS scheduler for execution, along with its relative deadline, and the E-machine continues executing. The E-machine exerts no further control over the scheduling, but it assumes that the task(s) finish before the deadline(s).
Fig. 2. The E-code Metamodel
Future E-code the future instruction marks a block of E-code for future execution.
Jump a branching instruction to aid code organization (also makes encoding mode switches easier). This instruction is optional.
2.2.1 Modeling the E-code
The entire metamodel for E-code is simple enough to be shown in Figure 2: A Program contains port, functionality and instruction objects. Ports can be environment, driver and task ports. Functionality objects are Tasks, Drivers and Guards. Instructions specialize into the five kinds listed above: if, schedule, future, call, jump. schedule is a reference to a Task instance. Similarly, a call references to a driver instance, and the two conditional instructions reference to a Guard (future is also conditional by the default timer guard).
Sequencing is provided by the Next (and Then, for if) connections.
In order to get a model more suitable for future formal verification, read-write access to Ports by Functionality objects should also be modeled. The above metamodel could be trivially extended to contain port access information — it is omitted only because of the different focus of this paper.
Similarly to the Giotto metamodel, OCL constraints can be used to enforce well-formedness rules. For example, instruction objects must have at most one outgoing Next connection. (Requiring exactly one ensures periodicity, which is not a requirement for generic E-Code).
3 Translating Giotto into E-code
A traditional Giotto compiler performs 3 tasks:
(i) Verify the well-formedness of the source file (syntax checking)
(ii) Map the functionality and port definitions from Giotto to E-code
(iii) Generate an instruction sequence of driver calls and task invocations that satisfies the timing constraints given by the Giotto program
In our context of model transformation, i) should not be done at the transformation level, since the metamodel and the model editor provide the necessary facilities for it (the editing process is constrained by the metamodel and the OCL constraints).
As for ii) since Giotto and E-code concepts for functionality are very closely related, this task is straightforward.
The main problem is to implement iii). Before going into the details of the solution, we briefly describe the graph transformation tool used.
3.1 Using GReAT to transform GME models
The GReAT [4] graph-rewriting engine is a part of the GME toolset. It operates by matching parts of the source graph and creating/deleting/modifying parts of the target graph. The basic unit of the transformation is the rule.
Rules can receive and pass references to already matched elements (pivot points or ports). This way a complex transformation can be divided into (sequenced) smaller rules. Rules can also be organized into higher-level hierarchies by using rule blocks. A test/case construct is also provided for branching.
Procedural (C++) code snippets can also be included in rules, either as code for attribute manipulation or guard conditions for matches. The code accesses the models through GME's API.
Pattern elements are references to source and target metamodel entities. This implements strong typing, and GReAT recognizes and supports UML concepts in the metamodels such as inheritance: for instance, an object of a derived type will match in a rule where the base type is specified.
In addition to the objects and associations from the imported metamodel, GReAT users can specify temporary objects and inter-metamodel associations as cross-links. These objects and associations exist only while the transformation is being performed.
Specifying a GReAT transformation involves the following steps:
(i) Import the source and destination metamodels
(ii) Create the rewriting rules containing graph patterns using the imported
(a) Top-level block (b) createProgram rule
Fig. 3. Top-level block and first rule
metamodel elements
(iii) Define (implicit and explicit) sequencing for the rules using GReAT language constructs
(iv) Configure the transformation by designating source and target files and a starting rule
In the following sections, the explanation of the transformation will be given, highlighting the non-trivial parts.
3.2 The Giotto^ E-code transformation
Figure 3 shows the high-level structure and the very first rule of the transformation.
In the first rule (createProgram) the Giotto System object (contained by the Root folder) is matched and a corresponding E-code Program container is created. It contains a Guard (timer), which is part of every E-code program (used by the future instruction). A dummy jump instruction is also created and designated as last instruction - it serves as a helper in the subsequent instruction sequencing. Another program object Tmp is created (will be used to store temporary objects during the translation), and an AttributeMapping code block is used to set the object names.
3.2.1 Mapping functionality definitions
Next, (as shown in Figure 3(a)), the System and Program objects are passed to the AddFunctionality ruleblock. The rules within will match all functionality definitions (Tasks, Drivers and Ports) in the Giotto model and create the corresponding E-code entities. To aid further processing, Crosslinks are also created between the corresponding entities The schematics of this block is
(a) Block AddFunctionality (b) Block Giotto2ECode
Fig. 4. Two blocks from the ruleset
shown in Figure 4(a).
3.3 Generating sequenced instructions
Next, the Giotto2Ecode block generates the E-code instruction sequence implementing the Giotto program. This consists of the following steps:
(i) Call the initializer driver for each port (memory location)
(ii) Append a jump to the sequence - this will eventually be set to point to the beginning of the start mode
(iii) Match each mode, and generate the instruction sequence for it
(iv) Set the jump (from step ii)
The block is shown on Figure 4(b).
The first step is trivial: match ports in the Giotto model, find their associated initializer driver (using the CrossLinks generated during AddFunctionality); generate the driver call and append it to the instruction chain.
3.3.1 Compiling a Mode
This rule-block is the heart of the transformation. Giotto timing constraints are given the following way: each mode has a Period, which is a duration (in msecs). Each activity within the mode has a frequency, relative to this period.
For example, if PeriodM = 600 and task tA has the frequency of 3 and tB of 2, then tA has to be executed once every 300 msecs (at 3.33Hz) and tB has to run at 5Hz (every 200 msecs), while the system is in mode M.
To generate a suitable schedule, the basic unit size has to be calculated, which is the GCD of the individual activities' periods. In the above example, those are (200, 300) and GCD(200, 300) = 100, so the basic time unit for this
Fig. 5. Example E-Code sequence
mode is 100msecs.
An E-Code sequence implementing this example is shown in Figure 5: scheduling a task involves
(i) evaluating the task driver's guard condition, and if it is true
(ii) executing (calling) the driver and
(iii) handing the task over to the OS scheduler
During the first time slot, both tasks are (conditionally) scheduled, and the E-Machine suspends for 100ms while the tasks are running. The next 100ms time slot is empty, and the E-Machine waits for another 100ms. At 200ms, tB needs to be scheduled, and subsequently at 300ms tA. Then, tB needs to be considered again, at 400ms. The time slot at 500ms is empty, and the period restarts after that. The subsequent future instructions can be optimized at a later stage.
In the figure, solid arrows represent instruction sequencing, and dashed arrows show Then branches.
Compiling a mode into an E-code instruction sequence involves several additional steps (e.g. port copy driver calls between task invocations). Describing these steps by graph patterns is trivial, since each object is mapped onto a simple instruction sequence, and their order (among the same class of objects) is not relevant.
The main problems are a) calculating the unit size and b) generating the required number of time slots. Giving the patterns to generate the if - call -sched sequences for each activity is easy, once the right time slot is identified for them.
3.3.2 Calculating the unit size
This problem is solved by implementing Euclid's well-known GCD algorithm in a recursive rule-block.
IJVT ' TmeD II.: + MOB ProD --Ufo P">n - llF"
p«pcessGCDLßt
Maintain Sum
Compilings Mod»
1 Call the Cop^Dnver for all Outputs usad in this mods
2 calculate the-: unit sizs (GCD of nil panoiiftroq)
3 Create an entra variable to accumulate the unit sum (halps to keep track Mien ijonnirflinri modes iier.'ilwoly}
4 Generate each mode Tisader'fa IuLuk.' mstr calling Uio noxlunit)
(a) CompileMode block
(b) GCD implementation
Fig. 6. CompileMode and GCD blocks
First, the set of activity periods is created (periodM/frequency.¿) for all activities of mode M. These are stored in a temporary Program model as future instructions (using the integer attribute of future). This is done in rule populateGCDList, shown in Figure 6(a)).
Then, two numbers (a, b) are selected, their GCD is calculated, and the numbers are deleted from the list and their GCD inserted back. The rule block implementing GCD(a,b) is shown in Figure 6(b). The ruleblock contains a reference to itself (GCD): this is a way to implement recursion in GReAT. It terminates when it is no longer possible to select two objects from the container: there is only one present, which must be the GCD.
3.3.3 Generating code for the time slots
As we had seen in Figure 5, implementing a Giotto mode requires generating code for period/unitsize time slots.
Within each time slot, we need to generate instructions for ti if the beginning of periodi coincides with the beginning of the current time slot.
In order to achieve this, we create yet another temporary variable (called Sum, similarly represented by a future instruction in Program Tmp) at the beginning of CompileMode (inside rule MaintainSum in Fig. 6(a)).
This variable represents the "timeline" of the mode: it is incremented by unitsize on generating each time slot, and we keep adding new time slots until Sum = Period M.
The structure of rule-block AddUnits is shown in Figure 7(a)
AddUnits is invoked with matches for (Mode, UnitSize, Prog). AddUnitHeader creates the future instruction for duration UnitSize. PeriodicActions rule will match those activities within the mode whose periods start at the same time as the current time slot (maintained in Sum). This match is implemented by a GReAT Guard condition, which is a boolean C++ function on the matching objects' attributes.
(a) Block AddUnits
(b) Test case NeedMoreUnits
Fig. 7. Ruleblocks generating time slots
The pseudocode for the Guard is as follows: int unitsize, timeline, period, freq;
unitsize = GCD.When(); timeline = Sum.When(); period = Mode.period(); freq = Periodic.frequency(); timeline -= unitsize; /* Sum is always one unit ahead */
return ((timeline mod (period/freq)) == 0);
GCD, Sum, Mode and Periodic are references to model object instances matched by the pattern within the rule. The rule matches if all the pattern elements match AND the Guard evaluates true.
Then, sub-block AddUnitContent generates the if - call - sched sequences for all the matching activities. These sequences are inserted before the future instruction marking the end of the time slot.
Finally, test case NeedMoreUnits (shown in Figure 7(b)) compares Sum with Periodu. If Sum = Periodu, (case notFinished) then the matching (Mode, UnitSize, Prog) triplet is passed along to a reference to block AddUnits (the parent block of the test case), implementing recursion. If the other test case matches (Sum = Periodu), no matches are passed and the recursion stops.
3.4 An E-Code program generated by the translator
Figure 8 shows the program generated by the translator for the hovercraft03 model, based on the example from the Giotto distribution. (Parts of the Giotto model are shown in Figure 1.)
The Functionality objects ( Guard, Driver, Task) mapped by the transformation are grouped along the top.
^Snardj [ DrV ) ^ Dry j ( Pre ) ( Dry j ^task J (task j ^ Dry j
timer copv_real_port copy_bool_port real_zero HovercraftWindowhovercraft.Error dummy dummy
^Gnardj
j call [-»j call I-call |--j call |-call |--j call | '| cal7~[
j Jump j* j >j call |t 'j call
Jump copy_tum ' copy_thr
init_v^nndQW init_errorAngle initjurn
nit_errorY i lit targetDi recti on
IZT 's 1 :EEE
leftMotor leftMotor idleTask
I if [tttJ.^J ca" I ' ^ Future I
-catl j-call j—
st copy_targetDi recti on copy_errorY copy.
S F=Gi]
_errorAngle | copy_error)
--çr\r-.....JT! :|T~| ,.„7-■
^ rightMotor nphr.'iotor getPos_getPos tovercrafiEfror c!!e_0
getPos getPos hovercraftEnror icf!e_1
Fig. 8. The generated E-Code program for hovercraft03
The instruction sequence starts on the second line by calling the initializer driver for each port.
Then, a jump instruction points to the beginning of the startup (and only) mode. On the third line, port copy driver calls are performed, implementing the necessary task output ^ task input copies so that tasks can be launched later. These instructions run at the beginning of each mode.
Unit-0 of the mode is shown on the fourth line. It has two ActuatorUpdates (guarded driver call) for leftMotor and rightMotor. Both have the frequency of 1. These are mapped onto if ^ call sequences.
Additionally, the mode has a task invocation (idleTask) of frequency 1. This task has no driver (thus no guard), and is mapped onto a single Sched instruction.
Task hovercraft.Error has input driver getPos, and its frequency is 2, so it is scheduled in both time slots. It is the only activity in the second time slot (fifth line) since all the others have the frequency of 1.
The future instruction concluding the last time slot points back to the beginning of the period on line 3.
4 Broader context and related research
The experiment described here is part of a broader research effort aimed at the translation of high-level, domain-specific languages into analysis models using model transformation. Analysis models use concepts from the analysis domain, such as timed automata and hybrid systems, and can be verified through model checking. The approach was demonstrated in a recent paper
Translating the high-level model onto a platform-level model (instruction sequence in this particular example) is the first step in this approach. Having a precise description of this lower abstraction level in the form of an explicit plat-
form model enables further translations towards more precise analysis models. The concepts of platform-based design are similar, and [8] gives a good articulation of the platform concept. In their approach, the authors use the same modeling language (Metropolis) to describe all abstraction layers in the design.
The aim of platform-based design is to find a platform instance in the design space best fitting the requirements. The properties of the particular instance are well known, since it is composed of lower-level models using well-defined composition rules.
In our work, the platform is given, and the problem is to map a DSML (time-triggered Giotto) models onto platform-level (synchronous, sequential E-Code) ones. In both approaches, a platform is a collection/abstraction of HW/SW services provided for the higher-level layers.
4.1 Graph transformation (GT)
Generating analysis models using GTs on UML-based models is an area gaining more and more attention. One particular problem is bridging the semantic gap between UML notations (esp. regarding dynamic behavior) and the rigorous languages used in formal analysis and verification.
The MetaEnv toolbox [9] illustrates an approach to overcome this problem by assigning precise semantics to visual notations using the HLTPN (HighLevel Timed Peti Net) language.
Another example is the VIATRA framework [10]. VIATRA is particularly relevant, since it aims for verification and validation via analysis models generated using GT. Here, metamodels are given as UML class diagrams, and the dynamic semantics are specified through a GT ruleset consisting of graph patterns. As a useful idea, VIATRA rewriting rules may contain an optional negative application condition graph. This is very helpful in specifying the "lack of" a pattern, which can be difficult in GReAT.
VIATRA proposes constructing a separate transformation for each analysis task, directly from the high-level model. In our experience this leads to tedious repetitions in human-generated transformation code: Typically all analysis models share a common structure dictated by the DSML semantics and the execution platform properties. This structure should be captured by an explicit, platform-level model accessible to all analysis-specific transformations.
Another problem regarding the GT approach is validating the GTs themselves, as the correctness of the analysis depends on them. This question is examined in general by J. Kiister in [11]. While not providing a general solution for this problem, his results serve as good first steps for further research.
5 Conclusions and further research
Having solved the problems introduced earlier, we can conclude that graph-rewriting based model translation is a viable approach to generate an explicit instruction sequence satisfying a scheduling problem given by constraints.
As opposed to a traditional compiler, this approach relies on the well-formedness of its input. As we had seen, this is not a problem,for the modeling languages and model editors are capable of enforcing well-formedness constraints.
This still highlights one major shortcoming of the pattern-matching approach used in the model-transformation language. Not matching a given pattern can happen for two reasons:
(i) The model is ill-formed (e.g. a mandatory entity is missing)
(ii) The model is well-formed, just does not contain the (not mandatory) structure the pattern is to match
Finding the reason might necessitate using several additional patterns just to verify well-formedness (i.e. one pattern for each possible error message or missing entity). These patterns basically describe the same structure repeatedly.
5.1 Further research
In the current form, the translation does not support Giotto mode switches, i.e. guarded transitions between system modes. The implementation of mode switches in E-Code requires the alignment of time slots within the source and destination modes. Giotto allows the same activities to be present even with different frequencies across mode switches, making the problem more difficult.
An additional task is modeling port access (driver/task read-write) at E-Code level. This information can be extracted from the Giotto model, and helps obtaining a more precise lower-level system model.
In the longer term, the models might be extended to accommodate recent Giotto and E-Code extensions and current research directions, such as distributed operation and dynamic linking.
6 Acknowledgements
The NSF ITR on "Foundations of Hybrid and Embedded Software Systems" has supported, in part, the activities described in this paper. The author also would like to thank the assistance received from Slobodan Matic, Giotto team member at UC Berkeley.
References
[1] T. Gardner et al. "A review of OMG MOF 2.0 Query / View / Transformations Submissions and Recommendations towards the final Standard" available online at http://www.zura.ch. ibm.com/pdf/ebizz/gardner-etal.pdf
[2] Ledeczi A., Bakay A., Maroti M., Völgyesi P., Nordstrom G., Sprinkle J., Karsai G. "Composing Domain-Specific Design Environments", Computer, pp. 44-51, November, 2001. The tool is available at http://www.isis.vanderbilt.edu/Projects/GME
[3] A. Bakay, E. Magyari. "The UDM Framework" available online at http://www.isis. vanderbilt.edu/Projects/mobies/
[4] Agrawal A., Karsai G., Shi F. "Graph Transformations on Domain-Specific Models" Technical report, ISIS-03-403, November, 2003. Available online at http://www.isis.vanderbilt.edu
[5] Thomas A. Henzinger, Benjamin Horowitz, and Christoph M. Kirsch. "Giotto: A time-triggered language for embedded programming." In Proceedings of the First International Workshop on Embedded Software (EMSOFT), Lecture Notes in Computer Science 2211, Springer-Verlag, 2001, pp. 166-184.
[6] Thomas A. Henzinger and Christoph M. Kirsch. "The Embedded Machine: Predictable, portable real-time code." In Proceedings of the International Conference on Programming Language Design and Implementation (PLDI), ACM Press, 2002, pp. 315-326.
[7] T. Szemethy and G. Karsai "Platform Modeling and Model Transformations for Analysis", Journal of Universal Computer Science, Vol. 10, Issue 10, 2004 pp 1383-1407
[8] Sangiovanni-Vincentelli, A.; Martin, G. "Platform-based design and software design methodology for embedded systems", Design & Test of Computers, IEEE , Volume: 18 , Issue: 6 , Nov.-Dec. 2001 Pages:23 - 33
[9] Baresi L., Pezze M. "MetaEnv: A Tool for Automating Visual Software Engineering", Technical Report, Universita degli Studi di Milano Bicocca, Dipartimento di Informatica, Sistemistica e Comunicazioni, Laboratorio Test e Analisi del Software.
[10] Gy. Csertan, G. Huszerl, I. Majzik, Zs. Pap, A. Pataricza, and D. Varro. "VIATRA: Visual automated transformations for formal verification and validation of UML models." In J. Richardson, W. Emmerich and D. Wile Proc. ASE 2002: 17th IEEE International Conference on Automated Software Engineering, pages 267-270, Edinburgh, UK, September 23-27 2002.
[11] J. Köster, "Systematic Validation of Model Transformations", Proceedings 3rd UML Workshop in Software Model Engineering (WiSME 2004), Lisbon, Portugal, October 2004.
