Model-Based Design for Embedded Systems- P17 pps

These sequences form the meaning of the program.Adopting this definition for the behavioral semantics of modeling languages,operational semantics of a DSML is defined by a model interpre

14.3.5.1 Derived Functions and Logic Programs

0

1 1 1

2 22 2 2

3 3 3 3 3

3 3

FIGURE 14.8

Calculatingreachablestates frominitial state 0

A query reduces some property of a model to a boolean

value: Either the property holds (the query is satisfied) or

it does not hold Sometimes this reduction loses

informa-tion that should persist For example, suppose we want to

know which states can be reached after one, two, and three

transitions of a FSM, as shown in Figure 14.8 This can be

done with the queries shown in Figure 14.9 Notice that

the queryfindTwo, which finds all states after two steps,

must first discover all the states one step away Similarly,

thefindThreequery must find the states reachable in one

and two steps, before finding the states reachable in three

steps The N th findquery does all the work of the N− 1

previous queries, which is wasteful and makes the queries unnecessarily bose

ver-This problem can be solved by temporarily storing the results of queries

into data structures These temporary results are created using derived tions A derived function is a function beginning with a lowercase letter.

func-Derived functions are only used to temporarily remember some ate results and can never appear in the data elements of an input model.∗Forexample:

declares a derived function for remembering those states reachable from aninitial state after one step Temporary results are created by writing the fol-

lowing expression:

reach1(y) :−xisInitial , yisState , tisTransition,

t current = x.state, t.next = y.

/// Queries searching for reachable states

3 findOne ?: x is Initial, y is State,

5 t.current = x.state, t.next = y.

7 findtwo ?: x is Initial, y is State,

8 t is Transition, s is Transition,

9 t.current = x.state, t.next = s.current, s.next = y.

11 findThree ?: x is Initial, y is State,

12 t is Transition, s is Transition, u is Transition,

13 t.current = x.state, t.next = s.current,

FIGURE 14.9

Queries for locating reachable states after one, two, and three steps

∗The upper/lowercase syntax for functions and derived functions is similar to the notationused in BNF grammars to distinguish terminal from non-terminal elements.

Note that this expression has the semantics explained in Section 14.3.2 For

example, this rule adds the reach1 term to all relations R k>0 for some k, when

evaluated against the example FSM:

reach1(State(“S2”,“”)) The information from reach1 can be used to calculate the states reachable

in two steps First, we introduce another derived function:

and then the expression:

reach2(y) :−xisreach 1, yisState , tisTransition,

t current = x.state, t.next = y.

Now reach1 is used as a term in the body of this expression Note that the ordering of expressions ensures that all the reach1 terms were calculated

before evaluating this expression

The following set of expressions are recursive and because our formalismrequires non-recursiveness, they cannot be expressed in it

reachN(y) :− xisInitial , yisState , tisTransition,

t current = x.state, t.next = y. (14.31)reachN(y) :− xisreachN , yisState , tisTransition,

t current = x.state, t.next = y. (14.32)

The rules above calculate all of the reachable states of a FSM Rule 14.31

cre-ates a reachN instance for each state immediately reachable from an initial state Rule 14.32 creates a reachN instance for each state that is reachable in one step from a reachN instance Rule 14.32 depends on Rule 14.31 and on

itself, thereby creating a dependency cycle

This example shows that recursive logic programs are useful, but theymay also result in an infinite loop of data creation Furthermore, in general

it is impossible to determine whether an infinite loop truly exists or not Inorder to support analysis of the specifications,FORMULAdisallows all recur-sive logic programs Note that it is possible to write logic programs thatappear recursive, but can be unrolled into non-recursive logic programs.FOR- MULAsupports this form of recursion, but it is beyond the scope of this chap-ter The non-recursive restriction also means there is always a good evalua-tion order for expressions:

1 Evaluate the expression that has not yet been evaluated and depends on

no other expressions

2 For an expression e ithat has just been evaluated, remove all

dependen-cies on e i from other expressions e j for j > i.

3 Repeat (1) until no more clauses are left to evaluate

We have presented logic expressions as a convenient way to reuse work,which might give the (wrong) impression that they only serve this purpose.

Some queries cannot be expressed without using logic expressions Here is

an example:

Is there a state x for which no transition goes to a blocking in state?

This query must locate a state x and test that every outgoing transition does

not end on a state with no outgoing transitions Neither a single query nor

a boolean composition of queries can keep track of all this information.Instead, an expression is needed that calculates those states that reach ablocking state in one step:

blocksOne(x, y) :−xisState , yisState , Transition (x, , y),

failTransition(y, , ).

The query uses this intermediate data to find states that do not go directly toblocking states:

:? xisState, failblocksOne(x, ).

14.3.6 Domains and Compositions of Domains

Bringing these concepts together, a domain D is simply a triple:

where

ΥPis a signature of primitive function symbols

ΥRis a signature of derived function symbols

Eis a nonrecursive stratified logic program defining theconformsquery

The set models (D) is the set of all models that satisfy theconformsquery:

Includes. Theincludesoperator is used to import the declarations of onedomain into another domain:

domain D’ includes D { }

The resulting domain Dhas

Υ

P⊇ ΥP, ΥR⊇ ΥR , E⊇ E[conforms/D.conforms] (14.35)

TABLE 14.1

Basic Set of Composition Operators

includes, restricts, D’ includes D, Imports the declarations of D into D

extends operators D’ restricts D, while renaming theconforms

D’ extends D, query of D to D.conforms

renaming D as X Produces a new domain from D by

operator“as” replacing every occurrence of a function

symbol f ( .) with X.f ( .) and

every query name q with X.q.

pseudo-product D1∗ D2 Produces a new domain Dby combining

operator“∗” the specifications of D1and D2,

and then adding the query

(conforms :? D1.conforms &

D2.conforms)

pseudo-coproduct D1+ D2 Produces a new domain Dby combining

operator“+” the specifications of D1and D2,

and then adding the query

(conforms :? D1.conforms XOR

D2.conforms)

The notation E[x1 /x

1, , x n /x

n] denotes the expressions formed by replacing

every occurrence of x i in E with xi Thus, domain Dhas direct access to the

declarations in D, but does not necessarily utilize the conformance rules of

D because it is renamed to D.conforms Theincludesoperation is defined if

the signatures of Ddo not contain contradictory function symbol definitions,

and the expressions E are non-recursive and stratified.

There are several variants of includes that make stronger statements

about D The restricts keyword requires that no new primitives are

introduced in D Additionally, D.conforms is implicitly conjuncted onto the conforms of D Therestrictsoperator enforces that

Theextendsvariant implicitly disjuncts D.conforms onto the conforms of D,therefore

Renaming. The renaming operator “as” gives new names to the function

symbols and queries in a domain The expression

(D as X)

produces a domain Dwith the same signatures and expressions as D, except

that every occurrence of a function symbol and query name is prepended

by “X.”

Pseudo-product. The pseudo-product operator “∗” is a precursor for building the categorical product of domains The expression

The pseudo-product has the property that if D1and D2have disjoint tures and query names, then

This is called the categorical product; it means that every model X ∈ models(D) can be uniquely partitioned into two subsets X1 and X2 so that X i ∈

models(D i ) This construct is important, because it combines two domains

into a larger one while guaranteeing no nontrivial interactions

Pseudo-coproduct. The pseudo-coproduct operator “+” is a precursor for building the categorical coproduct of two domains The expression

(14.40)

Let the models (D i ) be the set of all finite syntactic instances that satisfy the

conformsquery of domain D i The pseudo-product has the property that if

D1and D2have disjoint signatures and query names, then

This is called the categorical coproduct; it means that every model X ∈

models(D) is either in models(D1) or models(D2), but never both Again, this

construct is important, because it combines two domains into a larger onewhile guaranteeing no nontrivial interactions

14.3.6.1 Properties of Compositions

Regardless of the approach, complex modeling processes are often plagued

by the nonlocal effects of composition In our framework, compositions mayyield unexpected results because of interactions between declarations andlogic programs A minimum requirement to ensure that composition does

not introduce inconsistencies is to check non-emptiness of models (D) The

model finding procedure of FORMULAis suited for this task: Perform modelfinding on theconformsquery to check non-emptiness.

However, checking non-emptiness of models is only one of the toolsavailable inFORMULA Many of the composition operators guarantee relation-ships between domains For example, the composition operators can also becombined to guarantee relationships by construction For example, given afamily of domains(D i ) i ∈I and an one-to-one renaming function r : I→ Σ, thecategorical product can always be built by the construction:

if there exists a state with two distinct outgoing transitions triggered by thesame event Theconformsquery is satisfied ifisNonDeteris not satisfied.Note that the restricts keyword implicitly conjuncts NFA.conformsonto theconformsquery ofDFA

14.3.7 Summary

The structural semantics of DSMLs serve as interfaces to the users of ing languages and to underlying tool flows Beyond this, structural semanticsfacilitate reuse and composition of DSMLs, as we describe in the next sec-tion Therefore, it is important to formally specify and to provide tool sup-port for analysis of structural semantics In this section, we have provided

model-a genermodel-al frmodel-amework for understmodel-anding the relmodel-ationship between structurmodel-alsemantics (domains), DSMLs, and metamodels We have also described aconcretization of this framework using structured LP with carefully chosencomposition operators This approach allows formal analysis and correct-by-construction of structural semantics Please see [25] for a complete example,including formal analysis

/// Deterministic Finite Automaton Domain

2 domain DFA restricts (NFA){

3 isNonDeter :?

4 s is State, t1 is Transition, t2 is Transition,

5 t1.current = s, t2.current = s, t1.trigger = t2.trigger,

14.4 Specification of Behavioral Semantics of DSMLs

As defined by their structural semantics, models are well-formed tures that can represent domains (in metamodeling) or specific points indomains While structural semantics of DSMLs are important, they are notsufficient for expressing all essential meanings associated with models Themost important semantic category that needs to dealt with is behavior Forexample, in the simplified design flow of embedded controllers (see Fig-ure 14.1), the model of a proportional/integral/derivative (PID) controller[34] would be represented in Simulink R [21] as a structure of simple differen-

struc-tiator, integrator, adder, and multiplier nodes that form a point in the domain

of all well-formed Simulink(R) Models At the same time the PID controllerhas a well-defined dynamics that can be described using different mathe-matical formalisms such as differential equations, an impulse response, or afunction in the Laplace domain [34] In general, behavioral semantics need to

be represented as an interpretation of the model in a mathematical domainthat is sufficiently rich for capturing essential aspects of the behavior (such

as dynamics)

Explicit representation of structural and behavioral semantics in DSMLsconforms well to all engineering disciplines where the relationship betweenstructure and behavior is extensively studied Formalization of these twoclosely related aspects of modeling enables the exploration of fundamentalissues in modeling:

1 DSML composition: Given two DSMLs L1 and L2 with behavioral

semantics X and Y and a composition operator ⊕, create a compositeDSML with structural semantics(L1⊕ L2 ) such that the constraint sys-

tem of the composed domain is consistent (the domain of the composed

DSML is not empty) and the composed DSML exhibits both X and Y

behavioral semantics (there are two behavioral interpretations of themodels in the composed DSML)

2 Orthogonality: Given a DSML L = (Υ, RΥ, C, (struc,X,Y )) with behavioral semantics X and Y and two sets of structural operators op X ∈

OP X and op Y ∈ OP Y that are structure preserving (whenever a model r

is well-formed, the transformed models op X (r) = rand op Y (r) = rarealso well-formed):

∀r ∈ D(Υ, C) ⇒ (op X (r) ∈ D(Υ, C)), (op Y (r) ∈ D(Υ, C)) (14.43)

The operators are orthogonal to the behavioral semantics X and Y,

respectively, if

∀r ∈ D(Υ, C)) ⇒ (r X = op X (r) X ), (r Y = op Y (r) Y ) (14.44)

3 Structural/behavioral invariants: The design and verification tasks can

be significantly simplified if behavioral properties can be guaranteed

by structural characteristics Discovering and testing these ants requires the precise representation of structural and behavioralsemantics.

invari-In this section, we describe a method for formalizing behavioral

seman-tics based on transformational interpretation As we discussed before, an

model realizations of another domain:

Assuming that the RΥtarget domain has well-defined behavioral

seman-tics, the specification of the mapping assigns semantics to RΥif the mapping

is well-defined In other words, the behavioral interpretation of models in a

DSML L requires two distinct components:

• A mathematical domain and a formal language for specifyingbehaviors

• A formal language for specifying transformation between domainsSelection of the first component largely depends on the goal of the formalspecification If the models represent behaviors that need to be simulated by

computers or implemented on computers, selection of operational semantics is

the right choice In programming languages, operational semantics describehow a syntactically correct program is interpreted as sequences of abstractcomputational steps [17] These sequences form the meaning of the program.Adopting this definition for the behavioral semantics of modeling languages,operational semantics of a DSML is defined by a model interpretation pro-cess formed by a sequence of abstract computational steps [10,12] The modelinterpreter generates behavior from models While primitive behaviors aredescribed as sequences of computational steps, complex behaviors need to

be defined compositionally as the interaction of behaviors of primitive ponents Detailed treatment of this topic is out of scope for this chapter, werefer interested readers to the literature [5,11] Another relevant method for

com-specifying behavior is denotational semantics Denotational semantics of

pro-gramming languages provide mathematical objects for representing whatprograms do (as opposed to how they do it) [35] For example, the TaggedSignal Model (TSM) provides a denotational framework representing sets ofpossible behaviors as a collection of events [29] The primary goal of TSM iscomparing models of computation and not simulation or code generation.The second component is the specification of transformations betweendomains Since these transformations are syntactic operations, their for-mal specifications can be expressed using a logic-based structural semanticsfoundation [23] or graph transformations [26] We choose graph transforma-tion specifications because of the availability of high-performance tools [27]

In this chapter, we describe one formalization of behavioral tics based on Abstract State Machines (ASM) [7] and model transforma-tions We use ASMs for the formal specification of model interpreters and

seman-graph transformations to map models specified in various DSMLs into their

ASM representation This process, called semantic anchoring, is supported by

an integrated tool suite including the Model Integrated Computing (MIC)tools [27] and the ASML tool suite [18] We will use a simple example fordemonstrating the method

14.4.1 Overview of Semantic Anchoring

The outline above suggests that given a DSML L =Υ, RΥ, C,struc,

ii ∈I

we need to specify for each i ∈ I behavioral interpretation the following:

1 The : RΥ → RΥ ASML mapping between the RΥ domain of L and the

RΥASML domain of an ASM language ASML

2 A model interpreter in ASML

While this is certainly possible, the required effort would be significantand in direct conflict with the ultimate goal of DSMLs: rapid formulation andevolution of semantically precise, highly domain specific abstractions Thedifficulties are further exacerbated by the fact that specification of the map-ping between the two domains (DSMLs and ASML) requires model transfor-mations that use different formalisms on each side

To mitigate these problems, we have developed a more practicalapproach to semantic anchoring that enables the reuse of specifications Theapproach is based on the recognition that although DSMLs use many dif-ferent modeling abstractions, model composition principles, and notationsfor accommodating needs of domains and user communities, the funda-mental types of behaviors are more limited Broad categories of compo-nent behaviors can be represented by behavioral abstractions, such as FSM,Timed Automaton, and Hybrid Automaton This observation led us to pro-pose a semantic anchoring infrastructure that includes the following ele-ments [12]:

behav-a number of modeling lbehav-angubehav-ages such behav-as IF [37], UPPAAL [4], behav-andKronos [14] (and many others) have Timed Automata semantics Byspecifying a Timed Automata Semantic Unit (TASU) using ASML, wecan define semantics for IF, UPPAAL, and Kronos by specifying thetransformation between them and TASU (see details in [9]) The clearadvantage of this method is that the common semantic domain enablesthe semantically precise comparison of the different models

2 Specification of the transformational interpretationT : RΥ → RΥ ASML between the domains of a DSML L and a selected semantic unit



L SU j



j ∈J.

The T transformation “anchors” the semantics of L to the semantic

in Section 14.2, a domain is defined by a metamodel expressed in a

Lmeta metamodeling language Accordingly, the domain of

L SU j

can

be defined in two alternative forms: (a) using the metamodeling

lan-guage that we use for defining domains for DSMLs, or (b) as an Abstract

between the two representation forms is a simple syntactic mation This approach allows us to specify the model transformation

transfor-T between the DSML and the selected semantic unit such that their

domains are specified using the same formalism provided by Lmeta.Figure 14.11 shows our tool suite for semantic anchoring It comprises(1) the ASM-based common semantic framework for specifying semanticunits and (2) the MIC modeling and model transformation tool suites, theGeneric Modeling Environment (GME), and Graph Rewriting and Transfor-mation Tool (GReAT), respectively, which support the specification of thetransformation between the DSML metamodels and the Abstract Data Mod-els (ADM) of the semantic units

As we discussed above, we selected ASMs, formerly called EvolvingAlgebras [17], as a formal framework for the specification of semantic units.The ASML tool suite [18] provides a specification language, simulator, test-case generation, and model checking tools for ASMs GME [27] is employedfor defining the metamodels for DSMLs using the Unified Modeling Lan-guage (UML)/OCL-based MetaGME metamodeling language [32,33] The

Model transform.

specification

Semantic unit metamodel

Abstract data model

Interpreter

Instance of

Data model

Simulator

Model checker

ASML tool suite MIC Tool Suite : GME, GReAT, UDM

of Generated by

semantic anchoring is defined by model transformation rules expressed inthe UMT (Unified Model Transformation) language of the GReAT tool suite[26] In UMT, model transformations are expressed as graph transformationsthat can be executed (in interpreted and/or compiled form) by the GReATtool 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 suiteenables the simulation of domain models defined in a DSML according totheir “reference semantics” by automatically translating them into ASMLdata models using the transformation rules

In the rest of this section, we show the process of semantic anchoringusing a simple example Readers can refer for detailed discussion about theuse of the semantic anchoring tool suite in specifying a TASU in [9], and forspecifying semantics for a complex DSML by composing several semanticunits in [11]

14.4.2 Semantic Anchoring Example: Timed Automata

Timed Automata [2,3] model the behavior of real-time systems over the gression of time This formalism extends the definition of state-based transi-tion systems to include a finite set of real-valued clocks that synchronouslyprogress time The enabling of transitions is further restricted using con-straints over the clock valuations, and transitions can specify a set of clocks

pro-to reset pro-to zero upon firing

Timed automata have previously been defined within the semanticanchoring framework [9]; however, the semantic unit included many fea-tures to provide semantic equivalences to other versions of timed automatamodeling languages (e.g., UPPAAL [4] and IF [37]) The proposed TASUspecified 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 Thefirst two sections provide the Abstract Data Model (ADM) and operationalsemantics that govern a single automaton The ADM describes the data struc-tures of the semantic unit, and the operational semantics provide a modelinterpretation 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, l0, C, E, Pr e >

with an event alphabet Σ:

1 L is a finite set of locations.

2 l0is an initial location, l0∈ L.

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 lon 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, so that Pr e (e, v) is the priority of edge e at clock valuation v.

Transitions are assigned a priority to model the dynamics of many mon real-time systems This mechanism allows for dynamic priority assign-ment throughout the execution of a model Following the model of [9], theprogression of time is modeled as a transition; therefore, it too must beassigned a priority, the lowest priority in the specification This supports thenotion of urgent transitions; however, unlike [9], this semantic unit does notprovide mechanisms for blocking time or most urgent transitions (i.e., thetime transition is always enabled)

com-The semantics for a timed automaton fitting the structure above definesthe 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 definedrespectively as

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

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

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, or an 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 Domainmodels 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 ing step of the simulation

execut-Location and Transition are defined as first-class types (Figure 14.13) 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

Loca-the satisfaction of Loca-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

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

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,

∈ Nthat 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 thetimed 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 thesimulation This method receives an input parameter set of TimedAutoma-ton objects, and should return a set of Events to serve as input to the currentsimulation 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 setsthe 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 sourcelocation of the transition is the current location, the triggering events of thetransition are a subset or equal to the set of currently active input events,

et.trigger <= cur.Second , and time_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 thetransition and the generated output events of the transition and resets allclocks 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

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

and must set the time_ev event as the only active event for the given ton The UpdateEvents and GetEvents methods are self-explanatory The Prior-

are model dependent Each must be specified when simulating an instancemodel 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 trantran-sition.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 sition’s time guard is never included in this method since it is always anenabled transition

tran-14.4.2.4 Composition of Timed Automata

The timed automaton semantic unit presented thus far describes the ioral semantics and data structures of a single automaton To model larger,more complex systems and behaviors, the semantic unit needs to be extended

behav-to model concurrently executing aubehav-tomata Here, we show the synchronousparallel 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 andinsufficiently expressive These issues motivated this new specification that

is intended to be simpler and extensible to a wider variety of executionsemantics

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 aglobal system definition

The class Comp_System (Figure 14.15) contains the set of concurrently cuting TimedAutomaton objects and a variable E E represents the set of all

exe-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 dent timed automata