Process control engineers and the like use flowsheets to represent process control systems that are to be monitored and/or controlled. Process simulation model components are represented in the context of process simulation software by objects. Objects are used by process simulation software to create simulation models that represent plant operations. One object may represent a process model component (a “unit”), such as a valve, connected to another process unit, such as a pump. During the creation of the model, a connection (called a “stream”) must be made between the units; typically between ports on the units. Stretching streams between object ports can prove tedious, in that this connection process must be repeated many times over to complete the construction of a model. The connection process can be made easier for a user by reducing the time and steps required to complete a connection.
As a user designs a flowsheet, it is necessary to add objects to the flowsheet and connect them to other objects. Through repeated adding and connecting actions, the flowsheet eventually contains numerous objects connected in a variety of ways to represent an actual or simulated process control system. Typically, users must choose objects from a large library of different objects as they are building flowsheets. Even if this library of objects is organized, users often spend large amounts of time looking through it for the right objects to include in their flowsheets. Because flowsheet design software allows users to design different types of flowsheets and these different types of flowsheets may call for different types of objects, typical object libraries contain large quantities of objects that a particular user will never use. Nevertheless, this user would still have to scroll past or search through these objects to get to the desired object.
The ability to predict objects that a user will likely desire to include in a flowsheet and to present these predicted objects to the user in a clear way would improve flowsheet design and cut down on excessive time spent searching through large libraries of objects, allowing the flowsheet design process to become more efficient.
Briefly described, aspects of the present invention relate to a special-purpose computer executing a program enabling a user to design flowsheets that represent process control systems. Such program, when executed, provides a mini-palette of candidate objects to a user in a graphical flowsheet design program. A set of rules applied to previously designed flowsheets predicts candidate objects for inclusion in the flowsheet and presents them on the mini-palette to improve flowsheet design.
In one aspect, a computer-implemented method presents a mini-palette of candidate objects to a user in a graphical flowsheet design program. The user is enabled to choose a candidate object for inclusion in the flowsheet. The method comprises receiving an indication from the user to initiate a new connection from an output port of an object currently displayed on the flowsheet. The method determines a set of one or more candidate objects by applying a set of rules to a plurality of previously designed flowsheets. Further, the method displays the set of candidate objects to the user in a mini-palette and enables the user to select an object for inclusion in the flowsheet.
In another aspect, a non-transitory computer readable medium stores instructions that present a mini-palette of candidate objects to a user in a graphical flowsheet design program. The user is enabled to choose a candidate object for inclusion in the flowsheet. The instructions comprise receiving an indication from the user to initiate a new connection from an output port of an object currently displayed on the flowsheet. The instructions determine a set of one or more candidate objects by applying a set of rules to a plurality of previously designed flowsheets. And the instructions display the set of candidate objects to the user in a mini-palette and enable the user to select an object for inclusion in the flowsheet.
In yet another aspect, a system executes instructions that present a mini-palette of candidate objects to a user in a graphical flowsheet design program. The user is enabled to choose a candidate object for inclusion in the flowsheet. The system receives an indication from the user to initiate a new connection from an output port of an object currently displayed on the flowsheet. The system determines a set of one or more candidate objects by applying a set of rules to a plurality of previously designed flowsheets. Further, the system displays the set of candidate objects to the user in a mini-palette and enables the user to select an object for inclusion in the flowsheet.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Other features will be in part apparent and in part pointed out hereinafter.
Corresponding reference characters indicate corresponding parts throughout the drawings.
A system embodying aspects of the invention simplifies the design process of flowsheets in flowsheet design software. Flowsheet design software is executable on a computer system having a processor, memory, and other typical computer elements. When using this system, a user can minimize time spent searching through lists of potential objects for a desired object. As such, the number of times the user must click a mouse, for example, or otherwise interact with the system decreases significantly. Advantageously, aspects of the invention thus improve the user's ability to design a flowsheet.
Moreover, aspects of the present invention predict the most likely candidate objects based on a variety of factors and display the candidate objects in a way that the user can then choose the correct object if it is present. In the event that the system does not predict the correct object, the user can still return to the main list of objects and search for it in that manner; however the correct object will be predicted and among the candidate objects a significant portion of the time, allowing the user to forgo searching through the main list.
In an embodiment, the flowsheet is being constructed in a flowsheet design program that presents a palette of objects 112 associated with the canvas 102 on which selected objects are placed and connected to one another. As shown in the example of
Referring further to
At step 308, the system presents the predicted candidate object(s) to the user for selection. The display of the candidate objects is preferably in the form of a mini-palette.
Once the user chooses a desired object (step 310), the system executes further instructions enabling the user to add another object to the flowsheet (step 304). In the event that the mini-palette does not contain the object that the user desires, the user can fall back on a different method of placing a new object, such as using the main palette as shown in
At step 408, for example, the system determines the design library to be used during the prediction. Choice of design library depends on a variety of factors. In one embodiment, there is only one design library and it contains a large number of flowsheet designs from many different types of systems. In this embodiment, no choice is needed. This design library would likely be very large and could potentially require a great deal of time and processing power to properly analyze. Also, because the design library has such a large diversity of types of flowsheet designs, it may not give the most accurate prediction results.
Advantageously, the design library may be divided into useful groups to improve prediction results. Different types of flowsheet designs (e.g., steady-state or dynamic) may be divided into different groups. The divided libraries may be more focused based on design type and more likely to have accurate predictions for those particular types of flowsheets.
A company may maintain its own design library. Rather than drawing from a large group of general flowsheet designs, a company with more unique flowsheet design patterns may maintain a library of its designs in order to improve the prediction of candidate objects. The industry of the company may be a niche that has significantly different requirements than available generic design libraries, such that using a large, general design library may yield inaccurate results, resulting in the mini-palette being ineffective. Additionally, by maintaining a design library, the company has control of which designs are present in the design library. In the event that something about the design library needs to be changed (perhaps a design requirement changed, forcing flowsheets to use different objects going forward), the company can alter the design library as required to reflect the change.
These examples are not intended to limit the possible configurations of design libraries for use with this system, but rather to demonstrate some possible factors that may affect how design libraries may be used.
Design libraries can be stored on the same machine as that which is running the flowsheet design program or they may be stored separately on a server. The design libraries could be maintained in the cloud and updated with new designs from multiple globally distinct locations. The users may then select divided design libraries based on various factors to ensure that the designs in the selected libraries are representative of the flowsheet design being built.
Additional factors may affect the prediction of the candidate objects. Advantageously, the physical characteristics of the present object may be used to limit the selection of potential objects to objects that are compatible with those physical characteristics (step 410). For instance, if the present object is defining a flow of water, the potential objects would be limited to those objects that are compatible with the flow of water, rather than objects that only work with steam or some other material. The chemical makeup of a fluid flowing through the present object may also have an affect on what candidate objects are provided. If the fluid is extremely hot, or acidic, or it reacts with certain other chemicals, the prediction of candidate objects could change dramatically. Similarly, the system may take into account the type of the overall design being made. If the overall design is dynamic, it may call for different potential objects than a design that is steady-state.
In an exemplary case, a user indicates the desire to connect a new object to a heat exchanger object. The heat exchanger object is connected to a stream of full boiling crude, which is a type of fluid that has a vapor phase. The presence of a fluid with a vapor phase limits the potential candidate objects to those that are capable of transporting such fluids. In this case, analysis of the design library indicates that the most likely candidate objects include a heat exchanger, pump, furnace, mixer/splitter, distillation column, blender, flash, desalter, lumper, and basis changer. However, because the fluid flowing through the current object includes a vapor phase, that list is reduced. After filtering for candidate objects that are compatible with a vapor phase fluid, the list of candidate objects is reduced to five: a heat exchanger, a furnace, a mixer/splitter, a distillation column, and a flash. The use of physical characteristics of the present object and the stream or fluid flowing through the object as a filter allows the system to reduce the number of potential candidate objects, increasing the chance of providing the desired candidate object to the user.
Referring further to
A user's region may factor in to the prediction of candidate objects as well. Regional design conventions may cause certain objects to be weighed more heavily than others based on where the user lives. For instance, stream flowsheets designed in the United States have a tendency to use more volumetric flow measurement objects whereas flowsheets designed in Europe tend to use mass flow measurement objects. A user may indicate where they are or where the factory is that is represented by the flowsheet and that may improve the prediction of the candidate object in certain ways.
Referring further to
In an exemplary case, a user indicates a desire to connect a new object to the liquid product stream of a crude column's Kerosene side-stripper. The stream is a pure liquid phase and is known to contain 20 components that are trace in quantity that are typically removed from the stream. Analysis of the design library indicates that the most likely candidate objects are: a mixer/splitter, a heat exchanger, a pump, a distillation column, a valve, and a component merger. However, it is an industry best practice to remove the 20 trace components from the stream using a component merger. This best practice may be reflected in the system granting more weight to the component merger object and placing it in the first position of the mini-palette. By emphasizing the component merger object, the user is encouraged or reminded to follow the best practice of including the component merger object as the next object in the stream.
If there are common combinations of candidate objects that follow a present object, these combinations may be presented on the palette as a compound object choice to further streamline the flowsheet design process. Using compound objects as candidates will enable the placement of more complex object units at once, freeing a user from rebuilding the common object combination each time it is needed. The number of objects in a combination is limited by the statistical nature of the analysis. While a two object combination may be very common, a five object combination is likely to be much rarer, due to all the possible variations of a set of five objects.
In predicting the next object, the system considers the object to which the next object will be connected, but the system may also consider multiple objects farther upstream to detect patterns and determine candidate objects. Different combinations of upstream objects may indicate more clearly what is being designed and it may cause the system to provide different sets of candidate objects. For instance, rather than the system using a single valve to attempt to predict the next object, it may use the two previous objects. A boiler-valve combination may indicate different candidate objects than a simple tank-valve combination.
Referring further to
Based on the rankings, the system presents the top ranked candidate object(s) to the user and allows the user to choose. The number of candidate objects presented may be any realistic amount but the number should be small enough that the user can quickly identify the candidate objects and determine if the desired object is present. On the other hand, the number of candidate objects should be large enough that all of the most likely candidate objects can be displayed. As shown in
In the event that the mini-palette does not initially display the object desired by the user, the mini-palette may include additional pages or a method of expanding what is displayed (see the mini-palette in
If the user would like to connect a connection port from an object and there are already objects present on the flowsheet to which it may connect, the prediction system can be used to indicate the most likely present objects to which to connect. For instance, if a user is attempting to connect a source object to something and there are already several types of tank objects present on the flowsheet with available connection points, the system may determine that the most likely objects for the connection are the tank objects already present. When this occurs, rather than presenting objects in a mini-palette, the most likely connection points may be highlighted in some manner to indicate that they are the best choices. This indication may include the connection points or objects changing color, size, or appearance in some way. The connection line may snap to the predicted connection points more readily than to other connection points to enable the user to more quickly build the flowsheet.
As an example, prediction of the downstream units for Real Time Optimization (RTO) models is described, based on a library of real-world ethylene plant model simulations. First, all unit pairs are extracted from the models in the library. These large models consist of mostly the separation equipment that occurs downstream of reactors. Table I shows the probability of an object following one of the model's 380 heat exchangers. Table II shows the destinations of the flash vapor. In this example, the top four destinations (italicized), not including “None”, are shown in the mini-palette. Note that the heat exchanger and flash vapor mini-palettes will show different objects.
Flash
24
24
Mixer
18
62
HX
16
78
Splitter
9
87
Splitter
34
34
StagingTank
28
62
Mixer
15
77
TrayedSection
12
89
Tables I and II indicate what percentage of the time each object follows a heat exchanger object. While the body of total objects in the library is quite large, the heat exchanger is only ever connected to a relatively small number of objects, and the most common objects make up the majority of those connection instances. For the heat exchanger, the mini-palette may show the top four candidate objects from the Table I. “None” is not included as the user has already indicated that they want to connect an object to the heat exchanger. From the Flash object down through the Splitter object, Table I indicates that 78% of the time, the desired candidate object would appear in the mini-palette when trying to connect an object to the heat exchanger. For the flash vapor object, Table II indicates that 89% of the time, the desired candidate object would appear in the mini-palette when trying to connect an object to the flash vapor object.
Because objects in flowsheets tend to follow certain patterns repeatedly, even only providing the same four candidate objects for all upstream objects may be enough for the mini-palette to be accurate a majority of the time. The mini-palette is not limited to only displaying four candidate objects.
For purposes of illustration, programs and other executable program components, such as the operating system, are illustrated herein as discrete blocks. It is recognized, however, that such programs and components reside at various times in different storage components of a computing device, and are executed by a data processor(s) of the device.
Although described in connection with an exemplary computing system environment, embodiments of the aspects of the invention are operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well-known computing systems, environments, and/or configurations that may be suitable for use with aspects of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Embodiments of the aspects of the invention may be described in the general context of data and/or processor-executable instructions, such as program modules, stored one or more tangible, non-transitory storage media and executed by one or more processors or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote storage media including memory storage devices.
In operation, processors, computers and/or servers may execute the processor-executable instructions (e.g., software, firmware, and/or hardware) such as those illustrated herein to implement aspects of the invention.
Embodiments of the aspects of the invention may be implemented with processor-executable instructions. The processor-executable instructions may be organized into one or more processor-executable components or modules on a tangible processor readable storage medium. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific processor-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the aspects of the invention may include different processor-executable instructions or components having more or less functionality than illustrated and described herein.
The order of execution or performance of the operations in embodiments of the aspects of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the aspects of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
When introducing elements of aspects of the invention or the embodiments thereof, the articles “a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements. The terms “comprising,” “including,” and “having” are intended to be inclusive and mean that there may be additional elements other than the listed elements.
In view of the above, it will be seen that several advantages of the aspects of the invention are achieved and other advantageous results attained.
Not all of the depicted components illustrated or described may be required. In addition, some implementations and embodiments may include additional components. Variations in the arrangement and type of the components may be made without departing from the spirit or scope of the claims as set forth herein. Additional, different or fewer components may be provided and components may be combined. Alternatively or in addition, a component may be implemented by several components.
The above description illustrates the aspects of the invention by way of example and not by way of limitation. This description enables one skilled in the art to make and use the aspects of the invention, and describes several embodiments, adaptations, variations, alternatives and uses of the aspects of the invention, including what is presently believed to be the best mode of carrying out the aspects of the invention. Additionally, it is to be understood that the aspects of the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The aspects of the invention are capable of other embodiments and of being practiced or carried out in various ways. Also, it will be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting.
Having described aspects of the invention in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the invention as defined in the appended claims. It is contemplated that various changes could be made in the above constructions, products, and process without departing from the scope of aspects of the invention. In the preceding specification, various preferred embodiments have been described with reference to the accompanying drawings. It will, however, be evident that various modifications and changes may be made thereto, and additional embodiments may be implemented, without departing from the broader scope of the aspects of the invention as set forth in the claims that follow. The specification and drawings are accordingly to be regarded in an illustrative rather than restrictive sense.
| Number | Date | Country | |
|---|---|---|---|
| 61934922 | Feb 2014 | US |