Industrial IoT Applications

01Purpose and scope

• This manual supports the course Industrial IoT Applications. It is written for engineers, technicians, maintenance planners, data analysts and plant managers who are asked to connect physical equipment to digital systems and get useful decisions out of the data. It describes how the work is actually done on a plant floor or at a utility site, not how it looks in a vendor presentation.
• The scope covers the chain from sensing to action: choosing measurement points, installing field devices, moving signals through gateways and networks, storing and modeling data, building alerts or dashboards, and changing work based on what the data shows. It treats operational technology (OT) and information technology (IT) as two groups with different priorities, since uptime and safety usually outrank data freshness on the floor. Discrete manufacturing, process plants, water utilities, oil and gas sites and building systems all use these tools, but the constraints differ widely from one to the next.
• Limits matter here. This manual does not replace qualified engineering judgment, site safety procedures, management of change requirements or the authorization needed before you alter a control system. Where a rule depends on jurisdiction, such as electrical codes, occupational safety obligations or data retention requirements, check the current authoritative source for your location.

02Core principles

• Start from a decision, not a sensor. Every measurement point should answer a question someone will act on, such as whether a bearing is heating faster than normal or whether a batch is drifting out of its target range. Sensors that feed no decision add cost, network load and maintenance burden without any return.
• Keep control and monitoring separate. Most industrial IoT projects are monitoring projects. Data flows from the process to a historian, analytics platform or dashboard and does not write setpoints back to controllers. Adding a write path changes the risk profile and usually requires formal approval, testing and a rollback plan.
• Respect the network boundary. Field devices, programmable logic controllers and supervisory systems live in a segmented zone. Gateways and brokers sit at defined boundaries, and traffic crosses them through narrow, documented paths. Outbound connections are preferred over inbound ones.
• Model data with context. A temperature value without a tag name, unit, asset identity, operating mode and timestamp source is hard to trust. Use a consistent naming convention and asset hierarchy from the start. ISA-95 is a widely used reference model for how enterprise and control levels relate, and it is useful even when you do not implement it in full.
• Plan for the data you will lose. Connections drop, sensors fail and clocks drift. Design buffering, data quality flags and gap handling into the pipeline rather than discovering them during an incident.

03Planning and preparation

• Begin with a short use case statement. Name the asset or process, the question to answer, the people who will act on the answer and the cost of acting late or wrongly. A use case that cannot be stated in a few sentences is usually not ready for hardware.
• Survey the site. Walk the area with an operator or maintenance technician and record existing instrumentation, controller models, communication protocols, cabinet space, power availability, hazardous area classifications and radio conditions. Photograph cable routes and note which panels require lockout for work. Existing historians and SCADA systems often already hold data you need, so check them before buying new sensors.
• Define roles early. A typical team includes a process owner who accepts the outcome, an OT engineer who approves changes to the control environment, an IT or cloud architect, a data engineer, a cybersecurity lead and a site safety representative. Name one person accountable for each decision.
• Choose the architecture for the situation. Edge processing reduces bandwidth and keeps working during wide area network outages, but it adds hardware to maintain. Cloud analytics scales well and simplifies model updates, but it depends on connectivity and raises data governance questions. Many deployments use both, with edge filtering and cloud trend analysis. Wireless sensors suit retrofits where running cable is costly, but they need a site radio survey and battery planning.
• Set measurable indicators before deployment. Examples include the percentage of time sensor data is present and valid, the mean time from alert to technician response, the change in unplanned stops on the target asset and the number of false alarms per week. Record the baseline so the result can be compared honestly.

04Recommended workflow

1. 1
   : Confirm the use case and success measures with the process owner, and record them in the project charter before any purchase order is raised.
2. 2
   : Inventory existing data sources and signals, mapping each one to its asset, tag, unit, sample rate and owner. Gaps in this inventory tend to become gaps in the final system.
3. 3
   : Select sensors and gateways, checking environmental ratings, required certifications for hazardous areas, power supply and mounting. Confirm with the site safety group before installing anything in a classified area.
4. 4
   : Install and commission in stages. Bench test devices first, then install on one asset, verify readings against a calibrated reference instrument and record time synchronization settings.
5. 5
   : Build the data path. Configure protocol connections such as OPC UA or MQTT, set buffering and store-and-forward behavior, define the data model and naming, and route data to the historian or analytics platform.
6. 6
   : Develop the analytics or alerting logic. Start with simple threshold and rate-of-change rules validated against past events, and add statistical or machine learning models only when the simple rules fall short and the data supports them. Test alerts against historical incidents to estimate false positive and miss rates.
7. 7
   : Put outputs into the work process. Define who receives each alert, the response expected, the escalation path and how the outcome gets recorded. Run the system in shadow mode for a period before operators depend on it, and scale to other assets only after the first deployment has met its indicators for a sustained period.

05Quality checks, risk controls and compliance

• Check sensor accuracy and drift on a schedule. Compare readings against a reference at installation and at intervals set by the manufacturer or your quality procedure. Log calibration status alongside the data so analysts can exclude suspect periods.
• Apply cybersecurity controls from the start. ISA/IEC 62443 is the main family of standards for securing industrial automation and control systems, and NIST SP 800-82 offers guidance on operational technology security. Use network segmentation, least privilege accounts, patch management coordinated with the vendor, removal of default credentials and logging of remote access. Avoid exposing controllers directly to the internet.
• Manage change formally. Any new device, firmware update or network path that touches a controlled system should go through the site's management of change process, with a risk assessment, a test plan and a rollback method. Keep a record of who approved each change and when it went live.
• Protect data and privacy. Where the data relates to workers, such as badge location or individual productivity, consult your legal and human resources staff, since the rules vary by jurisdiction. Know where data is stored, who can access it and what the retention period is under your records policy.
• Address safety directly. Industrial IoT must not defeat safety interlocks, alarms or emergency stops. Sensors and gateways installed near energized equipment need appropriate electrical and hazardous area ratings. This guidance does not replace qualified professional judgment, approved site procedures or the authorization required before work on a safety-related system.

06Collaboration and documentation

• Hold a short weekly review during deployment with the process owner, OT engineer, data engineer and maintenance lead. Walk through open alerts, data gaps and pending changes. Keep the meeting focused on decisions rather than status slides.
• Maintain a living document set: asset and signal register, network diagram, data dictionary, alert rules with their rationale, change log, calibration records and a runbook for common failures. Store these where shift staff can find them and keep them under version control.
• Write the alert rationale down. When an operator asks why a threshold sits at a particular value, the answer should be in the record, including the historical events used to tune it. This reduces repeated debate and makes it easier to retire rules that no longer fit the process.
• Train the people who respond. Operators and technicians need to know what an alert means, what data supports it, what to check first and when to escalate. A short job aid tied to each alert type usually works better than a long manual nobody opens.

07Measures and continuous improvement

• Track the indicators defined at planning. Review data availability, alert precision, response times, downtime trends and changes in maintenance work orders each month. Be cautious with estimates of avoided downtime, since they depend on counterfactual assumptions and are easy to overstate.
• Review false alarms and misses with the people who responded. Classify each false alarm by cause, such as sensor fault, legitimate process change or a threshold set too tight. Trace each missed event back to the signal that should have caught it and decide whether that signal, rule or data path needs work.
• Retire what is not used. Signals that nobody reads, dashboards nobody opens and alerts ignored for months consume resources and attention. Remove or repurpose them on a regular cycle.
• Plan for lifecycle. Firmware, certificates, device batteries and software licenses all expire or age. Assign an owner and a due date for each, and place them on the maintenance calendar so they do not surprise anyone during a shift.

08Common mistakes and how to prevent them

• Starting with the platform rather than the problem. Buying a dashboard tool before the use case is clear usually produces attractive screens that nobody uses. Prevent this by requiring a signed use case before procurement begins.
• Ignoring time synchronization. Data from devices with unsynchronized clocks makes root cause analysis unreliable. Configure network time sources for every device and check drift as part of commissioning.
• Underestimating the field. Cable runs, cabinet heat, vibration, washdown cycles and radio interference cause more failures than analytics errors do. Survey the site and bench test under realistic conditions.
• Trusting the first model. Machine learning models trained on a short window often fail after a product change or a seasonal shift. Keep the simple rules as a baseline and monitor model performance over time.
• Skipping change control because the change looks small. A firmware update to a gateway can disrupt a control network as much as a controller change does. Apply the same discipline to every change on the OT side.

09Practical checklist

• Confirm a signed use case with a named process owner and measurable success indicators.
• Inventory existing signals, historians and SCADA data before selecting new hardware.
• Survey the site for power, cable routes, hazardous area ratings, radio conditions and lockout points.
• Confirm the architecture split between edge processing and cloud analytics, with a documented reason.
• Verify sensor readings against a calibrated reference and record time synchronization at commissioning.
• Apply network segmentation, least privilege access and removal of default credentials before connecting devices.
• Route every change through management of change with a risk assessment, test plan and rollback method.
• Run alerts in shadow mode and measure false positives and misses against historical events.
• Assign owners and due dates for firmware, certificates, batteries and licenses, and review indicators monthly.

★Learning sources

• Micro Degree: Industrial IoT Applications
• Micro Degree: Data Analytics Applications
• Micro Degree: Azure Cloud Fundamentals
• Micro Degree: Google Cloud Platform Basics