The Internet of Things has enabled information gathering at a level previously unseen. We can apply sensors to equipment, RFID systems to tagged assets, and other means to create a connected digital representation of the physical world. While sensing is valuable, the more interesting engineering question is what we can do with this information.
This is where AIoT - the convergence of AI and IoT - comes into play
What Can We Do With AIoT?
A normal IoT architecture can be visualized as:
Physical Device
↓
Sensor
↓
Connectivity
↓
IoT Platform
↓
Database
Whereas incorporating AI into the mix could be visualized as an additional layer:
Physical Asset
↓
Sensor
↓
Connectivity
↓
IoT Platform
↓
Data Pipeline
↓
AI / ML Model
↓
Prediction or Insight
↓
Operational Action
The focus here is not on the prediction itself, but rather what can be done about it.
Let's Take A Practical Example
Suppose that we have a machine connected with vibration and thermal sensors. The IoT infrastructure may collect information such as
timestamp
machine_id
temperature
vibration
operating_hours
motor_speed
and a data pipeline could convert this into features for an ML model:
...
"features": {
"temperature_avg": 78.4,
"temperature_change": 6.2,
"vibration_rms": 4.8,
"operating_hours": 8432
},
...
Such a model could be used to calculate a likelihood of an abnormal operational state.
But again, the critical question is: what can we do with that information?
An example architecture could be as follows:
Sensor
↓
Edge Gateway
↓
Message Broker
↓
Data Processing
↓
ML Model
↓
Risk Score
↓
Maintenance System
↓
Human Review / Action
That is to say: an AIoT application is not about creating interesting looking charts for you to look at, but rather about making decisions that you would otherwise need to make manually.
Cloud Versus Edge: Important Design Considerations
There is an architectural consideration of whether to make predictions from within the cloud or at the edge of the network.
While cloud-native approaches may be well-dimensioned in terms of processing resources, it is not always practical to send every single record from your IoT devices to some ML service in the cloud. Some reasons for avoiding edge processing could include:
- Limited availability of resources at the edge
- Need for greater precision than simple models can provide
- Need for greater reactivity to sensor values
- Required regulatory compliance
- Bandwidth limitations due to sheer volume Whereas edge computing may make sense due to the following factors:
- Limited connectivity
- High data volumes
- Latency requirements
- Privacy considerations
- General operating considerations By way of comparison, a system with edge processing might have a structure such as: Machine ↓ Edge Device ├── Filter data ├── Anomaly detection └── Send events ↓ Cloud ↓ Central analytics Rather than send every record for processing, edge devices can process this information themselves and only send important records upstream. The choice depends primarily on what latencies are acceptable, but there are many other concerns as well. See for example this post discussing various decision points that could impact AIoT architecture. Another Example: Asset Tracking Sensors are not exclusive to machines. Industrial facilities and other operations often include a great number of assets, some of which can be tagged with RFID systems. GPS services can provide tracking for equipment such as trucks, while other means include Bluetooth or cellular connectivity. These can be used to create a digital representation, and AI can then be used to infer trends and patterns from such data: for example, predicting time to failure based on vibration and thermal data identify equipment that is frequently being left idle detect patterns of unusual movement or placement determine utilization rates based on movement history recognize potential inventory management issues This represents a form of higher-level awareness. While raw RFID log data is useful, it is much more valuable to derive knowledge from that information. The Real Problem Often Lies In The Data Pipeline One of the most common misconceptions regarding AIoT is what machine learning model is most appropriate. The truth is, most of the time the pipeline for data cleaning and preparation is at least equally as important. Any given production facility will generate problematic data: missing values duplicate records inconsistent or faulty measurements erroneous timestamp information connectivity issues calibration problems A complex ML architecture will not be able to mitigate the problems of missing values or incorrect data labeling. An effective data pipeline is needed instead. That could include a validation and normalization step: Raw Sensor Data ↓ Validation ↓ Cleaning ↓ Normalization ↓ Feature Engineering ↓ ML Model In some cases, these data quality assurance steps may even be more important than the model itself. Interoperability With Other Systems Is Yet Another Challenge One of the reasons why AIoT is interesting is that it does not exist within a vacuum. Industrial facilities often have many other supporting systems for ERP, MES, warehouse management, and other applications. A standalone AIoT application would provide some value and intelligence, but it will typically be helpful if it can integrate with other applications that the organization uses. In some ways, this is an implementation detail: if such systems already exist, the integration must be achieved somehow. In terms of a specific example, consider the case where AIoT can be used to recommend maintenance for specific machinery, and such information is relayed to the relevant maintenance management system. This could take a form as simple as: IoT Event ↓ AI Analysis ↓ Maintenance Recommendation ↓ Existing Maintenance System ↓ Technician Workflow Security Should Not Be An Afterthought Physical assets and their digital counterparts are both vulnerable attack surfaces. Security should be considered at each layer of the architecture: Device / hardware security Network security Encryption Access control Firmware and device lifecycle management API security Infrastructure security (cloud / on-premise) Data retention and management Model management A single compromised IoT device can become a vector for an attack against the entire system. Rather than implementing security measures as an additional step once the system is complete, security considerations should be incorporated throughout the design process. A Converging Set Of Technologies As the name AIoT suggests, there is a certain amount of integration between AI and IoT, but that is only part of the picture. A complete system will also likely make use of such technologies as Edge AI Computer vision Digital twins Industrial robotics Analytics Real-time processing Predictive modeling And there are many more. The value proposition is not necessarily that these technologies will be used, but that all of these systems - together with humans - will form an intelligent ecosystem in which decisions can be automated or supported in real-time. A Note From Aperture Venture Studio Aperture Venture Studio, a venture building studio where I am currently employed, works on industrial AIoT solutions, among other projects. Aperture sees numerous opportunities for AI and connected technologies in the industrial space. That said, the technologies outlined in this post are available to many, not just those affiliated with Aperture. And the real magic begins when these building blocks come together into functional applications that solve practical problems. Sensors + Connectivity + Data Quality + AI + Security + Other Tools = Actionable Intelligence The most compelling AIoT applications will be focused on specific industrial concerns and make practical use of the technology. The technology is not an end in and of itself. The final result should be tangible and useful, whether it be in the form of predictive maintenance analytics, inventory optimization, asset tracking, or another application domain.
Top comments (0)