In most control systems the PID algorithm that regulates a loop lives in a central controller, and the field devices simply report measurements and accept commands. Foundation Fieldbus opened another possibility: because its transmitters and valve positioners contain their own processors, the PID block can run inside the field device itself. That arrangement is called control in the field, or CIF, and it moves the loop's brain out to the process. This guide explains what control in the field means, where the PID actually executes, the availability and scan-time tradeoffs it brings, and when operators choose it over control in the host.
Control in the field in one line: Control in the field means running the PID or control algorithm inside a smart field device, such as a Foundation Fieldbus transmitter or valve positioner, rather than in the central controller. Because the input, PID, and output blocks all execute on the fieldbus segment out at the process, the loop can keep controlling even if the host controller is unavailable, at the cost of tying the loop's speed to the fieldbus macrocycle and the device's processing capacity.
A conventional loop reads its measurement into a controller, runs the PID calculation there, and sends the result back out to the valve. Control in the field rearranges that path so the calculation happens on the fieldbus segment instead. In a Foundation Fieldbus system, function blocks such as the analog input, the PID, and the analog output are downloaded into the devices themselves, and the segment's schedule executes them in order during each macrocycle. The transmitter measures, a PID block hosted in either the transmitter or the positioner computes the new output, and the positioner drives the valve, all without the loop calculation passing through the host controller.
This works because Foundation Fieldbus devices are not dumb sensors; each carries a microprocessor capable of running standard function blocks, and the protocol schedules block execution deterministically on the wire. The engineer decides at configuration time where each block lives. A common choice is to place the PID in the valve positioner, so the block that computes the output sits next to the device that acts on it, minimising the number of times a value has to travel across the segment within one loop cycle. The host still sees everything, provides the operator interface, and can adjust setpoints and tuning, but it is no longer in the critical control path.
The distinction matters because it changes what has to be working for the loop to keep regulating. In host-based control, the loop depends on the controller, the I/O, and the communications between them. In control in the field, the loop depends only on the transmitter, the positioner, and the fieldbus segment that connects them. That smaller, more local dependency is the whole point of the approach, and it is also the source of its main tradeoffs.
The headline benefit of control in the field is availability. Because the PID runs on the segment rather than in the host, a loop configured this way can continue to hold its setpoint even if the central controller is offline for maintenance, has failed, or is being migrated. The measurement, the calculation, and the valve action all remain on the segment, so the process keeps being regulated. For a critical loop this can mean the difference between riding through a host outage and dropping to a safe but disruptive fallback state, which is a strong argument in continuous operations where an unplanned trip is expensive.
The main cost is speed and rigidity. A fieldbus segment executes its scheduled blocks once per macrocycle, and that cycle time is typically slower than a fast host controller scan. Control in the field therefore suits loops whose dynamics are slow enough to be comfortable at the segment's cycle, which covers a great many temperature, level, and pressure loops but not the fastest ones. The device's own processor also has finite capacity, so the number and complexity of blocks a single device can host is limited, and heavy control math is still better placed in the host.
There are practical constraints too. When the PID lives in the field, tuning changes, block reconfiguration, and diagnostics all involve the device rather than a central database, which some engineering teams find harder to manage across many loops. A mixed strategy is common: put the loops that most benefit from surviving a host outage into the field, and keep faster or more complex loops, and anything needing tight coordination with other loops, in the host controller where they are easier to see and change together.
Control in the field is fundamentally a local resilience technique: it keeps a loop regulating close to the process regardless of what is happening upstream. That local autonomy pairs naturally with a monitoring layer that sits above it. A SCADA system does not need to be in the control path for a field-hosted loop to work, which means the loop's integrity does not depend on the reliability of the link back to the control room or the cloud. The regulation happens on the segment; the supervisory system observes, trends, and alarms on it.
For a distributed or remote operation this separation is useful. A site can run its critical loops in the field so they survive communication interruptions, while a cloud SCADA platform such as Merobix collects the process values, setpoints, controller outputs, and device diagnostics that the fieldbus system exposes and presents them to operators anywhere. An engineer watching a fleet of sites sees the same loop information whether the loop is hosted in a controller or in a positioner, because at the supervisory level it is just a set of tags. The visibility is centralised even though the control is not.
This layering also helps with the health of the field devices themselves. Foundation Fieldbus devices carry rich diagnostics, and when a loop runs in the field those diagnostics are exactly what tells an operator that a positioner is struggling or a transmitter is drifting before the loop's performance degrades. Streaming that information into a central platform lets a remote team keep an eye on field-hosted loops across many sites, so the resilience of running control in the field is backed by the awareness of watching it from above.
Not exactly. A distributed control system already spreads control across many controllers rather than one central computer, but the PID still runs in a controller. Control in the field goes a step further and pushes the PID block into the field device itself, so the loop executes on the fieldbus segment. It is a more literal form of distribution, moving the control right out to the transmitter or valve.
Slower, self-contained loops that benefit most from surviving a host outage are the usual choice, such as many temperature, level, and pressure loops on continuous processes. Fast loops that need a quick scan, loops with heavy computation, and loops that must be tightly coordinated with several others are usually better kept in the host controller, where speed, capacity, and central visibility are easier to manage.
No. The host controller and the SCADA layer still see the measurement, setpoint, output, mode, and device diagnostics for a field-hosted loop, and operators can still change setpoints and tuning. What changes is only where the PID math executes. The loop continues to be displayed, trended, and alarmed exactly like a host-based loop, so operators generally cannot tell the difference from the screen.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.