Litmus Edge vs Ignition: Edge Data Platform or Plant App Platform?

A data team wants one clean stream from twelve plants into a lakehouse. The controls team wants local screens that keep working when the wide area link drops. Both point at an "edge" product, and the shortlist reads Litmus Edge vs Ignition. The two meet at the box next to the PLC, then head in different directions.

We make cloud OEE software, which reads data from tools like these, and we resell neither. For a wider set of options, see our Litmus Edge alternatives guide; this page stays with the pair.

Litmus Edge vs Ignition at a glance

Paraphrased from the vendor pages linked below, read on 13.11.2026.

What Litmus Edge does, per litmus.io

Litmus sells Litmus Edge as one product in a wider industrial data platform. As of 13.11.2026, its pages describe:

• Its place in the stack. On the Litmus Edge product page, Litmus Edge is the layer between machines and enterprise software: it takes data from assets, gives it structure, runs analytics and apps on site, and passes the result up.
• Getting data off machines. The Litmus data connectivity page describes native drivers, automated discovery that shows device type, vendor, IP and protocol, and tag discovery for large signal hierarchies. It ingests events, alarms and batches as well as time series. Per the DeviceHub documentation, DeviceHub maps device registers to named tags, for makers such as Siemens, Allen Bradley and Hitachi.
• Shaping the data. Litmus Edge normalizes values, adds context from assets and metadata, stores time-series data locally and keeps reusable machine and line data models.
• Logic and apps. The Flows Manager documentation says flows are based on Node-RED, a visual programming tool. The Analytics documentation describes flows of connected processors that can also run machine learning models. The product page lists built-in industrial KPIs, anomaly detection and a Docker-based application runtime.
• Sending data up. Per the product page, its targets include cloud platforms, enterprise software, databases and message brokers. The Litmus documentation home says it publishes over OPC UA and MQTT, and lists Litmus Unify separately as the MQTT broker and Unified Namespace.
• Many sites. The Litmus Edge Manager page calls it the central control plane for distributed Litmus Edge deployments, with over-the-air updates and version control for data models across sites.

Check early: which of your controllers the native drivers cover, and who owns the data models after go-live.

What Ignition and Ignition Edge do, per Inductive Automation

Inductive Automation makes Ignition. As of 13.11.2026, its pages describe:

• What it is for. The Inductive Automation homepage presents Ignition as an application platform for industry, for building SCADA, IIoT and MES software. Its MES entry reads "Track your production, manage recipes, calculate OEE, and more."
• The server. The Ignition platform page frames the product as one server for all plant-floor systems, running across operating systems, with SQL, Python, OPC UA and MQTT as its base and a bundled Designer for building applications.
• Screens and records. The Ignition modules page lists Vision for operator and office screens, Perspective for HTML5 apps that fit any screen size, SQL Bridge for logging to SQL databases, a historian suite and a Reporting module for PDF reports.
• Ignition Edge. The Ignition Edge page presents two product options: Edge IIoT for data communication at the edge, and Edge Panel for visualization and control at the edge. Both go onto devices next to the machines or at remote sites.
• Edge connectivity. Ignition Edge acts as an OPC UA server and client, lists drivers for Allen-Bradley, Siemens, Mitsubishi, Modbus, DNP3 and Omron, and can publish to an MQTT broker using Sparkplug.
• When the link drops. Ignition Edge talks to a central Ignition server through the Gateway Network and MQTT. Edge Panel adds a 35 day buffer for PLC data while the network is down, and store and forward once it is back.

Check early: which work stays on Ignition Edge, which goes to the central gateway, and who builds the screens.

Litmus Edge vs Ignition, job by job

Talking to controllers. Both carry their own drivers: Litmus adds device and tag discovery, Ignition Edge lists drivers by brand. Put your controller list in front of both and get an answer per machine.

Making the data consistent. Litmus puts the weight on normalization and reusable data models, versioned centrally. Ignition's pages put it on what you build on the server with tags, SQL and Python. Ask both how a model change reaches twenty sites.

Logic at the edge. Litmus names Node-RED based flows and Docker apps; the Ignition Edge page says Edge can run scripts and create REST APIs from the edge. That suits different builders: a data engineer wiring flows, or a controls engineer writing gateway scripts.

People at the line. Ignition's pages centre on screens, with Edge Panel for a local HMI. Litmus's pages centre on analytics, KPIs and alerts, with data published to other systems. Decide who will look at the result before picking the tool.

Sending data up. Both name OPC UA and MQTT. OPC UA, per the OPC Foundation, folds the older OPC Classic specifications into one extensible framework. MQTT, per mqtt.org, is an OASIS standard and a lightweight publish and subscribe transport. Our OPC UA vs MQTT guide explains the difference.

Running many sites. Litmus Edge Manager handles devices, updates and model versions from one place; Ignition Edge feeds a central Ignition system. Ask each how a site that was offline for a week catches up.

Can Litmus Edge and Ignition run together?

On paper, yes. The Litmus Ignition Integration documentation describes a module for Inductive Automation's Ignition platform that gives Litmus Edge read and write access to Ignition tags, so Litmus analytics and integrations can use them. A plant could keep Ignition for screens and alarms and use Litmus Edge to model and ship the same tags to the cloud. The same page asks for Ignition 8.1.x or 8.3.x and Litmus Edge 3.22.0 or later, and the connection uses port 4778 by default.

Two systems on the same tags need clear owners: who names tags, who changes the model, and which side writes back to the controller.

Where OEE and stop causes fit

The ISA-95 standard page at isa.org places PLCs and other control devices at Level 2 and puts MES and SCADA at Level 3, manufacturing operations management. An edge platform moves Level 2 data upward. OEE is a Level 3 job: lost time by line and shift.

Ignition lists calculating OEE under MES, and Litmus lists built-in industrial KPIs. Whoever builds OEE must own three things no tag carries: the shift calendar, the ideal rate per product, and the stop reasons operators pick from. The tag says the filler stopped at 10:42. The operator says the label reel ran out.

Pick Litmus Edge if, pick Ignition if, or run both

More on the layers: PLC vs SCADA vs MES and edge vs cloud for shop floor data.

Where Fabrico fits for an edge or data team

Edge data platforms, SCADA, HMI, connectivity servers and DataOps tools are outside what Fabrico sells. Fabrico measures OEE in the cloud, with a light MES around it: the Level 3 job above. Our MES and OEE overview has the full picture; in short:

• Signals in. Stops and counts come from a PLC, sensor or counter. Our machine connectivity page lists protocols including OPC UA, Modbus, PROFINET and MQTT, and says the gateway can store machine data offline for up to 30 days. A machine review at the start agrees the route per machine.
• Reasons and views. The operator picks the stop reason on a tablet or phone. OEE, downtime and lost money appear per line and per shift, in a browser and in iOS and Android apps.
• Hand-work and older machines: Where no tag exists, the camera add-on counts finished units, so the edge team has nothing to wire for that station. Video is a live view a supervisor opens on request; in the standard setup Fabrico keeps no recordings. Camera-suggested stop reasons are planned (Roadmap) and are not in the product today. Details: the camera add-on for OEE.
• Getting results out: REST API, webhooks, or an Excel or CSV file.
• Outside Fabrico: an edge app runtime, tag modelling for other systems, SCADA screens, process control or inspection vision.

For a data team, the split is easy to write down. The edge platform owns tags, models and pipes. The OEE layer owns the shift: planned time, reasons, and the loss ranking the morning meeting works from.

Have a list of your edge devices and sites? Send it with your demo request, and we will show which machines Fabrico would read from and where operators add the stop reason.

Worked example: a link drop, a buffer and the OEE sum

Sample numbers, not a customer's line and not a product screen. One filling line runs a 480 minute shift with 40 minutes of planned breaks, so planned production time is 440 minutes. At an ideal 50 units a minute, the line could make 22,000 units.

The machine signal shows 66 minutes stopped, so run time is 374 minutes and availability is 374 / 440 = 85.0%. At the ideal rate, 374 minutes would make 18,700 units; the line made 16,270, so performance is 87.0%. Inspection rejected 488, leaving 15,782 good units, so quality is 97.0%. Multiplied: 85.0% x 87.0% x 97.0% = 71.7% OEE, the same as 15,782 good of 22,000 possible (how the OEE calculation works).

Midway through the shift, the link to the central systems was down for 20 minutes while the line kept running. The edge layer buffered the data and sent it later. Without that buffer, a dashboard could have shown 20 phantom minutes of downtime and 80.5% availability. Ask both vendors to show this case live.

Because the edge buffer filled the gap, all 66 stopped minutes are real stops: label reel change 21, changeover 19, waiting for bottles 14 and short stops 12. Without the buffer, the label reel would have shared the list with 20 minutes of network outage.

Questions to ask both vendors

• Which of our controllers do your drivers cover today, and which need an extra driver or an outside server?
• Where does the data model live, and who changes it when a line is rebuilt?
• What keeps running on the edge device when the link is down, and how long is data buffered?
• Who builds the operator screens, and who maintains them after go-live?
• How do you push an update to many sites, and how do you roll it back?
• Which OEE inputs come from tags, and where do planned time, ideal rates and stop reasons live?
• Who supports a mixed setup, such as Litmus Edge reading Ignition tags?

Related: OPC UA for OEE and our ISA-95 guide.

What people ask next

Is Litmus Edge a SCADA system?

No. In Litmus's own words it is an industrial edge data platform, and its product page lists SCADA platforms among the systems it integrates with. Operator screens are the job of a SCADA or HMI such as Ignition.

What is the difference between Ignition and Ignition Edge?

Inductive Automation positions Ignition as the central server software for a plant. Ignition Edge goes onto devices out at the machines or remote sites, is offered as Edge IIoT or Edge Panel, and syncs to a central Ignition server. Its FAQ says the two share the same basic technology.

Can Litmus Edge read tags from Ignition?

Litmus documents an Ignition Integration module for the Ignition platform that gives read and write access to Ignition tags from Litmus Edge. Ask both vendors who supports the module once it runs in production.

Do Litmus Edge and Ignition support OPC UA and MQTT?

Yes, per their pages. Litmus's documentation says Litmus Edge publishes over OPC UA and MQTT. Ignition is built on technologies including OPC UA and MQTT, and Ignition Edge acts as an OPC UA server and client and publishes to MQTT brokers using Sparkplug.

Can either one calculate OEE?

Ignition's homepage lists calculating OEE among its MES uses, and Litmus lists built-in industrial KPIs for Litmus Edge. OEE also needs planned time, ideal rates and stop reasons, so ask who will set those up.

Does Fabrico replace Litmus Edge or Ignition?

No. Fabrico measures OEE in the cloud and adds a light MES; it is neither an edge data platform nor SCADA. Machine signals from a PLC, sensor or counter give it the stops and counts, operators type the reason on a phone or tablet, and results go out by REST API, webhooks or an Excel or CSV file.

Want a walk-through of OEE with stop reasons? Book a demo.