Note: Descriptions are shown in the official language in which they were submitted.
CA 02399996 2002-08-28
-1-
Title: MICROCOMPUTER CONTROL OF PHYSICAL DEVICES
FIELD OF THE INVENTION
This invention relates to automated control of physical systems
and, in particular, to a microcomputer-based system for controlling physical
devices.
BACKGROUND OF THE INVENTION
Automated control of physical devices has been the goal of
industry for over half a century. Simple logical control has given way to
increasingly complex and sophisticated systems relying on a central
processing unit (CPU).
A typical physical system includes a plurality of physical devices,
such as motors, valves, pumps, meters, thermocouples, heaters, and other
mechanical elements, gauges, etc. The automated control of such a system
involves acquiring information from these physical devices, such as motor
speed, valve positions, meter readings etc., processing the information with
reference to desired process parameters and then issuing commands to one
or more of the devices based on the outcome of the processing steps. The
more sophisticated the processing steps can become, the more sophisticated
and exacting the overall automated control system can be.
In practice, the physical devices (valve, pump, meter, etc.) have
an electric or electronic connection which are connected to a central control
device either directly or via an input/output (I/O) bank which has a plurality
of
I/O modules, typically at least one for connection to each device. Depending
on the device, the I/O signal is either an analog signal (e.g. an electrical
signal
measured in, say, millivolts (mV)) or a digital signal (e.g. an electronic
signal
representing a "1" or a "0"). The I/O bank will typically condition the signal
received from the physical device before passing the data on to a central
controller. For example, the I/O bank will typically convert analog signals to
digital signals.
Central control in modern industrial systems is typically achieved
with a programmable logic controller (PLC) unit. The PLC has a CPU which
uses software known as ladder logic to create logical paths for the
acquisition
f
CA 02399996 2002-08-28
-2-
of data and actuation of system devices. The PLC offers a robust, industrial
platform which is relatively low maintenance and insensitive to power
interruptions. Ladder logic, however, offers only relatively rudimentary
control of physical devices because it is generally limited to simple
operations
such as comparing a process parameter against a pre-determined value or
another input value, turning devices 'on' or 'off, sending alarm signals, or
starting a timer or other measurement means. Thus, for example, if the PLC
senses a temperature has reached a pre-determined critical level, the ladder
logic system may cause the PLC to send an alarm signal to an operator, or
may turn a heater off or open a cooling duct to alleviate the critical
temperature condition. More complex control operations, such as
incrementally adjusting the flow through a valve in response to a calculated
pressure differential between two points in a system, are difficult to achieve
with the PLC, and this difficulty is exacerbated by the fact that PLCs are
typically proprietary units which have a proprietary architecture and use
proprietary code and protocol in their programming. Thus, more sophisticated
programming of numerous PLCs is difficult and linking a number of systems
and/or PLCs together is in some cases, practically impossible.
PLCs typically offer little in the way of human operator
interaction. In recent years, however, PLCs have been given the ability to
speak on a limited basis to the standard personal computer (PC) to provide a
human-machine interface (HMI) which gives human operators a graphical
representation of what the ladder logic is doing inside the PLC during program
operation. The PC is also used in a passive role for such operations such as
data logging, historical tending and the like. While a limited amount of data
can be transferred from the PLC to the PC, and vice versa, to permit the
operator to affect process parameters, the logical control of the control
system
remains with the PLC and, without access to the manufacturer's proprietary
software, programmability is near impossible. In any event, the PLC's reliance
on ladder logic restricts the sophistication available to the programmer.
Furthermore, the use of ladder logic does not permit the PLC to interface with
other PC-based software applications and/or the operator's computer
networks
CA 02399996 2002-08-28
-3-
In its HMI role, the PC functions essentially as a graphical
interface with the PLC and as a passive collector of data. Typically, to
accomplish this task, the PC uses database software known as a supervisory
control and data acquisition (SCADA) system. The SCADA system collects
information, logs the information, and allows for sophisticated display of the
information on a operator graphics terminal, such as a touch screen display.
The SCADA program typically permits the PLC controller and physical
system to be displayed graphically in a manner that mimics the actual
physical system, which permits the operator to more easily identify with the
real system.
In essence, the SCADA program is used to monitor the PLC-
controlled system and provide certain control commands to the PLC. Such
control commands may be automatically initiated by the SCADA program or
may be initiated by the operator and passed by the SCADA program back to
the PLC. Underneath the graphical display is the SCADA program which is
essentially a database which can store and access data and perform
calculations and operations based on that data. Data is typically stored and
manipulated in a variety of data 'blocks' within the database. Depending on
the particular SCADA program used, a number of block types are available,
such as analog input blocks, digital input blocks, calculation blocks, boolean
logic blocks, text label blocks, program blocks, analog output blocks and
digital output blocks, to name a few. SCADA programs of this type are
described in more detail in Inteltution Incorporation's U.S. Patent No.
5,179,701. As described in the '701 patent, however, the SCADA program is
always used in conjunction with an "external control device", such as a PLC,
and thus the PC-based SCADA program is used only to access data,
manipulate data and output data within the traditional HMI role in a PLC
controlled physical system and, thus, is constrained by the limitations of the
ladder-logic-based PLC system discussed above.
Accordingly, there is a need for an improved control system for
physical devices which allows the computing flexibility and power of a PC
platform and other microprocessor-based platforms to be more fully utilized.
r~
CA 02399996 2002-08-28
-4-
SUMMARY OF THE INVENTION
The present invention provides a control system for controlling
the operation of a machine comprising a plurality of devices, said control
system comprising:
(a) a supervisory control and data acquisition (SCADA) program,
said SCADA program including a plurality of program blocks and
a plurality of database blocks;
(b) a supplemental program;
(c) a processor, wherein said processor is adapted to execute
said SCADA program, wherein said processor is adapted to
execute said supplemental program, and wherein said
processor is adapted for controlling operation of the devices;
(d) a memory coupled to the processor for storing the SCADA
program and the supplemental program;
(e) an input/output device coupled to the processor, for receiving
and providing electrical signals directly to and from the devices;
and
(f) said supplemental program enabling the processor to
interoperate at least one program block of said SCADA program
and at least one database block of said SCADA, in response to
electrical signals received from the devices, such that said
processor can control the devices directly and without the need
for an additional external control device.
In another aspect, the present invention provides a method of
controlling a machine comprising a plurality of devices, using a control
system
that includes a processor that executes a supervisory control and data
acquisition (SCADA) program which includes a plurality of program blocks
and a plurality of database blocks, said method comprising the steps of:
(a) receiving electrical signals from at least one of the devices;
(b) interoperating at least one program block of said SCADA
program with at least SCADA database block in response to the
electrical signals received from the devices using a
supplemental program stored with the SCADA program;
fi
CA 02399996 2002-08-28
-5-
(c) providing electrical signals to the devices that correspond to
the output of the at least one SCADA program block such that
the devices can be controlled directly and without the need for
an additional external control device.
BRIEF DESCRIPTION OF THE DRAWINGS
For a better understanding of the present invention, and to show
more clearly how it may be carried into effect, reference will now be made by
way of example to the accompanying drawings, in which:
FIG. 1 is a schematic view of a PLC-based control system
according to the prior art;
FIG. 2 is a schematic view of a PC-based control system
according to the present invention;
FIG. 3 is a schematic of a example logical chain of blocks of the
control program used in the system of FIG. 2;
FIG. 4 is a schematic diagram illustrating the program modules
of the supplemental programs utilized by the control program in the control
system of FIG. 2;
FIG. 5 is a flowchart of the TIMER routine which is executed by
the PC within the control system of FIG. 2;
FIG. 6 is a flowchart of the INTERLOCK routine which is
executed by the PC within the control system of FIG. 2;
FIG. 7 is a flowchart of the MAINTENANCE routine which is
executed by the PC within the control system of FIG. 2;
FIG. 8 is a flowchart of the PROGRAM routine which is
executed by the PC within the control system of FIG. 2;
FIG. 9 is a flowchart of the DIAGNOSTIC routine which is
executed by the PC within the control system of FIG. 2; and
FIG. 10 is a flowchart of the HISTORICAL routine which is
executed by the PC within the control system of FIG. 2.
CA 02399996 2002-08-28
-6-
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT
Referring to FIG. 1, a PLC-based control system according to
the prior art is shown at reference numeral 10. Control system 10 is used to
control the operation of a physical system 12 comprising a plurality of
components such as valve 12a, pump 12b and meter 12c, connected by a
plurality of signal lines 14 to an I/O bank 16 having a plurality of I/O
modules
16a, 16b, 16c and so on. One skilled in the art will understand that physical
system 12 may have hundreds of components and that only three such
elements are shown here for ease of explanation. I/O bank 16 conditions the
electronic signals received from signal lines 14 and communicates the
conditioned signals to a PLC control unit 18. PLC 18, using a ladder logic-
based software control system and communication protocol, monitors
readings received from physical system 12 and effects command signals for
return to system 12 via I/O bank 16.
Human machine interface (HMI) is provided in the form of
personal computer (PC) 20 which communicates with PLC controller 18 to
receive data from the PLC and log and/or display desired data to a human
operator. Ladder logic control software resident on PLC controller 18 permits
PLC to control physical system 12 and send certain data to PC 20 for display
thereon. PC 20 performs its operation by executing a supervisory control and
data acquisition (SCADA) software program such as that described in U.S.
5,179,701 to Intellution Incorporation, incorporated herein by reference. The
'701 patent describes a system which is similar to a product marketed by
Intellution Incorporation under the trade mark FIX 32. The SCADA program is
described in more detail below.
Referring to FIG. 2, a control system according to the present
invention is shown at 30. Control system 30 is similar to the prior art PLC-
based control system 10, in that it is used to control a physical system 32,
comprised of a plurality of physical devices such as valve 32a, pump 32b and
meter 32c from which electronic signals can be received and to which
electronic signals can be provided. It should be understood that any physical
device which is capable of sending an electronic signal based on its current
operating condition or receiving a signal to affect its current operating
CA 02399996 2002-08-28
-7-
condition may be used. Unlike the prior art PLC-based control system 10,
however, the physical devices 32a, 32b and 32c can be controlled through
direct communication with a microprocessor-based computer, such as a
personal computer (PC) 34, via a plurality of signal lines 36a, 36b and 36c.
The devices may communicate with PC 34 via an I/O bank 38 (see valve 32a
and pump 32b) or may be connected directly to PC 34 (see meter 32c).
I/O bank 38 can be any conventional I/O bank product that
contains a plurality of I/O modules 38a, 38b, etc, one for each input/output,
and communicates with PC 34 via a network connection 40. I/O bank 38 is the
same type of unit as used by the prior art control system 10. I/O bank 38
preferably accommodates both analog and digital inputs and outputs and is
capable of conditioning and scaling the inputs received and outputs sent to
permit full and complete communication between the physical devices 32a,
32b and 32c and PC 34. I/O bank 38 may be any type of input/output unit
connectable to a personal computer, such as the preferred SNAP I/OT"" board
(manufactured by Opto 22, Inc. of California, U.S.A.) Alternately, an existing
PLC can be modified, by disabling the ladder logic control program, to permit
the PLC to be used simply as an I/O bank, as will be described in more detail
below.
PC 34 is preferably a personal computer, but it should be
understood that any microprocessor-based computer capable of running the
SCADA program described below may be used. It is desirable to use very
stable operating system for PC 34 to provide reliable system performance for
industrial application. For this reason, an operating system such as
WINDOWS CET"" or WINDOWS NTT"" (manufactured by Microsoft
Corporation of Seattle, U.S.A.) is preferred. Other operating systems may be
used, however, such as UNIX, OS2, Windows 98, LINUX and Apple operating
systems. Unlike the prior art PLC-based control system 10, PC 34 controls
system 30 directly by using the SCADA program to monitor inputs, perform
control calculations and issue output commands to the physical devices
without the need for a ladder-logic system of the imposition of an external
control device like a PLC.
CA 02399996 2002-08-28
.8.
As stated, the SCADA program of the type employed with the
present invention is described in U.S. Patent No. 5,179,701, which is
incorporated herein by reference and thus will be described only briefly. The
SCADA program permits the operator to create a spreadsheet-like database
which, in essence, allows a plurality of different types of data blocks, such
as
input blocks, output blocks, control blocks and program blocks to be stored,
scanned and manipulated according to how they are incorporated within the
operational program. Within the SCADA database, each input and output
device in the physical system (valve 32a, pump 32b and meter 32c) is
assigned to an input and/or output data block, depending on the device and
then a plurality of additional data blocks containing information about that
input and/output are related to each such input/output block. In this manner,
a
data array is constructed containing all relevant data relating to each input
and output, such as the following types of data: the signal type (e.g. analog
or
digital); input/output location within the I/O bank (e.g. Rack 1, Module 1 );
a
network address assigned to the device; a label or text description of the
signal (e.g. "valve", pump"); any signal conditioning factor to be applied to
the
I/O signal; an alarm state or condition for the signal; and default values for
the
signal on start-up, etc. Other data may also be desired or required,
depending on the system or desired control program. In operation, the
SCADA program periodically scans the inputs and outputs to retrieve new
input values from, and to provide new output values generated by the SCADA
program to, devices 32a, 32b and 32c.
Once this array has been constructed, the SCADA system is
programmed according to the control procedures desired. To do so, the
variety of data manipulation blocks offered with the SCADA program are
chained together logically, and programming scripting is written to interact
with these logical chains, to provide system control fully within PC 34. The
plurality of data manipulation blocks types available in the SCADA program
described in U.S. Patent No. 5,179,701, include proportional-integral-
derivative (PID) control blocks, calculation blocks, program blocks, boolean
logic blocks and others, listed in Table 1 below, and described in more detail
in U.S. Patent No. 5,179,701.
CA 02399996 2002-08-28
_g_
TABLE 1
BLOCK TYPE BLOCK TYPE
Analog alarm On/off control
Analog input Pareto
Analog output PID
Boolean Program
Calculation Ramp
Digital alarm Ratio/bias
Digital input Signal select
Digital output SQL data
Digital register SQL trigger
Event action Statistical control
Extended Trend Statistical data
Fanout Text
Histogram Timer
Lead lag Totalizer
Multistate di ital in ut Trend
As stated, these blocks can be arranged in a logical order with
the physical inputs and outputs of the system, so that one block can send its
value to another block, and subsequent blocks may be linked to create a
logical chain among several blocks in the databases. This feature is useful in
achieving the control of devices by allowing for simultaneous monitoring of
appropriate outputs and provision of appropriate inputs accordingly to desired
control procedures. For example, a temperature input can be sent to a PID
controller block, downstream in the logical chain, to permit the PID block to
perform a PID calculation on the temperature output, to provide a resulting
output control value for the system, say, a heater setting output value. The
chaining of data blocks is described more particularly in U.S. Patent No.
5,179,701. In the course of creating logical chains, the program may be
configured to permit a plurality of "simulated" inputs and/or outputs to be
calculated and manipulated, in addition to the real, physical inputs and
outputs of the system, to provide enhanced and more sophisticated control.
CA 02399996 2002-08-28
-10-
Referring now to FIG. 3, an example logical chain of blocks of
the SCADA program as developed for use in association with a controlled
physical system (not shown) involving a heater, coolant flow and
thermocouple is illustrated.
A thermocouple 50 provides a signal to the SCADA database
via an analog input I/O module in I/O bank 38 to connect to PC 34 (not
shown) which is then passed to and stored within an Analog Input data block
52 in the SCADA database. The Analog Input block 52 is chained logically
upstream of a PID (proportional-integral-derivative) control block 54 which,
upon receiving the thermocouple reading, performs a PID control calculation
on the input signal value, then compares the input value to a set point value
and, based on the comparison, sends an output value to an Analog Output
block 58 downstream in a logical chain. This "output" value from the PID block
54, however, is not immediately output and is, thus, a "simulated output" to
be
used in a further downstream calculation or operation.
The simulated Analog Output block value is subsequently
provided (in this example) to a Calculation block 56 to calculate an
appropriate Analog Output value to be sent to a heater 60, and this value is
then stored by PC 34 (not shown) in an Analog Output block 58. The output
heater setting provided to heater 60 may be a reduced heater setting and,
when the SCADA database performs its scan cycle to update inputs and
outputs, this reduced-setting output value is sent to heater 60 via I/O bank
38
to heater 60 to modify its operation accordingly. Advantageously, this type of
control system can permit the output of heater 60 to be gradually reduced
over a calculated time period. On each scan cycle, the effect of the heater
reduction can be monitored by the system, until the process is near the
desired target temperature. This provides a dramatic improvement over the
simple "heater ofP' type control available with the ladder logic systems of
prior
art PLC-based control systems.
The use of the intermediate products stored as "simulated"
inputs/outputs permits a further flexibility in programming. For instance, in
the
previous example, if the simulated output, say, indicates that an upper
threshold temperature has been reached in the system, a subsequent script
CA 02399996 2002-08-28
-11 -
program (discussed further below) triggered by a downstream block can
determine if another system factor other than the heater is responsible. The
program may, for instance, check the flow of coolant through the cooling
system to determine whether this is the cause for elevated temperature. If so,
the control program may choose to modify the rate of coolant flow, using the
simulated output as an input to a control calculation for a flow valve or
other
flow regulation means in the physical system. This type of sophisticated
control is not available with PLC-based systems.
As stated, the SCADA program as described in U.S. Patent No.
5,179,701 also provides program blocks in which computer scripting language
can be incorporated, thereby allowing mathematical functions and algorithms
to be used to compare input values received from the I/O bank to desired
values and permit the control system to act to correct any deviations. Other
chains or events can then be initiated by the program blocks using many
different types of conditions. For example, the database can wait for a device
to reach a certain set point and, if the set point is not reached in a given
period of time, then a sequence of events can be put into effect by the
control
software. Once the device meets the required set point, then the control
procedure can be continued. For example, the program block can, once
executing, wait until a specified temperature input is reached and then issue
a
control command to the physical system to maintain that temperature for a
given amount of time. Simultaneously, the program can check for any
deviation in temperature ramp rate or final temperature and locate the cause
of the failure by scanning the appropriate blocks. Once an error is detected,
such as a heater element fault, an alarm can be issued and compensation
can be made during the process to ensure the load is run properly, such as
increasing the heat output of the other elements.
As shown in FIG. 4, PC-based control system 30 utilizes
supplemental program modules 61 to ensure that the various SCADA
program blocks execute on PC 34 to provide consistent and reliable control to
devices 32a, 32b, and 32c directly and without the use of an external control
device (e.g. PLC device). It should be understood that the SCADA program
blocks and database blocks were designed to interoperate with an external
CA 02399996 2002-08-28
-12-
control device, and accordingly if an external control device is not utilized
with
a SCADA program, several operational problems result.
The supplemental program modules are installed alongside the
SCADA program within the memory of PC 34. The supplemental program
modules are adapted to interoperate with various SCADA program blocks and
to provide a sufficient degree of supervision of the SCADA program such that
an external control device is no longer required for proper and complete
operation of the devices 32a, 32b, and 32c. Supplemental program modules
include a timer module 62. an interlock module 64, a maintenance module 66,
a program module 68, a diagnostic module 70, and a historical module 72.
These program modules are all interoperable with the SCADA program blocks
and together achieve operational control of devices 32a, 32b, and 32c as will
be described in detail below.
Referring now to FIGS. 2, 4, and 5, a flowchart of the TIMER
routine 100 which is executed by the internal microprocessor of PC 34 when
timer module 62 (FIG. 4) is utilized within control system 30 of FIG. 2, is
specifically shown in FIG. 5. One of the main problems that the inventor has
encountered that on continuous running, many of the reset triggers and timers
and recipes do not reset upon subsequent runs. As a result, every time it was
desired to run a process it was necessary to reload the database. When the
database was reloaded, it was necessary to cease scanning the inputs and
outputs, and to load in the default values for all program blocks and
accordingly important operational information stored in the timer block would
be lost (i.e. reset to default values) between runs. The timer module 62 of
the
supplemental program 34 was developed to address this operation limitation.
Specifically, at step (102), the script checks to see whether the
device (e.g. a pump) is on. An event in the script sends an "on" signal, or a
"1"
in the case of the Digital output block (DO) to start this chain of events
within
the timer module 62. A command in the script causes the SCADA database to
send a "1" value to trigger the DO block at step (104) and in tum the DO block
triggers the Boolean block at step (106). The Boolean block passes along
the"1" value to start the Timer block to count the "on" time at step (108). As
the time is counting, the timing data needs to be saved in the SCADA
CA 02399996 2002-08-28
-13-
database and so the script periodically takes the timer value and puts it into
a
TIMER variable at step (110). The TIMER variable is then stored in a text
block to be saved in the database at step (112).
Various additional routines can be built on top of the functionality
of the TIMER routine 100. For example, once the Timer block is started it can
be programmed to count down from a predetermined set point. A set point
can be downloaded from a Recipe program again by the script (not shown).
Once the timer has finished counting down, the script passes the "1" value to
a Quenchtrigger, which starts another chain of events (not shown). The script
contains a loop that waits for the Quenchtrigger to have a value of "1" which
is
the signal to continue with the program. In this way it can be ensured that
the
program holds for the appropriate amount of time while a certain chain of
events is accomplished. Finally, It is also possible to count the number of
operational cycles by utilizing the same procedures but by counting how many
times a device (e.g. a furnace) runs a program instead of "on" time as
discussed above.
Referring now to FIGS. 2, 4, and 6, a flowchart of the
INTERLOCK routine 200 which is executed by the internal microprocessor of
PC 34 when interlock module 64 (FIG. 4) is utilized within control system 30
of
FIG. 2, is specifically shown in FIG. 6. As is conventionally known in the
manufacturing field, interlocks are used by control systems to provide
safeguards against an operator doing something they are not supposed to.
For example, it is not desirable to allow a furnace door to be opened when the
furnace is at 2000 °F, so an interlock is created to prevent the
operator from
opening the door. When the operator pushes the button to open the door, PC-
based control system 30 will check to see if the temperature is below a safe
value before allowing the door to open. If it is not then the door does not
open
and we can display a message telling the operator the furnace is too hot.
It should be noted that in PLC-based control system 10, ladder
logic is used to check whether a number of conditions are present (i.e. the
pump must be off, the valve closed and the heaters off in order for the door
to
open). It was desired to allow PC-based control system 30 to react at any
point in the program when a operator tries to open a furnace door (or the
like).
CA 02399996 2002-08-28
-14-
In PC-based control system 30, it is contemplated that various routines would
be operating at the same time, and that it would be possible to jump back and
forth from one sub-routine to another if desired. It is noteworthy that such a
control scheme is not possible within ladder logic (i.e. associated with a
PLC).
Interlocks generally use a series of "if' statements to check the
status of the pertinent devices before allowing operation to continue. A
combination of code and values in SCADA database blocks were used within
interlock module 64 to implement proper interlock operation. Specifically, at
step (202), the device "on" button is pressed by the operator and the script
then checks necessary operational conditions for allowing the device to be
turned on (e.g. whether valve 2 is closed and valve 3 is open) at steps (204)
and (205), respectively. It is determined using the appropriate SCADA
program blocks whether both conditions are satisfied at step (208). If not
then
an alert message is sent to the operator at step (212) and optionally the
necessary conditions for operation are established (e.g. valve 2 is closed and
valve 3 is opened) at step (214). If the conditions are satisfied then at step
(210) the device is turned on. Also, once the alerting process and/or the
necessary operational conditions are established, the device is turned on at
step (210).
Referring now to FIGS. 2, 4, and 7, a flowchart of the
MAINTENANCE routine 300 which is executed by the internal microprocessor
of PC 34 when maintenance module 66 (FIG. 4) is utilized within control
system 30 of FIG. 2, is specifically shown in FIG. 7.
For example, in order to record how long a device (e.g. a pump)
has been operational the MAINTENANCE routine 300 must be executed.
When the device is turned on at step (302), a trigger with the same I/0
address is also turned on at step (304). The "1" value from the Pumptrigger
(i.e. a DO block) is sent to a Boolean block at step (306), which then starts
a
PUMPTIMER SCADA database block at step (308). The PUMPTIMER
database block then records the amount of time the pump is on. A script
program takes this value from the database block and stores it in a
PUMPTIMER variable at step (310). This variable is then sent to a Text block
in the SCADA database for storage at step (312) for use in an operator
CA 02399996 2002-08-28
-15-
display. Another script is used to compare this value to a preset value to
determine whether maintenance can be scheduled at step (314).
In this way, run time counters can be constructed to tell how
long a pump has been running and when it needs maintenance. Generally,
this required setting up variables to check the status of some database
blocks, triggering the timers and updating the variables with a new timing
values. Timers elsewhere also need augmentation in order to save their
values, which meant conducting certain file manipulation to periodically save
data and to upload it to the database for operator information. queries
Referring now to FIGS. 2, 4, and 8, a flowchart of the
PROGRAM routine 400 which is executed by the internal microprocessor of
PC 34 when program module 68 (FIG. 4) is utilized within control system 30 of
FIG. 2, is specifically shown in FIG. 8. In order for a manufacturing system
(e.g. a furnace) to run a program, a set of checks must be run to confirm that
the system is ready for operation. When the operator pushes the start button
on the screen a script goes through all the interlock checks (an example of
which was described in reference to the INTERLOCK routine 200 of FIG. 6) to
make sure all pumps, valves, and the like etc. are "in the proper order"
before
starting. If they are not, a message appears on the screen to tell the
operator
what the problem is and how to remedy it.
Specifically, the script starts an operational program that is to be
run on the manufacturing equipment at step (402). The script then starts
sending operational values to the appropriate blocks in the database at step
(404) to turn on pumps and cycle valves at the appropriate time, while
comparing vacuum levels and times. When the vacuum level is determined to
be correct at step (406), the scripts execute a command to download a pre-
programmed recipe at step (408). As is conventionally known in the
manufacturing field, the recipe sets the values for the temperature set point
and timers in the database at step (410). The database then takes over and
runs a logical chain of blocks at step (412) to control the furnace
temperature
and temperature of the load. The script waits until the database is finished
running the program at step (414) from the recipe downloaded. Then a trigger
starts the script to continue execution at step (416). At this point, it is
also
CA 02399996 2002-08-28
-16-
possible to dynamically set alarm values in certain database blocks based on
the values downloaded from the recipe for additional functionality.
This procedure can be used in association with other parts of
the furnace cycle. The script is executed and obtains data from the recipe,
writes the data into the database and then uses a trigger to send control back
to the script to continue to the next process. This can occurs a set number of
times (e.g. four). As is conventionally, known, once for the Brazing part of
the
cycle, then to a Quench sequence, then for a Temper part of the cycle, then to
do a Quench again, then finally the script finishes the program.
As discussed above, in order for PC-based control system 30 to
run a preset program a combination of code, database blocks and recipes are
used. The program starts in the script and then at the appropriate time
downloads values from a stored recipe. This allows the form of the code to
remain constant even though different values maybe downloaded from
multiple recipes. Once the recipes are downloaded, the values are
automatically put into the database. Logical chains in the database act on
these values to perform different functions (e.g. temperature control, and
cooling functions). Once any logical control from the database is
accomplished, the script looks for triggers, such as the Quenchtrigger noted
above, to continue in the code. This format is repeated in the code and is the
basis for the control system. The database is constantly scanning the blocks
and can be performing tasks at the same time as the script is running. This
approach is useful when controlling the furnace because the system can be
waiting for a critical value to be met in the code while the database is
controlling the temperature through PID blocks. Since the code can be
executed faster than the database scans, any interlocks written in the
database could be bypassed simply because the code executed before the
database had a chance to update. In order to remedy this, we had to transfer
all of our interlock checks to the code that starts the program.
Finally, historical data collection is initiated during operation of
the manufacturing machine. The script executes a command that starts the
built-in History Recorder Program within the SCADA program and is assigns
an operator provided file name. This way, every process run can be tracked
CA 02399996 2002-08-28
-17-
by file name. These files are stored on the hard drive of PC 34 and the date
and time are also associated with the file so that the History Display Program
can open the appropriate file for display and analysis purposes.
Referring now to FIGS. 2, 4, and 9, a flowchart of the
DIAGNOSTIC routine 500 which is executed by the internal microprocessor of
PC 34 when diagnostic module 70 (FIG. 4) is utilized within control system 30
of FIG. 2, is specifically shown in FIG. 9. The diagnostic module 70 uses the
history collection and display functions of conventionally available SCADA
program as well as original script, a few database blocks to hold some
operational values (e.g. to run the pumps and valves).
Specifically, the program first runs a pump down sequence to
bring the furnace under vacuum at step (502). It should be understood that
this step could be generalized to bring any manufacturing machine or
equipment to an operational state. The graph of all the different pressure
gauge readings are stored in a file at step (504) in much the same way that
the process runs are recorded (discussed above). A date and time stamp is
associated with the graph at step (506) and the curve is then displayed on a
background chart at step (508). A new chart is recorded and simultaneously
displayed showing the current pressure curve (could be any other current
diagnostic information) at step (510). Since date and time stamps are
associated with the graphs, the operator is enabled to view two graphs
simultaneously in order to compare a base line pressure curve to the current
pressure curve. This diagnostic system allows the operator to run a
comparison of the vacuum pumping performance of the system to a baseline
curve generated at their point of choosing. This functionality is not
currently
possible within traditional control systems.
Referring now to FIGS. 2, 4, and 10, a flowchart of the
HISTORICAL routine 600 which is executed by the internal microprocessor of
PC 34 when historical module 72 (FIG. 4) is utilized within control system 30
of FIG. 2, is specifically shown in FIG. 10. Control system 30 also tracks the
cycle runs of the associated equipment using the customers' production
numbers and can display a graph of the cycle using the build-in SCADA
Historical Display program (e.g. lntellution's Historical Display program).
CA 02399996 2002-08-28
-18-
Specifically, a file is created when the operator enters the
production number at step (602) and a file is created and linked to the
historical recording function at step (604). A list of the files is maintained
and
updated at step (606) within the SCADA database. This allows for relevant
information to be displayed on display to the operator to show exactly what
happened during the run based on a particular production number. During the
process, the alarm and setpoints can be dynamically changed based on the
input of the operator. For example, if the operator enters a particular
setpoint
(e.g. 100 °F) at step (608), then a high temperature alarm is
automatically set
at a predetermined value higher (e.g. at 110 °F). Subsequently, if the
operator
changes the setpoint to 150 °F, then the high temperature alarm would
be
automatically set to 160 °F. The predetermined value (i.e. the
difference
between the operator entered setpoint and the high temperature alarm) can
also be adjusted within the program as well.
It should be understood that the above-described routines are
only examples of the kind of functionality that is contemplated within control
system 30. For example, another contemplated feature would allow the
control system 30 to switch between inputs if a thermocouple fails during a
run. If as the process is running the thermocouple break (as commonly
happens), the system could automatically transfer the measurement
equipment to a backup thermocouple in order to keep the process running.
Also with regard to maintenance, it is possible to implement a clean up cycle
that needs to be run every 45 cycles (for example). For this application, the
counter block is used to keep track of cycle runs and every 45 runs, a
message is displayed to the operator indicating that it is time to run the
clean
up program. The operator has the choice of running the program or bypassing
it to do one more production run before the clean up cycle. This bypass option
will come up every time until the clean up cycle has finally be run and the
counter starts counting to 45 again
Within PC-based control system 30, control blocks, calculation
blocks and program blocks can be treated entirely within the PC database to
take real input values (i.e. values supplied by the I/O bank) and, through a
calculation process or the operation of a subroutine, create a series of
CA 02399996 2002-08-28
-19-
simulated I/O values which may be further processed by downstream
calculation or program blocks to create ultimate real output values for return
to
the control system. In this way the SCADA database software permits
realtime control of the physical system without the use of a PLC or ladder
logic. Advantageously, by freeing the control system of ladder logic, the
present invention permits a more sophisticated automated control, such as
permitting control parameters to run within a range and allowing multiple
inputs to be monitored and polled in response to a threshold condition,
permitting a variety of control operations to be explored for a given
threshold
situation.
Prior PLC-based systems cannot provide such sophisticated
control and allow for only rudimentary control. For example, if an input
thermocouple reached a critical temperature, a PLC-based system could only
effect a rudimentary result such as sending an alarm or shutting off a heater.
Also, because PLC-systems are limited in the amount of inputs and outputs
which can be monitored, due to memory limitations in the PLC. As described,
the present system permits a more sophisticated control such as gradually
scaling back an output setting to permit the system to return to the control
range, or to poll other system parameters to determine whether another
system parameter is the cause of the particular event considered. Also, an
almost infinite number of inputs and outputs can be monitored and controlled,
the numbers being limited only by the amount of RAM memory available in
the PC.
By eliminating the PLC, the control system of the present
invention is able to incorporate the flexibility and power of PC-based
applications in the operation and control of physical systems. With this
flexibility, operations such as data logging, trending, reporting, control
algorithms, monitoring, alarming, maintenance handling and error checking
can be more easily affected. Diagnostics can be run on the physical devices
to ensure reliable and functional operation of the system as a whole and/or
each particular device. Data can be moved to other applications within the
PC or microprocessor-based system for further processing. This permits the
plethora of application software available for the PC platform to be used.
CA 02399996 2002-08-28
- 20 -
Furthermore, by freeing the control system from the limitations of ladder
logic,
an increased degree of intelligence can be introduced to the control system to
permit more advanced alarming and error handling and the like to permit the
physical devices to operate within a range of process parameters rather than
the binary on-off capability of the PLC-based systems. Programming can be
provided, by way of control blocks, program blocks and scripting to allow a
physical device to run within an operating range and, if the device moves to a
condition outside of this range, the control system is able to affect changes
in
the operation of the physical system to bring the process back within the
desired range without the aid of manual intervention, the capability not
possible with current PLC-based systems.
Furthermore, by relocating control to the PC, the power of
Internet applications, worldwide web technology and local and wide area
networks are at the disposal of the programmer to be incorporated into the
control system strategy. Furthermore, the programmer is able to call on a
multitude of PC input and output devices, such as touch screen monitors,
keyboard, mouse or voice-activated input devices and modem output devices
to permit increased ~exibility for operator interface with the PC-based
control
system. For example, connection of the PC controller to a network permits
remote access to the PC from an external source and allows a remote
operator to access the control system. This is highly advantageous in a
global community where, for example, a control system running on one
continent may be accessed in real time by personnel, such as system
maintenance and support personnel at the equipment supplier, to access a
customer's control system to troubleshoot problems or provide software
updates, etc.
The present invention thus permits the proprietary hardware and
software of the ladder logic-based PLC systems currently in use to be
eliminated and permits the control system to conform to existing IT standards
for communication to networks and other computer software packages
currently in widespread use throughout the world. Furthermore, as increased
computing power is added to PC platforms, the software is transferable and
scalable to new PC platforms as they become available. Accordingly, the
CA 02399996 2002-08-28
-21 -
programmer is no longer reliant upon the closed proprietary systems of PLC
and equipment manufacturers.
Other features may be added to enhance operability and
functionality of the control system. For example, security features such as
password protection and power interruption contingencies may be added.
As one skilled in the art will understand, an I/O bank is preferred
but not necessary in the operation of the present system. For example, any
physical device which is capable of sending and receiving an electronic signal
may communicate directly with a properly configured microprocessor. In
other words, driver software may be provided directly to the microprocessor to
permit it to communicate directly with the physical device. Also, as mentioned
above, the PLC used in an existing system may be modified to operate as an
I/O bank. In such a system, the rungs of the prior-existing ladder logic
control
system of the PLC are deleted, leaving only the addressing information.
When this is done, the PLC acts as a I/O bank and advantageously permits
the upgrade of existing equipment currently using PLC control to be modified
to employ the system of the present invention.
While the above description constitutes the preferred
embodiment, it will be appreciated that the present invention is susceptible
to
modification and change without parting from the fair meaning of the proper
scope of the accompanying claims.
