I do not think that combining all the charts to run on a single SoftPAC would work. Our distributed system is somewhat modular, and some of the nodes are very similar to each other (that is, they have the same set of I/O, and run the same charts).
I will try to explain our problem in terms of the PAC bottling plant demo. Let’s suppose that you have two bottling plants side by side, and you also have a supply center that supplies empty bottles to these plants when that plant needs more bottles. So you build a control system for the supply center that monitors each plant, and when that plant needs bottles, your control system loads up a truck and sends it to the bottling plant. How would you design and simulate this system?
In my opinion, an architecture with a single controller that handles all the I/O for both of the plants and the supply center has several shortcomings:
- The control for all of these it tightly coupled. If you controller goes down, you have to shut everything down.
- This architecture does not scale well, either. If you build a new bottling plant, you have to clone a new set of charts for the new plant, and also configure the new I/O. When you clone the charts and variables, you would need to make sure all the names are unique. If you need to make a logic change to one of the bottling plant charts, you need to update the cloned charts for the other bottling plants.
An architecture where you have separate controllers for each plant and one for the supply center addresses the above shortcomings.
- The control is decoupled
- This solution also scales better. If you build a new bottling plant, you can use the same set of charts for your new bottling plant. The only differences in the charts would be some network configuration.
To simulate this a system (with two bottling plants and a supply center) now requires that you have three separate sets of charts running on three separate controllers.