Between the idea for a project and the detailed drawings that get built, there is a phase whose whole purpose is to turn a rough concept into a well-defined, costed scope that everyone can commit to. For automation and control work, that phase is front-end engineering design, or FEED. This guide explains what FEED is, the deliverables it produces for a control system, how it fits between the earlier conceptual work and the later detailed design, and why doing it well takes a lot of risk out of the rest of the project.
Front-End Engineering Design (FEED) in one line: Front-end engineering design (FEED) is the early engineering phase that develops a project concept into a defined and costed scope before detailed design and procurement begin. For an automation project, FEED produces deliverables such as a control philosophy, I/O count estimates, a control-system architecture, preliminary drawings, and a cost and schedule basis, giving the project a firm enough definition to make a confident investment decision.
Projects progress through decreasing levels of uncertainty. At the very start is conceptual work - sometimes called pre-FEED - which explores whether an idea is viable at all, compares a few options at a coarse level, and produces rough order-of-magnitude estimates. It answers the question of whether the project is worth pursuing, but it deliberately does not pin down much detail. Its estimates are wide because the point is to screen ideas, not to commit to one.
FEED is the next step, and its job is to take the option that survived conceptual work and define it properly. It resolves the major design choices, fixes the design basis, and develops enough engineering that a reliable cost and schedule can be built. FEED does not produce the drawings you build from - that is detailed design - but it produces enough definition that the detailed design can proceed efficiently and that the organization can make a sound decision to fund the project. In many organizations the end of FEED coincides with the final investment decision, precisely because that is the first point at which the scope and cost are defined well enough to commit.
After FEED comes detailed engineering, procurement, and construction, where the defined scope is turned into buildable drawings, equipment is bought, and the system is built and tested. The clean progression - pre-FEED to screen, FEED to define, detailed design to build - exists so that money is committed only as uncertainty falls, and so that changes, which get more expensive the later they happen, are pushed as early as possible when they are still cheap.
For the control and automation part of a project, FEED produces a recognizable set of deliverables. Chief among them is the control philosophy, a document that describes at a high level how the facility is to be controlled and monitored: what is automated versus manual, how the operator interacts with the process, the general approach to alarms and safety, and the split of responsibility between the control system and any safety system. The control philosophy is the anchor that later, more detailed specifications are developed from.
FEED also develops an I/O count estimate - a reasonable projection of how many inputs and outputs the system will handle, broken down by type - because I/O count drives the size of the control hardware, the cabinet count, the wiring, and ultimately a large part of the cost. Alongside it comes a control-system architecture diagram showing the major elements and how they connect: controllers, the SCADA or supervisory layer, networks, and communication paths to remote sites. Preliminary process drawings, such as early P&IDs, are developed far enough to support these estimates without being fully detailed.
Underpinning all of it is the cost and schedule basis. FEED gathers enough definition to produce a cost estimate accurate enough to base an investment decision on, and a schedule that reflects the real sequence and duration of the work. It also identifies the significant risks and long-lead items, so that the project goes into detailed design with its eyes open rather than discovering surprises later. The whole package is what lets a project sponsor commit with confidence.
The reason organizations invest in a proper FEED is that it moves discovery and decision-making to the cheapest point in the project. Every ambiguity resolved during FEED - a control approach settled, an I/O count firmed up, an architecture chosen - is one less thing to discover during detailed design or, far worse, during construction and commissioning, where changes ripple through drawings, procurement, and field work at great cost. A well-run FEED also exposes the risks early enough to plan for them, so the project is not blindsided by a long-lead controller, an unsupported protocol, or a communications gap that only becomes obvious once the money is committed.
For a SCADA-heavy project - one that supervises a distributed set of remote sites rather than a single plant - FEED is where the fleet-wide questions get answered while they are still cheap to answer. How many sites, how many points per site, what telemetry media, how the sites roll up to a central control room, and what the standard site template looks like are all far better settled in FEED than discovered site by site during execution. Getting the architecture and the I/O basis right at FEED is what allows the later work to be a repeatable rollout rather than a series of one-off surprises.
The platform choice a FEED settles on shapes the whole cost and risk profile of the execution phase, and a cloud SCADA platform such as Merobix affects the FEED arithmetic in a specific way. Because the supervisory servers, redundancy, and historian are provided as a hosted service, the architecture developed during FEED carries less on-site server infrastructure, and the cost basis shifts from capital hardware toward a per-site configuration and subscription model that is often easier to estimate accurately across a fleet. The control philosophy, the I/O basis, and the field architecture still need the same careful FEED work; what changes is that the supervisory tier is a defined, known quantity from the outset rather than a bespoke build that has to be scoped, sized, and costed as part of every project.
Pre-FEED, or conceptual engineering, explores whether a project idea is viable, compares options at a coarse level, and produces wide, order-of-magnitude estimates to screen ideas. FEED takes the option that survives and defines it properly - resolving major design choices, fixing the design basis, and developing enough engineering for a reliable cost and schedule. Pre-FEED decides whether to pursue the project; FEED defines it well enough to commit funding.
Typical automation deliverables include a control philosophy describing how the facility is controlled and monitored, an I/O count estimate that drives hardware sizing and cost, a control-system architecture diagram, preliminary process drawings such as early P&IDs, and a cost and schedule basis. FEED also identifies significant risks and long-lead items. Together these define the automation scope well enough to support a confident investment decision.
FEED moves discovery and decisions to the cheapest point in the project. Every ambiguity resolved during FEED is one less thing to find during detailed design or construction, where changes ripple through drawings, procurement, and field work at great cost. FEED also exposes risks and long-lead items early enough to plan for them, so the project enters detailed design with a defined scope and reliable estimates rather than expensive surprises.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.