Patent Application
20170205795
Exemplary embodiments relate to field device communications systems and methods, user interfaces, and the monitoring of industrial automation processes.
In the related art within industrial plant environments, particularly those utilizing Industrial Automation (IA), there are control systems for the monitoring and adjustment of field devices. Examples of such a control system include a distributed control system (DCS), such as the [CENTUM VP]®. The field devices are used for measuring physical properties, quantities, or characteristics, such as flow rate, temperature, level, or pressure. In the related art, the operator generally uses a console in a control room to control the IA process. Additionally, field devices can be used to modify these physical properties for the purpose of controlling the process or providing safeguards the IA process.
In some cases of providing safeguards to the IA process, the field devices can be configured to notify a user or system of excessive measured physical values, and triggering an alarm based on the conditions or notifying device diagnostics. The ISA 18.2 2009 standard describes one type of an alarm management standard. As part of the standard, one element describes a concept of pre-upset warnings. These warnings are capable of notifying the operator when some part of the process moves away from an ideal value and can provide the operator ample time to prevent the process from triggering an alarm.
Additionally, the operator's interaction with the user interface of the control system for the alarm has traditionally been achieved through a text entry method.
When the operator desires to change a variable, such as the SV (1305) or MV (1306), the operator can double click on the associated area on the faceplate (1301, 1501) to bring up a menu as shown in
One or more embodiments relate to a method for setting drift warnings for monitoring processes. The method includes configuring a desired range for an acceptable drift range of a process, setting a desired parameter value for the operating of the process, detecting an actual parameter value of the process, comparing the actual parameter value to the desired parameter value and the desired range, and displaying an indication of a drift occurrence when the actual parameter value is within the desired range but different from the desired parameter value.
In some embodiments, the method includes automatically adjusting a field device parameter to maintain the actual parameter value at the desired parameter value.
According to one or more embodiments, the method includes that at least one of an adjustment of the desired parameter value and drift range is by a touch input of an operator.
In exemplary embodiments, the adjustment occurs through at least two touch inputs, where a first touch input is configured to make the adjustment at a first rate corresponding to the movement of the touch input of the operator, and where a second touch input is configured to make the adjustment at a second rate, proportionally different from the first rate, corresponding to the movement of the touch input of the operator.
Embodiments of the method may further comprise recording a current desired parameter value of a process.
Embodiments of the method may further comprise saving the desired parameter value and the desired range into a configuration file.
Embodiments of the method may provide for recording a desired parameter value of the process, wherein the process is selectable from a hierarchy of levels of processes such that the recording is configured to record the desired parameter value of the process and desired parameter values of associated lower level processes.
One or more embodiments relate to a system comprising at least one device for setting drift warnings for monitoring processes. The system includes at least one non-transitory computer readable medium operable to store program code and at least one processor operable to read said program code and operate as instructed by the program code. The program code includes configuring a desired range for an acceptable drift range of a process, setting a desired parameter value for the operating of the process, detecting an actual parameter value of the process, comparing the actual parameter value to the desired parameter value and the desired range, and displaying an indication of a drift occurrence when the actual parameter value is within the desired range but different from the desired parameter value.
According to one or more embodiments, the program code further includes automatically adjusting a field device parameter to maintain the actual parameter value at the desired parameter value.
In exemplary embodiments, at least one of an adjustment of the desired parameter value and drift range is by a touch input of an operator.
In some embodiments, the adjustment occurs through at least two touch inputs, where a first touch input is configured to make the adjustment at a first rate corresponding to the movement of the touch input of the operator, and where a second touch input is configured to make the adjustment at a second rate, proportionally different from the first rate, corresponding to the movement of the touch input of the operator.
Embodiments of the system include that the program code includes recording a current desired parameter value of a process.
Embodiments of the system include that the program code includes saving the desired parameter value and the desired range into a configuration file.
In one or more embodiments, the program code include receiving a device identifier associated with a process management console, retrieving configuration data for connection to the process management console, and automatically configuring the system to connect to the process management console based on the configuration data, where the process management console provides information regarding the process to the system.
One or more embodiments relate to an apparatus for setting drift warnings for monitoring processes. The apparatus includes at least one non-transitory computer readable medium operable to store program code and at least one processor operable to read said program code and operate as instructed by the program code. The program code includes configuring a desired range for an acceptable drift range of a process, setting a desired parameter value for the operating of the process, detecting an actual parameter value of the process, comparing the actual parameter value to the desired parameter value and the desired range, and displaying an indication of a drift occurrence when the actual parameter value is within the desired range but different from the desired parameter value.
According to one or more embodiments, the program code further comprises automatically adjusting a field device parameter to maintain the actual parameter value at the desired parameter value.
In exemplary embodiments, at least one of an adjustment of the desired parameter value and drift range is by a touch input of an operator.
In some embodiments, the adjustment occurs through at least two touch inputs, where a first touch input is configured to make the adjustment at a first rate corresponding to the movement of the touch input of the operator, and where a second touch input is configured to make the adjustment at a second rate, proportionally different from the first rate, corresponding to the movement of the touch input of the operator.
Embodiments of the system include that the program code includes recording a current desired parameter value of a process.
Embodiments of the system include that the program code includes saving the desired parameter value and the desired range into a configuration file.
In one or more embodiments, the program code include receiving a device identifier associated with a process management console, retrieving configuration data for connection to the process management console, and automatically configuring the system to connect to the process management console based on the configuration data, where the process management console provides information regarding the process to the system.
Embodiments will be described below in more detail with reference to the accompanying drawings. The following detailed descriptions are provided to assist the reader in gaining a comprehensive understanding of the methods, apparatuses, and/or systems described herein, and equivalent modifications. Accordingly, various changes, modifications, and equivalents of the systems, apparatuses and/or methods described herein will be suggested to those of ordinary skill in the art. Also, descriptions of well-known functions and constructions may be omitted for increased clarity and conciseness.
The terms used in the description are intended to describe embodiments only, and shall by no means be restrictive. Unless clearly used otherwise, expressions in a singular form include a meaning of a plural form. In the present description, an expression such as “comprising” or “including” is intended to designate a characteristic, a number, a step, an operation, an element, a part or combinations thereof, and shall not be construed to preclude any presence or possibility of one or more other characteristics, numbers, steps, operations, elements, parts or combinations thereof.
In the related art usage of alarms, when an alarm occurs this indicates that the process is already in an upset condition.
During states of stable operation of the plant processes, operators monitor the operating states of the plant processes and the associated field devices through a monitoring system. As part of this monitoring, the operators are waiting for alarms to occur. In normal process operations when the process is stable, the operators do not have much activity and are waiting for a process upset of the operating state. When this happens, especially during night shifts when no outside activities occur, the operators are prone to boredom and their ability to respond to/have awareness of, minor process disturbances is reduced.
When a number of critical and important parameters or tags that affect a process grows large, the operator does not have the ability to keep track of all the parameters to prevent an alarm occurrence. In the related art, the operator may bring up the trends of a select few, very important parameters—that have may occur often and/or an impact of which is high—on a screen in the multi monitor environment. However, this may create tunnel vision for the operator, and the operator may miss changes in parameters—that occur rarely but their impact is still significant because they can affect the process.
Additionally, due to the interconnected nature of chemical processes, if a parameter in a process is allowed to drift, a single alarm might trigger a flood of alarms causing the operator to lose track of the root cause of the process upset. In the related art, the use of pre-upset warnings is unwieldy as they must be configured manually, and that is difficult to do on a large scale if there are hundreds or thousands of tags in a system.
Even in a single process unit, different process conditions may require different operation ranges, and manually configuring the parameters of the pre-upset warnings to these different operation ranges may be difficult. For example, different operations might mean that a refinery changes the grade of crude that is being blended or the production of a different output based on market demand.
Also, different operators, even in the same plant or process, may operate differently based on their experiences and on the production goal, e.g. maximize efficiency, maximize production, increase quality, etc.
Exemplary embodiments of the present application provide a method for automatically setting up parameters for the pre-upset warning conditions for entire systems based on drifting parameters. The parameters of the pre-upset warning conditions may be numerical set values for specific processes to indicate the operating state of the process. The exemplary embodiment may provide monitoring to operate the process so that the upset condition is never reached, so that the operator can take actions so that the process remains in a stable state. Exemplary embodiments aim to monitor and limit variations in parameters to enable the operator to achieve a much tighter control on the process and not allow the alarm to occur in the first place.
Additionally, exemplary embodiments may provide the important values in context via a display, as well as allow the operator to directly manipulate the values through a variety of touch input.
Drift Monitoring
Exemplary embodiments of the present application provide for a user interface where the operator is shown a summary of drift conditions. The summary can display and provide situational awareness of what parameters are drifting out of stable states for the operator to take action on.
In this way, the UI can clearly distinguish drift from alarms for the operator. The operator is also provided with an easy to review summary screen of whether there are drifts occurring. The UI also further provides a lay out to review lower level processes associated with the higher level, level 2 information.
In some embodiments, level 2 icons can be arranged along the vertical edges of the UI on both the left side edge and the right side edge. Alternatively, some embodiments may provide for the level 2 icons to be arranged along a left side edge of the UI. Clicking on a level 2 icon will display associated lower level processes in the center of the UI, e.g. Tower as a level 3 process of the level 2 Crude Unit process.
When the operator selects a specific device for the graphical display (303), the parameters for the range of the tolerable drift (305, 306) as well as a target value (304) may be shown. This provides additional context for the graphical display (303) as the settings.
In some embodiments, when an alarm overload occurs, the drift monitoring system can be turned off automatically to allow the operator to bring the alarm occurring process back to a stable condition. This would be useful since always alarms take higher priority than drift. Additionally, it is likely that there would be numerous drifts occurring in an alarm condition.
According to some embodiments, based on the process dynamics, the operator is able to define the tightness of control for each parameter. These values could be the output of a Real Time Optimizer (RTO) and shall be allowed to be imported into the system via a configuration file. Further to
In some embodiments, if a configuration file is used, the default range for drift settings shall be the one that is imported. Alternatively, if there is no configuration file for importing, the drift range may be preset to a percentile range as desired, such as a default of 10% of the operating range.
In exemplary embodiments, where drift occurs to a sufficiently high degree, the system may automatically display the drifting parameters and bring up a user interface for the operator to make adjustments to parameters to bring the process within normal operating standards.
In some embodiments, the system may automatically adjust the field devices based on predetermined algorithms to bring operating states within norms. These algorithms may be predetermined or set by the operator based on experience. In these embodiments, the system may actively adjust the field device. Adjustment may be achieved through the use of a controller, such as a proportional-integral-derivative (PID) controller. A PID controller is a control loop feedback mechanism that is configured to attempt to minimize error between a measured PV and a desired SV. The PID controller may operate on the basis of an algorithm with three correcting terms, including a proportional term, an integral term, and a derivative term. The proportional term is proportional to a deviation value. The integral term considers the duration of deviation. The derivative term considers predicted system behavior in view of adjustments. One or combinations of these terms may be used for determining an adjustment amount to adjust the process. The PID controller can adjust the position of a component, such as a control valve or power supply, to attempt to correct any deviations. In some embodiments, the system may automatically begin to adjust the field devices when drift is experienced. This may allow for correction instead of further deviation into an alarm stage, even if an operator is unable to manually adjust the process.
In some embodiments, the adjustments are made to the tuning parameters (P, I & D constants) of a PID controller instead of the SV in the controller.
In some embodiments, algorithms such as a real time optimizer are placed on top of the drift detection and the algorithm adjusts the field values.
In exemplary embodiments, a series of possible actions could be tagged to the drift parameters. For example, particular drift notifications may cause automatic adjustments to be made according to established standard operating procedures. This may include adjustments in the process or setting a notification to check the process. Additionally, some embodiments may provide onscreen guides for the operator to review and analyze the drift notifications. Such an onscreen guides may be provided by software, such as [YOKOGAWA EXA-PILOT]®.
In exemplary embodiments, simulation may be used to predict the trend of the drift itself or the nature of how the process may move based on possible actions in the standard operating procedures.
In exemplary embodiments, when the simulation detects future process values to be unstable after taking into consideration a series of possible actions on a particular drift, an alarm or notification is raised to the operator.
Snapshot Configuration
Exemplary embodiments provide for a snapshot feature (509) as shown in
For example, if a plant is changing the process, e.g. switching between processing Saudi Arabia light crude and a different crude, the corresponding snapshot file can be restored quickly.
The snapshot feature can be configured to save all the data associated with the desired process, including lower level processes down to specific parameters of specific field devices.
In other embodiments, the snapshot feature may be used for troubleshooting. When non-optimal conditions can be saved through snapshot, they may be sent for analysis and discussion with other operators or researchers. This may provide aid to the operator in determining a corrective course of action.
In some embodiments, the range for drift notification is also saved in the snapshot. Alternatively, the range for drift notification shall continue to come from a separate configuration.
By taking a snapshot of a level 2 process, all the lower level data from the specific field devices in the process is also saved.
By allowing selective level based snapshot saving, the type and amount of saved data can be tailored to the specific needs of the operator. The snapshot saving would allow for the saving of the parameter values of the selected process as well as the saving of all related parameter values for the associated lower level processes. In such a way, the desired parameter value of the process can be recorded, wherein the process is selectable from a hierarchy of levels of processes. By doing so, the recording is configured to record the desired parameter value of the process and desired parameter values of associated lower level processes. Accordingly, if a higher level process is selected, all data for the associated lower level processes can also be recorded.
In some embodiments, the snapshots can be automatically generated with software for real-time optimization (RTO) or advanced process control (APC). However, the snapshots could also be used in stand alone systems with manual operations.
Additionally, in some embodiments, the snapshots may be automatically loaded when a manufacturing execution system (MES) for the IA process detects changes in the process operating conditions. For example, if different inputs, such as a different crude oils, are detected, the MES system may automatically load the corresponding snapshot.
Implementation with a Mobile Device
This application configuration procedure must be repeated to connect to each individual console. Due to this manual configuration process, the mobile device cannot be quickly connected to multiple different consoles in the control room. Additionally, the process does not take proximity of the mobile device to the control room console into account.
In other related art embodiments, the related art may use NFC and proximity as part of the login process. However, this requires a two-step authentication and validation process, including exchanging security certificates between the proximity technology and the mobile device, prior to connection of the mobile device and the console.
In exemplary embodiments, an NFC tag will be placed next to a control room console. Each NFC tag will contain a Unique ID that will identify the console that it is placed next to. This unique ID will be entered into a database, such as
To start the connection process a user will get a mobile device that has been approved and loaded for control room use (S1101). An operator will then bring the mobile device to the console they wish to be connected with. The mobile device will then touch the NFC tag at the console to begin the configuration and connection process (S1102). This will also satisfy the requirement that the mobile device starts the configuration process in close proximity to a control room console.
Once the mobile device has touched the NFC tag, an application on the mobile device will receive the NFC tag's unique identifier (S1103). The Mobile application will then look up the NFC tags unique identifier in the database (S1104).
Using the returned configuration information in the database, the application will then be automatically configured to connect to the control room console (S1105). Following configuration, the application can connect itself to the control room console (S1106). Accordingly, the operator can then follow any additional authentication procedure required for that specific control room console (S1107).
Through the exemplary embodiments, the mobile device can be quickly connected to another control room console without needing manual configuration for each and every console.
As an alternative, some embodiments may use an RFID chip instead of NFC. The process would be the similar to use of NFC on the mobile device except that RFID would be used. The RFID chip would give the mobile device a unique ID. This RFID unique ID would then be used similarly to the NFC unique ID to look up the control room console's configuration information. The use of RFID would also necessitate that the mobile device be in close proximity to the control console it is connecting to.
Separately from NFC and RFID, it may be necessary to populate a list of control room consoles detected in close proximity using [BLUETOOTH]®. In some embodiments, the operator would have to select which console the mobile device is to be configured and connected with. A feature of low power [BLUETOOTH]® devices is that the signal strength can be adjusted. This will affect the proximity range that a mobile device must be in order to detect a low power [BLUETOOTH]® device. As such, the usage of [BLUETOOTH]® may be adjusted to suit particular control room layouts and console spacing to improve efficiency for connections.
To start the connection process, the operator will get a mobile device that has been approved and loaded for control room use (S1201). The operator will bring the mobile device in the proximity of the console they wish to be connected with (S1202). A mobile application on the mobile device will then be able to detect the nearby low power [BLUETOOTH®] devices affiliated with the consoles.
A list of control room consoles will be populated on the mobile device (S1203) and the operator can select a console that will be automatically configured and connected with (S1204).
The low power [BLUETOOTH]® device will then provide the mobile application with a unique ID (S1205). The Mobile application will then look up the unique ID from the low power [BLUETOOTH]® device in the database (S1206). The information returned from the database will be the control room consoles configuration information.
Using the returned configuration information in the database, the application can be automatically configured to connect to the control room console (S1207). The application will now connect itself to the control room console (S1208). Accordingly, the operator can then follow any additional authentication procedure required for that specific control room console (S1209).
Through the exemplary embodiments, the mobile device can be quickly connected to another control room console without needing manual configuration for each and every console.
In some embodiments, the use of the mobile device may be linked with specific user rights or user profiles. These may enable the ability to selectively configure access and monitoring of particular processes. In this way, the operator on the mobile device may be able to selectively monitor processes of interest without having to respond or be alerted to changes in separate processes. In some complex processes, there may be multiple operators, each operator being responsible for one section or portion of the process. In such a case, the operator does not need to monitor all elements of the processes. By selectively linking particular processes with the mobile device, the operator is not encumbered by excessive, irrelevant information. For example, an operator might choose to only link to TOWER or CRUDE_OIL_FEED as shown in
Some embodiments may allow for the operator to view all of the processes while only allowing modification of particular linked processes. Other embodiments may only allow viewing and modification of the particular processes.
In these embodiments, specific mobile devices, user rights, or user profiles may be limited to modification of specific processes in order to prevent accidental changes to other processes. By preventing modification of parameters outside of the particular processes, the operator cannot accidently modify the settings of a process that is not assigned to the operator. This prevents potential error where another operator responsible that particular process may not be aware of changes in the pre-upset warning conditions until an alarm has occurred.
Additionally, in cases where a supervisor or visitor may be using a mobile device to monitor the processes, the accidental modification of unrelated processes may be prevented.
Touch Interaction
In contrast, the slider indicator (1703) indicates a configurable value within a range of the graph (1702). The slider indicator (1703) is movable corresponding to the movement of the operator's touch inputs. Touch movement up or down moves the slide indicator (1703) up or down within a range. The distance that the slide indicator (1703) moves is correlated to how many fingers are being used.
Alternative embodiments may switch the responses between one finger and two finger operation, such that the two finger operation results in the smaller corresponding movement.
Additionally, the function in which the distance degrades with fewer inputs could be something other than a reduction by half. The corresponding movement of the slider indicator based on the touch input may be set at other proportional ratios. The distance the value moves is directly proportional to the distance the input touches travels on the display, and, in some embodiments, one of the touch input methods may result in movement that is twice the touch input.
By having different movement responses, the operator can be provided with the ability to make coarse and fine adjustments of the slider indicator. This is in contrast to a single correspondence method, where one may find that the control of the movement of the slider indicator is difficult for fine adjustments due to large movements of the slider indicator based on the touch input or for coarse adjustments due to small movements of the slider indicator based on the touch input.
In some embodiments, a user interface may utilize additional input touches to further adjust the proportional movement of the slider indicator in response to touch inputs by the operator. This relationship could be extrapolated out to any number of input touches, where each additional touch changes the proportional movement of the slider indicator.
For example, in an exemplary embodiment where the maximum number of touches moves the slider indicator the same distance as the distance of the touches, one fewer touch results in travel of half the distance, two fewer touches results in travel of a quarter of the distance, and so on. Alternatively, the opposite may be true that one touch results in the slide indicator moving the same distance as the distance of the touch and additional touches reduces the distance that the slide indicator moves. The maximum number of touches necessary can be determined by the granularity, or level of detail, as required.
In application, the touch input system may be used to adjust the individual limitations of the drift range configuration.
Although this specification has been described above with respect to the exemplary embodiments, it shall be appreciated that there can be a variety of permutations and modifications of the described exemplary features by those who are ordinarily skilled in the art without departing from the technical ideas and scope of the features, which shall be defined by the appended claims.
A method of one or more exemplary embodiments may be recorded as computer-readable program codes in non-transitory computer-readable media (CD ROM, random access memory (RAM), read-only memory (ROM), floppy disks, hard disks, magneto-optical disks, and the like) including program instructions to implement various operations embodied by a computer.
While this specification contains many features, the features should not be construed as limitations on the scope of the disclosure or of the appended claims. Certain features described in the context of separate embodiments can also be implemented in combination. Conversely, various features described in the context of a single exemplary embodiment can also be implemented in multiple exemplary embodiments separately or in any suitable sub-combination.
Although the drawings describe the user interface (UI) views in a specific order or layout, one should not interpret that the UI views are performed in a specific order or layout as shown in the drawings or successively performed in a continuous order, or that all the UI views are necessary to obtain a desired result. Also, it should be noted that all embodiments do not require the distinction of various system components made in this description. The device components and systems may be generally implemented as a single software product or multiple software product packages.
A number of examples has been described above. Nevertheless, it is noted that various modifications may be made. For example, suitable results may be achieved if the described techniques are performed in a different order and/or if components in a described system, architecture, or device are combined in a different manner and/or replaced or supplemented by other components or their equivalents. Accordingly, other implementations are within the scope of the following claims.
