IIoT Solutions for Connected Industrial Operations 2026

2. IIoT Solution Areas

It is easiest to evaluate IIoT by the problem it solves. These are the most common solution areas, with the data each needs and how you would know it is working.

Choose one or two areas that are costly, well understood, and measurable, and use them to build the foundation that the others can share. For maintenance-specific detail, see our guides to predictive maintenance technologies and predictive maintenance software.

3. The Solution Stack: What You Actually Buy

A solution is rarely a single product. When you issue a requirement or an RFP, you are buying some combination of the following, and it helps to decide for each element whether you will buy, build, or have a partner assemble it.

4. Data Architecture That Scales: The Unified Namespace

Many plants have grown a tangle of point-to-point connections: controllers to SCADA, SCADA to a historian, the historian to the MES, and the MES to the ERP. Every new use case needs a new connection, and the data means something slightly different at each hop. A unified namespace (UNS) is an architectural pattern that addresses this. It is not a product you buy.

In a UNS design, systems publish their data to a central, well-structured message hub, typically an MQTT broker, under a predictable hierarchy that reflects the organisation (commonly following the ISA-95 equipment hierarchy of enterprise, site, area, line, and cell). Any authorised system can subscribe to what it needs. Producers and consumers are decoupled, so adding a new application means subscribing to existing data instead of building another integration.

A Topic Hierarchy Example

enterprise/site/area/line/cell/asset/measurement

example-co/sydney-plant/packaging/line-2/filler-01/motor/temperature

A message published to that topic might carry a payload such as the one below. It is shown as JSON for readability. In practice, the Sparkplug specification defines a compact binary payload and lifecycle messages on top of MQTT so that devices announce themselves and their status consistently.

{

"value": 71.4,

"unit": "degC",

"timestamp": "2026-10-23T02:15:00Z",

"quality": "good"

}

Where Each Protocol Fits

● OPC UA is widely used on the plant floor to read data from controllers and machines, with a rich information model and built-in security features.

● MQTT is a lightweight publish-subscribe protocol suited to distributing data between sites and systems, including over limited networks.

● Sparkplug is an Eclipse Foundation specification that standardises MQTT payloads and device lifecycle messages for industrial use, so different devices describe themselves in the same way.

● A common arrangement reads from equipment with OPC UA (or older protocols such as Modbus) at the edge, translates to MQTT with Sparkplug, and publishes to the namespace.

Trade-Offs to Plan For

● Governance: the namespace is only as good as its naming standards and data models. Decide who owns them and how changes are approved.

● Infrastructure: the broker becomes critical infrastructure and needs clustering, monitoring, backup, and recovery planning.

● Security: use encrypted connections, device and user authentication, and per-topic access control, so a compromised device cannot read or publish everything.

● Not a replacement for everything: historians, analytics stores, and enterprise applications still have roles. The namespace is the integration backbone, not the only data store.

● Fit: the pattern is not mandatory. Smaller sites with a handful of integrations may be well served by simpler designs.

5. Connectivity Choices

Whatever the network, design the edge to keep working when the connection drops, buffering data and continuing local control, then sending summaries when the link returns.

6. Security by Design

Connecting operational technology (OT) to IT networks and the cloud widens the attack surface, and attacks on industrial systems can have safety and production consequences. Security must be part of the solution design from the first sketch.

Useful references include the IEC 62443 series for industrial automation and control system security, NIST SP 800-82 on operational technology security, and CISA's industrial control systems resources. In Australia, the Australian Cyber Security Centre publishes OT guidance, and operators of critical infrastructure may have obligations under the Security of Critical Infrastructure Act 2018.

7. Integrating With Enterprise Systems

Connected operations create value when data reaches the systems where decisions and work happen. Plan integration with manufacturing execution systems (MES), enterprise resource planning (ERP), maintenance systems (CMMS or EAM), historians, data platforms and BI tools, quality systems, and digital twins. Avoid new point-to-point links: publish once to the shared data layer and let consumers subscribe or query. Agree a common asset model early, so that 'Filler 01' means the same thing as maintenance, production, and finance. Close the loop where it matters, for example by letting a confirmed alert create a maintenance work order automatically.

8. A Delivery Approach That Scales Beyond the Pilot

Many organisations run impressive pilots that never become standard practice, sometimes called pilot purgatory. The causes are usually a pilot designed as a one-off, no agreed data model, no owner, and no plan for support. Design the pilot as the first step of a rollout.

● Phase 1: Discover and prioritise: map solution areas to costed problems and pick one or two with clear baselines and sponsors.

● Phase 2: Design the foundation: architecture, naming and asset standards, security zones, and the operating model, before the first device is connected.

● Phase 3: Pilot on a real line or site: set success criteria and a baseline in advance, include operators in design, and time-box it.

● Phase 4: Productise: turn what worked into templates, standard edge builds, asset models, pipelines, and runbooks.

● Phase 5: Scale in waves: add similar assets and sites using the templates and measure each wave against its baseline.

● Phase 6: Operate and improve: define support, monitoring, model and data governance, and a regular review of value delivered.

KPIs for Operations

9. Build, Buy, or Partner: Evaluating IIoT Vendors

Questions to Ask Any Vendor

● Who owns the data and the data model, and can I export everything in open formats?

● Which open standards do you support (OPC UA, MQTT, Sparkplug, ISA-95 hierarchies)?

● Can the solution run at the edge, offline, and in my cloud of choice, or only in yours?

● What security evidence can you show, such as IEC 62443 certification of products or processes and SOC 2 reports for hosted services?

● How do you integrate with my MES, ERP, historian, and maintenance systems?

● How does the solution scale from one line to many sites, and what does each additional site cost?

● What support do you provide in my time zone and region, and what are the service levels?

● What are the total costs over five years, including licences, integration, support, and the cost of leaving?

● Can I speak to customers with similar assets, scale, and region?

10. Building the Business Case

Build the case from your own numbers. Identify the value levers (avoided downtime, higher throughput, lower scrap, energy savings, reduced site visits, safety and compliance benefits), establish baselines, and be conservative about the share you can capture. Then count all the costs: devices and installation, connectivity, platform and licences, integration, security, internal staff, training, and change management.

Here is a hypothetical illustration, not a benchmark. Suppose a packaging line produces output worth US$12,000 per hour and loses 40 hours a year to unplanned stops. If better visibility and faster response avoid a quarter of those stops, that is 10 hours multiplied by $12,000, or $120,000 a year, which you would weigh against the first-year and ongoing programme costs. Your figures will differ, which is why a pilot with a baseline is the best way to firm up the estimate.

11. Industry Applications

12. Common Pitfalls

● Starting with technology instead of a costed operational problem.

● Pilots that cannot scale because they lack standard data models, templates, and owners.

● No governance of naming and asset models, so data becomes inconsistent across sites.

● Choosing a solution that locks your data model to one vendor.

● Treating security as a later phase, or leaving remote access uncontrolled.

● Ignoring operators and maintenance staff, who decide whether the system is used.

● Underestimating support: someone must run, monitor, and improve the platform after go-live.

13. Choosing the Right Partner

IIoT sits between operations, OT, IT, and cloud, and no single supplier is strong in all of them. Be wary of any partner who claims otherwise. For control-system programming and plant-floor integration, you will usually need an OT or automation integrator. For the data and platform layers (cloud and edge architecture on AWS and Azure, containerised edge workloads with Kubernetes, Infrastructure as Code, DevSecOps and security, and ongoing managed IT operations), you need an IT and cloud partner who understands industrial constraints. The most important quality is the ability to bridge the two, with clear roles, shared standards, and knowledge transfer so you are not dependent on one party. Ask any partner how they would divide responsibilities with your OT team and your automation vendors.

14. Frequently Asked Questions

What are IIoT solutions?

IIoT solutions are combinations of connected devices, networks, edge and cloud platforms, applications, security, and services that give industrial organisations real-time visibility and control over assets, processes, and operations.

What does a connected industrial operation look like?

Assets, processes, people, and enterprise systems share data through a common architecture, so teams across sites see the same trustworthy picture of production, assets, energy, quality, and safety, and can act on it quickly.

What are the main IIoT use cases?

Common solution areas are asset health and reliability, production visibility and OEE, quality, energy management, remote operations, safety and compliance, fleet and logistics, traceability, and connected-worker tools.

What is a unified namespace?

A unified namespace is an architectural pattern in which systems publish their data to a central, well-structured hub, usually an MQTT broker, under a consistent naming hierarchy, so any authorised system can subscribe without building point-to-point integrations. It is a design pattern, not a product.

Should I use MQTT or OPC UA?

They often work together. OPC UA is widely used to read data from machines and controllers, while MQTT is well suited to distributing data across systems and sites. Sparkplug standardises MQTT payloads for industrial use.

How do I secure an IIoT deployment?

Maintain asset visibility, segment OT from IT, use strong identities and least privilege, control remote access, patch and harden where possible, monitor with OT-aware tools, manage supply-chain risk, and plan for recovery. Follow guidance such as IEC 62443 and NIST SP 800-82.

How do I choose an IIoT platform?

Start from the problems you need to solve, then compare options on open standards, data ownership and export, edge and cloud flexibility, security evidence, integration, scalability across sites, support in your region, and total cost, and test them in a pilot.

Should we build or buy IIoT?

Buy for well-defined solution areas where you need speed, build where you have strong engineering and differentiated needs, and use a partner to assemble and run it when you have skills gaps. Many organisations combine approaches, but protect data ownership.

How long does an IIoT pilot take?

Pilots are typically time-boxed to a few months, depending on scope, connectivity, and integration. Design the pilot as the first step of a rollout, with success criteria and a baseline set in advance.

How do I calculate IIoT ROI?

Establish baselines for the value levers you target, such as downtime, throughput, scrap, and energy. Estimate the share you can capture conservatively, compare with all programme costs, and validate the estimate in a pilot.

How do I connect legacy equipment?

Start with data the existing controllers already hold, and use edge gateways that translate older protocols such as Modbus to modern ones such as OPC UA or MQTT. Add retrofit sensors only where needed, and secure the connection carefully.

Why do IIoT projects stall after the pilot?

Common causes are pilots built as one-offs, no shared data model or templates, unclear ownership, weak support, and limited operator adoption. Plan the path to scale from the start.

16. Conclusion

IIoT solutions deliver value when they start from costed operational problems, rest on an architecture and security model that can scale, are delivered as templates rather than one-offs, and are owned by people who will run them. Choose partners and platforms that keep your data portable and your options open, pilot with a baseline, and expand in waves.

Planning connected industrial operations?nuwair.com cloud and edge architecture, Kubernetes, DevSecOps, Infrastructure as Code, and managed IT teams can help you design the data platform and security model, and work alongside your OT and automation partners. Talk to our team to scope your first IIoT solution.

Categories