Patent Application
20110257767
The present invention relates generally to process control networks and, more particularly, to a batch display engine that obtains and displays information regarding batch processes implemented within a process plant.
Process control networks, such as those used in chemical, petroleum or other processes, generally include a centralized process controller communicatively coupled to one or more field devices which may be, for example, valve positioners, switches, sensors (such as temperature, pressure and flow rate sensors), etc. These field devices may perform physical control functions within the process plant (such as opening or closing a valve), may take measurements within the process plant for use in controlling the operation of the process plant or may perform any other desired function within the process plant. Process controllers have historically been connected to field devices via one or more analog signal lines or buses which may carry, for example, 4-20 mA (milliamp) signals to and from the field devices. In the past couple of decades or so, however, the process control industry has developed a number of standard, open, digital or combined digital and analog communication protocols such as the FOUNDATION™ FIELDBUS (hereinafter “Fieldbus”), HART®, PROFIBUS®, WORLDFIP®, Device-Net® and CAN protocols which can be used to implement communications between a controller and field devices. Generally speaking, the process controller receives signals indicative of measurements made by one or more field devices and/or other information pertaining to the field devices, uses this information to implement a typically complex control routine and generates control signals which are sent via the signal lines or buses to the field devices to thereby control the operation of the process plant.
Certain types of process control networks, such as those used in batch processes, typically include multiple sets of replicated equipment, with each set of equipment being designed to have the same or similar hardware which performs essentially the same function within the process plant. Thus, for example, a cookie manufacturing plant may have multiple sets of mixing equipment, multiple sets of baking equipment, and multiple sets of packaging equipment, with some or all of the individual mixers being capable of operating in parallel and of being connected to operate in series with some or all of the baking equipment and the packaging equipment. In such a system, it is typical to use the same general control algorithm or routine to control the operation of any particular set of replicated equipment to make the same product (as defined by a specific batch recipe). Typically, each such batch control procedure performs a number of different steps or stages in sequence, finishing the first stage before beginning the second stage and so on. Thus, in the cookie manufacturing plant described above, the batch control procedure runs a first procedure or step to control the mixing equipment, then runs a procedure to run the baking equipment on the product made by the mixing equipment and then runs a third procedure that controls the packaging equipment to package the product produced by the baking equipment, each step of which takes a finite amount of time.
Thus, generally speaking, batch processes involve subjecting raw materials to processing steps using one or more pieces of equipment to produce a “batch” of product.
Preparation of polyvinyl chloride is an example of a batch process practiced on an industrial scale wherein polyvinyl chloride is made by polymerizing or joining together much smaller molecules of vinyl chloride. This process is accomplished by filling a batch reactor to the appropriate level with a mixture of vinyl chloride, solvent and polymerization inducer, heating the mixture in the reactor, cooling the resulting batch, and purifying the batch by removing leftover starting materials. The production of polyvinyl chloride is but one example of batch process, and in general, there are many different kinds of batch processes including those used in product manufacturing, distribution, and testing as well as batch processes related to non-product uses.
One batch control standard that has been promulgated by the International Society for Measurement and Control, an international organization concerned with issues of process control, is entitled Batch Control Part 1: Models and Terminology and is often referred to as the ISA S88.01-1995 standard, or one of its updates (referred to herein as the “S88 standard”). The S88 standard defines models of equipments and procedures for use in automated batch processes, and defines certain terminology for use in referring to those models and their elements. For example, the S88 standard defines a “batch process” as a process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment. As another example, a “batch” is defined by the S88 standard as the material that is being produced or has been produced by a single execution of a batch process.
Batch processing equipment (e.g., controllable elements such as valves, heaters, mixers, etc.) is operated during a batch process or a batch run according to pre-defined procedures to make a batch. All such batch processing equipment is referred to synonymously herein as equipment, equipment modules, processing equipment, and/or physical elements. The procedures to operate such physical elements are often referred to by the S88 standard as the “procedural model.” According to the S88 standard, the procedural model is structured as a hierarchical ranking of procedures, with the highest level encompassing each of the lower levels, the next highest level encompassing each of the levels below it, and so on. The levels of the S88 procedural model of particular interest include, in descending order, “procedures,” “unit procedures,” “operations,” and “phases.” The terms “procedural element” or batch sub-procedures are used herein to refer to any embodiment or implementation of any of these levels of the S88 procedural model as well as to any other hierarchical definition of a set of batch procedures.
As indicated above, the highest-level S88 procedural element of interest is referred to as a procedure, which is made up of one or more unit procedures. Each unit procedure is or can be in turn made up of one or more operations, which are each in turn made up of one or more phases. Moreover, the S88 procedural model does not preclude the definition and use of other hierarchical levels in particular applications. Rather, the S88 standard and the procedural elements referred to herein are intended to provide a broad, standardized model for describing the procedures followed in automated batch-process control, and these elements are not limited to the four procedural elements defined by the S88 standard.
The different procedural elements of a batch are generally implemented in practice as computer programs that are executed by and within data-processing devices, including personal computers, workstations, and programmable controllers. Execution of a typical procedural element results in an electrical or optical output from the data-processing device that can be used to control a physical element, typically by connecting an output of the data-processing device to the physical element directly, or indirectly over a local-area or wide-area network. A procedural element performs an assigned or associated task by invoking “basic control” with respect to at least one physical element. This type of control is typically dedicated to establishing and maintaining a specific desired state of the physical element. Basic control would include, for example, starting or maintaining a flow of material in a storage bin element, heating the starting materials in a polyvinyl chloride reactor element, etc. In practice, the lower levels of the procedural model (namely phases) perform the actual communications with the actual physical elements, thereby invoking or performing basic control. The higher levels of the procedural model are essentially abstractions to improve the organization and the structure of the procedural model, as well as the physical model.
Moreover, many batch systems use a state machine model as a logical construct to describe the state of a batch process or activity. The state machine model describes or defines a number of process states, together with actions that cause transitions between those states. A state machine model of a process is said to be in a particular state due to an earlier transition into that state. When a particular event occurs or a particular status is sensed, the state machine model makes a transition to another state corresponding to the particular event or sensed status. State machine models are useful techniques for defining and implementing the operation of a procedural element of a batch process. In particular, a procedural element defined and implemented as a state machine initiates an action, for example, when its associated state machine makes a transition from an old state to anew state.
Of course, the S88 standard permits the definition and implementation of procedural elements in accordance with a standard state machine model. While the S88 standard does not mandate this approach, this approach has been broadly adopted in the process control industry to enable a higher degree of interoperability among the products of various vendors. One present commercial application of the S88 standard having procedural elements defined and implemented according to a state machine model is the DeltaV™ Batch product from Emerson Process Management. In DeltaV™ Batch, a server program or a batch executive program runs on the data processing device that executes the various procedural elements. The server or batch executive program coordinates execution of procedural elements in accordance with one or more state machine models so that procedures, corresponding unit procedures, corresponding operations, and corresponding phases are sequenced through their respective steps by the server program. Moreover, a batch campaign program may be used in conjunction with a user interface to set up a set of various batch processes or batch run to be run in a plant using the plant equipment. In any event, during the implementation of a particular batch run or a particular batch process, such as when a phase is initiated by the server program, the phase communicates the initiation request to the phase logic interface within a programmable controller. The programmable controller then executes the actual state logic or control routine for the phase and provides the required process control via communications to the process equipment.
As will be understood, it is desirable to gather data representative of the historical events that make up the processing of a batch run. Such historical data may be useful, for example, in determining trends in quality control or for determining when equipment used in the batch process is in need of service. A number of types of data are potentially useful in reviewing the quality or progress of a batch process. One such source of data is continuous data generated by the various data points in the batch process during the processing of the batch. A data point is a single source of such continuous data that reflects some control value or other status or measurement of the batch process. For example, a particular level of a material flow or a temperature as measured by a sensor might be one such data point. A present setting of a control valve, the time at which a sample was taken, etc. may be other data points. Each such data point may have a continuous stream of data values sensed or controlled over time by the batch process application associated therewith. The aggregation of all such continuous data, generated during processing of a batch, is often logged by a batch processing system. These log records usually include a timestamp and a present value along with other identifying information for the data point such as a tag to identify the source of the data.
Another type of data useful in reviewing the quality or progress of a batch process is event information, which relates to or includes information that describes the batch process in terms of execution of the procedural model. For example, batch events that describe the start and end time of a particular phase or a particular operation, unit procedure or procedure of the procedural model constitute event information. Event information also includes process events, including information generated by the physical elements of the batch process or by an operator. In particular each equipment module, cell, etc. of a process may generate process events that indicate one or more specific activities in the starting, stopping or running of a particular phase (i.e., performing specific basic control actions). Alarm and event conditions recognized by the process equipment are further examples of process events. Process events may also include information regarding operator changes to the batch process made during operation of the batch process.
It is most useful to integrate these various forms of event information and continuous data to provide a comprehensive, understandable presentation of such information to a user of the batch process. However, many presently available tools for reporting on batch process quality and progress fall far short of such integration. A user is generally required to perform the integration manually using a variety of disjoint tools. Further, to the limited extent present solutions provide such integration, a user is required to provide significant, detailed configuration information to permit the reporting programs to correlate the various types and sources of event information and continuous data. For example, many present tools used in batch processing gather continuous data from the batch process while other tools provide the user with a cumbersome interface to locate particular sections of interesting data. For example, a user may use an indexing tool to define a filter or trigger that locates captured data relating to a particular event or procedure in the batch process. The filter or trigger may be, for example, as simple as defining a start and end time for data relating to execution of a particular phase. In some instances, the definition may be more complex, requiring the user to identify other parameters that identify data corresponding to a particular procedural element.
In general, with these tools, the user must manually provide configuration information to define events of interest in the batch process. The access of and configuration of this information often entails a complex task for the user, requiring significant user knowledge of the events of interest and the likely characteristics of data relevant to those events of interest. Furthermore, regardless of the complexity of defining the filter for associating data with a procedural event, the process of defining such filters to associate data with batch events is a largely manual process. Essentially, using these tools, the user must enter configuration data that identifies a particular event and particular portions of continuous data associated with that event. Such manual processes are prone to error such that the relationships between event information and related continuous data may be incorrectly established. Furthermore, these tools require that the user be knowledgeable about the structure of the stored data and makes the user responsible for generating meaningful relationships among the data for their presentation. Though the query capabilities of the existing techniques may be significant, these techniques generally provide little more than a relational database “front-end” for accessing data. Such relational database management system query operations still require a user to understand the relationships among the various elements of stored data and to create therefrom meaningful queries for presentation of desired data.
Another problem with many present batch processing tools arises in the presentation of process and batch event information to a user. A batch historian program is one system that gathers and presents batch event information related to a batch processing system to a user. However, present batch historian programs generally produce tabular, textual reports from the continuous data or, at best, produce simple linear graphs of trends in elements of the continuous data. Present batch historian features of batch processing systems therefore provide limited flexibility in presentation of data to a user. For example, the relationships among batch events or process events and continuous data is difficult to discern from the tabular, textual presentations of present historian programs.
U.S. patent application Ser. No. 09/302,687, which was filed on Apr. 29, 1999 and which published as UK Patent No. GB 2,353,616, entitled “Methods and Structure for Batch Processing Event History Processing and Viewing,” the disclosure of which is hereby expressly incorporated herein by reference, discloses a batch viewing system which makes it easier for a user to view continuous batch data in relation to the various batch procedural elements or events. In particular, this patent describes a view client process that permits a user significant flexibility in viewing event information and relationships among the various events of a batch as derived by a batch history executive. Generally speaking, the view client displays the event information in a graphical manner using Gantt chart displays to represent batches and related procedural hierarchical events. The graphical user interface also allows a user to select an event so displayed to “drill down” and view lower levels of the hierarchical events that make up the selected event. A textual, tabular format presentation of hierarchically lower events that comprise the selected event are also displayed in a textual tabular format below the graphical Gantt chart presentation. This batch view enables the user to graphically view continuous data for logged data points in a manner that relates the continuous data to associated event information. However, even in this case, the view of the batch is presented in a Gantt chart, which can make it hard to understand or view an entire batch process in a manner this is useful or meaningful to a user.
Thus, as will be understood, to view the ongoing operation of a batch, it is not possible to take a simple snapshot of the batch process at any particular time and display that data to a user, as the batch process has various different procedural elements, which may be run on different equipment within the plant at different times, using different setpoints, settings, etc. Instead, to view a batch run, the user must review and analyze data from the batch at various different times related to the procedural events of the batch (i.e., the sub-procedures and sub-processes associated with the batch) to thereby be able to understand the operation of the batch run. While various batch data is typically automatically collected and stored during operating of the batch run, different types of data are generally collected by different subsystems and, in fact, may be stored in different databases. This fact makes it difficult for the operator to have a comprehensive view of any particular batch process. For example, data such as alarm data and sensor measurement data which is obtained from actual field devices such as sensors, valves, etc. within the batch process are typically stored in a data historian as time-stamped data and are available from the data historian generally based on the time at which the data was collected. However, a different database, such as one associated with the a batch executive routine, may store the start and end times of a batch run and the various different sub-procedures or procedural elements within the batch run.
Nonetheless, it can be important, and in some cases critical, that a user or an operator be able to easily view the operation of a batch in a compact manner, e.g., in a manner that does not require the user to scroll through and view massive amounts of raw data collected during the operation of the batch. In many cases, it is desirable to quickly and easily examine a batch to determine whether a given batch deviates from a noun such as that defined by a “golden batch.” Currently, the solution to this problem requires that the user monitor data related to certain process variables collected during a batch run and graph those batch parameters against a norm to understand whether the batch process is actually performing according to normal procedure or whether the batch process has deviated in a manner that makes the output of the batch inferior or is operating in a manner indicating that the batch process is no longer functioning correctly.
A data collection and viewing application within a process control system for a process plant provides a user interface that allows a user to quickly and easily examine a particular batch process or a batch run, compare separate batch runs and/or determine whether the particular batch run deviates from a norm, without having to perform a lot of manual data manipulation. In particular, the user interface provides or creates a compact graphical representation of a batch, illustrating a number of different types of batch-related data in relation to one another in a manner that enables a user to easily view or understand the operation of the batch run, either alone or as compared with one or more other batch runs.
Generally speaking, the compact batch view includes a number of graphical layers which are juxtaposed or interleaved on a display, with each of the layers providing different types of information about the operation of the batch, time synchronized with one another. If desired, abuse layer of the compact batch view may describe or indicate the duration of the batch from the start or activate time to the end or deactivate time, while different aspects of the procedural elements, steps or stages of the batch process, such as those identified by the S88 standard, may be illustrated in one or more additional layers. Moreover, alarms, alerts, events, etc. as well as other information may be placed in one or more additional layers, and the various layers may be shown together to provide a compact graphical view of the batch.
If desired, the compact graphical view may include a batch signature for a particular type of batch process or a particular batch recipe. Such a batch signature could be developed as a mathematical or statistical representation of a number of different batch runs, showing, for example, the average or expected start and/or end times of the various procedural elements, statistical times associated with various events, alarms, etc. that occur during the batch run, etc. If desired, the batch signature may be developed using one or more statistical measures of data from actual batch runs, from modeled batch runs or both.
Referring now to
Each of the workstations 14 includes a memory 20 for storing applications, such as configuration design applications, and for storing data, such as configuration data pertaining to the configuration of the process plant 16. Each of the workstations 14 also includes a processor 21 that executes one or more applications which may, among other things, enable a user to design process control routines such as batch control routines and to download those process control routines to the controller 12. Likewise, the controller 12 includes a memory 22 for storing configuration data and process control routines to be used to control the process plant 16 and includes a processor 24 that executes the process control routines to implement a process control strategy. If the controller 12 is a DeltaV Batch controller, it, in conjunction with one or more applications on one of the workstations 14, may provide a graphical depiction of the process control routines within the controller 12 to a user illustrating the control elements within the process control routine and the manner in which these control elements are configured to provide control of the process plant 16.
In the example process plant control network 10 illustrated in
As illustrated in
The valves, sensors and other equipment illustrated in
Generally speaking, the process control system of
The batch execution engine 30 is generally a high level control routine and may include what is commonly referred to as a batch campaign manager that enables a user to specify a number of batch runs to be performed within the process plant and that sets up a number of different batch runs or batch processes to operate essentially independently within the process plant control network 10. The batch execution engine 30 may also include batch executive routines or applications, that implement and oversee the different batch runs specified by the campaign manager. Each such batch run directs the operation of one or more procedures, unit procedures, operations, phases and other sub-divisions of a batch, each of which are or may be sub-routines or processes that operate on a single unit, such as one of the reactor units, the filter units, the dryer units, or other equipment within the process plant 16. In this example, each unit procedure (which is a part of a batch run that is generally run on one of the workstations 14) may perform a series of operations, each of which may perform one or more phases on a physical unit. For this discussion, the terms phases, operations, unit procedures and procedures are meant to refer to these procedural elements defined by the S88 standard and thus, a phase is the lowest level action or step performed on a unit and is typically implemented or executed in one of the controllers 12, an operation is a set of phases that performs a particular function on the unit and is typically implemented or executed on one of the workstations 14 by calling a series of phases within the controller 12, and a unit procedure is a series of one or more operations performed on a single unit and is typically implemented as a set of operation calls on one of the workstations 14. Likewise, a procedure is a set of unit procedures which may be performed on, for example, different physical units within the process plant 16. As a result, any procedure can include one or more unit procedures, and any unit procedure can include one or more phases and/or one or more operations. In this manner, each batch process performs different steps or stages (e.g., unit procedures) needed to produce a product, such as a food product, a drug, etc.
To implement different procedures, unit procedures, operations and phases for an individual batch, a batch process uses what is commonly referred to as a recipe which specifies the steps to be performed, the amounts and times associated with the steps and the order of the steps. Steps for one recipe might include, for example, filling a reactor vessel with the appropriate materials or ingredients, mixing the materials within the reactor vessel, heating the materials within the reactor vessel to a certain temperature for a certain amount of time, emptying the reactor vessel and then cleaning the reactor vessel to prepare for the next batch, running a filter to filter the output of a reactor and then running a dryer to dry the product created in the reactor vessel. Each of the series of steps associated with a different unit defines a unit procedure of the batch and the batch process will execute a different control algorithm for each one of these unit procedures. Of course, the specific materials, amounts of materials, heating temperatures and times, etc. may be different for different recipes and, consequently, these parameters may change from batch run to batch run depending on the product being manufactured or produced and the recipe being used.
As will be understood by those skilled in the art, the same phases, operations, unit procedures and procedures of a generic batch process can be implemented on each of the different reactor units of
Referring again to
Generally, each of the server nodes 44a, 44b, and 44c is a batch server having a known batch executive routine or application 52 which establishes bi-directional communication with one or more of the BOI applications 48 and/or the BDA applications 32 within the nodes 42a, 42c and 42d, and which implements and oversees one or more separate batches within the process plant at the same time. In a similar manner, the client node 44d includes a campaign manager server application 54 which establishes bi-directional communication with the CMOI applications 50 and/or the BDA applications 32 and implements the batch campaigns created using the CMOI applications 50 by interfacing or communicating with the batch executive applications 52 (using batch initiation request) within the batch server nodes 44a, 44b and 44c. The client/server architecture of
As illustrated for the batch executive application 52 in the batch server node 44b, the batch executive application 52 responds to batch initiation requests sent by the campaign manager server 54 and the BOI applications 48 to implement one or more batch runs within the process plant 16. It will be understood that the batch server 44b is communicatively connected to one or more controllers 12 which, in turn, are communicatively connected to one or more devices, units, etc. within the process plant as, for example, illustrated in
The process event server 305 and batch event server 316 may be present to provide a common inter-process communication interface between the executive 302 and its associated data sources which generate the batch events and the process events within the logs 314 and 304. Those skilled in the art will recognize however, that there are many equivalent software structures to permit the executive 302 to gather data from a variety of data sources having potentially different data formats. The embodiment shown in
In fact, if desired, an arbitrary number of data sources may be connected to the batch historian executive 302. To illustrate this concept, an other events block 340 is shown in
The executive 302 reconstructs the batch process procedural hierarchy of executed procedural events from event messages received from the batch server 312. The batch history executive 302 may generate a message when each procedural element is executed on behalf of a particular identified batch and the event information in such messages may include identification information to identify the particular procedural element and the time of the event. Events include, for example, the starting, stopping, pausing, aborting, etc. of the procedural element. Essentially, the state transitions of the procedural model of the S88 standard may cause the generation of an event information message and transmission of the message (via batch event server 316) to the executive 302. Other event messages may be related to the procedural hierarchy reconstructed by the executive 302.
The executive 302 may store objects in the database 340 reflecting the reconstructed batch process procedural execution and if desired may create a compact batch view for a batch run. The executive 302 may inspect all such gathered event information from its attached data sources and determine whether the batch events referenced therein are already known to the executive 302. Such events are known to the executive essentially when these events are found to be previously stored as objects in the database 340. Where new batch events are detected, appropriate descriptive objects may be generated and stored in the database 340. Where, for example, a phase is started, an object for that phase including identification information and timestamp information is generated and stored. If the phase relates to an operation that is already known in the database 340, those relationships are established. If the operation (or unit operation or procedure) is not presently known, then other objects may be generated and stored in the database 340 to reflect these higher levels of the procedural hierarchy execution. Receipt of each batch event message via the batch event server 316 therefore provides event information that permits the executive 302 to reconstruct the batch procedure execution.
The executive 302 may also store process events 303, received via the process event log 304 and the process event server 305, in the database 340. Relationships between the batch events and the process events may thereby automatically be created and retained without need for manual user configuration.
Moreover, an object API 350 provides an object oriented programming interface for user access to the event information and derived relationships stored in the database 340 as well as to any compact batch views stored in the database 340. In one embodiment, the batch event historian 300 provides a Structured Query Language (SQL) interface 352 for external access to the information stored in database 340. The object API 350 therefore accesses the database 340 via an Open Database Connectivity (ODBC) driver 354 and the SQL interface 352. This structure makes the underlying persistent store largely transparent to the user or the application client programs. The persistent store may be implemented as depicted in
Exemplary user applications 364 through 370 may access the information in the persistent storage using the object API 350. The view client 364 is an exemplary user application that provides a standardized hierarchical view of the acquired historical data and may be used to provide a compact batch view as described herein. The report client 366 is an exemplary user application that produces standardized reports from the historical data. Such standard reports may include, for example, quality assurance related reports to monitor quality of the batches produced and the equipment used in the batch process or standard status reports indicating the progress of particular batch processes. The SQL browser client 368 is an exemplary user application that provides an SQL standard query interface for a user to browse information stored in the persistent storage. Similarly, the user SQL API 370 is an exemplary user application that permits other user generated application processes to access the persistent storage using standard query programming interfaces. Those skilled in the art will recognize that exemplary user applications 364 through 370 are intended merely as examples of common application programs that may utilize data in the persistent storage. Those skilled in the art will recognize a variety of similar applications that could utilize this standard interface to the data in the persistent storage.
A further function of the object API 350 is to provide a standard interface for user access to continuous data 380. The object API 350 permits the user or application to access continuous data 380 transparently as though this continuous data 380 is integrated and related with the objects in database 340. In other words, the object API 350 permits a user or an application to freely intermix and access process events, related batch events and related continuous data as though all of this data were stored in a single database, and thus enables the creation of a compact batch view which uses some or all of these different types of data. Directing access of the user to the proper persistent store (e.g., the database 340 or the continuous data 380) and determining all relations necessary to associate the data with a request may be handled with a common user interface by the object API 350. A user may specify a particular batch event and access therefor all related batch events (hierarchically related procedural elements), all related process events and all related continuous data, etc. The relationships among the various data may be automatically determined by the executive 302 and/or the object API 350.
A diagnostic interface 390 and an administrative interface 392 provide administrative user interfaces for managing the persistent store (e.g., the database 340). In particular, requests which startup or shutdown the historian processing or which reconfigure the persistent store (i.e., resize the database 340 or add/remove/modify information about data sources) may be generated by a user through the diagnostic interface 390 and/or the administrative interface 392. Moreover, the administrative interface 392 may also control the archival features of the executive 302. For example, the executive 302 may controllably perforin batch based backups, which are backups that back up all event information in the persistent store related to processing of a particular batch. The backup may be created in another section of the database 340 and may be save for other processing. These backup sections of the persistent store may be “detached” from the database 340 for offline processing. Essentially the administrative interface 392 instructs the executive 302 to make a “snapshot” of all event information for one or more identified batches. The snapshot may then be copied to a safe backup using offline processing techniques. Such an archived (snapshot) set of event information may then be deleted from the persistent store to make room for further batch history information. At a later time, an earlier archive may be restored (re-attached) to the database 340 to permit the data to be viewed and manipulated again. Deletion and restoration of such archived information is also performed by control of the administrative interface 392 that, in turn, controls the executive 302.
Those skilled in the art will recognize that the diagnostic interface 390 and the administrative interface 392 are not needed for the operation of the batch event historian 300 illustrated in
While, in the past, data has been collected for each of the batch runs of a batch process or recipe established by the campaign managers 50, 54 and/or implemented by the batch executives 30, 48, 52 of
To reduce or alleviate these issues, the batch display applications 32 may operate as one of the view clients 364 of
An example of a compact batch view which may be determined by the BDAs 32 is illustrated in the display screen 400 of
As will be seen, the compact batch view 404 is displayed in the view section 402 for the batch as highlighted or selected within the batch list section 408. As also illustrated in
Moreover, various other layers may be added to the base layer 420 to produce the compact batch view for a batch run. In particular, a further layer 423 is illustrated below the base layer 420 of
Still further, a third layer 431 illustrated above the base layer 420 includes indications or icons of other events including for example, process events or batch events, which occurred during the batch run. These icons are illustrated as being of a different type than the icons used to illustrate the batch procedure elements in the layer 423. One example of such events includes process alarms and process alerts generated during the batch run. In the example compact batch view 404 of
If desired, viewing of the data or legends illustrated in the compact batch view 404 may be enhanced by the use of color, visual effects such as blinking, video displays, graphics, etc. For example, legends associated with different types of batch procedure elements, such as phases and operations, or icons associated with the starting and stopping of the same batch procedural element, may be shown using different colors and/or visual effects. Likewise, the severity or importance of alarms or events may be shown using different colors while the quality of a product produced or results of a test may be shown using some combination of color and graphics. Still further, the user may be able to obtain further information on the meaning of legends or the data behind legends shown on the compact view 404 by hovering the mouse or cursor above the associated legends. If desired, further information may be obtained by clicking on or selecting a legend, with this information generally being more complete or raw data collected and used to create the legend on the compact batch view. Likewise, if desired, the various information to be shown in any particular layer or the number and types of layers to be shown in any particular compact batch view may be user selectable or changeable to thereby enable the user to configure the compact batch view in a manner that best suits that particular user's needs. Moreover, if desired, several compact views could be shown parallel to each other on a display screen with the time scale being vertically oriented instead of horizontally oriented as illustrated in
As will be understood, and as shown in
Of course, the information used in creating the compact batch view may be obtained from the data historians, from the controllers or the batch executive routines or even from the campaign management routines of
The compact batch view 404 or any other compact batch view may be used to quickly identify or visualize the significant events associated with the batch, or may be view by an operator or other user to see the ongoing operation of a batch for the purpose of understanding the operation of a batch and/or to compare different batch runs to one another in an easy and useful manner. Thus, for example, the display screen 440 of
Generally speaking, the simultaneous viewing of multiple compact batch views in the same display, as illustrated in
Still further, to enable a user to perform a better comparison of a particular batch run and other batch runs that used the same recipe, equipment, etc., the BDA 32 may create and illustrate a batch signature for a particular batch recipe or batch process, as developed by a number of runs of the batch recipe or batch process. Generally, a batch signature may be created as a statistical norm or a measure of an expected batch run based on a number of previous batch runs that were implemented using the same or similar batch recipe, raw materials, equipment, processing techniques, etc. As a batch signature may be a statistically determined norm for a batch run using a particular set of equipment, recipe, etc., any subsequent batch run may be compared to this norm either after completion of the batch run or during the batch run to view or indicate whether the batch run is within the norm as defined by the batch signature or meets certain criteria associated with the normal operation of the batch process. For example, a user may compare a compact batch view in relation to the batch signature for the appropriate batch process to quantify the variation of the particular batch run from the normal operation of the batch process.
As an example,
Of course, the average, median, and/or deviations for each start and end time associated with a batch procedural event, a process event or any other batch event may be determined statistically based on several or multiple batch runs of the process. Thus, the statistical signature 500 may include a pulse 572 which is associated with the start of the unit procedure 574 in the compact batch view 450, and may include another pulse 576 associated with the start of the unit procedure 580. In a similar manner, pulses 582, 584, 586, 588, 590 and 592 may be associated with a start or an end of an indication of one of the other procedures, unit procedures, operations and phases of the batch run identified by or shown within the compact batch view 450. Of course, the batch signature 500 could include pulses or other indicia indicating the expected or statistically based times for other events, such for process events, like alarms, sample times, test times, utilization, etc. In
If desired, a different batch signature layer could be created for each of the layers of a compact batch view and the various layers of the batch signature could be combined or displayed relative to one another (such as above or below one another) in either the same or a different manner as those layers are displayed in the compact batch views. In this manner, the various different layers or elements of a compact batch view may be compared to the same elements of the batch signature. Of course, because the signature pattern of a batch process is graphical in nature, this signature lends itself to acting as a layer in a batch view or to being superimposed on a given batch view to enable a user to determine any deviation. If desired, a BDA 32 may automatically determine batch deviation from a signature norm algorithmically at runtime and may, for example, set an alarm or an alert when any significant deviation occurs (wherein a user or an operator may be able to define the amount of deviation that will result in an alarm or alert being set for a particular deviation). Of course, the BDAs 32 may also or instead automatically graphically indicate deviations, for example, by highlighting the screen to show where a batch as illustrated in a particular compact view deviates from the norm defined by an associated batch signature. Moreover, because the batch now has a graphical nature, the BDA 32 may also create a display that displays only the deviations of a particular batch run from the appropriate batch signature.
While each batch signature may be illustrated as being generated from a set of stored batches, the batch signature may be generated live or while the batch is running based on a predetermined number of other batches, including other batches which are currently running and, if desired, including batch data from the batch for which the signature is being shown. Thus, the stored batches from which the batch signature may be calculated may include batch data from currently running batches, and the batch signature may be generated on the fly or on-line when a batch is running.
Moreover, to enable a better comparison of different batch views, the BDA 32 may enable a user to implement a concept referred to herein as time folding on one or more compact batch views and/or batch signatures, to thereby allow a user to view only particular, and non-contiguous, sections of a compact batch view or a batch signature. Generally speaking, time folding may be described as omitting one or more specific time periods of the batch run, and can be thought of as drawing a compact batch view on paper, and then folding the paper to show different non-contiguous portions of the compact batch view concatenated together.
This time folding feature is helpful in viewing the most important or interesting parts a batch run, as many compact batch views may be very long, especially when the associated batch runs have multiple procedures, unit procedures, operations and/or phases associated therewith. Still further, some of the sections or sub-procedures of a batch run displayed in a compact batch view may not be of high importance or relevance to a user, while other sections or portions may be of great importance in, for example, determining whether the batch run is executing properly. In these instances, a user may want to eliminate or remove the sections of the compact batch view (and/or the associated batch signature) which are less important, to thereby highlight the more important sections of the compact batch view (and/or the associated batch signature).
To perform this time folding function, the BDA 32 may provide the user with the ability to specify the sections of the compact view to be folded out or removed.
Of course, a compact batch view may have multiple time folded segments and the time folded segments may be folded out of a particular compact batch view in any desired location to allow the user to view, in a continuous nature, the relevant or interesting portions of a batch run and to display the same portions of different batch runs on a single display screen. Thus, in one example, the same sections of various different compact batch views, such as the compact batch views of
It will be understood that the batch display applications and the batch execution engines, the BOIs, CMOIs and the campaign manager server applications described herein can be used and implemented within any desired process plant control programming environment, and may be used in any process plant control system using any desired type of process plant control communication protocol and, further, may be used to perform any type of function with respect to any type of device(s) or sub-units of device(s). While the batch routines as described herein are preferably implemented in software stored in, for example, a server, a workstation or other computer, these routines may alternatively or additionally be implemented in hardware, firmware, application specific integrated circuits, programmable logic circuits, etc., as desired. If implemented in software, the batch routines may be stored in any computer readable memory such as on a magnetic disk, a laser disk, or other storage medium, in a RAM or ROM of a computer, controller, field device, etc. Likewise, this software may be delivered to a user or a device via any known or desired delivery method including, for example, over a communication channel such as a telephone line, the Internet, on a transportable medium, such as a computer-readable disk, etc.
While the present invention has been described with reference to specific examples, which are intended to be illustrative only and not to be limiting of the invention, it will be apparent to those of ordinary skill in the art that changes, additions or deletions may be made to the disclosed embodiments without departing from the spirit and scope of the invention.
This application is a divisional application of, and claims the benefit of priority to, U.S. patent application Ser. No. 12/837,145, filed Jul. 15, 2010, and entitled “COMPACT BATCH VIEWING TECHNIQUES FOR USE IN BATCH PROCESSES,” and U.S. patent application Ser. No. 11/531,457, filed Sep. 13, 2006, and entitled “COMPACT BATCH VIEWING TECHNIQUES FOR USE IN BATCH PROCESSES,” both of which are hereby incorporated by reference herein, in their entirety, for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 12837145 | Jul 2010 | US |
| Child | 13102866 | US | |
| Parent | 11531457 | Sep 2006 | US |
| Child | 12837145 | US |
