A lot of industrial Internet of Things (IIoT) initiatives start with an aspiration to collect and analyze data. Projects work on this aspiration, but there are a lot of details to IIoT architecture that goes well beyond the ability to collect sensor readings.
Adding an AI layer into the system provides value in making predictions and recommendations, but that AI isn't the only consideration in the system. This post describes these aspects in detail and covers some engineering recommendations for industrial applications of AIoT systems.
- Typical Layers of an Industrial AIoT System
There are 5 logical layers to an industrial AIoT application:
Physical devices and sensors
Connectivity and protocol conversion
Edge computing and data integration
Cloud computing and analytics
Actions and decisions based on insights
Layer 1 - Physical Assets & Sensors
Physical assets are industrial equipment. They might include pumps, motors, production equipment, environmental sensors, or tracking devices. For these assets, various parameters might be captured as telemetry data depending on their type:
For Motors and pumps, these might be temperatures, vibration levels, pressure, and currents
For general production equipment: the machine's state or parameters in the production process
For Counts: Number of produced items or process cycles
For Location: GPS or indoor position of an asset
For Environment: Temperature, humidity, or other relevant parameters
Depending on the type of application, sensors will be needed to gather these metrics. In some cases, multiple sensor types or even sensor fusion will be needed to capture relevant information about the state of a machine.
When adding sensors, make sure they actually matter. Adding parameters that you aren't planning to use in your application adds complexity to your application without benefits.
Layer 2 - Connectivity and Protocol Conversion
Depending on the equipment, there might be different communication methods and even communication protocols that apply:
Examples of communication methods include OPC UA, Modbus, MQTT, industrial Ethernet, or connections specific to a vendor. These methods can and differ widely in available data, refresh rates, reliability, or other parameters, and generally can't be mixed together in further processing.
A conversion layer (sometimes also called a gateway) can provide normalized access to telemetry data. When designing the conversion layer, consider:
Common aspects of data between protocols
Required sampling rate (if any)
Network availability and reliability
Timestamp synchronization between sensors
Authentication & access control to data
For operational technology, there might also be additional concerns regarding system availability and safety. When using these systems for monitoring, avoid interfering with other industrial control applications for monitoring.
- Edge Computing vs. Cloud Computing
Not all processes belong in the cloud. Edge processing is valuable when there is a need for low-latency, the ability to operate independently, limited bandwidth, and an ability to keep processing going in the event of a network interruption.
Cloud computing is appropriate when data needs to be consolidated, aggregated, or analyzed across multiple locations or facilities. A hybrid approach often makes sense: process data relevant for local decisions at the edge and synchronize relevant data and events to a central location.
Based on application needs, balance the pros and cons of latency, bandwidth, data sovereignty, and operational requirements of the location.
- Preparing for AI - Making Data Ready
At the end of the day, AI is only as good as the data and the validation that it provides. Most industrial data sets have plenty of noise, offsets, incorrect units, sampling rates, and other issues that will lead an AI model to provide wrong insights or predictions if not taken into account.
As the data pipeline is designed, consider these aspects of the system:
Valdiation - Ensure numbers are in a physically possible range
Normalization - Ensure that parameters use the same units
Time Synchronization - Ensure measurements from all sources are synchronized
Contextualization - Add context to measurements, such as what machine the readings are from and what state it is in.
Data validation - Determine if data is missing, late, or otherwise invalid.
For many predictive maintenance applications, data about what maintenance has been done (or not done) and known equipment failures are critical to train a supervised model. If such labeled failures aren't available, consider anomaly detection approaches. But also make sure your system isn't detecting "anomalies" as normal, everyday operations.
- Example: Predictive Maintenance
Let's say that we have a motor with attached sensors that measure its vibrations and temperature. We want to create a system that analyzes the data from these sensors and determines when the equipment is in danger of failing.
In code, the program may look something like this:
def evaluate_machine(vibration, temperature, vibration_limit,
temperature_limit):
alerts = []
if vibration > vibration_limit:
alerts.append("Vibration exceeds configured threshold")
if temperature > temperature_limit:
alerts.append("Temperature exceeds configured threshold")
return {
"status": "investigate" if alerts else "normal",
"alerts": alerts
}
It's a very simple program that checks whether the motor's vibration and temperature level exceed some thresholds that have been programmed into the application. This isn't really a predictive maintenance algorithm, but shows more how these applications may be constructed.
Thresholds generally need to be tuned for the specific machine and its operating conditions. A more advanced application may apply additional information, such as the sensor values and context history, along with a validated machine learning model, to determine whether the machine is likely to fail.
Before rolling out such a model, engineers need to consider potential issues with accuracy and false positives or negatives and have the right metrics in place to measure how effective the application is.
- Acting on AI Insights
An anomaly in a set of measurements rarely stops a machine or process on its own. For an AIoT initiative to be truly disruptive in an industrial application, the outputs of ML models might need to tie into maintenance or manufacturing execution or enterprise systems.
A predictive maintenance system, perhaps, could take a validated AI insight or anomaly and turn it into a task for a human maintainer to prioritize and investigate: for instance, identifying what machine part likely failed, its location, and triaging severity levels.
Some applications, especially those that could impact the safety of plant personnel or production continuity, might warrant deeper analysis before taking any action.
- Security and Reliability Aspects
An AIoT application adds new devices and capabilities that need to be protected. When designing an application, engineers should consider:
Segregating network activity according to function and risk
Access control and privilege escalation considerations
Secrets management and secure device onboarding practices
Secure communications when supported by devices
Software, patch, and firmware lifecycle management
Logging, auditing, backup, and recovery considerations
Change control processes prior to production deployment
Engineering security controls should be informed by an understanding of the overall environment and threat model for the application. A cloud-based analytics application isn't a secure place to extend an industrial control network.
- From Prototype Solution to Production-Grade Applications
Applications with promising results rarely go live after one prototype build. For many engineering initiatives, identifying a set of clear goals based on some set of outcomes is a necessary step toward production-grade applications.
A typical process for launching an AIoT application may follow several phases:
Determine an impactful set of problems for your business
Identify devices that have the right connectivity
Build a limited prototype proof of concept
Test this prototype under live conditions
Integrate the application into an appropriate business process
Measure performance and impact of the application
Repeat this process in a rolling deployment
When launching an AIoT initiative and looking at connections between AIoT applications and venture opportunities in this space,
Aperture Venture Studio also looks at these industrial applications for inspiration.
Conclusion
An industrial application built with AIoT components entails much more than sticking a few sensors into an AI application. Instead, reliable production applications generally start with an appropriate architecture for the application and its requirements.
Other considerations also come into play, including preparing data and validating AI outputs, as well as making sure the application fits into the wider technology stack, including the appropriate business decision-makers. Beginning with a well-defined business question or application can provide a long-term roadmap for a technical implementation.
Top comments (0)