Patent Grant
7474925
This invention relates to a system for automation of technical processes or experimental procedures having a measurement and control unit connected to sensors and actuators of a process, a library containing visualization objects and control modules together with software managing the system.
There is a group of products known as “process instrumentation and control systems” on the market. They are often used to control and operate large industrial installations. Such systems work on two tracks. For control tasks they use automation software known as PLC (programmable logic controller) software and PLC programming system. Visualization software independent of the control software is used for operator guidance. Control software and visualization software run in distinct devices: the control software in PLCs or process control devices in a process plane, and the visualization software in the instrumentation and control plane. Therefore, the automation as a whole is not a self-contained unit. It is not possible to set up such automation without the aid of specialists. The expense is considerable.
At the end of the 1980s, when personal computers (PCs) with a degree of power and graphical capabilities had been developed, virtual measuring instruments appeared. Measuring instruments with knobs, buttons, switches and display instruments were known up to then. Measuring circuits were physically built up from wire and filters and the like.
The early measuring instruments were replaced by virtual measuring instruments and measuring circuits. Now one had illustrations of such devices on the screen. Turning knobs and actuating buttons and switches were replaced by mouse clicks. Automation was not yet associated therewith. A programming language was overlaid thereon to remedy this defect. In the view of many users, the setup of automation on the basis of such software solutions is very complicated and demands a long familiarization time. A user needs special knowledge that he must acquire. The expense is considerable. These solutions did not succeed in bringing about consistency between operating and observing and automation. In laboratory automation in particular, it would be very advantageous to have simple solutions making it possible to develop automation tasks quickly, without large expense and without the necessity of possessing special knowledge or employing specialists.
It is a primary object of the invention to remedy the before mentioned shortcomings by providing a closed unit or a system that enables the user to cause processes to run their course or to perform experiments without learning the syntax of a programming language. With this invention, a user can concentrate solely on his experimental and/or process tasks.
The object of the invention is achieved by using a measurement and control unit that is connected to sensors and actuators of the process or of the experimental unit via measurement and control lines, using at least one library that contains visualization objects and control modules, and by using software that manages the system. This invention permits proceedings that are laborious to carry out manually to be performed automatically by the herein disclosed system.
The measurement and control unit brings about the connection to the experimental setup or to the process that is to be automated. This connection to the process rests on measurement channels and control channels that are connected to the sensors and actuators of the process. In many cases it is also necessary for the measurement and control unit to have ports available through which other devices are integrated into the automation occurrence. Such devices can, for example, be scales whose measurements are supplied to the automation system via a port.
The software makes it possible to query the status of the experiment via the measurement portion of the measurement and control unit 49, draw the needful conclusions therefrom and, via the control portion, put the sequence of the experiment in the form desired by the user.
The software further puts methods in the user's hands for observing and operating the experiment during runtime. This occurs via graphical screens, which may show process diagrams as shown in
A library for visualization objects and a library for control modules is furthermore available according to the invention. The function of the visualization objects and control modules as illustrated in
Provision is made for a user to first select, from a library, those visualization objects, that he needs for his automation task. He will arrange them on the screen in diagrams, such as shown in
Visualization objects are linked to control modules predefined as to their function. Both together contribute to the accomplishment of sub-tasks of automation. When a visualization object has been selected, the linked control module is simultaneously shown in a module window without effort on the user's part.
In a further embodiment of the invention it is provided that there are, in the program code of the control modules, instructions that directly change the properties of visualization objects. Writing of text messages in text output boxes and similar control transactions are directly integrated into the automation process by querying properties of, for example, a virtual button.
A user, from the knowledge of his experiment, can select further modules from the library of control modules. The previously automatically exhibited control modules do not cover all functions necessary for the accomplishment of the automation task. The framework of the automation task is completed with the choice of the further control modules
A central idea of the invention for the achievement of the overall object is to allocate the control modules to the categories sequences, events and functions, wherefrom three types of control modules are derived. These are the sequence module, event module and function module types.
The sequence module type, as its name states, is responsible for the temporal ordering of various activities one after another. It handles process guidance. These activities are affected by the status of the automating process and by operator transactions. For example, further actions must wait to be run until a temperature has been reached. The process can wait at a certain point until an operator transaction has taken place.
The event module type processes proceedings are chiefly unexpected for the process sequence and can arise at an arbitrary point in time. The event modules are invoked by interrupts. As soon as the event arises, activities are initiated that break into the sequence. After the activities of the event have been worked through, the normal sequence is resumed unless the event has as its consequence a safety shutdown that terminates the program. Event modules are, however, never invoked by other modules. Events can include sequences that break into but never supplant the original sequence. Event modules are almost always linked to visualization objects.
The function module type includes special functions, for example controller, measurement, set points controlled in dependence on time, and the like. Function modules are characterized by the fact that they work concurrently with sequence modules. Thus function modules work in parallel to sequences. Process guidance is not handled by function modules. Function modules can be broken into by events. Function modules can be invoked and terminated by sequences and events. Function modules can always be linked to visualization objects. In this way an observer can, for example, observe the correct function of a controller. He can analyze courses of curves in a trend graphic.
It can be seen that this classification greatly facilitates the development of the automation task, especially as the event modules and the function modules are automatically placed in the module window upon the choice of visualization objects. If the program start and program end are left aside as obvious, the user only has to be concerned with the choice of the sequence modules.
In further embodiment of the invention it is provided to assign a symbolic figure to each of the sequence, event and function modules. These symbolic figures should be clearly distinct from one another. In conjunction with chaining, which is described further on, they make it easy for the user to recognize the structure of his automation task. If the user pulls a module from the library into the module window, the module will manifest itself as a symbolic figure on the screen surface of the module window. Other modules, as already described, are automatically exhibited when the corresponding visualization object is exhibited. The user can arrange the figures on the screen as he would like to shape the sequence as illustrated in
A further feature of the invention provides that the modules are graphically connected or chained to one another by lines. Such chaining is depicted and described in
A great part of the development work has already been performed without special knowledge being demanded for the purpose. The user can concentrate fully on his process that he would like to automate. What now has to be done in the further development work is to give to the modules the properties needed for the specific automation task.
In a further embodiment of the invention, the module configuration screen opens to the user by marking the symbolic figure of a control module in the module window and, for example, by double-clicking on the marked figure. There he will find, depending on the module type, a program skeleton or input dialogs (similar to forms). In the case of modules that perform standard tasks, such as controllers, he will find input dialogs that enable him to parameterize the module. In the case of other modules such as sequences and events, he will find a program skeleton.
Although this code is a script language, the user need not learn the language. Further features of the invention serve this purpose. In the program skeletons he finds keywords specially emphasized, for example by underscoring. His task is then to replace these keywords by further keywords, program code, variables and constants. This occurs in that he clicks on the keyword. A knowledge list then opens. From this knowledge list he chooses a list item, which replaces the keyword. How this is achieved in practice is described in an example. Configuration of the module is finished when all underscored keywords have been replaced by program code, variables and constants.
The following example of an event module that controls a digital display instrument with the individual name “TempDisplay” will make this clear. The digital display device is assigned the task of continuously displaying the value of the analog channel with the name “TempSensor.” All that the user must do is to select the variable “TempSensor” from the knowledge list “AnalogChannels.” The following code appears in the configuration window:
According to the invention, the program code knows only two categories of instructions. These are queries and actions. The program code is thus very easy to read, as shown by the following example:
The query category contains the instruction “If TYPE [logical operation] then” with the options “If now but not previously then” and “If not then.” This instruction, indeed, contains the command “IF then else,” known per se. The instruction according to the invention is inventive because, with the optional instruction “If now but not previously then,” it contains the possibility of detecting exactly the point in time at which the event arose. Thus the “If [ ] then” construct expands to new dimensions by further facilitating the user's development of his application.
The known programming languages are text-based. This means that a user will type in the commands that he is newly formulating except for those that he copies from another text region. These steps are time-consuming and error-prone. There is thus a danger of syntax errors. The invention takes a quite novel route in that the script is graphically oriented. The individual components of the script, such as keywords, instructions, variables, constants—in short, script objects—are graphical objects. These graphical objects are in part the subject of the program skeletons of the individual modules. Also, as previously described, further script objects can be taken from the knowledge or library lists and inserted into the script via keywords. The script objects are arranged in line-oriented fashion, so that the graphical script does not look much different from a text-based script. The advantages are obvious because handling is easier. It is further possible to append image-oriented symbols to the text-oriented script objects, so that the language can be still further simplified.
The constant 100 appears in the instruction “Query: If AnalogInput [AnalogInput TempSensor>100] then.” The user must be given the opportunity to create a graphical object that includes the value of a constant. This can be implemented in a simple way with “pop-up menus.”
For the further explanation of the invention, reference is made to the simplified depictions of exemplary embodiments in the drawings, in which:
Referring to
In
The screen 11 makes it possible to install and configure visualization objects on the screen in development mode. This is the first step toward development of an application. The library of visualization objects is available for installation. When an object is selected, it is depicted as a graphical object on the screen 11 and the screen 14. An object is selected when an individual name has been given to it. Now the individual objects can be configured through adaptation of their object properties. Object properties are size, coloration, text, and status such as on/off.
The module window 12 enables the user to install, arrange and link control modules during development. The user can pass from the individual module objects into the configuration window 13 and configure the individual modules. This is the second step toward development of an application. By double-clicking on the geometric figure of a control module, configuration window 13 opens and the previously prepared program skeletons, depending on the module chosen, appear. Standard functions such as controllers are configured via input masks. In the case of modules that are represented by a module skeleton in the configuration window 13, the module skeleton is supplemented, subject to specified rules, into functionally finished modules.
When the individual modules are configured, the third step toward development of the application follows. The individual modules are appropriately arranged in the module window 12 and graphically connected to one another according to specified rules, as is necessitated by the automation task.
The following description, with
In
The function corresponding to
The sequence of the automation task in runtime mode begins when button 22, “StartButton,” is pressed. The program waits until this button is pressed. This occurs by double-clicking on visualization object 22, “StartButton.” The program continues when this has occurred. Now “ValveA” 16 is opened for 15 seconds and “ValveB” 17 for 20 seconds by the digital outputs of the measurement and control unit. Lamp 23 “OperationOn” is turned on, and a waiting time of 25 seconds commences. In this way the tank of the reactor is charged with the desired liquid media.
The visualization object 25 “SetpointSpec” of Profile type this supplies the time-controlled setpoint for the on/off controller with the name “TempController” 26 of OnOffController type. The function module “SetpointSpec” 25 of Profile type is configured as follows: During one hour the temperature is warmed up from 20° C. to 100° C. During a further hour the temperature is held at 100° C. During a further hour the temperature cools down to 20° C. Function module “SetpointSpec” 25 supplies the setpoint for “TempController” 26. The task of “TempController” 26 is to control the liquid temperature according to the setpoint “SetpointSpec” 25 so that the temperature correctly tracks the temporal sequence provided. The visualization object of“SetpointSpec” 25 shows, with its two curves, the temporal sequence of the setpoint and of the actual value. In this way, an observer has the opportunity to monitor the correct sequence of the experiment.
Function module “TempController” 26 of OnOffController type controls the liquid temperature according to the setpoint specified by function module “SetpointSpec” 25 of Profile type, with the aid of temperature sensor “TempSensor” 19 and of the digital output of the measurement and control unit with the name “Heater” 21. Concurrently with function module “SetpointSpec” 25 and of “TempController” 26, the function module of Measurement type with the name “Trend” is invoked. This is not depicted as a visualization object in the diagram of
When the time of three hours of function module “SetpointSpec” 10 has elapsed, the temperature of the liquid is cooled to ambient temperature under setpoint control. The digital output of the measurement and control unit “Drain” assigned to valve 18 now opens valve “Drain” 18, so that the tank of the reactor vessel is emptied. The program is then terminated.
The visualization object “DigitalDisplay” 24 of DigitalDisplay type works separately from the previous proceeding. It is the event module, whose task is to display cyclically the liquid temperature in “DigitalDisplay” 24. A shutdown event is assigned to the visualization object “Malfunction” 27 of SignalLamp type and the function is next described. The temperature sensing element “TempSafety” 20 is provided on grounds of safety. A test is automatically performed cyclically to determine whether the measured values of temperature sensing elements “TempSensor” 19 and “TempSafety” 20 differ from each other by not more than 2° C. If the temperature difference becomes larger, a shutdown is initiated. If the temperature difference becomes larger, it can be inferred that the temperature measurement of one of the two paths is in a malfunctioning condition. A further shutdown is initiated if the liquid temperature exceeds a value of 120° C., for example because the control action of “TempController” 26 has gotten out of control. When the shutdown event arises, malfunction lamp 27 is turned on, “Heater” 21 is turned off, and valve “Drain” 18 is opened for approximately 50 seconds so that the tank is emptied. The program is terminated afterward.
If a user has exhibited the diagram according to
In
The function corresponding to
In
On the basis of sequence module “Control” 2 of
The tasks that sequence module “Control” 2 of
In order to carry out a configuration, a configuration window 3 is provided as shown in
The keyword StepProcedure is automatically inserted after Endstep in order to facilitate the installation of a further step procedure.
The keyword was replaced by Step “Button.” A user will clear the lines that he does not need. An action instruction is not needed, because all that is waited for is the button press; afterward the program continues at the next step. The user will therefore clear the line in which Action appears. Window 13 then shows:
Next the two keywords Name and Yes/No in the above display must be replaced. The knowledge list for the keyword Name contains the individual names of the visualization objects that have been selected for the task in question (
StartButton is chosen. The knowledge list Yes/No contains a plurality of terms that represent logical 1 and logical 0. Such as:
The sequence module “Control” now appears in Windows 13 as follows.
The first step is thus finally configured. Now the second, and thus last, step must be configured.
All actions to be executed in step 2 are listed in order. No (If [ ] then) queries are necessary. The following listed activities of step 2 are all actions.
The keyword StepProcedure must now be replaced with:
The list item StandardStep is chosen. StandardStep now replaces the keyword StepProcedure. Window 13 shows:
Because queries are not needed, the user will clear these lines. He knows that eight actions are necessary; he will thus provide eight Action lines by inserting lines as follows:
The first action of step 2 is open “ValveA” 1 of
The list item SetDigitalOutput [DigitalOutputName=H/L] is chosen. “ValveA” is chosen for DigitalOutputName. The configuration window will show:
For the keyword H/L, the following items are available from the knowledge list H/L:
The list item Open for (?) sec. is chosen. For (?), 15 is substituted. The window shows:
The opening of ValveB for 20 sec. is done in the same way.
All further actions are configured in the same way. Function modules are invoked with Run [TYPE ModuleName]. The type of the module, Profile, OnOffController, Measurement is selected from the knowledge list TYPE. The individual names of the modules “SetpointSpec,” “TempController,” “Trend” are chosen from the knowledge list ModuleNames.
Because no further step is necessary, the keyword StepProcedure is cleared.
Hence the completely configured sequence module “Control” has the following appearance:
The example can be extended in a variety of ways and formulated variously without new inventive ideas being needful. For example, data such as opening times of the valves can be taken from input lists. One could provide an additional StopButton in a simple way. Thus the experiment could be manually terminated at any time.
In
The system function corresponding to
The task of a measurement and control unit 49 is to acquire the signals of various sensors and transform them into physical quantities such as temperatures, pressures, flow rates, rotation speeds, velocities. Further, circuit input data can be acquired, for example whether a machine is turned on or off, whether valves are open or closed, and other information. The process underlying the application can be controlled in the desired fashion via logical outputs and analog outputs of measurement and the control unit 49. Further, measurement and output devices such as scales, large-scale displays can be integrated into the automation process through standardized data ports. In the case of simple applications, the measurement and control unit 49 can also be fashioned as plug-in boards in a data processing device 50.
The data processing device 50 serves as man/machine interface and hosts the control software. Cable connections 51, depicted schematically, bring about the connections between the sensors and actuators of the process. A data connection 52 is a standardized port, for example Ethernet, via which measurement and control unit 49 and the data processing device 50 can be integrated into larger data networks.
| Number | Date | Country | Kind |
|---|---|---|---|
| 02008464 | Apr 2002 | EP | regional |
| Number | Name | Date | Kind |
|---|---|---|---|
| 5878040 | Peirce | Mar 1999 | A |
| 5893105 | MacLennan | Apr 1999 | A |
| 5913028 | Wang | Jun 1999 | A |
| 5918020 | Blackard | Jun 1999 | A |
| 6157649 | Peirce | Dec 2000 | A |
| 6226555 | Kallal et al. | May 2001 | B1 |
| 6298377 | Hartikainen | Oct 2001 | B1 |
| 6317701 | Pyotsia et al. | Nov 2001 | B1 |
| 6321272 | Swales | Nov 2001 | B1 |
| 6343083 | Mendelson | Jan 2002 | B1 |
| 6370448 | Eryurek | Apr 2002 | B1 |
| 6370683 | Sobers | Apr 2002 | B1 |
| 6397114 | Eryurek | May 2002 | B1 |
| 6532392 | Eryurek | Mar 2003 | B1 |
| 6735764 | Nakai | May 2004 | B2 |
| 6754540 | McFarland et al. | Jun 2004 | B1 |
| 6865729 | McMillan et al. | Mar 2005 | B1 |
| 6965800 | Schmit et al. | Nov 2005 | B2 |
| 7146231 | Schleiss et al. | Dec 2006 | B2 |
| 7317959 | Pfander et al. | Jan 2008 | B2 |
| 20020054099 | Schmitt et al. | May 2002 | A1 |
| 20030130752 | Gasiorek et al. | Jul 2003 | A1 |
| 20030167096 | Nakai | Sep 2003 | A1 |
| 20060206866 | Eldrige et al. | Sep 2006 | A1 |
| Number | Date | Country |
|---|---|---|
| 0413044 | Aug 1989 | EP |
| Number | Date | Country | |
|---|---|---|---|
| 20030200004 A1 | Oct 2003 | US |
