IoT & Industrial Automation
Industrial IoT, SCADA integration, predictive maintenance, digital twins for critical infrastructure. From sensor to CEO dashboard.
What it is and who needs it
The IoT practice covers design and implementation of industrial IoT systems: telemetry collection from sensors, SCADA integration, edge processing, time-series analytics, predictive maintenance, digital twins.
We work primarily for critical infrastructure (energy, oil & gas, water supply) and manufacturing holdings, where reliability matters more than features, and OT environment cybersecurity is a separate layer of complexity.
Signals that equipment needs a telemetry layer
- You have >100 industrial points with telemetry and get no actionable insights from them.
- The latest maintenance plan is calendar-based, not equipment-state-based.
- Critical equipment failures are only understood post-mortem.
- The OT network segment is isolated from IT, but there is pressure to integrate.
- Energy/water sector regulator inspection is approaching.
A failure should become a forecast, not a surprise
The IoT page is about visibility into physical assets: equipment state, downtime risk, telemetry and decisions made before an incident.
OT knows the equipment, IT wants data, business wants uptime
The real IoT complexity is not sensors. It is connecting OT reality, IT architecture and business metrics without risking production.
One critical asset, one failure mode
We do not put sensors everywhere. We choose equipment where downtime is expensive, verify historian data and build a pilot with the OT team.
Why we do this differently
Predictive maintenance pays off NOT by spare parts savings, but by knowing about a failure 2 weeks ahead, not 2 hours.
Spare parts savings are a side effect. Main value — ability to schedule maintenance for night shift instead of stopping the production line in daytime. Without this understanding, ROI calculations do not add up.
OT segment cannot be integrated with IT "via VPN". It is a different security philosophy and different operational reality.
IT team thinks SLA 99.5%. OT team thinks "zero downtime on this turbine in 20 years". Integration is done via DMZ with one-way data diodes for critical flows, not through usual enterprise patterns.
A digital twin without historian data is a CAD model. Twin value comes from comparing the theoretical model with real telemetry.
Before building a digital twin, you need at least 12 months of historical data from measurement points. Without this the model cannot be calibrated and gives inaccurate predictions.
When you need this — and when you don't
It is more honest to say "you do not need this yet" than to sell an engagement that will not deliver ROI.
✓ Need it
- Industrial enterprise with >100 telemetry points
- Critical infrastructure (energy, water, oil & gas)
- You have 12+ months of historical sensor data
- OT team ready to cooperate with IT project
- Failures on critical equipment cost >$100k per incident
✗ Not yet
- Small manufacturing business without OT team
- <6 months of historical data — predictive models cannot calibrate
- OT team categorically against any IT integration
- You want "an AI agent that predicts everything"
How we run the engagement
OT/IT discovery ·
Inventory of sensors, controllers, SCADA systems. Audit of historian data. Interviews with OT team to understand operational constraints.
Architectural design ·
Design of edge collection layer, time-series data lake, ML pipeline for predictive maintenance, DMZ for OT/IT integration with cybersecurity-by-design.
Pilot on one equipment unit ·
Usually — a critical unit with known failure history. Pilot proves predictive model precision/recall and operational adoption with OT team.
Scale-out ·
Phased expansion to full equipment fleet. Adapting models by equipment type. Developing digital twins for most critical systems.
Continuous operations ·
Model drift monitoring, retraining for new failure patterns, integration with maintenance management, regular OT cybersecurity audits.
Project lead: AZIOT (IoT platform, edge collection, SCADA integration) and Softengi (ML models for predictive maintenance, digital twins).
Brought in when needed: Softline (OT cybersecurity, NIS2 compliance for critical infrastructure).
Typical mistakes we have seen projects fail on
IoT without a use case
They enter the project with the idea "let's install sensors and figure out later what to do with them". A year later — 10 TB of historical data and zero operational insight.
What we do instead: we start from the business problem: which equipment is critical? which failure modes do we want to predict? Only then we choose sensors.
OT/IT integration via usual enterprise patterns
IT team opens a VPN tunnel into the OT segment "for analytics". Six months later — ransomware attack via compromised IT user reaches OT.
What we do instead: DMZ with one-way data diodes for critical flows. The OT segment is never accessible for back-queries from IT.
Predictive model without OT validation
Data scientists train models on historical data without OT engineers. The model produces alerts that OT ignores because they do not correlate with actual failure patterns.
What we do instead: OT engineer as model co-author. Every new model version — joint review with OT before deployment.
Typical scenarios from our practice
Each example shows the client-side story: what was getting in the way, what changed, and what result the team got.
Preventing failures
- Problem
- Equipment wear was discovered too late, when downtime was already unavoidable.
- What we did
- We collected key equipment signals and agreed response rules with engineers.
- Result
- The team sees risk in advance and plans repair without emergency shutdowns.
Finding leaks faster
- Problem
- Finding the problem area in the network took too long, and losses accumulated for hours.
- What we did
- We added control at key points and alerts for unusual behavior.
- Result
- Problem detection became faster, and losses went down.
Testing changes without stopping the line
- Problem
- Any change in operating mode risked downtime, so changes were postponed.
- What we did
- We created a safe model to check changes before launching them on the shop floor.
- Result
- The team tests new modes without risking production.
Articles on this topic
Nine recent expert articles — from thematic overviews to specific architectural decisions.
No articles in this category yet.
Technologies we work with
IoT platforms
AZIOT · AWS IoT Core · Azure IoT Hub · GCP IoT Core · ThingsBoard · PTC ThingWorx
Edge & gateways
AWS Greengrass · Azure IoT Edge · KubeEdge · NVIDIA Jetson · Raspberry Pi industrial
SCADA & PLC
Siemens SIMATIC · Schneider EcoStruxure · ABB 800xA · Rockwell FactoryTalk · Wonderware
Time-series & historian
OSIsoft PI · InfluxDB · TimescaleDB · Prometheus · Apache Druid
ML & digital twins
TensorFlow · PyTorch · MLflow · Azure Digital Twins · AWS IoT TwinMaker · ANSYS Twin Builder
Standards
IEC 62443 (OT cybersecurity) · ISA-95 · MQTT · OPC UA · NIS2 · ISO/IEC 27001
Frequently asked questions
Which equipment to start IoT with?
With the most critical — equipment whose failure costs most per incident. Then — equipment with known failure history (for model training). Avoid "new flagship" equipment that has not accumulated 12 months of data yet.
How long does predictive maintenance implementation take?
Pilot on one equipment unit — 3–4 months. Full coverage for critical infrastructure — 12–18 months. First truly reliable predictions — 6–9 months after production start (because validation on real failures is needed).
Can IoT be done without an in-house OT team?
For typical scenarios (monitoring, predictive maintenance) — yes, with outsourced OT expertise. For critical infrastructure — categorically no. The OT team must be in-house, because equipment knowledge is an asset that cannot be outsourced.
How to ensure OT cybersecurity?
IEC 62443 as base framework. Principles: (1) network segmentation with DMZ; (2) one-way data diodes for critical flows from OT to IT; (3) never allow back-queries from IT to OT; (4) separate IAM for OT; (5) regular OT-specific penetration testing.
What is a digital twin and when does it pay off?
Digital twin — a software copy of a physical object with real-time telemetry and physical model. Pays off for critical equipment where experiment errors are costly. Does not pay off for typical equipment where predictive maintenance is enough.
Related competencies
Real projects rarely fit in one competency. See which other areas we work in.
Tell us about your industrial situation — we will see where to start
30-minute discovery call with an IoT architect. We will discuss equipment, historical data and realistic expectations.
Intecracy Group does not force a single delivery team. We clarify the task, identify the required competencies and help involve the relevant alliance members.