In industrial automation the aim is to control and optimise production processes and to provide high-quality and reliable products and services by minimising material, cost, and energy waste. Automation systems rely on smart sensors, actuators, and other industrial equipment like robotic and mechatronic components. Open and standardised communication networks are employed for the communication as well as configuration and control of the various automation components. The standard architecture consists of PLCs (Programmable Logic Controllers) or DCS (Distributed Control Systems), fieldbus systems, and PCs serving as man/machine interfaces as well as intelligent sensors and actuators (e.g. frequency converters). The fieldbus systems gather the signals from the process level or the sensors and actuators with fieldbus interfaces, and are directly connected to distributed or centralised control devices, such as PLCs.

The standard IEC 61131-3 of the International Electrotechnical Commission provides a range of programming notations suitable for implementation on PLCs. It comprises basic notations close to those in electrical engineering like contact plans, instruction lists, and function plans as well as graphical and textual programming notations called sequential function charts and structured text. Currently, the development of software in automation technology proceeds step by step along the life cycle using the notations of this standard and different tools provided by different PLC vendors.

A problem is that different PLC vendors use their own variants of the standard with different syntax, semantics, and tool sets. Also, the approaches based on the standard are not well suited for the development of distributed applications and applications with hard real-time requirements.

The Duration Calculus can be used as a high-level specification language for properties of real-time systems. The question arises whether reasoning about such specifications can be automated. To this end, we first discuss the decidability of the realisability problem of the Duration Calculus: is there an algorithm that for a given Duration Calculus formula decides whether this formula can be realised. By using proof techniques of Zhou Chaochen, M.R. Hansen, and P. Sestoft, we show that for a subset of the Duration Calculus and the discrete-time domain this problem is indeed decidable. However, for the general case of continuous time it is not. The proofs of these results shed light on the difference between these two time domains.

Next we introduce the subset of implementables due to A.P. Ravn. This subset provides certain patterns of formulas formalising concepts like stability and progress that are convenient for specifying the behaviour of controllers. Finally, we introduce Constraint Diagrams due to C. Kleuker as a graphical representation of a subset of Duration Calculus. These diagrams specify timed behaviours in an assumption/commitment style. We show that the implementables all have lucid representations as Constraint Diagrams. In general, Constraint Diagrams are more expressive than implementables.

Decidability results

Zhou Chaochen, M.R. Hansen, and P. Sestoft showed that the problem whether a given DC formula is satisfiable is decidable for a subset of DC when discrete time is assumed [ZHS93]. This result has been exploited by P.K. Pandya in a tool called DCVALID for automatically checking satisfiability and validity of formulas in this subset [Pan01].

Computers are used more and more to provide high-quality and reliable products and services, and to control and optimise production processes. Such computers are often embedded into the products and thus hidden to the human user. Examples are computer-controlled washing machines or gas burners, electronic control units in cars needed for operating airbags and braking systems, signalling systems for high-speed trains, or robots and automatic transport vehicles in industrial production lines.

In these systems the computer continuously interacts with a physical environment or plant. Such systems are thus called reactive systems. Moreover, common to all these applications is that the computer reactions should obey certain timing constraints. For example, an airbag has to unfold within milliseconds, not too early and not too late. Reactive systems with such constraints are called real-time systems. They often appear in safety-critical applications where a malfunction of the controller will cause damage and risk the lives of people. This is immediately clear for all applications in the transport sector where computers control cars, trains and planes.

Therefore the design of real-time systems requires a high degree of precision. Here formal methods based on mathematical models of the system under design are helpful. They allow the designer to specify the system at different levels of abstraction and to formally verify the consistency of these specifications before implementing them. In recent years significant advances have been made in the maturity of formal methods that can be applied to real-time systems.

Structure of this book

In this advanced textbook we shall present three such formal approaches:

• Duration Calculus (DC for short), a logic and calculus for specifying highlevel requirements of real-time systems;

• […]

Timed automata were introduced by R. Alur and D. Dill as an operational model of real-time systems. In their simplest form timed automata extend classical finite automata, having only finitely many control states, by clock variables ranging over the non-negative real numbers (continuous time). Constraints on the values of the clock variables serve as guards of the transitions and as invariants in the control states. Timed automata can be combined into networks by using parallel composition and restriction operators of process algebras like CCS or CSP. One of the most important results on timed automata is that it is decidable whether a given control state is reachable. This led to the development of several tools for the automatic verification of behavioural properties of timed automata. Here we shall present in more detail the tool UPPAAL.

Timed automata

Timed automata engage in transitions from locations to locations when certain timing conditions are satisfied. These transitions either perform input and output actions on channels that will synchronise with other timed automata working in parallel or they perform internal actions that are invisible from the outside.

As a first contact with timed automata let us look at an example.

Example 4.1 (Light controller)

We wish to model a light controller with the following behaviour. Initially, the light is off. When the switch is pressed once, the light goes on (into a dim mode). If the switch is pressed twice quickly the light gets bright. Otherwise, if the switch is pressed only after a while the light goes off again.

What is a real-time system?

This book is about the design of certain kinds of reactive systems. A reactive system interacts with its environment by reacting to inputs from the environment with certain outputs. Usually, a reactive system is not supposed to stop but should be continuously ready for such interactions. In the real world there are plenty of reactive systems around. A vending machine for drinks should be continuously ready for interacting with its customers. When a customer inputs suitable coins and selects “coffee” the vending machine should output a cup of hot coffee. A traffic light should continuously be ready to react when a pedestrian pushes the button indicating the wish to cross the street. A cash machine of a bank should continuously be ready to react to customers' desire for extracting money from their bank account.

Reactive systems are seen in contrast to transformational systems, which are supposed to compute a single input–output transformation that satisfies a certain relation and then terminate. For example, such a system could input two matrices and compute its product.

We wish to design reactive systems that interact in a well-defined relation to the real, physical time. A real-time system is a reactive system which, for certain inputs, has to compute the corresponding outputs within given time bounds. An example of a real-time system is an airbag. When a car is forced into an emergency braking its airbag has to unfold within 300 milliseconds to protect the passenger's head. Thus there is a tight upper time bound for the reaction. However, there is also a lower time bound of 100 milliseconds.

The finite automaton is one of the simplest and most fundamental computing models. You are almost certainly familiar with this model from your first course in the theory of computing, but if not, you may want to review the material in Sections 1.3–1.4.

In this chapter we reexamine the theory of finite automata from a more advanced standpoint. In particular, we prove the very important Myhill–Nerode theorem in Section 3.9.

We begin with some generalizations of the finite automaton model.

Moore and Mealy machines

In most introductory courses on automata theory, finite automata are viewed as language recognizers, not as computers of functions. A deterministic finite automaton (DFA), for example, takes a string as input and either accepts or rejects it. Of course, we can view a DFA as computing a function f : ∑* → {0, 1}, where 0 represents rejection and 1 acceptance, but there are other ways to associate outputs with machines.

In this section, we introduce two simple models of finite-state machines with output, called Moore and Mealy machines. A Moore machine has outputs associated with its states, while a Mealy machine has outputs associated with its transitions.

We can use transition diagrams to represent both Moore and Mealy machines. In a Moore machine, a state labeled q/b indicates that when state q is entered, the output b is produced. In a Mealy machine, a transition labeled a/b indicates that when this transition is taken on input symbol a, the output b is produced.

In this chapter, we discuss how to decompose a given multigraph G into a set of forests to obtain a spanning subgraph that preserves the edge/vertex-connectivity of G. We introduce a total ordering of the vertices in a multigraph G, called a maximum adjacency (MA) ordering, and then find such a forest decomposition. Based on this set of forests, we can convert G into a sparse graph in linear time while preserving the edge/vertex-connectivity. This sparsification technique can be used for many connectivity algorithms as a preprocessing that reduces the size of input graphs. We describe some of the applications of connectivity algorithms.

Spanning Subgraphs Preserving Connectivity

A k-edge-connectivity certificate (resp. k-vertex-connectivity certificate) of a multigraph G is a spanning subgraph H of G such that, for any two vertices u, ν and any positive integer k′ ≤ k, there are k′ edge-disjoint (resp. internally vertex-disjoint) paths between u and ν in H if and only if there are k edgedisjoint (resp. internally vertex-disjoint) paths between u and ν in G. That is, a kedge- connectivity (resp. k-vertex-connectivity) certificate is defined as a spanning subgraph that preserves the edge-connectivity (resp. vertex-connectivity) up to k. Therefore,when H is a k-edge-connectivity certificate (resp. k-vertex-connectivity certificate) of G, H is k-edge-connected (resp. k-vertex-connected) if and only if G is k-edge-connected (resp. k-vertex-connected). If a k-edge-connectivity certificate H of G is k-edge-connected, then |ε(H)| ≥ holds since the degree of any vertex in H is at least k. Then we say that a k-edge-connectivity certificate H is sparse if |ε(H)| = O(kn). A sparse k-vertex-connectivity certificate is similarly defined. It is known that such a certificate exists [203].