7. Distribution Control Solution
The control solution developed to meet these requirements consisted of the addition of a QNX control system to the PLC that currently provided low level control of pumps and monitored high limit switches.
The computer control system we developed is able to suggest the most effective routes for pumping chocolate based on source and destination tanks selected by the operator. A network graph model that describes the interconnection between the tanks, pumps and valves is used to make this decision. During pumping operations, the control system monitors high high limits (through physical limit switches) and high and low limits (through software). Pumps are automatically stopped when any limit is reached in either the source or destination tanks. A set of rules embedded in the control system prevents the operator from performing an action that may cause recipes to be blended, or that could cause a tank to overflow.
Initially we had chosen an expert system program to supply the 'smarts' necessary for the control program. The complexity of the piping systems soon made it clear that a rule based approach would not be viable. There are in excess of 10,000 unique routing possibilities within the system and 1036 possible combinations of valves and piping which were not monitored by any control system.
A better approach was found using a mathematical network model, known as an edge attributed graph, for which well-known algorithms exist to calculate such things as the shortest path between two points. This model was incorporated into a transportation modeler, which reads a file describing the entire piping network. Both the transportation modeler and control program were implemented using Cogent's SCADALisp programming language (which is a predecessor to the Gamma programming language). QNX and SCADALisp proved to be the ideal environment for developing this type of modular control system containing complex real-time computations.
In the final system, the network modeler runs as a separate QNX task that waits for source and destination tanks to be identified by the operator. The transportation modeler then generates a list of valve settings for an optimal route between the source and destination tanks based on which other pumping operations are in progress at that time. Communications between the network modeler and the control program were implemented using standard QNX inter-process communication. The network models were tested on-line and corrections were made directly to the running system, without having to shut down the control system to update the model. The actual control of pumping operations was transferred to the computer gradually with the operators gaining reassurance that the system was able to monitor many simultaneous pumping actions.
The Distribution system contains many nearly identical screen elements associated with the tanks and pumps in the network. Traditional interface development programs require that identical faceplates be copied over and over again and then modified to reflect the different data points linked to each element. For a large number of objects this can be tedious, and even minor modifications can be time consuming and frustrating. Since SCADALisp had already been established as a practical tool for the control elements in the system, a decision was made to use SCADALisp to generate the user interface as well.
Using SCADALisp we were able to write functions that constructed definitions for QNX Windows elements from a set of arguments. These arguments were stored in configuration files and they typically defined information for placement, scale and data point interactions. It then became relatively easy to construct higher level functions that automatically arranged groups of screen elements onto a single window. This method of developing screens had two major advantages over the more tradition screen editor approach. First, we did not have to expend a considerable amount of effort drawing hundreds of screen elements in an interface type editor program (which from experience would have taken many days or weeks). Secondly, we were able to make changes to the screen displays by simply changing the definition files and then re-running the SCADALisp code that generates the screens (all without shutting down the control system). On several occasions we made modifications and additions to the screens over the modem in order to quickly resolve problems the operators found with some of the placement of screen elements.