On the Partitioning of Syntax and Semantics
For Hybrid Systems Tools
Jonathan Sprinkle,Aaron D.Ames,Alessandro Pinto,Haiyang Zheng,and S.Shankar Sastry
ab型
Abstract—Interchange formats are notoriously difficult to finish.That is,once one is developed,it is highly nontrivial to prove(or disprove)generality,and difficult at best to gain acceptance from all major players in the application domain. This paper address such a problem for hybrid systems, but not from the perspective of a tool interchange format, but rather that of tool availability in a toolbox.Through the paper we explain why we think this is a good approach for hybrid systems,and we also analyze the domain of hybrid systems to discern the mantic partitions that can be formed to yield a classification of tools bad on their mantics.The discoveries give us the foundation upon which to build mantic capabilities,and to guarantee operational interaction between tools bad on matched operational mantics.
I.I NTRODUCTION
The study of hybrid systems is an exciting and complex topic for rearch.Generally,hybrid systems
are systems where the model of computation for the entire system is het-erogeneous.When many rearchers refer to a hybrid system, they commonly mean a system with switched discrete states, each of which has its own continuous dynamics.This is the kind of hybrid system to which we refer throughout this paper.The complexity of this specific kind of hybrid system results in all kinds of interesting rearch problems and modeling challenges.Several tools have been developed to address issues of the design of hybrid systems in simulation, controller synthesis,verification,and validation.However, the complexity of each of the aspects of hybrid system design and development is such that no one tool is currently able of providing all capabilities for all class of hybrid systems.
Hybrid systems are more prevalent now than they were, say20years ago,due in large part to the increasing tendency to control continuous process with discrete processors. Previously,control by continuous hardware devices such as resistors,capacitors and inductors,was common,but the advent of embedded processors which are innately discrete (both in terms of execution and analysis)required the domain of computer engineering—relevant to design and program the embedded processors—to acquaint itlf with the domain of hybrid systems,and vice versa.Creating models of computation and tools in the computing world that sufficiently emulate the continuous worl
d is necessary This work is supported by the Large NSF ITR Project on“Foundations of Hybrid and Embedded Software Systems,”award number:CCR-0225610. J.Sprinkle,A.D.Ames,A.Pinto,H Zheng,and S.S.Sastry are with the Department of Electrical Engineering and Computer Sciences, University of California,Berkeley,Berkeley,CA94720. {sprinkle,adames,apinto,hyzheng,sastry}@EECS. Berkeley.Edu in order to accurately control or simulate the systems; the degree of freedom in computing to produce this result, however,means that the designflexibility for each tool can be such that it is nontrivial to“connect”the tools with one another,even when the purpo of tho tools is identical. Becau hybrid systems are interesting on multiple levels of the design ,simulation and code generation)a logical problem was one of using the same model of a system across multiple tools.Depending on the level of abstraction of the design tool,this task was either easier or more difficult. Generally,the more domain-specific a tool,the more likely that design decisions were made which conflict with another tool.On the other hand,the more domain-independent a tool, the more likely that constructs unavailable in other tools may have been ud.
A.HSIF
A previous attempt to join tools together—the Hybrid Systems Interchange Format(HSIF)[1]—was bo
rn in the DARPA MoBIES(Model Bad Integration of Embedded Systems)program.HSIF was designed by committee—resulting in a large syntax and some enhancements which were tool-specific.HSIF,in fact,was defined in terms of existing tools,regardless of their design quality[2]. HSIF was successful in interchanging some models be-tween veral tools(notably Charon[3],CheckMate[4], and HyVisual[5],[6]).Many of the transformations were unidirectional,and,although bidirectionality in a toolchain is not necessarily a requirement,it was highly nontrivial to introduce enhancements to the translators that would allow so-called“round-tripping”during the design pha.Overall, HSIF was not successful in convincing the entire hybrid systems community that HSIF should be a part of the design philosophy of each tool.
B.The Columbus Project
It would be somewhat overstating to claim that HSIF was a failure.However it is true that there were problems with the HSIF philosophy which would have prevented its growth into a fullyfledged interchange format.The problems,and the subtlety with which such an interchange format should be designed,are succinctly discusd in[7],and extensively covered in a Columbus Project report that discuss hybrid systems modeling and interchange issues[8].
C.Integration strategies
The previous interest of tool integration,as addresd by the HSIF effort,was not without its problems.For instance
the design of the solution was immediately constrained by the maturity and design decisions of each tool.One danger of this is that the influence of certain design decisions could make the entire process untenable for all tools.The best example of this is that not all tools allowed hierarchy in the discrete state specifi,state machines to describe the discrete states),and furthermore that the mantics of hierarchical discrete states were not globally accepted.This led to the decision that all HSIF models in the initial version would be restricted to so-calledflattened models (without hierarchy).A further danger is that modifications to a particular tool will then influence the tool integration format(after all,a tool integration format is coupled to the format and capabilities of the tools),which is more uful for tools which are in their“steady state”rather than tho who formats,execution policies,and subtleties are emerging. Examples such as this,as well as a tight coupling with the tool,make the justification of a tool integration strategy quite difficult.We suggest that a better goal is to utilize the capabilities provided by numerical analysis tools,as well as hybrid systems tools,to provide simulation,verification,etc. We draw the analogy to that of a toolbox,where different tools are chon for different kinds of ,a hammer for a nail,a screwdriver for a scre
w).Further extending this analogy,not all kinds of screws and nails are the same.Some nails require different weight hammers,or rubber mallets; some screws areflathead while others require phillips. From the hybrid systems perspective,the designflow for each kind of system is itlf a hybrid system,where discrete switches between simulation,verification,and controller synthesis phas require a different kind of analysis tool.We are certain that the hammer/nail analogy could be extended throughout this paper,but from here onward we choo to switch from the metaphorical to the material aspects of the problem,and address the philosophy of using tools for their capabilities,and not simply becau they exist as a tool. D.Paper goal,and overview
The goal of this paper is to acquaint tho who are familiar with hybrid systems with some of the computer science reasons that a unified model is difficult to achieve across tools,and also to acquaint tho with computer sciences experience why the hybrid systems domain is so difficult to model,due to its complex mantics.Our condary goal is to encourage readers to investigate the tools with which they are familiar—or which they have designed—in the categories that we describe in this paper,in order to determine whether or not they are suitable for integration in our framework,and to encourage them to collaborate to achieve that end.
The organization of the remainder of this paper is as follows.In Section II we give literature and pers
onal per-spective on how to partition the syntax and mantics of hybrid systems bad on the theory in the domain.In Section III we discuss our proposal for a toolbox-style framework, which takes the advice of the literature in its layout and philosophy,and provides a well-defined interface in which to lay out the integration of various tools to take advantage of their capabilities.In Section IV we look to the future, and prent an estimate for the availability of the toolbox for general enhancement and u.Finally,we prent our conclusions.
II.A DDRESSING SEMANTICS
The mantics of a particular hybrid systems model(where here model means an instance in abstraction or reality, such as the canonical water tank problem,or the bouncing ball)varies between experts.Such variances are not always differences in interpretations,but frequently are made to sim-plify pieces of the domain for various reasons.Simplifying assumptions such as the may actually have cascading effect on the ability of a certain notation or tool to adequately model other aspects of a hybrid system,or to allow certain kinds of asrtions to be guaranteed on further reflection. This problem and reasons for limiting such assumptions in particular is addresd in[5],to which we direct the reader for an in-depth discussion with numerous examples and justifications for certain design decisions.
We stipulate that not all design decisions must be the same in order to have broad tool inter-operability.The Metropolis[9]group has spent significant effort to develop a methodology and framework for the specification of formal mantics.Through the u of formal mantics,as well as the judicious u of abstraction,the Metropolis project aims to reduce the complexity of a complete designflow by accommodating multiple models of computation and design constraints.While much of the preliminary work in Metropolis has been applied to electronic-system design (e.g.,processors and embedded hardware),many of the solutions and design abstractions in Metropolis are directly applicable to the world of hybrid systems tools becau of the commonality of mismatched mantics,multiple models of computation,and different application domains of a tool (e.g.,simulation versus verification).
As previously mentioned,some exploration of the com-puting world is necessary to understand why the issues emerge,and how they may be addresd.In order to give more detail on why some mantics should be logically partitioned between tools,and some mantics should be common across all tools,some brief background is required on different kinds of syntax and mantics,as discusd in the following ctions.For more insight into this subtle topic, we refer the reader to Harel and Rumpe[10].
A.Syntax
The syntax of a language describes the allowable expres-sions made up of syntactic elements that can be made in that language.Expressions are made up of syntactic elements (e.g.,in C++,void is a syntactic element),and the syntax of the language describes what ordering and nesting of language elements and expressions are ,in C++,void main(void);is an expression).
By producing a syntax,a language’s notation is able to be formalized,similar to how mathematical notation is formalized.For instance,the statement f(x)=7+x is an
expression in mathematics,and is consistently recognized as a valid syntax for the definition of a function.Even slight deviations in this syntax,though,make the statement ,f((x=7x+,resulting in a statement that is unable to be interpreted in generally accepted mathematics.
B.Semantics
The interpretation of some syntax is what gives it meaning, or mantics.Again,[10]does an excellent job in defining some of the subtleties of mantics as they pertain to language issues.For the purpos
es of this paper,we can identify two similar,yet significantly distinguishable,kinds of mantics that provide some insight into the modeling and execution of hybrid systems.
1)Denotational mantics:The denotational mantics define the mantics of the model,independent of the exe-cution platform.Simply put,the denotational mantics tell the model builder what behavior the model should have. In general,the denotational mantics are in line with or defined by some model of computation,such as dataflow, controlflow,continuous,discrete,etc.For this paper,the denotational mantics are the intuitive interpretation of the hybrid systems domain.
2)Operational mantics:The operational mantics de-fine the mantics of how a model is executed,according to some denotational mantics.Simply put,the operational mantics tell the computer how a model does execute. As such,the operational mantics is technically decoupled from the denotational mantics,to the degree in which the execution platform differs from the model of computation, but practically should exactly reflect the denotational -mantics.For example,a model of computation may allow scheduling of an event at a certain time in the future,but no mechanism exists for this in the operating system;the job of the operational mantics is to produce this scheduling effect with the given interfaces of the operating system.
C.Partitioning the H-tuple
The mathematical notation of hybrid systems is varied,to say the least.In the common hybrid systems literature,a hybrid system is defined as a tuple(frequently referred to as the H-tuple),and the length of this tuple varies according to the specifics of the definition.For example,a hybrid system has been defined1to be the tuple
质量鉴定H=(Q,X,V,Y,Init,f,h,I,E,G,R).(1) where Q is t of discrete variables,X is a t of state variables,V is a t of input variables,Y is a t of output variables,Init is a t of initial conditions,f is a t of ordinary differential equations,h is a t of output functions, I is a t of domains,E is a t of edges,G is a t of guards andfinally R is a t of ret maps.We will avoid a deep 1This definition is bad on that of a previous version of the yet unpublished work The Art of Hybrid Systems,by Lygeros,Tomlin,and Sastry.Since the u of this definition it has been altered to include fewer elements,and we include it here as evidence of the emerging nature of the definition of hybrid systems,as well as to show an extreme example of the often unwieldy notations required to manage the complexity of planation of each of the components of H discusd here, since the purpo is to demonstrate how the tuples defining hybrid systems change in composition more than substance. For example,another tuple defining a hybrid system is given by
H=(H,S)(2) where H is a small category and S is a functor from H to the category of dynamical syste
ms[11].This definition exhibits a significant difference,upon a cursory examination,becau much of the definition is hidden using abstraction techniques, i.e.,the definition of small categories and functors. Prented with the two definitions of a hybrid system—which reprent opposite ends of the notational spectrum—the reader may suspect that there is no commonality between the different definitions of hybrid systems utilized in the literature.In fact,this is not the ca,though there is some truth to the asrtion.All definitions of hybrid systems share the same underlying structure;it is largely the formalization of this structure that changes.
The commonality between most definitions of hybrid systems is that they all have a discrete component:usually in the form of a graph;and a continuous component:a collection of dynamical systems indexed by the vertices of the graph,together with a collection of maps between the dynamical systems,indexed by the edges of the graph.Few rearchers dispute the abstraction of a hybrid system into the well known mathematical constructs.However,there is no uniform way in which the tuple is modeled.We will focus on the different ways in which the continuous component of a hybrid system is specified,interpreted,and executed,since this is where many of the differences ari.
D.Example:Transition Semantics
Although a graph-like reprentation of the discrete por-tion of a hybrid system is common across most(if not all) hybrid systems abstractions,there is a subtle interpretation among simulation and verification tools which is important to distinguish.Namely,the conditions under which the edge e=(q,q )∈E can—or must—be taken are not universal. Using the notation in(1),Guard(q,q )=G e={x∈I q|g e(x)≤0},where I q is the domain of the state q. Abstractly,hybrid systems experts agree that the interction of theflow of the state of the system with some guard,G e, prescribes a discrete change in the behavior of the system. Transition mantics prescribe that some time,t,is the exact time at which a transition takes place.Triggered/as-is mantics enforce t as−is=min{t∈R|g(x(t))=0}. Enabled mantics enforce t enable∈{t∈R|g(x(t))≤0∧x(t)∈I q}.Thus,t as−is is not necessarily equal to t enable(e Fig.1).
Becau triggered/as-is mantics may require a different transition time than enabled mantics,there is the possibility for multiple simultaneously-enabled guards as well as an in-herent nondeterminicity as to the time at which the transition occurs.In verification,the u of enabling mantics can have an advantage becau verification results are broader
x 1(t )
[
]老公生日祝福语
t enable
Fig.1.Flow of the state,x 1(t ),and guard,G e Note that the t as −is is a single point,and t enable is a range of possible values.
than a particular trace.For simulation,the triggered/as-is mantics are convenient becau they provide a way to enforce deterministic ,provide a single trajectory of the system.
While the details of the mantics are implemented in the tools themlves,it is possible to distinguish between the tools bad on their adherence or indifference to triggered/as-is mantics.This differentiation between tools allows for a partitioning of the allowed mantics into different syntax elements,and can give confidence or cast suspicion on the ability of two tools to prod
uce acceptably similar traces.In the rest of this paper,we show how we have partitioned the H -tuple ud to define hybrid systems into logical components that reflect the mathematical concepts (rather than modeling concepts)with which an abstract hybrid system is specified.Our logical partitioning us hierarchical components to hide information (similar to the definition in (2)),and thus us structure and containment as an aid to ensure well-formedness of a definition (e.g.,it is possible to check that each discrete state has a flow,by looking in the discrete state).The choices we made are described next.
III.T HE hyper TOOLBOX FRAMEWORK
The hyper toolbox philosophy is to address issues of oper-ational mantics through configuration of syntax elements.This allows a model builder to ensure that the operational mantics of the constructed model will be compatible with the modeler’s intuitive denotational mantics.We suggest such functionality through strong typing in the syntax tree.A.Syntax
The syntax of hyper is an evolution of that of HSIF,to the degree that many of the concepts emerge from the mathematical definition of a hybrid system,and its domain concepts.As discusd in Section II-C,we cho to partition the definition of the hybrid system into logical components.For brevity we will show only the vector field’s partition.
Fig.2.This model shows a graph which is made up of nodes and edges.Tho nodes may be ud to model discrete states in the hybrid system,which are indicated using the inheritance triangle,which has an exact mantics
(e.g.,‘a DiscreteState “Is A”Node ’).
Fig.3.Complex domains require a functional expression to define their bounds.In the cas,the reader may understand that the type of the object (e.g.,LevelSet ,or SuperSet )determines how the function is ud to form the domain.For example,the same function x 12+x 22−1is interpreted as x 12+x 22−1=0for a LevelSet ,and x 12+x 22−1≥0for a SuperSet .
The syntax of the hyper modeling framework is defined using the MetaGME modeling language [12],[13],which is a metamodeling language ud to define domain-specific mod-eling languages (in our ca,the domain of hybrid systems).By using this approach,we can generate the modeling lan-guage that hyper will u from the definition of what hyper considers to be its own domain.Fig.2shows 2a simplified version of the graph portion of a hybrid system (discusd in Section II-C);Nodes are DynamicalSystems ,and contain one or more Variables (upon which are defined Domains ),and VectorFields .
In the specification of a hybrid system,the vector field de-fines the flow of the state over time,and some kinds of vector fields are shown in Fig.4.In the figure,a VectorField contains a reference to a defined StateVariable (de-noting the state variable upon which this VectorField defines a flow),and the kind of VectorField may be specialized as a CoordinateFunction (ud to define
2A
name in italics is a UML notation to denote abstract ,objects that cannot be instantiated themlves,but who subtypes can be instantiated.
Fig.4.Kinds of vectorfields which may be ud to specify aflow.U of the types allow a correlation between domains and vectorfields,to determine whether a mismatch has occurred during specification,and to provide analysis through external tools.
flows on a manifold defined by an atlas),or as an ODE, which is subtyped in turn by NonlinearODE,in turn AffineODE,and in turn LinearODE.
B.Impact of syntax on mantics
In the previous subction we alluded that certain vector fields were uful when definingflows on certain domains. The u of the strong types allows another feature for which the hyper framework is intended:the integration of tools with certain capabilities to perform analysis—both of the system or controller,and also to confirm that the model of the system or controller conforms to necessary constraints (e.g.,that a VectorField is a ction of the tangent bundle of the manifold defined by an Atlas).Mathematical and computational tools,such as Mathematica and Matlab,will prove uful in this area,but the hyper framework is designed to tie directly into such tools to utilize their capabilities, without requiring the system modeler to be an expert in the field of computational mathematics.The stronger the types (i.e.,the less inference required),the easier it is to export the model to computational tools that include tho types as primitives in their language.
1)Choosing tools bad on equation types:If the VectorFields ud to specify a hybrid system are strongly typed as shown in Fig.4,it is possible to determine the t of tools which can perform simulation,verification, etc.,on models which u certain specific subts of tho types.For example,for Nonlinear,almost all simulation tools are included in the t of usable tools.However,tools such as d/dt[14]and CheckMate[4]are unable to u pure nonlinear equations when running verification algorithms. When considering the linearity of guard conditions,the t of simulation tools is divided
into subts as well,resulting in tho which can u nonlinear guards(among them, Simulink/Stateflow,Modelica,HyVisual,Scicos),and tho which can u only linear guards(including CheckMate and HyTech).Fig.5.The types TriggeredGuardSet and EnabledGuardSet describe whether the contained GuardExpression us triggered/“as-is”mantics,or enabled mantics(e Section II-D).
2)Choosing tools bad on transition mantics:In Sec-tion II-D we discusd triggered and enabled mantics.If the two types of transitions mantics are strongly typed, as shown in Fig.5,it is possible to discriminate tools which are compatible with the mantics of the transitions bad simply on the type of the objects.While this requires more input time from the perspective of the modeler in an open system,it is more simple to request that the modeler choo the toolfirst,and let the transition mantics follow from there,as discusd next.
3)Choosing model components bad on tools:In addi-tion to determining the tools which can be ud bad on existing models,it is also possible to determine the model structure bad on tool constraints.That is,given that a ur wants to u HyVisual for simulation,and CheckMate for verification,it is possible to restrict the t of models which can be created to tho which are linear ODEs and linear conjunction of guard expressions.Then,the ur is then prevented from creating models that will be unusable in tho tools bad on constraints generated from tool configuration definitions.
IV.F UTURE WORK:A DDING TO hyper
The hyper framework is designed to extend with the intro-duction of new elements in the H-tuple.As 开心菜园
new elements for defining domains,vectorfields,ret maps,and guards are introduced(such as stochastic behaviors or disturbances, invariant ts,hyperplanes),there exists a framework in which to introduce them as types,and to partition them in terms of their operational mantics according to their well-understood mathematical denotational mantics. Finally,we hope to integrate ongoing work in the def-inition of a Metropolis metamodel for the interchange of hybrid systems models.This promis to provide an intuitive mantics for how models should be executed,and could produce abstract behaviors of models bad on execution mantics chon in the hyper model.
V.C ONCLUSIONS
This paper details how the H-tuple commonly ud as a notation for the definition of a hybrid system may be partitioned in both syntax and mantics to abstract the components of the definition of a hybrid system into a more intuitive model.By strongly typing the elements of the syntax,and introducing concepts which are more commonly ud to define modeling languages and definitions
of ,operational and denotational mantics), we suggest that the modeling formalism lends itlf to an extensible framework that will grow with the continued introduction of new concepts in the hybrid system domain, and as tools emerge which are designed to analyze,verify,or simulate hybrid systems with specific(or more interestingly, without specific)restrictions on their behavior.
We have also prented a metamodel for our language us-ing the GME modeling framework,which is ud to generate languages from the formal specification of a domain.This provides a rapid way in which to produce prototypes for the modeling language,as well as interfaces for creating models using the hyper modeling language.
At the reading of this paper,we hope the reader will under-stand better some of the complexities which ari from small differences in the intuitive definitions of a hybrid system, and why the differences can stifle the interaction of two modeling tools that were built upon different assumptions in the domain.Further,we hope that the hyper framework will inspire toolmakers to examine their tools and produce a formal operational mantics(coupled with the denotational mantics)which will enable them to integrate their tool into the hyper framework,and thus provide modelers familiar with other tools the ability to utilize the hyper framework as a toolchain or as an alternative simulator.
VI.A CKNOWLEDGMENTS
炒海鲜的做法The authors for this particular paper are a short list of involved rearchers who are members of a special inter-est group that discuss the hyper framework weekly at University of California,Berkeley.Active local members of this group,excluding the authors,include(alphabetically b
y surname)Alessandro Abate,J.Mikael Eklund,Alexander Kurzhanskiy,Edward A.Lee,and Alberto Sangiovanni-Vincentelli.The members contributed greatly to the nti-ment of this paper,if not the contents
Additional thanks are due to G´a bor Karsai of Vanderbilt University,and Oleg Sokolsky of the University of Penn-sylvania,who were the original designers of HSIF,and provided many insightful comments and suggestions over time regarding the hyper effort.
曾莉婷
We also thank the National Science Foundation and Office of Naval Rearch for their support and direction of this hybrid systems rearch.
R EFERENCES
[1]J.Sprinkle,G.Karsai,and A.Lang,Hybrid Systems
Interchange Format(v.4.1.8),Vanderbilt University, www.isis.vanderbilt.edu/projects/mobies/downloads.asp,Jan.
2004.
[2]J.Sprinkle,“Generative components for hybrid systems tools,”J.of
Obj.Tech.,vol.4,no.3,pp.35–40,Apr.2005,Special Issue from GPCE Young Rearchers Workshop.
[3]R.Alur,T.Dang,J.Esposito,R.Fierro,Y.Hur,F.Ivancic,V.Kumar,
I.Lee,P.Mishra,G.Pappas,and O.Sokolsky,“Hierarchical hybrid
modeling of embedded systems,”in EMSOFT’01,First Workshop on Embedded Software,Oct.2001.
[4] A.Chutinan and B.H.Krogh,“Computational techniques for hybrid
system verification,” Automatic Control,vol.48,no.1, pp.64–75,2003.
[5] E.A.Lee and H.Zheng,“Operational mantics of hybrid systems,”
in Proceedings of Hybrid Systems:Computation and Control,8th International Workshop,HSCC2005,r.Lecture Notes in Computer Science,M.Morari and L.Thiele,Eds.,vol.3414.Springer-Verlag, Mar.2005.
[6] A.Cataldo,C.Hylands,E.A.Lee,J.Liu,X.Liu,S.Neuendorffer,
and H.Zheng,“Hyvisual:A hybrid system visual modeler,”University of California,Berkeley,Berkeley,C
A94720,Technical Memorandum UCB/ERL M03/30,July2003.
[7] A.Pinto,A.Sangiovanni-Vincentelli,L.Carloni,and R.Pasrone,
“Interchange formats for hybrid systems:Review and proposal,”
in Proceedings of Hybrid Systems:Computation and Control,8th International Workshop,HSCC2005,r.Lecture Notes in Computer Science,M.Morari and L.Thiele,Eds.,vol.3414.Springer-Verlag, Mar.2005.
82年的拉菲多少钱一瓶[8]L.Carloni,M. D.Di Bebedetto, C.Pinello, A.Pinto,and
A.Sangiovanni-Vincentelli,“Modeling techniques,programming lan-
guages design toolts for hybrid systems,”The Columbus Project, Tech.Rep.DHS4-6,July2004.
[9] F.Balarin,Y.Watanabe,H.Hsieh,L.Lavagno,C.Pasrone,and
A.Sangiovanni-Vincentelli,“Metropolis:An integrated electronic sys-
tem design environment,”IEEE Computer,vol.36,no.4,pp.45–52, Apr.2003.
[10] D.Harel and B.Rumpe,“Meaningful modeling:what’s the mantics
of“mantics”?”IEEE Computer,vol.37,no.10,pp.64–72,Oct.
2004.
[11] A.D.Ames and S.S.Sastry,“A homology theory for hybrid systems:情况说明模板
Hybrid homology,”in Proceedings of Hybrid Systems:Computation and Control,8th International Workshop,HSCC2005,r.Lecture Notes in Computer Science,M.Morari and L.Thiele,Eds.,no.3414.
Springer-Verlag,Mar.2005,pp.86–102.
[12]G.Karsai,M.Maroti, A.L´e deczi,J.Gray,and J.Sztipanovits,
“Composition and cloning in modeling and meta-modeling,”IEEE Transactions on Control Systems Technology,vol.12,no.2,pp.263–278,Mar.2004.
[13] A.L´e deczi,A.Bakay,M.Maroti,P.V˝o lgyesi,G.Nordstrom,J.Sprin-
kle,and G.Karsai,“Composing domain-specific design environ-ments,”IEEE Computer,pp.44–51,Nov.
2001.
[14] E.Asarin,T.Dang,O.Maler,and O.Bournez,“Approximate reacha-
bility analysis of piecewi linear dynamical systems,”in Proceedings of the Third International Workshop on Hybrid Systems:Computation and Control,r.Lecture Notes in Computer Science,vol.1790.
London:Springer-Verlag,Mar.2000,pp.20–31.
