This plug-in offers some examples of modeling with SME. To access to these examples, right-click on the navigator view and select Example... (as shown on the following picture). Then in the window, select Examples-> Polychrony Examples-> Polychrony Examples or, if you use the TopCased Modeling Perspective, select Polychrony Examples-> Polychrony Examples.
The wizard creates, in your navigator view, a new project called “fr.irisa.espresso.sme.examples”, which contains five model (and graphical) examples and the Intrinsic Process library. There are three simples examples (Counter, Simple Hierarchic Automaton, and Watchdog) that we will detail in the following. A more complex example (Modem) is also provided, it is a library containing the modulator and demodulator part of a modem.
The Counter process constitutes a first simple example to see how to design a component with the Graphical SME editor. This process counts the number of times it is called since the last reset events.
To build this process, the first thing to do is to create an Interface Definition Diagram, and to add to it the declarations of the Input signal reset typed as an event, and the Output signal val typed as an integer.
Then, you have to create the Data flow Diagram (for example, by pressing the Dataflow Button in the tool bar). Automatically (if the Data flow Diagram does not already exist), the reset Input and the val Output signals appear in the diagram. Now, you have only to drag and drop the operators from the palette.
The previous picture can be read as following:
Remark:
The second example is the specification of a Watchdog process. This example is not more complicated as the previous one, but it shows the use of a Clock Relations and Dependences Diagram and some specific actions on some operators.
Specification: a process emits an order, to be executed within some delay. When finished, a finish signal is made available. The Watchdog is designed to control this delay. It receives a copy of order and finish signals. It must emit an alarm whenever a job is not finished in time. If a new order occurs when previous one is not finished, the time counting restarts from zero. A finish signal out of delay, or not related to an order, will be ignored.
An order is supposed to be coded by an integer. The process receives also as other input the finish signal, which is an event. In order to count the time, synchronous languages do not use language-defined devices, like seconds, whose accuracy is not sufficient. The source of time is also an input signal called tick, of type event. The amount of time between two such time events is defined by the environment. The parameter DELAY is expressed as a number of tick. As output, the process produces an alarm when the DELAY between order and finish is exceeded. This alarm is an integer corresponding to the hour (the number of tick since the beginning of execution) at which the alarm is sent.
The following pictures are screen shots of the Data flow Diagram of the Watchdog and of the Clock Relations and Dependences Diagram.
The main differences between this Data flow Diagram and these of the Counter example concerning the use of the graphical editor are:
This third example presents how to define a mode automaton with the SME graphical editor. An Automaton cannot be the root of an sme (or smedi) file, so you have first to create a Data flow Diagram (with an Interface Definition Diagram to specify the Input/Output signal of the process) as shown in the previous examples. The parent of this Automaton is a Model Declaration with three Input events called i, j, and tick. This Automaton is added inside a Data flow Diagram, and its master clock is specified inside a Clock Relations and Dependences Diagram (we specify that the master clock of the Automaton is the union of the clock of the three Input events as in the previous example).
Now, we have to define the Mode Automaton itself, so double click on the Automaton to display the Mode Automaton Diagram (shown on the previous picture). The Automaton has two sub-states: an And-State A, which is also the initial state, and a leaf-state DecrX (which decrements X at each execution). A leaf-state is as a Sub Process. This means that you can use a Data flow Diagram and a Clock Relations and Dependences Diagram to specify the behavior of the State.
To indicate the initial state of an Automaton, right-click on the wanted initial state and select the Set the Initial State action. Two Local integer signals X and Z are also declared in the Automaton and are shared (so, their status has to be shared) among the different sub-states.
Remark: when Local signals declared in an Automaton are defined in several sub-states of the Automaton, do not forget to use partial definition links to define them. A partial definition is a Dataflow Connection with the Use Partial Definition set to true.
The A And-State is composed of three sub-states: one leaf-state IncrX (which increments X at each execution), and two automata YEvolution and ZEvolution (which makes evolve Y and Z. A Local integer signal Y is declared inside the And-State (Z is declared outside the And-state because it is used by the guard of the transition between A and DecrX; this means that Y is shared among the sub-states of A (so its status has to be shared).
Remark: on the previous picture, all states have a specific symbol (a green arrow). In general case, all elements with this symbol has one or several sub-diagram(s) whose root is the element itself.
Finally, there is one Weak Transition from A to DecrX, and one in the opposite direction. The guard of these transitions are a textual boolean expression. The priority attribute is useless here because each state has only one out-going transition.
Remark: