Patent Application
20130041479
1. Field of the Invention
The present invention relates to industrial control apparatus and methods and to the manner in which such apparatus and methods may be utilized for more efficient industrial production. More specifically, the present invention relates to graphical user interfaces and computerized systems for industrial control and manufacture. The invention also relates to those apparatus and methods that may be used for numerous other automation opportunities including laboratory sample handling, paint and plastic spray automation and most routine logic control functions. Significantly, the present inventions provide unique opportunities for large savings in energy during chemical processing.
2. Background Art
Many factory PLC-type control systems are available in the market but nearly all of them have a critical defect, lack of flexibility. They are intended to work optimally when configured and programmed for specific tasks; alterations of the steps in the tasks (the “Recipe”) generally demand modifications of the program and/or the electromechanical configuration. Such changes are typically the province of specialists, who are frequently engineers and electricians, and are not commonly achievable by routine factory workers. Frequently however, manufactures require, or at least would prefer, a flexible control system so that they can reconfigure quickly and easily for a range of unanticipated needs. For example, a chemical producer manufacturing one type of cosmetic may have the opportunity to produce a new product, but one that requires a different sequence of steps and even additional features such as more pumps and tanks into which to direct ingredients, in-process mixes or finished products. Such a change of recipe, if it could be done with existing non-specialized, staff would be of great commercial value to the factory.
Thus, modern industrial manufactures depend on computerized control systems. A typical computerized control system contains a controller responsible for reading information from devices, sending information to devices and other system operations; and a GUI to show information of devices and system statuses to users and to provide operations of these devices. Some automation control systems also provide methods to run automation process. For example, a typical PLC system contains a PLC, as a controller and an HMI as a GUI. The user can control devices from the HMI and get some information such as speed of motors, temperature, etc. However, depending on different industrial environments, different types of manufactures, different devices and different controllers, control systems are usually quite different. Users cannot find a universal control system to fit most of the controllers and devices in the market. If a chemical plant has one hundred tanks, each of them has a PLC, and the user needs to write one hundred HMI programs.
Another issue is that a controller is designed for a particular GUI and automation process. Also using the example of a PLC, one HMI program designed for a specific model of PLC, such as, for example the Allen-Bradley SLC-504, cannot run simply at another model of PLC, such as, for example, the Siemens S7-200. Because the controller is responsible for running automation process and dealing with conditions, subroutines, etc, the automation process depends very heavily on the controller. If a chemical plant has three kinds of PLC, for each automation process, three different recipes must be written. Assuming the plant has three hundred different process, there will be nine hundred different recipes. This situation is fraught with difficulty.
Recently the PAC (Programmable Automation Controller) provides a computer based control system and allows the user to write his own automation process program. However, PAC's lack flexibility and simplicity. One issue is that user must learn how to write such programs; to some degree, it is similar to Ladder Logic. Another issue is the control system is always designed for a specific controller, so these programs are very difficult to run on other controllers.
Even if the problems mentioned above are overcome, it is often difficult for a chemical or other production facility to properly schedule and supervise a particular production run, or even more significantly, numerous production runs for a variety of customers. Raw materials, equipment and personnel must all be available at the right time. Further, the production process must be monitored, and information must often be supplied to customers to assure them that the products they need, will be available on time.
Often, it is difficult for factory personnel or even engineers to conceive of the manner in which such control systems should be designed and set up. It would be useful if plant configuration could be made available to a remote location so that a central design facility could acquire the information and propose solutions.
Finally, while some chemical processing facilities are associated with large companies, the majority are associated with small businesses. The United States Department of Labor web site, in March of 2006, indicated that nearly eighty percent of chemical manufacturing jobs are in businesses having fewer than fifty employees. When the fact is considered that most jobs are created by small businesses, especially in the United States, there is a tremendous potential for creating a large number of new jobs, if small businesses can keep costs under control by utilizing efficient automation to offset otherwise rising costs due to possibly higher taxes and an increasing morass of government regulations and mandates.
The present invention relates to various aspects for control systems and automation processes.
In one aspect of the invention, a new computerized method allows a user to control different systems in universal software.
In another aspect of the invention, this computerized method allows a user to edit their own automation processes and run them on different systems.
These objectives and many others are achieved in accordance with the invention by reference to the description and claims set forth below.
The foregoing aspects and other features of the present invention are explained in the following description, taken in connection with the accompanying drawings, wherein:
Although the present invention will be described with reference to the embodiments shown in the drawings, it should be understood that the present invention can be embodied in many alternate forms of embodiments. In addition, any suitable size types of elements or materials could be used.
The description below is divided into five sections. The first section, entitled Overview, presents aspects of the control system during routine use. The second section, entitled, Architecture, presents detailed information about the processing and computations that underlie the inventions. The third section, entitled Implementation, presents detailed examples of several embodiments of the subject matter mentioned in the Principles section. The fourth section, entitled applications, presents disparate examples of the utility of the devices enabled by the methods of the application section. The fifth section, entitled Supervisor Scheduler, presents methods of conveniently scheduling and observing the embodiments of the prior four sections.
In the following description, numerous details are set forth to provide a more thorough explanation of the present invention. Because the present invention is universal and can be applied to various kinds of environments and systems, in the description below an example in chemical manufacture is presented to demonstrate the operation of the system. By universal is meant that the computer program in the PC is able to work with a wide suite of controllers ranging from PLC devices of most manufacture, to Field IO products, to Data Acquisition Boards, to specialized process chips, e.g. the Arduino chip.
The program that is the basis of the invention is called “the UDI” or the “UDI Program”. This name evolved from the initial hardware embodiment, called “the DART”. As it developed that multiple processors, not just the one first tried, could be enabled in the DART, and that these embodiments used virtually the same PC software, the name Universal DART Interface or UDI became synonymous with the operational code.
After the software is started on a computer (
Since a single computer may control multiple process tanks, Screen 100 includes a top bar 102 for displaying a list of systems or process tanks being controlled. In this case names PC-67, PC-68, PC-100 refer to Process Control units 67, 68 and 100. These tanks may not be contiguous with one another, though it is generally preferable for the operating PC to be in the vicinity of a tank being controlled. The particular system is selected by overlaying the mouse and clicking. A system status box 104 displays the status of the system being monitored or programmed. A recipe control box 106 can be used to load a recipe for a particular process to be performed in the processing tank, as represented by tank 120. Indeed, the situation depicted in
The process according to this recipe can be started, stopped, or a next recipe loaded by the various controls in control box 106. A heating control box 108 allows the tank represented by 120 and its contents to be heated by an appropriate heater (not shown). Heating may be started, stopped, the temperature set, and control may be changed between an automatic mode and a manual mode. A system dashboard 110, allows monitoring of various system parameters, as described below. An overall process monitor section 112 displays process or recipe name, status, running time and percentage of completion.
The representation of the tank 120 and its associated system controls include icons for four variable frequency drives (the two Tree units having only states of off, low or high), and eight valves. This suite of devices is a representation of the automated controls at unit PC-67. In general, every process tank will have its own unique set of devices and the representation shown on the screen will reflect the particular devices associated with the tank.
The variable frequency drives include those for a sweep 123 for sweeping material from the tank wall 124, and a mixer 128 for homogenizing the material being processed in the tank. A sweep 123 typically includes a member in contact with the tank wall and disposed parallel to the longitudinal axis of the tank for scraping material off the tank wall. Variable frequency drives may also be used to control motors for driving devices such as agitator baskets, propellers, or tree structures, or any other device that mixes the contents of the tank.
A tank drain valve 132 controls draining of tank 120 for purposes of cleaning or removing finished material at the end of a process in accordance with a recipe. The additional valves, including SteamIn and SteamOut, WaterIn and WaterOut and Vacuum and Purge are used for thermal regulation insider the tank jacket.
There is an additional feature that is apparent in
During operation in manual mode if any option other than off is selected with the appropriate radio button 202, 204 or 206, the icon for left tree input 122 will change color; for example turn from red to green. When the recipe is run and the state of the device such as the LeftTree changes from off to on, the corresponding icon changes color from red to green.
More complex decision-making is possible, beyond that of two speed motors as shown in
Referring to
While not specifically illustrated herein, it will be understood that, where necessary, DC motors may be controlled with a similar dialog box, but the details of what is being controlled will vary due to the markedly different nature of the motor.
Referring to
It will be understood that the portion of the system interfaced as in
The Command is to run an operation with a value on a system's device. For example, to open PC-1's Steam In, system=PC-1, device=Steam In, operation=Open, value=null. Another example, to set PC-1's Sweep's frequency to 100, system=PC-1, device=Sweep, operation=SetFrequency, value=100
2. Time Span Command, to Wait Some Period, when it Starts Executing.
Parameters: days, hours, minutes, seconds, such as 5 days, 6 hours, 3 minutes, 1 second
Parameters: system, dynamic controller, PC-1's HeatingControl
Parameter: message, “Hello World”
The system described above offers many opportunities for significant savings of energy by monitoring energy being used during every step of an industrial process, and optimization of the process. For example, the viscosity of a material in the process tank may be accurately inferred from the amount of power needed to drive a mixing motor. Monitoring of the drive voltage and current being drawn is one approach to making this measurement. As an alternative, motor shaft torque may be measured by any of several well-known techniques, and equated to power being expended. The power being supplied to a heater to heat the tank, or to a storage vessel for raw materials to heat those materials prior to their being introduced into the tank, may also be monitored. For example, this could be anything from a slow ramp of temperature versus a fast ramp; to a “process at 62° C. for 10 minutes rather than 60° C. for 15 minutes” (assuming similar product quality). Another aspect of a process that may be monitored is the issue of mechanical repeatability or reliability. For example, with the use of an active database that intelligently records these parameters, and data logging, a particular step is monitored, and a determination may be made as to whether it take more or less power than it did during previous runs. In general, most of the energy usage is read by meters based on electrical use; but hot water, compressed air, etc. energy demands can be calculated based on flow rates, temperatures etc. The amount of power used may be integrated over time to determine total energy expended for a step in the process, or for a portion of a step in the process over a time period smaller than the total time needed to perform that step.
Thus, instantaneous values of parameters related to energy consumption my be displayed on the dashboard 110, as described above, and as a function of time, as described with respect to
To better appreciate the simplicity of the application,
On the right hand side is a list of devices in PC-1, a particular system. These devices are depicted by name, written as text, in this embodiment. But it should be understood that alternative representations are also intended. One such embodiment would use iconic-images listed in a sequence much as the text is in
Moving from
The choice of which items to include and their set points; the choice of the sequence of use; the duration; in fact of any part of the batch procedure is well within the ability of a typical user to grasp intuitively, quickly and enduringly. Hence, the UDI Program method is shown to be capable of enabling even those untrained in the art of automation programming to be usable virtually at once.
To most precisely grasp the scope of the invention, key words are defined as follows:
When the information in either the Core 601 or Automation Scheme 602 changes, push notifications are pushed to the Graphical User Interface 600 to update the information on the interface. In other words, something such as a change in the temperature reading or the progression to the next line in the recipe is seen on the Graphical User Interface. Symmetrically, operations initiated by the user on the Graphical User Interface can pass to the Core 601 and Automation Scheme 602 as commands to execute.
The UDI Program 603 communicates with Controller Programs 604 by messages 606 using message queue, an operating system level service. In turn the Controller Program 604 talks to a Controller, which as described above can be a PLC or a Field I/O. The program 603 also sends command messages 606 to operate devices or inquire value of devices via a Controller Program 604. Additionally, Controller Programs 604 send notification messages 606957 (
The program 603 can communicate with different kinds of Analyzer Programs 605 to implement analyzing functions. The program 603 sends command message 606 to analyzer programs 605 to analyze the product and analyzer programs 605 send messages 606 back to the program 603 reporting the analyzing result or the action after analysis. Communication with real analyzers is show by the arrows between the Core 601 and the Analyzer Program 605. These can indicate, for example that the Core 601, having been told by the Automation Scheme to turn on the analyzer does so. An interesting application occurs when the analyzer, sensing that a part of the process is complete, reports this information to the Core 601, which in turn can direct the Controller Program 604 to modify a procedure or to advance to the next step.
It is emphasized that the identification of the Automation Scheme with the recipe in a batch chemical manufacturing procedure is but one embodiment of the general invention. Another is the use in Laboratory Automation, wherein a protocol for making, for example a series of dilutions on sample materials and then performing measurements is made possible with a similarly flexible approach of selecting instructions in whatever order is needed.
Referring to
The System Manager 703 stores all necessary information such as details of the devices and where they are connected in the controller hardware of individual systems 800 which correspond to the real system 808. Each system 800 contains a device list containing devices 801 which corresponding to the real device 807. While it might appear that the number of controllers should equal the number of systems, this is not generally necessary. A system can use multiple controllers to control devices; or one controller may operate multiple systems.
A Process means a program that is running on a computer. Upon start of the execution of the UDI Program 603, the process needs to initialize itself from configuration files that are typically stored locally, for example on the hard disk. This requirement for initialization from stored files is a consequence of the flexibility of the UDI Program 603. System components are customized by users in, for example the chemical manufacturing industry, to address numerous variations such as number and types of valves or motors, a variability that must be represented and expressed concretely in the UDI Program 603. In fact, variability resides not only in the components but also in the graphical layout, which is a user adjustable feature of the way the system is represented.
Returning to the controllers, each of these must be initialized in an orderly and comprehensive way, meaning that for each controller, all data must be ready for use at initialization so that the UDI Program 603 can then run properly with all variables properly accounted for. There is back and forth communication between the program 603 and controller programs 604 to make sure they are initializing in a correct order.
This activity, shown in 902, is explained further in
After the main program 603 receives all initialization-done messages from each controller program 604 at 902, at 903, it uses the second part of the main configuration file to initialize the System Manager 703 at 953 (
The initialization of the system manager at 903 means that the variables (the parameters associated with ports), as described above, are read into memory. During initialization at 903 the program 603 sends a registration message to controller programs 604 to subscribe to the update notification from the controller programs at 954 (
Once the system manager completes initialization, the other managers also initialize one by one. The Macro Manager 702 uses its own configuration file to initialize at 904. The Macro Manager configuration file contains all user pre-defined macros, which can help the user do a series of actions in one command. For example, some tanks need to be drained of water before they are heated. The drain algorithm might be: open drain valve for 5 seconds then open air purge for 2 minutes then close both of them. The macro takes the above actions and then starts the heating action together as one command to execute, which makes for user convenience. The Emergency Manager initializes at 805 with its own configuration file, storing it into memory. The Emergency Manager configuration file contains all user pre-defined emergency conditions and the corresponding required responses. An example of an emergency condition/response if/then statement is “IF steam in valve AND water in valve are open at the same time, THEN close all steam and water valves”.
When all configuration files have been read into memory, all information is stored in the Core 601. Then the program 603 sends message to all controller programs saying they can begin to refresh their port tables to renew the value of all ports continuously at 906, 956 (
After the Core 601 is finished reading all the configuration files, the graphical user interface reads UI configuration files to make a cartoon of the system schematic. This graphic contains a visual expression of the system, including the size and location of each device 907.
The last step is to initialize the automation scheme at 908, which may in one instance be a chemical batch manufacturing function and in another a laboratory automation procedure. These are different schemes in the sense that they are totally distinct activities. Necessarily different automation schemes will have their own initialization, possessing specialized hardware and functionality.
If a disruption such as a power failure occurs during a recipe run, the recipe is halted, but the temporary data storage file remains on the hard disk. Thus, the first step of recipe system's initialization is a search for temporary files or unfinished recipes at 1000. If none are found, the initialization is complete. However, if at least one is found, it will prompt the user for to decide on a course of action: discard at 1001, meaning delete the temporary files and ignore the last unfinished recipes; load unfinished recipes at 1002, into system and show them on the screen without further action; or after loading recipes, continue the recipe run from the step recorded as the current step in the temporary file.
Conceptually, the program can be considered to divide into two parts, the first being the user interface and the second the inner workings that enable the intended actions. Both of these parts enjoy a measure of generality, as follows. To understand this readily, begin from the affected end, for example a steam valve. This device is addressed by a controller, which can be a PLC of specific manufacture. Perhaps the steam valve is connected to the address N10:4/3 on the PLC. In routine operation, the PLC would have a configuration file that links this channel to the steam valve. In the UDI Program, identification of this location is associated with a given name such as PC-1_SteamIn_Switch so that this name and the channel are linked. Additionally, a controller is identified in the UDI Program with a specified name such as ABDF1RS232. Since the PC-1_SteamIn_Switch is identified with a physical location this name is the tag that the UDI Program has (the mapping) to the channel on the controller.
What is needed then is the communication protocol for the controller, the method that the controller uses to access this channel. That is a key part of the controller program. The generality of the UDI Program depends on using the precise communication protocol for the specific controller. In the example, a PLC was used. But there are numerous different manufacturers and models; also there are numerous alternative controllers. However, the strategy of linking a physical address with a variable name and then passing an instruction to a specific channel is the same.
The User Interface is also generalizable, but in this case it is according to language. Consider how the UI connects to the execution layer, how it maps an icon to a physical location on a controller. This is done by linking the name, for example PC-1_SteamIn_Switch to a user assigned name. While logically, the user would typically select a name with the word steam, there might be reasons to do otherwise, as when the user refers to steam in a different language. The designation then can be to a dummy variable, say D1, which is a placeholder for the string that is shown on the user interface. Here it is meant to point to the first entry in a row 1 of a list of UI text variables. Similarly, a second icon, linked to another channel would be D2, and so on. In fact, all of columnl are in the same language. A user may then create a matrix, adding other languages or symbols. Logically, then column 2 would be a parallel set of names, but in a different language. This method is employable for as many languages as desired. At the time that the actual text is used, the only needed specification to determine which language is selected is the column number. In this system a simple click on the keyboard, ALT F #, enables instant change of language.
To show the wide-ranging applicability of the UDI concept, four different computational devices, or “engines”, are selected as examples and shown in Table 1. These four are a microcontroller, a PLC, a data acquisition board (DAQ) and a Field I/O. In particular, an Arduino, an open-source platform (http://www.arduino.cc/) was used to represent the microcontroller; an Allen-Bradley model 1500, the PLC; an Ontrak control board, e.g. the ADR 2100, (Ontrak Control Systems Inc, Sudbury, Ontario, Canada), for the DAQ; and an Applied Automation XXX (Bridgend, UK) for the Field I/O. These are selected examples and should not be considered limitations of the invention.
The manner of illustration is by the selection of four types of i/o commonly used in automation: digital input and digital output; analog read and analog write. The specific elements chosen are illustrated in Table 1.
Each of the engines will be illustrated to operate all four i/o devices. To do so, three actions must be addressed: physical connection; software connection; and mapping.
The subsequent sections provide the detailed explanation for multiple embodiments of the invention.
What is common to all of these engines is the GUI that a user may choose at the PC. For many practical applications the specific engine chosen will be transparent to the user, meaning that from an operational viewpoint (from the perspective of actually doing the automation), the user may be unaware of which engine had been selected. This versatility has multiple advantages.
First of all, when selecting the components for a DART, a prospective user may take advantage of cost and size. Thus, as will be shown later in this specification, laboratory-scale automation may be affected using low-cost micro-controllers. Alternatively, confidence or experience with one or another type of engine, for example a PLC, may prompt selection of that means of control.
Secondly, the ability to retrofit UDI technology to engines such as PLCs and Field I/O devices in the field is a very practical matter. The advantage of simplified recipe-making or other perceived value offers to prospective adopters of UDI technology the very real and practical opportunity to do field-upgrading.
In the discussion below the conceptual interchangeability of the engines is shown explicitly.
3.1 Physical Connections: this is to Describe all of the Physical Wiring Connections Between Components.
The 12V Solenoid valve requires a 12V DC voltage to operate. When it gets +12V across its terminals it opens, when it gets 0V across its terminals it is closed. The terminals of the 12V solenoid valve are connected to the output terminals of the 12V relay. When the relay 12V receives +5V across its input terminals it outputs +12V across its output terminals. When it receives 0V across its input terminals it outputs 0V across its output terminals.
The water fill level limit switch is a 12V sensor. When the water fill level is at maximum, the limit switch will trigger. When the limit switch is triggered it will output +12V across its output terminals. When the limit switch is not active it will output 0V across its output terminals.
The analog thermocouple is a passive device that generates voltage according to the temperature it senses.
The DC motor is a motor which supports voltages from 0-36V DC input. The speed of the motor will depend on the voltage applied to its terminals. When it receives 0V it will be stopped. When it receives 36V it will operate at maximum speed. Square waves with different duty cycles are illustrated in
Pin 1 is set to be a digital output pin.
Pin 2 is set to be a digital input pin.
Pin 3 is set to be a Analog output pin.
Pin 16 is set to be a Analog input pin.
Serial Communication at 9600 bps is set on the USB port.
Sample list of protocol and connection types.
The communication software on the Arduino is set up in two parts. One is to read from the pins, the other is to write from the pins. Each of those is in two parts, analog and digital. The 4 functions which are called to do these are:
List of some of the functions that can be applied to pins on the Arduino.
These 4 functions are called, depending on the serial input coming to the Arduino's USB port from the PC. The Arduino receives a message in serial, parses the message for commands, and then calls the appropriate function for each command. For example:
DW01H//will call the function DigitalWrite(1,HIGH)
DR02//will call the function DigitalRead(2)
AW03v255//will call the function AnalogWrite(3,255)
AR16//will call the function AnalogRead(16)
Sample commands sent to the Arduino. In the AnalogWrite function, the Arduino scales the voltage between 0V and 5V with 255 steps of accuracy. At 255 it is at a steady +5V.
The pin modes of each pin on the Arduino are sent via Serial communication to the Arduino as well. For example:
DO01//will set pin 1 to be a Digital Output
DI02//will set pin 2 to be a Digital Input
AO03//will set pin 3 to be an Analog Output
AI16//will set pin 16 to be an Analog Input
Sample header sent to the Arduino on boot. These are the first commands sent to the Arduino to initialize the pins in the correct state.
Pin O:0/0 is a digital output pin.
Pin I:0/0 a digital input pin.
Pin O:0.0 is a Analog output pin.
Pin I:0.0 is a Analog input pin.
Serial Communication at 9600 bps is set on the Serial port.
Sample list of connection types.
The communication between a computer and PLC is set by address tables. Values are written to addresses. The values written to the addresses are then transferred to the PLC using Standard Modbus Protocol.
With PLC's, the pin configuration is already settled, the pin modes do not need to be declared. The addresses that are being written to already determine the pin-mode of the address. See Table 2.
Each value for each address is written to the address within the PLC communication program. The program then updates the PLC with the values written to each address. The PC communicates with the PLC using ModBus Protocol over the Serial line. See Table 3.
The data written to the table is then continuously updated on the PLC.
On the Ontrak:
Pin PA0 is set to be a digital output.
Pin PA1 is set to be a digital input.
Pin RD0 is an analog input.
Pin PWMA is a PWM output.
Serial Communication at 9600 bps is set on the Serial Port.
Sample list of protocol and connection types.
The Ontrak board needs its pin-modes to be configured for the Digital IO. Pin-modes for Analog Input and PWM output are set by the hardware. After the controller boots up, which port is output and which port is input, must be configured.
To set and write to a digital pin as an output:
10 OPEN “COM1:9600,N,8,1,CS,DS,RS” AS#1;opens com port
20 CLS; clears screen
30 PRINT#1, “SETPA0”; sets PA0*
40 REM ;forces <cr>
50 PRINT#1, “CPA11111110”; configures PA0 as output
To set a digital Pin as an Input:
10 OPEN “COM1:9600,N,8,1,CS,DS,RS” AS#1;opens corn port
20 CLS; clears screen
30 LOCATE 1,1;locates cursor
40 PRINT#1, “CPA11111111”; configures port as input
50 REM; forces <CR>
60 PRINT#1, “RPA0”; reads PA0 (SW1)
70 INPUT#1, SW1; saves status in variable SW1
To set and read an Analog Temperature Sensor:
0 OPEN “COM1:9600,N,8,1,CS,DS,RS” AS#1; open com port
20 CLS; clear screen
30 LOCATE 1,1; locate cursor
40 PRINT#1, “RD0”; send RD0 command to ADR2100
50 INPUT#1, READING; retrieve data from ADR2100
60 TEMPERATURE=((READING/1023)*5)-2.73)*100; convert data to Celsius*
70 PRINT “Temperature is”, TEMPERATURE; display it
80 GOTO 30; repeat procedure
To set a PWM output:
10 Print#1 “TAxxxx”; Where xxxx goes from 0000 to 1024, 0000=0% and 1024=100%)
Pin DO,1 is a digital output pin.
Pin DI,10001 is a digital input pin.
Pin AO,30001 is an Analog output pin.
Pin AI,20001 is an Analog input pin.
TCP/IP Communication on the Ethernet port.
Sample list of connection types.
The communication between a computer and Field I/O is set by address tables. Values are written to addresses. The values written to the addresses are then transferred to the Field I/O using Standard Modbus Protocol.
With Field MT s, the pin configuration is already settled, we do not need to declare the pin modes. The addresses that are being written to already determine the pin mode of the address.
Each value for each address is written to the address within the Field I/O communication program. The program then updates the Field I/O with the values written to each address. The PC communicates with the Field I/O using ModBus Protocol over the Ethernet line. See Table 4.
The data written to the table is then continuously updated on the Field I/O.
The PC has three pieces of software on it, a Graphical User Interface (GUI), the UDI, and a utility program to simplify installation, the Wizard. The latter program is used for setting up the DART to run for the first time and for upgrades or modifications. The UDI with its accompanying GUI are used during normal operation.
In the absence of an existing automation system in the factory, devices of the type already mentioned, need to be installed. If there is already an automation system in the factory, the user must create an I/O map that specifies the location on the engine that drives the particular device. Usually a PLC provides only one connection to the PC. If the PLC provides multiple connections to the PC, the user needs to specify the one he is using. To control two identical devices together, a connection can be made to one channel, such as, if for example, Steam In and Steam Output would normally be operated in tandem to prevent buildup of pressure. Thus, both may be connected to DOO for joint operation.
Either way, after the user has the I/O map, he can use the Wizard,
The second step is to use the I/O configuration files to generate system structures and device information. Next the user inputs the information of every function of one specific device and specifies the port on IO configuration file to that function.
The last step is in this setup would be, in one embodiment of the invention, to make a cartoon schematic as in
The Wizard creates a configuration file that is used by the UDI and the GUI. The functions of the Wizard are:
The Wizard prompts the user for information:
The Wizard takes the information entered and generates a configuration file that is used by the UDI. The Wizard does this by comparing the data entered with a library of hardware configurations. Using the information in the library it formats the configuration file for the specific hardware it is connected to.
The libraries of the Wizard contain all of the hardware controllers with which it is compatible. Each library contains the information on how to communicate with each class of controller. The communication is in two parts. One is the physical connection between the PC and the controller, the second is the format of the commands to send to the controller. Physical connections are wired or wireless connections between the PC and the controller. Command formats are the specific characters, bits and protocols which must be used when communicating with the controller to perform some function.
The GUIB connects the UDI to the GUI using some information gathered by the Wizard. The GUIB asks the user to connect the unique name with a hardware control on the GUI. Then it asks them to input where it is physically located on the piece of equipment on which it is being used (Table 9).
Once the configuration file is fully established by the Wizard, the user can begin to automate the process using the GUI, which controls the UDI. The UDI is the translator between the commands placed in the GUI to the commands which are sent to the controller.
The UDI Program can be applied in several areas besides batch processing. Another example is laboratory automation. In a sense, this extension may be thought of as a matter of scale, as for example with automatically filling or rinsing a container that would be used in collecting a sample to be measured in a laboratory. Essentially these activities are simply a miniaturization of the procedures outlined above, requiring pumps and valves, and used in ways previously described. Characteristically, this application may be done preferentially with smaller, less expensive controllers. For example, a field programmable gate array (FPGA) or even an Arduino processor would be sufficient for these benchtop-scale procedures.
There are additional items and concerns that distinguish the method in lab applications. Consider the case of a tray of liquid samples in test tubes. The samples may be arrayed in a matrix of M×N where there are M rows and N columns. The spacing between the tubes along a row is DR and along a column is DC. A simple measurement of pH is considered. A stationary electrode can be placed over the tray, and the tray moved in the beneath the probe; when a tube is positioned, the probe is lowered. Alternatively, and preferred strictly for the purposes of discussion, the tray could be stationary and the probe manipulated in a gantry-like fashion. This gantry arm would position the electrode above the test tubes and then lower it to take the measurements.
The use of stepper motors to selectively position items is a distinguishing feature in lab automation; so too is the step-and-repeat algorithm required. In effect, a three axis CNC machine is needed in this example of the extension of UDI Programs to the laboratory. This machine allows for movement of a universal test head in the X,Y (plane of the tray) and Z directions (raising/lowering of probe). Samples may be loaded in any configuration into the sample tray. The software then allows for the variations of sample configuration and allows procedures to be built around this arbitrary configuration. The software also allows for user defined testing procedures, which can be looped or single use.
When initializing the lab version as a three axis CNC machine, the user is presented with a menu with several options to choose from: Form Factor, Recipe Creation and Macro Editor.
The form factor (FF) menu is used for configuring the software of the machine to the current state of the hardware. It asks for several pieces of information, including the aforementioned number of elements and spacing in the tray. But it also provides for special situations such as a calibration station or wash station to which the probe may retreat for calibration or cleansing between measurements and also the very nature of the probe, which may be pH or conductivity or some other needed analytic tool. The sensors that can be attached can either be micro controller based or PC based.
Recipe creation is readily described by example. Consider a pH measurement probe attached to the test head of the gantry. The recipe creation tool dynamically produces the interface according to the form factor. When the recipe creation tool is clicked the software generates an image of a grid with the same number of rows and columns indicated in the FF. It uses the spacing for the X and Y information to calculate the center of each cell. The centers of each cell are assigned the location of each sample; this location is the location the probe will be instructed to go to while testing. The X and Y offsets can be used to translate the center locations for each sample in the x and y directions so that the center of each sample is sampled. The minimum Z clearance is used to indicate how much travel the z axis must use when it is plunging the test head into the sample medium.
It is important to the success of this effort that instructions be created to enable each motor to move a specified number of steps. Thus, when the X-axis motor is prompted, a popup requests information about the number of steps, etc. This protocol is the elementary operation scheme for each motor. However, it is even more convenient to use the Macro feature of the UDI Program to combine actions of all the motors and, with knowledge of the form factor, enable simplified programming
In the recipe editor the user is presented with a graphic of the layout of the sample chambers of the machine. The user is prompted to select the cells that are to have macros run on them. Selecting the cells can be done in several ways. Users can select to add cells by the order in which they were selected, or by a sorting algorithm which will optimize the tool path to minimize the amount of distance the test head must move through. Upon selection of the cells the indication to test the cells is added to the recipe editor. Other types of manipulation to the recipe are possible through this interface. A schedule of how often to perform actions at special cells is then inserted into the recipe. For example, after every N tests on a sample the test head should move to the wash cell. These types of special actions, as well as the testing procedure itself are configured in the macro editor.
The macro editor allows for control of the testing procedure, meaning that a wide variety of implementations are possible. In the macro editor the testing procedure is defined through a graphical interface with icons that perform functions that permit looping instructions. The user is asked to create a macro and define all of the steps for it. For example, a sample test procedure can be generated to dip the test probe into a solution, run a pH test, and then move to the next cell. A sample of how a micro-recipe to test and record pH may be defined, is:
Move test head to current sample location
Move test head z axis down by half the minimum z clearance.
Activate the test head and record the value received into memory
Move test head z axis up by half the minimum z clearance
Wash test head
The example of a gantry measurement is meant to illustrate the nature of the concept. Extension to other applications such as delivery of wafers into an oven or of creating repeated small scale mixing experiments to test product formulations are included by implication.
It is commonly understood that many manufacturing processes require quality control checks while the product is being manufactured. This is frequently true in the chemical manufacturing business, where a batch may be stopped so that a sample may be drawn and then taken to a quality control lab for analysis. At the lab, the technician frequently needs to prepare the sample for analysis, using multiple standard procedures such as dilution, addition of reagents, and heating.
The UDI Program-based technology, particularly the lab automation variant is proposed as an alternative, and on-site, means of doing this analysis. One embodiment is an electrochemical measurement wherein a sample is drawn from a vessel using a tube immersed in the tank and a metering pump to draw a measured amount of chemical into a receptacle. To this sample, another metering pump adds a second fluid, either for dilution or to produce a desired chemical reaction. Next, the measurement is made. Finally, the receptacle is emptied, either by opening a valve or by drawing off the sample with a pump; a wash solution may also be used. Then this automated analyzer is ready for the next sample.
Preferentially, the entire automated analyzer may be assembled at a user's laboratory and programmed with a PC as discussed with the laboratory automation application. Upon completing the assembly and testing, the user may then disengage the PC and deliver just the controller, here considered to be a simple FPGA or even an Arduino, downloading the recipe scheme to the controller. For this application, the flexibility of reprogramming is not needed, since the lab automation device is called upon to emulate the procedure that would ordinarily be done by the technician at the quality control laboratory.
The microprocessor-based unit, now without the UDI Program-containing PC, is referred to as a compound analyzer. This transferred microprocessor-based unit is connected to the PC controlling the manufacturing process, but it serves strictly as an analyzer. The device may be connected via USB or Ethernet or serial port.
The measuring unit, as for example the electrochemical analyzer, can upload its result to the microcontroller so that, preferably only one connection between the compound analyzer and the controller operating the batch is needed. It is understood, however, the on occasion, a more complex measurement, such as that encountered in optical spectroscopy, may be required. At this time a processor, perhaps a PC is needed for the operation of the optical device. If the complex data measured in this separate PC can be processed in that same PC and a result derived, this result may then be uploaded to the microcontroller, preserving the one-connection method. An example of such simplification is the requirement to color-match a sample. The compound analyzer may have diluted the batch sample with a white base prior to the optical measurement. The PC associated with the optical unit may have in its database the specification to match and return a yes/no result to the controller.
This compound analyzer is based on the UDI Program method, modified by the laboratory automation scheme, and further simplified by the removal of the PC and use as a special function, on-site device. Further enhancing it by allowing either a switch of processors or the downloading and incorporation of multiple programs is included within the scope of the embodiments described herein.
While industrial process can be controlled using the apparatus and methods as described above, as previously stated, it is often difficult for a chemical or other production facility to properly schedule and supervise a particular production run, or even more significantly, numerous production runs for a variety of customers. Raw materials, equipment and personnel must all be available at the right time. Further, the production process must be monitored, and information must often be supplied to customers to assure them that the products they need will be available on time. A system for performing these functions is described below.
One of the purposes of the Supervisor/Scheduler is to reduce the complexity of planning where to manufacture batches. For example, some products will require vessels of a certain minimum (or maximum) size; others will need special features such as vacuum ability; and yet others will benefit from specific types of on-line analyzers. The use of a walk-through method reduces the complexity of decision making, enabling modestly trained or even untrained individuals to act in a supervisory role. Once a user has selected a type of product to be made, particularly if a similar one has already been made and is included in the database, the user is constrained by the Supervisor/Scheduler to make selections on the basis of a limited allowable set. Hence, when scheduling a product known to require vacuum processing, the user will not be offered the opportunity to consider vessels not so equipped. Similarly, when the UDI Recipe requires the product to be made with a color optical analyzer, installations properly equipped will be offered.
A fully implemented data base, then, will enable virtually anyone to schedule a batch since the choices will be simplified, reduced to where the product can actually be produced. And when features are not available, for example a color optical analyzer is needed and no vessels otherwise suitable are available with such analyzer, the user is able to order the installation of the required analyzer and modify the database to show its availability.
As will be explained below, the Supervisor/Scheduler consists of two programs. One, the LocalSS is based at the computer that controls the batch. This module provides information to the worker on-site, such information, in general having been created off-site as by a supervisor specifying the details of a production run. The supervisor, in turn, uses the WebSS, a cloud-based module to create the information in question. Additionally, the Supervisor/Scheduler in the local computer gathers relevant site information ranging from run-time parameters obtained from the controller or from analyzers and uploads these data to the cloud. Remote users then may access the cloud and obtain the desired information.
As shown in
Once the user has logged in, a server will direct the user to the respective user pages of Supervisor, Worker, and Client.
The user schedules manufacturing process with the help of walk through GUI. Walk through GUI is comprised mainly of user drop-downs and the last drop down of the GUI is noted as Nth dropdown with it value as zero (N==0) by WebSS program. This walk through allows the user to make a single choice at a time, such choice potentially affecting the range of possibility of the next choice to be made. A relational database is the backbone of this walk through process. A remote database on an independent server communicates with the local database on a 24/7 basis and categorizes all the available components. While this server may be on an Intranet arrangement to enable containment of all the data to the user's own location, the example shown here and throughout the discussion is based on the World Wide Web. Either method may be used without loss of generality of the invention.
As shown in
Editing of the manufacturing procedure may be accomplished easily with a single click. The user can just click on the icon of sweep 3001, or any of the other functional items such as tree, valves, steam 3003 etc. The step will automatically appear in the recipe editor box 3004. This is another—but separate—embodiment of the Recipe Editor. The prior version was generated at the UDI; this current method is done on at a PC connected to the Internet and not at all directly connected with the active batch manufacturing area. The procedures done are not interactive with the manufacturing site and can be done independent of whether the site is running a batch, idle or even in a nonfunctioning state. This part of the Supervisor/Scheduler is for preparing to run a batch in the future. Addition of conditions, as for example, enabling temperature, is achieved by guiding the user and providing certain pre-determined conditions/user key-in and can be observed in
Authorization and validation of the manufacturing process is done through the control shown in 3102 of
5.2 Real time System Monitoring
Monitoring of manufacturing procedure is done by clicking on any pending tasks of the pre-scheduled manufacturing table 3103. By doing so, the user will see the display of
Thus far, the user could be expected to have been a plant supervisor. This user planned the batch and observed it operating. But the login shown in
5.3 Running the Batch with the Supervisor/Scheduler
The third category of the user-triad after Supervisor and Client, is the Worker. The worker in the plant has local control from the local personal computer in the plant, as represented by
1) The local database 4401 is compared to a remote database (in the cloud 4403) and a verification is performed to check if there were any changes made overnight by a supervisor. If changes were made, the worker will see an updated manufacturing task. This update may include physical modifications required of the worker such as the selection of alternative ingredients for the batch or even the need to connect an analyzer.
2) Once these tasks are done and confirmed by the worker, the system is ready for manufacture. Generally, this means that the local personal computer is enabled to start the automated process according to the prescription of the Recipe.
Addition of new details to the categories and editing of the current pending manufacturing process is done through the editing features shown in
A general schematic of components of a Supervisor Scheduler network is shown in
Flow of information is as shown in
This layer is a general purpose layer. All layers discussed below are called by this layer, processed by this layer, and interfaced by this layer to the end user. For example, if the user needs to analyze a current batch manufacturing process with respect to data in the historical database, the user request is processed in this layer, and the results sent back to the user.
This layer ensures that all flow of information between the cloud and the local station is encrypted. This layer is controlled by an independent entity who are retained to continuously update security features so that there is no compromise in security.
The function of this layer is to assure that all video communication works smoothly as programmed by the programmer (see section on video technology below). If changes or upgrades to video communication are implemented only this layer need be changed.
The main function of this layer is to enable chat/messenger communication to operate, so that communication between the supervisor, the client and the worker are done smoothly. If any new features are developed, only this layer will need to be updated.
This layer stores all data for entire cloud, as well as data processing algorithms. The entire database is in this layer.
This layer is generally for use by customers to customize their product, i.e. this layer is used to add some external devices that are not generally part of the system described herein.
5.5.2 How Information is Transferred with the Supervisor/Scheduler
Flow of data from UDI to LocalSS and from LocalSS to WebSS is as shown in
Required data such as Recipe instruction set, authentication details, location, tanks, PC, check list that is needed by UDI are inserted by LocalSS into UDI_Message_Queue 4605 auto asynchronously. The UDI synchronously or asynchronously sends requests (query) to UDI_Message_Queue for any new data present in the queue and UDI_Message_Queue sends response to UDI (response-new data). Upon receipt of the data by UDI, UDI empties the queue.
Similarly, required recipe step number being executed; motor and valve states (on or off); motor speeds; temperature; batch run time, recipe name, tank number and estimated time for completion that is needed by LocalSS are inserted by UDI into SS_Message_Queue 4605 auto asynchronously. Local SS synchronously sends requests (query) to SS_Message_Queue for any new data present in the queue and SS_Message_Queue sends response to LocalSS (response-new data). Upon receipt of the data by LocalSS, Local SS inserts new received data from SS_Message_Queue into Local SS database and then LocalSS empties the queue.
Note that in the current embodiment both UDI and LocalSS send requests to message queue and message queue send response (update) to both UDI and LocalSS. If the response from UDI_Message_Queue and SS_Message_Queue to UDI and LocalSS is no new data or empty queue, no action is taken either by UDI or LocalSS and loop continues to execute till the program is terminated.
Required data such as run number, client name, product name, order number, due data, location, UDI, recipe instruction set, analyzer name, worker name, assigned time, notes etc that is need by LocalSS are inserted by WebSS into dbo.worker_localSS data-table 4607 (this data table is physically located in cloud database server) auto asynchronously. LocalSS synchronously sends request (query) to dbo.worker_localSS data-table for any new data present in data table and dbo.worker_localSS data table sends response (yes/no) to localSS. If response is yes, all the new parameters from dbo.worker_localSS data-table are downloaded from server and stored in localSS database.
Similarly, required data such as RTD_Temp, Recipe Name, Recipe_Status, Recipe Current Step, Recipe_finished_percentage, sweep_status, prop_status, tree_status, homogen_status, steamin_status, steam_out status, heating_setpoint, cooling_setpoint etc that is needed by WebSS are inserted by LocalSS into dbo.Tanks_values_WebSS data-table 4706 (this data-table is physically located in Local Network of Client manufacturing site) auto asynchronously. WebSS synchronously sends request (query) to dbo.Tanks_values_WebSS for any new data present in data table and dbo.Tanks_values_WebSS data table sends response (yes/no) to WebSS. If response is yes, all the new parameters from dbo.Tanks_values_WebSS are uploaded from localSS database to server.
Note that in the current embodiment both WebSS and LocalSS send requests to data-table that exits in database and data-tables send response (update) to both WebSS and LocalSS. If the response from dbo.Tanks_values_WebSS and dbo.worker_localSS to WebSS and LocalSS is no new data, no action is taken either by WebSS or LocalSS and loop continues to execute till the program is terminated.
Each database server accommodates a plurality of databases 4702 depending upon size, strength (processing speed and disk space). The expected range is a minimum of 100 databases to many thousands. Each database accommodates a plurality of data tables 4703. Each data table consists of fields where Supervisor/Scheduler information i.e. data is stored. Any new data-tables to be created or existing data table structure to be changed in databases, only that particular part of data-table can be programmed by programmers without effecting entire application. Once new changes are made, both localSS and WebSS update automatically with new changes by auto downloading/uploading new data-tables.
Note that in the current structure any new changes in future doesn't affect day to day running operations of Web-SS or Local-SS and both WebSS and LocalSS auto-update each other thereby promising 99.99% uptime.
Rights to monitor the manufacturing procedure are distributed to three classes of user, though fewer or more classifications can readily be implemented.
Referring to
Referring to
Due to day-to-day change in manufacturing procedure i.e. the same procedure for a specific day may vary in quantities and the user is able to edit the quantities or the way manufacturing instructions should run i.e. swapping instructions in manufacturing procedure. As an example, the user may make high pulp orange one day with the same instructions and another day no pulp orange juice. In this scenario, mixing instructions may need to change. This result can be achieved in the Recipe Wizard
In summary, the Supervisor Scheduler may be implemented as Web-based software running on a server accessed by the all the browsers (safari, Google chrome, Mozilla Firefox, Internet Explorer etc) of PC, Notebooks, PDA & Smartphone's to:
The Supervisor Scheduler uses twenty first century complicated communication technology and gives to the user a simple interface but is powerful in controlling the factory. The Supervisor Scheduler may have database as its backbone, which guides the user Step by Step in scheduling a task. The Scheduler allows the user to customize his screen day to day according to the present day needs, such as what gadgets the user needs to monitor today, build new gadgets etc. The Supervisor Scheduler is a 24/7 365 day approach to monitoring via WEB the local station in highly secured manner and reporting back securely to the users who are globally spread. The Supervisor Scheduler is the same whether it controls PLC, DART or PAC control system; user's will not note any difference. Even in the case of the Web being down, the Supervisor Scheduler has the ability to make the local station run without interruption and when web the is up again, its retrieves the data from local station, broadcasts globally and is synchronized automatically. Unlimited control of local stations in real time is possible.
In accordance with yet another aspect of the invention, it has been noted that the vast majority of manufacturing companies in the chemical process sector are small entities with fewer than 250 employees, and as noted above, often with less than 50 employees. One goal of the invention is to enable these small businesses to have much of the automation advantages that their large competitors can afford. Much automation technology relies on the sophisticated skills of specialized programmers and systems engineers. By reducing the need for such skilled labor, the invention allows a broader distribution of companies to benefit from the efficiencies inherent in predictable, repeatable, and auditable manufacturing.
The PC-based software operates with an intuitive structure that allows the worker to apply his fundamental factory skills, ones generally acquired by practiced manual labor, to easily generate a programmed sequence of instructions.
It should be understood that the foregoing description is only illustrative of the invention. Various alternatives and modifications can be devised by those skilled in the art without departing from the invention. Accordingly, the present invention is intended to embrace all such alternatives, modifications and variances which fall within the scope of the appended claims.
This application is a continuation-in-part of application Ser. No. 13/007,512, filed on Jan. 14, 2011, which is a continuation-in-part of application Ser. No. 12/791,778 filed on Jun. 1, 2010, which is a continuation of application Ser. No. 12/580,245 filed on Oct. 15, 2009, now abandoned, which in turn claims priority under 35 U.S.C. 119(e) from provisional application Ser. Nos. 61/105,719 and 61/105,778 which were both filed on Oct. 15, 2008. All of these documents are incorporated herein by reference, in their entireties, for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61105719 | Oct 2008 | US | |
| 61105778 | Oct 2008 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12580245 | Oct 2009 | US |
| Child | 12791778 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13007512 | Jan 2011 | US |
| Child | 13225395 | US | |
| Parent | 12791778 | Jun 2010 | US |
| Child | 13007512 | US |
