Unlocking the power of collaborative learning on Arm MCUs

****All content for this blog written by Alexander Eroma, head of Intelligence at Octonion****

In today's industrial IoT eco-system, equipment manufacturers are facing different challenges. One of their pains is the lack of information they have about their equipment usage after the sale. Indeed, it is crucial for an Industrial manufacturer to know how the machine is used, how performant it is, and when it is starting to act 'abnormally'. The goal of having this information is to provide to its end customers a qualified recommendation for maintenance and propose better services to fit customer's needs.

In this context, the idea of having Intelligence at the edge, within the machine, and sharing received knowledge from one to many machines, seems obvious.  The manufacturer deals with a fleet of equipment and is what we call “Collaborative Learning”.

In Octonion’s Collaborative Learning approach: each industrial equipment is powered by an Arm Cortex M microcontroller (what we define as the edge) and connected to the Cloud.

Figure 1: Octonion’s edge pipeline

Each edge node manages the unsupervised AI model which provides the output used for the collaborative learning. The node is responsible for:

• Recognizing vibration patterns in unsupervised mode through dynamic clustering.
• Sending each novel pattern information into the cloud to update the shared AI model. Note that we differentiate patterns ‘known’ as already identified by the machine and sent to the cloud. Patterns ‘novel’ as first time identified by the machine, not yet sent to the cloud.
• Receive and store vibration patterns information from other nodes. 

Octonion’s pipeline of unsupervised learning at the edge can be represented as follows:

Figure 2: Octonion’s edge pipeline

The following is a short description of all the steps of the Octonion’s edge Pipeline that are done on the Arm Cortex M microcontroller:

• The signal filtration stage is used to remove the low-frequency variations and constant component of the accelerometer.
• Signal features extraction recognizes vibration patterns and build the vibration pattern descriptors. To reduce CPU load and perform evaluations effectively the CMSIS DSP library used for fast Fourier transform evaluation
• The stationary features filter is used to dropout the features representing non-stationary signal from the classification and clustering. This ensures that the eventual outlier will not be considered in the learning target.
• The pattern classifier makes decisions if observations represent the known or novel vibration pattern. Clustering procedure is used to construct vibration pattern descriptors based on past observations in unsupervised mode. If a set of objects under the current observation window was not classified as a known vibration pattern, we need to create a novel vibration pattern. At this step, we deal with relatively stationary observations, which means that one cluster represents most of the objects and the rest of the clusters contains a few objects. The goal of this clustering step is to filter out the outliers from the study population, to ensure that only the typical samples are used to build the pattern descriptors.
• The rule processor module is used to trigger user-defined actions based on recognized machine state. The rules define users such as: “if a new pattern (novel) is detected then send me an alert”. At each iteration, the rule engine takes as an input the output of data analysis pipeline and evaluates if the rules should be triggered.
• The IoT Connection module is used to send information about each vibration event to the cloud.

Now let us consider the principles of knowledge sharing across multiple nodes.

When any device recognizes a novel vibration pattern, this pattern is sent to the cloud to contribute to the shared model. The cloud application builds the model and delivers learned patterns to other edge nodes with the following assumptions:

• Each device holds a local instance of the model
• The cloud application is responsible for the shared model storage, the model correction, and versioning
• The shared model is complemented with new patterns learned at the edge

 Figure 3. Patterns sharing

One of the key aspects of this collaborative learning approach is the procedure of model correction in the cloud application.

In the real world, despite that each machine is mechanically unique, N similar machines may have N similar vibrational patterns at a global scale for the same machine operational mode or condition, even if vibration patterns are different at the local level. This approach is the rationale for the procedure of model correction.

Figure 4. Model correction procedure 

To manage globalization of different local clustering of each machine, a specific procedure of model correction is triggered. The procedure consists in applying an additional clustering to all known patterns from all nodes, so the similar vibration patterns recognized independently on different nodes can be merged into a single shared pattern. The last step is to find out groups of overlapping and tight shared patterns. Once clustering is complete, the allocated clusters replace the vibration patterns. The appropriate model correction patch is then built and sent to all edge nodes.

The Collaborative Learning process enables building a knowledge database for a given type of machine. , By persistently monitoring one machine’s output and having localized unsupervised learning, anomalies are flagged. These flagged anomalies are then pre-classified for the next similar machine. Through this collaborative learning approach, one machine’s anomalies become another machine’s known error state and previous learnings are shared between devices.

Thanks to Intelligence at the machine level, Industrial manufacturers can get a knowledge per equipment. With Collaborative learning on top, manufacturers can bring this Intelligence to a next level with machines being smarter together.

Learn More about Collaborative Learning