A working AIoT application is rarely limited to an AI or ML model that consumes the output of a sensor. At least some contextually relevant data preparation and operational relevance validation must take place.
Below is a technology-agnostic description of such a pipeline.
We will consider the example of a warehouse with tracking devices.
- First, there is the source event
A warehouse tracking application would see the events generated by a reader or a sensor, identifying
Device or asset ID
Event time
Position or zone identifier
Sensor value (if any)
Sensor or event source ID
The list could be expanded from there, but these are the most common fields, with the caveat that some information may not be applicable to a given application.
- Next, the data must be validated and normalized
Events can have duplicates, erroneous, out-of-bound values, or be missing some data, especially time and identifier fields. This layer ensures that the event meets the criteria specified for this application, validates and, if necessary, corrects anomalous values, and handles duplicates.
For example, consecutive events from the same source identify movement, but these movements may not actually occur, indicating erroneous data.
- Events must be given operational context
What does a position or zone mean to an operator? Depending on the type of asset and the stage of the process, a similar event may need to be treated differently.
The location or status change must be related to a specific asset type, its life cycle, the relevant procedure, and other factors.
- Then, a model or a decision logic must extract actionable information
A rule-based system could be used, for example, to find that an asset has been found in a prohibited area or has been delayed for too long in a particular zone.
A trained model could find patterns of behavior similar to previously observed ones and propose a solution or assess the risk of a delay in the process. These are two sides of the same coin and one does not exclude the other. The choice of the method should be dictated only by the specifics of the application.
- An action must be taken to involve the operator in the decision-making process.
What does the operator need to do to resolve this situation? Depending on the application, it may require drawing up a report, inspecting the asset, or changing the procedure. The action taken must be specific to the case, and the operator must have the ability to influence the outcome.
Actions involving changes in the state of the equipment or physical processes are usually automated through appropriate techniques and tools. In this case, the model should not specify the action directly but select it from a list of options presented, with an explicit confirmation step. There are many dangers in automatically executing model-specified actions without checking their relevance to the current context.
In addition, for such applications, the question of safety, security, and physical protection of devices from interference and disruption arises.
- It is necessary to collect statistics on the results of decisions made to continuously improve the system
Did the action produce the desired result? Did the operator take any action? Was the model correct in its choice, or was it wrong?
It is important to analyze not only the results of the system but also possible changes in the external environment.
There are several pitfalls that often occur in the development and deployment of such systems.
The quality of input data is often not taken into account. Even the best neural networks cannot correct incorrect input data. Contextual conditions are often not considered, which leads to unjustified conclusions. The model’s accuracy often works as the only metric, while other values, such as latency, may be much more important. It often goes unnoticed that the system works in the presence of other processes. This interaction must be considered in the design of the application or system as a whole. The system’s context and assumptions are static and rarely take into account the changes that are happening in the application context. All of this leads to failures and the loss of trust in the entire concept of AIoT.
Finally, a generic system such as this one is usually applied to specific sets of data and requires the implementation of data preparation and operational quality control for each new use case.
This note relates to the work of venture studios Aperture Venture Studio in developing applications involving artificial intelligence and the Internet of Things in industrial environments. They specifically focus on the problems of industrial applications for venture studios, not the AI itself.
In summary, the main takeaway is that the application as a whole, from sensors to final decisions, is much more important than the model itself.
Questions: Which layer tends to cause the most problems for your AIoT systems – data, context, models, or operational applications?
Top comments (0)