In the most basic sense, industrial AIoT initiatives aim to harness the power of data and analytics to make industrial processes more effective. In practice, industrial AIoT often requires addressing a range of considerations from device connection and processing needs to system interfacing requirements, analytical approaches, and security.
When combined with AI, IoT sensors and devices enable powerful applications such as predictive maintenance, production and process analytics, asset tracking, and quality control. But these typically require an effective architecture to support data collection, processing, and operational relevance.
This article highlights key AIoT engineering considerations relevant to creating end-to-end systems at scale and provides an overview of important questions to ask while moving from proof of concepts to production-grade analytics solutions.
- Industrial aiot architecture: An overview
Industrial AIoT architecture can be thought of as comprising five major subsystems:
Layer 1: Industrial assets + sensors
This represents the physical objects that make up a given industrial use case. This can range from production-line machinery and rotating equipment to production-rate sensors and tracking devices.
Depending on a given use case, these can measure a wide array of parameters – from temperature and vibration to process variables such as machine state and counts, and asset-specific information.
The choice of sensors often depends on a given use-case and should be prioritized around actionable analytics. The ability to capture additional information beyond what might be required can add unnecessary complexity in terms of processing and integration.
Layer 2: Connectivity + protocol integration
Industrial facilities often comprise numerous pieces of machinery and automation equipment from different vendors. Similarly, industrial equipment and sensors can employ a wide range of connectivity approaches and air-gapped networking technologies.
A number of standardized approaches apply to industrial equipment including OPC UA, Modbus, MQTT, industrial Ethernet, and others besides custom solutions that might be specific to a vendor. These represent fundamentally different approaches to data acquisition that cut across a wide range of sampling rates, system requirements, and approaches to security, scalability, and synchronization. A gateway or integration layer may therefore be necessary to enable consistent data formats.
Important considerations at this level include protocol support, sampling rates and data-volume requirements, operational impact on connected equipment, synchronization and timestamping, and authentication and access requirements.
In the case of operational equipment, it’s important to ensure that monitoring and analytics do not directly impact equipment functionality due to safety, control, and integrity requirements.
- Edge vs. cloud: What constitutes a hybrid system?
Not all industrial data requires a cloud connection.
Edge solutions apply analytics at the data source or a gateway closer to the equipment itself. Edge processing is particularly valuable in applications where latencies and reliability issues could impact overall performance, or in cases where processing closer to the source reduces bandwidth or storage-cost requirements.
Meanwhile, cloud solutions enable enterprise-level storage, analytics, model management, and aggregation of data from multiple manufacturing or industrial facilities for richer insights.
It’s common to use a combination of the two – a hybrid approach, wherein time-critical processing happens at the edge with periodic uploads to enterprise analytics platforms. The balance depends on requirements for reliability, bandwidth, analytics value, risk, and system cost.
- Getting data ready for ai analytics
At the simplest level, AI requires good data and processes to consistently apply the correct analytics. Industrial data, with missing or erroneous values, inconsistent temporal resolution, and other challenges, presents unique challenges to analytics engineering.
A solid data pipeline should consider validation, normalization, temporal resolution, contextualization, and data-quality assurance.
Validation often applies to ensuring that measured values fall within an acceptable range. Normalization ensures that different quantities and labels are comparable, and temporal resolution considers how frequently data points were recorded. Contextualization considers additional factors such as which machine or process was being monitored at a given point in time. It’s similarly essential to ensure data-quality and processing consistency, and to ensure that missing values, delays, and other issues are properly flagged and addressed.
When applied to predictive maintenance, relevant historical data includes maintenance and repair records for the analyzed machine or equipment. It is therefore worth considering the richness of historical data as a valuable input when selecting supervised learning approaches for failure prediction. Where historical failure data is unavailable, it could be worth exploring unsupervised anomaly detection but keep in mind that anomalies are not necessarily failures.
- Example: Predictive maintenance pipeline
As an example, consider a predictive-maintenance technique that applies simple decision rules to vibration and temperature readings from a motor. Pseudocode for such a system could be:
def evaluate_machine(vibration, temperature, vibration_limit, temperature_limit):
alerts = []
if vibration > vibration_limit:
alerts.append('Vibration exceeded')
if temperature > temperature_limit:
alerts.append('Temperature exceeded')
return {
"status": "investigate" if alerts else "normal",
"alerts": alerts
}
This represents a simple set of rules for predictive maintenance instead of an AI model. Threshold values would need to be validated for each application, and could be informed by statistical or machine learning techniques. Another approach could apply historical vibration data, process context, maintenance records, and validated failure-indication models to estimate a measure of risk or anomaly.
It’s important for engineers and analysts designing such systems to consider false positives, false negatives, model drift, and the practical relevance of any alerts or model scores. Predictive maintenance analytics should therefore be evaluated against an appropriate benchmark or reference set, depending on the nature of the application.
- Analytics as an enabler: Operational workflows
While an anomaly alert is useful in its own right, its overall impact on operations depends on how it’s subsequently handled. For analytics to achieve meaningful value, it is often necessary to integrate its outputs with an appropriate operational or enterprise-level application.
This could represent a closed-loop feedback system wherein an alert triggers a maintenance inspection, feeding back information about the observed system state. An appropriate analyst workflow could assign tags, verify issues and resolve the underlying causes. Analyst judgment is particularly important where a predictive maintenance alert could involve plant safety or production downtime.
- Security + reliability considerations
Industrial AIoT systems add new elements to a system architecture that might require new reliability, security, and risk-mitigation approaches.
These subsystems should follow general operational technology and enterprise security best practices including network segmentation to limit exposure of operational equipment to enterprise IT systems. Authentication and least-privilege access control can help reduce the risk of unauthorized access to critical equipment.
Physical device access, device authentication and attestation, and transport encryption should also be carefully considered. Secure over-the-air updates, logging and auditing, backup and recovery, and production deployment testing play essential roles in building reliable AIoT solutions.
It’s particularly important to assess and design security controls based on an organization’s risk profile and operational requirements. Industrial AIoT analytics solutions should have appropriate segmentation to ensure that cloud analytics services or interfaces do not create direct links into enterprise or control networks, potentially introducing new risks.
More : Aperture Venture Studio
- From prototypes to production-grade systems
A proof of concept can serve as a useful launchpad for developing AIoT analytics solutions. However, it should be complemented by a clearly defined set of success metrics and goals for a production-grade solution.
Many industrial analytics solutions are initially deployed on a small scale – and this should be viewed as an opportunity to explore the domain and iterate through successive prototype cycles before committing to a production-scale solution.
It can be helpful to identify a particular domain or problem statement to focus on, and evaluate device connectivity and data requirements for a chosen application.
An actionable rollout sequence for launching an industrial AIoT solution is provided below:
• Pick a specific industrial problem to focus on
• Evaluate device connectivity
• Build a targeted prototype or proof of concept
• Evaluate system performance
• Identify the appropriate analytics application to move to production
• Track performance and reliability
• Deploy to production in stages
For enterprises looking to understand how to begin their own industrial AIoT analytics journey, Aperture Venture Studio provides a deep dive into the relevant trends and emerging opportunities for technology and venture innovation in the industrial AIoT space.
Conclusion
Industrial AIoT system design and engineering encompasses a range of considerations beyond basic sensor-to-cloud analytics. Effective analytics solutions in industrial IoT settings require attention to architecture considerations, data-quality and processing, hybrid edge-cloud approaches to reduce latency and operational impact, analytical pipelines that enable operational outcomes, and appropriate security practices to ensure smooth operation and avoid disruptions at scale.
A focused approach that emphasizes tangible outcomes and tracks meaningful performance indicators is critical to building a solution that successfully addresses a specific domain at scale.
Top comments (0)