Demand mode describes how often a safety function is actually called upon to act, and that frequency splits safety functions into fundamentally different categories. A function that is rarely demanded is treated very differently, mathematically and conceptually, from one that is demanded frequently or is continuously relied upon. This distinction is not a technicality; it changes which reliability metric you use, how you verify the design, and how you think about failures. Getting the demand mode right is a prerequisite for every other safety calculation.
Demand Mode in one line: Demand mode classifies a safety function by how frequently it is called upon: low-demand mode for functions demanded rarely, and high-demand or continuous mode for functions demanded frequently or relied on constantly. Low-demand functions are assessed by their average probability of failure on demand (PFD), while high-demand and continuous functions are assessed by their frequency of dangerous failure per hour (PFH), which changes the entire reliability math.
The defining question for demand mode is simple: how often does the process actually call on this safety function to act? Some functions, like a high-pressure trip on a well-behaved vessel, may be demanded only rarely across their entire life. Others, like a guard interlock that is challenged many times a day, or a control-related protection that the process leans on constantly, are demanded far more often. That difference in demand frequency is what separates low-demand from high-demand and continuous operation.
The reason this matters is that the two situations fail in different ways. For a rarely demanded function, what counts is whether it happens to be in a working state at the moment a rare demand arrives. The function can sit with a hidden failure for a long time between demands, so the relevant measure is the probability that it is failed when the rare demand comes. Frequent proof testing is what keeps that probability low, because the demands themselves are too rare to expose failures.
For a frequently demanded or continuously relied-upon function, the picture flips. Demands come often enough that a hidden failure is likely to be exposed by a real demand rather than a test, and the function is effectively part of keeping the process safe moment to moment. Here the meaningful measure is how often the function suffers a dangerous failure per unit time, because a dangerous failure translates almost directly into a hazardous event. The same hardware, in these two roles, has to be judged by different yardsticks.
Low-demand functions are measured by their average probability of failure on demand, usually written PFD. This is a dimensionless probability: given a demand, what is the chance the function is in a failed state and cannot respond? Because it is an average over the proof test cycle, it depends heavily on how often the function is tested, since testing is the main mechanism that finds the hidden failures that would otherwise cause a failure on demand. Low-demand SIL targets are expressed as ranges of this probability.
High-demand and continuous functions are measured by their frequency of dangerous failure per hour, usually written PFH. This is a rate, not a probability: how often does the function develop a dangerous failure over time? For a continuously operating protection, a dangerous failure is essentially a direct step toward a hazardous event, so the frequency of such failures is the natural measure. The same SIL levels exist in this world, but they are defined by bands of dangerous failure frequency rather than probability on demand.
Choosing the wrong metric produces meaningless results. Applying a probability-on-demand model to a function that is actually demanded continuously understates the risk, because it ignores that a dangerous failure will be exploited almost immediately. Applying a per-hour failure-rate model to a rarely demanded function ignores the crucial role of proof testing. This is why classifying the demand mode is the first step in any verification: it decides which reliability framework, and which entire set of equations, applies.
Demand mode is set during design, but the assumption behind it should be checked against how the process actually behaves. A function assumed to be low demand can quietly become high demand if the process starts challenging it far more often than expected, and that shift invalidates the reliability model built on the low-demand assumption. Knowing the real demand rate, rather than the one written into an old study, is therefore an operational safety question, not just a design one.
This is exactly the kind of insight continuous monitoring provides. A SCADA platform that logs every time a protective setpoint is approached or a trip is initiated builds an empirical picture of how often each function is really being demanded. If a supposedly rare high-pressure trip is being challenged weekly, that data is a signal that the original low-demand classification, and every calculation built on it, needs revisiting. Without that record, a mode shift can go unnoticed for years.
For distributed oil and gas assets, where functions were often designed with conservative but untested demand assumptions, this feedback is particularly useful. Cloud monitoring that trends demand frequency across many sites lets engineers catch functions whose real demand rate has drifted away from their assumed mode, and reclassify or reinforce them before the mismatch causes trouble. The demand mode fixes the math; field data confirms the math is still describing reality.
Low-demand mode applies to safety functions called upon rarely, where the key question is whether the function is working at the moment a rare demand arrives. High-demand or continuous mode applies to functions demanded frequently or relied on constantly, where a dangerous failure quickly leads to a hazard. The distinction changes which reliability metric is used and how the design is verified.
Use average probability of failure on demand (PFD) for low-demand functions, since the concern is the chance the function is failed when a rare demand occurs, and proof testing is the main way hidden failures are found. Use frequency of dangerous failure per hour (PFH) for high-demand and continuous functions, since demands are frequent enough that a dangerous failure quickly turns into a hazard. Choosing the wrong metric produces a meaningless result.
Yes. A function designed as low demand can effectively become high demand if the process starts challenging it far more often than the original study assumed. That shift invalidates the low-demand reliability model, so the real demand rate should be monitored in operation. Logging how often each protective setpoint is approached or a trip fires reveals when a reclassification is needed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.