Predictive pressure protection system

Systems and methods include a computer-implemented method for providing a predictive pressure protection system. Flare sources, performance limits, and relationships between control valves and relief valves are established. A flare simulator is generated using piping isometric drawings. An emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. Event start and finish time periods are divided into cases representing smaller time frames. Source max loads are determined for each case, and each case is run through the flare simulator. Flare/relief valve performance indicators are determined based on the source max loads after running each case.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a conversion of Provisional Application No. 63/036,077, filed on Jun. 8, 2020, and is hereby incorporated by reference in its entirety.

BACKGROUND

The present disclosure applies to predictive pressure protection systems used, for example, for petroleum facilities.

A commonly-held concept that basic process control layer and a passive layer for equipment protection are “independent” is a well-known practiced doctrine in the industry. This concept teaches away from the view that information from basic process control layer can form an important process input to the passive layer in predicting the performance of the passive layer. Therefore, for a typical process engineer, a need does not arise to draw a relation between the two layers. Also, although a typical plant emergency lasts only for a few hours, dynamic load modelling with actual process equipment changes affecting the flare piping flow hydraulics is a cumbersome exercise. A need arises for a systematic and organized means to capture and model the process equipment dynamics interacting with the disposal system. Thereby, the ability of a process safety system to accommodate the required relief can be predicted.

SUMMARY

The present disclosure describes techniques that can be used to provide a predictive pressure protection system. The system can be implemented as a predictive application developed from data procurement principals of a corporate flare monitoring system, for example. The techniques can solve complex dynamic modeling obstacles by sectionalizing an emergency event, dividing the event into parts, and then modelling each part through a hydraulic model to obtain a profile of the what-if impact on the passive protection layer. The predictive tool can include safety aspects (predicting strengths and weaknesses of processes) and economic aspects (identifying over capacity for future expansion opportunities). The predictive tool can be used for petroleum facilities, for example.

In some implementations, a computer-implemented method includes the following. Flare sources, performance limits, and relationships between control valves and relief valves are established. A flare simulator is generated using piping isometric drawings. An emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. Event start and finish time periods are divided into cases representing smaller time frames. Source max loads are determined for each case, and each case is run through the flare simulator. Flare/relief valve performance indicators are determined based on the source max loads after running each case.

The previously described implementation is implementable using a computer-implemented method; a non-transitory, computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer-implemented system including a computer memory interoperably coupled with a hardware processor configured to perform the computer-implemented method/the instructions stored on the non-transitory, computer-readable medium.

The subject matter described in this specification can be implemented in particular implementations, so as to realize one or more of the following advantages. First, techniques can be used to identify weak points in passive flare and relief systems which may fail in an emergency release. Second, the techniques can be used to identify flare and relief system overcapacity that may provide an opportunity for facility throughput/feed increase. Third, techniques can be used to determine whether a passive layer of protection is adequate, for example, whether a passive layer can be predicted based on actual events. Fourth, links can be identified between active (basic process control) and passive (flare and relief) layers. For example, techniques can be used to connect the two layers by transferring rates from a Basic Process Control System (BPCS) to a passive system. Fifth, events can be modeled using loads in time slices. Sixth, prototypes can be developed by applying the framework on actual cases to prove a practical implementation of ideas. Seventh, digitalization concepts can be developed per flare evergreening and data management systems. Eighth, visual dashboards and key process indicators (KPIs) can be provided to display information related to the predictive pressure protection system. Ninth, a flare digitized system can be integrated with a plant data archiver. Tenth, maximum flow can be used in valve characteristic equations for efficient estimation of BPCS rates. Eleventh, entire flare networks can be modeled to account for breaches occurring in inactive parts of the flare system. Twelfth, processes can implicitly account for equipment interactions and can use actual releases to predict behavior of relief systems.

The details of one or more implementations of the subject matter of this specification are set forth in the Detailed Description, the accompanying drawings, and the claims. Other features, aspects, and advantages of the subject matter will become apparent from the Detailed Description, the claims, and the accompanying drawings.

DETAILED DESCRIPTION

The following detailed description describes techniques for providing predictive pressure protection systems. Various modifications, alterations, and permutations of the disclosed implementations can be made and will be readily apparent to those of ordinary skill in the art, and the general principles defined may be applied to other implementations and applications, without departing from scope of the disclosure. In some instances, details unnecessary to obtain an understanding of the described subject matter may be omitted so as to not obscure one or more described implementations with unnecessary detail and inasmuch as such details are within the skill of one of ordinary skill in the art. The present disclosure is not intended to be limited to the described or illustrated implementations, but to be accorded the widest scope consistent with the described principles and features.

Predictive tools used to validate events to model passive layers can be based on basic process control/passive layer link. Numerous hydraulic cases can be run for an entire emergency event after identifying and dividing the event into shorter time periods. The techniques can ensure that the relief valves and piping are fit for the purpose. If the system cannot handle a release, then the sources can be flagged. Subsequently, in future de-bottlenecks of the plant, a system that requires an upgrade can also be flagged.

FIG.1is a block diagram showing an example, of an architecture100that includes a predictive pressure protection system (or system102). The system102can log upset events (for example, power failures and cooling water loss). The events can be first registered through real-time monitoring104(or tracking) of releases from process equipment to the flare against a digitized flare network of relief valves and piping. For example, the term real-time can correspond to events that occur within a specified period of time, such as within minutes or seconds. The real-time monitoring104can use a Flare Monitoring System (FMS)106, for example. As a result, the system102can aid in predicting process safety deficiencies, minimizing the chances of overdesigning a plant's flare network. The system102can use an as-built simulation of flare and relief (or passive protection) model108.

The system102can dissect a time period of a flagged event during which each flare source (for example, a set of control valves) releases fluid to the flare piping. Each source has one or more corresponding relief valves in a digitized flare model. As such, each source release is allocated to the relief valve(s). The time period can be divided into N number of discrete points. For an actual flaring event, the flare model is run for N number of times to develop actual performance factors (for example, pressure, temperature, and velocity) for each relief valve. The actual performance factors can be compared against the relief valve and flare design parameters (for example, mechanical limit, back pressure limit, and vibration). Then, a design integrity (indicating under-design or overdesign) report can be developed. An event logger can append and cache the actual performance with past results to enhance an integrity profile in a graphical format. This information can be used to generate predictions of the robustness of relief valves/flares against the risk of catastrophic failure. Consequently, an operations engineer can fix a potential deficiency (categorized as a safety impact) or increase plant feed (categorized as an economic impact) in response to the predicted performance of relief valves/flares from actual events.

The techniques described in the present disclosure can be used to predict the ability of a flare and relief system to handle an emergency release. Based on a predetermined set of metrics, the operator can be alerted if the capacity may be breached. Also, any overdesign margin can be identified and used in opportunities to increase and process additional feed through the plant in the future.

To be able to generate predictions, actual releases to the flare system typically occur through pressure control valves (also known as basic process control system). The releases can be recorded in a data historian. The actual data can be imported through relief valves in a simulator, for example. Multiple simulations can be run to develop predictions for how relief devices may have reacted if the releases were to occur through relief valves.

FIGS.2A-2Care flow diagrams collectively showing an example of a workflow200for a predictive pressure protection system, according to some implementations of the present disclosure. Process and Instrumentation Drawings (P&ID) are typically used to develop an overall process schematic. At201, the P&ID and process flow diagram (PFD) are obtained. The process schematic should include the major process equipment that are tied to flare. The sources to the flare, specifically, include control valves and relief valves that are depicted on the schematic. At202, process flows that include flare sources to flares are developed. At203, identification tags of the control valves and relief valves are obtained. Pressure control valves are a part of basic process control for the process equipment in case of an emergency.

Detailed piping isometric or field mechanical walkdown of piping can be used to develop a flare piping network sketch, at208. A flare piping model can be constructed using a commercial software at209.

Relief valves that form a passive control can be activated when basic process control is deficient. A relationship table between the pressure control valve and the relief valves is developed from the P&IDs at204. Specification sheets of control valves and relief valves are obtained at205. Characteristics of control valves including valve normal operating flow coefficients and installed flow coefficients can be included in the specification sheet. Relief valve types and mechanical limits, including back pressure limits, can be obtained from the relief valve specification sheet.

From203, the control valve tags are filtered in a data historian. Specifically, the valve opening tags which, for instance, depict the position of valves are selected. The plant operators monitor the real-time valve openings on a daily basis, as table depicting spurious or actual event can be used to filter the actual emergency events at207. The filter is initially provided by abnormal opening of the valve with operations, providing a feedback validating the actual event at208. When an event, such as a power failure or loss of plant utilities (for example, instrument air) occurs in a given period at211, a time period from the start, throughout, and an end of the incident is dissected at212. The valves' opening and closing positions within a 24-hour period are used to dissect the emergency period at213. The period is further divided into time increments (for example, 5 minute increments) to obtain the percent opening of the valves at214. A counter is set from the first point, followed by time increments until the last point at215and217. During the counter, the valve position is converted into the instantaneous flow rate by using standard performance equations for control valves based on the data from the valve specification sheet at216. The cases representing each point in the incremented time are logged with flow rates corresponding to each control valve at220.

The relational table between the control valve and the relief valve developed in at204is used to distribute the control valve rate to relief valve(s) at221. As a result, the flow rate for each relief valve is specified in each case. From the flare hydraulic model at205, each of the cases is run until all the cases in a given time increment are solved at223and results of the relief device/flare (including back pressure, velocity, and temperature) are stored in a table at227. A graphical representation of relief valve design limits (for example, back pressure, rating, and temperature) are compared against the predicted performance at228. A notification is sent through an alert system to plant operations and engineering to take an action for rectifying the situation at230. The predicted performance is logged with the previously recorded results and displayed to show the disposition of the relief system at231. Any overcapacity with satisfactory performance showing the relief valve parameters within the design limits can be logged with a notification to the plant. The events can be continuously monitored through the validation at210.

In order to study the effectiveness of the techniques of the present disclosure, an actual emergency release was used to develop a prediction profile. A company's plants were scanned for emergency releases over a period of 12 months. Events from one facility were identified. Techniques of the present disclosure and steps of the workflow were applied with an apparatus for analyzing the under or overcapacity of the system.FIGS.3-12correspond to actual event showing how the techniques of the present disclosure can be used to predict the strength of a passive relief system from a BPCS.

FIG.3is a block diagram showing an example of a Basic Process Control System (BPCS)300, according to some implementations of the present disclosure. The BPCS300can be used for a flare monitoring system for a gas and oil separation plant (GOSP), for example. Equipment include pressure control valves (PCVs)302, a purge gas304, high pressure (HP) production traps (HPPTs)306, a low pressure production traps (LPPT)308, a degasser310, and flare meter312.

The block diagram presented inFIG.3can serve as a process connectivity drawing. For example, the block diagram shows relationships between the protected equipment and associated protective equipment (for example, the Basic Process Control System). The relationship between the protected equipment and the BPCS is required to monitor instantaneous flow release from the equipment during an emergency. Equipment in the block diagram generally includes protected equipment (for example, pressure vessels, compressors, and piping sections), protective equipment (for example, pressure control valves, flow control valves, and flares), and measurement equipment (for example, flowmeters).

FIG.4is a graph400showing an example of an abnormal event402captured by real-time monitoring of a BPCS, according to some implementations of the present disclosure. For example, the graph400shows the abnormal event402taking place, as BPCS activation is identified. Plots on the graph400are relay time404and magnitude406. The graph400includes plots for process equipment (for example, High Pressure Production Trap or HPPT) gas outlet to flare header, process equipment pressures, and flare flowmeter reading.

FIG.5is a graph500associated with an example of a daily Flare Management Strategy (FMS) flaring report, according to some implementations of the present disclosure. The graph500includes bars using amounts of gas and water over time. A bar502indicates an event validated as an emergency.

FIG.6is a screen print of an example of a user interface600with operational comments that accompanies the graph500, according to some implementations of the present disclosure.

FIG.7is a graph showing an example of gas out plots700, according to some implementations of the present disclosure. The gas out plots700correspond to a sectionalized event period from a BPCS activation start and end.

FIG.8is a screen shot of an example of a BPCS/passive relief table800, according to some implementations of the present disclosure. The table800includes relationship between process equipment, control valves and relief valves.

FIG.9is a screen shot showing example of discrete time stamps900identified with a BPCS valve opening, according to some implementations of the present disclosure. The discrete time stamps900correspond to cases with values in the table tied to specific timestamps. The valve opening positions derive values for the prediction profiler.

FIG.10is a block diagram of an example of a hydraulic model1000with passive protection layer developed for predicting hydraulic flow profile, according to some implementations of the present disclosure. Relief valves serve as protective equipment and belong to the Passive Control System.

FIG.11is a screen print of an example of a table1100including data for automated hydraulic model run cases with results, according to some implementations of the present disclosure. Values that are output from a data historian can be transferred as input to the simulator. Data in the highlighted cells1102can be calculated from the data historian using a new pressure control valve performance equation (For example, based on a maximum value in each dissected time period). If an actual flow control valve with a flow indicator is present, then a direct reading can be taken from the data historian.

FIG.12is a screen print of an example of a dashboard1200displaying results compared with a threshold, capacity, and strength indicator, according to some implementations of the present disclosure. The dashboard1200can include UI elements such as simulator input file name and location, event date with start and end time, and protected equipment (for example, HPPT, LPPT, HPTT, and HP compressor tags). The UI elements can also include protective equipment, including relief valve tags (for example, PZV-3210s, PZV-3011s, PZV-4001) and flare tags. The UI elements can also include a number of cases evaluated (and a number of incidents evaluated) and relief valve performance information, including flow capacity of relief valve (input origin from data historian or can be over-ridden by user), flow capacity design limit of relief valve, backpressure of relief valves for each case (simulated), back pressure design limit of relief valves, and a number of relief valves satisfying the design criterion. The UI elements can also include flare system performance information, including flare flow design limit and actual flow (aggregated from data historian), flare Mach number design limit and actual (simulated), and a number of cases where the flare limit is exceeded. The UI elements can also include flare system piping information alerts in case of a breach, including an actual Mach number (simulated) and a design limit (set in the simulator).

FIG.13is a flowchart of an example of a workflow1300for a predictive pressure protection system, according to some implementations of the present disclosure. The workflow1300can serve as a simplified version of the workflow200, for example.

At1302, flare sources, performance limits, control valve/relief valve relation are established. The information can be established, for example, using one or more of piping and instrument drawings, process flow diagrams, and instrument specification sheets1304.

At1306, flare simulator is developed using the sources, for example using piping isometric drawing1308.

At1310, an emergency event is monitored and filtered with respect to control valve limit breach. The monitoring and filtering can use a process data historian1312, for example.

At1314, event start/finish time periods are divided into short time frames (or cases).

At1316, source max loads are calculated for each case, and each case is run. For example, the calculation can use a calculate control valve flow and transfer values in related relief valves1318.

At1320, a determination is made whether the case is the last case run in simulator.

At1322, if the last case has been run in the simulator, flare/relief valve performance indicators are developed at1320. Outputs can include, for example, notifications, key process indicator (KPI) reports, and an event log1324. A real-time display1326can be created.

FIG.14is a flowchart of an example of a method1400for a predictive pressure protection system, according to some implementations of the present disclosure. For clarity of presentation, the description that follows generally describes method1400in the context of the other figures in this description. However, it will be understood that method1400can be performed, for example, by any suitable system, environment, software, and hardware, or a combination of systems, environments, software, and hardware, as appropriate. In some implementations, various steps of method1400can be run in parallel, in combination, in loops, or in any order.

At1402, flare sources, performance limits, and relationships between control valves and relief valves are established. As an example, establishing the flare sources can be based on one or more of piping and instrument drawings, process flow diagrams, and instrument specification sheets. From1402, method1400proceeds to1404.

At1406, an emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. For example, the monitoring and filtering can use a process data historian. In some implementations, method1400further includes detecting the emergency event based on deviations of a source from preset limits, for example, determining that equipment readings are outside a pre-determined range associated with a non-emergency state. From1406, method1400proceeds to1408.

At1408, event start and finish time periods are divided into cases representing smaller time frames. From1408, method1400proceeds to1410.

At1410, source max loads are determined for each case, and each case is run through the flare simulator. For example, determining the source max loads for each case can include calculating control valve flow and transferring values in related relief valves. From1410, method1400proceeds to1412.

At1412, flare/relief valve performance indicators are determined based on the source max loads and running each case. For example, the flare/relief valve performance indicators can include notifications, key process indicator (KPI) reports, and event logs. After1412, method1400can stop.

In some implementations, method1400further includes creating a real-time display for presenting the flare/relief valve performance indicators. For example, the dashboard1200can display results compared with a threshold, capacity, and strength indicator.

In some implementations, method1400can include interactions within the equipment and piping that form part of one single process has significant impact on how concurrent releases from disparate equipment may occur during an emergency release. The system dynamics, hydraulics and interaction became evident when actual releases were monitored within the period of an emergency release. This dynamic shows that the prediction of release from a given equipment at any given time may be under or over predicted even if the overall release reaches a certain maximum value.

Although emergency events typically occur in a shorter durations of time (for example, hours), techniques of the present disclosure can be used to handle short bursts of releases that are detected. In most cases, meters without validation are unreliable sources of information in an emergency. A lack of validation steps can result in spurious events that can taint the performance prediction based on history of releases during an actual emergency release.

In some implementations, method1400can include identifying outdated engineering information. For example, changes in a chemical plant that are not reflected in distributed control systems, piping and instrumented drawings or flare schematics can be flagged. This can be accomplished because the system can generate correlations between basic process control systems (control valves) and passive protection system (relief valves).

Predictive monitoring can be used to alert plants of breaches of the protection layer, allowing weak element to be pinpointed. Moreover, systems with near protection capacity or over capacity can aid in decisions with future upgrades (for example, to increase plant throughput).

FIG.15is a block diagram of an example computer system1500used to provide computational functionalities associated with described algorithms, methods, functions, processes, flows, and procedures described in the present disclosure, according to some implementations of the present disclosure. The illustrated computer1502is intended to encompass any computing device such as a server, a desktop computer, a laptop/notebook computer, a wireless data port, a smart phone, a personal data assistant (PDA), a tablet computing device, or one or more processors within these devices, including physical instances, virtual instances, or both. The computer1502can include input devices such as keypads, keyboards, and touch screens that can accept user information. Also, the computer1502can include output devices that can convey information associated with the operation of the computer1502. The information can include digital data, visual data, audio information, or a combination of information. The information can be presented in a graphical user interface (UI) (or GUI).

The computer1502can serve in a role as a client, a network component, a server, a database, a persistency, or components of a computer system for performing the subject matter described in the present disclosure. The illustrated computer1502is communicably coupled with a network1530. In some implementations, one or more components of the computer1502can be configured to operate within different environments, including cloud-computing-based environments, local environments, global environments, and combinations of environments.

The computer1502can receive requests over network1530from a client application (for example, executing on another computer1502). The computer1502can respond to the received requests by processing the received requests using software applications. Requests can also be sent to the computer1502from internal users (for example, from a command console), external (or third) parties, automated applications, entities, individuals, systems, and computers.

Each of the components of the computer1502can communicate using a system bus1503. In some implementations, any or all of the components of the computer1502, including hardware or software components, can interface with each other or the interface1504(or a combination of both) over the system bus1503. Interfaces can use an application programming interface (API)1512, a service layer1513, or a combination of the API1512and service layer1513. The API1512can include specifications for routines, data structures, and object classes. The API1512can be either computer-language independent or dependent. The API1512can refer to a complete interface, a single function, or a set of APIs.

The service layer1513can provide software services to the computer1502and other components (whether illustrated or not) that are communicably coupled to the computer1502. The functionality of the computer1502can be accessible for all service consumers using this service layer. Software services, such as those provided by the service layer1513, can provide reusable, defined functionalities through a defined interface. For example, the interface can be software written in JAVA, C++, or a language providing data in extensible markup language (XML) format. While illustrated as an integrated component of the computer1502, in alternative implementations, the API1512or the service layer1513can be stand-alone components in relation to other components of the computer1502and other components communicably coupled to the computer1502. Moreover, any or all parts of the API1512or the service layer1513can be implemented as child or sub-modules of another software module, enterprise application, or hardware module without departing from the scope of the present disclosure.

The computer1502includes an interface1504. Although illustrated as a single interface1504inFIG.15, two or more interfaces1504can be used according to particular needs, desires, or particular implementations of the computer1502and the described functionality. The interface1504can be used by the computer1502for communicating with other systems that are connected to the network1530(whether illustrated or not) in a distributed environment. Generally, the interface1504can include, or be implemented using, logic encoded in software or hardware (or a combination of software and hardware) operable to communicate with the network1530. More specifically, the interface1504can include software supporting one or more communication protocols associated with communications. As such, the network1530or the interface's hardware can be operable to communicate physical signals within and outside of the illustrated computer1502.

The computer1502includes a processor1505. Although illustrated as a single processor1505inFIG.15, two or more processors1505can be used according to particular needs, desires, or particular implementations of the computer1502and the described functionality. Generally, the processor1505can execute instructions and can manipulate data to perform the operations of the computer1502, including operations using algorithms, methods, functions, processes, flows, and procedures as described in the present disclosure.

The computer1502also includes a database1506that can hold data for the computer1502and other components connected to the network1530(whether illustrated or not). For example, database1506can be an in-memory, conventional, or a database storing data consistent with the present disclosure. In some implementations, database1506can be a combination of two or more different database types (for example, hybrid in-memory and conventional databases) according to particular needs, desires, or particular implementations of the computer1502and the described functionality. Although illustrated as a single database1506inFIG.15, two or more databases (of the same, different, or combination of types) can be used according to particular needs, desires, or particular implementations of the computer1502and the described functionality. While database1506is illustrated as an internal component of the computer1502, in alternative implementations, database1506can be external to the computer1502.

The computer1502also includes a memory1507that can hold data for the computer1502or a combination of components connected to the network1530(whether illustrated or not). Memory1507can store any data consistent with the present disclosure. In some implementations, memory1507can be a combination of two or more different types of memory (for example, a combination of semiconductor and magnetic storage) according to particular needs, desires, or particular implementations of the computer1502and the described functionality. Although illustrated as a single memory1507inFIG.15, two or more memories1507(of the same, different, or combination of types) can be used according to particular needs, desires, or particular implementations of the computer1502and the described functionality. While memory1507is illustrated as an internal component of the computer1502, in alternative implementations, memory1507can be external to the computer1502.

The application1508can be an algorithmic software engine providing functionality according to particular needs, desires, or particular implementations of the computer1502and the described functionality. For example, application1508can serve as one or more components, modules, or applications. Further, although illustrated as a single application1508, the application1508can be implemented as multiple applications1508on the computer1502. In addition, although illustrated as internal to the computer1502, in alternative implementations, the application1508can be external to the computer1502.

The computer1502can also include a power supply1514. The power supply1514can include a rechargeable or non-rechargeable battery that can be configured to be either user- or non-user-replaceable. In some implementations, the power supply1514can include power-conversion and management circuits, including recharging, standby, and power management functionalities. In some implementations, the power-supply1514can include a power plug to allow the computer1502to be plugged into a wall socket or a power source to, for example, power the computer1502or recharge a rechargeable battery.

There can be any number of computers1502associated with, or external to, a computer system containing computer1502, with each computer1502communicating over network1530. Further, the terms “client,” “user,” and other appropriate terminology can be used interchangeably, as appropriate, without departing from the scope of the present disclosure. Moreover, the present disclosure contemplates that many users can use one computer1502and one user can use multiple computers1502.

For example, in a first implementation, a computer-implemented method includes the following. Flare sources, performance limits, and relationships between control valves and relief valves are established. A flare simulator is generated using piping isometric drawings. An emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. Event start and finish time periods are divided into cases representing smaller time frames. Source max loads are determined for each case, and each case is run through the flare simulator. Flare/relief valve performance indicators are determined based on the source max loads after running each case.

A first feature, combinable with any of the following features, where establishing the flare sources is based on one or more of piping and instrument drawings, process flow diagrams, and instrument specification sheets.

A second feature, combinable with any of the previous or following features, where the monitoring and filtering use a process data historian.

A third feature, combinable with any of the previous or following features, where determining the source max loads for each case includes use a calculate control valve flow and transfer values in related relief valves.

A fourth feature, combinable with any of the previous or following features, where the flare/relief valve performance indicators include notifications, key process indicator (KPI) reports, and event logs.

A fifth feature, combinable with any of the previous or following features, the method further including creating a real-time display for presenting the flare/relief valve performance indicators.

A sixth feature, combinable with any of the previous or following features, the method further including detecting the emergency event based on deviations of a source from preset limits.

In a second implementation, a non-transitory, computer-readable medium stores one or more instructions executable by a computer system to perform operations including the following. Flare sources, performance limits, and relationships between control valves and relief valves are established. A flare simulator is generated using piping isometric drawings. An emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. Event start and finish time periods are divided into cases representing smaller time frames. Source max loads are determined for each case, and each case is run through the flare simulator. Flare/relief valve performance indicators are determined based on the source max loads after running each case.

A first feature, combinable with any of the following features, where establishing the flare sources is based on one or more of piping and instrument drawings, process flow diagrams, and instrument specification sheets.

A second feature, combinable with any of the previous or following features, where the monitoring and filtering use a process data historian.

A third feature, combinable with any of the previous or following features, where determining the source max loads for each case includes use a calculate control valve flow and transfer values in related relief valves.

A fourth feature, combinable with any of the previous or following features, where the flare/relief valve performance indicators include notifications, key process indicator (KPI) reports, and event logs.

A fifth feature, combinable with any of the previous or following features, the operations further including creating a real-time display for presenting the flare/relief valve performance indicators.

A sixth feature, combinable with any of the previous or following features, the operations further including detecting the emergency event based on deviations of a source from preset limits.

In a third implementation, a computer-implemented system includes one or more processors and a non-transitory computer-readable storage medium coupled to the one or more processors and storing programming instructions for execution by the one or more processors. The programming instructions instruct the one or more processors to perform operations including the following. Flare sources, performance limits, and relationships between control valves and relief valves are established. A flare simulator is generated using piping isometric drawings. An emergency event is monitored, and information for the emergency event is filtered based on a control valve limit breach. Event start and finish time periods are divided into cases representing smaller time frames. Source max loads are determined for each case, and each case is run through the flare simulator. Flare/relief valve performance indicators are determined based on the source max loads after running each case.

A first feature, combinable with any of the following features, where establishing the flare sources is based on one or more of piping and instrument drawings, process flow diagrams, and instrument specification sheets.

A second feature, combinable with any of the previous or following features, where the monitoring and filtering use a process data historian.

A third feature, combinable with any of the previous or following features, where determining the source max loads for each case includes use a calculate control valve flow and transfer values in related relief valves.

A fourth feature, combinable with any of the previous or following features, where the flare/relief valve performance indicators include notifications, key process indicator (KPI) reports, and event logs.

A fifth feature, combinable with any of the previous or following features, the operations further including creating a real-time display for presenting the flare/relief valve performance indicators.

Computers suitable for the execution of a computer program can be based on one or more of general and special purpose microprocessors and other kinds of CPUs. The elements of a computer are a CPU for performing or executing instructions and one or more memory devices for storing instructions and data. Generally, a CPU can receive instructions and data from (and write data to) a memory.

Graphics processing units (GPUs) can also be used in combination with CPUs. The GPUs can provide specialized processing that occurs in parallel to processing performed by CPUs. The specialized processing can include artificial intelligence (AI) applications and processing, for example. GPUs can be used in GPU clusters or in multi-GPU computing.

A computer can include, or be operatively coupled to, one or more mass storage devices for storing data. In some implementations, a computer can receive data from, and transfer data to, the mass storage devices including, for example, magnetic, magneto-optical disks, or optical disks. Moreover, a computer can be embedded in another device, for example, a mobile telephone, a personal digital assistant (PDA), a mobile audio or video player, a game console, a global positioning system (GPS) receiver, or a portable storage device such as a universal serial bus (USB) flash drive.

Furthermore, any claimed implementation is considered to be applicable to at least a computer-implemented method; a non-transitory, computer-readable medium storing computer-readable instructions to perform the computer-implemented method; and a computer system including a computer memory interoperably coupled with a hardware processor configured to perform the computer-implemented method or the instructions stored on the non-transitory, computer-readable medium.