inmation in 2026: Architecture, Pros, Cons, Alternatives
Most “inmation pros and cons” articles read like a feature checklist scraped off a datasheet, and they miss the only question that matters: does an object-oriented real-time data platform belong in your industrial stack, or are you really shopping for a historian or a broker? inmation software is an object-oriented industrial DataOps platform that pulls OPC, SQL, and MQTT sources into a single live object model rather than a flat tag list, and that single design choice drives almost every genuine advantage and every real drawback. This matters now because the 2026 industrial data landscape is crowded with historians, unified-namespace brokers, and cloud platforms that all claim the same territory. By the end, you will be able to place inmation precisely against PI System and a UNS-broker approach, and decide whether it fits using a concrete checklist rather than vibes.
What this covers: what inmation actually is and how its Core, Connector, object-model, scripting, and Web API layers fit together; where it sits in the modern industrial data stack; honest pros and cons; a side-by-side comparison matrix; and an architect’s evaluation decision tree.
Context and Background
Industrial sites have collected real-time process data for decades, and for most of that time the default answer was a historian — a time-series database optimized for high-frequency tag ingestion and long retention. The incumbent, OSIsoft PI (now AVEVA PI System), remains the most widely deployed example, and a generation of engineers thinks of plant data as “PI tags.” That tag-centric mental model is exactly what newer platforms push against.
inmation entered this space as a different shape of tool. Instead of storing thousands of independent tags, it builds a hierarchical object model — a tree where assets, properties, and time-series values are nodes that can carry relationships, metadata, and behavior. The vendor refers to the live model as system:inmation. The platform connects to OT sources through OPC UA, OPC DA, SQL, MQTT, and REST, normalizes them into that object tree, and exposes the result through a Web API and scripting engine. In ecosystem terms, inmation grew up as an independent German DataOps vendor and now sits within the broader AVEVA/inmation industrial-software orbit; treat any specific packaging or branding claim as something to confirm against the vendor’s current documentation rather than as settled fact.
This places inmation in an awkward-to-classify middle ground. It is not purely a historian, not purely a message broker, and not a cloud analytics suite. It is closer to what people now call an industrial DataOps layer — the connective tissue between OT and IT. That category barely had a name a few years ago, which is part of why evaluating inmation software is confusing: buyers reach for the comparison they already know (usually “is it cheaper than PI?”) rather than the comparison that fits. For the broader pattern it borrows from, see our deep dive on unified namespace architecture for industrial IoT. For the protocol foundations it relies on, the OPC Foundation’s OPC UA specification is the authoritative reference.
Why does this matter in 2026 specifically? Two pressures converged. First, OT/IT convergence and cloud analytics created real demand for contextualized data — models, not tags — because machine-learning and digital-twin projects choke on undocumented tag strings. Second, the unified-namespace movement made “one structured real-time view of the plant” a mainstream architectural goal rather than a fringe idea. inmation software predates the UNS hype but lands squarely in its slipstream, which is both a marketing gift and a source of confusion, since a product and an architectural pattern get compared as if they were the same kind of thing.
How inmation Software Works: The Reference Architecture
In short: inmation software is an object-oriented industrial DataOps platform. A central Core hosts a live object model; distributed connectors ingest OPC, MQTT, SQL, and REST sources; a Lua engine computes KPIs; an embedded store holds history; and a Web API serves everything. The object model — not a flat tag list — is the design centre.
inmation software is built as a small number of cooperating components: a central Core that holds the object model and orchestrates everything, distributed Connectors (sometimes deployed as edge relays) that talk to OT sources, an embedded time-series store, a Lua-based scripting and KPI engine, and a Web API plus web clients for access. Data flows from devices through connectors into the object model, where scripts compute derived values, and out through the API to consumers. That object model — not a tag database — is the centre of gravity.
Figure 1: inmation software reference architecture — OT sources enter through the connector layer, normalize into the central object model in the Core, and surface through the scripting engine, time-series store, and Web API.
The diagram traces four bands. On the left, OT and source systems (OPC UA/DA servers, SQL databases and historians, MQTT/Sparkplug brokers, files and REST endpoints) feed the connector layer. Connectors normalize and buffer that traffic and hand it to the Core, where the object model, the Lua scripting and KPI engine, and the embedded time-series store live. The access layer — Web API, OData, and the web studio and clients — sits on top. The single arrow worth remembering is that everything converges on, and radiates from, the object model.
The Core and the object model
The Core is the runtime that hosts system:inmation, the live hierarchical model. Each node can be an asset folder, a property, a connected data point, or a computed value. Because the structure is a tree with typed relationships, you can model a plant the way it physically exists — site, area, line, machine, signal — instead of flattening everything into a tag namestring. This is the same modeling instinct behind a unified namespace, and it is the platform’s defining trait. The Core also handles security, model versioning, and the lifecycle of the objects beneath it.
The practical payoff is inheritance and reuse. Define a template for a pump once — its expected properties, alarm thresholds, and KPI scripts — and instantiate it fifty times across the model. When you later refine the template, every instance updates. A flat tag database cannot express that relationship; it stores fifty unrelated copies. This object-template pattern is where inmation software earns its keep on large, repetitive asset estates, and it is also where a poorly governed model can amplify mistakes fifty-fold. The abstraction cuts both ways, which is the recurring theme of any honest inmation assessment.
A second Core responsibility worth naming is security at the object level. Permissions attach to nodes in the tree, so you can grant a contractor read access to one line without exposing the whole site. In a flat namespace, access control is coarser and harder to reason about. The model-first design makes fine-grained governance natural rather than bolted on — provided someone actually configures it.
Connectors, relays, and edge
Connectors are the ingress. They implement the OT protocols — most importantly OPC UA and OPC DA, plus MQTT, SQL polling, and REST — and they can run remotely as relays close to the equipment. Running a connector at the edge means store-and-forward buffering survives a WAN outage and the Core sees a clean, reconnect-tolerant stream. For a fuller picture of how this layer compares to traditional SCADA and OPC gateways, see SCADA vs OPC vs IoT platform vs data historian in 2026.
The relay topology also shapes how inmation software scales geographically. A multi-site operator can place relays at each plant, let them buffer locally, and stream into one or a few Cores that hold a federated model. That keeps WAN bandwidth predictable and isolates a site outage from the rest of the estate. The cost is operational: every relay is a process to monitor, patch, and secure, and a federated model needs deliberate naming so two sites do not collide in the namespace. Connectivity breadth is a real inmation strength, but breadth without a deployment standard becomes sprawl.
Scripting, KPIs, and the Web API
Two layers turn raw signals into something useful. The Lua scripting engine lets you attach logic to objects — compute a rolling KPI, validate a reading, raise an event, or transform units — so calculation lives next to the data rather than in a downstream tool. The Web API (with OData-style access) is how external systems read the model and history, which is what makes inmation usable as a serving layer for dashboards, cloud pipelines, and operational apps. If you only remember one thing: the object model is the contract, scripting enriches it, and the API exposes it.
Choosing Lua rather than a mainstream language is a deliberate trade. Lua is small, fast, and embeddable, which suits in-platform scripting and keeps the runtime light. The downside is familiarity: most data engineers reach for Python, and Lua is one more language for a team to learn and support. This is a microcosm of the whole platform — a clean technical choice that narrows the talent pool. When you weigh inmation software against alternatives, the scripting language is a small line item, but it is symptomatic of the broader “powerful but niche” character that defines the product.
Where inmation Fits in the Modern Industrial Data Stack
The hardest part of evaluating inmation software is not understanding it — it is positioning it. It overlaps with three adjacent categories at once, and the right comparison depends on what job you are hiring it to do.
Figure 2: Where inmation software fits — it can sit alongside or downstream of a historian and a UNS broker, acting as the modeled integration layer that feeds analytics, cloud, and operational apps.
In the figure, plant and OT sources on the left fan out to three real-time integration options: a historian such as PI System, a UNS broker on MQTT/Sparkplug B, and inmation as an object platform. Crucially, inmation can consume from both a historian and a broker rather than only competing with them — it ingests, models, and re-serves. On the right, consumers (analytics/BI, cloud and data lake, operational apps) draw from the modeled layer. This is the platform’s most honest selling point: it is frequently additive to an existing stack.
Against a historian like AVEVA PI System, the difference is structural. A historian excels at swallowing millions of high-rate tags and retaining them cheaply for years; its data model is essentially a flat, well-indexed tag space with asset frameworks bolted on. inmation leads with the model and treats storage as a feature of the objects. If your problem is “store everything fast and forever,” a historian wins. If your problem is “make sense of heterogeneous OT data as a coherent asset tree,” inmation’s shape fits better. Our comparison of SCADA historian architecture in 2026 unpacks the historian side in depth.
Against a UNS broker approach — HiveMQ or another MQTT broker carrying Sparkplug B — the trade is openness versus completeness. A broker is lightweight, event-driven, and vendor-neutral, but a raw broker gives you transport and a namespace convention, not modeling, history, or computation. You assemble those from other parts. inmation ships the model, the store, and the scripting in one platform, at the cost of being a single vendor’s product. Against cloud platforms (a data-lake-plus-analytics stack), inmation is usually the on-prem, real-time, OT-adjacent layer that feeds the cloud, not a replacement for it.
So the fit question reduces to three buckets: replace a historian (rarely the right framing), add a modeled DataOps layer over existing systems (the common one), or stand up an integration backbone for a greenfield site (where it competes most directly with assembling a UNS yourself).
A worked example of the fit
Consider a specialty-chemicals operator with eight plants, three SCADA vendors, two legacy historians, and a new MQTT broker from a recent line upgrade. The pain is not storage — both historians work — it is that every analytics request becomes a bespoke integration against a different system with different tag conventions. This is the canonical case where inmation software fits: deploy relays at each plant, model the eight sites as one consistent object tree, ingest from the historians and the broker, and expose a single Web API. Analysts then query “any plant / any reactor / temperature” with consistent context, and the cloud team ingests modeled data instead of eight raw feeds.
Now flip the scenario. A single greenfield bottling line wants cheap, high-rate storage and a couple of trend screens, with a small team and no DataOps function. Here inmation software is over-specified — a lean historian or even a broker-plus-database would deliver faster with less to learn. The platform’s value is proportional to integration complexity and the number of consumers, not to raw data volume. Sizing that complexity honestly is the single best predictor of whether the platform pays off.
inmation Pros and Cons: An Honest Assessment
Now the part the listicles get wrong by treating every bullet as equal weight. The genuine strengths and weaknesses of inmation software cluster tightly around its object-model design, and most of them are two sides of the same coin.
The genuine pros
A real object model, not a tag soup. This is the headline advantage. Modeling a plant as a typed hierarchy with relationships makes context portable: a downstream app reads “Line 3 / Mixer / Temperature” with its metadata attached, not an opaque tag string it has to decode. For teams drowning in undocumented tag conventions, this alone can justify a pilot.
Breadth of OT connectivity. Native OPC UA and OPC DA, MQTT/Sparkplug, SQL, and REST connectors cover the messy reality of a brownfield plant where five vendors’ equipment speak five dialects. The relay/edge model adds store-and-forward resilience that matters on unreliable plant networks.
A central namespace and serving layer. Because everything converges on system:inmation and re-exposes through the Web API, the platform can act as the single read surface for many consumers — dashboards, cloud ingestion, ML pipelines — instead of each one integrating with every source separately. That is the unified-namespace value proposition delivered as a product.
Scripting and edge computation. The Lua engine puts logic next to data: KPIs, validation, unit conversion, and event detection run in the platform. This reduces the “extract, transform somewhere else, hope it stays in sync” tax that plagues historian-plus-ETL designs.
The genuine cons
A smaller ecosystem. Compared with PI System’s decades-deep install base, partner network, and library of pre-built connectors and dashboards, inmation is niche. Fewer third-party integrations exist out of the box, and fewer reference architectures are public. You are more likely to build than to download.
A real learning curve. The object model is powerful precisely because it is not a flat tag list, and that abstraction takes time to internalize. Teams used to “make a tag, trend a tag” face a conceptual shift, and Lua scripting is another skill to acquire and maintain.
Talent availability. This follows directly from the ecosystem size. The pool of engineers with production inmation experience is far shallower than the PI talent pool. Hiring, contracting, and even getting community answers are harder, which raises key-person risk.
Vendor concentration and licensing. A single-vendor platform that holds your model, history, and computation is a concentration of risk and cost. Licensing for commercial industrial platforms is typically negotiated and non-trivial, and consolidation in the AVEVA/inmation ecosystem means your roadmap dependency is on one vendor’s strategy. Confirm current commercial terms directly; do not assume.
Weighing the pros against the cons
The honest way to read this list is that most pros and cons are the same property viewed from two sides. The object model is both the standout strength and the source of the learning curve. The all-in-one bundling of model, storage, and scripting is both convenient and the root of lock-in. The niche, focused design that makes inmation software coherent is exactly what makes its ecosystem and talent pool small. There is no version of the platform that keeps the upside and discards the downside, because they share a cause.
That symmetry is useful for decision-making. It means the question is not “are the pros good enough?” but “does my situation reward the trade this platform makes?” An operator with heavy OT-integration pain, multiple consumers, and the appetite to invest in a modeled approach is on the favorable side of every trade. A team that mostly needs storage, has little DataOps capacity, and prizes vendor neutrality is on the unfavorable side of every one. The pros and cons of inmation software do not net out to a universal score — they resolve differently for each buyer, which is exactly why a generic listicle is the wrong tool for this decision.
Comparison Matrix: inmation vs PI System vs UNS Broker
The cleanest way to choose is to compare on the dimensions that actually differ, not on marketing categories. The table below is a decision matrix, and the diagram after it maps the positioning.
| Dimension | inmation (object platform) | AVEVA PI System (historian) | UNS broker (MQTT / Sparkplug B) |
|---|---|---|---|
| Core data model | Hierarchical object model with relationships | Flat tag space plus Asset Framework | Topic namespace convention, no built-in model |
| Primary strength | Modeled DataOps and OT integration | High-rate ingestion and long retention | Lightweight, open, event-driven transport |
| Time-series storage | Embedded store within the platform | Mature, purpose-built historian engine | None by default — add a historian/DB |
| OT connectivity | OPC UA/DA, MQTT, SQL, REST connectors | Broad interface library, huge connector set | MQTT/Sparkplug native; others via bridges |
| Computation | Built-in Lua scripting and KPI engine | Asset analytics and calculations | External — compute lives elsewhere |
| Ecosystem and talent | Niche; smaller pool, fewer integrations | Very large install base and talent pool | Open standard; broad MQTT skills, UNS newer |
| Openness / lock-in | Single-vendor platform | Single-vendor, deep lock-in via Asset Framework | Most open; mix-and-match components |
| Best fit | Modeled integration layer over many sources | Enterprise historian of record | Real-time backbone you compose yourself |
Figure 3: Comparison positioning — each option’s defining strength and its defining weakness, so the trade-off is visible at a glance rather than buried in feature lists.
The diagram distils the matrix into three branches. inmation trades a strong central object model and OT breadth against a smaller ecosystem and shallower talent pool. PI System trades a mature historian and a vast install base against a tag-centric model and heavier licensing. The UNS-broker route trades openness and an event-driven design against the need to add modeling and storage yourself. There is no universally correct pick; there is only the pick that matches your constraints. For a parallel three-way analysis in the analytics tier, our AVEVA PI vs Cognite Data Fusion vs Tulip comparison for 2026 is a useful companion.
A common winning pattern in 2026 is not to choose one. Many sites keep PI as the historian of record, run a UNS broker for event-driven distribution, and use a modeled DataOps layer (inmation software or a competitor) to give consumers one coherent, contextualized read surface. The platforms are more complementary than the “vs” framing suggests.
It is worth being concrete about why that hybrid works. The historian’s job — durable, high-rate, regulatory-grade retention — is one it does better and cheaper than a general platform, so leaving it in place reduces both cost and lock-in. The broker’s job — low-latency, publish-subscribe distribution of events — suits real-time apps that should not poll an API. inmation software then does the job neither of those does well: it imposes a consistent object model across the heterogeneous mess and serves it through one contract. Each component plays to its strength, and the modeled layer becomes the place where context lives rather than the place where everything is stored. The failure mode to avoid is letting the platform quietly absorb responsibilities it is not best at — for instance, becoming your only copy of regulated history — simply because it was already there.
Thinking about total cost of ownership
License price is the part of the decision buyers fixate on and the part that misleads them most. The dominant cost of any modeled DataOps platform is rarely the license — it is the people and time to model your plant, write and maintain scripts, operate relays, and keep the model governed as the site changes. A realistic total-cost-of-ownership view
