Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 466 2009-10-2 466 Model-Based Design for Embedded Systems semantic anchoring is defined by model transformation rules expressed in the UMT (Unified Model Transformation) language of the GReAT tool suite [26]. In UMT, model transformations are expressed as graph transformations that can be executed (in interpreted and/or compiled form) by the GReAT tool. In summary, semantic anchoring specifies DSML behavioral semantics by the operational semantics of selected semantic units (defined in ASML) and by the transformation rules (defined in UMT). The integrated tool suite enables the simulation of domain models defined in a DSML according to their “reference semantics” by automatically translating them into ASML data models using the transformation rules. In the rest of this section, we show the process of semantic anchoring using a simple example. Readers can refer for detailed discussion about the use of the semantic anchoring tool suite in specifying a TASU in [9], and for specifying semantics for a complex DSML by composing several semantic units in [11]. 14.4.2 Semantic Anchoring Example: Timed Automata Timed Automata [2,3] model the behavior of real-time systems over the pro- gression of time. This formalism extends the definition of state-based transi- tion systems to include a finite set of real-valued clocks that synchronously progress time. The enabling of transitions is further restricted using con- straints over the clock valuations, and transitions can specify a set of clocks to reset to zero upon firing. Timed automata have previously been defined within the semantic anchoring framework [9]; however, the semantic unit included many fea- tures to provide semantic equivalences to other versions of timed automata modeling languages (e.g., UPPAAL [4] and IF [37]). The proposed TASU specified here is intended to be simple while capturing all the basic facili- ties of the original timed automata model. In the AsmL semantic definition, the structures mimic the abstract constructs of the behavioral formalism. The first two sections provide the Abstract Data Model (ADM) and operational semantics that govern a single automaton. The ADM describes the data struc- tures of the semantic unit, and the operational semantics provide a model interpretation over an instance of the ADM, the data model. The succeed- ing sections will explain how automata are composed to form more com- plex systems and then define the modeling language of the semantic unit, L s , required for semantic anchoring. 14.4.2.1 Timed Automata Overview Structurally, a timed automaton is a mathematical 5-tuple < L, l 0 , C,E, Pr e > with an event alphabet Σ: 1. L is a finite set of locations. 2. l 0 is an initial location, l 0 ∈ L. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 467 2009-10-2 Semantics of Domain-Specific Modeling Languages 467 3. C is a finite set of clock variables. 4. E ⊆ L × Σ × 2 C × L is a set of edges. An edge < l, α, φ, λ, ω, l > is a transition from l to l on a set of input events α ⊂ Σ and the satisfaction of the guard φ(v) over the valuation function v of the clocks c ∈ C, v : c → N. Upon the firing of a transition, the clocks λ ⊆ C are reset to 0, and the set of output events ω ∈ Σ are generated. 5. Pr e : E×N n → N is a map that assigns to each edge a nonnegative integer priority with respect to a given clock evaluation v,sothatPr e (e, v) is the priority of edge e at clock valuation v. Transitions are assigned a priority to model the dynamics of many com- mon real-time systems. This mechanism allows for dynamic priority assign- ment throughout the execution of a model. Following the model of [9], the progression of time is modeled as a transition; therefore, it too must be assigned a priority, the lowest priority in the specification. This supports the notion of urgent transitions; however, unlike [9], this semantic unit does not provide mechanisms for blocking time or most urgent transitions (i.e., the time transition is always enabled). The semantics for a timed automaton fitting the structure above defines the state of a timed automaton as a pair of (l, v) where l is a location in L and v is a valuation of the clocks C. The possible state changes are enabled over the union of location-switching transitions and the progression of time defined respectively as (l, v) α −→ (l , v[λ := 0]) ⇔∃e =< l, α,φ, λ,ω, l >∈ E such that φ(v) = true and ∀e =< l, α, φ , λ , ω , l >∈ E ∧ φ(v) = true ⇒ Pr e (e, v) Pr e (e , v) (14.46) (l, v) t −→ (l , v +ε) ⇒ Pr e (e, v +ε) = 0 (14.47) In the following, we will use AsmL syntax in the specifications. The advantage of this approach is that these specifications are directly executable using the freely available AsmL tools [18] that can be used with the latest Microsoft Visual Studio distributions. 14.4.2.2 Semantic Unit Abstract Data Model In ASML, Events and Clocks (shown in Figure 14.12) are enumerated stores for the defined events (∈ Σ) and clock variables (C) of the automaton. The TimedAutomaton class captures the mathematical model described above for the semantic unit. The id field, present in all following class definitions, pro- vides a naming construct to identify objects, but it has no semantic implica- tions. The initial field holds the initial location of the automaton, and it must Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 468 2009-10-2 468 Model-Based Design for Embedded Systems 1. enum Clocks 2. enum Events 3. class TimedAutomaton 4. const id as String 5. const locations as Set of Location 6. const initial as Location 7. const transitions as Set of Transition 8. const local_clocks as Set of Clockss 9. var v as Set of Clocks of Clocks to Integer ={−>} 10. var cur as (Location, Set of Events) = ( null, {}) FIGURE 14.12 Structures: Clocks, events, and timed automata. be a predefined location of the system, member of the field locations,oran error will occur. The transitions field holds the set of all defined transitions between the locations of this automaton. The variable v is the valuation of the clock variables in local_clocks. The valuation is a partial function specified as a mapping from the clock domain, C, to the domain of natural numbers, N. Natural numbers were chosen for discrete time steps for clarity. Domain models from a DSML that uses variable discrete time steps can be scaled as required, complicating the operational code. The variable field cur is a 2-tuple indicating the location and set of active events in the current execut- ing step of the simulation. Location and Transition are defined as first-class types (Figure 14.13). Loca- tions contain only the unique identifier, id. Transition defines a move from a location src to a location dst, given the appropriate input events, trigger, and the satisfaction of the time guard condition, φ(v). The variable time_guard is a partial function that maps clock valuations to a Boolean. The time guard must be defined as a variable since the valuation of the clocks v(C) is variable over the progression of time. Upon taking a transition, the event set outputs is added to the set of currently active events. The resets field holds the clocks to 1. class Location 2. const id as String 4. class Transition 5. const id as String 6. const src as Location 7. const dst as Location 8. const trigger as Set of Events 9. const output as Set of Events 10. const resets as Set of Clocks 11. var time_guard as Map of (Map of Clocks to Integer) to Boolean 13. const time = new Transition(“time”, null, null, {}, {time_ev}, {}, {->}) FIGURE 14.13 Structures: Locations, transitions, and time. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 469 2009-10-2 Semantics of Domain-Specific Modeling Languages 469 be reset to zero upon taking the transition. According to the original model, the progression of time is enabled in every state of a timed automaton; there- fore, the time transition is defined as a constant. If the time transition is taken, all clocks in the timed automaton will be incremented by some value ∈ N that must be defined for the model. Note that the time transition has an out- put event, time_ev. This event must be included in the data model definition. 14.4.2.3 Operational Semantics As is the case for all MIC semantic units, the operational semantics of the timed automaton semantic unit are specified as a set of ASML rules that exe- cute over models instantiated using the ADM data structures. A global function InputEvents provides an interface to continue the execu- tion of a model within the AsmL tools, that is, it provides a means to drive the simulation. This method receives an input parameter set of TimedAutoma- ton objects, and should return a set of Events to serve as input to the current simulation step. It must be provided by the consumer of the semantic unit (i.e., the simulation environment). The InitializeTA method (shown in Figure 14.16) first initializes the cur variable to the initial location and an empty active event set, and then sets the valuation of all local clock variables to zero. The set of currently enabled transitions returned by the EnabledTransitionsTA method is the time transition added to the set of transitions that meet the enabling conditions: the source location of the transition is the current location, the triggering events of the transition are a subset or equal to the set of currently active input events, et.trigger <= cur.Second,andtime_guard(v) evaluates to true. The EvolveTA method (Figure 14.14) fires the transition passed to it, tr, by updating the current configuration to be the destination location of the transition and the generated output events of the transition and resets all clocks specified in the resets field of tr to zero. The partial update to the map- ping v also maintains the current valuations of all other clocks not in resets, local_clocks -(local_clocks intersect resets). Even though the time transition is always returned as an enabled transition, its effect it not yielded by pass- ing it to the EvolveTA method. Instead, the TimeProgressTA method must be invoked to increment all local clock valuations by the defined integer value 1. class TimedAutomaton 2. EvolveTA(tr as Transition) 3. require tr in transitions 4. cur := (tr.dst, tr.output) 5. v := {clki − > 0 | clki in (tr.resets intersect local_clocks) } 6. union {clki − > v(clki) | 7. in local_clocks -(tr.resets intersect local_clocks) } FIGURE 14.14 Execution: Stepping a timed automaton. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 470 2009-10-2 470 Model-Based Design for Embedded Systems and must set the time_ev event as the only active event for the given automa- ton. The UpdateEvents and GetEvents methods are self-explanatory. The Prior- ityTA and UpdateTimeGaurdTA methods are not predefined functions as they are model dependent. Each must be specified when simulating an instance model of a DSML. The PriorityTA method returns a nonnegative integer value for each tran- sition in the system with the base priority being 0, that of the time transition. Returning identical priorities for multiple transitions allows for nondeter- minism in the data models. The UpdateTimeGuardTA method reevaluates the guard condition of every transition given the current valuation of the clocks. The time tran- sition’s time guard is never included in this method since it is always an enabled transition. 14.4.2.4 Composition of Timed Automata The timed automaton semantic unit presented thus far describes the behav- ioral semantics and data structures of a single automaton. To model larger, more complex systems and behaviors, the semantic unit needs to be extended to model concurrently executing automata. Here, we show the synchronous parallel execution semantics for multiple automata and provide the appro- priate metamodel for the TASU. The modeling of concurrent automata was previously approached in [9]; however, the resulting semantic unit appeared overly complex and insufficiently expressive. These issues motivated this new specification that is intended to be simpler and extensible to a wider variety of execution semantics. The set of globally scoped clocks, global_clocks, is a set of clocks that all automata can read and possibly reset. Conversely, the set of clocks in the TimedAutomaton class, local_clocks, is scoped exclusively to its respective automaton. The variable g_v is the partial function that maps the global clock variables to their valuations. Figure 14.15 contains the ASML structures for a global system definition. The class Comp_System (Figure 14.15) contains the set of concurrently exe- cuting TimedAutomaton objects and a variable E. E represents the set of all 1. const global_clocks as Set of Clocks 2. var g_v as Map of Clocks to Integer = {clki − > 0 | clki in global_clocks} 4. class Comp_System 5. const TA_components as Set of TimedAutomaton 6. var E as Set of Events = {} FIGURE 14.15 Execution: ASML structures supporting concurrent composition of indepen- dent timed automata. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 471 2009-10-2 Semantics of Domain-Specific Modeling Languages 471 1. class Comp_System 2. InitializeCS_TA() 3. forall c in TA_components 4. require {t} intersect {tr.resets | tr in c.transitions} = {} 5. require c.local_clocks intersect global_clocks = {} 6. require c.local_clocks intersect {h.local_clocks | hin TA_components 7. where h <> c} = {} 8. c.InitializeTA() 10. UpdateEventsCS_TA() 11. let e = E union InputEvents(TA_components) 12. E := e 13. forall c in TA_components 14. c.UpdateEvents(e) 16. UpdateTimeGuardCS_TA() 17. forall c in my_sys.TA_components 18. c.UpdateTimeGuardTA() FIGURE 14.16 Execution: Initialization and update for noninteracting concurrent timed automata. active events in the composed system. This composition does not restrict or scope events that an automaton can see; therefore, events generated from one automaton will be visible for all other automata in the composed system as well. The InitializeCS_TA method invokes the InitializeTA method for each TimedAutomaton object in the composed system after it checks constraints that are placed on the clock variables (Figure 14.16). First, in the composed system, the clock variable t is the system clock and is not allowed to be reset. The next two constraints ensure that no clock is defined both globally and locally and that no clock is defined as local to multiple automata. The Upda- teEventsCS_TA method must correctly update the global set of active events for all TimedAutomaton objects in the system. Remember, all of the automata see the same set of active events (i.e., there is no scoping of local events ver- sus global events). Still, this could be extended to allow event scoping in the semantics of other variations of a composed system. The UpdateTime- GuardCS_TA method simply calls the UpdateTimeGuardTA method for each TimedAutomaton. The TimeProgressCS_TA and EvolveCS_TA methods (shown in Figure 14.17) are responsible for changing the state of the system for every execu- tion step. Along with calling the TimeProgressTA method for each automa- ton, TimeProgressCS_TA must increment all global clock valuations by the defined constant . This method is only called if all automata in the sys- tem have elected to take the time transition in this step. The EvolveCS_TA method takes as input each timed automaton in the system with its respec- tive highest priority currently enabled transition. ev and nev are initialized to Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 472 2009-10-2 472 Model-Based Design for Embedded Systems 1. class Comp_System 2. TimeProgressCS_TA() 3. g_v := {clki -> g_v (clki) + epsilon | clki in global_clocks} 4. forall c in TA_components 5. c.TimeProgressTA() 7. EvolveCS_TA(cT as Set of (TimedAutomaton, Transition)) 8. let ev = {k | k in cT where k.Second <> time} 9. let nev = {l | l in cT where l.Second = time} 10. let gr = BigUnion({ h.Second.resets | h in ev}) 12. g_v := {clki -> 0 | clki in ( gr intersect global_clocks) } 13. union { clki -> g_v (clki) | clki in global_clocks 14. - ( gr intersect global_clocks)} 16. forall m in ev 17. m.First.EvolveTA(m.Second) 18. forall n in nev 19. n.FirstUpdateEvents({}) FIGURE 14.17 Execution: Progress for global time and individual automata. the automata that will take a non-time transition in this step and those that will not, respectively. The automata in nev indicate that their highest prior- ity transition is the time transition; however, all other automata (specified in ev) do not agree so the time transition will not be taken. If a transition is not taken by an automaton, the set of active output events for that automa- ton are cleared. Given the automata that will be taking a non-time transition, the method must also reset global clocks specified in the resets field of the enabled transitions. The EvolveTA method of each automaton will reset the local clocks. Accordingly, the EvolveTA method is called for each automaton in the set ev. The RunCS_TA method provides a single execution loop for the com- posed system (Figure 14.18). First, each automaton of the composed sys- tem must be initialized. Notice that the variable count restricts the number of execution steps of the loop and has no semantic meaning for the system. During each iteration of the execution loop, the active event set is updated (UpdateEventsCS_TA method) to include the events generated from the last set of transitions, initially held in E, joined to the events returned from the InputEvents method. Also, all time guards must be reevaluated given the resulting system state from the last execution step. Following these updates, the set of enabled transitions for all automata can be determined. First, the set of all enabled transitions for each automa- ton are stored in eT in the anonymous 2-tuple of type <TimedAutomaton, Set of Transitions> . Next, the set of enabled transitions for each automaton is reduced to a single transition that has the highest priority of all enabled transitions. This reduction is nondeterministic if multiple enabled transi- tions have the highest priority value. Time will progress only if all automata Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 473 2009-10-2 Semantics of Domain-Specific Modeling Languages 473 1. class Comp_System 2. RunCS_TA() 3. Var_ count = 1 4. step my_sys.InitializeCS_TA() 5. step while count < 35 6. step 7. UpdateEventsCS_TA() 8. UpdateTimeGuardCS_TA() 9. step 10. let eT = {(ta, ta.EnabledTransitionsTA()) | ta in TA_components} 11. let eT2 = {(b.First, (any h | l in b.Second where 12. b.First PriorityTA(h) = (max b.First.PriorityTA(tp) 13. | tp in b.Second))) | bineT} 14. if {b2.Second | b2 in eT2} = {time} then 15. TimeProgressCS_TA() 16. else 17. EvolveCS_TA(eT2) 18. step 19. E := BigUnion({ c.GetEvents()| c in TA_Components}) 20. count := count + 1 21. FIGURE 14.18 Execution: Global coordination code. indicate that the time transition should be taken; otherwise, eT2 is passed to EvolveCS_TA. Following either action (time progress or taking other transi- tions) all generated events from each automaton in the composed system are collected and stored in the variable field E. 14.4.2.5 TASU Modeling Language Within the MIC semantic anchoring framework, model transformations between metamodels of a given DSML and the TASU specifies the anchoring of the DSML to the TASU. In order to connect the ASML and the MIC tool suites, we must represent the TASU ADM as a MIC metamodel (expressed in MetaGME) and must implement a translator that translates MIC model instances into ADM model instances. Figure 14.19 shows the metamodel of the TASU specified in the MetaGME metamodeling language [22] of the MIC tool GME. The metamodel in Figure 14.19 captures the Abstract Data Model of the TASU. Note that the metamodel includes Constant and Variable objects for defining model-dependent data. The remaining piece of the TASU is a model translator that generates the ASML of data models from timed automata models created in the MIC tool suite. Since these time automata models are instances of the TASU Metamodel as well as the TASU ADM on the ASML side, the translator is a simple XML parser. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 474 2009-10-2 474 Model-Based Design for Embedded Systems Event <<Atom>> 0 x 0 x 0 x 0 x 0 x 0 x src 0 x dst 0 x 0 x 0 x 0 x Constant <<Atom>> Variable <<Atom>> Initial <<Reference>> Location <<Atom>> Type : field Value : field Type : field Value : field output : field resets : field trigger : field time_guard : field Priority : field TimedAutomaton <<Model>> Transition <<Connection>> System <<Model>> Clock <<Atom>> FIGURE 14.19 Metamodel for our timed automata abstract data model. 14.4.2.6 Semantic Anchoring Example: The Timing Definition Language The timing definition language (TDL) [16,36] provides a high-level pro- gramming abstraction that allows distributed real-time system designers to describe the temporal behavior of components apart from their functional code and deployment/configuration concerns. This timing model is based on logical execution time (LET) introduced by the Giotto modeling lan- guage [20]. TDL preserves many other artifacts of Giotto, but some syntactic and semantic differences remain. This case study will capture the timing behavior of a TDL application by anchoring a TDL modeling language to the TASU. For simplicity, in this example, all TDL communication artifacts will be excluded from the map- ping since they have no effect on the temporal behavior of a TDL application. In Giotto [20] a system is defined over a set of nonconcurrent modes, each of which contains periodically executing activities and a communica- tion topology description. The periodic activities, task invocations under LET semantics, actuator updates, and mode switches, all conditionally execute a finite number of times, their frequency, within the mode’s cyclic execution period. A task’s timed execution cycle is initiated by a release for scheduled execution and finished by a completion event at time after the release. Actua- tor updates and mode switches are considered synchronous activities; there- fore, they take zero logical time to execute. In TDL [16] the notion of a mode is preserved; however, the model is extended to include a module, a TDL component. A module encapsulates Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 475 2009-10-2 Semantics of Domain-Specific Modeling Languages 475 what is characterized as a Giotto system, and a TDL system is defined as a set of modules and communication networks between them. Like Giotto, the modes within a single module do not execute concurrently; however, modules of a TDL system execute in parallel. 14.4.2.7 Anchoring the TDL Modeling Language to the TASU Figure 14.20 shows an abbreviated metamodel for the TDL modeling lan- guage. The full metamodel contains data handling mechanisms, such as ports and drivers; however, these omitted artifacts do not affect the tim- ing behavior of a TDL application. Notice that the ModeSwitch class inherits from the abstract class Periodics. The attribute frequency that ModeSwitch now contains will be ignored in the transformation since nonharmonic mode switches are not allowed in TDL unlike Giotto [20]. The TaskReference class is used to copy a previously defined Task into a new mode that may define a different frequency value for the TaskReferemce versus the original Task object’s frequency. The model transformation that provides the anchoring across the meta- models is specified in the UMT language of the MIC tool GReAT [26]. The transformation is given by a set of rules that define the mapping between the TDL metamodel and the TASU metamodel. The transformation takes a TDL System <<Model>> Module <<Model>> Mode <<Model>> Periodics <<FCO>> 0 x 0 x 0 x Task <<Model>> TaskReference <<Reference>> ModeSwitch <<Reference>> ModePeriod: field StartMode: bool Frequency: field DriverFunction:field FIGURE 14.20 TDL MetaGME Metamodel (abbreviated). . Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 466 2009-10-2 466 Model-Based Design for Embedded Systems semantic anchoring is defined by model transformation rules. automaton. Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 470 2009-10-2 470 Model-Based Design for Embedded Systems and must set the time_ev event as the only active event for the. location of the automaton, and it must Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 468 2009-10-2 468 Model-Based Design for Embedded Systems 1. enum Clocks 2. enum Events 3.