introduced in the UML profile for MARTE and its companion constraint language CCSL. 1. Introduction. The project-team Aoste promotes a model-driven engi-.
TIMESQUARE: a software environment for timed systems Benoît FERRERO, Charles ANDRÉ, Frédéric MALLET, Robert de SIMONE {benoit.ferrero,charles.andre,frederic.mallet,robert.de_simone}@inria.fr AOSTE Project – I3S/INRIA – University of Nice/INRIA Sophia – France http://www.inria.fr/recherche/equipes/aoste.en.html
Abstract TIMESQUARE is a software environment for modeling and analysis of timed systems. It implements the Time Model introduced in the UML profile for MARTE and its companion constraint language CCSL.
1. Introduction The project-team Aoste promotes a model-driven engineering (MDE) approach for embedded system design based on formal semantics, models and methods. The models we consider comprise Models of Computation and Communication (MoCC) and synchronous reactive formalisms (including GALS and multi-clock extensions). We apply these models in SoC design and we have developed software tools (K-Passa and TimeSquare) for describing and analyzing such applications. This presentation focuses on TimeSquare, which implements the Time model defined in the UML profile for Modeling and Analysis of Real-Time and Embedded systems [1] (referred to as MARTE in what follows) and the Clock Constraint Specification Language (CCSL) also introduced in MARTE. In this paper, we illustrate the usage and the usefulness of TimeSquare through the example of a simplified digital filtering application.
2. The UML profile for MARTE UML is a general modeling language with limited capabilities for modeling time aspects. UML can be extended (using profiles) with domain-specific concepts. MARTE provides support for modeling real-time and embedded systems. It has enriched UML with time-related concepts: instants, durations, timed events, timed behavior, time domain and clocks. The MARTE time model is described in a previous paper [2]. It deals with both discrete and dense time. It differentiates chronometric time (implicitly referencing physical time) from logical time. A clock gives access to the underlying time structure. An application can refer to as many clocks (chronometric or logical) as needed. These clocks may be interdependent and the existing relationships can be specified by defining CCSL clock constraints. A set of kernel constraints has been defined and composition mechanisms are provided to build rich and expressive constraints. Three categories of kernel constraints are considered: synchronous, asynchronous, and chronometric-related. A tool support is required to build, apply and analyze the composite constraints.
3. TimeSquare TimeSquare is a software environment, available as an
Eclipse plug-in. It offers four main features: 1) Interactive application of time-related MARTE stereotypes and clock constraint specification within a UML modeler (Papyrus); 2) Checking conformance with MARTE and CCSL; 3) Constraint solving (clock calculus) producing consistent time evolutions according to various simulation policies; 4) VCD viewer to display simulation traces as waveforms and interactive clock constraint highlighting. 3.1 Illustrative example This (simplified) application is borrowed from a video system. A digital filter reads image pixels from a memory, filters them, and sends output pixels out to a display device. One image is composed of LPI lines; each line consists of PPL pixels. The pixels are stored in words. A word contains PPW pixels. The pixel transformation (digital filtering) is defined by a dot product with 2L+1 coefficients: outPixel k
j L c j * inPixel k j j L
For illustration purpose, we choose PPW=4, and PPL=16. 3.2 Modeling with UML The application is described as two interacting components: a filter and a memory. The components communicate through their ports. The UML modeling starts with the definition of signal types: Pixel, Word, and Control. Only the first two convey values. Filter and Memory are also defined as UML classes. Ports are then attached to each class (component). The structure diagram in Figure 1 gives the connections between the components. Ports get (from filter) and inWord (from mem) are input ports. All others are output ports.
Figure 1: Structure diagram of the application 3.3 Introducing logical clocks In MARTE, a logical clock can be associated with any event. In our design approach, we consider events that represent changes of value on a port. CCSL clocks are a priori independent. Clock constraints must be applied to reflect the time and causal requirements of each component. Communications between components also induce constraints between the sender clock and the receiver clock.
To add time information to a UML model, we proceed in three steps. First, the profile MARTE is applied to the model. Then, the clocks are selected. Here, the classes Pixel, Word, and Control are stereotyped by «clockType», and all ports are stereotyped by «clock». This second step allows TimeSquare to take control of events occurring on the ports. The third step is the specification of the clock constraints.
(2)
3.5 Simulation and model tuning For a first analysis, we take account of all the clock constraints of the model, excepted constraint (5). The TimeSquare constraint solver generates the waveform presented in Figure 3. Dashed arrows and rectangles are optional adornments displayed by TimeSquare to highlight the effects of selected clock constraints. The dashed lines stand for precedence relations. As seen on the picture, the 7th inWord, received by filter just before the first eoL, is effectively used after an undesirable long delay. This behavior is functionally correct but not efficient since it requires excessive buffering. Constraint (5) has been introduced as a “back-pressure” to avoid inWord stacking up. Figure 4 shows the corrected design, which is both functionally correct and efficient in terms of buffering.
eoL outPixel 015.1
(3)
3 inWord 0.13 outPixel 02. 1.03 .02
4. Perspectives
(4)
3.4 Clock constraints Hereafter, we give the clock constraints related to the Filter component. They are written in their symbolic form. The textual form (concrete syntax of CCSL) is described in the TimeSquare documentation. ready inWord (1)
inWord outPixel /4
outPixel 0. 1.03 inWord 0.1
(5)
The user is guided in the definition of constraints and need not know the concrete syntax. He should rely on dialog boxes like the one shown in Figure 2, which illustrates the definition of constraint (3).
The current release of TimeSquare focuses on simulation. Since we have defined a formal operational semantics for CCSL, clock constraints are also liable to formal analysis. CCSL is a highly expressive constraint language, so that reachability is not decidable. At the expense of slight restrictions imposed to the CCSL kernel, it is possible to compile a CCSL specification into a finite state model representing the set of all reachable clock configurations. Model checking techniques are then applicable to this model. So, we plan to extend TimeSquare in two directions: opening to formal verification tools, and a better support to clock constraint visualization and traceability.
5. References [1] OMG. UML Profile for MARTE, beta 2. Object Management Group, June 2008. OMG document number: ptc/08-06-0 [2] C. André, F. Mallet, and R. de Simone. Modeling time(s). In G. Engels, B. Opdyke, D. C. Schmidt, and F. Weil, editors, MoDELS, vol 4735, LNCS, pages 559–573. Springer, 2007. Figure 2: Example of clock constraint dialog box Other clock constraints related to the Memory and the communications are omitted.
Acknowledgement TimeSquare has been partly funded by the RNTL platform OpenEmbeDD (http://www.openembedd.org)
Figure 3: A possible time evolution without constraint (5)
Figure 4: A possible time evolution with constraint (5)
