This section introduces theory relating to the behavior modeling and formal validation of functionality in the canal system. Procedures for the assessment of the canal system performance will be based on variational analysis of fluid system flows and sequencing of pump and gate operations. Timed (finite state) automata and model checking procedures will be used to assess the correctness of functionality for waterway system operations.

#### 4.1. Mathematical Modeling of the Fluid System

The desired configuration of the fluid system is the one that: (1) does not violate flow continuity constraints of fluid,

i.e., water in this case, and (2) maintains the fluid pressure compatibility constraints in the system. Thus, instead of the full loop variational indicator [

24], we rely on the complementary form of Hamilton’s principle, which results in the fluid system obeying the following set of Lagrangian’s equations of motion.

where

G is the content of the fluid dissipators,

${P}_{j}$ the generalized fluid pressure source of the

${j}_{th}$ fluid volume coordinate;

$j=1,2,...,g$. The system co-Lagrangian

${L}^{*}$ is defined based on the total co-kinetic energy of the system fluid inertances

${T}^{*}$ and the total potential energy of the system fluid flow stores

U as follows (

$r\le g$).

The fluid system Lagrangian

L is defined based on the total kinetic energy of the system fluid inertances

T and the total co-potential energy of the system fluid flow stores

${U}^{*}$ as follows.

Equations (

1) through Equation (

3) describe the behavior of a wide range of dynamical systems. The next step is to customize the mathematical formulation to the specific details of fluid-flow operation in our canal system setup.

**Step 1.** The relative configuration of Lock 2 and the reservoir means that water can flow from Lock 2 to the reservoir by gravity alone. Therefore, L2 is the only volume considered; thus,

$g=1$, and

${T}^{*}$,

U and

G are defined using the reservoir capacitance

${C}_{fR}$, pipe inertance

${I}_{f}$ and resistance

${R}_{f}$ as follows.

We combine Equations (

4) and (

5) into Equation (

2) and replace the result into Equation (

1) along with Equation (

6). We also have

${P}_{j}={P}_{S}$, the pressure of the ship, and express the volume of the water in Lock 2 as a function of its section

${A}_{2}$ and water height

${h}_{2}$ by

${V}_{2}={A}_{2}{h}_{2}$. These transformations result in the following differential equation that captures the dynamics of water flow from lock L2 to reservoir R.

**Step 2.** Water is transferred from the reservoir to Lock 1 for equalization of the water level with Lock 2. This step is accomplished with

nodal analysis, which is a fluid momentum-based (Γ) approach appropriate for understanding the dynamic of the water flowing from the reservoir R to Lock L1. Lagrangian’s equations of motion are written as follows:

where

J is the co-content of the fluid dissipators;

${Q}_{j}$ the generalized fluid flow source associated to the

${j}_{th}$ fluid momentum coordinate;

$j=1,2,...,l$.

**Step 3.** Water is transferred between lock L1 and the reservoir. From Equation (

1) through Equation (

8),

$l=2$, and

T,

${U}^{*}$,

${Q}_{j}$ and

J are defined using, in addition to the parameters defined above, the reservoir capacitance

${C}_{fR}$, section

${A}_{R}$, water height

${h}_{R}$ and the water height in Lock 1

${h}_{1}$ as follows.

The first order linearization of Equation (

11) at the connection Point B of the pipe to the reservoir (as close as possible to the bottom of the reservoir) results in the following equation.

We replace Equations (

9) and (

10) into Equation (

8) and subsequently into Equation (

7) along with Equation (

12). Since there is no external source of water flow to any of the two tanks, we have

${Q}_{j}=0$. Furthermore, we have

$P=\dot{\Gamma}=\frac{A}{{C}_{f}}h$. Equipped with these transformations, we compute the derivate of the resulting expression of Equation (

7), respectively, to

${\Gamma}_{1}$ and

${\Gamma}_{R}$ and obtain the following set of differential equations.

With the ship now in Lock 1, a pump with pressure

${P}_{t}$ is needed to pump the water out of L1 to the reservoir R. We perform another loop variational analysis using the same set of Lagrangian’s equations of motion as Equation (

1) and rewriting Equations (

3) to (

5). After combination, simplification and replacement of

A by the section of the ship in contact with water in Lock 1,

i.e.,

${A}_{1S}$, we obtain:

Equations (

6), (

13) and (

14) describe the behavior of the water lock system, that is water equalization between Locks L1 and L2 during an outbound ship crossing. Along with Equation (

15), this set of equations fully represents the three sequences of behavior for the water lock fluid system during an outbound crossing.

#### 4.2. System Behavior Modeling with Networks of Timed Automata

Timed systems are those where timing and scheduling of events (

i.e., logical results of computation) are relevant to correct operations [

25]. In a hard real-time system, correct operation depends on the satisfaction of hard deadlines. Missing a deadline in a safety-critical system may have a disastrous effect. Soft real-time systems have correct operations that depend on the satisfaction of “average time” constraints.

Many complex engineering systems can be easily modeled using networks of communicating finite state machines (e.g., software systems; digital circuits; control of traffic through intersections). Individual processes are represented as finite state machines (FSM); embedded software systems can be modeled as networks of communicating FSM, as illustrated in

Figure 5. A deterministic finite automaton (DFA) is a simple machine that reads an input string (one symbol at a time) and then, after the input has been completely read, decides whether to accept or reject the input [

26]. In mathematical terms, a DFA is a five-tuple

$\left(Q,\sum ,\delta ,{q}_{o},F\right)$ where: (1) Qis a set of states; (2) ∑ is a finite alphabet; (3)

δ: Q × ∑ → Q is the transition function; (4)

${q}_{o}$ ∈ Q is the start state; and (5) F ⊆ Q is the set of accepting states. The language recognized by a DFA M is the set of all strings accepted by M and is denoted L(M). Simply put, automata are simple, but useful models of computation. They keep notions of state, stepping between states and well-defined start and end states, but omit notions of memory, variables, commands and expressions. Constructions on automata are a way of systematically building automata from (smaller automata) components [

26]. In other words constructions operate on automata, yielding new automata. Therefore, constructions are a way of systematically building automata from (smaller automata) components. For example, the product automaton takes two DFAs and delivers the product automaton, also a DFA. Conceptually, the product automaton is a single machine that runs its two component machines in parallel on the same input string. At each step of the computation, both machines access the (same) current input symbol, but make transitions according to their respective transition functions. Construction operations provide closure under union, intersection, complement and concatenation operations.

A timed automaton is a stripped-down finite-state machine extended with clock variables. Mathematically, we state that a time automaton A over clocks C and actions Act is a four-tuple $\left(L,{l}_{o},E,I\right)$ where: (1) L is a finite set of locations; (2) ${l}_{o}$ is the initial location; (3) E ⊆ L × B(X) × Act × P(C) × L is the set of edges; and (4) I:L → B(X), each location to an invariant. Within an automaton model, the system’s states are defined by the locations of all automata, the clock constraints and the values of discrete variables in the model. Every automaton may fire an edge separately or synchronize with another automaton, which leads to a new state. Edge firings are not allowed to be carried out simultaneously; therefore, the automata do not really operate in parallel, but rather in an interleaving way.

#### 4.3. Model Checking

While semi-formal procedures such as SysML are useful for preliminary design (mainly because they force a designer to think about what they really want!), some errors, such as safety and liveness conditions, may be far too subtle to catch by inspection. Therefore, there is a strong need for automated procedures for the analysis of design specifications. Model checking [

27] is a technique that relies on building a finite state model of a system and checking that a desired property holds in that model. Given a state-transition graph (M) and a formula (f), the model checking problem aims to decide whether the formula (f) is true for all possible runs. In mathematical terms, model checking solves the problem:

That is, find all states “s” of “M”, such that formula “f” holds. If the property does not hold, then a counter example will be provided. To date, model checking has been used primarily in hardware and protocol verification; the current trend is to apply this technique to analyzing specifications of software systems.

#### 4.4. Model Checking with UPPAAL

UPPAAL [

8] is an integrated tool environment for modeling, simulation and verification of finite-dimensional real-time systems that can be modeled as a collection of non-deterministic processes (timed automata). Assessment procedures are described in terms of temporal logic. Typical areas of application include real-time controllers and communication protocols in particular, those where timing aspects are critical. Thus, as a real-time system, our water lock system falls within the scope of this software.

System behavior is described in terms of timed automata extended with variables and real-valued clocks where clock variables evaluate to a real number, increase without bound and may be associated with a transition, in a guard or in a reset, and with a node, using an invariant. This is a dense-time model. The state of the system is defined by the locations of all automata, the clock constraints and the values of the discrete variables. Every automaton may fire an edge separately or synchronize with another automaton, which leads to a new state. Edge labels may include constraints on integer variables and array components in their guards, similar to timing constraints, and may specify assignments to variables in their actions, which are executed simultaneously.

To avoid the need for dealing with an infinite number of clock values, UPPAAL uses zones defined by sets of constraints on clock values. When a system is in a particular state (location), we do not have a concrete value of time; instead, differences defined by region boundaries. A particular simulation explores only a particular execution trace (i.e., sequence of states of the system). The model checker uses state-space exploration to ascertain whether certain combinations of control nodes and constraints on clocks and integer variables are reachable from an initial configuration. Other properties, such as bounded liveness, can be checked by reasoning about the system in the context of testing automata or annotating the system description with debugging information and then checking reachability properties. In checking a property, a diagnostic trace can be automatically reported explaining why the property is satisfied or not. This trace can be visualized by running it through the simulator.