Industrial AIoT refers to the combination of artificial intelligence and the Internet of Things applied to industrial operations, spanning from asset monitoring and logistics tracking to production visibility and predictive maintenance. Developing a commercially viable industrial AIoT product requires more than simply attaching sensors to a process and publishing the data – there are critical technical and commercial development considerations to be made.
This article provides a high-level overview of the technical and business factors to consider while building an industrial AIoT product.
- Pick the Use-Case First
Prior to building the MVP or choosing the sensors, cloud, or modeling tools, the team should have a general idea of what the industrial AIoT system is trying to resolve.
For example, when a manufacturing plant has frequent unplanned downtime, a potential solution would be to apply some form of analytics to determine what activities occur right before the event so that the process can either be modified or its deviations can be learned by an AI model and future occurrences can be predicted.
The MVP or pilot documentation should include:
What operational challenge does the system seek to resolve?
What data is needed to provide color or context around the challenge?
At what frequency is the data generated?
Who are the users of the information?
What is a key performance indicator that demonstrates success?
The use-case should be focused to avoid scope bloat.
- Design the Data Pipeline
Industrial IoT systems typically include a few layers of processing before data becomes actionable information. These layers can create points of failure if the pipeline is not carefully designed.
There are several stages that may be included in the system, such as:
Sensing: Collecting measurements or events
Connectivity: Sending the data to another destination
Processing: Validating, enriching, or otherwise manipulating the information
Storing: Keeping a persistent copy of the data records
Analytics: Performing calculations or machine learning model inference to extract additional information
Applications: Generating visualizations and notifications
Each layer can add points of failure if there are exceptions that are not handled or data that does not match expectations. Examples of such issues may include skipped records, erroneous timestamps, events being processed more than once, connectivity issues, and so on. Practical implementations may involve extensive data validation, adding timestamps, device health metrics, buffering to smooth out intermittent connectivity, and careful handling of record failures.
- Decentralize Some Processing
Not all data collected by sensors may need to go through the same systems. While cloud processing has advantages such as shared storage and easier access to data for other analytical tools, some processing at the edge may be required.
Edge processing can reduce bandwidth requirements by only transmitting necessary statistics, increase resilience against connectivity issues by allowing time-series processing and buffering, and provide faster local responses for time-critical activities.
Hybrid approaches are often used in practice, such as performing some threshold alert processing and localized analytics at the edge while utilizing the cloud for higher-level tasks.
The choice between centralized and decentralized processing should be informed by bandwidth, reliability, security, latency, and budget constraints rather than preferences.
- Leverage the Value of AI
At the analytics stage, AI can be applied to perform specific operations. However, it is important to recognize that AI should be used in the right circumstances. A simple rule may be more effective than a complex AI model if the requirements can be met directly, such as simple threshold crossing. More traditional statistical models may be more valuable than machine learning in cases where there are multiple interacting variables that the AI needs to learn.
When designing such a system, there should be an understanding of the characteristics of the data that the model will see in production, the representativity of historical data, expected false-positive and false-negative rates, and how drift in production data will affect the model. Additionally, procedures for operationalizing such a model in production, including validation, retraining, and model performance checks, should be considered.
Finally, the model performance should be measured in an operational context: a prediction may be accurate, but if it does not drive downstream processes and verifiable physical outcomes, it is no better than guesses. Wherever possible, predictions should be utilized to inform PDCs rather than automatically triggering decisions or events.
- Integrate with Other Manufacturing or Industrial Software
Industrial systems may need to exchange information with other enterprise systems such as manufacturing execution, warehouse management, enterprise resource planning, and various analytics systems. Careful consideration should be given to the exchange of information between such IT systems and the AIoT system.
Such processes should be standardized with the use of shared identifiers, data formats, interface definitions, and data ownership rules. It is not enough to merely capture the required information – additional care should be given to ensure that the data can be correlated to other relevant entities. As an example, while a sensor can indicate a particular event occurred, analytics may need to associate it with the correct manufacturing order and equipment before it can be utilized.
Defining such relationships from the beginning will prevent such data from being siloed and will maximize the value of the information extracted from it.
- Measure Operational Outcomes Beyond System Statistics
A common mistake while measuring the performance of an industrial AIoT system is to focus too much on generic technology-centric performance indicators such as throughput, model accuracy, and event processing rates. Operational impacts should also be measured to ensure that the technology actually serves its purpose.
As such, it is advisable to establish a set of use-case specific key performance indicators (KPIs) related to supported applications. Some examples may include equipment downtime rates, maintenance turn-around time, inventory accuracy, OEE, energy consumption per unit, and others. For each of these process KPIs, a baseline should be established prior to implementing the new technology solution and then compared to the results after its deployment. It is also important to remember that other factors beyond the technology implementation may influence these indicators and that a contextual assessment should be made.
- Operationalize Not Just Technical Commercialization
A product that is technically perfect but unaffordable or operationally incompatible with the client’s environments will fail just the same as any other commercialization or implementation mistake.
As such, technical commercialization should take into account budget, installation requirements, ongoing operations and security, documentation, and technical support costs. This is often where technical development meets venture building – the team working on the technical commercialization needs to answer not only the ‘is our solution viable’ question but also address the ‘what is the market willing to pay’ and ‘can we actually provide this solution to more than one client’ questions.
Aperture Venture Studio(https://apertureventurestudio.com/) is a venture building studio focused on realizing AIoT for real-world applications.
- Conclusion
Industrial AIoT development requires a multidisciplinary approach that touches upon business, operations, and technical development areas. The architecture that best suits a given application may vary drastically depending on the use-case, but it should always be focused on resolving a particular challenge or displaying information in an accessible manner.
For developers and founders, focusing on the use-case while maximizing the resolution of particular industrial or operational challenges is a good starting point for technical development.
Top comments (0)