IoT has the potential to connect physical devices to software, and continuously collect information. AI can take that information and make decisions based on it. The engineering challenge is in building something that can combine the information from physical devices, and make meaningful decisions out of it.
This whole system is often referred to as AIoT (Artificial Intelligence of Things)
But building anything useful always involves more than just connecting a sensor to an AI system. Developers need to think through all aspects of a system, from the way the device generates information, through processing and presentation.
A useful AIoT architecture probably looks something like this:
Devices → Connectivity → Edge → Data Platform → Analytics → Application → Action
We’ll go through each of these layers and discuss the type of work, limitations and issues that might arise.
Devices and Sensors
Depending on the use-case, the type of information that might need to be gathered by the physical devices can vary significantly. Possible information types include: temperature and environmental readings, equipment status, machine telemetry, location, motion, RFID or BLE tags, other measurements of interest,
The data itself matters: having poor quality measurements coming out of the sensors will limit everything else the system can achieve.
Connectivity
The information coming out of the devices needs to get somewhere. The way of achieving that "somewhere" can be as varied as the use-cases. Factors that influence the type of connection needed include: availability and type of network, bandwidth, latency, range, power budget, deployment location,
Again, there is no single correct approach that will work for every possible AIoT implementation.
Edge Processing
Pushing everything the devices see out to some form of analytics or data collecting system might not be viable. By using an edge node (or multiple), some of the raw information coming from devices can be processed. For example, rather than pushing every single sensor measurement to some centralized place, an edge node can be used detect if something interesting happens. If it does, the edge node can share that conclusion with the rest of the system.
This approach can simplify things: instead of pushing all of the raw data further, the edge node can push events or conclusions it draws from looking at streams of information
Data Platform
After the devices generate data, and potentially some edge processing, the information still needs to be stored somewhere or have some additional processing done. The data platform is probably the largest part of this architectural diagram.
What type of information does it need to support? It will most likely include streaming data from devices, as well as time series, metadata about each device, historical information and events, device location data, etc.
As the volume of devices and data grows, system robustness and appropriate data schemas will become an issue.
Analytics and AI
At this point, useful information and insights can be extracted using some form of analytical or AI processing. This stage probably uses ML or AI, the choice of which depends on the specifics of the problem and the type of data available.
What type of ML or AI applications make sense in this stage of the architectural diagram? Several possibilities exist: event detection (normal or special), classification (based on some known set of possible categories), regression (prediction models), etc.
To give an example: the historical sensor readings for a specific piece of equipment can be used to detect some type of "normal" state that the equipment exhibits. New sensor readings can be compared against that known "normal", and the ML model can flag any abnormal or unexpected results.
But what about the ML or AI part itself? The choice of model isn't enough: developers and engineers will also need to consider the training data, feature engineering and selection, validation and monitoring, and updating or retraining of the ML/AI model when appropriate.
The Last Step in Processing: Action
But to actually create an AIoT application that does anything useful, the process above still needs a meaningful action at the end of the chain.
Let's imagine a hypothetical "equipment monitoring" system: sensor → any edge processing → data platform → ML analytics → alert → ??
If that system detects some unexpected data pattern, how does it translate that pattern into some useful conclusion? Perhaps after the ML model runs, the application that utilizes its results sends that information to the operations group for the equipment in question.
That action part is probably the most important in this chain: having the AI/ML model isn't useful if it isn't used for something specific.
Engineering Challenges of AIoT
Putting all this together means that developers and engineers still need to understand some of the specific limitations and issues with building such a system.
Some of these challenges might include issues like
data reliability or quality issues,
availability and limitations of connectivity,
scalability issues as more equipment is added,
latency (sensitivity to time delay),
security issues (in the system as a whole, including data and APIs, edge security, etc.),
drift or changing nature of ML/AI models as conditions change,
and others.
Those challenges are what make AIoT implementations significantly more complex than just using a particular AI or IoT application.
Problem-First Design of AIoT Applications
In many ways, the way to approach the development and engineering of AIoT applications should start with the problem to be addressed. Before deciding on the specific use of IoT devices or AI methods, the technical and development teams can ask themselves several questions:
What physical process or phenomenon do I need to understand?
What data do I need to capture? (Including sensors, location, etc.)
Where will that data be processed? (Edge?)
What data will need to be stored? (Time series? Images?)
What conclusion or decision do I want the AI/ML algorithms to help reach?
What do I want to have happen in the real world after that decision is reached?
How will the process be monitored and evaluated? (Including drift detection in ML models?)
This approach might help simplify the engineering and development of a useful AIoT application and keep it focused on the intended outcome.
Related Reading & Resources
To learn more about AIoT implementations in the context of physical-world or industrial systems, you can refer to this article from Aperture Venture Studio, titled "AIoT: Bridging the Gap Between AI and the Physical World".
Final Thoughts;
AIoT brings together the areas of AI and IoT, connecting physical devices and systems to decision-supporting or analytical applications. This connection usually involves some combination of devices, data pipelines, edge processing and AI/ML analytics.
The engineering challenge in this context is in building the necessary systems so that they are able to support the AI/ML process.
But developers and engineers need to understand that the ultimate aim isn't the collection of more data, or the use of AI/ML algorithms for their own sake. A properly-designed AIoT application will create a process that connects a physical signal to one or more useful actions.
I hope that this overview has given you food for thought about the potential applications, challenges, and approaches to developing and publishing an AIoT application.
Top comments (0)