<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>An Abstract Block Formalism for Engineering Systems?</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Ievgen Ivanov</string-name>
          <email>ivanov.eugen@gmail.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Paul Sabatier University</institution>
          ,
          <addr-line>Toulouse</addr-line>
          ,
          <country country="FR">France</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Taras Shevchenko National University of Kyiv</institution>
          ,
          <country country="UA">Ukraine</country>
        </aff>
      </contrib-group>
      <fpage>448</fpage>
      <lpage>463</lpage>
      <abstract>
        <p>We propose an abstract block diagram formalism based on the notions of a signal as a time-varying quantity, a block as a signal transformer, a connection between blocks as a signal equality constraint, and a block diagram as a collection of interconnected blocks. It does not enforce implementation details (like internal state-space) or particular kinds of dynamic behavior (like alternation of discrete steps and continuous evolutions) on blocks and can be considered as an abstraction of block diagram languages used by engineering system designers. We study its properties and give general conditions for well-definedness of the operation of a system specified by a block diagram for each admissible input signal(s).</p>
      </abstract>
      <kwd-group>
        <kwd />
        <kwd>block diagram</kwd>
        <kwd>signal transformer</kwd>
        <kwd>semantics</kwd>
        <kwd>engineering system</kwd>
      </kwd-group>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>Many software tools for developing control, signal processing, and
communication systems are based on block diagram notations familiar to control engineers.
Examples include system design software Simulink [1], Scicos [2], Dymola [3],
SCADE [4], declarative synchronous languages [5], some embedded
programming languages [6, 7].</p>
      <p>In such notations, a diagram consists of blocks (components) connected by
links. Typically, blocks have input and output ports, and (directed) links connect
output ports of one block with input ports of the same or another block. A block
is interpreted as an operation which transforms input signals (i.e. time-varying
quantities) flowing though its input ports into output signals.
? Part of this research has been supported by the project Verisync
(ANR-10-BLAN0310), France.</p>
      <p>Wide applicability of block diagram notations makes them an interesting
object of study from a theoretical perspective. Classical control theory and signal
processing already provide some degree of formal treatment of block diagrams
[8, 9], but this is normally not suficient to handle such aspects of modern system
design languages as mixing of analog and discrete-time blocks, partially defined
block operations, non-numeric data processing, etc.</p>
      <p>To take these issues into account, researches developed formal semantics for
various block diagram languages [10–13]. Some efort has been made to unify
approaches taken by diferent engineering system modeling and analysis tools
and make them interoperable by the use of exchange languages with well-defined
semantics [14, 15] such as Hybrid System Interchange Format (HSIF) which gives
semantics of hybrids systems in terms of dynamic networks of hybrid automata
[16, 17].</p>
      <p>Although hybrid automata-based approaches like HSIF can be used to give
semantics to block diagram languages [18] and have many advantages (e.g.
availability of verification theory for hybrid automata), we consider them not entirely
satisfactory from a theoretical standpoint for the following reasons:
– Semantics of a system component (block) is based on the notion of a
dynamical system with an internal state, and so the components with the same
externally observable behavior can be semantically distinguishable. In our
opinion, this is not needed for a high-level semantics which does not intend
to describe details of the component’s physical/logical implementation.
– Semantics of a system has a computational nature: it describes a sequence
of discrete steps, where a step may involve function computations, solving
initial-value problems for diferential equations (continuous evolution), etc.
It may be adequate for certain classes of discrete-continuous systems, but it
does not always capture the behavior of a physical realization of a system
(and thus may conflict which the view of a system designer).</p>
      <p>For example, a Zeno execution [17] of a hybrid automaton can be described
as an infinite sequence of discrete steps which takes a bounded total time
(but each step takes a non-zero time). This normally does not correspond
to the behavior of a physical system described by the automaton. In many
cases this is caused by system modeling simplifications. The conflict is
usually resolved by applying a certain method of continuation of an execution
beyond Zeno time (regularization, Fillipov solution, etc.) [19]. But an
extended execution is not, in fact, a sequence of discrete steps, as it resumes
after the accumulation point.</p>
      <p>In our opinion, in the general case, the dynamic behavior of a system should
not be restricted to a particular scheme like a sequence of discrete steps and
continuous evolutions.</p>
      <p>The goal of this paper is to introduce abstract formal models for blocks
and block diagrams which overcomes limitations of the classical
control/signaltheoretic approach to them and does not enforce implementation details (like
internal state-space) or particular kinds of dynamic behavior (like alternation of
discrete steps and continuous evolutions) on blocks.</p>
      <p>These models can be used to identify the most general properties of block
diagram languages which are valid regardless of implementation details. In
particular, in the paper we will give a general formulation and conditions for
welldefinedness of the operation of a system specified by a block diagram for each
admissible input signal(s).</p>
      <p>To achieve our goal, we will use a composition-nominative approach [20].
The main idea of this approach is that semantics of a system is constructed
from semantics of components using special operations called compositions, and
the syntactic representation of a system reflects this construction.</p>
      <p>The paper is organized in the following way:
– In Section 2 we give definitions of the auxiliary notions which are used in
the rest of the paper.
– In Section 3 we introduce abstract notions of a block, a connection, a block
diagram, and a block composition. We show how they fit into a system design
process and give conditions of well-definedness of the operation of a system
specified by a block diagram for each admissible input signal(s).
2
2.1</p>
    </sec>
    <sec id="sec-2">
      <title>Preliminaries</title>
      <sec id="sec-2-1">
        <title>Notation</title>
        <p>We will use the following notation: N = {1, 2, 3, ...}, N0 = N ∪ {0}, R+ is the
set of nonnegative real numbers, f : A → B is a total function from A to B,
f : A →˜B is a partial function from A to B, 2A is the power set of a set A, f |X is
the restriction of a function f to a set X. If A, B are sets, then BA denotes the
set of all total functions from A to B. For a function f : A→˜ B the symbol f (x) ↓
(f (x) ↑) means that f (x) is defined (respectively undefined) on the argument x.</p>
        <p>We denote the domain and range of a function as dom(f ) = {x | f (x) ↓} and
range(f ) = {y | ∃x f (x) ↓ ∧ y = f (x)} respectively. We will use the the same
notation for the domain and range of a binary relation: if R ⊆ A × B, then
dom(R) = {x | ∃ y (x, y) ∈ R} and range(R) = {y | ∃ x (x, y) ∈ R}.</p>
        <p>We will use the notation f (x) ∼= g(x) for the strong equality (where f and g
are partial functions): f (x) ↓ if g(x) ↓ and f (x) ↓ implies f (x) = g(x).</p>
        <p>The symbol ◦ denotes a functional composition: (f ◦ g)(x) ∼= g(f (x)).</p>
        <p>By T we denote the (positive real) time scale [0, +∞). We assume that T is
equipped with a topology induced by the standard topology on R.</p>
        <p>Additionally, we define the following class of sets:</p>
        <p>T0 = {∅, T } ∪ {[0, x) | x ∈ T \{0}} ∪ {[0, x] | x ∈ T }
i.e. the set of (possibly empty, bounded or unbounded) intervals with left end 0.
2.2</p>
      </sec>
      <sec id="sec-2-2">
        <title>Multi-valued functions</title>
        <p>A multi-valued function [20] assigns one or more resulting values to each
argument value. An application of a multi-valued function to an argument is
interpreted as a nondeterministic choice of a result.
Definition 1 ([20]).</p>
        <p>tm
(denoted as f : A−→ B) is a function f : A → 2B\{∅}.</p>
        <sec id="sec-2-2-1">
          <title>A (total) multi-valued function from a set A to a set B</title>
          <p>Thus the inclusion y ∈ f (x) means that y is a possible value of f on x.
2.3</p>
        </sec>
      </sec>
      <sec id="sec-2-3">
        <title>Named sets</title>
        <p>We will use a simple notion of a named set to formalize an assignment of values
to variable names in program and system semantics.</p>
        <p>Definition 2. ([20]) A named set is a partial function f : V →˜ W from a
nonempty set of names V to a set of values W .</p>
        <p>In this definition both names and values are unstructured. A named set can be
considered as a partial (”flat”) case of a more general notion of nominative data
[20] which reflects hierarchical data organizations and naming schemes.</p>
        <p>We will use a special notation for the set of named sets: V W denotes the set
of all named sets f : V →˜W (this notation just emphasises that V is interpreted
as a set of names). We consider named sets equal, if their graphs are equal.</p>
        <p>An expression of the form [n1 7→ a1, n2 7→ a2, ...] (where n1, n2, ... are distinct
names) denotes a named set d such that the graph of d is {(n1, a1), (n2, a2), ...}.
A nowhere-defined named set is called an empty named set and is denoted as [].</p>
        <p>For any named sets d1, d2 we write d1 ⊆ d2 (named set inclusion ), if the
graph of a function d1 is a subset of the graph of d2. We extend set-theoretical
operations of union ∪, intersection ∩ and diference \ to the partial operations on
named sets in the following way: the result of a union (intersection, diference) of
named sets (operation’s arguments) is a named set d such that the graph of d is
the union (intersection, diference) of graphs of the arguments (if such d exists).
3
3.1</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>An Abstract Block Formalism</title>
      <p>Let us introduce abstract notions of a signal as a time-varying quantity and
a block as a signal transformer. We will use a real time scale for signals, but
we will not require them to be continuous or real-valued. So the signals can be
piecewise-constant as well and can be used to represent discrete evolutions.</p>
      <p>Informally, a block (see Fig. 1) is a device which receives input signals and
produces output signals. We call a collection of input (output) signals an input
(resp. output) signal bunch. At each time moment (the value of) a given signal
may be present or absent. In the general case, the presence of an input signal at
a given time does not imply the presence of an output signal at the same or any
other time moment.</p>
      <p>A block can operate nondeterministically, i.e. for one input signal bunch it
may choose an output signal bunch from a set of possible variants. However,
for any input signal bunch there exists at least one corresponding output signal
bunch (although the values of all signals in it may be absent at all times, which
means that the block does not produce any output values).</p>
      <p>Normally, a block processes the whole input signal bunch, and does or does
not produce output values. However, in certain cases a block may not process
the whole input signal bunch and may terminate at some time moment before
its end. This situation is interpreted as an abnormal termination of a block (e.g.
caused by an invalid input).</p>
      <p>
        Definition 3. (
        <xref ref-type="bibr" rid="ref1">1</xref>
        ) A signal is a partial function from T to W (f : T →˜ W ).
(
        <xref ref-type="bibr" rid="ref2">2</xref>
        ) A V -signal bunch (where V is a set of names) is a function s : T →˜ V W such
that dom(s) ∈ T0. The set of all V -signal bunches is denoted as Sb(V, W ).
(
        <xref ref-type="bibr" rid="ref3">3</xref>
        ) A signal bunch is a V -signal bunch for some V .
(
        <xref ref-type="bibr" rid="ref4">4</xref>
        ) A signal bunch s is trivial, if dom(s) = ∅ and is total, if dom(s) = T . A
trivial signal bunch is denoted as ⊥.
(
        <xref ref-type="bibr" rid="ref5">5</xref>
        ) For a given signal bunch s, a signal corresponding to a name x is a partial
function t 7→ s(t)(x). This signal is denoted as s[x].
(
        <xref ref-type="bibr" rid="ref6">6</xref>
        ) A signal bunch s1 is a prefix of a signal bunch s2 (denoted as s1 s2), if
s1 = s2|A for some A ∈ T0.
      </p>
      <p>Note that on V -signal bunches is a partial order (for an arbitrary V ). Later we
will need generalized versions of the prefix relation for pairs and indexed families
of pairs of signal bunches.</p>
      <p>For any signal bunches s1, s2, s01, s02 let us denote (s1, s2) 2 (s01, s02) if there
exists A ∈ T0 such that s1 = s01|A and s2 = s02|A.</p>
      <p>For any indexed families of pairs of signal bunches (sj , s0j )j∈J and (s0j0, s0j00)j∈J
of signal bunches let us denote (sj , s0j )j∈J J,2 (s0j0, s0j00)j∈J if there exists A ∈ T0
such that sj = s0j0|A and s0j = s0j00|A for all j ∈ J .</p>
      <p>It is easy to check that 2 is a partial order on pairs of signal bunches and
J,2 is a partial order on J -indexed families of pairs of signal bunches.</p>
      <p>A block has a syntactic aspect (e.g. a description in a specification language)
and a semantic aspect – a partial multi-valued function on signal bunches.</p>
      <sec id="sec-3-1">
        <title>Definition 4. (1) A block is an object B (syntactic aspect) together with an as</title>
        <p>
          sociated set of input names In(B), a set of output names Out(B), and a total
multi-valued function Op(B) : Sb(In(B), W )−tm→ Sb(Out(B), W ) (operation,
semantic aspect) such that o ∈ Op(B)(i) implies dom(o) ⊆ dom(i).
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) Two blocks B1, B2 are semantically identical, if In(B1) = In(B2), Out(B1) =
        </p>
        <p>
          Out(B2), and Op(B1) = Op(B2).
(
          <xref ref-type="bibr" rid="ref3">3</xref>
          ) An I/O pair of a block B is a pair of signal bunches (i, o) such that o ∈
        </p>
      </sec>
      <sec id="sec-3-2">
        <title>Op(B)(i). The set of all I/O pairs of B is denoted as IO(B) and is called the input-output (I/O) relation of B.</title>
        <p>An inclusion o ∈ Op(B)(i) means that o is a possible output of a block B on the
input i. For each input i there is some output o. The domain of o is a subset of
the domain of i. If o becomes undefined at some time t, but i is still defined at
t, we interpret this as an error during the operation of the block B (the block
cannot resume its operation after t).</p>
      </sec>
      <sec id="sec-3-3">
        <title>Definition 5. A block B is deterministic, if Op(B)(i) is a singleton set for each</title>
      </sec>
      <sec id="sec-3-4">
        <title>In(B)-signal bunch i.</title>
        <p>We interpret the operation of a block as a (possibly nondeterministic) choice
of an output signal bunch corresponding to a given input signal bunch. However,
we would also like to describe this choice as dynamic, i.e. that a block chooses
the output signal values at each time t, and in doing so it cannot rely on the
future values of the input signals (i.e. values of the input signals at times t0 &gt; t).</p>
        <p>If a block is deterministic, this requirement can be formalized in the same
way as the notion of a causal (or nonanticipative) input-output system [26].
Definition 6. A deterministic block B is causal if for all signal bunches i1, i2
and A ∈ T0, o1 ∈ Op(B)(i1), o2 ∈ Op(B)(i2), the equality i1|A = i2|A implies
o1|A = o2|A.
This means that the value of the output signal bunch at time t can depend only
on the values of the input signal at times ≤ t.</p>
        <p>Some works in the domain of systems theory extend the notion of a causal
(deterministic) system to nondeterministic systems. However, there is no unified
approach to an extension of this kind. For example, in the work [21], a system,
considered as a binary relation on (total) signals S ⊆ AT × BT , where T is
a time domain (Mesarovic time system, [22]) is “non-anticipatory”, if it is a
union of (graphs of) causal (non-anticipatory) selections from S, i.e, S = S{f :
dom(S) → range(S) | f ⊆ S, f is causal}. In the work [23] the authors define
another notion of a “non-anticipatory” or “causal” system in nondeterministic
case. In the theory developed in the work [24], the authors use a similar notion
of a “precausal” system, which is also defined in [22], as a generalization of the
notion of a causal system to the nondeterministic case.</p>
        <p>In this work, we generalize the notion of a non-anticipatory system in sense
of [23] to blocks and call such blocks nonanticipative, and generalize the notion
of a non-anticipatory system in sense of [21] to blocks, but call such blocks
strongly nonanticipative. We will show that strongly nonanticipative block is
nonanticipative. We will consider the words “causal” and “nonanticipative” as
synonyms when they are used informally, but we will distinguish them in the
context of formal definitions to avoid a conflict with Definition 6.</p>
        <p>Note, however, that the notion of a strongly nonanticipative block defined
below is very diferent from the notion of a ”strictly causal“ system, defined in
some works [25] as a system which uses only past (but not current or future)
values of the input signal(s) to produce a current value of the output signal(s).
Definition 7. A block B is nonanticipative, if for each A ∈ T0 and i1, i2 ∈
Sb(In(B), W ), if i1|A = i2|A, then</p>
        <p>{o|A | o ∈ Op(B)(i1)} = {o|A | o ∈ Op(B)(i2)}.</p>
        <p>Definition 8. A block B is a sub-block of a block B0 (denoted as B E B0), if
In(B) = In(B0), Out(B) = Out(B0), and IO(B) ⊆ IO(B0).</p>
        <p>Informally, a sub-block narrows nondeterminism of a block.</p>
        <p>Definition 9. A block B is strongly nonanticipative, if for each (i, o) ∈ IO(B)
there exists a deterministic causal sub-block B0 E B such that (i, o) ∈ IO(B0).</p>
        <p>Informally, the operation of a strongly nonanticipative block B can be
interpreted as a two-step process:
1. before receiving the input signals, the block B (nondeterministically) chooses
a deterministic causal sub-block B0 E B (response strategy);
2. the block B0 receives input signals of B and produces the corresponding
output signals (response) which become the output signals of B.
Intuitively, it is clear that in this scheme at any time the block B does not need
a knowledge of the future of its input signals in order produce the corresponding
output signals.</p>
      </sec>
      <sec id="sec-3-5">
        <title>Lemma 1. If B is a deterministic block, then B is causal if B is nonanticipa</title>
        <p>tive.</p>
        <p>Proof. Follows immediately from Definition 6.</p>
        <p>The following theorem gives a characterization of a nonanticipative block
which does not rely on comparison of sets of signal bunches.</p>
      </sec>
      <sec id="sec-3-6">
        <title>Theorem 1. A block B is nonanticipative if the following holds:</title>
        <p>
          (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) if (i, o) ∈ IO(B) and (i0, o0) 2 (i, o), then (i0, o0) ∈ IO(B);
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) if o ∈ Op(B)(i) and i i0, then (i, o) 2 (i0, o0) for some o0 ∈ Op(B)(i0).
Proof. (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) Assume that (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) and (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) are satisfied. Assume that A ∈ T0, i1, i2 ∈
Sb(In(B), W ), and i1|A = i2|A. Let o ∈ Op(B)(i1). Then from
assumption (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) we have o|A ∈ Op(B)(i1|A), because (i1|A, o|A) 2 (i1, o).
Moreover, i1|A i2, because i1|A = i2|A. Thus (i1|A, o|A) 2 (i2, o0) for some
o0 ∈ Op(B)(i2) by assumption (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ). It is not dificult to check that o|A ∈
{o00|A | o00 ∈ Op(B)(i2)}. Because i1, i2, A are arbitrary, B is nonanticipative
by Definition 7.
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) Assume that B is nonanticipative. Let us prove (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ). Assume that (i, o) ∈
IO(B) and (i0, o0) 2 (i, o). Then i0 = i|A and o0 = o|A for some A ∈ T0.
Then i0|A = (i|A)|A = i|A, whence
        </p>
        <p>o0 = o|A ∈ {o00|A | o00 ∈ Op(B)(i)} = {o00|A | o00 ∈ Op(B)(i0)}
by Definition 7. Then o0 = o00|A for some o00 ∈ Op(B)(i0). Moreover, dom(o00) ⊆
dom(i0) ⊆ A. Thus o0 = o00 and (i0, o0) ∈ IO(B).</p>
        <p>
          Let us prove (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ). Assume that o ∈ Op(B)(i) and i i0. Then i = i0|A for
some A ∈ T0. Then i|A = (i0|A)|A = i0|A, whence
        </p>
        <p>o|A ∈ {o00|A | o00 ∈ Op(B)(i)} = {o00|A | o00 ∈ Op(B)(i0)}
by Definition 7. Then o|A = o0|A for some o0 ∈ Op(B)(i0). Moveover, dom(o) ⊆
dom(i) ⊆ A, whence o = o|A = o0|A. Thus (i, o) 2 (i0, o0).</p>
      </sec>
      <sec id="sec-3-7">
        <title>Theorem 2. (About strongly nonanticipative block)</title>
        <p>
          (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) If a block B is strongly nonanticipative, then it is nonanticipative.
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) There exists a nonanticipative block which is not strongly nonanticipative.
        </p>
      </sec>
      <sec id="sec-3-8">
        <title>Proof (Sketch).</title>
        <p>
          (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) Assume that B is strongly nonanticipative. Let R be the set of all
relations R ⊆ IO(B) such that R is an I/O relation of a nonanticipative
block. For each R ∈ IO let us define a block BR such that IO(BR) = R,
In(BR) = In(B), Out(BR) = Out(B). Let B = {BR | R ∈ R}. Then each
element of B is nonanticipative. From Definition 9 and Lemma 1 we have
IO(B) ⊆ S R = SB0∈B IO(B0). On the other hand, IO(B0) ⊆ IO(B) for
any B0 ∈ R, so IO(B) = SB0∈B IO(B0). It is easy to see from Theorem 1
that (nonempty) union of I/O relations of nonanticipative block is an I/O
relation of a nonanticipative block. Thus B is nonanticipative.
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) Assume that W = R. Let f : R → R be a function that is discontinuous
at some point (e.g. a signum function). Let use define a block B such that
In(B) = {x} and Out(B) = {y} for some names x, y, and for each i ∈
Sb(In(B), R), Op(B)(i) is defined as follows:
• if dom(i[x]) = T and limt→+∞ i[x](t) exists and finite, then Op(B)(i) is
the set of all {y}-signal bunches o such that dom(o) = dom(o[y]) = T
and
        </p>
        <p>lim o[y](t) = f
t→+∞</p>
        <p>lim i[x](t) ;
t→+∞
• otherwise, Op(B)(i) is the set of all {y}-signal bunches o such that
dom(o) = dom(o[y]) = S{A ∈ T0 | A ⊆ dom(i[x])}.</p>
        <p>Obviously, in this definition Op(B)(i) 6= ∅ (because T0 is closed under
unions) and dom(o) ⊆ dom(i) for each o ∈ Op(B)(i). So B is indeed a
block. Using Theorem 1 it is not dificult to show that B is
nonanticipative. Suppose that B has a a deterministic causal sub-block B0. Let a ∈ R
and ak ∈ R, k = 1, 2, ... be a sequence such that limk→∞ ak = a. Let us
show that limk→∞ f (ak) = f (a). Let us define sequences ik ∈ Sb({y}, R),
ok ∈ Sb({y}, R), and tk ∈ T , k = 1, 2, ... by induction as follows.
Let i1(t) = [x 7→ a1] for all t ∈ T , o1 be a unique member of Op(B0)(i1),
and t1 = 0. If i1, i2, ..., ik are already defined, let ik+1(t) = ik(t), if t ∈ [0, tk]
and ik+1(t) = [x 7→ ak+1], if t ∈ T \[0, tk]. Let ok+1 be a unique member
of Op(B0)(ik+1). Because B0 E B, dom(ok+1) = dom(ok+1[y]) = T and
limt→+∞ ok+1[y](t) = f (limt→+∞ ik+1[x](t)) = f (ak+1). Then let
tk+1 = 1 + max{tk, inf{τ ∈ T |
We have defined sequences ik, ok, tk. The sequence tk, k = 1, 2, ... is a strictly
increasing and unbounded from above and t1 = 0.</p>
        <p>Let i be a {x}-signal bunch such that dom(i) = T , i(t1) = i1(t1), and
i(t) = ik+1(t), if t ∈ (tk, tk+1], k ∈ N, and o be a (unique) member of
Op(B0)(i). We have ik+1[x](t) = ak+1 for all k = 1, 2, ... and t &gt; tk. Then
i[x](t) ∈ {ak+1, ak+2, ...} for all k ∈ N and t &gt; tk. For each &gt; 0 there exists
k ∈ N such that |ak0 − a| &lt; for all k0 ≥ k, whence |i[x](t) − a| &lt; for
all t &gt; tk. Thus limt→+∞ i[x](t) = a. Then dom(o) = dom(o[y]) = T and
limt→+∞ o[y](t) = f (a), because B0 E B.</p>
        <p>On the other hand, ik+1|[0,tk] = ik|[0,tk] for all k ∈ N. Because tk is an
increasing sequence, we have ik0 |[0,tk] = ik|[0,tk] for all k and k0 ≥ k.
Besides, i|(tk,tk+1] = ik+1|(tk,tk+1] for all k ∈ N, whence i|(tk,tk+1] = ik0 |(tk,tk+1]
for all k0 ≥ k + 1. Also, ik(t1) = i1(t1) for all k ∈ N. Then i|[0,tk] =
i|{t1}∪(t1,t2]∪...∪(tk−1,tk] = ik|[0,tk] for all k = 2, 3, ..., whence o|[0,tk] = ok|[0,tk],
because B0 is causal. Then o(tk) = ok(tk) for all k = 2, 3, ..., and from the
definition of tk we have |o[y](tk) − f (ak)| = |ok[y](tk) − f (ak)| ≤ k1 for all k =
2, 3, .... This implies that limk→∞ f (ak) = f (a), because limt→+∞ o[y](t) =
f (a). We conclude that f is sequentially continuous and thus is continuous.
This contradicts our choice of f as a discontinuous function. Thus B has not
deterministic causal sub-blocks. Consequently, B is not strongly
nonanticipative, though it is nonanticipative.</p>
        <p>
          The proof of this theorem gives a reason of why Definition 9 better captures
a intuitive idea of causality than Definition 7. Consider, for example, the block
B constructed in the proof of the item (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) of Theorem 2, when f is the signum
function (i.e., f (0) = 0, f (x) = 1, if x &gt; 0, and f (x) &lt; 0, if x &lt; 0). Then B
outputs a signal which converges to 1 (as t → +∞) whenever the input signal
converges to a positive number (as t → +∞). Moreover, it outputs a signal which
converges to 0 whenever the input signal converges to 0. This implies that when
the block receives a decreasing positive input signal which tends to 0, it decides
to output values which are close to 0 starting from some time t. Intuitively, after
reading the input signal until time t, the block decides that 0 is a more likely
limit of the input signal than a positive value, but such a decision cannot be
based on the past values of the input signal, so it requires some knowledge of
the future of the input signal. These informal observations are captured by the
fact that B has no deterministic causal sub-blocks.
        </p>
        <p>In the rest of the paper we will focus on strongly nonanticipative blocks, as
more adequate models of (real-time) information processing systems.</p>
        <p>Consider an example of a strongly nonanticipative block.</p>
        <p>Let u, y be names. Assume that W = R.</p>
        <p>Example 1. Let B be a block such that In(B) = { }
u , Out(B) = {y}, and for
each i, Op(B)(i) = {o1(i), o2(i)}, where o1(i), o2(i) ∈ Sb(Out(B), W ) are signal
bunches such that
– dom(o1(i)) = dom(o2(i)) = dom(i);
– o1(i)(t) = [y 7→ i[u](t)] for all t ∈ dom(i);
– o2(i)(t) = [y 7→ 2i[u](t)] for all t ∈ dom(i).</p>
        <p>Informally, this means that B is a gain block with a slope which is either 1 or 2
during the whole duration of the block’s operation.</p>
        <p>
          Obviously, B satisfies Definition 4(
          <xref ref-type="bibr" rid="ref1">1</xref>
          ). Let us check that it is strongly
nonanticipative. For j = 1, 2 let Bj Θ B be a sub-block such that Op(Bj )(i) = {oj (i)}
for all i ∈ Sb(In(B), W ) (i.e. B1 always selects o1(i) from Op(B)(i) and B2
always selects o2(i)).
        </p>
        <p>The blocks B1, B2 are deterministic and it is easy to see that they are causal.
Obviously, each I/O pair (i, o) ∈ IO(B) belongs either to IO(B1), or to IO(B2),
so B is strongly nonanticipative.</p>
        <p>Now let us consider an example of a block which is not nonanticipative.
Example 2. Let B0 be a block such that In(B0) = {u}, Out(B0) = {y}, and
– Op(B0)(i) = {o1}, where dom(o1) = dom(i) and o1(t) = [y 7→ 1] for all
t ∈ dom(i), if dom(i[u]) = T ;
– Op(B0)(i) = {o2}, where dom(o2) = dom(i) and o2(t) = [y 7→ 0] for all
t ∈ dom(i), otherwise.</p>
        <p>
          Informally, the block B0 decides whether its input signal u is total. It is easy to
see that B0 indeed satisfies Definition 4(
          <xref ref-type="bibr" rid="ref1">1</xref>
          ), but the condition (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) of Theorem 1 is
not satisfied, because ( i, o) ∈ IO(B0), where i(t) = [u 7→ 0] for all t ∈ T , o(t) =
[y 7→ 1] for all t ∈ T , and (i|[0,1], o|[0,1]) 2 (i, o), but (i|[0,1], o|[0,1]) ∈/ IO(B0).
So B0 is not nonanticipative. Informally, the reason is that at each time t the
current value of y depends on the entire input signal.
By connecting inputs and outputs of several (strongly nonanticipative) blocks
one can form a larger block – a composition of blocks (see Fig. 2). We assume that
an output can be connected to several inputs, but each input can be connected
to no more than one output. Unconnected inputs and outputs of constituent
blocks become inputs and output of the composition. Connections are interpreted
as signal equality constraints and they always relate an output of some block
(”source”) with an input of the same or another block (”target”). We represent
connections in the graphical form (like in Fig. 2) as arrows connecting blocks.
        </p>
        <p>
          Definition 10. (
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) A block diagram is a pair ((Bj )j∈J ,
of blocks (Bj )j∈J and an injective binary relation
called an interconnection relation, where
) of an indexed family
⊆ Vout × Vin, which is
Vin = [ {j} × In(Bj ), Vout = [ {j} × Out(Bj ).
        </p>
        <p>j∈J</p>
        <p>j∈J</p>
        <p>) is called regular, if each Bj , j ∈ J is strongly
Note that a diagram may consist of an infinite set of blocks. A relation ( j, x)
(j0, x0) means that the output x of the j-th block is connected to the input x0 of
the j0-th block.</p>
        <p>A block diagram is only a syntactic aspect of a block composition. We define
semantics of a block composition only for strongly nonanticipative blocks.</p>
        <p>To describe it informally consider Fig. 3. The connection between y2 and x2
means a signal equality constraint. The block B chooses (nondeterministically)
some deterministic sub-block B0 E B. When a signal starts flowing into the
input x1, the block B0 tries to choose the initial values for the signals of y1,
y2, x2 so that they satisfy the operation of the block B0 (Op(B0)) and the
signals of x2 and y2 have the same values. If such initial values do not exist, the
block B0 terminates (the output signal bunch is nowhere defined). Otherwise,
B0 continues to operate in the similar way until either the signals of y1, y2, x2
cannot be continued, or the input signal (x1) ends.</p>
        <p>Definition 11. Let ((Bj )j∈J , ) be a regular block diagram.</p>
        <p>
          A block B is a composition of (Bj )j∈J under the interconnection relation
, if
– In(B) = (Sj∈J {j} × In(Bj ))\range( ),
– Out(B) = (Sj∈J {j} × Out(Bj ))\dom( ),
– Op(B)(i) is the set of all Out(B)-signal bunches o such that there exist
deterministic causal sub-blocks Bj0 E Bj , j ∈ J and an indexed family
(ij , oj )j∈J ∈ Xm(i) such that
(
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) dom(o) = dom(oj ) for all j ∈ J ,
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) o[(j, x)] = oj [x] for all (j, x) ∈ Out(B),
where Xm(i) is the set of J,2-maximal elements of X(i), and X(i) is the
set of all indexed families of pairs of signal bunches u = (ij , oj )j∈J such that
(
          <xref ref-type="bibr" rid="ref3">3</xref>
          ) dom(ij ) = dom(oj ) = dom(ij0 ) = dom(oj0 ) ⊆ dom(i) for all j, j0 ∈ J ,
(
          <xref ref-type="bibr" rid="ref4">4</xref>
          ) ij [x] = i|dom(ij)[(j, x)] for each (j, x) ∈ In(B),
(
          <xref ref-type="bibr" rid="ref5">5</xref>
          ) (ij , oj ) ∈ IO(Bj0 ) for each j ∈ J ,
(
          <xref ref-type="bibr" rid="ref6">6</xref>
          ) (j, x)
        </p>
        <p>(j0, x0) implies oj [x] = ij0 [x0].</p>
        <p>In this definition, ij and oj denote the input and output signal bunches of the
j-th block. The set Xm(i) contains maximally extended (in sense of the relation</p>
        <p>
          J,2) indexed families of signal bunches defined on a subset of the domain of i
(the input signal bunch of B) which satisfy constraints imposed by the
interconnection relation. Any such family gives a possible output of B for the given i by
the condition (
          <xref ref-type="bibr" rid="ref2">2</xref>
          ), i.e. output signals of B are obtained from the output signals
of the sub-blocks B0 .
        </p>
        <p>j</p>
        <p>It is clear that any two compositions of (Bj )j∈J under are semantically
identical.</p>
      </sec>
      <sec id="sec-3-9">
        <title>Lemma 2. (Continuity of the operation of a causal deterministic causal block).</title>
        <p>Let B be a deterministic causal block. Let c ⊆ Sb(In(B), W ) be a non-empty
-chain, i∗ be its supremum (in sense of ), and o∗ ∈ Op(B)(i∗). Then o∗ is a
supremum of Si∈c Op(B)(i) (in sense of ).</p>
        <p>Proof. Follows from Definition 6.</p>
        <p>
          Theorem 3. Let ((Bj )j∈J ,
(
          <xref ref-type="bibr" rid="ref1">1</xref>
          ) A composition of (Bj )j∈J under exists.
(
          <xref ref-type="bibr" rid="ref2">2</xref>
          ) If B is a composition of (Bj )j∈J under
        </p>
        <p>tive.</p>
        <p>The proof follows from Lemma 2 and Definition 11.</p>
        <p>) be a regular block diagram. Then
, then B is strongly
nonanticipa3.3</p>
        <sec id="sec-3-9-1">
          <title>Specification and implementation</title>
          <p>Above we have considered a block as an abstract model of a real component.
However, it can also be considered as a specification of requirements for a
component. Let Bspec, Bimpl be two strongly nonanticipative blocks. Let us call them
a specification block and implementation block respectively.</p>
        </sec>
        <sec id="sec-3-9-2">
          <title>Definition 12.</title>
          <p>Bimpl is a refinement of Bspec, if Bimpl is a sub-block of Bspec.</p>
          <p>I.e. an implementation should have the the same input and output names as a
specification, and for each input, an output of an implementation should be one
of the possible outputs of a specification. We generalize this to diagrams.</p>
          <p>Let D = ((Bj )j∈J , ) and D0 = ((Bj0 )j∈J0 , 0) be regular block diagrams.</p>
        </sec>
      </sec>
      <sec id="sec-3-10">
        <title>Definition 13. D is a refinement of</title>
        <p>for each j ∈ J , and the relations</p>
        <p>D0, if J = J 0, Bj is a refinement of
and 0 coincide.</p>
        <p>B0
j
Theorem 4. (Compositional refinement) Let B be a composition of (Bj )j∈J
under and B0 be a composition of (Bj0 )j∈J0 under 0. If D is a refinement
of D0, then B is a refinement of B0.</p>
        <p>The proof follows from Definition 9, 11, and transitivity of the sub-block relation.</p>
        <p>This theorem can be considered as a foundation of a modular approach [29,
30] to system design:
1. Create specifications of the system components ( Bj0 , j ∈ J 0) and connect
them ( 0), as if they were real components.
2. Analyze a composition of specifications ( B0) to ensure that any of its
implementations (B00 E B0) satisfies requirements to the final system.
3. Create an implementation (Bj ) for each specification ( Bj0 ).
4. Connect implementations (according to 0). Then the composition of
implementations (B) is a final system which satisfies design requirements.
We consider the steps 1 and 3 domain- and application-specific. The conclusion
of the step 4 is addressed in Theorem 4. Step 2 requires some verification method
which depends on the nature of requirements.</p>
        <p>One of the most basic and common requirements is that the operation of
B0 is defined on all input signal bunches which are possible in the context of a
specific application of this composition. This trivially holds because of Theorem
3 and our definition of a block. However, B0 may terminate abnormally on some
or all input signal bunches of interest (as we have noted, we interpret the
situation when o ∈ Op(B˜)(i) and dom(o) ⊂ dom(i) for some block B˜ as abnormal
termination of B˜ on i). So the requirement can be reformulated as follows: B0
never terminates abnormally on any input signal bunch from a given set IN
(this implies that the same property holds for B). We will call this property as
well-definedness of the operation of B0 on IN and study it in the next subsection.
3.4</p>
        <sec id="sec-3-10-1">
          <title>Well-definedness of the operation of a composition of blocks</title>
          <p>Let B be a block and IN be some set of In(B)-signal bunches.</p>
          <p>Definition 14. The operation of B is well-defined on IN , if dom(i) = dom(o)
for each i ∈ IN and o ∈ Op(B)(i).</p>
          <p>Let D = ((Bj )j∈J , ) be a regular block diagram and B be a composition of
(Bj )j∈J under . Let F be the set of all families of blocks of the form (Bj0 )j∈J ,
where for each j ∈ J , Bj0 is a deterministic causal sub-block of Bj .</p>
          <p>
            For each In(B)-signal bunch i and a family of blocks F = (Bj0 )j∈J let XF (i)
be the set of all indexed families of pairs of signal bunches u = (ij , oj )j∈J which
satisfy conditions (
            <xref ref-type="bibr" rid="ref3">3</xref>
            )-(
            <xref ref-type="bibr" rid="ref6">6</xref>
            ) of Definition 11 (for B and (Bj0 )j∈J ).
          </p>
          <p>
            Let XmF(i) denote the set of all J,2-maximal elements of XF (i). For any
indexed family of signal bunches u = (ij , oj )j∈J let O(u) denote the set of all
Out(B)-signal bunches o which satisfy conditions (
            <xref ref-type="bibr" rid="ref1">1</xref>
            )-(
            <xref ref-type="bibr" rid="ref2">2</xref>
            ) of Definition 11.
          </p>
          <p>For any u = (ij , oj )j∈J ∈ XF (i), the domains of ij , oj for all j ∈ J coincide.
Denote by cdom(u) this common domain (we assume cdom(u) = T , if J = ∅).</p>
          <p>From Definition 11 we have Op(B)(i) = SF ∈F Su∈XmF(i) O(u) for each i.
Then from Definition 14 we get the following simple criterion:</p>
        </sec>
      </sec>
      <sec id="sec-3-11">
        <title>Theorem 5. The operation of B is well-defined on IN if for each</title>
        <p>F ∈ F , and u ∈ XF (i), if cdom(u) ⊂ dom(i), then u ∈/ XmF(i).
i ∈ IN ,
This criterion means that B is well-defined, if each u ∈ XF (i), the common
domain of which does not cover dom(i), is extendable to a larger u0 ∈ XF (i) (in
sense of J,2). We will call it a local extensibility criterion, because, basically,
to prove well-definedness, we only need to show that the members of the family
u can be continued onto a time segment [0, sup cdom(u) + ] for some small
&gt; 0 (under constraints imposed by the interconnection relation ). Locality is
especially useful when a block diagram contains ”delay” blocks (possibly working
as variable delays), because constraints imposed by connections between blocks
reduce over small time intervals.</p>
        <p>
          A drawback of this criterion is that it requires checking local extensibility
of signal bunches satisfying the I/O relations (IO(Bj0 )) of arbitrarily chosen
deterministic causal sub-blocks Bj0 E Bj (condition (
          <xref ref-type="bibr" rid="ref5">5</xref>
          ) of Definition 11), which
are not explicitly expressed in terms of I/O relations of Bj , j ∈ J .
        </p>
        <p>For this reason, we seek for a condition of well-definedness in terms of I/O
relations of the constituents of the composition (IO(Bj ), j ∈ J ).</p>
        <p>Let X(i) denote the set XF (i), where F = (Bj )j∈J . Note that F may not be
a member of F .</p>
        <p>Theorem 6. The operation of B is well-defined on IN if for each i ∈ IN and
u ∈ X(i) there exists u0 ∈ X(i) such that u J,2 u0 and cdom(u0) = dom(i).
The proof follows from Theorem 5 and Definition 9.</p>
      </sec>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1. Simulink - Simulation and
          <article-title>Model-Based Design</article-title>
          , http://www.mathworks.com/ products/simulink
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Campbell</surname>
            ,
            <given-names>S.L.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chancelier</surname>
            ,
            <given-names>J.-P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Nikoukhah</surname>
          </string-name>
          , R.:
          <source>Modeling and Simulation in Scilab/Scicos with ScicosLab 4</source>
          .4. Springer (
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Multi-Engineering Modeling</surname>
          </string-name>
          and Simulation - Dymola, http://www.3ds.com/ products/catia/portfolio/dymola
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <given-names>SCADE</given-names>
            <surname>Suite</surname>
          </string-name>
          , http://www.esterel-technologies.com/products/scade-suite
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Caspi</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Pilaud</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Halbwachs</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Plaice</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>LUSTRE: A declarative language for programming synchronous systems</article-title>
          .
          <source>In: 14th Annual ACM Symp. on Principles of Programming Languages, Munich, Germany</source>
          , pp.
          <fpage>178</fpage>
          -
          <lpage>188</lpage>
          (
          <year>1987</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Henzinger</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Horowitz</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kirsch</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          :
          <article-title>Giotto: A Time-Triggered Language for Embedded Programming</article-title>
          .
          <source>First International Workshop on Embedded Software, EMSOFT'01</source>
          , pp.
          <fpage>166</fpage>
          -
          <lpage>184</lpage>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7.
          <string-name>
            <surname>Lublinerman</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Tripakis</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>Modular Code Generation from Triggered and Timed Block Diagrams</article-title>
          .
          <source>In: IEEE Real-Time and Embedded Technology and Applications Symposium</source>
          , pp.
          <fpage>147</fpage>
          -
          <lpage>158</lpage>
          (
          <year>2008</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Sontag</surname>
          </string-name>
          , E.D.:
          <source>Mathematical Control Theory: Deterministic Finite Dimensional Systems. Second Edition</source>
          , Springer, New York (
          <year>1998</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Proakis</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Manolakis</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          : Digital Signal Processing: Principles, Algorithms and Applications, 4th ed.
          <source>Pearson</source>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Tiwari</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>Formal semantics and analysis methods for Simulink Stateflow models</article-title>
          .
          <source>Unpublished report</source>
          , SRI International (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Bouissou</surname>
            ,
            <given-names>O.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Chapoutot</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          :
          <article-title>An operational semantics for Simulink's simulation engine</article-title>
          .
          <source>LCTES</source>
          <year>2012</year>
          , pp.
          <fpage>129</fpage>
          -
          <lpage>138</lpage>
          . (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Agrawal</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Simon</surname>
            ,
            <given-names>G.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Karsai</surname>
          </string-name>
          , G.:
          <article-title>Semantic translation of Simulink/Stateflow models to hybrid automata using graph transformations</article-title>
          .
          <source>Electronic Notes in Theoretical Computer Science</source>
          <volume>109</volume>
          ,
          <fpage>43</fpage>
          -
          <lpage>56</lpage>
          (
          <year>2004</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Marian</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ma</surname>
          </string-name>
          , Y.:
          <article-title>Translation of Simulink Models to Component-based Software Models</article-title>
          .
          <source>In: 8-th Int. Workshop on Research and Education in Mechatronics</source>
          ,
          <volume>14</volume>
          -
          <fpage>15</fpage>
          June 2007, Talin University of Technology, Estonia (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Pinto</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sangiovanni-Vincentelli</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Carloni</surname>
            <given-names>L.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Passerone</surname>
          </string-name>
          , R.:
          <article-title>Interchange formats for hybrid systems: Review and proposal</article-title>
          .
          <source>In: HSCC 05: Hybrid Systems Computation and Control</source>
          . Springer-Verlag, pp.
          <fpage>526</fpage>
          -
          <lpage>541</lpage>
          (
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Beek</surname>
            ,
            <given-names>D.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reniers</surname>
            ,
            <given-names>M.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Schifelers</surname>
            ,
            <given-names>R.R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rooda</surname>
            ,
            <given-names>J. E.</given-names>
          </string-name>
          :
          <article-title>Foundations of a Compositional Interchange Format for Hybrid Systems</article-title>
          .
          <source>In: HSCC'07</source>
          , pp.
          <fpage>587</fpage>
          -
          <lpage>600</lpage>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Henzinger</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          :
          <article-title>The theory of hybrid automata</article-title>
          .
          <source>In: IEEE Symposium on Logic in Computer Science</source>
          , pp.
          <fpage>278</fpage>
          -
          <lpage>292</lpage>
          (
          <year>1996</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Goebel</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Sanfelice</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Teel</surname>
          </string-name>
          , R.:
          <article-title>Hybrid dynamical systems</article-title>
          .
          <source>In: IEEE Control Systems Magazine</source>
          <volume>29</volume>
          ,
          <fpage>29</fpage>
          -
          <lpage>93</lpage>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Schrammel</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jeannet</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          :
          <article-title>From hybrid data-flow languages to hybrid automata: a complete translation</article-title>
          .
          <source>In: HSCC</source>
          <year>2012</year>
          : pp.
          <fpage>167</fpage>
          -
          <lpage>176</lpage>
          (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Camhbel</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>K.</given-names>
            ,
            <surname>Heemels</surname>
          </string-name>
          , A.J., van der Schaft,
          <string-name>
            <given-names>A.J.</given-names>
            ,
            <surname>Schumacher</surname>
          </string-name>
          ,
          <string-name>
            <surname>J.M.:</surname>
          </string-name>
          <article-title>Solution concepts for hybrid dynamical systems</article-title>
          .
          <source>In: Proc. IFAC 15th Triennial World Congress, Barcelona</source>
          , Spain (
          <year>2002</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Nikitchenko</surname>
            ,
            <given-names>N.S.:</given-names>
          </string-name>
          <article-title>A composition nominative approach to program semantics</article-title>
          .
          <source>Technical report IT-TR 1998-020</source>
          , Technical University of Denmark,
          <volume>103</volume>
          p. (
          <year>1998</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Windeknecht</surname>
          </string-name>
          , T.G.:
          <source>Mathematical systems theory: Causality. Mathematical systems theory 1</source>
          , pp.
          <fpage>279</fpage>
          -
          <lpage>288</lpage>
          (
          <year>1967</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Mesarovic</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            ,
            <surname>Takahara</surname>
          </string-name>
          ,
          <string-name>
            <surname>Y.</surname>
          </string-name>
          :
          <article-title>Abstract systems theory</article-title>
          . Springer, Berlin Heidelberg New York, 439 p. (
          <year>1989</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23.
          <string-name>
            <surname>Foo</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Peppas</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>Realization for Causal Nondeterministic Input-Output Systems</article-title>
          .
          <source>Studia Logica 67</source>
          , pp.
          <fpage>419</fpage>
          -
          <lpage>437</lpage>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <surname>Lin</surname>
          </string-name>
          , Y.:
          <article-title>General systems theory: A mathematical approach</article-title>
          . Springer, 382 p. (
          <year>1999</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          25.
          <string-name>
            <surname>Matsikoudis</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>On Fixed Points of Strictly Causal Functions</article-title>
          .
          <source>Technical report UCB/EECS-2013-27</source>
          , EECS Department, University of California, Berkeley (
          <year>2013</year>
          ).
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <string-name>
            <surname>Williems</surname>
          </string-name>
          , J.:
          <article-title>Paradigms and puzzles in the theory of dynamical systems</article-title>
          .
          <source>In: IEEE Transactions on Automatic Control 36</source>
          , pp.
          <fpage>259</fpage>
          -
          <lpage>294</lpage>
          (
          <year>1991</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref27">
        <mixed-citation>
          27.
          <string-name>
            <surname>Williems</surname>
          </string-name>
          , J.:
          <article-title>On Interconnections, Control, and Feedback</article-title>
          .
          <source>In: IEEE Transactions on Automatic Control 42</source>
          , pp.
          <fpage>326</fpage>
          -
          <lpage>339</lpage>
          (
          <year>1997</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref28">
        <mixed-citation>
          28.
          <string-name>
            <surname>Williems</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>The behavioral approach to open and interconnected systems</article-title>
          .
          <source>In: IEEE Control Systems Magazine</source>
          , pp.
          <fpage>46</fpage>
          -
          <lpage>99</lpage>
          (
          <year>2007</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref29">
        <mixed-citation>
          29.
          <string-name>
            <surname>Baldwin</surname>
            ,
            <given-names>C.Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Clark</surname>
            ,
            <given-names>K.B.</given-names>
          </string-name>
          :
          <string-name>
            <surname>Design</surname>
            <given-names>Rules</given-names>
          </string-name>
          , Volume
          <volume>1</volume>
          :
          <article-title>The Power of Modularity</article-title>
          . MIT Press (
          <year>2000</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref30">
        <mixed-citation>
          30.
          <string-name>
            <surname>Tripakis</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lickly</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Henzinger</surname>
            ,
            <given-names>T.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lee</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          :
          <article-title>On relational interfaces</article-title>
          .
          <source>Proceedings of EMSOFT'2009</source>
          , pp.
          <fpage>67</fpage>
          -
          <lpage>76</lpage>
          (
          <year>2009</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref31">
        <mixed-citation>
          31.
          <string-name>
            <surname>Ivanov</surname>
          </string-name>
          , Ie.:
          <article-title>A criterion for global-in-time existence of trajectories of nondeterministic Markovian systems</article-title>
          .
          <source>Communications in Computer and Information Science 347</source>
          , pp.
          <fpage>111</fpage>
          -
          <lpage>130</lpage>
          , Springer (
          <year>2012</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref32">
        <mixed-citation>
          32.
          <string-name>
            <surname>Carloni</surname>
            ,
            <given-names>L.P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Passerone</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <source>Pinto A.: Languages and Tools for Hybrid Systems Design. Foundations and Trends in Design Automation 1</source>
          ,
          <fpage>1</fpage>
          -
          <lpage>204</lpage>
          (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>