Model Sharing and Scalability in the Real-Time Simulation and Intelligent Hierarchical Control of Discrete-Event Systems

Abstract

Large-scale automated systems such as manufacturing systems, transportation systems, the Smart Grid and many others are continuously becoming larger, more distributed, more complex, and more intelligent. There is a growing expectation that their software controller will make real-time intelligent decisions, at all levels of the control hierarchy that make up the enterprise. The need is changing for distributed intelligent controllers that are scalable to arbitrarily large systems. In this paper, we first present the model explosion problem. This problem arises when every controller in the control hierarchy is to have a unique simulation model of its unique control domain to use in its decision-making process. That is, the modeling effort needed to provide intelligence to all controllers in the control hierarchy grows exponentially with the number of controllers in the hierarchy using current modeling technology. Since each controller is in a unique location within the control hierarchy, each will need to have its simulation model custom made for its unique control domain, leading to the scalability issue that we refer to as the model explosion problem. Next, a new modeling paradigm that solves the scalability issue resulting from the model explosion problem is presented, where the simulation models are automatically generated by recycling the models used for control. If the controller models are created using the presented modeling paradigm, then these same models can be used for simulation with no modification or the need to understand the control logic. Furthermore, gathering the state from the physical system being controlled to initialize the simulation models in a real-time control application becomes a trivial operation of simply coping data from one software model to its identical copy, without the need to interpret the meaning of the data. Finally, an example of a hierarchical controller to control a small physical model of a manufacturing plant is presented. We show how we automatically generated all the simulation models in the control hierarchy without any modification and with minimal effort, and used them to make intelligent decisions in real time.

1. Introduction

Today there are many large-scale automated systems which include manufacturing plants, such as Flexible Manufacturing Systems (FMSs), the Smart Grid, security systems, and many other systems. Tomorrow’s automated systems may be even larger. Consider an intelligent transportation system that involves autonomous vehicles all coordinated in some fashion to reduce traffic, an intelligent delivery system that coordinates airplanes, ships, trucks, drones and other means perhaps not yet discovered to optimize delivery cost, a better coordinated Smart Grid system where all of the individual power companies are coordinated by an enterprise-wide real-time intelligent control system, and many other systems we have yet to create. We do not know what systems are being designed and created in the future but what we do know is that these systems are growing in size, growing in the level of automation and growing in their expectation for intelligent operation.

These control architectures are generally distributed among many computers. Many controllers that are used to control today’s, and future, systems have a control hierarchy with the topmost controller responsible for the most aggregate decisions down to the low-level controllers deciding on very specific local issues. For example, the Supervisory Control and Data Acquisition (SCADA) [1] control architecture is used to control physical plants. It has five levels in its control hierarchy with the topmost level performing production scheduling and the bottommost performing field-level decisions.

These controllers run independently on different computers and rely on communication through a network for coordination. Many of these systems continuously run in a highly transient state. Consider an FMS that is designed to produce many different types of parts, in very small quantities, filling the customer’s requests as they arrive. We assume that to control the automated systems we have today and in the future in some intelligent way, the controllers at all levels in the control hierarchy will need to have capabilities to make intelligent decisions.

A large body of research in the real-time intelligent control of large-scale discrete-event systems (DESs) is related to manufacturing, where these systems rely on non-deterministic discrete-event modeling and real-time simulation to produce feedforward information that is then used in their decision-making process [2,3]. These simulations are used to evaluate different alternative options, sometimes referred to as control laws, to then select the best option in the hope it improves the performance of the system by some target metric, see [4]. This type of simulation is used to predict the performance under a what-if scenario and therefore must be executed extremely fast. Since the physical system does not stop to wait for the controller to optimize the system or make any type of decision, the controller must continue to operate the system while concurrently running its decision-making process. This leads to the need for real-time simulation; that is, the controller continues to operate the physical system while concurrently performing its intelligence that relies on simulations.

The stochastic nature of the systems these controllers are generally used for requires the simulation to run many times with the same initial state but different random numbers to better cover the whole risk space. Therefore, while the system is distributed, the simulation cannot be. It is important to note that this type of simulation is not considered to be distributed or parallel simulation even though the system it is modeling is, in fact, distributed. This type of simulation requires the use of a model that accurately represents the behavior of the system being controlled. Therefore, to implement intelligence in a controller, a simulation model must be created for that controller that encompasses the logic in that controller’s complete control domain.

This effort is called the simulation modeling effort, not to be confused with the control modeling effort that is needed to create software models that simply control the system without any significant optimization or performance improvement strategies. Note that in a distributed controller, every controller is at a unique location in the control hierarchy and, therefore, has a unique control domain and needs to have a unique simulation model. Furthermore, the higher the location of the controller within the control hierarchy, the more subordinate controllers are in its control domain, and therefore, the more logic their simulation models need to encompass. This leads these controllers to encompass more logic, requiring more effort to create. If one were tasked with creating a simulation model for a particular model somewhere in the control hierarchy, one may find that a good approach is to copy the logic from all its controllers in its control domain and glue them together into a new simulation model. This cut-and-paste operation may represent a significant effort and may lead to errors representing the control logic of its subordinate controllers.

Our contributions are summarized as follows:

• We show how the simulation modeling effort increases exponentially with the increase in the number of control models, which we refer to as the model explosion problem. We first derive the equations, then we show this exponential growth rate. The purpose of this analysis is to bring awareness to this problem that will only become worse over time.
• We propose a solution to the model explosion problem by presenting a new modeling paradigm where the process of creating simulation models used for intelligent distributed control is mostly automated when given the set of control models in its control domain. The control models are recycled and also used for simulation with minimal or no modification.

This paper has three parts. The first part shows how the modeling effort increases exponentially with the increase in the size of the system, thus leading to the model explosion problem. Implementing a large scale distributed intelligent controller using the current modeling technology is not scalable, as the model explosion problem makes the simulation modeling effort increase exponentially, while the modeling effort to create the non-optimizing controllers increases only linearly with an increase in the number of individual controllers in the control hierarchy. This part presents the derivation of formulas that compute the modeling effort, given parameters associated with the size and shape of the hierarchy. Its purpose is to show the strong need for such a new paradigm that is scalable to large-scale systems. This can benefit any distributed controller that must have decision-making capabilities at all levels of the hierarchy. Examples include the Smart Grid, intelligent transportation systems, flexible manufacturing systems and many more. The second part presents a solution to this problem. It shows a new modeling paradigm that allows us to automatically create simulation models by sharing the control models. This is important for scalability issues, since using this paradigm we only need to create the control models manually, an effort that increases only linearly with an increase in the size of the overall distributed controller. The simulation modeling effort, which increases exponentially with an increase in the size of the controller, is avoided. Therefore, using this new modeling paradigm to create an intelligent controller is considered scalable to large-scale systems when compared to using the current modeling technology that requires creating each simulation model manually. The paper presents the theory that supports this paradigm. Finally, the third part presents a case study or example where we create a controller that has intelligent decision-making capabilities using a simulation model created from recycling the set of control models. We measure and compare the simulation modeling effort that was needed using this paradigm versus that using a traditional modeling paradigm.

2. Related Work

Later in the paper we will show how the amount of code needed to implement the simulation models grows exponentially to the size of the system being controlled. Without any technology aimed at the automatic generation of models, one will need to manually write this modeling code. For example, Arena [5] is a popular modeling and simulation software used by the manufacturing community. It allows the user to create discrete-event models and then run simulations using the models to predict performance under test conditions, see Simulation with Arena [6]. It is not used for control. Because each unique model is written manually, this method is not scalable, as it suffers from the model explosion problem. There are several methods that are being studied that avoid the model explosion problem.

One method involves model reuse; however, these methods do not refer to reusing the control models for simulation but rather to reusing the general simulation models for other simulation needs. That is, in this approach, a generic simulation model is used and each time one needs to create a new simulation model, the generic model is used as a starting point and customized to the system. In [7] they present a generic simulation model that models a seven-step manufacturing process. In [8] they created a library of generic models for manufacturing processes. Both these methods are limited to manufacturing, and both still require a significant modeling effort to produce the simulation models.

In [9] the authors are working on reducing the simulation modeling effort; however, they are focused on multi-fidelity models. Their method, called Optimization-based Multi-fidelity Simulation Modeling (OMFSM) requires the designer to provide some models and then it adjusts the resolution to optimize speed and accuracy. They indicate that creating simulation models is currently an expensive and time-consuming manual process that requires expertise and domain knowledge.

Another method is to generate simulation models automatically by observing the data generated by the manufacturing process [10]. These digital models are automatically generated by analyzing the data stream to estimate a Petri net model. The premise of this work is a reverse engineering approach, whereby through analyzing the production data logs over time, one should be able to estimate the model that generated the data logs, which is the control model. A survey of approaches, Ref. [11], shows several works related to this approach. One can see several challenges using this approach. First, it is only an estimation of the model based on past operation history. Processes that occur only on rare occasions may not be captured in the data logs. Another challenge is initializing the models to the current state of the system. In [12] they show how this process is prone to errors. Other challenges are presented in [13], where they say more research is needed. In [14] they indicate this method is still in its infancy stage and the current studies use overly simplified models that are unrealistic.

In contrast, the premise of our approach is not to estimate the simulation model by observing the control model in operation, but rather use the control models for simulation. The control models must exist, since they are actively being used to control the system. So then one may ask, why estimate something that is known? The answer is because it is very time-consuming to understand the logic in all the independent control models. However, we show how the control models can be used directly, without any modification, and without understanding their logic details, for simulation if the presented modeling paradigm is used to create the control models. That is the merit of this work. Furthermore, the approach of building the system then figuring out how to add simulation capabilities after the system is operational is not scalable. The model estimation will become more complex and more difficult to estimate as the systems grow. We show how our approach is scalable to arbitrarily large systems. That is also the merit of this work. In [5,12,13], they show the challenges in initializing the simulation models with the current state of the physical system in operation. For example, in [15] they present a machine learning algorithm that estimates the dynamic parameters associated with the physical system to automate the simulation initialization process, which they say is currently a difficult manual process prone to errors. The authors indicate that, due to the human interventions needed, this process is not performed as often as needed, leading to obsolete and inaccurate models. This problem becomes trivial using our approach, since the simulation models consists of the same source code as the control models so state transfer is a simple matter of copying the data in the data structures from one copy of the code to the other, a process performed by being totally automated.

3. Materials and Methods

A scalability issue arises when we desire to implement optimization at all levels of the control hierarchy. Consider a controller somewhere towards the top of the control hierarchy. Its simulation model must include the logic in all the controllers below it in its control domain, while its control model only needs to consider its own process logic. One can see that the logic in the controllers towards the bottom of the tree is duplicated many times in the simulation models of the controllers in its chain of command.

Before we begin, we first present some assumptions we are making, along with some preliminary information needed to understand the remainder of this section. The tree structure in a hierarchical controller lends itself to easier analysis, since there are useful theorems associated with the shape of the tree. So, while the shape of the control network is not guaranteed to have a hierarchical tree structure, it is assumed it does for the sake of the analysis. It should be noted that the model explosion problem is not a cause of the hierarchical tree structure but rather of the chain of command a controller system may have, regardless of its network structure.

We assume that each individual controller in the intelligent control hierarchy has two software components, the actual controller which we will refer to as the control model and the simulation model. The control model runs its subsystem without any significant effort to improve its performance unless it possesses intelligence, in which case it must also have a simulation model. This simulation model must accurately predict the reaction of any decision it makes and therefore must encompass the logic in all the controllers in its control domain.

Table 1. Summary of assumptions.

Assumption	Description
A	Intelligent controllers have a tree-like hierarchical architecture.
B	Optimization generally uses nondeterministic discrete-event simulations to produce feed-forward information, Gonzalez [2].
C	A truly intelligent controller should have optimization capabilities at all levels of the control hierarchy. Therefore, each controller has two software components, called models, one for its control and the other for its simulation.
D	Both the controller and the simulation may be decomposed into its model and the engine that runs the model.
E	The control model may contain source code that is similar to the source code in the part of the simulation model that represents its logic, Gonzalez [2,3].
F	Each discrete-event simulation engine needs a model that encompasses the logic in its control domain. In this case, all the controllers in its control domain.

summarizes the assumptions we have made.

In reference to assumption F in Table 1, the controller may be a tool which, given a control model, runs the controller.

We denote the control modeling effort, or time that an engineer will need to spend to create the models used to control the system, as C, and the simulation modeling effort, the time it takes to create the models used to run the simulations needed to support its intelligent decision-making process, as S. We will first show a small sample control hierarchy and compute the modeling effort to support simulation at all controllers. Then we extend our reasoning to arbitrarily large hierarchies with arbitrary shapes to derive a set of formulas that compute the modeling effort needed to add optimization to the controllers for a general control hierarchy. To put the simulation modeling effort into context, we will present the explosion problem using the value of P, the ratio of S to C.

$$\mathrm{P}={\displaystyle \frac{\mathrm{S}}{\mathrm{C}}}={\displaystyle \frac{\mathrm{S}\mathrm{i}\mathrm{m}\mathrm{u}\mathrm{l}\mathrm{a}\mathrm{t}\mathrm{i}\mathrm{o}\mathrm{n}\hspace{0.33em}\mathrm{M}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\hspace{0.33em}\mathrm{E}\mathrm{f}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{t}}{\mathrm{C}\mathrm{o}\mathrm{n}\mathrm{t}\mathrm{r}\mathrm{o}\mathrm{l}\hspace{0.33em}\mathrm{M}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{l}\mathrm{i}\mathrm{n}\mathrm{g}\hspace{0.33em}\mathrm{E}\mathrm{f}\mathrm{f}\mathrm{o}\mathrm{r}\mathrm{t}}}$$

(1)

Consider the following tree, where each circle represents a controller implemented as a computer running some code to control its subordinate controllers or system. Typically, the controllers at the bottom have direct control of the system, while the top and middle controllers are like managers in that they delegate to the lower-level controllers.

To quantify modeling effort, we define one unit of modeling effort to be the effort needed to produce the logic for a single non-optimizing controller. We also assume all the controllers in the control hierarchy are similar in size and complexity, resulting in a similar modeling effort to produce them. Because of Assumption E in Table 1, the modeling effort to add the logic of a single controller into a simulation model is also one unit of effort, since the logic in the control and simulation models are similar. Our approach is to first study the modeling efforts for the sample tree in Figure 1b then extend this analysis to the general case for arbitrary large hierarchies and to arbitrary shapes.

3.1. Sample Tree

To analyze the control modeling effort, C, we can see that the tree in Figure 1b has 13 nodes or circles so the modeling effort to create the set of basic non-optimizing controllers is 13. To compute the simulation modeling effort, C, we can start at the lowest level of the tree. There are nine simulation models for the nine controllers, each only modeling the code in its corresponding controller. We add a modeling effort of nine for that row. The next level up has three controllers, where each model must include the logic of its own controller and the three controllers in its control domain. The total modeling effort for the second row is therefore 12 units, three controllers with a modeling effort of four each. The topmost controller requires a simulation model that encompasses the logic of itself plus the 12 controllers in its control domain, requiring a modeling effort of 13 units. Adding these yields 9 + 12 + 13 = 34 total modeling effort to produce the 13 unique simulation models needed to provide every controller with simulation capability. Therefore, to add simulation models to all 13 controllers, we will need to provide an additional modeling effort equal to $\mathrm{P}={\displaystyle \frac{\mathrm{S}}{\mathrm{C}}}={\displaystyle \frac{34}{13}}=2.6$ times the effort that we spent on creating the set of non-optimizing controllers.

3.2. General Tree

Next, we will generalize this analysis to the case of a general hierarchal controller with an arbitrary number of independent controllers and an arbitrary fan-out at each controller. The amount of additional work to add simulation capabilities to each controller is dependent on the number of individual controllers, the number of levels in the control hierarchy and the shape of the hierarchy tree, that is the fan-out at each node. We will let N represent the number of controllers and L represent the number of levels in the control hierarchy tree. Note, the control modeling effort to build all the control models for the controller, C, is independent of the shape of the tree, since each node in the tree represents a single controller with a single model for its control logic. Therefore, we have the following:

$$\mathrm{C}=\mathrm{N} \mathrm{f}\mathrm{o}\mathrm{r} \mathrm{a}\mathrm{l}\mathrm{l} \mathrm{s}\mathrm{h}\mathrm{a}\mathrm{p}\mathrm{e}\mathrm{s} \mathrm{a}\mathrm{n}\mathrm{d} \mathrm{t}\mathrm{r}\mathrm{e}\mathrm{e} \mathrm{h}\mathrm{e}\mathrm{i}\mathrm{g}\mathrm{h}\mathrm{t}\mathrm{s}$$

(2)

The sample trees in Figure 1a–c have a constant fan-out and are full trees. This gives the tree a perfect tree-like shape. However, without making any assumptions of the shape of the control hierarchy of a controller, we must compute an average modeling effort over all possible shapes or fan-outs. That is, given a fixed number of controllers and a fixed tree height, fixed N and L, we must compute the average modeling efforts over all possible fan-out combinations.

We next study how the simulation modeling efforts change with changes to the tree shape. Consider the trees in Figure 1d–f, each with 7 nodes. The only difference among the trees is the relationships between the parents and children, but the number of nodes in each level remains the same. We can show the simulation modeling effort is the same for all three trees and conclude that only the number of nodes in each level impacts the simulation modeling effort.

Next, we consider moving nodes up and down levels. In Figure 1d we have the original tree with nodes 1 and 2 labeled. In Figure 1e, we moved node 2 up one level and in Figure 1f we moved node 1 down one level from its original tree in Figure 1d. Notice that each time we moved a single node by one level the simulation modeling effort changed by exactly one unit. We conclude that moving a node up by one level drops the modeling effort by one unit and moving a node down by one level increases the modeling effort by one unit. The reason for this has to do with the number of times the logic for a controller appears in the simulation model.

We conclude that the problem of finding the simulation modeling effort for a tree is only dependent on the number of controllers in each row and not the relationship they have with their parents or children. Therefore, the problem of finding all the possible shapes a tree can have has now been reduced to finding all the possible combinations of the number of nodes in the different levels. The rate of change of the modeling effort changes linearly with the rate of change of the number of the nodes in the rows of the tree. To find the average modeling effort over all possible combinations, we can take advantage of this linearity to simply compute the shape with the maximum and minimum modeling effort and average only those two points.

We start by showing the constraint that exists in filling the rows within the tree. Given the number of nodes, N, and the tree height, L, we need to have at least one node per row to satisfy the tree height. Therefore, we only have the freedom to place N–L nodes in the rows. The tree configuration that produces the smallest modeling effort is where all the nodes are as high as possible in the tree. Figure 2a shows a tree where all the nodes are as high as possible and Figure 2b shows the same tree with all the nodes as low as possible. To the right of each tree is the simulation modeling effort that belongs to the corresponding row. Recall that the total simulation modeling effort is the sum of the modeling effort for each row.

The modeling effort for the tree in Figure 2a is

$${\mathrm{S}}_{\mathrm{m}\mathrm{i}\mathrm{n}}=1+2+3+\cdots +(\mathrm{L}-2)+\mathrm{N}+(\mathrm{N}-1)=\sum _{\mathrm{i}=1}^{\mathrm{L}-2}\mathrm{i}+\mathrm{N}+(\mathrm{N}-1)={\displaystyle \frac{1}{2}}{\mathrm{L}}^2-{\displaystyle \frac{3}{2}}\mathrm{L}+2\mathrm{N}$$

(3)

The modeling effort for the tree in Figure 2b is

$${\mathrm{S}}_{\mathrm{m}\mathrm{a}\mathrm{x}}=\mathrm{N}+\left(\mathrm{N}-1\right)+\cdots +\left(\mathrm{N}-\left(\mathrm{L}-2\right)\right)+\left(\mathrm{N}-\left(\mathrm{L}-1\right)\right)=\sum _{\mathrm{i}=1}^{\mathrm{L}-1}\left(\mathrm{N}-\mathrm{i}\right)=-{\displaystyle \frac{{\mathrm{L}}^2}{2}}+{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}\mathrm{L}$$

(4)

The next step is to take the average of the minimum and the maximum terms for the simulation modeling effort.

$$\bar{\mathrm{S}}={\displaystyle \frac{1}{2}}\left[\left({\displaystyle \frac{1}{2}}{\mathrm{L}}^2-{\displaystyle \frac{3}{2}}\mathrm{L}+2\mathrm{N}\right)+\left(-{\displaystyle \frac{{\mathrm{L}}^2}{2}}+{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}\mathrm{L}\right)\right]={\displaystyle \frac{\mathrm{N}\mathrm{L}}{2}}-{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}$$

(5)

Putting the average simulation modeling effort and the control modeling effort into Equation (1), yields the following:

$$\bar{\mathrm{P}}={\displaystyle \frac{\bar{\mathrm{S}}}{\mathrm{C}}}={\displaystyle \frac{1}{\mathrm{N}}}\left({\displaystyle \frac{\mathrm{N}\mathrm{L}}{2}}-{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}\right)={\displaystyle \frac{\mathrm{L}}{2}}-{\displaystyle \frac{\mathrm{L}}{2\mathrm{N}}}+1$$

(6)

$${\mathrm{P}}_{\mathrm{m}\mathrm{i}\mathrm{n}}={\displaystyle \frac{{\mathrm{S}}_{\mathrm{m}\mathrm{i}\mathrm{n}}}{\mathrm{C}}}={\displaystyle \frac{{\mathrm{S}}_{\mathrm{m}\mathrm{i}\mathrm{n}}}{\mathrm{N}}}={\displaystyle \frac{1}{\mathrm{N}}}\left({\displaystyle \frac{1}{2}}{\mathrm{L}}^2-{\displaystyle \frac{3}{2}}\mathrm{L}+2\mathrm{N}\right)={\displaystyle \frac{{\mathrm{L}}^2}{2\mathrm{N}}}-{\displaystyle \frac{3\mathrm{L}}{2\mathrm{N}}}+2$$

and

$${\mathrm{P}}_{\mathrm{m}\mathrm{a}\mathrm{x}}={\displaystyle \frac{{\mathrm{S}}_{\mathrm{m}\mathrm{a}\mathrm{x}}}{\mathrm{C}}}={\displaystyle \frac{{\mathrm{S}}_{\mathrm{m}\mathrm{a}\mathrm{x}}}{\mathrm{N}}}={\displaystyle \frac{1}{\mathrm{N}}}\left(-{\displaystyle \frac{{\mathrm{L}}^2}{2}}+{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}\mathrm{L}\right)=-{\displaystyle \frac{{\mathrm{L}}^2}{2\mathrm{N}}}+{\displaystyle \frac{\mathrm{L}}{2\mathrm{N}}}+\mathrm{L}.$$

3.3. Full Tree

We have shown formulas to compute the minimum, maximum, and average modeling efforts for all possible tree shapes, given a fixed tree size and height. One may argue that many of the tree shapes considered are unlikely to be found in a real hierarchical control architecture, especially those where the concentration of nodes is towards either the top or bottom of the tree. Therefore, we will compute formulas for modeling efforts assuming a tree with a node distribution that tends to increase gradually as the level goes down the tree; that is, we will use a full tree with fixed fan-out. This is the most perfectly shaped tree. We are not assuming a real control hierarchy will have such a shape, but rather that this provides an additional point that may result in a better estimate of modeling effort for control hierarchies that tend to have a more balanced tree shape.

For this study, we will again fix the tree height, L. However, instead of fixing the number of nodes in the tree, N, now we will fix the fan-out, f, and only consider full trees. Consider the tree shown in Figure 1b above. This tree has a fan-out of three and three levels. Therefore $\mathrm{f}=3$ and $\mathrm{L}=3$.

Each row has ${\mathrm{f}}^{\mathrm{i}}$ nodes where $\mathrm{i}$ is the row number starting with 0 at the root. Recall the rows are numbered from 0 at the root to $\mathrm{L}-1$ at the leaves. Since we are not specifying the number of nodes, N, we will need to compute it from L and f. The control modeling effort, ${\mathrm{C}}_{\mathrm{L}}$, is derived below, using the identity for the sum of a geometric progression. Note that ${\mathrm{C}}_{\mathrm{L}}$ is simply the number of nodes in the full tree with a height of $\mathrm{L}$.

$${\mathrm{C}}_{\mathrm{L}}=\sum _{\mathrm{i}=0}^{\mathrm{L}-1}{\mathrm{f}}^{\mathrm{i}}={\mathrm{f}}^0+{\mathrm{f}}^1+\cdots +{\mathrm{f}}^{\mathrm{L}-1}={\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}$$

(7)

To verify, we compute ${\mathrm{C}}_{\mathrm{L}}={\mathrm{C}}_3={\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}=13$, which coincides with the number of nodes in the sample tree above.

A tree is a recursive structure where each node is also a subtree. We compute ${\mathrm{S}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ as the product of the number of subtrees in the tree by the number of nodes in each subtree. Let $\mathrm{S}{\mathrm{U}}_{\mathrm{i}}$ be the total number of nodes in all the subtrees on row $\mathrm{i}$. Then, we have the following:

$$\mathrm{S}{\mathrm{U}}_{\mathrm{i}}={\mathrm{C}}_{\mathrm{L}-\mathrm{i}}{\mathrm{f}}^{\mathrm{i}}={\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}-\mathrm{i}}}{1-\mathrm{f}}}{\mathrm{f}}^{\mathrm{i}}={\displaystyle \frac{{\mathrm{f}}^{\mathrm{i}}-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}$$

(8)

where ${\mathrm{C}}_{\mathrm{L}-\mathrm{i}}$ is the number of nodes in each subtree whose root is on row $\mathrm{i}$, and ${\mathrm{f}}^{\mathrm{i}}$ is the number of subtree roots on row i. Note that the height of a tree whose root is on row $\mathrm{i}$ is $\mathrm{L}-\mathrm{i}$. Figure 3 shows the $\mathrm{S}{\mathrm{U}}_{\mathrm{i}}$ terms for the sample tree and shows how the sum is the simulation modeling effort ${\mathrm{S}}_{\mathrm{L}}$.

Using Equations (4) and (8), the sum of a geometric progression identity and the sum of a constant identity, we have

$${\mathrm{S}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}=\sum _{\mathrm{i}=0}^{\mathrm{L}-1}\mathrm{S}{\mathrm{U}}_{\mathrm{i}}=\sum _{\mathrm{i}=0}^{\mathrm{L}-1}{\displaystyle \frac{{\mathrm{f}}^{\mathrm{i}}-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}={\displaystyle \frac{1}{1-\mathrm{f}}}\left({\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}-\mathrm{L}{\mathrm{f}}^{\mathrm{L}}\right)$$

(9)

To verify, we compute ${\mathrm{S}}_{\mathrm{L}}$ with $\mathrm{f}=3$ and $\mathrm{L}=3$, and obtain ${\mathrm{S}}_{\mathrm{L}}=34,$ which coincides with the total number of nodes in all 13 subtrees of the sample tree above. We then compute

$${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}={\displaystyle \frac{\mathrm{L}{\mathrm{f}}^{\mathrm{L}}}{{\mathrm{f}}^{\mathrm{L}}-1}}-{\displaystyle \frac{1}{\mathrm{f}-1}}$$

(10)

To verify, we compute ${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ with $\mathrm{f}=3$ and $\mathrm{L}=3$, to obtain ${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}=2.6,$ which is what we showed for our sample full tree above, in Figure 1b.

3.4. Analysis

We show the following formulas:

S	P
${\mathrm{S}}_{\mathrm{m}\mathrm{i}\mathrm{n}}={\displaystyle \frac{1}{2}}{\mathrm{L}}^2-{\displaystyle \frac{3}{2}}\mathrm{L}+2\mathrm{N}$	${\mathrm{P}}_{\mathrm{m}\mathrm{i}\mathrm{n}}={\displaystyle \frac{{\mathrm{L}}^2}{2\mathrm{N}}}-{\displaystyle \frac{3\mathrm{L}}{2\mathrm{N}}}+2$
${\mathrm{S}}_{\mathrm{m}\mathrm{a}\mathrm{x}}=-{\displaystyle \frac{{\mathrm{L}}^2}{2}}+{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}\mathrm{L}$	${\mathrm{P}}_{\mathrm{m}\mathrm{a}\mathrm{x}}=-{\displaystyle \frac{{\mathrm{L}}^2}{2\mathrm{N}}}+{\displaystyle \frac{\mathrm{L}}{2\mathrm{N}}}+\mathrm{L}$
$\bar{\mathrm{S}}={\displaystyle \frac{\mathrm{N}\mathrm{L}}{2}}-{\displaystyle \frac{\mathrm{L}}{2}}+\mathrm{N}$	$\bar{\mathrm{P}}={\displaystyle \frac{\mathrm{L}}{2}}-{\displaystyle \frac{\mathrm{L}}{2\mathrm{N}}}+1$
${\mathrm{S}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}={\displaystyle \frac{1}{1-\mathrm{f}}}\left({\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}-\mathrm{L}{\mathrm{f}}^{\mathrm{L}}\right)$	${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}={\displaystyle \frac{{\mathrm{S}}_{\mathrm{L}}}{{\mathrm{C}}_{\mathrm{L}}}}={\displaystyle \frac{\mathrm{L}{\mathrm{f}}^{\mathrm{L}}}{{\mathrm{f}}^{\mathrm{L}}-1}}-{\displaystyle \frac{1}{\mathrm{f}-1}}$

These formulas show the simulation modeling effort, the modeling effort that is needed to incorporate intelligence beyond what is needed to simply control the system with a non-optimizing controller. These formulas provide the simulation modeling effort, S, and the ratio of the simulation modeling effort over the control modeling effort, P. They have as input L, the number of levels in the control hierarchy tree or the height of the tree and N, the number of individual controllers in the control hierarchy. Also, note there are two separate analyses: one where the control hierarchy has an arbitrary tree shape where we computed the minimum, maximum, and average, and the second where we assume the control hierarchy has a full tree structure. We can observe the following.

3.5. Observation 1

Between the two estimates for the simulation modeling effort, ${\mathrm{S}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ is perhaps the better estimate. Since $\bar{\mathrm{S}}$ changes linearly as the nodes move vertically, the average between the minimum and the maximum assumes that the number of nodes are uniformly distributed among all rows leading to a square-shaped tree. This square tree will tend to have an average fan-out of one below the root. The full tree has a triangular shape with the bottom having more nodes than the top, which we assume is more characteristic of an actual control hierarchy. Note, ${\mathrm{S}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ tends to be larger than $\overline{\mathrm{S},}$ since it has more nodes towards the bottom, where they are included in more models, leading to a larger value.

3.6. Observation 2

The model explosion problem becomes worse with the increase in controller size. Both $\bar{\mathrm{P}}$ and ${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ are approximately proportional to $\mathrm{L},$ which increases as the number of controllers in the control hierarchy increases. From (7) we showed that the number of nodes in a full tree with fixed fan-out $\mathrm{f}$ and height $\mathrm{N}$ is computed by the equation below.

$$\mathrm{N}={\displaystyle \frac{1-{\mathrm{f}}^{\mathrm{L}}}{1-\mathrm{f}}}$$

(11)

And we can derive this to obtain

$${\log }_{\mathrm{f}}\left(1+\mathrm{N}(\mathrm{f}-1)\right)=\mathrm{L}$$

If we do not assume the fan-out is fixed, but rather bounded by a maximum fan-out, ${\mathrm{f}}_{\mathrm{m}}$, then, from (11) we have the following relation.

$$\mathrm{N}\le {\displaystyle \frac{1-{\mathrm{f}}_{\mathrm{m}}^{\mathrm{L}}}{1-{\mathrm{f}}_{\mathrm{m}}}}$$

And we can derive this to obtain

$${\log }_{\mathrm{f}}\left(1+\mathrm{N}({\mathrm{f}}_{\mathrm{m}}-1)\right)\le \mathrm{L}$$

In both cases, we can see that $\mathrm{L}$ grows logarithmically with the number of controllers $\mathrm{N}$. While this growth is not large, the fact that there is growth at all means the problem worsens as the number of controllers increases.

Consider the simple hierarchy with three levels and a fan-out of three, as in Figure 1b. We showed that the value of P was 2.62. That means if we were to add optimization capabilities to all controllers the simulation modeling effort will be 2.62 times or 262% the effort spent on creating the basic non-optimizing controller models. This controller has 13 basic control models. However, if instead our controller has eight levels and a fan-out of seven, then this system will have just under 1 million controllers and a value of P of 7.83. The modeling effort to create all the simulation models is almost an order of magnitude higher than that of building the basic non-optimizing controller models. One million controllers are not unrealistic in future systems such as the Smart Grid we envision.

It is estimated that to avoid this unrealistic modeling effort explosion using current technology, the controller at the bottom of the hierarchy, requiring the smallest number of simulation models, will be the only one implemented. One will only be able to implement local or regional intelligence, with no system-wide intelligence capabilities. It was shown that the catastrophic power outages we had in 2003 could have been avoided if the different power companies involved were coordinated. In other words, system-wide intelligence could have prevented that outage. Of course, one could argue that a realistic system-wide simulation used for decision making at the topmost level will not include all the logic details of the complete system. While this will make the actual simulation modeling effort, $\mathrm{S}$, smaller, it is still a significant modeling effort that must be avoided to justify the investment in higher-level intelligence.

4. Our Solution

Fortunately, there are solutions to this modeling problem. One may desire that we have a modeling paradigm where $\mathrm{P}=1$ for all controller shape and sizes. The modeling effort for simulation will be the same as for creating the basic set of non-optimizing controllers. However, we present a solution, or a modeling paradigm, that results in $\mathrm{P}=0,$ since $\mathrm{S}=0$ for all controller shape and sizes. We achieve this by recycling the controller models and using them for simulation. We create each simulation model by including the controller models for all the controllers in their control domain with no or minimal modification to the existing models. We created a simulation tool that models the communication network that ties together all the individual models. This method allows the set of individual models to function as though it were a single model.

While in theory there is no modeling effort needed to create the complete set of simulation models for all the controllers, in practice there may be some modeling effort associated with modeling the physical machines or the control software that is provided by the manufacturers of the machines. However, these models are needed, regardless of the modeling paradigm used, and the modeling effort is proportional to the number and complexity of the hardware comprising the system being controlled. This effort is not impacted by the model explosion problem presented, as the number of machines being controlled does not grow exponentially with the growth of the number of controllers in the control hierarchy.

While the controller is distributed among many computers, the simulation must be run on a single machine to avoid internet communication delays. The challenge is to create a single model from a collection of models, with no modification. Since the only thing that ties together the collection of control models is the communications among them, our solution for tying these models together is to model the communication network. So, our solution is to include all the individual control models, along with a model of the communication system into a new single model that can then be used in a simulation following well-known algorithms for a discrete-event simulation. This is carried out without the need to modify any of the individual control models.

This has many other advantages. For example, as a byproduct, the communications among the controllers are also modeled. This is not necessarily the case using a traditional approach unless it is specifically included in the simulation model. Another advantage is the increased fidelity. Since we are using the same model source code used for the control, all its logic, including any errors, will appear in the simulated model. One of the challenges of initializing a simulation model from a system’s current state is translating the system-state information from the controller to the simulation model. Since we use the same source code, it is a simple matter of copying all the data in its variables from the copy used for the control to the copy used for simulation. Finally, since the simulation model is created by simply including existing control models, we can vary the resolution of the composite simulation model by simply deciding what models to include. That is, we can decide how far down the control hierarchy tree to model our simulations, thus varying the resolution or amount of detail in the simulation.

To better explain our approach, we present how traditional simulation works so that we can contrast that to how a controller works and finally to how our simulation using a composite model works.

4.1. Traditional Discrete-Event Simulation

Discrete-event simulation works by moving the system clock in discrete time increments between events. When modeling an external entity that does not exist in the simulation such as a physical machine, the completion time is taken from a random variable distribution and used to schedule a completion time event onto a scheduled event list. This communication basically becomes a delay event. The scheduled event list has the next event that will occur. Events are forwarded to the simulation model for processing. Executing events may induce other events to occur when resources are released. Once nothing more will happen until the next scheduled event occurs, the clock time is incremented to the time of the next event instantly, and that event is pulled of the scheduled event list and executed. This occurs in a loop until some terminating condition stops the simulation.

4.2. Control Using Discrete-Event Simulation-Type Logic

To control a physical system, a similar algorithm is used. The main difference is that the time is not incremented in discrete time increments but rather increments continuously in real time, like a clock on a wall. Since external entities exist, when a task is given to an external entity the algorithm must not schedule its termination event but rather store the event in a pending-event list. This list has events that are waiting for an external event to occur before executing, such as a message from a machine indicating it completed a task. A scheduled-event list may still be used as some processes complete after a predetermined amount of time, such as an oven baking a part. So, when used for control, both the pending- and the scheduled-event lists are used. The actual models are very similar, if not identical. If the models are written for control applications, then when used for simulation, the events in the pending-events list are instead inserted into the scheduled-event list with an event execution time computed by a random-number generator. Communications with the external entities do not occur. Communication functions must also be added to the controller to handle physical communication with the external entities.

4.3. Discrete-Event Simulation Using a Composit Model

When the simulation model consists of a collection of independent control models forming a composite simulation model, which is the case when using our presented model-sharing paradigm, the simulation is effectively the same as when it is used for control. In traditional simulation, since external entities do not exist, they are modeled with delay events and the use of the scheduled-event list. However, when the model consists of a collection of models, when looking from the point of view of one of the individual models, external entities do exist; these are the other models in the composite model. Therefore, the pending-event list is still used as if it were actively controlling in real time. In fact, the models are executed exactly as they are when controlling, except that the time increases in discrete time increments as opposed to real time. Of course, the models that have direct communications with the hardware need to consider that the hardware does not exist and to model its communication with delay events. In addition, the simulation tool needs to include a model of the communication network to synchronize all the individual models. And finally, the simulation tool needs to coordinate all the individual scheduled-event lists into a global scheduled-event list. This global scheduled-event list has the order of all the events from all the models. It determines which module will be executed next.

For the way the composite simulation model is created is by encapsulating each individual model into a software object, along with its scheduled- and pending-event lists, see Figure 4a. Then, all the simulation objects are included into the complete simulation software object, as in Figure 4b.

The communication network is implemented as a queue that saves incoming messages in the order they arrive and delivers them to the proper simulation object. To coordinate all the individual events in all the simulation objects, a global scheduled-event list is added to the simulation, which stores a copy of every event in every controller object’s scheduled-event list, see Figure 4b. In the simulation, the scheduled-event list has the next event to execute. However, in a simulation using a composite model, each simulation object has its own scheduled-event list. Therefore, the global scheduled-event list has a copy of every event in every scheduled-event list from every object. It has all the events sorted by time. So, every event in the global schedule-event list must indicate the simulation object that houses that event. To execute the next event, the simulation engine grabs the next event from the global scheduled-event list and forwards it to the proper simulation object that contains that event. Then the simulation engine that corresponds to that simulation object grabs the next event from its own scheduled-event list and executes it. The global scheduled-event list serves to coordinate the collection of simulation objects by managing the execution of all events in chronological order.

When simulating using a composite model, the simulation objects run as though they are in control mode, in that they send messages to other controllers and store the event in the pending event list while it waits for a reply. Note that while a controller using a single model does not use the pending-event list, a controller using a composite model still needs the use of a pending-event list. The simulation engine uses its model of the communication system to capture these messages and route them to the appropriate simulation object. A byproduct of this method is that the communication among the different controllers is captured in the simulation automatically, with no further modeling effort necessary.

4.4. The Algorithms

The simulation using a composite model runs in a loop. It first pulls the next event from the global scheduled-event list and calls the corresponding object to tell it to run its next event. When this is complete, it then checks the message queue and delivers the next message to the destination simulation object and tells it to process that message. This is repeated until the message queue is empty, see Algorithm 1.

In addition to events occurring at scheduled times or resulting from an input message, there is a third way that an event can occur. When executing any event, that event may release resources that some other event is waiting for in order to execute. Therefore, every time any event is finished executing, the model must check to see if any event that is waiting for resources can execute. There is a modeling element called “QueueSeize”, which is used to stop an event from executing further until its needed resources are available. When the resources are available, it seizes the resources and executes. It must release all its resources once it no longer needs them. When an event is given to a simulation object to execute, it follows the Algorithm 2. When a message arrives, it is given to the appropriate simulation object for processing, following the Algorithm 3. Note, a key is used to match the message to the corresponding event in the pending-event list. However, if an unexpected message arrives, then an input event must occur. This event handles unexpected messages such as a new job arrival or when a machine needs to be serviced. When a simulation object is called to either process an incoming message or execute its next event, the object called then assumes control and returns control once that task is complete.

Algorithm 1: Distributed Simulation Main Loop

1: while the global scheduled-event list or the message queue are not empty do 2:  Get the next event from the global-scheduled event list. 3:  Update the system clock with the event’s time. 4:  Give the event to the proper simulation object to execute. 5:  while the message queue is not empty do 6:   Remove the next message from the message queue. 7:    Give the message to the proper simulation object to execute. 8:  end while 9: end while

Algorithm 2: Execute an Event by a Simulation Object (6)

1: Execute the event by calling the model and passing it the event number. 2: repeat 3:  for each QUESEIZE element that has at least one entity in it do 4:   if this element can allocate the resources requested then 5:    Execute the corresponding QUESEIZE event. 6:   end if 7:  end for 8: until every QUESEIZE element is checked without causing an event to execute.

Algorithm 3: Processing a Message in a Simulation Object (7)

1: Search the pending-event list for a key match. 2: if a match is found then 3:  Execute the PENDING event. 4: else 5:  Execute the INPUT event. 6: end if 7: repeat 8:  for each QUESEIZE element that has at least one entity in it do 9:   if this element can allocate the resources requested then 10:    Execute the corresponding QUESEIZE event. 11:   end if 12:  end for 13: until every QUESEIZE element is checked without causing an event to execute.

For example, consider a system consisting of some hardware and three controllers in its hierarchy. To keep things simple, we will assume only the topmost controller, controller S3, has intelligence, see Figure 5.

In this hierarchy shown in Figure 5, controllers L5 and L6 have direct communication with the hardware and controller S3 manages the two lower controllers and has intelligence capabilities. Each of the three controllers is implemented as a simulation object running in control mode, shown in Figure 4a. The composite simulation model is created by simply including all three objects, S3, L5, and L6, into a single program, along with the message queue, global scheduled-event list, and its simulation engine, see Figure 4b.

In this example, the cycle starts by removing the next event from the global scheduled-event list, which corresponds to object L6, and asking object L6 to execute it. While object L6 processes this event, it sends a message to object L5, which is simply added to the message queue. Once object L6 is completed, the simulation removes the message from the message queue and delivers it to object L5. Object L5 then processes this message. While processing it, it generates a new event and adds it to the global scheduled-event list. The cycle then repeats by removing the next message from the global scheduled-event list and sending it to its object for processing.

The complete intelligent controller is achieved by having the controllers manage the operation of the system while simultaneously having these controllers run simulations of the system to support making intelligent decisions. Figure 6 shows the complete intelligent system for our three-model example.

When the system is using its models for physical control, the simulation engine in the simulation objects runs in control mode and follows Algorithm 4. Note, while we refer to it r as a simulation object, the engine is operating in control mode. In this mode, messages are real and flow through a physical network, and the clock runs in real time.

Algorithm 4: Control Mode Main Loop (10)

1: while the scheduled-event list and the pending-event list are not empty do 2:  Get the next event’s time from the scheduled event list. 3:  if the event’s time is equal to the current time then 4:   Execute the event. 5:  end if 6:  Execute the communication function. 7:  if a key is returned then 8:   Process the message. 9:  end if 10: end while

5. Results

The validity of our concepts is demonstrated as an example. The example shows that we can create a simulation model of the complete distributed system by simply including models from the collection of existing models used for control. It is shown that the tool can use this collection of control models without modification to simulate the complete distributed system and use the results to make intelligent decisions in real time. The examples validate the feasibility of our concepts. The arguments on scalability made earlier should show how this translates to a scalable intelligent controller, at least in terms of a necessary condition.

6. Example

This example is described in [2]. Because testing this methodology on a real functioning manufacturing plant or other large-scale system is unreasonably expensive, we built an intelligent controller for a small-scale model flexible-manufacturing system (FMS), shown in Figure 7. In Figure 8, a photograph of one of the machines is shown. While the model is small and simple, it is not a computer simulation but rather a physical model implemented using purchased and custom-made hardware. The design of the system was selected to have modular components that allow for the decomposition of the controller into a distributed controller while remaining physically small to fit into our lab space, as well as economical to fit within our budget. It has four stations, each with its own conveyer disk system to move parts from the main automated guided vehicle (AGV) to its processor. The parts were implemented using steel washers about one inch in diameter. The AGV was implemented using an HO-scale electric train. The train carries the washers on top of its body, and it loads and unloads the washer using an electromagnet that lifts the washer when powered, swings it to the other side of the port and drops the disk by cutting power to the magnet. The processor itself is modeled using a simple LED that indicates the part which is being worked on. The complete system has four general-purpose stations, each with one processor, and a port that moves the disk between the AGV and its processor. There is also a fixturing station that has two processors and two ports. The electric train tracks reach all six ports. In this layout, there are over forty track segments that can be individually powered. Sensory switches are provided on each track segment to detect the presence of an AGV. To demonstrate our approach, five laptops and a desktop computer were employed to provide the distributed control. Each station, plus the fixturing station, has its own laptop, and the AGV shared the desktop computer with the supervisory cell controller. Microcontrollers are used to provide low-level direct control to the hardware devices such as the various electric motors, power electromagnets, track segments, and all sensors.

The complete intelligent controller consists of 12 low-level controllers named L1 through L12, which have direct communication with the hardware microcontroller circuit boards that run the hardware. The six mid-level controllers named S1 through S4, F, and A, manage the lower-level controllers. For example, controller L1 manages the processor of the machine, while L2 manages the material handling disk with the electromagnetic devises. Note that controller F has two ports, each with its own controller L9 and L10, and two processors managed by L11. The AGV train tracks are managed by L12. The supervisory controller named SUP manages the entire manufacturing cell and makes high-level- type decisions, see Figure 9. The low-level L-series controllers have direct interaction with the hardware. The microcontrollers that run the hardware are considered part of the hardware, and are shown in the square boxes in Figure 9. The 19 controllers that make up the complete intelligent controller run concurrently on six different computers, connected using a local area network (LAN). The locations of the controllers within the six computers are shown in Figure 7.

For simulation, all models excluding the low-level L-series, L1 through L12, were given intelligent decision-making capabilities and therefore a simulation model encompassing all the logic in all the controllers in its control domain. The low-level controllers were not given decision-making capabilities, since the machines in this physical system are not complex enough to benefit from optimization. In a real FMS, the low-level controllers will make decisions pertaining to the operation of the machine in its control domain. This may include operating parameters. Therefore, we need to add intelligence to the topmost seven controllers, SUP, S1 through S4, F, and A, by giving each a simulation model encompassing its unique control domain. The simulation models are shown in Figure 10 and are given the names Sim 1 for controller SUP, Sim 2 through Sim 5 for controllers S1 through S4, Sim 6 for controller F, and Sim 7 for controller A.

In the setup for this experiment, the controller was given a total of three jobs, each with two processing steps. Each processing step required the part to be moved to a different machine. In addition to the task of processing the part, before and after each processing step the part had to be moved to the fixturing center for fixturing. To verify the correctness of the simulation model that was produced with no additional modeling effort using our methodology, the optimizer unit of the distributed controller requested each controller, along with the communication system, to capture and return its current state while actively controlling the physical system. It then compiled a system state and used it to initialize the simulation models. After executing the simulation, the transcript of both the real-time controller and the corresponding simulation were observed to be almost identical, with the only difference attributed to the simulation using estimated task-duration times, while the hardware used actual duration times.

Next, the complete optimizing controller was tested. The two most common types of cases were tested, a new job arrival and a component failure. First, a new job was given to the controller that had a short due date and a high penalty for being completed late. The system was observed to perform many simulations runs and then reorder the jobs in several queues to expedite this new job and reduce the overall penalty among all jobs. Next, a disturbance situation was induced, when one of the machines was deliberately taken offline. The system was again observed to execute many simulation runs then reschedule the jobs on another machine that had the same capabilities in order to avoid the downed machine. The optimizer continuously gathers the system state, initializes the simulation models with the current system state and performs its optimization. Once complete, it cycles and starts the process again, assuring that any opportunity to optimize is taken.

Next, we calculate the modeling effort that would have been required if our presented methodology had not been used and compare that to the modeling effort required using our paradigm. First, we demonstrate the modeling effort needed without considering the presented modeling paradigm; we will compute S, C, and P. Consider, as an example, that Sim 4 needed to give controller S3 intelligent decision-making capabilities. It has in its control domain L5 and L6, so the simulation model will need to include the logic in itself, S3, plus the logic in L5 and L6. We compute S = 3 in this case, since the simulation model includes the logic of three control models, S3, L5, and L6. Following similar calculations, we can compute the total modeling effort needed to create all seven simulation models as $\mathrm{S}=\left[1+\left(4\ast 3\right)+4+2\right]+\left[\left(4\ast 3\right)+4+2\right]=37$. To compare this to the modeling effort that was needed to create the non-optimizing controllers, we compute $\mathrm{C}=1+(4\ast 3)+4+2=19$ and then $\mathrm{P}={\displaystyle \frac{\mathrm{S}}{\mathrm{C}}}={\displaystyle \frac{37}{19}}=1.95$. This means that to give intelligent decision-making capabilities to the top seven controllers, we will need to invest in an effort that is almost twice the effort we originally invested in when producing the set of non-optimizing controllers. Now, to consider this modeling effort using our presented model-sharing modeling paradigm, we will not need to create any models, as all of them can be created automatically by recycled existing control models with no or insignificant effort, providing $\mathrm{P}=0$. The only effort in creating the models is in needing to instantiate seven new simulation engine objects, and for each, including the appropriate control model objects as its data elements. Figure 11a shows a diagram of the simulation using the traditional single-model paradigm, while Figure 11b shows the same simulation using the presented model-sharing paradigm. Note, the physical machine operations are trivial and the simulation modeling tool we created allows one to simply replace a physical machine with a delay-modeling element which models a machine as a delay and, therefore, no new models need to be created to model the operation of the machines. Had the machine been complex, then models would have needed to be created to model their operations and P would be greater than 0 but still very small.

7. Discussion

One of the two goals of this work is to bring awareness of the need to use a new modeling paradigm for creating intelligent controllers, which allows model sharing between control and simulation. We show how the modeling effort to manually create all the necessary simulation models needed for full intelligent control grows exponentially with the size of the system being controlled. We showed that this modeling effort is proportional to L times the control modeling effort, where L is the number of levels in the control hierarchy. As the modeling effort grows, the cost of adding intelligent decision-making capabilities to the distributed controller grows. Therefore, using the current modeling technology that requires the simulation models to be manually created is not scalable to implementing intelligent distributed control for large systems. Examples of these large systems include the Smart grid, which is designed to encompass the whole U.S. power system [16], intelligent traffic management systems that optimize the flow of vehicular traffic, and flexible manufacturing systems that are fully automated and make many different parts in small batches at one time [3]. These large-scale distributed systems rely on intelligent control to realize their full potential benefit.

The second goal is to suggest one solution where the simulation models are created automatically by reusing the control models. In the presented modeling paradigm, the control models are used without any significant modification for simulation, removing the need to manually create the simulation models. In addition to not having to create any new simulation modeling code, the interactions between the controllers are also modeled automatically, since the model-sharing paradigm works by modeling the interactions between the individual models, interactions that need to be included in any accurate simulation model.

A model used in real-time control must be initialized to the current state of the physical system before starting its simulation. By recycling the original control models, the data in all its data structures can be copied directly and used to initialize the simulation models, with no need to interpret their meaning. The state of the hardware was used to initialize the state of the simulation models. No changes had to be made to any of the models to switch from using them for control or simulation. In Gonzalez and Davis (1998) [17], the physical system is discussed in greater detail, while in Gonzalez and Davis (1997) [3] the employed simulation model is discussed.

The presented methods are scalable to arbitrarily large systems. Scalability is the motivation for our paradigm. Recall that in Observation 2 the model explosion problem worsens with the increase in controller size, which increases as the number of controllers in the control hierarchy increases. We showed that both $\bar{\mathrm{P}}$ and ${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ increase with an increase in the number of controllers in the control hierarchy. Our presented modeling paradigm results in $\mathrm{P}=0$ for all controller sizes. There is nothing in the methodology that is dependent on the size of the system other than the number of models to include in a composite simulation model.

When a system is said to be scalable to arbitrarily large systems, this does not mean that no effort is needed to implement a controller for a large system. The simulation modeling effort increases as the systems to control increase in size. What is meant by scalable is that the effort needed to implement all the simulation model needed to add intelligence to a none-optimizing controller grows as the system to be control grows, but at a growth rate that is small enough that it remains feasible to implement in a realistic setting. In contrast, using the current modeling methodology will result in an exponential growth rate and, eventually, as the system to be controlled grows, the modeling effort to add intelligence will become unreasonable and no longer considered feasible. In theory, our approach does not require any additional modeling effort beyond what is needed to implement a non-optimizing controller. However, in practice, there is always some modeling effort needed to model dynamics that are not included in the set of control models. Such may include modeling the hardware like the physical equipment and machines. What our approach provides with no additional modeling effort is the set of simulation models that model the logic in each controller plus the model of the communications among all the controllers, including the communication network. Discrete-event simulation used in real-time decision-making applications must run on a single computer to be executed as fast as possible. If a particular controller is high in the control hierarchy, resulting in it having a large control domain and therefore a large simulation model, then to reduce the execution time, it is common to reduce the resolution of its simulation model, see [9]. This is necessary regardless of the modeling methodology used. This can be accomplished by removing the details of the models that are lower in its control hierarchy and only focusing on the dynamics included in the control model just below itself. Using our methodology, it is easy to adjust a simulation model’s resolution. Simply include only the models that are necessary and omit those that are not, such as those lower in its control hierarchy.

8. Conclusions

In this paper we present a modeling paradigm that can be used to add real-time simulation models used for decision making without needing any significant additional modeling effort, making our approach scalable to arbitrarily large systems. This paradigm is based on a novel theory where the models used for control are shared and used for simulation as well. Furthermore, we showed that since these shared models are actual copies of the control models, they model the exact behavior of the controllers, including any error they may have. This is an improvement over the current research on automatically creating new simulation models by estimating the behavior of the controller via its data logs. Lastly, since the simulation models are actual copies of the control models, our novel approach trivializes the very difficult problem of needing to interpret the system state of the controller to initialize the simulation models. The transfer of the system state can be performed in real time by simply copying all the data from the copy used for control to the copy used for simulation, with no need for interpretation of their meaning. However, using our approach does require that the control models be created using the presented paradigm for facility sharing.

In this paper, we showed that when manually creating all the simulation models, needed using the traditional modeling methodology, the additional modeling effort that is needed to implement intelligence at all levels of a control hierarchy is proportional to the number of levels in the control hierarchy times the modeling effort needed to build the controllers with no intelligence. Furthermore, we showed that this problem worsens as the number of controllers in the control hierarchy increases. In our analysis, we derived two equations for $\mathrm{P},$ the ratio of the modeling effort to create the simulation models over the modeling effort to create the control models. For $\bar{\mathrm{P}}$ we made no assumptions on the shape of the hierarchy tree and computed $\bar{\mathrm{P}}$ for the average tree shape. For ${\mathrm{P}}_{\mathrm{f}\mathrm{u}\mathrm{l}\mathrm{l}}$ we assumed a perfect triangular tree shape. Both gave similar results, in that $\mathrm{P}$ is proportional to $\mathrm{L}$, the number of levels in the control hierarchy, and $\mathrm{L}$ grows as the number of controllers in the control hierarchy grows, worsening the problem.

We then presented a solution, a new modeling paradigm, which involves recycling the control models as opposed to creating new models for its simulation, effectively making $\mathrm{P}=0$. With our solution, no additional modeling effort is needed to add intelligence at all levels of a control hierarchy. This was implemented by modeling the communication network and including a global scheduled-event list, both used to synchronize the execution of the collection of independent models. We also showed that, as a byproduct, our solution also provides simulation models with maximum fidelity, the communication among the controllers is automatically modeled, the resolution of the models can be adjusted dynamically, and the state of the system can be directly transferred to the simulation models without interpretation.

Finally, as a proof of concept, an example was presented. In this example, we showed that we were able to create a simulation model that represents the complete distributed system by reusing the individual- and independent-control models with no additional modeling effort, and that this “free” model was successfully used in making intelligent decisions in real time.

In future research, the aim will be to add algorithms that will perform the optimization using the composite models. Genetic algorithms may be used to search the solution space of all possible control laws for an optimal law, while only needing to simulate a small subset of the laws in the solution space. An algorithm to automatically adjust the resolution of the composite dynamically during execution will allow for faster optimization. Ideally, a mapping between the resolution and the type of decision being made can be created to guide the setting of the resolution in real time.