1 Introduction
Hybrid systems are dynamical systems with continuous evolution of states and discrete evolution of states and governing equations. We have been developing a modeling framework of hybrid systems based on the notion of Constraint Programming. Our goal is to establish a constraintbased paradigm in which (i) to describe diverse phenomena found in physical, cyberphysical, and biological systems using logical formulae involving equations and inequations and (ii) to solve or verify them using search techniques represented by constraint propagation.
Our motivation has been to establish, in the field of hybrid systems, a declarative programming paradigm that directly handles as source programs highlevel description of problems in mathematical and logical formulas, as opposed to traditional formalisms based on automata and Petri Nets [4][1]. A similar approach was first taken by Hybrid CC [3], and we have made a lot of experiments on Hybrid CC programming. However, we found that it was not necessarily straightforward to specify constraints that a system consisting of alternate discrete and continuous phases should satisfy, and this lead us to design a new language that enables a concise description of hybrid systems.
Since the basic design of HydLa was established in 2008 [9], we studied the details of the language through the description of a number of examples [5], developed a simulation algorithm [8] and a prototype implementation, and explored technologies for implementing discrete changes with guaranteed accuracy [6]. All those studies contributed to the clarification of the essence and subtle points of the HydLa language specification. Based on those experiences, this paper formulates the declarative semantics of the core of HydLa, and discusses its descriptive power and properties by means of examples.
2 Overview of HydLa
HydLa is a declarative language for hybrid systems. Its objective is to allow one to provide the mathematical formulation of a given problem with minimal modification and to simulate or analyze them. For the design principles and related work of HydLa, the readers are referred to [9].
Dynamical systems that HydLa aims to handle are in general represented as a countable number of realvalued functions , , … that include integervalued functions as a special case. A HydLa program imposes constraints on the behavior of those functions (hereafter called trajectories) that may cause continuous or discrete changes over time. The declarative semantics of a HydLa program is defined as a satisfaction relation between trajectories and , or equivalently, the set of all ’s that satisfy .
In order to describe hybrid systems in a concise manner, the use of hierarchies to represent defaults and exceptions will play an important role exactly as in knowledge representation and objectoriented design. Consider a ball bouncing on a floor. The change of the velocity of the ball is determined by the gravity most of the time (default), while it is determined by the collision equation when the ball hits the floor (exception). A mathematically concise way to describe solution trajectories of such systems in a welldefined matter would be to introduce partial order between candidate sets of equations that the system should satisfy and to take a maximally consistent element of the partially ordered set (poset) of sets of constraints. HydLa’s design principle is exactly based on this idea.
INIT  
PARAMS  
FALL  
BOUNCE  
Figure 1 shows the description of a bouncing ball in HydLa. The first four lines are the definition of constraint modules. Constraint modules are program units which are combined to form a set of constraints and to which priorities may be given. In the righthand side constraints, the postfix ‘’’ stands for a time derivative, the postfix minus sign stands for the leftside limit of a trajectory, and stands for an always temporal operator. All the constraints stand for constraints at time 0. However, since the constraints other than INIT start with , they hold at all time points on and after time 0. A constraint with an implication (such as BOUNCE) is called a conditional constraint. A conditional constraint prefixed by an imposes its consequent exactly when its antecedent (guard) holds.
The final line combines the four constraint modules. A comma stands for composition without priorities, while << gives a higher priority to BOUNCE than to FALL. In this example, all the four constraints are taken when the ball is in the air, while will be taken as the maximally consistent set when the ball hits the floor because FALL and BOUNCE become inconsistent.
This example is known to exhibit a Zeno behavior, an infinite number of discrete changes within a finite amount of time, beyond which the simulation normally does not proceed.
3 Basic HydLa
We consider the semantics of Basic HydLa whose syntax is shown in Fig. 2. Basic HydLa simplifies HydLa [9] as follows:
(program)  
(module set)  MS  
(definitions)  DS  
(definition)  
(constraint)  
(guard)  
(expression) 

For each time point, HydLa chooses a consistent set of constraint modules that satisfies the priority constraint and that is maximal with respect to the set inclusion relation between constraint modules. More specifically, from a relative priority relation between constraint modules, HydLa first derives a poset whose elements are admissible (with regard to constraint priorities) sets of all the subsets of constraint modules [5], and then chooses a maximal consistent element. Basic HydLa does not handle this derivation but assumes that the “(irreflexive) poset of sets of constraint modules” is directly given in a program together with the definitions of constraint modules. Default constraints such as the continuity of trajectories (frame axioms, see Section 6.1) are to be explicitly specified within this poset. The constraints at the top of a constraint hierarchy should often be treated as required constraints that must be adopted, and whether to do so can be expressed explicitly within the poset.

Basic HydLa does not support the time shift (i.e. delay) operator ‘’. We can use the feature explained in the next item instead.

To enable dynamic creation of trajectories, Basic HydLa introduces an existential quantifier for local variable creation. This enables us to dynamically create a timer with which to represent a delay between the detection of some condition and the issue of a new constraint.

Basic HydLa does not support program definitions since they can be simply inlined.

For the same reason, Basic HydLa does not support the operator to generate a family of trajectories.
We assume that a Basic HydLa program satisfies , where is the set of modules appearing in MS and is the set of lefthand sides of DS. In the following, we consider a set DS of constraint module definitions as a function from module names to constraints.
As shown in Fig. 2, we restrict the guard constraints to atomic constraints and their conjunctions. HydLa does not specify the class of constraints that can be described in a program. In this sense, HydLa is a language scheme that parameterizes constraint systems. The reason why we allow only as a temporal operator is that our syntax is targeted at the modeling of systems. Other temporal operators such as will be included in the specification language when we construct a verification system that use HydLa as a modeling language.
4 Declarative Semantics of Basic HydLa
As shown in Section 2, the declarative semantics of HydLa is defined as a relation meaning that a given trajectory (or interpretation) satisfies a program (or specification). The information to be maintained by the declarative semantics depends on design criteria such as what class of programs it deals with and what degree of compositionality (i.e., the ability to compose the overall semantics from the semantics of components) it aims at. The semantics in [9] dealt with programs containing no operators in the consequents of conditional constraints. Parameters and behaviors of systems with a finite number of components and no delays can be described by constraints with ’s only in their prenex positions. When those programs contain conditional constraints, their consequents hold exactly when the antecedents hold, which means that a maximal consistent set of constraints can be chosen at that time.
However, a constraint whose consequent includes an leaves the consequent as a candidate for choice even after the corresponding antecedent ceases to hold. If we have to judge which consequents of constraints should be chosen in the future when the corresponding antecedents held, it would be a lookahead of the future. Thus the choice of a maximal consistent set must be performed not when constraints are discharged but when the constraints are actually applied. Therefore we further refine our semantics in the following way.
First, we identify a conjunction of constraints with a set of constraints; i.e., we view the syntax of a constraint in Fig. 2 as
and also allow an empty set. By Skolemization, we recursively eliminate existential quantifiers except for those occurring in the consequents of conditional constraints.
Next, we consider constraint sets as functions of time. For example, a constraint that occurs in a program is regarded as a function , .
For a constraint that is a function of time, the closure is defined as a function that satisfies the following properties:

(Extension) ;

(closure) ;

(Minimality) For each , is the smallest set that satisfies the above two conditions.
For for example, we have , .
The constraint set that determines a solution trajectory of a HydLa program may change over time for two reasons: one is that a maximal consistent set may change; the other is that the consequent of a conditional constraint is newly added when its antecedent holds. The choice of a maximal consistent set in the former case is performed independently at each time point. By contrast, when the program has a constraint whose consequent begins with , whether the constraint is active or not depends on whether its antecedent has been activated in the past; hence the state of a system should maintain the activation history of the antecedents. Therefore it is appropriate to consider a satisfaction relation stating that a program is satisfied by a pair of a solution trajectory and the constraint module definition recording the activation of antecedents. We define this relation as shown in Fig. 3.
(i)  
(ii)  
(iii)  (s0)  
(s1)  
(s2)  
(s2)  
(s2)  
(s2)  
(s3)  
(s3)  
(iv)  For each and , is the smallest set  
that satisfies (i)–(iii). 
The principle of the declarative semantics in Fig. 3 is the consistencybased adoption of constraints. It requires that, at each time point, a consistent set of constraint modules with a maximal preference must be adopted and satisfied.
Condition (i) requires to satisfy the closure property, and Condition (ii) requires to be an extension of . Now we look into Condition (iii) closely. The order of the quantifiers at Line (s0) allows to choose, at each time point, a different set of candidate modules from the constraint hierarchy. Line (s1) means that, at time , satisfies some set of candidate modules in the constraint hierarchy. Lines (s2) mean that there is no trajectory that behaves exactly as before and satisfies a better candidate module set than at . Lines (s3) mean that, when the antecedent of a chosen conditional constraint holds, is extended by expanding its consequent into the definition of the corresponding module in . If a member of the consequent (regarded as a set of constraints) begins with , it is further expanded by the closure condition (i). Also, if it begins with , the quantifier is eliminated by using a Skolem function. Condition (iv) requires the minimality.
5 Examples
Using simple examples, we explain how the declarative semantics actually defines solution trajectories and the constraint sets used to determine them.
Example 1: The first example shows how the arrival of a monotonically increasing function value at a certain threshold is reflected to another function with a delay.
Here, f is a function that expresses the elapsed time, a is a timer invoked by as the trigger, and g is a pulse function that is usually 0 but momentarily becomes 1 two seconds after the invocation of the timer. The solution trajectory expresses those behaviors of f, a (whose Skolem function is also called a here), and g. Now we see all the constraints that are stored in . At , consists of , , and the constraint C with the leftmost removed. At , , , , , and are added to them. At , , , and are removed. At , replaces . At , is replaced by again; the other constraints that remain are , and the two conditional constraints.
Example 2: The declarative semantics presented in the previous section disallows the propagation of constraints to the past. This may be obvious from the construction of the semantics, but we confirm it by using an example since it is an important property.
leaves the initial value of x undefined. We check whether the constraint x=1 imposed by F at propagates to the past by the effect of in E. We consider the following three cases as candidates for solution trajectories.

and satisfy all the constraints D, E, and F at all times.

and satisfy all the constraints except at and satisfy D and E at .

, , and satisfy all the constraints except at and satisfy D and F at .
Case 1 is a solution since it obviously satisfies the maximality. Cases 2 and 3 obviously satisfy the maximality except at , and there are no better solutions than these. Neither of them is worse than the other at , and there are no other solutions that satisfy all the constraints; hence both of them are maximal. In other words, any of Cases 1 to 3 is a result of “extending a solution along the time axis so the maximality is satisfied,” and is therefore a solution to .
6 Discussions on the Specification and the Semantics of the Language
6.1 Differential Constraints
The basic principle of HydLa to utilize existing mathematical and logical notations as much as possible suggests that the precise meaning of the notations should also conform to mathematical conventions. For example, at the time point where a piecewise continuous trajectory causes a discrete change, we do not consider the trajectory differentiable even if it is differentiable both from the left and the right, and we do not deactivate the differential constraints at that time point. We also assume only the right continuity and right differentiability at the initial time.
For the reasons above, the priority of the differential constraints of a piecewise continuous function should in general be lower than that of the constraints describing discrete changes. On the other hand, for a continuous trajectory after a discrete change to be welldefined as an initial value problem of an ordinary differential equation, we need to assume the right continuity at the time of the discrete change. Since the differential constraints are deactivated when a discrete change occurs, we also require left continuity to be able to decide the value of a trajectory. Accordingly, HydLa assumes both the right and the left continuity of trajectories described by differential constraints. Since these two continuity constraints are automatically entailed whenever a trajectory is differentiable, we assume them separately with a priority higher than differential constraints.
6.2 Expressive Power of HydLa
Although the primary purpose of HydLa is to describe piecewise continuous trajectories, we can define various trajectories or sets of trajectories using HydLa’s constraints and constraint hierarchies.
6.2.1 Trajectories defined without using differential equations
HydLa allows us to describe trajectories without using differential constraints. For example, a drifting parameter can be described by a constraint , which represents the set of all trajectories whose range is .
Note that a trajectory defined by the above constraint may not be continuous. Hence, a trajectory defined by is not guaranteed to satisfy between time and . By adding a constraint (we do not add any constraint on b), a stands for a set of all continuous and differentiable trajectories whose range is , and is guaranteed to intersect with f.
A pulse function is another example defined without differential constraints. An example of a pulse function is g of Example 1 (Section 5). Pulse functions play a significant role in representing the occurrences of events. Since pulse functions are not rightcontinuous at the time of discrete changes, we conjecture that a trajectory after the discrete change cannot be defined directly by a differential equation. The following example shows that one of the attempts to define a pulse function b fails:
Based on the discussion in Section 6.1, between two sets of constraint modules in , there exist several sets with additional constraints on the continuity including the right continuity of b. At , the set is not satisfiable but with the right continuity of b is satisfiable, and holds from the first constraint of J. However, then, the greatest lower bound of the time when the guard of the second constraint of J holds is . The consequent of the constraint is thus activated at and contradicts the right continuity. Now suppose we drop the assumption of the right continuity. Then it turns that () is consistent for all . Therefore, although there exists a solution trajectory, HydLa fails to guarantee its uniqueness.
6.2.2 Zeno behaviors
Let us reinvestigate the bouncing ball example in Section 2 based on the declarative semantics of Section 4. Although the program in Fig. 1 specifies a unique solution trajectory until the Zeno time, after that, it allows a trajectory that falls through the floor. We need some additional rules to specify the behavior after the Zeno time [10]. In HydLa, we can define it as , though checking the guard condition would need a special simulation method, e.g., in [7].
The following program shows another method for detecting the Zeno time. It checks the convergence of a function vmax that holds the velocity at the last bounce.
This example shows that the left limit operator ‘’ is also useful for a function that only causes discrete changes.
7 Conclusions and Future Work
This paper presented the declarative semantics of HydLa, a hybrid constraint language with hierarchical structure, described its mechanisms and consequences by means of examples, and discussed the language features and expressive power.
The semantics given in this paper regards trajectories as functions over time. On the other hand, the theory of hybrid systems often adopts hybrid time that allows more than one discrete change at a single time point [2]. One of the motivations of hybrid time is to model computation involving multiple steps at the time of a single discrete change. However, because HydLa is constraintbased, such evolution can be represented as constraint propagation rather than state changes. Another motivation of hybrid time is to deal with the stability and convergence of trajectories in a declarative framework. This would require the extension of our semantics with hybrid time, which is a topic of future work.
We are currently working on the formulation and its implementation of a simulation algorithm corresponding to our declarative semantics. The resulting system is planned to exploit the flexibility of constraint programming and its affinity to interval computation.
Acknowledgments The design of HydLa has received constant feedback from the theoretical and implementation work and daily discussions of the past and present members of the HydLa project. This research is partially supported by GrantInAid for Scientific Research ((B) 20300013), JSPS, Japan.
References
 [1] David, R. and Alla, H.: On Hybrid Petri Nets, Discrete Event Dynamic Systems, Vol. 11, No. 1–2 (2001), pp. 9–40.
 [2] Goebel, R., Sanfelice, R. G., Teel, A. R.: Hybrid Dynamical Systems, IEEE Control Systems Magazine, Vol. 29, No. 2 (2009), pp. 28–93.
 [3] Gupta, V., Jagadeesan, R., Saraswat, V. and Bobrow, D.: Programming in Hybrid Constraint Languages, in Hybrid Systems II, LNCS 999, SpringerVerlag, 1995, pp. 226–251.
 [4] Henzinger, T. A.: The Theory of Hybrid Automata, in Proc. LICS’96, 1996, pp. 278–292.
 [5] Hirose, K., Otani, J., Ishii, D., Hosobe, H. and Ueda, K.: Modeling techniques of Hybrid Systems using Constraint Hierarchies, in Proc. 26th Annual Conference of Japan Society for Software Science and Technology, 2D2, 2010 (in Japanese).
 [6] Ishii, D., Ueda, K., Hosobe, H., Goldsztejn, A: Intervalbased Solving of Hybrid Constraint Systems, in Proc. ADHS’09, pp. 144–149, 2009.

[7]
Ohno, Y., Ishii, D. and Ueda, K.:
A Method of Deriving Zeno States in Hybrid Systems
using Formula Manipulation and Quantifier Elimination,
in
Proc. 22nd Annual Conference of the Japanese Society for Artificial Intelligence
, 1D13, 2008 (in Japanese). 
[8]
Shibuya, S., Takata, K., Hosobe, H. and Ueda, K.:
An Execution Algorithm for the Hybrid System Modeling Language HydLa,
Computer Software, Vol. 28, No. 3 (2011), pp. 167–172 (in Japanese),
https://www.jstage.jst.go.jp/article/jssst/28/3/28_3_3_167/_article/. 
[9]
Ueda, K., Ishii, D. and Hosobe, H.:
Constraintbased Hybrid System Modeling Language HydLa,
in Proc. 5th Symposium on System Verification,
Research Center for Verification and Semantics, AIST, 2008, pp. 1–6
(in Japanese),
https://www.ueda.info.waseda.ac.jp/~ueda/pub/HydLaSSV2008.pdf.  [10] Zheng, H., Lee, E. A., Ames, A. D.: Beyond Zeno: Get on with It!, in Proc. HSCC 2006, LNCS 3927, SpringerVerlag, pp. 568–582, 2006.
Comments
There are no comments yet.