Model-Based Design for Embedded Systems- P47 potx

Nicolescu/Model-Based Design for Embedded Systems 67842_C013 Finals Page 436 2009-10-1 436 Model-Based Design for Embedded Systems Tolerant Systems, Seventh International Symposium (FTRTFT’02), Olden- burg, Germany, LNCS, 2469:205–224, September 2002, Springer, Berlin, Heidelberg. 103. S. Tripakis. Folk theorems on the determinization and minimization of timed automata. Information Processing Letters, 99(6):222–226, September 2006. 104. S. Tripakis. What is resource-aware verification? Unpublished docu- ment, 2008. Available from the author’s web page. 105. S. Tripakis and C. Courcoubetis. Extending promela and spin for real time. In T. Margaria and B. Steffen (editors), Second International Workshop on Tools and Algorithms for Construction and Analysis of Sys- tems (TACAS’96), Passav, Germany, LNCS, 1055:329–348, March 1996, Springer, Berlin, Heidelberg. 106. S. Tripakis and S. Yovine. Analysis of timed systems using time- abstracting bisimulations. Formal Methods in System Design, 18(1):25–68, January 2001. 107. A. van der Schaft and H. Schumacher. An Introduction to Hybrid Dynam- ical Systems. LNCIS, 251, 2000, Springer, Berlin, Germany. 108. B. Wile, J. Goss, and W. Roesner. Comprehensive Functional Verification. Elsevier, San Francisco, CA, 2005. 109. M. De Wulf, L. Doyen, and J F. Raskin. Almost ASAP semantics: From timed models to timed implementations. In Hybrid Systems: Computation and Control (HSCC’04), Philadelphia, PA, LNCS, 2993, 2004, Springer, Berlin, Heidelberg. 110. M. Yannakakis and D. Lee. An efficient algorithm for minimizing real- time transition systems. In Fifth International Conference on Computer- Aided Verification, Elounda, Greece, LNCS, 697, June 1993. 111. J. Yuan, C. Pixley, and A. Aziz. Constraint-Based Verification. Springer, New York, 2006. 112. H. Zhu, P. Hall, and J. May. Software unit test coverage and adequacy. ACM Computing Surveys, 29(4):366–427, 1997. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 437 2009-10-2 14 Semantics of Domain-Specific Modeling Languages Ethan Jackson, Ryan Thibodeaux, Joseph Porter, and Janos Sztipanovits CONTENTS 14.1 Introduction 438 14.2 Domain-Specific Modeling Languages 440 14.2.1 DSML Specification: Informal and Formal 440 14.2.2 Framework for Formal Semantics of DSMLs 442 14.3 Specification of Structural Semantics of DSMLs 443 14.3.1 Structural Semantics in DSMLs 444 14.3.2 Formal Foundations 445 14.3.2.1 Signatures and Terms 445 14.3.2.2 Terms with Types 445 14.3.2.3 Expressive Constraints with Logic Programming 446 14.3.3 An Introduction to Domains and Models 449 14.3.3.1 The Type of a Domain 451 14.3.4 Examining the Contents of Models 451 14.3.4.1 Examples of Negation as Failure 452 14.3.4.2 Boolean Composition of Queries 454 14.3.5 Adding Domain Constraints 455 14.3.5.1 Derived Functions and Logic Programs 456 14.3.6 Domains and Compositions of Domains 458 14.3.6.1 Properties of Compositions 460 14.3.7 Summary 461 14.4 Specification of Behavioral Semantics of DSMLs 462 14.4.1 Overview of Semantic Anchoring 464 14.4.2 Semantic Anchoring Example: Timed Automata 466 14.4.2.1 Timed Automata Overview 466 14.4.2.2 Semantic Unit Abstract Data Model 467 14.4.2.3 Operational Semantics 469 14.4.2.4 Composition of Timed Automata 470 14.4.2.5 TASU Modeling Language 473 14.4.2.6 Semantic Anchoring Example: The Timing DefinitionLanguage 474 14.4.2.7 Anchoring the TDL Modeling Language to the TASU 475 14.4.3 Conclusion 482 Acknowledgments 482 References 483 437 Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 438 2009-10-2 438 Model-Based Design for Embedded Systems 14.1 Introduction Perhaps the most fundamental and persistent difficulty in engineering is misunderstanding between producers and consumers of technology. The computing industry is rife with tales of failed software projects. Bloated projects with obscene cost and schedule overruns mingle with stories of dramatic functional failures due to subtle bugs, incompatibilities, or incom- petence. These problems stand in stark contrast to the requirements of embedded system designs, many of which operate in environments that demand total confidence in their proper and timely function. A large number of methodologies claim to address the deficiencies of software design in general [6,26,30,31]. Many have been successful in controlling some of the complexities of development, though notably far fewer have been tailored to address the specific problems of embedded systems design [8,28]. Embedded systems complicate the software development process in a number of important ways: • Embedded implementations must operate with proven correctness in many environments. The notion of correctness takes on multiple forms. Both hardware and software must be correctly specified, designed, and constructed for the problem at hand. Specifications must correctly characterize the users’ intentions, and the relationships between the behaviors of assembled components must not compromise those intentions. Designs and implementations must be verified against the requirements. Safety-critical embedded systems must also conform to additional requirements imposed by government standards and certi- fication processes. • Embedded systems are heterogeneous. Although we frequently think of embedded systems in terms of small devices, the end result (which is not always small) is the product of large and complex software designs. Even physical interconnections are many and varied between hardware components. Embedded systems require diverse notions of time and data values—a sensor may continuously mon- itor a process in order to precisely capture the time of occurrence for a desired event; an embedded processor may sample and process discrete streams of data; and analog circuitry may combine with digital logic and embedded software to implement a standard communications protocol. The constraints placed on embedded systems designs are also heterogeneous: power, memory, processor load- ing, physical dimensions, bandwidths, numbers of I/O lines, and many more. Distribution adds another dimension to design considerations. Engineers create functional designs and validate them through simulation. Implementation of those designs may exhibit unantici- pated (even catastrophic) behavior when distributed over a network Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 439 2009-10-2 Semantics of Domain-Specific Modeling Languages 439 Plant dynamics models Controller models Specification implementation interface Controller design System-level design Implementation platform design Code HW and network configuration Software architecture models System-level models Specification implementation interface FIGURE 14.1 Simplified design flow for embedded controllers. of independent processing nodes. In current practice, these issues are resolved by costly and time-consuming testing on a physical prototype. A simplified design flow for embedded control systems is shown in Figure 14.1. Heterogeneity of the design objectives (e.g., dynamics, safety, and power consumption) and the need for mitigating design complexity dictates that design progresses along abstraction layers, or “design plat- forms” [8]. The objective of controller design is the construction and verification of Controller Models that meet performance and safety requirements. This step requires modeling plant dynamics, controller dynamics, and ver- ifying the performance and safety criteria using simulation and verification tools. System-level design takes the next step toward implementation. The objective is to select (or design) a software component model and a system architecture that are consistent with the implementation requirements in the controller design. This step requires careful considerations on the effects of the selected interaction model of the software component platform and the execution model of the system platform on the required controller dynamics. The last stage of the design flow is implementation platform design, which includes code generation for the software components from controller models, design of the assignment of the software components and their Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 440 2009-10-2 440 Model-Based Design for Embedded Systems interactions to the computation, and communication resources in the form of a Deployment Model and verification of the implemented system. In each of the stages of the design flow, the actual state of the design is expressed using domain-specific modeling languages (DSML). These languages comprise the required heterogeneous abstractions for expressing controller dynamics, software and system architecture, component behavior, and deployment effects. The models expressed in these DSMLs need to be precisely related to each other via the specification/implementation inter- faces. They need to be analyzable and their fidelity must be sufficiently precise to accurately predict the behavior of the implemented embedded controller. In addition, the design flow is supported by heterogeneous tools including modeling tools, formal verification tools, simulators, test generators, language design tools, code generators, debuggers, and performance analysis tools that must all cooperate to assist developers and engineers struggling to construct the required systems. If the DSMLs are only infor- mally specified then mismatched tool semantics may introduce mismatched interpretations of requirements, models, and analysis results. This is particularly problematic in the safety critical real-time and embedded systems domain, where semantic ambiguities may produce conflicting results across different tools. The goal of this chapter is to discuss the fundamental problems, methods, and techniques for specifying the semantics of DSMLs. 14.2 Domain-Specific Modeling Languages Formal specification of DSMLs promises to extend the reach of DSML-based development techniques to ensure consistent analysis of designs, reuse of models between tools, and to increase the extent to which models can be constructed correctly during design. Numerous studies have shown the ben- efits of dealing with design flaws early in the development process [30]. As a first step, we discuss current techniques used for DSML specification, show examples for the different specification styles, and discuss the key concepts required for the formal specification of DSMLs. 14.2.1 DSML Specification: Informal and Formal Current practice of specifying DSMLs covers a wide range of methods from formal to informal. Starting with the conceptualization of Harel and Rumpe [19], a DSML specification can be expressed as a 5-tuple L =< A, C,S, M S , M C > consisting of abstract syntax (A), concrete syntax (C), syntactic mapping (M C ), semantic domain (S), and semantic mapping (M S ). The abstract syntax A defines the language concepts, their relationships, Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 441 2009-10-2 Semantics of Domain-Specific Modeling Languages 441 and well-formedness rules available in the language. The concrete syntax C defines the specific notations used to express models, which may be graph- ical, textual, or mixed. The syntactic mapping, M C : C → A, assigns syntactic constructs to elements in the abstract syntax. The DSML semantics are defined in two parts: a semantic domain S and a semantic mapping M S : A → S. The semantic domain S is usually defined in some formal, mathematical framework, in terms of which the meaning of the models is explained. The semantic mapping relates syntactic concepts to those of the semantic domain. First, we consider informal and widely used approaches. • Least formally, the specification is implicit: natural language constructs and notations are chosen to represent concepts familiar to users. This approach is the simplest, but also most dangerous. Individual interpretations of language details are guaranteed to differ. Few would argue the adequacy of the fully informal approach for any sizable project or development team. • A common technique used quite extensively in practice is the specification of the abstract syntax A and the M C : C→A syntactic mapping using a model, called a metamodel. The modeling language used for metamodeling is frequently UML Class Diagrams and OCL [32,33] or some other variations of the metamodeling languages (for an overview, see [15]). While this approach represented a major step ahead and had opened up the possibility for developing metapro- grammable tool suites for model-based design [15,27], specification of precise semantics both for the metamodeling languages and for the DSMLs has remained an open problem. • Specification of semantics for various DSMLs have been most frequently done by means of natural language (possibly interspersed with mathematical notations). At a minimum, writing down the semantic ideas and expressing their mathematical meaning reduces misunder- standings between individual developers, though characterization of completeness or consistency of the specification is impossible as languages grow in size and complexity. • Informal semantics for modeling languages can also be defined implic- itly at a lower level by creating code generators for models defined in the language. We loosely define a code generator as any model inter- preter that provides useful machine-executable output. A code generator explicitly defines an executable representation of behavior (or other system aspects, such as data and configuration) for any model. At least four problems mar the practicality of this approach: 1. Observing generated behavior for embedded systems may be difficult—especially when deployed in highly integrated or distributed configurations. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 442 2009-10-2 442 Model-Based Design for Embedded Systems 2. Changes made to the language often require significant and detailed changes to the code generators, which often contain the detailed description of the DSML semantics. 3. Code generators may be developed separately by different developers or teams. Problems arising from inconsistency or incom- pleteness of language interpretations have not been eliminated, only deferred to a later stage of development. This is a step back- ward from the goal to resolve inconsistencies early in the design process. 4. Source code templates are poor documentation, frequently tend- ing toward incomprehensibility. Further, the unrestricted expres- siveness of general-purpose programming languages often leads to undisciplined (but executable) specifications. Clearly, there is a need for the explicit, formal specification of DSML semantics. A formal specification is not only precise, but also manipulable. As such, formal specifications remove ambiguity and enable automated analysis for many design issues at a cost of higher detail. Formal specification of semantics is particularly important in translating models between languages recognized by different tools. In the rest of the chapter we will focus on the formal and explicit specification of semantics of DSMLs. 14.2.2 Framework for Formal Semantics of DSMLs The first step in developing a framework for the formal specification of DSMLs is a more precise definition of modeling languages. Following the discussion in [24], we define a “domain” as the set of all “structurally well- formed models.” A model is a “point” in the domain. A “well-formed model” is a model that satisfies all the constraints imposed on its construction. The set of all well-formed models contains all the meaningful structures of a domain, that is, to say the set of well-formed models defines the structural semantics of a domain. Formally, a domain is 1. A set Υ of concepts, components, or primitives from which models are built 2. A set R Υ of all possible model realizations 3. A set of constraints C over R Υ The model realizations are all the ways that models can be built from the available primitives. The set of well-formed models in a domain is the set of all models that satisfy the constraints. This set construction is written as D(Υ, C) ={r ∈ R Υ |r |= C} (14.1) where the notation r |= C can be read as “r satisfies the constraints C.” Domains frequently carry meaning beyond that of the structure. However, to express meaning in terms of behavior, there must exist a mapping from Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 443 2009-10-2 Semantics of Domain-Specific Modeling Languages 443 models in one domain to models in another domain with existing behavioral semantics. This mapping is called an interpretation . : R Υ → R Υ  (14.2) A single domain may have many different interpretations, and these form a family of mappings ( i ) i∈I . For some model r ∈ R Υ , we denote the i th interpretation of r as r i . The interpretations together with the behavioral semantics of the target domain define the behavioral semantics of the domain. Notice this approach ties model transformation closely to the specification of semantics; in fact any framework that supports model transformations also supports specification of semantics. Based on these notions of domains and interpretations, a DSML L is defined as a 4-tuple comprised of its domain and a possibly empty set of interpretations. L =  Υ, R Υ , C,   i  i∈I  (14.3) Every domain has at least one interpretation, which is the structural interpretation, which defines the structural semantics. DSMLs may have behavioral interpretations and their specification provides the behavioral semantics.Inthe next two sections, we discuss methods for defining structural and behavioral semantics of modeling languages. 14.3 Specification of Structural Semantics of DSMLs The interpretation  struc maps model realizations of a source domain to the Boolean domain where model r of domain R Υ is mapped to {true} upon the satisfaction of Equation 14.1 and {false} otherwise. The structures and interpretations of domains can be extended to describe the process of defining DSMLs via metamodeling.Ametamodel is expressed in a DSML called the metamodeling language. A metamodeling language L meta is a DSML with a special interpretation  meta ,themetamodeling semantics, which maps models to domains: L meta =  Υ meta , RΥ meta , C meta ,   struc ,  meta  (14.4) The interpretation  struc is the same structural interpretation that indicates whether a metamodel r is a well-formed model. If r is well formed, then r meta maps r to a new domain. Note that all other interpretations map models in a domain to models of another domain. To make a mapping from models to domain, as r meta does, a domain of domains must be created. This is beyond the scope of this chapter. See [23] for a more detailed explanation of metamodeling semantics. Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 444 2009-10-2 444 Model-Based Design for Embedded Systems 14.3.1 Structural Semantics in DSMLs DSMLs require a notation (syntax) for expressing models, as is the case for traditional programming languages. However, the use of syntax in DSMLs goes beyond notational convenience. Syntax is used to characterize models with unwanted behavioral properties. It also serves as the basis for model transformations between DSMLs. With these applications in mind, DSML syntax is better understood as a constraint system that identifies behaviorally meaningful models. We call this constraint system the structural semantics of a DSML. Unlike traditional programming languages, the structural semantics of DSMLs may be more general than simple, regular, or context-free languages. The various uses of DSMLs demand a number of key operations on structural semantics: 1. Conformance testing: Test if a model satisfies the structural semantics (constraints) of a DSML. This is analogous to testing if some program text conforms to the syntax of a programming language. 2. Non-emptiness checking: Check if there exists any model that satisfies the structural semantics. This amounts to finding contradictions in the definitions of structural semantics. 3. DSML composing: Given two DSMLs with structural semantics X and Y, a composition operator ⊕, and a property P. Create a composite DSML with structural semantics (X ⊕ Y) such that the composite constraint system satisfies property P. A formal modeling framework may provide many different composition operators as building blocks for creating composite DSMLs. 4. Model finding: Given a DSML X and property P, automatically construct a set of models S, each of which satisfies the property P and conforms to the structural semantics of X. This basic operation can be used for design space exploration and to calculate platform mappings. 5. Transforming: Given DSMLs X and Y and a model transformation T from X to Y, find the constraint system T(X) such that a model m  satisfies T(X, Y) if and only if there exists a model m that satisfies the structural semantics X and m  = T(m) satisfies Y. In other words, m  is the result of transforming m with T;bothm and m  are well formed. These requirements necessitate formalisms that uniformly address structural semantics and model transformations. For example, we must be able to reason about the effects of model transformations on structural semantics. However, model transformations are not constraint systems, but (semi-)operational rewriting procedures. Thus, a purely algebraic formal- ism is not an ideal candidate. Additionally, the non-emptiness checking and model finding operations suggest formalisms for which finite model finding algorithms are known. In this chapter, we describe one formalization of structural semantics based on structured logic programming (LP). LP allows formal constraint Nicolescu/Model-Based Design for Embedded Systems 67842_C014 Finals Page 445 2009-10-2 Semantics of Domain-Specific Modeling Languages 445 systems to be specified in a programmatic style [1,13]. Logic programs have the advantage of being mathematically precise and executable. Therefore model transformations can be captured in the same framework. Our specification language, called FORMULA (Formal Modeling Using Logic Analysis), provides structuring and composition operators for formalizing and composing structural semantics and model transformations. At its core is a well- studied class of LP called non-recursive and stratified. 14.3.2 Formal Foundations 14.3.2.1 Signatures and Terms A function symbol, for example, f(·), is a symbol denoting a unary function over a universe U. We say that f stands for an uninterpreted function if f satisfies no additional equalities other than ∀x ∈ U, f(x) = f(x).LetΣ be an infinite alphabet of constants, then a term is either a constant or an applica- tion of some uninterpreted function to a term. For example, {1, f(2),f(f(3))} are all terms assuming {1, 2,3}⊆Σ. Henceforth, our function symbols will be n-ary to capture relations and other constructs. Constructing terms general- izes for arbitrary arity. Uninterpreted functions form a flexible mechanism for capturing sets, relations, and relations over relations without assigning any deeper interpretations (behavioral semantics) to the syntax. A finite signature Υ is a finite set of n-ary function symbols. The term algebra T Υ (Σ) is an algebra where all symbols of Υ stand for uninterpreted functions. The universe of the term algebra is inductively defined as the set of all terms that can be constructed from Σ and Υ. It is standard to let T Υ (Σ) either denote the term algebra or its universe. A structural semantics provides a term algebra whose function symbols characterize the key sets and relations through uninterpreted functions. A syntactic instance of some structural semantics is a finite set of terms over its term algebra T Υ (Σ). The set of all syntactic instances is then the power set of its term algebra: P(T Υ (Σ)). 14.3.2.2 Terms with Types The power set of terms contains many unintended instances of the DSML syntax. For example, we can encode directed graphs with the two function symbols {vertex(·), edge(·, ·)}. However, the syntactic instance edge(edge(1,2),edge(3,4)) is not a meaningful directed graph, because the edge function was not intended to be applied to edges. Erroneous terms can be eliminated by typing the arguments of uninterpreted functions. In FORMULA we write vertex : (Integer). edge : (vertex, vertex). . their Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 440 2009-10-2 440 Model-Based Design for Embedded Systems interactions to the computation, and communication resources in the form of. See [23] for a more detailed explanation of metamodeling semantics. Nicolescu /Model-Based Design for Embedded Systems 67842_C014 Finals Page 444 2009-10-2 444 Model-Based Design for Embedded. Nicolescu /Model-Based Design for Embedded Systems 67842_C013 Finals Page 436 2009-10-1 436 Model-Based Design for Embedded Systems Tolerant Systems, Seventh International