Developers
The path a signal takes from a machine on your floor into the Singularity, the Ignition setup that publishes it, the topic it lands on, and what the documentation does not specify.
One path carries operational data off a plant floor and into the Singularity. It is worth reading end to end before any single piece gets scoped, because nearly every decision later in an implementation sits somewhere on it.
Steps one through three run inside your network, on infrastructure your team owns and operates. Step four onward runs in the mode40 cloud on AWS. The boundary between them is a single outbound MQTT connection.
The site opens the connection to mode40. mode40 does not open a connection into the site. For a network security team this is usually the first question and it should be the shortest answer on the page.
The one network dependency is outbound internet from the infrastructure Ignition runs on. Confirm it early, because it is a firewall change on your side and firewall changes have lead times.
The on-site MQTT client is the entire mode40 footprint inside the plant, and it is Ignition with the MQTT Transmission module, running on infrastructure your team owns. There is no on-premise install of the platform, no air-gapped deployment, and no deployment into cloud infrastructure a customer controls. If a mandate requires one of those, settle it in the first conversation. Architecture and deployment states this in full.
Ignition on site is the recommended collection hub, and mode40’s own architecture places it there. It reaches floor equipment over the protocols that equipment already speaks.
Which of the three a given machine uses is a property of that machine and not a choice made at the platform. Where a machine speaks none of them today, that is a task on the site rather than a task in the platform, and it belongs on the connectivity list before it belongs in a phase plan.
Nothing bespoke gets written. The publisher is Ignition with the Cirrus Link MQTT Transmission module, configured in the Ignition Gateway.
Only tags under that provider publish. A tag that lives anywhere else in the Gateway is invisible to the platform, which is the single most common reason a machine that is clearly connected in Ignition never appears downstream.
Metrics may be OPC tags, reference tags, or expression tags, so a value the platform needs can be derived in Ignition rather than instrumented on the machine. UDTs are strongly recommended. A user-defined type instantiated across every asset of a kind is what keeps tag naming identical from the tenth machine to the hundredth, and tag naming is what the model binds to.
Topics follow ISA-95 Part 1, six levels deep.
Capitalization and spelling must match exactly. The topic path is the address the platform resolves against, and a segment spelled two ways is two assets as far as the platform is concerned. Settle the naming for the enterprise, sites, areas, and lines once, before the first transmitter goes live, because renaming a level later means re-pointing every asset under it.
Asset model has the hierarchy these segments come from and what breaks when the naming drifts. MQTT topic access rules are a customer responsibility, defined during implementation alongside firewall and VLAN posture, and Division of responsibilities lists them with the rest.
mode40 issues the certificate and the credential the transmitter authenticates with. Provisioning is manual, per site.
Plan for it. Every new site is a request to mode40 and an install on your Gateway, and neither happens on the afternoon someone decides to add a plant. Where a site has a certificate lifecycle policy of its own, raise it during implementation rather than at renewal.
Nothing below is documented. These are the first questions a technical reader asks about an MQTT connection, and inferring an answer would be worse than naming the gap.
What the documentation does say is that the client should handle transmission failures gracefully, with mechanisms in place to retry sending data or to log errors. Read that as written: it places the requirement on your client. It describes no platform behaviour behind it.
If an outage-recovery guarantee is a condition of your deployment, get it answered in writing during implementation. Do not read the absence above as a promise in either direction.
Inside your network: the floor equipment, Ignition, the MQTT Transmission module, and the firewall and VLAN posture around all three. Your team owns the configuration and the uptime of each.
In the mode40 cloud: the broker and the platform itself, running on AWS, multi-tenant, delivered in the browser. Databases sit in private VPCs. They are not exposed to the internet and are reachable only by the platform backend, which authenticates with a JWT.
The AWS region is chosen per customer at onboarding. Canadian data runs in AWS Canada Central in Montreal, US data in US-East or US-West, and data does not cross a border unless that movement is explicitly configured. Identity runs on OAuth 2.0 with AWS Cognito, which supports multi-factor authentication and password policies. Security and governance covers identity, audit logging, and certification status.
Every signal that arrives is schema-normalized and source-tagged, so every module downstream reads the same values and can tell which system produced each one.
Connection health monitoring watches each connection continuously. When one drops it is flagged before a module works from stale data. This matters more than it sounds like it should: the failure mode of an operational platform is rarely a loud error. It is a screen that still shows a number after the machine behind it stopped reporting.
The flag tells you a connection is down. Restoring it is site-side work, because the break is almost always somewhere on the path between a machine and Ignition.
Connectivity is the long pole in an implementation, and the work is physical rather than software. That is the single most useful thing to know before scheduling one.
What actually blocks a site: a legacy controller sitting behind NAT waiting on a firewall change, a serial-only machine whose protocol has to be reverse-engineered before it can report at all, an OPC UA server not yet installed on a PLC that could otherwise report today. None of those is solved by the platform, and each one consumes site time and often a change window.
Implementation runs a dedicated network and machine connectivity assessment before configuration starts, followed by a readiness gate that produces a readiness score and a site tier. Both exist because this is where projects slip. Division of responsibilities has the full sequence and the split of who does what. What the published tags have to look like once they arrive is in Data models.
We use cookies to understand how the site is used and to connect form submissions to earlier visits. No analytics or marketing cookies are set until you choose. Privacy Policy