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

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.

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.

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. For sites weighing a move off Citect or Geo SCADA, see our Citect and Geo SCADA migration guide. 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.

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

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.