Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1.1 Introduction

1.1.1 From Centralized to Distributed Control

The evolution of computer science and information technology has made possible the application of control techniques to systems that were beyond the possibilities of control theory just a decade ago. The size of the problems faced today by control engineers has grown enormously as the limitations imposed by the communication and computational capabilities decrease. In this sense, there are strong incentives to be ambitious: society heavily depends on infrastructure systems, such as road-traffic networks, water networks, electricity networks, intermodal transport networks, etc. These are examples of large-scale, networked systems, that everybody makes use of on a daily basis, and any performance improvement would have a great direct impact on the society. However, traditional centralized control approaches cannot be used with these kind of systems due to, e.g., centralized computational issues or issues with centralized modeling, data collection and actuation.

It is at this point where distributed controllers come into play. The idea behind distributed control approaches is simple: the centralized problem is divided in several different parts whose control is assigned to a certain number of local controllers or agents. Therefore, each agent does not have a global vision of the problem. Depending on the degree of interaction that exists between the local subsystems, the agents may need to communicate so that they can coordinate themselves.

Distributed approaches have important advantages that justify their use. The first advantage is that in general these schemes are easier to implement. Their computational requirements are lower because a difficult problem is substituted by several smaller problems. In addition, these schemes are scalable. Their inherent modularity simplifies the system maintenance and the possible expansions of the control system. Moreover, the modularity provides robustness in comparison with a centralized controller. A possible failure does not have to affect the overall system. For this reason, distributed systems have a greater tolerance to failures. Nevertheless, these systems have also several drawbacks that have to be taken into account, being the main one the loss of performance in comparison with a centralized controller. This loss depends on the degree of interaction between the local subsystems and the coordination mechanisms between the agents.

During the last years many distributed control approaches using the control strategy model predictive control (MPC) have been proposed. MPC is a popular control strategy for the design of high performance model-based process control systems because of its ability to handle multi-variable interactions, constraints on control (manipulated) inputs and system states, and optimization requirements in a systematic manner. These features are essential in this context because they allow the control engineer to handle explicitly the interactions between the different subsystems.

1.1.2 Need for an Overview

Although many approaches for distributed MPC have been proposed, a coherent and easily accessible overview of the components of these approaches is lacking. Having such an overview would facilitate making the approaches easier known to a wider community, and help students, researchers and practitioners in choosing the approach most suitable for their particular situation.

This book is the result of the efforts of creating such an overview. For researchers and students, the book can provide a state-of-the-art overview, while at the same time making clear directions of research that deserve more attention. The goal that was kept in mind while developing the book was to make available to a wide audience in a systematic, practical, and accessible way the available approaches for distributed (and hierarchical) MPC. To make this possible, in each chapter of the book one particular approach is described, including:

  1. 1.

    the rationale and background of the approach;

  2. 2.

    the assumptions made on the system dynamics, control objectives and constraints;

  3. 3.

    a step-by-step description of the computations/equations;

  4. 4.

    the availability of theoretical results;

  5. 5.

    the availability of real (or simulated) applications.

The consistent description of all approaches enables readers to compare the approaches and assess the usefulness of these approaches for their respective applications.

This remainder of this chapter is structured as follows. In Sect. 1.2 we present the list of questions that served as basis for structuring the descriptions of the various schemes and the notation suggested to be used is presented. In Sect. 1.3, specific properties of distributed MPC schemes are described and a naming convention for distributed MPC schemes is proposed. Section 1.4 provides concluding remarks. Finally, Sect. 1.4 gives a categorization of schemes according to values of the properties and summaries of the specific values of a property per scheme.

1.2 Distributed MPC Schemes Commonalities

In order to obtain coherence in the description of distributed MPC schemes, we propose to structure the description of a scheme using a pre-specified set of questions and a common notation. These questions and notation suggestions were also used in the preparation of the schemes described in this book.

1.2.1 Description Questions

The most important and distinguishing elements of each distributed MPC scheme are captured by describing a scheme along the following line:

  1. 1.

    Short introduction

    • What is the rationale behind the approach?

    • Where did it originate from?

    • What makes this approach interesting?

  2. 2.

    Boundary conditions on considered system, control objectives, and constraints

    • What kind of system partition and type of dynamical model is assumed?

    • What kind of control problem is being solved for this kind of system?

    • What kind of communication architecture is assumed available?

  3. 3.

    Step-by-step description of how the approach works

    • What initialization is required?

    • What equation/optimization is used when?

    • When does what communication take place with which agent?

    • When do agents agree on/decide to take an action?

  4. 4.

    Availability of theoretical results

    • What theoretical properties have been investigated?

    • How does the approach relate to other existing approaches?

    • Where have results of this been published?

  5. 5.

    Availability of actual applications of the approach

    • What are the systems in which your approach has been tested?

    • Where have results of this been published?

1.2.2 Consistent Notation

Considering a common notation increases the coherence among the chapters and facilitates comparing the various techniques discussed. The following notational guidelines are suggested:

  • Number types:

    • \(\mathbb {R}\) for real numbers.

    • \(\mathbb {Z}\) for integers.

  • Vectors:

    • Boldface and small characters, e.g., \(\mathbf {x}\).

    • \(n_{\mathrm {x}}\) for dimension of a vector \(\mathbf {x}\).

    • \({\mathbf {x}}(k+1:k+N_{\mathrm {p}})\) represents \([\mathbf {x}^{\mathrm {T}}(k+1),\ldots ,\mathbf {x}^{\mathrm {T}}(k+N_{\mathrm {p}})]^{\mathrm {T}}\).

  • Matrices: Boldface and capital characters, e.g., \(\mathbf {A}, \mathbf {B}\).

  • Sets: Calligraphic characters, e.g., \(\mathcal {N}\).

  • Model description:

    • \(\mathbf {x}\) for states

    • \(\mathbf {u}\) for inputs/actions

    • \(\mathbf {y}\) for outputs/measurements

    • \(\mathbf {d}\) for disturbances.

  • Functions:

    • \(f,g,h\) for functions returning scalars; boldface versions for functions returning a column vector.

    • \(\oplus \) for Minkowski sum, i.e., \(\mathcal {A} \oplus \mathcal {B} \triangleq \{a+b: a \in \mathcal {A}, b \in \mathcal {B}\}\).

    • \(\sim \) for the Pontryagin difference, i.e., \(\mathcal {A} \sim \mathcal {B} \triangleq \{a: a+b \in \mathcal {A}, \forall b \in \mathcal {B}\}\).

  • Subsystems:

    • \(\mathcal {N}\) for the set of subsystems.

    • \(\left| \mathcal {N}\right| \) for the cardinality of \(\mathcal {N}\), i.e., the number of subsystems.

    • Subscript \(i\) for a variable of subsystem \(i\), e.g., \(\mathbf {x}_i\).

    • Subscript \(j\) for a variable of another subsystem (e.g., neighboring), e.g., \(\mathbf {x}_j\).

  • Network: Graph \((\mathcal {N}, \mathcal {E})\), where \(\mathcal {N}\) is the set of subsystems and \(\mathcal {E} \subset \mathcal {N} \times \mathcal {N}\) is the set of edges/links.

  • Time:

    • Discrete time index \(k\).

    • Continuous time \(t\).

    • Time index as parameter of variable: in brackets behind a variable, e.g., \(\mathbf {x}(k)\).

  • Model predictive controller:

    • Performance index: \(J\).

    • Penalty matrices: \(\mathbf {Q}\) for the state, \(\mathbf {R}\) for the actuation.

    • Target/references values for \(\mathbf {x}\): \(\mathbf {x}_{\mathrm {ref}}\).

    • Target/references values for subsystem \(i\): \(\mathbf {x}_{\mathrm {ref},i}\).

    • Prediction horizon length: \(N_{\mathrm {p}}\).

    • Control horizon length: \(N_{\mathrm {c}}\).

    • Time step within prediction horizon: \(l\).

    • The value of a variable \(x\) at iteration \(p\) will be denoted using a superscript: \(x^p\).

  • Math:

    • Transpose: Superscript T, e.g., \(\mathbf {x}^\mathrm{T }\).

    • Min/max: Subscripts \(\min \) and \(\max \) of a variable, e.g., \(x_{\min }\) and \(x_{\max }\), represent the minimum and maximum value of that variable, respectively.

    • \(\Vert \mathbf {z}\Vert _\mathbf {M}\) is the weighted Euclidean norm, i.e., \( \sqrt{\mathbf{{z}}^{\mathbf{{T}}}\mathbf{{Mz}}}\)

1.3 Properties for Categorization

There exist many different features that can be used to described a distributed control scheme. We consider the following main sets of properties as basis for comparison: process properties, control architecture properties, and theoretical properties.

1.3.1 Process Properties

This set of properties is related with the specifications of the physical system that is going to be controlled using a distributed scheme. This is an important point since it determines what schemes can be used to control the system. The most important process features are:

  • System type, or the way in which the scheme is derived: either starting from a group of autonomous systems and then introducing communication to obtain coordination, or from a (hypothetical) monolithic system decomposed into subsystems that are coordinated taking into account limitations in communication/processing power. This book itself has been partitioned in two parts according to this feature.

  • Process type, or the kind of dynamics that better capture the behavior of the system: linear, non-linear, or hybrid.

  • Type of model, or the way in which the system model is described mathematically: transfer function or state-space.

  • Randomness, i.e., whether the process shows a deterministic or non-deterministic behavior.

  • Type of control, i.e., the control goal: regulation, tracking, or economic.

  • Coupling source, or whatever makes the overall optimization problem become non-separable: inputs, outputs, state, objective, or constraints. Notice that some schemes may deal with more than one coupling source and consequently they appear in more than one column.

We present a classification of the schemes contained in the book according to this feature in Table 1.1. Table 1.2 shows a classification of the schemes in the book according to this feature. The classification of schemes according to the type of model is presented in Table 1.3. Table 1.4 presents a classification of the schemes according to the randomness feature. Table 1.5 shows a classification of the schemes in the book according to the type of control. In Table 1.6 we present the schemes that deal with each of the five possible coupling sources.

1.3.2 Control Architecture Properties

This set of properties describe the essence of the schemes presented in the book. These features are important from a practical point of view, as there may be real situations in which a scheme cannot be applied due to, for example, communicational or informational constraints. The most important features are:

  • Architecture, or how the coordination between local controllers is structured: decentralized, distributed, and hierarchical. In general, the controllers can be classified depending on how many of them participate in the solution of the control problem and the relative importance between them. We say that a control system is centralized if there is a single controller that solves the plant-wide problem. The control is decentralized when there are local controllers in charge of the local subsystems of the plant that require no communication among them. When the local controllers communicate in order to find a cooperative solution for the overall control problem the control system is distributed. Finally, if there are different control layers coordinated to take care of the process the control system is hierarchical. In this case, upper layers manage the global objectives of the process and provide references for the lower layers, which control directly the plant.

  • Controller knowledge, which measures the degree of global information that a a controller has: strictly local or partially global. Naturally, the amount of information that each agent has about the overall system has a great impact in the performance and ease of implementation of the scheme.

  • Computation type, or how the joint control actions are calculated, in an iterative or non-iterative fashion.

  • Controller’s attitude, i.e., the degree in which an agent takes into account other agents’ objectives: non-cooperative, or cooperative. In general, attitude is related with the will of collaboration between subsystems. We say that a controller has a noncooperative attitude if it behaves selfishly, i.e., it only seeks the maximization of its own objective function. On the other hand, the controllers’s attitude is cooperative when the it minimizes not only its cost but the cost of its neighbors. Hence, it may make sacrifices in terms of its own welfare to help the overall system attain a better global situation. Notice that there are some schemes that are really in between these two categories as their local controllers have both cooperative and noncooperative features. In this case, we have approximated the controller to the category in which it fits better.

  • Communication, or if there is a sequence in which the agents transmit and receive information: serial and parallel. In particular, under the serial communication paradigm only one controller can communicate at the same time in contrast with parallel communication, where several controllers are allowed to communicate at the same time.

  • Timing, or whether there is or not a strict schedule in the communication process that determines when controllers can communicate: synchronous or asynchronous.

  • Optimization variables, i.e., the nature of the variables in the optimization problem: real or integer. Notice that some schemes are in both columns since they use both these type of variables, i.e., they solve a mixed-integer optimization problem.

The classification of schemes according to this feature is presented in Table 1.7. The classification of schemes according to the controller knowledge is shown in Table 1.8. Table 1.9 shows the classification of schemes according to the computation type. Table 1.10 presents a classification of the schemes contained in the book according to the controller’s attitude. In Table 1.11 we present the classification of the schemes according to the communication. A classification of the chapters of the book according to timing can be seen in Table 1.12. Table 1.13 presents the schemes that use each type of optimization variable.

1.3.3 Theoretical Properties

This set of properties has to do with the availability of mathematical results that provide a certain guarantee regarding the scheme’s performance. The following set of properties have been considered:

  • Optimality, i.e., if the scheme provides the same result that the corresponding centralized optimization problem.

  • Suboptimality bounds, i.e., if the scheme provides a measurement of the distance with respect to the optimum of the corresponding centralized optimization problem.

  • Stability, i.e., if the the scheme guarantees a non-divergent evolution of the state and the output of the system.

  • Robustness, if the scheme is able to reject external unknown disturbances.

Table 1.14 shows a classification of the schemes according to optimality. A classification of the schemes of the book according to the suboptimality bounds property is presented in Table 1.15. Table 1.16 shows a classification of the schemes according to the stability property. We present a classification of the schemes according to the robustness property in Table 1.17.

1.3.4 Naming Convention

Using the values of the properties of the distributed MPC schemes, we propose a naming convention, to able to refer to different schemes in a standardized way. The short name that we propose is derived from three of the aforementioned features, the key features that are used to structure the distributed MPC schemes in this book. In particular, each short name is composed of:

  • Two letters indicating if the scheme is tailored for monolithical systems (Mo) or multiple independent systems (Ma).

  • Two or three letters indicating if the local controllers use a sensible amount of global information (Glo) or mainly local information (Lo).

  • Two or three letters indicating whether the scheme is iterative (It) or not (Nit).

  • A slash, followed by the first letters of the first author of the chapter.

This short naming convention provides the essence of each scheme at a glance. Naturally, there may be other short naming options. We propose this way for the following reasons.

  • We consider the main property the System type feature. Undoubtedly, this is the most important feature since it has to do with the perspective from which the distributed control scheme has been designed, bottom-up or top-down. Likewise, there is also a sensitive difference in the target applications of these two families of schemes. We observe two different perspectives: The Group of Autonomous Systems Perspective and The Decomposed Monolithic System Perspective.

  • The second property has to do with the degree of global information that local controllers have. On the one have we have local controllers that only have strict local information and on the other we have controllers with a significant amount of global information. While the first approach could be favorable for systems with a dynamic structure (e.g. plug-and-play networks), the second can simplify the coordination due to the additional knowledge about the overall system.

  • Finally, we have chosen as third distinguishing property in the short naming the Computation type, i.e., if the scheme is iterative or not.

This book is structured using the same criteria on which the short naming convention is based. The chapters in the book are ordered from most distributed to most centralized, as shown in Table 1.1. Indeed, the first chapter discussed scheme MaLoNit, i.e., multiple subsystems controlled by agents that only have local knowledge and that do not iterate in order to find a solution. This contrasts the last chapter of the book, which is MoGloIte, i.e, a scheme considering local controllers that have global system information and exchange information iteratively in order to find a control action for the decomposed monolithical system they are controlling.

1.4 Concluding Remarks

The techniques presented in the book, introduced in accessible and standardized way, constitute a true handbook of distributed model predictive control. In this sense, we believe that this book will become a valuable aid for those readers that are beginning their research careers (e.g.: master and PhD students). Likewise, researchers in the field will find in this book a valuable survey of the state-of-the-art methods carefully explained by their original contributors. But the contribution of the book goes far beyond theory. The current compilation of hierarchical, decentralized and specially distributed model predictive control schemes provides a potential solution to almost any imaginable application. Vehicle formation, irrigation canals, chemical processes, energy networks, among many others, are used as benchmarks in the book. For this reason, practitioners will also find the tools and recipes they need to face their practical challenges.

As editors of this compilation of schemes, we do not expect this first edition of the book to be the last one. Despite that the field of distributed MPC has registered a strong research activity during the last decade, there are still new schemes being proposed every now and then. On top of that, it is also easy to find enhancements of previous schemes that guarantee new theoretical properties. Nevertheless, we can say the basis of this young research field is already settled.

What will the future bring? We envision several potential research lines. We expect a refinement of the most popular schemes aiming to a commercial implementation. So far, most distributed control schemes have only been tested via simulations or with lab benchmarks. A real implementation will demand to discard some of the simplifications made during the research, e.g: common distributed computing fallacies as assuming that the network is reliable. We also expect a proliferation of dynamic distributed control schemes, able to adapt the degree of coordination to the circumstances. For example, one may think of a traffic network. When the system is close to congestion, a high degree of coordination and communication is necessary between the agents. On the contrary, if the roads are almost empty (e.g., at night), such coordination is not needed and agents can work in a decentralized fashion. Furthermore, the development of the field will also be linked to the evolution of paradigms that may become strong research topics such as the domain of systems of systems.