Demand rate estimation is the process of working out how often a safety instrumented function will actually be called on to act, expressed as demands per year. That number is not a guess; it is derived from the frequencies of the initiating events that would trigger the function, usually inside a layer-of-protection analysis. The demand rate matters because it decides whether the function is treated as low demand and analysed with a probability of failure on demand, or as high or continuous demand and analysed with a frequency of dangerous failure per hour. Estimating it correctly is what keeps you from measuring the wrong thing about your safety system.
Demand rate estimation in one line: Demand rate estimation is how you calculate the number of times per year a safety instrumented function will be called on, by summing the frequencies of the initiating events that would place a demand on it. The result decides the mode of operation: roughly once per year or less is treated as low demand and evaluated with PFD, while more frequent demands are treated as high or continuous demand and evaluated with PFH.
The demand rate on a safety instrumented function comes from the scenarios that would require it to act. In a layer-of-protection analysis, each hazard scenario has an initiating event with an estimated frequency, such as a control loop failing, an operator error, or a pump running on when it should stop. If several of those initiating events would each place a demand on the same function, you add their frequencies together to get the total demand rate for that function. The point is that demand rate is an output of the scenario analysis, not an assumption you bring to it.
Getting the initiating-event frequencies right is the hard part. They come from generic industry data, plant history, and engineering judgement about how often the specific cause occurs. A basic process control loop failing to a dangerous position, for instance, has a commonly used generic frequency, and operator-error scenarios have their own ranges. The analyst has to be careful to count only the demands that reach the safety function after any upstream protection layers, because a demand that an earlier independent layer already handles does not land on the function under study.
The result of this exercise is a single figure in demands per year that represents how busy the function is. A high-pressure trip on a well that rarely sees upset conditions might see a fraction of a demand per year, while a level trip on a vessel with a twitchy upstream control loop might see several. That figure is then compared against a threshold to pick the mode of operation, which changes the entire reliability calculation that follows.
The demand rate is compared against a boundary of roughly one demand per year. Below that, the function is treated as operating in low-demand mode, and its performance is measured as the average probability of failure on demand, a dimensionless number between zero and one. Above it, the function is treated as high-demand or continuous mode, and its performance is measured as the frequency of a dangerous failure per hour. These are genuinely different metrics answering different questions, so the choice of mode is not cosmetic.
The logic behind the boundary is about proof testing. In low-demand mode, real demands are rarer than proof tests, so a proof test is your main opportunity to reveal a hidden dangerous failure before a real demand finds it. That makes the probability of being in a failed state at the moment of an infrequent demand the right thing to measure. In high-demand or continuous mode, demands come so often that they effectively test the function themselves, and a hazardous failure rate per hour becomes the meaningful figure instead.
This is why a wrong demand rate mis-selects the reliability metric and can invalidate the whole analysis. If you underestimate demand rate and call a function low demand when it is really high demand, you calculate a probability of failure on demand for something that should have been evaluated as a failure rate per hour, and the resulting target may be far too easy to meet. Overestimating in the other direction wastes money on a function that never needed to be that fast or that reliable. The boundary is a hinge, and demand rate is what puts you on one side of it or the other.
The estimates that feed a demand rate are only as good as the data behind them, and this is where operating history becomes valuable. A safety function may have been designed years ago against generic initiating-event frequencies, but once it is in service the plant generates its own record of how often trip conditions actually occur. Those real counts are the strongest possible check on whether the assumed demand rate was right, because they describe your equipment on your process rather than an industry average.
A cloud SCADA platform is well placed to capture this evidence, because it can log every time a measured variable approaches or crosses a trip point, with a timestamp, and keep that history for years without an engineer having to trawl through a local controller. Over time those logs reveal the true demand frequency: how many high-level excursions the tank really saw, how often the compressor tripped on high discharge pressure, how frequently an operator intervened just short of a trip. That is precisely the data a functional-safety review wants when it revisits the mode-of-operation decision.
For oil and gas operators running many similar assets, a platform like Merobix that consolidates event history across sites turns a one-off design assumption into a living measurement. If a function that was classified as low demand is quietly seeing demands far more often than once a year, the historian makes that visible, and the classification can be corrected before the next assessment cycle. The estimate remains an engineering judgement, but it becomes an informed one, anchored to what the field actually did rather than to a number chosen at design time.
You identify every initiating event that would call on the function, estimate the frequency of each from industry data and plant history, and add those frequencies together. The result, expressed in demands per year, is the total demand rate. Only demands that actually reach the function after upstream protection layers are counted.
Below roughly one demand per year, proof tests happen more often than real demands, so probability of failure on demand is the meaningful metric. Above it, demands come often enough to effectively test the function themselves, so a dangerous failure rate per hour is used instead. The demand rate decides which side of that boundary you sit on.
Underestimating demand rate can wrongly classify a high-demand function as low demand, so you calculate a probability of failure on demand when you should have calculated a failure rate per hour. The reliability target you then meet may be far too weak for the real duty, leaving the function under-specified for how often it is actually called on.
Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.