From Proc. CACSD’94 (IEEE/IFAC Symp. on Computer-Aided Control System Design), Tucson, AZ, March 1994.
c
IEEE
A Modeling Language for Hybrid Systems
James H. Taylor
Odyssey Research Associates (ORA)
301 Dates Drive, Ithaca, NY 14850
jim@oracorp.com
Abstract
1
The general hybrid systems modeling language (HSML)
described here will serve two purposes: to define for-
mally what is meant by the term “hybrid system”,
and to provide the basis for language-based “front
ends” for hybrid system simulation environments. Fea -
tures of HSML include: hierarchical, modular construc-
tion of models; consistent yet distinctive definition of
continuous-time, discrete-time and logic-based compo-
nents; prioritized scheduling of discrete-time compo-
nents; mechanisms for state-event handling; approaches
for dealing with vector-field conflicts and changing order
and structure; rigorous type and range checking; and
a strict semantic basis that permits extensive checking
and validation of the model.
Keywords: Modeling langua ges; hybrid systems; dy-
namical systems; integration methods; discontinuity
handling; modeling and simulation.
1 Intro duction
The language described below is b e ing designed to sup-
port a broad definition of a hybrid system (within the
context of intelligent distributed control), which we
may express informally as being an arbitrary intercon-
nection of components that a re arbitrary instances of
continuous-time, discrete-time and logic-based systems.
HSML is based partially on the modeling environment
provided by Simnon [1]. The reas on Simnon is used as a
starting po int is that it provides an excellent language-
based environment for building hierar chies of intercon-
nected components of various typ e s with a c onsiderable
degree of encapsulation and rigor, which are features be-
lieved to be key ingredients of a solid modeling language
as envisioned here.
In addition to these underpinnings, we have considered
features of the earlier standard CSSL [2], the ACSL
1
Support for this work has been provided by the Advanced
Research Project Agency through the U.S. Army AMCCOM at
Picatinny Arsenal, NJ by Contract Number DAAA21-92-C-0013.
modeling approach [3], and the MEAD paradigm for
component interconnection [4]. Note that a completely
graphical model-building environment isn’t considered –
in part, this is because we believe that the definition of
a language standard should precede the definition of a
graphical standard; in part this is due to a prejudice
that at the lowest component level a language-based
approach is more rigorous, flexible and natural. Thus
a graphical notation fo r connecting components is pre-
sented, and a supporting graphical editor for defining
hierarchical models of hybrid systems would be viewed
as a n important as set (refer to [5] for a co nce pt close to
this philosophy).
In developing and evaluating HSML, it is impor tant to
recognize that there is no claim that one cannot rig-
orously model hybrid systems using other, extant lan-
guages. For example, ACSL [3] can be used to model
hybrid systems of great generality. However, the high-
level features and strict semantics and syntax being for-
mulated for HSML will facilitate and enforce a higher
degree of rigor in hybrid sys tems modeling, thereby en-
suring a greater probability of model correctness. In
this context, note that HSML is being created to be as
simple as possible within the constra ints imposed by the
perceived need for rigor and functionality.
This paper is a companion to [6], which described the
three types of components (CTC = continuous-time
component, DTC = discrete-time component, and LBC
= logic-base d component) and provided two illustra-
tive examples of HSML - a CTC for a s imple electro-
mechanical component with a sta te event handler, and
a composite component (CC) comprised of the electro-
mechanical subsystem and digital sensor and controller
modules. Here we will concentrate on the connection
of components and on modeling language features that
support a broad spectrum of hybrid systems and fea-
tures. It should be stressed that this language is still
under development, and details will be subject to change
as they are finalized. Syntax, in particular, is still an
open questio n.
The remaining sections of this paper are as follows:
Parts 2 and 3 deal with the connection and modeling of
components, and Part 4 describes how to build a system
model. The final section outlines additional considera-
tions needed to complete the definition of HSML.
2 Component Interfaces and
Connections
As mentioned in [6], at the lowest level HSML compo-
nents are “pure” CTCs, DTCs and LBCs. These are
assembled into composite components (CCs), and then
systems. Every component has an interface and a body;
its interface defines the entities that are accessible from
and to the outside, as follows:
1. Primary input/output variables: inpu t and output
signals may be connected to other comp onents’ out-
puts and inputs, respe c tively.
2. Secondary input/output variables: scope and knob
entities can not be connected to other components’
inputs and outputs; rather scope variables may b e
stored and displayed, and knob parameters (con-
stants) may be set/changed arbitrarily using a sup-
porting simulation environment during the defini-
tion of simulation experiments.
At the interface, e very component may have an ar bi-
trary number of inputs and outputs (prima ry and sec -
ondary), of the following types: continuous-time signal,
real number, integer, boolean variable, and character-
string (message). Correspondingly, there ar e five types
of “pure” connections in this for malism, as illustrated
in Fig. 1 and denoted by:
1. Continuous-time signal: 4−→4 Example: input
disturbance connected to tur ret input load
dist.
2. Real number, transmitted at discrete time(s): •−→•
Example: track mgr output theta com connected
to DPID input ref.
3. Integer, transmitted at discrete time(s):
−→
Example: engagement mgr output wh ich one con-
nected to track mgr input threat num.
4. Boolean variable, transmitted at discrete time(s):
⊕−→⊕ Example: input engage connected to en-
gagement mgr input hit it.
5. Character-string (message), transmitted at discrete
time(s):
−→
Example: engagement mgr output
stat connected to system output trac k stat us.
In addition, there are two allowed types of “mixed” c on-
nections, denoted by:
1. Continuous-time signal to real number, transmitted
at discrete sampling time(s): 4−→• Example: tur-
ret output the ta connected to tracker input theta.
2. Real number (transmitted at discrete time(s) a nd
held until the next sample) to continuous-time sig-
nal: •−→4 Example: DPID output command con-
nected to turret input volts.
These mixed connections are pe rmitted to eliminate
the need for explicit modeling of analog-to-digital and
digital-to-ana log converters; if there are reasons to
model these transformations more rigorously, then one
may define a component for each such conversion. Most
simulation environments take care of these conversions
automatically; we assume this to be so in defining
HSML.
3 HSML Component Model
Structure
The interconnect formalism outlined above is supported
by the following general template for defining any type
of co mponent:
<Component_type> <Component_name> is
%
interface
[ input(<name>,<type>,<range>); ]*
[ output(<name>,<type>,<range>); ]*
[ knob(<name>); ]*
[ view(<name>); ]*
end interface;
%
body
declarations
. . . ;
end declaration s;
section_one
. . . ;
end section_one ;
. . . ;
assignments
[ <parameter_name> : <value>; ]*
end assignments ;
end body;
%
end <Component_ name>;
In this example and others in this presentation, the fol-
lowing BNF notation will b e used:
Symbol Meaning
< > delimits an arb itrary syntactic entity
[ ] delimits an optional element
{ } delimits a compulsor y element
* repeat the marked element the appro-
priate number of times
% the text that follows is a comment
The sections decl arations and assignments exist for
sp e c ifying internal variables and assigning para meter
values, respectively. In the interface section, note
that the primary input/output variables must be typed
(‘signal’, ‘real’, ‘integer’, ‘boolean’ or ‘string’) and may
be co ns trained as to range, broadly interpreted to be
a numerical range (<range> = (v min, v max)) or a
set (e.g., <range> = {"high", "medium", "low"} for
a s tring variable).
The component template defined above may be elab-
orated for the specific <C omponent type>s CTC, DTC,
LBC and CC. To do so, the body part of the c omponent
must be comprised of distinct mandatory and optional
sections; these are based on the model formulation un-
derlying each category:
Continuous-time Components (CTCs):
• A CTC may be described by an arbitrary ordinary
differential / algebraic equatio n set:
2
˙x
c
= f
c
(x
c
, u
c
, u
k
, m
j
, b
i
, t)
0 = g
c
(x
c
, u
c
, u
k
, m
j
, b
i
, t) (1)
y
c
= h
c
(x
c
, u
c
, u
k
, m
j
, b
i
, t)
As outlined in [6], x
c
is the sta te vector, y
c
is the
output vector, u
c
and u
k
are numeric input sig-
nals (continuous- and discrete-time, respectively),
m
j
is comprised of symbolic input variables, b
i
rep-
resents boolean inputs, and t is the time; in gen-
eral u
c
, u
k
, m
j
and b
i
are vectors. There are im-
plicit “zero-order holds” operating on the elements
of u
k
, m
j
and b
i
, i.e., these inputs remain constant
between those times when they change instanta-
neously.
• The internal variables to be sp e c ified in the
declarations section include state, local and
flag variables; the first correspo nds to x
c
, the sec-
ond to internal variables to be (for example) con-
strained in range, and flag variables are used for
state-event modeling (below).
• Correspondingly, CTC comp onents may include
initial ...end initial; dynamics ...end
2
The specific class of CTC that can be modeled depends on the
simulator’s integration methods. Many cannot handle even index
1 DAEs (as in Eqn. (1)), in other words, they cannot simultane-
ously integrate the ordinary differential equation ˙x
c
= f
c
(· · ·) un-
der the constraint 0 = g
c
(· · ·). Integration routines have been de-
veloped for Index 1 systems; cf. [7]. Higher index models present
additional difficulties [8, 9].
dynamics; constraints ...en d constraints;
and output ...end o utput; sections. The first
section is provided for initializing the model includ-
ing its state; the rest correspond directly to the
sections of Eqn. (1).
• a CTC may include sections for rigorous handling
of unpredictable state events (e.g., mechanical sub-
systems eng aging and disengaging [10]). These sec-
tions have the structure:
event(<signal_variable>)
negative-to-positive
. . . ;
end negative-to -positive;
positive-to-negative
. . . ;
end positive-to -negative;
end event;
where <sig nal
variable> must be declared to be
of type flag in the declara tions section of the
CTC, and it characterizes the state event by a zero-
crossing condition,
S(x
c
, b
i
, m
j
) = 0 (2)
where S is a general expression involving the
state and perha ps boolean variables and modes
of the CTC model. The arbitrary result of
the state event in the CTC model can be
represented in the negative-to-positive and
positive-to-negative subsections, or a simple
switching variable (e.g. sgn) may be set therein
and that variable may be used in arbitrarily com-
plicated expressions of the form if sgn > 0.0
then do . . . else do . . . endif; in
the dynamics sectio n.
• Suppo rt for models that undergo structural changes
(e.g., changes in the definition or number of state
variables) will be provided. In the case of mechan-
ical subsystems engaging, the number of states de-
creases, producing a “higher-index” model that can
be characterized by c onditional constraint equa-
tions and may be reduced using the Pantelides algo-
rithm [11] to automatically reduce it to state–space
form.
Note that none of the above itemized sections are
mandatory; e.g., a CTC need not include con-
straint equations, thereby eliminating the need for a
constraints ...en d constraints; section. A signif-
icant e xample CTC model in included in [6 ].
Discrete-time Component s (DTCs):
• A DTC may be described by an arbitrary difference
equation set:
x
k+1
(t
k
) = f
k
(x
k
, u
c
, u
k
, m
j
, b
i
, k)
0 = g
k
(x
k+1
, u
c
, u
k
, m
j
, b
i
, k) (3)
y
k+1
(t
k
+ δ
k
) = h
k
(x
k+1
, u
c
, u
k
, m
j
, b
i
, k)
where x
k
is the discrete state vector, k is the index
correspo nding to the discrete time point t
k
, y
k+1
is
the output vector, and u
c
, u
k
, m
j
, b
i
are as above.
There are implicit “sampling” opera tors acting on
u
c
, i.e., the input value u
c
(t
k
) is used in updating
x
k
. The times t
k
are usually – but not necessarily
– uniformly spaced (t
k
= k ∗ T
s
where T
s
is the
“sampling time”); in any case we assume that the
upda te times can be anticipated and included in the
component model. Note that there may be compu-
tational delays δ
k
in the output equation, modeled
with an a rbitrary degree of realism.
• The internal variables to be sp e c ified in the
declarations section include several that are com-
mon to CTCs, i.e., state and local variables; as
befo re, the first corresponds to x
k
, and the sec-
ond to internal variables to be (for example) con-
strained in range. Additional variables to be de-
clared are: tsample (the internal variable defining
the time of next update), tdelay corresponding to
δ
k
in Eqn. (3), and priority which establishes the
precedence order of exe c ution of DTC and/ or LBC
modules that may always or sometimes have coin-
cident execution times.
• Corresponding to
the parts in Eqn. (3), DTC components may in-
clude initia l ...end initial; upda te ...end
update; and const raints ...en d constraints ;
sections.
• Note that DTCs are easier to emulate in a digita l
simulation environment; therefore, we do not antic-
ipate that special features for state-event ha ndling
will be required.
• Suppo rt for models that undergo structural changes
(e.g., changes in the definition or number of state
variables) will be provided.
This component type repre sents a particular digital
module c lass that is reserved for pure numerical compu-
tations. The advantages of this particular taxono my are
that (i) the detailed structure of Eqn. (3) can be fully
supported, and (ii) such components c an meaningfully
be linearized and analyzed while, in general, logic-based
components (below) cannot.
Logic-based Components (LBCs):
• Each LBC may have numeric and/or symbolic in-
puts, symbo lic outputs, and symbo lic internal vari-
ables called “modes”. At this point, it is not c le ar
that these components have a “generic form” in
mathematical terms as above except in terms of
the categ orization of input and output variables.
Thus we formally write
m
j+1
= Φ
j
(m
j
, u
c
, u
k
, j) (4)
where m
j
is the mode vector, j is the index c orre-
sp onding to the discrete event triggering the LBC
action, Φ
j
is a completely undefined relationship,
and u
c
, u
k
are as a bove. The output of each LBC
is the mode m
j
which changes instantaneously at a
discrete event (e.g., triggered by an event in a CTC
such as a zero-crossing); in contrast to the situation
in DTCs, we assume that the update times (mode
changes) often can not be anticipated. There may
be a computational delay between the trigger event
and the mode change; this may be modeled with
varying degrees of realism, fr om a fixed delay time
to an actual emulation of the computational burden
required in handling the event.
• LBCs may also exhibit unpre dictable state-event
or dis c rete-event be havior – provision will provided
for this a s in the continuous-time case.
• The lack of a unifying paradig m for log ic-based
components will, at this time, pre c lude pr oviding
more than a “shell” definition for this class of com-
ponent; attempting to s pecify the structure of LBC
models beyond the general template above is thus
inadvisable.
Composite Components (CCs):
• Each CC may have inputs and outputs s pecified
as in the case of the pure CTC, DTC and LBC
components. The example in Fig. 1, and the corre-
sp onding textual description in [6], illustrates this
type of co mponent.
• the CC-specific element of the body section is
the conne ctions ...end connections; section,
whose function is obvious.
4 Building a System
A system is simply completed using the component
models of the above types, as follows: First, pure and
composite c omponents are built to model every part of
the system, as outlined in the prec e ding sections. Then,
signal generator s are created for every component input
that needs to be defined in this way, of w hatever typ e is
appropriate (e.g., a CTC signal generator would be used
to generate a sine-wave continuous-time input). Finally,
a Sy stem is defined using the same paradig m as in the
CC definition outlined above, with the additional con-
dition that a System may not have input variables in
its interface. Such a model is then ready to run under
a s uita ble simulation environment.
5 Conclusion
The following co mments have governed the develop-
ments outlined in the body of this pape r:
• HSML should naturally lack many of the features
of modern general-purpose high-level languages:
– to avoid exce ssive complexity and unnecessary
detail, and
– to allow model-specific support (see below).
• Ancillary modeling support should include:
– syntactic checks (e.g., is there a state differen-
tial e quation corresponding to each declared
state variable, do all input/output connec-
tions involve consistent variable types ), and
– semantic checks (e.g., detection of algebraic
loops, checks for the correct use of struc-
tures for state-event handling, model struc-
tural changes, etc.)
• Note that some of the features of the modeling
language outlined above impose significant require-
ments on the corresponding algorithms for numer-
ical integration.
• In addition, there are many suppor t feature s that
would add to the facility and effectiveness of HSML;
for example, these include a graphical connections
editor, automatic template generation for CTC,
DTC, LBC and CC components, and a lang uage-
sensitive editor to provide preliminary elimination
of syntactic and elementary semantic errors.
For further detail and for discussions of adva nce d fea-
tures of HSML, refer to [14]. Also, see [13, 12] for re-
lated modeling issues including a more object-oriented
approach to modeling than that presented here.
References
[1] Elmqvist, H., “SIMNON - An Interactive Simula-
tion Program for Non-Linear Systems”, in Proc. of
Simulation ’77, Montreux, France, 1977.
[2] Augustin, D. C., Strauss, J. C., Fineberg, M. S.,
Johnson, B. B., Linebarger, R. N., and Sansom, F.
J., “The SCi Continuous System Simulation Lan-
guage (CSSL)”, Simu lation, Vol. 9, No. 6, Decem-
ber 1967.
[3] Advanced Continuous Simulation Language
(ACSL), Reference Manual. Mitchell & Gauthier
Associates, Concord MA 01 742.
[4] Taylor, J. H., Frederick, D. K. Rimvall, C. M. and
Sutherland, H. A., “The GE MEAD Computer-
Aided Control Engineering Environment”, Proc.
IEEE Symposium on CACSD, Tampa, FL, Decem-
ber 16, 1989.
[5] Marttinen, A., ISEE Interface to Simnon, Control
CAD, Espoo Finland.
[6] Taylor, J. H. “Toward a Modeling Language Stan-
dard for Hybrid Dynamical Sys tems”, Proc. 32nd
IEEE Conference on Decision and Control, San
Antonio, TX, 15-17 December 1993.
[7] Brenan, K. E., Campbell, S. L. and Petzold, L.
R., Numerical Solution of Initial Value Problems
in Differential-Algebraic Equations, North Holland,
1989.
[8] Mattsson, S. E. and S¨oderlind, G., “A New
Technique for Solving High-Index Differential-
Algebraic Equations Using Dummy Derivatives”,
Proc. CACSD’92, IEEE Computer-Aided Control
Systems Design Conference, Napa, Calif., pp. 218–
224, March 17–19, 1992.
[9] Campb e ll, S. L., “High Index Differential Algebraic
Equations”, preprint/report, Dept. of Math, North
Carolina State University, Raleigh NC 27695-82 05,
June 1993; slc@math.ncsu.edu.
[10] Cellier, Francois, “Combined Continuous/Discrete
System Simulation by Use of Digital Computers:
Techniques and Tools”, PhD Thesis, Swiss Federal
Institute o f Technology, Zurich, Switzerland, 1979,
Number ETH 6438.
[11] Pantelides, C.C., “The Consistent Initialization of
Differential-Algebraic Systems,” SIAM Journal of
Scientific and Statistical Computation, 9, No. 2,
pp. 213–231, 1988.
[12] Mattsson, S. E. and Andersson, M. “The Ideas Be-
hind Omola”, Proc. CACSD’92, IEEE Computer-
Aided Control Systems Design Conference, Napa,
Calif., pp. 218–2 24, March 17–19, 1992.
[13] Cellier, F. E., Elmqvist, H., Otter, M. and Tay-
lor, J. H., “Guidelines for Modeling and Simulation
of Hybrid Systems”, Proc. IFAC World Congress,
Sydney Australia, 18–23 July 1993.
[14] Taylor, J. H. A Rigorous Modeling Language
for Hybrid Systems, Odyssey Research Associates,
Inc., December 1993.
