IIoT & Industrial Connectivity
IIoT & Unified Namespace - The Data Backbone That Makes Manufacturing AI Work
Every AI initiative in manufacturing fails or succeeds at the data layer. Predictive maintenance models trained on bad data predict nothing. Agentic AI grounded in incomplete IIoT signals makes wrong decisions. Computer vision fed by poorly calibrated cameras flags false positives until the line supervisor disables the system. The intelligence is downstream of the connectivity. Fix the connectivity first.
Ajinkya Technologies builds industrial IoT foundations for manufacturers - connecting PLCs, SCADA, sensors, and legacy machines over OPC-UA, Modbus, and MQTT into a Unified Namespace architecture. Every machine signal gets a single, contextual, standardised address. The AI layer above it gets clean, real-time data instead of the brittle point-to-point integrations that break every time a machine firmware updates.
OPC-UA, Modbus, and MQTT - connecting every machine regardless of age
Modern PLCs speak OPC-UA natively. Legacy drives, older controllers, and third-party equipment speak Modbus RTU or TCP. Sensors, edge devices, and high-frequency telemetry sources speak MQTT. A real factory floor has all three - often on the same line.
We design and deploy the protocol layer that connects all of them into a single data pipeline. OPC-UA servers for new SIEMENS, Rockwell, and Beckhoff PLCs. Modbus gateways for legacy equipment where the controller has no network port and no intention of getting one. MQTT brokers with edge clients for high-frequency sensor data - vibration, temperature, current - that needs to reach the historian without losing samples.
For machines with no connectivity at all - older motors, pneumatic systems, utility equipment - we retrofit non-invasive sensor clamps and edge gateways. The machine does not know it is being monitored. Production does not stop for the installation.
- OPC-UA: native connection for modern Siemens, Rockwell, Beckhoff, Schneider PLCs and SCADA
- Modbus RTU/TCP: legacy PLC, drive, and controller connectivity without hardware replacement
- MQTT: high-frequency sensor telemetry, IoT device connectivity, lightweight edge publishing
- Non-invasive retrofit: vibration clamps, current transformers, temperature probes for legacy machines
- Protocol translation at the edge: any machine signal normalised to a common format upstream
- Multi-vendor, multi-age shop floors handled in a single connectivity architecture
Unified Namespace - one address for every signal on the shop floor
Point-to-point integration is how most factories currently connect systems. Machine A sends data to System B via a custom API. Machine C talks to System D via a database export. System B and System D have never met. When you add AI - which needs data from A, B, C, and D simultaneously - you are integrating with every one of those point-to-point connections individually. It is expensive, fragile, and breaks constantly.
A Unified Namespace eliminates the point-to-point problem. It is a single data bus - typically built on an MQTT broker with a structured topic hierarchy - where every machine, system, and data source publishes its current state. Any consumer - the MES, the AI model, the SCADA dashboard, the ERP - subscribes to the signals it needs. Publishers and consumers are decoupled. Adding a new AI use case means subscribing to existing topics, not building a new integration.
The topic hierarchy mirrors the physical plant: enterprise/site/area/line/machine/signal. Every signal on the shop floor has one canonical address. The AI layer has one place to read from.
- Single MQTT-based data bus: every machine publishes, every system subscribes
- Structured topic hierarchy: enterprise/site/area/line/machine/signal
- Decoupled architecture: add a new AI use case without building a new integration
- Point-to-point integrations retired progressively as UNS adoption expands
- Real-time pub/sub: AI models and dashboards see current machine state, not batch exports
- ISA-95 aligned hierarchy for compatibility with MES and ERP data models
Edge computing - line resilience when the cloud is unavailable
Cloud connectivity should be an amplifier, not a dependency. A factory floor that stops collecting data when the internet goes down is not an Industry 4.0 deployment - it is a connectivity liability.
We deploy edge computing at the machine or line level that handles data collection, pre-processing, local storage, and critical control functions without cloud involvement. The historian buffer at the edge stores hours of telemetry locally if the WAN link drops, and syncs when connectivity is restored - so no data gaps in the time-series record, and no predictive maintenance model degradation from missing samples.
For safety-critical and regulatory-critical functions - line stop on defect detection, batch record logging under FDA 21 CFR Part 11 - the logic runs at the edge regardless of cloud state.
- Edge-local historian buffer: hours of telemetry stored locally during outages, sync on recovery
- No data gaps in the predictive maintenance or quality inspection record
- Safety and control logic runs at the edge - cloud outage does not affect line operation
- Reduced cloud egress cost: pre-aggregated data published upstream, not raw sample stream
- Edge device management: remote firmware update, health monitoring, and alert from central platform
- Compatible with AWS IoT Greengrass, Azure IoT Edge, and private on-premise deployments
SCADA modernisation - cloud migration without production disruption
Older SCADA systems are islands. Their data exists, but it is locked inside a proprietary historian, accessible only through vendor-specific tools, and incompatible with modern AI infrastructure. Replacing the SCADA means a plant shutdown and a multi-year project. Most manufacturers do not have that option.
We migrate SCADA data to the cloud without touching the existing control system. An OPC-UA server reads from the SCADA historian. An edge device republishes to the Unified Namespace MQTT broker. The old SCADA keeps running - it does not know anything changed. The AI layer now has access to years of historical process data for model training, and real-time SCADA data for live inference.
This is how we give manufacturers the AI readiness of a greenfield deployment on a 15-year-old SCADA system, without a single hour of unplanned downtime.
- SCADA historian tap via OPC-UA: no SCADA modification, no vendor involvement required
- Historical data migration: years of SCADA records made available for AI model training
- Real-time SCADA signal republishing to Unified Namespace for live AI inference
- Existing SCADA HMI and operator interface unchanged - no retraining required
- Cloud platform options: AWS, Azure, GCP, or private on-premise deployment
- Phased migration: one area or line at a time, no plant-wide cutover risk
Frequently asked questions
What is a Unified Namespace in manufacturing?
A Unified Namespace (UNS) is a single data bus - typically built on an MQTT broker with a structured topic hierarchy - where every machine, sensor, and system in a factory publishes its current state. Any consumer (MES, AI model, SCADA, ERP) subscribes to the signals it needs. Publishers and consumers are decoupled, so adding a new AI use case means subscribing to existing data, not building a new point-to-point integration. The topic hierarchy mirrors the physical plant: enterprise/site/area/line/machine/signal, giving every signal one canonical address.
What is the difference between OPC-UA, Modbus, and MQTT?
OPC-UA is the industrial standard for structured, semantic data exchange between modern PLCs, SCADA systems, and software - it carries context (what the value means, its units, its quality status) alongside the value itself. Modbus RTU/TCP is the legacy industrial protocol used by older PLCs, drives, and controllers - simple, reliable, but without semantic context. MQTT is a lightweight publish/subscribe protocol designed for high-frequency, high-volume sensor telemetry from edge devices and IoT sensors - fast, efficient, and suited for the Unified Namespace bus. A real factory typically needs all three.
Can you connect legacy machines that have no PLC or network port?
Yes. For machines with no native connectivity, we retrofit non-invasive sensors - vibration clamps, current transformers, temperature probes - connected to an edge gateway. The machine does not know it is being monitored, and production does not stop for the installation. The edge gateway publishes the sensor data to the Unified Namespace via MQTT. This is how we give predictive maintenance coverage to the oldest, most critical equipment without a control system upgrade.
Does IIoT connectivity require replacing our existing SCADA?
No. We migrate SCADA data to the cloud without modifying the existing control system. An OPC-UA server reads from the SCADA historian, and an edge device republishes to the Unified Namespace MQTT broker. The existing SCADA keeps running unchanged - operators see the same HMI, control logic is unaffected. The AI layer gains access to historical and real-time SCADA data without a single hour of unplanned downtime or a multi-year system replacement project.
What happens to IIoT data collection when internet connectivity is lost?
Edge devices buffer data locally during connectivity outages and sync to the cloud historian when the connection is restored - so there are no gaps in the time-series record that would degrade predictive maintenance models. Safety-critical and control functions (line stop on defect, batch record logging) run at the edge and are completely independent of cloud availability. The line does not stop, and data collection does not stop, because the internet is down.
Explore related solutions
Talk to our IIoT engineering team
Tell us your current machine connectivity situation - which PLCs, which SCADA, which legacy equipment, and which AI use cases you are trying to enable. We will design a Unified Namespace architecture scoped to your plant, your protocols, and your phased rollout plan.
Book a consultation