Model-Based Design for Embedded Systems- P17 pps

Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 456 2009-10-2 456 Model-Based Design for Embedded Systems 14.3.5.1 Derived Functions and Logic Programs 0 1 1 1 2 2 2 2 2 3 3 3 3 3 3 3 FIGURE 14.8 Calculating reachable states from initial 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 query findTwo, which finds all states after two steps, must first discover all the states one step away. Similarly, the findThree query must find the states reachable in one and two steps, before finding the states reachable in three steps. The N th find query does all the work of the N − 1 previous queries, which is wasteful and makes the queries unnecessarily ver- bose. This problem can be solved by temporarily storing the results of queries into data structures. These temporary results are created using derived func- tions. A derived function is a function beginning with a lowercase letter. Derived functions are only used to temporarily remember some intermedi- ate results and can never appear in the data elements of an input model. ∗ For example: reach1:( state : State ). (14.29) declares a derived function for remembering those states reachable from an initial state after one step. Temporary results are created by writing the fol- lowing expression: reach1(y) :−x is Initial, y is State, t is Transition, t.current = x.state, t.next = y. /// Queries searching for reachable states 3. findOne ?: x is Initial, y is State, 4. t is Transition, 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, 14. s.next = u.current, u.next = y. 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 notation used in BNF grammars to distinguish terminal from non-terminal elements. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 457 2009-10-2 Semantics of Domain-Specific Modeling Languages 457 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: reach2:( state : State ). (14.30) and then the expression: reach2(y) :−x is reach1, y is State, t is Transition, 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 formalism requires non-recursiveness, they cannot be expressed in it. reachN(y) :− x is Initial, y is State, t is Transition, t.current = x.state, t.next = y. (14.31) reachN(y) :− x is reachN, y is State, t is Transition, 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 they may 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. In order to support analysis of the specifications, FORMULA disallows all recur- sive logic programs. Note that it is possible to write logic programs that appear recursive, but can be unrolled into non-recursive logic programs. FOR- MULA supports 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 i that 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. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 458 2009-10-2 458 Model-Based Design for Embedded Systems 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: Isthereastatexforwhichnotransitiongoestoablockinginstate? 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 a blocking state in one step: blocksOne(x, y) :−x is State, y is State, Transition(x, __,y), fail Transition(y,__,__). The query uses this intermediate data to find states that do not go directly to blocking states: :? x is State, fail blocksOne(x,__). 14.3.6 Domains and Compositions of Domains Bringing these concepts together, a domain D is simply a triple: D =Υ P , Υ R , E (14.33) where Υ P is a signature of primitive function symbols Υ R is a signature of derived function symbols E is a nonrecursive stratified logic program defining the conforms query The set models(D) is the set of all models that satisfy the conforms query: models(D) =  X ∈ P(T Υ P (Σ))     X satisfies conforms  , X is finite. (14.34) This simple semantics admits powerful composition operators for build- ing new domains with known properties. Table 14.1 lists these composition operators. Includes. The includes operator is used to import the declarations of one domain into another domain: domain D’ includes D { }. The resulting domain D  has Υ  P ⊇ Υ P , Υ  R ⊇ Υ R , E  ⊇ E[conforms/D.conforms] (14.35) Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 459 2009-10-2 Semantics of Domain-Specific Modeling Languages 459 TABLE 14.1 Basic Set of Composition Operators Operator Usage Description includes, restricts, D’ includes D, Imports the declarations of D into D  extends operators D’ restricts D, while renaming the conforms 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 D 1 ∗D 2 Produces a new domain D  by combining operator “∗” the specifications of D 1 and D 2 , and then adding the query (conforms :? D 1 .conforms &. D 2 .conforms). pseudo-coproduct D 1 +D 2 Produces a new domain D  by combining operator “+” the specifications of D 1 and D 2 , and then adding the query (conforms :? D 1 .conforms XOR . D 2 .conforms). The notation E[x 1 /x  1 , , x n /x  n ]denotes the expressions formed by replacing every occurrence of x i in E with x  i . Thus, domain D  has direct access to the declarations in D, but does not necessarily utilize the conformance rules of D because it is renamed to D.conforms.Theincludes operation is defined if the signatures of D  do 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  .Therestricts keyword requires that no new primitives are introduced in D  . Additionally, D.conforms is implicitly conjuncted onto the conforms of D  .Therestricts operator enforces that models(D  ) ⊆ models(D). (14.36) The extends variant implicitly disjuncts D.conforms onto the conforms of D  , therefore models(D  ) ⊇ models(D). (14.37) 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 D  with 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 Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 460 2009-10-2 460 Model-Based Design for Embedded Systems (D 1 * D 2 ) defines a domain D  where Υ  P = Υ 1 P ∪Υ 2 P , Υ  R = Υ 1 R ∪Υ 2 R , E  = E 1 [conforms/D 1 .conforms]∪ E 2 [conforms/D 2 .conforms]∪ {conforms :? D 1 .conforms & D 2 .conforms.} (14.38) The pseudo-product has the property that if D 1 and D 2 have disjoint signa- tures and query names, then models(D  ) ∼ = models(D 1 ) × models(D 2 ). (14.39) This is called the categorical product; it means that every model X ∈ models(D  ) can be uniquely partitioned into two subsets X 1 and X 2 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 (D 1 +D 2 ) defines a domain D  where Υ  P = Υ 1 P ∪Υ 2 P , Υ  R = Υ 1 R ∪Υ 2 R , E  = E 1 [conforms/D 1 .conforms]∪ E 2 [conforms/D 2 .conforms]∪ {conforms :? D 1 .conforms XOR D 2 .conforms.} (14.40) Let the models(D i ) be the set of all finite syntactic instances that satisfy the conforms query of domain D i . The pseudo-product has the property that if D 1 and D 2 have disjoint signatures and query names, then models(D  ) ∼ = models(D 1 )  models(D 2 ). (14.41) This is called the categorical coproduct; it means that every model X ∈ models(D  ) is either in models(D 1 ) or models(D 2 ), but never both. Again, this construct is important, because it combines two domains into a larger one while 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 may yield unexpected results because of interactions between declarations and logic programs. A minimum requirement to ensure that composition does not introduce inconsistencies is to check non-emptiness of models(D).The Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 461 2009-10-2 Semantics of Domain-Specific Modeling Languages 461 model finding procedure of FORMULA is suited for this task: Perform model finding on the conforms query to check non-emptiness. However, checking non-emptiness of models is only one of the tools available in FORMULA. Many of the composition operators guarantee relation- ships between domains. For example, the composition operators can also be combined to guarantee relationships by construction. For example, given a family of domains (D i ) i∈I and an one-to-one renaming function r : I → Σ,the categorical product can always be built by the construction:  D 1 as r(1) ∗ D 2 as r(2) ∗ ∗D n as r(n)  (14.42) where renaming is used to ensure disjointness of declarations. The categori- cal coproduct can be formed by a similar construction. Figure 14.10 shows the specification of the deterministic finite automaton (DFA) abstraction by restricting the NFA domain. Line 2 declares DFA as a restriction of NFA. Lines 3–6 define the isNonDeter query that is satisfied if there exists a state with two distinct outgoing transitions triggered by the same event. The conforms query is satisfied if isNonDeter is not satisfied. Note that the restricts keyword implicitly conjuncts NFA.conforms onto the conforms query of DFA. 14.3.7 Summary The structural semantics of DSMLs serve as interfaces to the users of model- ing languages and to underlying tool flows. Beyond this, structural semantics facilitate 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 a general framework for understanding the relationship between structural semantics (domains), DSMLs, and metamodels. We have also described a concretization of this framework using structured LP with carefully chosen composition 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, 6. t1.next != t2.next. 7. conforms :? !isNonDeter. 8. } FIGURE 14.10 DFA as a restriction of NFA. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 462 2009-10-2 462 Model-Based Design for Embedded Systems 14.4 Specification of Behavioral Semantics of DSMLs As defined by their structural semantics, models are well-formed struc- tures that can represent domains (in metamodeling) or specific points in domains. While structural semantics of DSMLs are important, they are not sufficient for expressing all essential meanings associated with models. The most important semantic category that needs to dealt with is behavior. For example, 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- 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 controller has a well-defined dynamics that can be described using different mathe- matical formalisms such as differential equations, an impulse response, or a function in the Laplace domain [34]. In general, behavioral semantics need to be represented as an interpretation of the model in a mathematical domain that is sufficiently rich for capturing essential aspects of the behavior (such as dynamics). Explicit representation of structural and behavioral semantics in DSMLs conforms well to all engineering disciplines where the relationship between structure and behavior is extensively studied. Formalization of these two closely related aspects of modeling enables the exploration of fundamental issues in modeling: 1. DSML composition: Given two DSMLs L 1 and L 2 with behavioral semantics X and Y and a composition operator ⊕, create a composite DSML with structural semantics (L 1 ⊕ L 2 ) 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 the models 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) = r  and op Y (r) = r  are also 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 Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 463 2009-10-2 Semantics of Domain-Specific Modeling Languages 463 by structural characteristics. Discovering and testing these invari- ants requires the precise representation of structural and behavioral semantics. In this section, we describe a method for formalizing behavioral seman- tics based on transformational interpretation. As we discussed before, an inter- pretation is a mapping from the model realizations of one domain to the model realizations of another domain: : R Υ → R Υ  (14.45) 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 specifying behaviors • A formal language for specifying transformation between domains Selection of the first component largely depends on the goal of the formal specification. 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 describe how a syntactically correct program is interpreted as sequences of abstract computational 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 model interpreter generates behavior from models. While primitive behaviors are described as sequences of computational steps, complex behaviors need to be defined compositionally as the interaction of behaviors of primitive com- ponents. Detailed treatment of this topic is out of scope for this chapter, we refer interested readers to the literature [5,11]. Another relevant method for specifying behavior is denotational semantics. Denotational semantics of pro- gramming languages provide mathematical objects for representing what programs do (as opposed to how they do it) [35]. For example, the Tagged Signal Model (TSM) provides a denotational framework representing sets of possible behaviors as a collection of events [29]. The primary goal of TSM is comparing models of computation and not simulation or code generation. The second component is the specification of transformations between domains. Since these transformations are syntactic operations, their for- mal specifications can be expressed using a logic-based structural semantics foundation [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 seman- tics based on Abstract State Machines (ASM) [7] and model transforma- tions. We use ASMs for the formal specification of model interpreters and Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 464 2009-10-2 464 Model-Based Design for Embedded Systems 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 for demonstrating the method. 14.4.1 Overview of Semantic Anchoring The outline above suggests that given a DSML L =  Υ, R Υ , C, struc ,   i  i∈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 significant and in direct conflict with the ultimate goal of DSMLs: rapid formulation and evolution of semantically precise, highly domain specific abstractions. The difficulties 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 practical approach to semantic anchoring that enables the reuse of specifications. The approach is based on the recognition that although DSMLs use many dif- ferent modeling abstractions, model composition principles, and notations for 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]: 1. Specification of a  L SU j  j∈J set of modeling languages for the basic behavioral abstractions. We use the term semantic units to describe these languages. The role of the semantic units is to provide a common behav- ioral foundation for a variety of DSMLs (or aspects of DSMLs) that are syntactically different, but semantically equivalent. For example, a number of modeling languages such as IF [37], UPPAAL [4], and Kronos [14] (and many others) have Timed Automata semantics. By specifying a Timed Automata Semantic Unit (TASU) using ASML, we can define semantics for IF, UPPAAL, and Kronos by specifying the transformation between them and TASU (see details in [9]). The clear advantage of this method is that the common semantic domain enables the semantically precise comparison of the different models. 2. Specification of the transformational interpretation  T : R Υ → R Υ ASML between the domains of a DSML L and a selected semantic unit  L SU j  j∈J . Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 465 2009-10-2 Semantics of Domain-Specific Modeling Languages 465 The T transformation “anchors” the semantics of L to the semantic unit  L SU j  . 3. Since the domain of  L SU j  is a subset of the domain of ASML, we can exploit this for a further significant simplification. As we discussed in Section 14.2, a domain is defined by a metamodel expressed in a L meta 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 Data Model expressed using the type language of ASML. The conversion between the two representation forms is a simple syntactic transfor- mation. This approach allows us to specify the model transformation T between the DSML and the selected semantic unit such that their domains are specified using the same formalism provided by L meta . Figure 14.11 shows our tool suite for semantic anchoring. It comprises (1) the ASM-based common semantic framework for specifying semantic units and (2) the MIC modeling and model transformation tool suites, the Generic Modeling Environment (GME), and Graph Rewriting and Transfor- mation Tool (GReAT), respectively, which support the specification of the transformation between the DSML metamodels and the Abstract Data Mod- els (ADM) of the semantic units. As we discussed above, we selected ASMs, formerly called Evolving Algebras [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 employed for defining the metamodels for DSMLs using the Unified Modeling Lan- guage (UML)/OCL-based MetaGME metamodeling language [32,33]. The DSML metamodel DSML model Transf. engine Semantic unit model 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 Instance of Instance of Generated by D r r Є D r T (r) T:D r D SU j r ' D SU j γ ' r' Є D SU j r' FIGURE 14.11 Tool suite for semantic anchoring. [...]...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... International Symposium of VDM Europe on Formal Software Development, 1:164–188, 1991 7 E Börger and R Stärk Abstract State Machines: A Method for High-Level System Design and Analysis Springer-Verlag, Berlin, 2003 8 L P Carloni, F De Bernardinis, C Pinello, A L SangiovanniVincentelli, and M Sgroi Platform-based design for embedded systems In R Zurawski, editor, The Embedded Systems Handbook CRC Press,... 1–3 above, must be performed in sequence; however, the remaining steps, creating all of the transitions assigning the initial locations for each automaton are performed in parallel Figure 14.22 shows the GReAT transformation rule responsible for creating the mode switch transitions in the TASU It is an individual element of the overall transformation, shown to illustrate the form of individual rules... simulation output for the following event trace: 1 2 3 4 5 g_v(t), g_v(t), g_v(t), g_v(t), g_v(t), v(m1_clk, m2_clk) = 3 → {} v(m1_clk, m2_clk) = 4 → {Finish "inc"} v(m1_clk, m2_clk) = 4 → {Finish "dec"} v(m1_clk, m2_clk) = 4 → {Reset "m1_clk"} v(m2_clk) = 4; v(m1_clk) = 0 → {Switch to mode "Down"} 482 Model-Based Design for Embedded Systems 14.4.3 Conclusion The effective application of DSMLs for embedded. .. ModeSwitch 476 Model-Based Design for Embedded Systems domain model as the input and produces a corresponding TASU model as output A transformation in GReAT is formed by a sequence of rules, each of which contains a pattern graph [26] The pattern graph is constructed from the objects defined in the TDL and TASU metamodels Each pattern graph object is assigned an action to perform on matched objects... semantics In Design, Automation, and Test in Europe: The Most 484 Model-Based Design for Embedded Systems Influential Papers of 10 Years DATE, part III, the Netherlands, pp 253–265, 2008 Springer 12 K Chen, J Sztipanovits, S Neema, M Emerson, and S Abdelwahed Toward a semantic anchoring infrastructure for domain-specific modeling languages In Proceedings of the Fifth ACM International Conference on Embedded. .. release for execution, and the other transition with id=“F” denotes a task finishing execution Notice that we create 2n transitions for each task A unique transition for release and finish must be created for each execution cycle in a given mode period (e) Task Reference(Mode) to Transitions (TA): Repeat step 4.d but use TaskReference Figure 14.21 shows the GReAT transformation responsible for anchoring... syntax for model-based development Technical Report MSR-TR-2008-86, Microsoft Research, June 2008 26 G Karsai, A Agrawal, and F Shi On the use of graph transformations for the formal specification of model interpreters Journal of Universal Computer Science, 9(11):1296–1321, November 2003 27 G Karsai, A Ledeczi, S Neema, and J Sztipanovits The modelintegrated computing toolsuite: Metaprogrammable tools for. .. "TUp_inc_r_0", "TUp_Down_sw", etc ) The format of the transition identifier indicates what activity the transition corresponds to: "TUp_inc_r_0" means in mode “Up,” the release of task “inc” at mode time 0, "TDown_dec_f_2" means in mode “Down,” the finishing of execution of task “dec” at mode time 2, and "TUp_Down_sw" means the 480 Model-Based Design for Embedded Systems 1 Mode_Switches(Mode_src... local_clocks) } 6 union {clki − > v(clki) | 7 in local_clocks -(tr.resets intersect local_clocks) } FIGURE 14.14 Execution: Stepping a timed automaton 470 Model-Based Design for Embedded Systems and must set the time_ev event as the only active event for the given automaton The UpdateEvents and GetEvents methods are self-explanatory The PriorityTA and UpdateTimeGaurdTA methods are not predefined functions . precursor for building the categorical product of domains. The expression Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 460 2009-10-2 460 Model-Based Design for Embedded. t2.next. 7. conforms :? !isNonDeter. 8. } FIGURE 14.10 DFA as a restriction of NFA. Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 462 2009-10-2 462 Model-Based Design for Embedded. transforma- tions. We use ASMs for the formal specification of model interpreters and Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 464 2009-10-2 464 Model-Based Design