Skip to content
Ignition SCADA in Australia: A Practical Guide for Food and Beverage Manufacturers engineering guide from Metromotion Controls
Control Systems · MAY 2026 · Updated JUNE 2026 · 8 min read

Ignition SCADA in Australia: A Practical Guide for Food and Beverage Manufacturers

Key points

Key points
1

Platform fit comes before platform capability

Ignition suits greenfield sites, multi-site rollouts and data-heavy plants. A Rockwell-heavy estate or a well-supported legacy SCADA can justify staying put, so the fit is assessed site by site.

2

Perspective vs Vision is the first build decision

Browser-based clients make Perspective the default for all new projects. Vision, the older thick-client module, is being phased out and should not be chosen for new greenfield builds.

3

Tag-model and project discipline decide success

A planned tag model, restrained polling, OT segmentation and a staged commissioning sequence matter more to a successful Ignition deployment than any single platform feature.

Ignition by Inductive Automation has become one of the breakout platforms in modern SCADA. It takes a different path from traditional systems by building on current IT technologies, which makes it lightweight to deploy, unusually broad in what it can connect to, and quick to stand up. For many plants it can cover most of what a factory wants from a supervisory system, from operator screens to historian, reporting and integration with business systems, and it gets there fast. Metromotion Controls is an Ignition Gold Certified Integrator based in Mount Waverley, working with food and beverage manufacturers across Melbourne, Victoria and Australia. This guide sets out where Ignition fits well, where it is one of several sound options, and where another platform serves a site better, so the platform decision stays a question of fit rather than default.

This post supports our PLC, SCADA and HMI programming service, where Ignition SCADA delivery, Perspective and Vision work, historian and reporting, and legacy SCADA migration all sit.

Is Ignition the right fit for your site

The right SCADA platform is the one that fits the existing PLC estate, the IT constraints and the in-house support skills, not the one with the longest feature list. Four characteristics decide most of the fit.

Licensing model

A server-based licence with no per-tag, per-client or per-screen fees. For sites with many workstations or large tag counts, the cost profile stays predictable as the system grows.

Browser-based clients

Perspective runs in a web browser and on mobile devices with no client installation, so operator access from tablets, office PCs and phones is straightforward.

IIoT and data integration

Native MQTT and Sparkplug support, a built-in historian and cloud connectors suit sites that need plant data connected to business systems, reporting tools or analytics.

MES and batch modules

Sepasoft MES and Batch Procedure modules extend Ignition into ISA-88 batch control, OEE and recipe management on the same database and tag structure as the SCADA layer.

Ignition is the clear choice on greenfield sites, on multi-site deployments where centralised architecture and predictable licensing pay off, and on sites that need plant data flowing to business systems. Other platforms can be the better fit on Rockwell-heavy sites with established FactoryTalk infrastructure, and where a heavily customised AVEVA or Citect system still holds real value. The migration question is covered below.

Perspective vs Vision: choosing your client architecture

Perspective is the browser-based client module and the right choice for new work: it runs on any device with a browser, scales across screen sizes and needs no installed software. Vision is the older thick-client module and is being phased out, so it should not be considered for new greenfield builds or projects. It remains on many existing systems, where it is still supported, but new work should be designed on Perspective from the start.

Build any new plant on Perspective. Treat Vision only as something you may inherit on an existing site, not as an option for new design.

Architecture patterns: standalone gateway vs Edge and MQTT

A single site can run a standalone gateway polling the PLCs directly, the simplest pattern for one plant with a manageable device count. As sites grow, or where a Unified Namespace is the goal, Edge gateways at the line or area publish over MQTT and Sparkplug to a central gateway, decoupling the field devices from the central system.

Two design points carry most of the risk:

  • Redundancy. Decide early whether the gateway needs a redundant pair. Where SCADA loss stops production, it usually does; for a reporting-only deployment it may not.
  • Database sizing. Tag history and alarm journals grow continuously. Size the historian database and its retention plan for the tag count and logging rates at design time, not once the disk fills.

Warm or cold standby

Ignition runs redundancy as a Master and Backup pair sharing the same configuration: when the Backup connects, it synchronises with the Master so both hold the same project and tag setup. The behaviour at switchover is set by the Standby Activity Level:

  • Warm standby. The standby runs as if active, short of logging data or writing to devices. Failover is fast, at the cost of extra device and network load from a second set of tag subscriptions.
  • Cold standby. The standby connects to the OPC servers but does not subscribe to tag values. It loads the system less and fails over more slowly, because tags must be subscribed and initialised when it becomes active.

Where a SCADA outage stops or risks the process, warm standby usually justifies the load. For reporting-focused deployments, cold standby is often the better balance. The choice belongs in the architecture phase, because it affects device load, network sizing and the failover time operations can expect.

Tag-model discipline and common pitfalls

Most Ignition projects that disappoint do so for reasons of process and design rather than the platform itself.

Pitfalls to design out from the start

  • Plan the tag model and User Defined Types before building screens. Retrofitting a tag structure after the graphics exist is slow and error-prone.
  • Set polling rates and query frequencies to what the process needs. Over-polling and unbounded queries are a common cause of gateway load.
  • Use built-in components and bindings before reaching for custom scripting, so the project stays maintainable by the next engineer.
  • Document configurations and standards so the system can be supported by someone who did not build it.
  • Plan historian retention and database maintenance up front, not after the database has grown unmanageable.

Alarm management to ISA-18.2

A good alarm system gives the operator a short list of valid, prioritised alarms that each require a response. That outcome is what the ISA-18.2 alarm-management lifecycle is built to produce, running from alarm philosophy and identification through rationalisation, design, implementation, operation, maintenance and monitoring. Ignition supplies the technical pieces: prioritisation, shelving, notification pipelines and an alarm journal. The decisive work is rationalisation, done with the process and operations team, where each alarm is justified, prioritised by consequence and time to respond, and stripped of duplicates and nuisance triggers. Designing to ISA-18.2 from the start is far cheaper than retrofitting it onto a plant where operators have already learned to ignore the screen.

OT security and networking for an Ignition deployment

An Ignition deployment lives on the operational technology network, so its security depends on the surrounding design: segment the control network from business systems, keep reporting paths outbound-only where possible, and control remote access. This work overlaps with OT network security.

The Purdue model, which underpins ISA-95, places the pieces. Field devices, PLCs and safety controllers sit at Levels 0 and 1. Ignition operator clients and the supervisory functions sit at Level 2. The gateway, tag historian and MES connections sit at Level 3. A Level 3.5 DMZ between OT and IT is where reporting paths and MQTT brokers terminate, rather than letting enterprise systems reach into the control network directly.

IEC 62443 formalises that layout into zones, groupings of assets with a common security requirement, and conduits, the controlled communication paths between them. Each zone is assigned a target security level from SL 1, protection against casual or coincidental misuse, to SL 4, protection against a sophisticated and well-resourced attacker. The practical effect is that the supervisory zone gets a defined target level, and every conduit in or out of it, including remote access and reporting, is identified and given controls that meet it.

Buying and supporting Ignition in Australia

Ignition is licensed by the server, with annual support priced as a percentage of the licence. Inductive Automation describes this as unlimited licensing: the licence does not cap tags, clients, screens or device connections, so the practical limit becomes the gateway hardware, the database and the network. That is why gateway sizing and polling discipline matter so much on large deployments. Pricing is quote-based and terms change, so confirm them with the vendor at the time of purchase.

Since 2023, Ignition has been sold and supported locally by Inductive Automation Australia, the vendor's wholly owned subsidiary and its first office outside the United States, which took over from the former distributor iControls.

Migrating from an existing platform

When migrating existing SCADA to Ignition is worth it

  • The existing platform is at or approaching end-of-support and the cost of maintaining it is rising.
  • The site has genuine IIoT, mobile-access or MES requirements the existing platform cannot meet.
  • The existing system carries significant technical debt: undocumented graphics, complex custom scripting, or no support from the original integrator.
  • The organisation is adding sites and wants one consistent SCADA platform across them.

Migration is a project in itself: tag migration, graphics rebuild, historian reconnection and operator retraining are real costs to weigh against the value the current system still holds. Our automation upgrades work covers staged migration that keeps a live plant running through the change.

A realistic project sequence

  1. Front-end design and control philosophy agreed before configuration begins.
  2. Tag model and User Defined Types built and reviewed.
  3. Factory acceptance testing against simulation, so logic is proven before site.
  4. Site acceptance testing and loop checks confirming each signal end to end.
  5. Live cutover with a defined rollback, line by line where the plant cannot stop at once.

This mirrors the method we use on every project, covered in our commissioning service. Mixed-vendor connectivity and the data flow up to MES and ERP sit with our systems integration work.

References

The standards and platform details referenced above are vendor and industry sources, cited so the technical claims can be checked against the originals. They are not Metromotion Controls measurements.

About the author

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.

Share:LinkedInX
Next step

Planning work in Control Systems?

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.