Ignition, FactoryTalk and AVEVA are all capable. On most sites the right choice is set by the installed PLC base, the legacy SCADA already running and the in-house support skills, not by a feature checklist.
Ignition uses a server-based unlimited licence, while FactoryTalk and AVEVA have historically used per-display, per-client or per-tag models. That difference changes the cost profile most as client and tag counts grow.
Browser-based clients and native MQTT and Sparkplug support favour greenfield and multi-site IIoT projects. Established Rockwell or Wonderware estates often favour staying on the platform the team already runs.
Choosing a SCADA platform is a decision most Australian manufacturers make once a decade and live with for a long time, so it is worth getting past the marketing and onto the engineering. The three platform families on most Australian sites are Ignition by Inductive Automation, Rockwell FactoryTalk and AVEVA, which covers Wonderware InTouch, AVEVA System Platform and AVEVA Plant SCADA, the product formerly known as Citect. Metromotion Controls is a control systems integrator based in Mount Waverley that delivers SCADA projects on all three across Melbourne, Victoria and Australia. We are platform-aware and vendor-agnostic, so this comparison is written to help you choose the right platform for your site rather than to favour one product.
This post supports our PLC, SCADA and HMI programming service, where SCADA platform selection, new builds, historian and reporting, and legacy SCADA migration all sit.
Before comparing features it helps to be precise about what each name covers, because each is a family rather than a single product.
A server-based, platform-agnostic SCADA with browser clients through Perspective and a thick client through Vision. Native MQTT and Sparkplug, a built-in historian, and the Sepasoft MES and Batch modules extend it into the data and batch layers.
Rockwell Automation's SCADA and HMI line: FactoryTalk View SE for distributed supervisory systems, FactoryTalk View ME for machine-level HMIs on PanelView, and the newer FactoryTalk Optix for web-based visualisation. Tightest integration is with the Allen-Bradley controller estate.
Wonderware InTouch as the long-running HMI and SCADA product, AVEVA System Platform as the object-based architecture on the ArchestrA model, and AVEVA Plant SCADA as the current name for the former Citect, widely deployed across Australian process and utility sites.
The platform decision is rarely a clean choice between three products. It is usually a choice between staying on a family already installed and moving to a different one, and that distinction shapes everything below.
Licensing is the comparison point where the three differ most, and the difference is structural before it touches price.
Inductive Automation licenses Ignition on a server basis that it describes as unlimited licensing, meaning a single server licence does not cap the number of tags, clients, screens or device connections the way a per-unit model does. The practical limit becomes the server hardware and network rather than the licence, so gateway sizing and polling discipline carry the load.
FactoryTalk and AVEVA have historically used per-display, per-client or per-tag models, where the licence scales with the size of the deployed system. Adding operator stations or expanding the tag count adds licence cost. On a small, fixed-size system that model can be competitive. On a site with many workstations, large tag counts or multiple displays, the cost profile climbs as the system grows.
The engineering implication is that the licensing model should be compared against the shape of the system, not as a headline number. A two-station packaging cell and a forty-screen multi-area plant sit at opposite ends, and the model that suits one may not suit the other. All three are quote-based in Australia, and licensing terms change, so confirm current pricing and structure against each vendor at the time of decision. This post does not publish dollar amounts for that reason.
Architecture is where the platforms reflect their design philosophies, and the differences matter most as a site grows or spreads across locations.
Ignition runs from a central gateway that polls PLCs directly, and scales out through Edge gateways that publish over MQTT and Sparkplug to a central gateway, decoupling field devices from the central system. That pattern suits multi-area and multi-site deployments where a Unified Namespace is the goal.
AVEVA System Platform is built on the object-based ArchestrA model, where the plant is modelled as reusable templates and objects within a Galaxy and deployed to Application Server engines running on platform nodes. That object model is a real strength on large, repeatable process environments, because a change to a template propagates to every instance. AVEVA Plant SCADA, the former Citect, is a mature distributed architecture proven on large tag-count process and utility systems across Australia.
FactoryTalk View SE is a distributed architecture with HMI servers, data servers and clients, designed to scale across a Rockwell estate and to integrate tightly with the Logix controller platform and FactoryTalk Directory. Its scalability is strongest where the controllers and the rest of the FactoryTalk stack are already Rockwell.
What decides most projects is not raw scale but fit to the installed base.
How operators reach the SCADA is a dividing line for new builds.
Ignition Perspective is a browser-based client that runs on any device with a browser and no installed software, which makes operator access from tablets, office PCs and phones straightforward. Ignition Vision remains a thick client for stations that need direct operating system, file or serial access. FactoryTalk View SE has historically been a Windows thick client, with FactoryTalk Optix added as Rockwell's web-based visualisation product. AVEVA offers web and mobile access alongside its established thick clients, with web client capability that has grown across recent releases.
The trend across all three vendors is toward browser-based and mobile access, so the comparison is less about whether a platform can do it and more about how mature and central that capability is on each. Weight it heavily for a greenfield project where browser clients on the plant floor and in the office are a requirement; weight it lightly where operators work from fixed, hardened stations. Confirm the current client capabilities against each vendor, because this is the area changing fastest.
These four capabilities tend to be evaluated together, because they decide whether the SCADA stays an island or becomes part of a connected, recoverable plant.
On the historian, Ignition ships a built-in tag historian on the same database and tag structure as the SCADA. AVEVA has a strong historian heritage through the product line now branded AVEVA Historian, long established on large process sites. FactoryTalk integrates with FactoryTalk Historian, built on the PI engine that was OSIsoft and is now branded AVEVA PI System following the acquisition, which is a capable enterprise historian on Rockwell estates. The comparison is less about whether each can historise and more about whether the historian is bundled or licensed separately and how it fits the reporting stack the site already uses.
On IIoT, Ignition's native MQTT and Sparkplug support is a genuine differentiator for projects centred on a Unified Namespace, which is why it features so often on greenfield IIoT work and on industrial data and IIoT projects. FactoryTalk and AVEVA both have IIoT and cloud paths and can publish to MQTT brokers, but the architecture and the modules differ, so treat MQTT centrality as a primary selection criterion rather than assuming parity. All three support OPC UA, which is the common ground on mixed-vendor sites.
On redundancy, all three run a redundant server or gateway pair on a broadly similar pattern: a Master and Backup sharing configuration, with warm standby carrying extra load for faster failover and cold standby loading less but recovering slower. The decision is an availability question answered by what an outage costs the process, and it has to extend past the server to the network path, the historian database and the power feed. A redundant server behind a single switch has only moved the single point of failure.
All three platforms provide the technical building blocks for a sound alarm system, including prioritisation, shelving and an alarm journal, so a deployment on any of them can follow the ISA-18.2 alarm-management lifecycle. ISA-18.2, developed by the ISA18 committee, defines that lifecycle from philosophy and identification through rationalisation, design, implementation, operation, maintenance, monitoring and management of change.
The decisive work is rationalisation and priority assignment, done with the process and operations team, not a default the platform arrives configured with. A poor alarm model carried from an old SCADA onto a new one stays poor regardless of which product it lands on, so rationalise as part of any migration rather than replatforming the problem intact. The deeper treatment of this sits in our guide to SCADA design for food and beverage plants.
The PLC estate is the single most important input to a SCADA platform decision, because the SCADA spends its life polling those controllers.
FactoryTalk is built around the Rockwell Allen-Bradley estate. On a site running ControlLogix and CompactLogix, the integration is deep, tag browsing is direct, and the engineering tools share the FactoryTalk Directory and Studio 5000 environment. That tight coupling is FactoryTalk's strongest argument on a Rockwell-heavy plant.
Ignition is platform-agnostic by design, with native drivers for Allen-Bradley, Siemens through S7 and OPC UA, Omron, Modbus and most other devices, which makes it well suited to mixed-vendor sites running several PLC brands on one gateway. AVEVA also connects broadly across vendors through its driver set and OPC UA, and is widely used over mixed and Siemens-based estates.
The practical rule is that a single-vendor Rockwell estate pulls toward FactoryTalk, a mixed estate pulls toward a platform-agnostic option such as Ignition or AVEVA, and the choice between those two turns on the other criteria above. The PLC-side of this decision is covered further in our PLC platform comparison.
Setting the families against the situations they suit makes the decision clearer than a feature table.
| Situation | Platform that usually fits | Why |
|---|---|---|
| Rockwell-heavy site with working FactoryTalk | FactoryTalk | Deep Allen-Bradley integration, existing skills and infrastructure, no migration cost |
| Greenfield or multi-site IIoT build | Ignition | Server-based licensing, browser clients, native MQTT and Sparkplug, platform-agnostic |
| Large existing Wonderware or System Platform estate | AVEVA | Object model and historian heritage, established support, value in the installed system |
| Mixed-vendor estate, no incumbent SCADA | Ignition or AVEVA | Both platform-agnostic; choose on licensing shape, client needs and support skills |
| Plant SCADA / Citect already deployed at scale | AVEVA Plant SCADA | Mature distributed architecture, large tag-count proven, retained team knowledge |
The table is a starting point, not a verdict. The strongest single factor is usually the installed base, because the cost of fighting an existing estate and retraining a team is often larger than any feature advantage.
Consider a mid-size food plant in outer Melbourne running a process area on Siemens controllers and two Allen-Bradley packaging lines, with an ageing SCADA approaching end-of-support. The site wants mobile access for supervisors, plant data flowing to a future MES, and a cleaner alarm system, and it has one controls technician and no deep SCADA skills in-house.
The mixed PLC estate weakens the case for FactoryTalk, whose deepest value is on an all-Rockwell estate. The mobile and MES requirements favour first-class browser clients and native MQTT and Sparkplug feeding a food and beverage data architecture that can grow. The thin skill base favours predictable licensing an integrator can support without per-station cost surprises as screens are added.
On those criteria the build points toward Ignition, with the existing Siemens and Allen-Bradley controllers retained and connected through native drivers and OPC UA. The alarm system is rationalised as part of the project rather than carried across, so the new platform starts with a short list of valid, prioritised alarms. The detail of running Ignition on a food and beverage site, including CIP evidence and batch records, sits in our practical Ignition guide.
If the same plant were all Allen-Bradley with a working FactoryTalk system and no IIoT requirement, the answer would flip toward staying on FactoryTalk, because the migration cost would not be justified by the change in requirements. The situation decided the fit, not the platform.
Reduced to a working order, the decision runs through a small set of questions, weighted by the site.
Work these top to bottom, but recognise that the installed estate and the incumbent SCADA usually settle the decision before the feature comparison begins. A capable platform that fights the existing plant is a worse outcome than a sound platform that fits it.
Metromotion Controls delivers on Ignition, FactoryTalk and AVEVA, and the recommendation for any site follows the existing PLC estate, the IT constraints, the in-house support skills and the functional requirements. The aim is the platform that serves the plant over its life, not a single product we prefer to deliver.
If you are weighing a SCADA platform decision, the most useful inputs are your existing SCADA, your PLC mix and the sites in scope. With those, Metromotion Controls can work through the right platform and architecture for your plant as part of our PLC, SCADA and HMI programming work.
The standards and platform sources below are general industry and vendor references, cited so the technical claims above can be checked against the originals. They are not Metromotion Controls measurements, and the vendor product details and licensing terms change, so confirm them against current vendor documentation at the time of decision.
Tommy Kim writes for Metromotion Controls, a Melbourne control systems integrator delivering PLC, SCADA, controls integration and commissioning for food, beverage, dairy and FMCG manufacturers across Australia.
There is no single best platform. Ignition, Rockwell FactoryTalk and AVEVA are all proven on Australian sites, and the right one depends on what is already installed. A Rockwell-heavy plant with working FactoryTalk usually stays on FactoryTalk. A greenfield or multi-site IIoT project often favours Ignition. A large existing Wonderware or System Platform estate usually favours AVEVA. The platform decision should follow the requirements and the installed base rather than lead them.
Ignition uses a server-based licence that Inductive Automation describes as unlimited, so cost does not scale with tag, client or screen count. FactoryTalk and AVEVA have historically used per-display, per-client or per-tag models, where adding operator stations or tags adds licence cost. The practical effect is that Ignition tends to be more predictable on sites with many workstations or large tag counts, while the per-unit models can be competitive on small, fixed-size systems. Licensing terms change, so confirm current pricing against each vendor before deciding. All three are quote-based in Australia.
These are all AVEVA product lines, some inherited through acquisitions. Wonderware InTouch is the long-established HMI and SCADA product. AVEVA System Platform is the larger object-based architecture built on the ArchestrA model and the Application Server. AVEVA Plant SCADA is the current name for the product that was Citect SCADA, widely deployed across Australian process and utility sites. They overlap in purpose but differ in architecture, so a site running InTouch is in a different position from one running System Platform or Plant SCADA. Confirm the current product naming against AVEVA, because the portfolio has been renamed more than once.
Yes, though to different degrees. Ignition is platform-agnostic and connects to Allen-Bradley, Siemens, Omron, Modbus and others through native drivers and OPC UA, which suits mixed-vendor sites. AVEVA also connects broadly across vendors through its driver set and OPC UA. FactoryTalk is strongest and most tightly integrated with Rockwell Allen-Bradley controllers, and it can reach other vendors through OPC UA, but its deepest integration is with the Rockwell estate. On a mixed estate, confirm the specific driver and firmware support against current vendor documentation during design.
Ignition has native MQTT and Sparkplug support through its MQTT modules and is commonly used to build a Unified Namespace, which is one of the reasons it features on greenfield IIoT projects. FactoryTalk and AVEVA both have IIoT and cloud connectivity paths and can publish to MQTT brokers, though the architecture and the modules involved differ from Ignition. If MQTT and Sparkplug are central to the project, treat the connectivity model as a primary selection criterion and confirm the current module support with each vendor rather than assuming parity.
Only when there is a clear reason. Migration means rebuilding graphics, remapping the tag model, reconnecting the historian and retraining operators, which is a real project cost. It is usually justified when the existing platform is end-of-life, hard to support, or cannot meet new IIoT, mobile or MES requirements. It is rarely justified when the current platform works, the team knows it, and the requirements have not changed. Weigh the migration cost against the value the existing system still holds before committing.
All three provide the technical building blocks for a sound alarm system, including prioritisation, shelving and an alarm journal, so a deployment on any of them can follow the ISA-18.2 alarm-management lifecycle. The standard defines a lifecycle from philosophy and rationalisation through to monitoring and management of change. The work that decides alarm quality is rationalisation and priority assignment done with the process team, not a default the platform arrives configured with. A poor alarm model carried from an old platform onto a new one stays poor, so rationalise as part of any migration.
No. Metromotion Controls is platform-aware and vendor-agnostic. We deliver on Ignition, FactoryTalk and AVEVA depending on what fits the site, and the recommendation follows the existing PLC estate, the IT constraints, the in-house support skills and the functional requirements. The aim is the platform that serves the plant over its life, not a single product we prefer to sell.
PLC logic, SCADA architecture, HMI standards, alarming and historian integration for manufacturing sites.
OEE, downtime, historian and production reporting systems built from reliable plant signals.
Automation, traceability, CIP, SCADA and production data for Australian food and beverage plants.
A practical view of where Ignition is the right SCADA platform for Australian manufacturers and where it is not.
SCADA system design considerations for alarms, records, historian data and operator use.
Rockwell, Siemens, Schneider, Beckhoff and Omron compared on programming, motion, installed base and support for Australian manufacturers.
A practical Ignition SCADA guide for Australian food and beverage manufacturers, written from an integrator's delivery experience: when Ignition is and is not the right fit, Perspective vs Vision, architecture, CIP and batch, OT security, and buying and supporting Ignition in Australia.
Key point
Platform fit comes before platform capability
Published 9 May 2026
A practical ISA-88 batch control guide for Australian food and beverage manufacturers, covering when you need it, the physical, procedural and recipe models, phase states, FSANZ traceability, platform choice and brownfield migration.
Key point
ISA-88 gives batch control a consistent structure
Published 9 May 2026
CIP is one of the largest controllable cost centres in a food or beverage plant. This article covers the four areas where CIP automation investment pays back: cycle optimisation for trade waste and chemical cost, digital audit records, queueing for equipment availability, and coverage verification to prevent silent failures.
Key point
CIP is one of the largest controllable cost centres in a food plant
Published 9 May 2026
Map out scope, delivery approach and what to have ready before the first conversation. Answer a few questions and Metromotion Controls returns a tailored scoping brief on screen.