Utilizing AI for Gaining Efficiency in Production Processes and Improving Product Quality with MATLAB

Hi all. My name is Imola Fodor. I'm an innovation engineer in the Electrolux in the Global Technology Organization. What we do in our team is project development using AI technologies, but what is a big part of our work is also to evaluate tools and the environment to work in across the company. So what I will be talking about today is a project that we use for this kind of evaluation. And the project is about noisy fridge detection at Electrolux, so in one of our plants.

More in detail what is the agenda for today is introducing the problem in a more detailed way. I will be talking about the analysis we did in order to construct this project, how we identify challenges; what we did to overcome them; and what were the decisions that we made; and for a big part of my presentation, I will be talking about the implementation-- so how we were decreasing the signal to noise ratio; how the modeling went on; what options did we take into consideration; and what we tried. And I will be talking about the deployment of the winning model.

What is the problem? The problem is that in some cases our fridges get complaints from our customers for the noise. What we would like to leverage in this project is advanced acoustic sensor technology, the signal processing, and the modern machine learning techniques to identify the malfunctioning and anomalous noise coming from the fridge.

What we deal with is audio data. So the setting looks like this. On the right, you can see that there is an installation of a microphone that listens to the fridges. The microphone is embedded into a cupboard, which is connected to a workstation-- always in the factory. And the workstation, and the workstation, and the server is saving, also, all the data.

And one of the responsibilities of this workstation is also that it runs an application software that contains the machine learning model that gives us an output pass or fail sign. This sign goes to the responsible from the industrial operations that block a fridge, take it into a lab where our audio engineers make further analysis and assure whether the model was right or not.

About the data-- and the data is big. Daily, there are around 1,000 fridges that pass the production line. Maybe there is 1% that we are not registering, all the rest, yes. And we end up with around 2.5 gigabytes stored of audio per day.

Let's see the cobot in action as I was explaining the process. So in this simulated environment in the lab, we have assured ourselves that the cobot will get closer to the compressor itself. It will register in that moment, and it will go back to its position and save the data.

What were the challenges of this setting? One of the biggest one is the fact that there is noise also in the factory. There are various external sounds such as people talking, shouting, sirens starting, and the usual factory noise. That, the microphone unfortunately captures, because it's not a directed sort of microphone. It's actually capturing in an omni way the surroundings.

The other challenge is that we have two types of compressors. One is the variable speed and one is a fixed speed compressor. They, by their nature, are different and use different technology. But on the line itself, we cannot in this stage of the process, really, distinguish which fridge is containing which type of compressor.

One of the biggest challenges is the fact that we are not storing labels together with the audio files. There is no proof whether the stored audio is coming from a noisy compressor or not. We did create a controlled data set. In this case, we passed one extremely noisy fridge three times on the line and constructed a data set to at least work with in the initial phases.

Let's dig deeper into this data quality issue that is coming-- that is deriving from the fact that there is noise in the factory itself. What our expectations were is that we would be able to distinguish exactly what is a kind of clean compressor noise and what is the measurement that we take from noisy background and the noisy fridge itself.

In reality, we do not have recordings of pure compressor noise. What we can deal with is only audios that take into consideration-- like capture background noise-- and the ones that have the background noise and the compressor noise. Analyzing these signals, especially the frequencies, what we can see is that, in a way, the frequency is derived from the external noise, it's embedded into the frequencies of the sounds coming from the compressor. So we cannot purely eliminate to a band pass, for example, the frequencies that are not of interest.

This was a reality that we faced. And it is the fact that there is no possibility that this is track pull noise from the track. There must be different ways, also, to address noise in the files. For us, this was a trial. And we went for a different solution.

The fact that we have big data but no labels, obviously, can be a good circumstance. It cannot be for us. In a way, it was a downside, the fact that we don't have labels. Since we wanted to work with some of the examples of noises fridges, what we took into consideration is the service calls stored in the company registered from our customers.

So, taking the records of customer complaints together with a technical comment that strictly has to approve the complaints of the customer, we consider a serial number, a noisy fridge. So we track down the recording that was made previously in the factory for that given serial number. And we put it into the bunch of labels to labels.

So the decisions that we took prior to implementation-- so, to address the noise from the factory, we have installed a shield around the cobot. To use as labels, we use the service calls. What is important to note here is that there are probably in our false labels-- so noisy fridges-- possibly fridges that later on would get complaints from our customers. What we can certainly know that for the true labels, there were complaints. But for the false labels, unfortunately, we cannot know for 100% certainty that they are not really noisy from the perspective of our customers.

About the compressor types, so a fixed speed, variable speed, what we did was generalized them, the compressor types. There are no two different models for each of the two types of the compressors. We can use a subset of all the collected data. Not in any moment we are using all the data set, but since we did use a substantial amount of it. Just as a parenthesis, what really worked out for us well were the tall tables from MATLAB that fastened them, the feature instruction-- spoiler-- that I will be talking about later.

Let's talk about the different inputs that the model can get in the case of audio data. To arrive to the conclusion of the spectrogram as an input, we need to take into consideration the other inputs, too. So the raw audio files, actually, are the amplitudes in a time dimension. So that means that the mechanical energy that gets transferred, that gets translated into electrical energy is the one that is stored.

Here, we lose the information about the different frequencies that compounded a certain amplitude strength. We lose, in this way, possibly some of the typical frequencies on which the compressor actually makes the noise. To not lose this information, and to actually combine, somehow, the amplitude and the frequency information, we can work with the spectrograms. The spectrogram captured the transient features. The spectrogram takes the frequency values, along with the time, into consideration. So it's definitely a thing to try when it comes to audio files.

The main paths taken, we have considered different options to work with, also to explore better the world of audio processing. In the beginning, what was the most straightforward and logical in consideration that we work with audio engineers for this project was to do feature engineering, manual feature extraction on a controlled data set. In this way, we did have a true label, so a supervised approach made absolute sense. And to try the classical machine learning techniques like SVM, random forest, in order to see what would work best.

In this case, we used the Classification Learner for MATLAB to make this quick analysis, at least in the initial phase. Not quite satisfying results, and what we also wanted to try on this smaller data set was an unsupervised approach. In particular, what worked best was hierarchical clustering. But obviously keny alt encoders can also be taken into consideration here. The other segment that was tried is the automatic feature extraction with spectrograms as inputs.

Here, we have also two different paths to take. One is that we extract features using a well-known network that should capture all the different aspects of an image, such as alexnet or the edges, lines. And then use a classical machine learning technique, like SCM learning forest again. That's some of the techniques that usually work best-- quite well-- proved quite well. But what we also had to try was to do deep learning end-to-end.

So take spectrogram as an input. Use a deep network-- in this case, CNN, for example-- one of the most popular ones-- and see how the classification goes. In this setting, we have used the service calls as labels. Not anymore-- the controlled setting.

What purpose was hierarchical clustering and the deep learning end-to-end? What I have to emphasize here is the fact that the clustering in a real-time setting would be not so logical to implement. Because a clustering technique is not, let's say, discriminating based on an individual input-- rather on a set.

Nevertheless it was interesting to see that they are features that are relevant, that are indicating indeed what is different than the normal. We have used the audio feature extractor function inside the Audio Toolbox from MATLAB to generate all sorts of features. It was very useful to actually get the whole pool of possibilities in one place rather than how it was before that we used Python.

Hierarchical clustering as a methodology-- so based on similarity. We got the result, if we took into consideration individual features, that some of them really estimated better the difference between normal and anomalous.

Here, we can see that from the control data set of 184 files, there were three-- the three of the truly noisy fridges that recognized as indeed different-- and also false positive. But overall, a very, very good performance.

It also led us to explore further options and allowed us to think that indeed our audios are suitable to treat this problem. The next step was to use service calls and a bigger data set.

So in this case, we follow the typical path now of image processing. And that is using a deep learning technique, spectrograms of inputs, then constructing a CNN-- kind of shallow, in our case-- and use it for training. For training, yes, it has proved well. Obviously, there was a possibility that it has overfitted the situation.

So what we have seen and said that in testing it, it also proved well that 11 audios that were deriving from the serial numbers of fridges that caused complaints were recognized well. So this led us to decide to use this particular model for deployment.

Just to recap the setting from the beginning-- so what we need now to do is to embed in a way the inference script into the application that is running in the workstation in the factory. The application is written in C Sharp. And what we needed is actually a compiled piece of code-- no DLL coming from our inference code.

Inference-- no surprises here. So we loaded the network. On the input, we had the audio data. And we transform it into a spectrogram. And we use the image itself to predict the output. In case it's 1 or 0, the phase would be blocked or passed for packaging.

We have used a library compiler to actually generate this software component to be called from the main application. The application, it's a simulation environment, where we were able to import an audio file, run the DLL that was generated, and see the eventual performances. This setting in the month of October should be up and running in the factory, so here that is circle closed.

Our lessons learned and the next steps-- definitely where we saw a benefit from MATLAB is the feature extraction part-- also, the faster feature extraction for a substantial amount of audio files-- in comparison with Python, which was the primary programming language used for this project in its initial phase. What proved along the way very useful is actually the easy deployment to this external software.

Our next steps is to observe the performance in production-- the performance of this model-- to preferably get new assured labels of fridges after they get tucked in the respective labs, and to continuously improve the model itself.

What was our decision from this project regarding the tools and the environments is that MathWorks definitely should be used for treating engineering problems-- also in the future. So we would be taking it into consideration for projects, and already control system identification too. So I hope that you enjoy this presentation. I'm here for any questions. Thank you for your attention.

Welcome to the second part of today's session on utilizing AI to gain efficiency in industrial processes and improve product quality. In my role as product manager for statistics machine learning, one of my projects over the last two years has been to look into how statistical and machine learning approaches can be applied to improve manufacturing and quality. And today's presentation essentially summarize what I found so far.

So let's start by reflecting what you just heard from Electrolux. So they essentially try to improve quality control with AI. They were trying to predict whether fridges, before they left the factory and were delivered, whether they are likely to become one of those that are noisy-- and that consumers later complain about, and then they need to go out and service them.

Let's look at some of the challenges-- how they solved them and how that relates to what I'll talk about. So they had the challenge that the microphone picked up factory noise. They switched to the frequency domain and used spectrograms as features, essentially. I'll talk about various noise-filtering methods that you can apply to the signal.

They had to try multiple approaches to find a model with sufficient accuracy, which is pretty typical. I'll talk about yet some other statistical and machine learning approaches that you can try in your case, as well.

And then third, they needed to integrate with their existing factory QC system. And that leveraged a third-party solution. I'll show you how you can do something similar staying in the MathWorks ecosystem and some other ways to operationalize your process analytics.

So as main topics, though, I'll talk about these three things-- how you can access industrial process data and ingest it into MATLAB to build those models, and then how you can improve the data quality, among others, by removing noise at the signal level. And then third, how you can build models that identify the process anomalies that you are after and that may cause inefficiencies-- and also identify quality defects.

Additionally, I'll cover some other topics, as shown in this full agenda. So first, I'll talk a little bit about what we mean with manufacturing analytics. Then, I'll dig into the first main topic-- accessing data-- and how to build models with the multivariate. Statistical process control as one approach. And alternatively, normal only, we call them anomaly detection approaches-- and how you can share insights from those models with other stakeholders and operationalize them.

And I'll close on how you can improve the data quality with noise removal and feature engineering. So let's get started.

What is manufacturing analytics? Well, here you see responses to the question, what do you associate with manufacturing analytics, or smart manufacturing? Standing out are terms like predictive maintenance. Well, you heard about that in the last session, if you attended it.

Monitor quality-- well, that's what Electrolux was trying to do. But also fewer down times, higher utilization, improve quality, reduce waste. And then finally, we spot some alternative terms-- industry 4.0-- you may have heard it that way-- or smart factories.

So manufacturing analytics pursues three main goals. First, monitor a process. And there, well, you're after detecting deviations from normal. But you may also be after watching the energy usage and how much of your raw materials may be wasted. And you may try to improve asset utilization.

Then, second, monitoring the quality of what you're producing. So there the primary goal is to detect defects in what you produced. But also once you have defects identified, how you can infer the root cause-- or a little more challenging, improve the repeatability of batches you produce.

And then third, you may be optimizing yield. You may think, well, am I not trying to optimize yield by monitoring the process, or the quality? That's true. But in those two cases, you're focused typically on an individual step or the product. Here, I'm talking about optimizing across multiple steps in the manufacturing process. And that is a more challenging problem.

So let's look at some industries that have applied manufacturing analytics. And, well, they realized our ROI, which doesn't go without saying. AI has become a little bit a bad rap, that a lot of it stays in the lab and you never see the actual benefit. So all of these bullets here represent our customers applying AI to something what I summarize under the umbrella of manufacturing analytics.

So in the chemical and petrol industry, a customer monitored their fracking sites. And, well, there is tight regulations. If you exceed a limit in emissions, you may face a stiff penalty. And that's what they try to avoid by monitoring those emissions. Another customer monitored their plastic extrusion process and gained efficiency-- others, the steel rolling.

Yet another one in the steel precision part business faced competition from Asia, and wanted to differentiate on quality. So they developed a system to detect even the minute defects in their precision parts.

In the pharma industry, some monitor the quality of what they produce, like contact lenses. Or a customer needed to increase capacity of their toothpaste-- good problem to have, to produce more of your product-- but they wanted to avoid the capital expense of building additional factories. So they found a way to monitor the different phases more closely, so they could hand off from one phase to the other phase faster, and thus gain efficiency. And we see applications in semiconductor, as well.

So you may wonder, how does today's session relate to other areas? Well, we are focusing on process modeling analytics. I hope you're starting to get a sense. Last time, if you attended it, it was focused on predictive maintenance and also anomaly detection. So there is some overlap. But the other focus was on the machinery, where today the focus is on the whole process.

So with predictive maintenance, you detect anomalies in the machine. And then you wonder what's causing that. So that's called condition monitoring. And then, well, you may try to predict, how much longer can you operate that machine, to schedule maintenance not too early.

Next time, we'll be focusing on visual defect detection. So there the data is image based. And, well, finding little intrusions in contact lenses is an example for that. Whereas we focus primarily on sensor data today.

So now is a good time to look at the actual work flow. What's involved? What do you need? Well, at the highest level, you need to first, even before the start, instrument to your process with sensors.

Then, you need to access that data, prepare it, and, well, work your way towards building an effective model, that's robust to sensor failures and noise. But then, well, to actually gain ROI, you need to operationalize your model, so that it actually influences your production.

So if you're familiar with the AI workflow or data analytics, you may recognize those phases, but the details differ. So here in the data area, you may need to access the data through industrial protocols, or on process historians.

You may be facing non-Gaussian noise, that's harder to remove than Gaussian noise. Or like this former customer, index the phase of where you are in the mixing of the toothpaste components. Or in steel rolling-- where on the steel band did you identify a defect.

Then, typically, you deal with many different sensors. So it's multivariate statistics. On the build model side, well, in addition to standard classification regression, you might be applying anomaly detection. And I'll talk more about that.

Or you might be building more robust virtual sensors out of multiple unreliable sensors. So that's kind of a challenge. And finally in operationalizing, in addition to edge cloud and desktop, you might be operationalizing on these industrial controllers.

So today's sessions cannot cover all this. Instead, we'll focus on the areas highlighted, starting with accessing data. So let's dig into that area.

And here you can see an overview of how you can access industrial data to MATLAB. First, well, if you have access to an OPC server, you can access it live or historically-- both with classic OPC, or the newer OPC UA standard. So you can connect to the OPC DA server from MATLAB, or use one of the read-write blocks in Simulink.

Second, if your industrial plan stores data in OSIsoft PI system, we have an integration that allows you to bring that data into MATLAB. And finally, you can also communicate directly with protocols like Modbus, or also other more modern protocols, like MQTT.

Next, let's look at the integration with OSIsoft a little bit more. So first, well, you'll want to access the historic data. And that's done through the asset framework SDK. And then we have the MATLAB interface, that then helps to ingest that data into MATLAB.

Later, when you're ready to operationalize your analytics, there is a slightly different workflow and tools, that I'll talk about near the end of my presentation. We know that among others utilities, smart grid operators, and wind turbine vendors are using PI server, in addition to the chemical industry-- at least in the US. And OPC UA has been pretty widely adopted.

Now if your data is elsewhere, hopefully you indicated that in your answer to our poll question, or let us know in the chat. So now that we have access to the data, let's look at how you can build process analytics and models. Well, the key to find-- well, when your process is normal-- is finding anomalies. But that may be harder.

Here, well, I plotted different distributions that overlap. Now is that a statistical variation, or is it an indication of an anomaly? Not easy to tell-- even harder looking at the signal-- an anomalous versus normal signal. Clearly, that doesn't tell you anything.

If you look at the frequency range, though, you can see, well, commonality is these two peaks, but the middle peak is distinctly different. So that's the kind of information your statistical or machine learning approach needs to cue off.

Next, let's look at the popular statistical approach to identifying anomalies in sensor data. And instead of lecturing, I'll transition to a demo soon. The demo takes sensor data from aircraft engines. So you have a fan, a combustion chamber, and a nozzle. And we took 14 sensor measurements-- the speed of the fan, temperatures, and fuel flow, and data from a hundred engines across 125 flights.

So as that progresses some of them may start to show signs of wear. So that's what we are after-- the anomaly. Well, having a criterion when we need to schedule those engines for maintenance. And certainly, well, maybe a more immediate indication is that they are about to fail, and they need to be maintained immediately.

So you may think that's a predictive maintenance use case, and you are right. But, well, at its core it's very similar to what you are trying to do with a monitoring process, and even quality of your manufacturing. You are taking sensor data from that process and then identifying when it veers off normal. And that's very similar to the problem here.

One key algorithm for a multivariate process control is principal component analysis, or PCA. And, well, you'll learn what that does.

So this part of the demo is called unsupervised anomaly detection using PCA. Well, we are detecting anomalies in that sensor data. And we don't have much labeled failures. So it's unsupervised. And as I just explained, the key technique is PCA-- principal component analysis.

But let's first look at the data. Here, we are reading just some sample data in. And you recognize some of the sensors I mentioned-- different temperatures. And then if you look at the others, some speeds and flow ratios.

So as a first step, we can just look at samples of that data. And one way to do so is here with a scatter plot. And, well, in these different variables, you can clearly see some trends, like here going up, going down. But without deeper knowledge of engine behavior, it's hard to tell whether that means anything.

One simple approach to statistical process control is something called control charts. And here, we plotted for one of the sensors. If you haven't seen a control chart before-- so it shows here, the mean of the sensor data, and then applies an upper and typically lower control limit.

Often that can be one or more standard deviations, or some other control limit. And then if it exceeds that limit, like in these points near the end of the segment, that may be an indication that sensor is out of the normal range.

However, well, now it so happens this engine was not out of normal near the end of its flights. So looking at one variable really isn't meaningful. So let's build a model using more data. As a step up, we need to access the data.

And one way to ingest data is, well, typically, you would collect it from each engine separately-- maybe organize it in a folder hierarchy. Like here, we have the 100 engines and data for each engine. So the data stored in MATLAB makes it easy to just get a reference to this directory.

And then you can ingest all the files that it finds in the directory here, with this command. And that creates a table. And then here's a section of that table.

So what can we do with that data? Well, as you see above, if you plot it, it just becomes just a big band-- not very telling. So to apply a multivariate process control will normalize it and then apply the principal component analysis.

As I explained earlier, so that reduces the dimensionality of many sensors into just a few. And it, well, preserves the meaningful variance while getting rid of the noise. And it does so by finding orthogonal dimensions as linear combinations of the sensors.

But that they're orthogonal is key. And that's why you sort of preserve the meaningful variance but separate the different dimensions.

So applying PCA is simple. It's just that PCA command. And you pass it your sensor data. And then to see what's going on, you can plot the amount of variance explained by the different principal components. So here we show the first 10 of the 14. And you see here on the axis, the first already explained 75% of the variance.

So that's pretty good. That captures most of the meaningful information in that sensor data. And then adding the second, you're almost at 90%. So that's really good.

So with just those two principal components, we captured most of the key information of all that sensor data. So then how can we build a model of when those engines deviate from normal, or your process? So one way to approach it is to look at early in the process and late in the process-- when some of them weren't normal anymore.

And this shows the plot of the first and last sample. And the first one are these blue dots. They are sort of in this rectangle. Whereas the last points, well, some of them are still in the rectangle, but then others are outside here. So then the question becomes, is that meaningful? Does that indicate these engines were deviating?

Well, to drill more into that, we'll highlight the problematic engines in the plot. So here, we plotted the last 10 cycles-- again, the first and second principal components. And the problematic engines are shown in red. So now it becomes pretty clear, definitely all of those problematic engines were in the outside area, whereas none of them is in this middle rectangular.

So that really suggests maybe a good initial model is to define boundaries where you are this middle area, the engines seemed to be definitely normal. And then once they are more in the outside area, they should be scheduled for maintenance sometime soon. And then the really problematic ones were the ones all the way outside. So there they need maintenance immediately.

So that gives us an initial process model. And let's return. So now you just saw how you can apply multivariate process analytics to build an initial process model.

Next, let's apply some different approaches, more from machine learning-- namely, dedicated anomaly detection. The right approach there depends how much labeled data you have available and how much of that data is abnormal. So here to the right, it's more labeled data available-- and to the top, more kinds of anomalies.

So here in the upper-left quadrant, you have several kinds of anomalies, but very little label data. So for this kind of scenario a clustering approach might help you identify these different types of anomalies and then later classify them as such.

On the right-upper quadrant on the other hand, you have lots of label data available. So there a standard supervised learning approach might be appropriate. And you can just train that classifier to distinguish both the different kinds of anomalies, as well as your normal process.

Now interesting is the lower-right bottom corner. So there you have only normal data available-- very few anomalies-- yet you need to try to identify those few anomalies. So that's the area where a dedicated anomaly detection approach is the most promising.

Let's look at some. One basic distance based is robust covariance. So you estimate the mean and the covariance of your multi-dimensional distribution. And though to make that more robust towards outliers, that those don't shift the mean or balloon the variance, you can avoid that with that robust estimation-- though, since it's a distance-based approach, it's not working well for high-dimensional data. And it assumes normal distribution. So if that's not the case, you may not get good results.

So then, you have a distance-based methods. One is a type of support vector machine that only distinguishes one class-- the normal. Support vector machines try to maximize the margin between your classes. So that's why it's a fairly powerful classifier, and it could work well to detect anomalies in this variance.

Finally, and more recently, we've implemented something called isolation forest. So that's similar-- you may know random forest, where you grow a forest of trees to make classifications.

Here the twist is each observation is isolated in their own leaf. So then the distance from the root of the tree to the leaf becomes a measure of how many decisions you have to make to identify this sample.

And if it's an abnormal sample, typically you need to make more decisions. So a longer path means more likely anomalies. So that's the score that this model computes. The advantages of it, it applies to a mix of categorical and numeric features-- and also works on high-dimensional data.

So next, let's try this out in another demo. This one, we have data from electrolytical copper production and look at different impurities of copper, like silver, nickel, , lead and so forth. And also there is, as a kind of ground truth, a total quality index available, that indicates how pure or how polluted the copper overall was deemed to be.

So the anomalies we are detecting here are maybe any single one impurity is a problem. That's fairly easy. More interesting is if there is groups of these impurities that then cause a problem for the copper.

Now again, this doesn't apply just to copper production. You could imagine any measurements from your industrial process, like acidity or temperature or pressure. And again, you're detecting when those aren't in the normal range.

OK, so here is an example for multivariate statistical process monitoring on this copper impurity data. Let's first look at the data. Here, we read it in.

And then another way to get a sense of the data is stacked plot, which plots all these variables on top of each other. And here I pull it out, because then it becomes interactive.

And one really neat thing is you have this cursor, so you can see like, well, you may look here for peaks-- and whether there is peaks at the same spot in other areas-- like here, definitely, and not so much over here, like at this point. We have here one big peak, but not down here.

All right. Then, well, we can apply basic statistics, like finding the means and variances. If just one of these sensor variables indicates a problem, this would be an appropriate approach. And this would help you define boundaries on a percent basis.

If you need to define boundaries on groups of sensors, you'll probably want to normalize them to the same variance and mean. And this box plot shows you that.

Then, well, just as a little flashback to what you may have seen earlier, a control chart allows you to put control limits on a variable. Now here, we have eight different process variables. So you could try to spot anomalies across all these by stacking them on top of each other. But you see that gets quite awkward very quickly.

You might spot, well, here is control variations of almost all the sensors, whereas over here it's just these two. So which of those are the real process anomalies? You need to know more ground truth.

Or you switch to some of these anomaly detection approaches, that really build a model of what's normal. And one is this one-class SVM, that finds and maximizes the margin between normal and anything else. So the function to use is fitcsvm. You apply it to your data.

And then, we can display what anomalies the one-class SVM finds. Down here, I drew vertical lines for each of the detected anomalies. And then, I plotted four of the sensors and marked with a red circle where there is anomalies. So over here there was the area with aligned spikes in multiple variables. So no surprise, it detects those.

But then there is other areas. Like here, we have a big spike, and no spikes down here. That was the one-class SVM.

Alternatively, we can apply other similar methods, like the isolation forest. Similar to one-class SVM, you pass to the function the data. And then, you need to give an indication how often anomalies occur. And then it builds that scoring model. And then, well, we could look at that just by itself. Or let's just compare what various anomaly detection methods are finding.

So here in this chart, I plotted the one-class SVM isolation forest and the control charts violations on top of each other-- and here at the bottom, to give us an indication about truth, this total quality index. So if you think of that as the total amount of impurity, if it's high, then the copper really is not pure enough.

So while we can see the one-class SVM just detected this one spike-- this anomaly-- isolation forest-- this one in addition. And then the control charts violations, there were a couple additional ones.

If you look at this index-- so maybe this one and that one really is too impure. So if that's true, the isolation forest seems to do best on this very limited set. But really to compare multiple methods what you need is at least limited test set of known anomalies. And then you can compare how many of those anomalies each approach finds.

So now we have covered anomaly detection. Next, let's discuss how you can operationalize your process and quality monitoring model-- and starting with empowering those who typically oversee your manufacturing process and adjust parameters. Empower those with the inside. So integrate into an enterprise system, just like Electrolux did in their case study.

To make that easy, we have a process for building custom apps. So you can deliver the insights and alerts that your process is drifting from normal in a custom app. And MATLAB App Designer makes that easy, by letting you assemble standard interface components on a canvas. And then, you can reuse the code you developed while building the anomaly detection model. Reuse that in the callback code.

And you can use standard elements like bottoms, tables, fields, gauges, knobs, switches, and containers, such as panels and context menus. Clearly, it won't be your process engineers operators that can't code that built this app. That's the team that has MATLAB experience.

So once you've developed the app, next step is to package it. And depending on how in your production environment it should be used, you can either build a standard executable, if those operators have access to a computer. Or if they are still use to an Excel workflow, you can package the app as an Excel add in. Or finally, you can package this as a web app, that can be accessed from multiple places.

To demonstrate how you can share your process analytics this way, we cast the second demo that identified the impurities in copper in an app. So first, I'll run it on my desktop, and then I'll show you the web version.

So here, I opened up the App Designer in MATLAB. And here is the canvas. Over here, you have all the different standard components that you can integrate in your canvas-- and then start to build up an interface of different elements.

So you see in frames the different elements. And then behind the scenes there is some callback code. And into that callback code, you can reuse some of the modeling code you have developed.

Here, I've started this app locally. And you recognize here, well, just the display of the different sensor variables. And, well, it even has that vertical cursor across multiple sensors.

So then, well, we can look at the control chart. But more interesting is, well, the anomaly detection. Here, well, we need to focus on one variable-- like here, the silver content.

And now it's plotting here the control chart violations-- one-class SVM. So a cluster here, but not hear this spike, whereas the anomaly isolation forest caught that in the total quality index. Seems to be high impurity, so that's a good one.

All right. So you can share this app with others once you compile it, and they can just run it. Or you can bring it to a web page. So here, we stood up a little server that runs that same application. You can see here all the same elements that I just showed.

So you have seen how you can create a custom app for operators to access your process analytics. You know, well, this app you can run on a server. And if you need to scale that server to many parallel access for a large group of operators, you might use MATLAB Web App Server to help you with that.

So to round out our story of how you can operationalize your process analytics, let's look at this detection of the two main ways to operationalize process analytics and any AI in MATLAB. So far I've talked about the right-hand side-- how to deploy your analytics to an enterprise system. And if not as a custom web app, as I just showed, then you can integrate it as software components, like dot net, Java, DLL-- within your existing enterprise system, just like Electrolux did into the existing QC system.

Alternatively-- and that's shown on the left side-- you can automatically generate low-level code from high-level MATLAB code and then deploy that code without having to recode it in a different language, like CC++, or CUDA. So for easy-use microcontrollers, MATLAB coda translates to CC++.

If you want to run on a GPU, we have GPU coda that translates to CUDA. And we also have automated code generation to HTL for specific hardware, like FPGAs.

Let's also go back to integrating data with OSIsoft-- one of the popular historians. So earlier I talked about how you can ingest process data in PI system via the asset framework SDK into MATLAB and develop your process analytics models.

Now as you deploy and operationalize, you can leverage MATLAB Production Server, that has an interface to PI server, and can get data there near real time-- and can also help handle the streaming data and orchestrate paralyzing computation to multiple workers as needed.

Some companies have applied this workflow-- like Enel Green Power, who implemented a monitoring system of their geothermal sites, and reduced down times. For ongoing monitor, they ingest data from PI system via the interface I just showed. But they also have developed an adaptive control in Simulink and deployed that to Siemens PLC for real-time adjustments.

OK, so let's look at the workflow. We covered operationalizing to both enterprise system and the edge. Next, let's go back to improving the quality of your data, in case that's needed-- in case you can't build sufficiently accurate models just working on the signal, like I've shown in the demos.

So then you may have to remove non-Gaussian noise. So that's pretty typical for process data-- non-Gaussian noise. On the other hand, you have edges that may carry key information. So then standard smoothing filters, like mean, they tend to even out all those edges. And if those carry key information to help you distinguish normal from abnormal, you are hosed.

Well, so then you need to consider robust noise removal, that preserves at least some of those edges-- like shown here with these arrows. A simple, robust filter is median. As we'll see in a minute, that's not doing a great job. Better is something like Savitzky-Golay, where you fit a polynomial locally to the signal. And that does capture some of those edges.

Though if you need even better preservation of edges, you may lean deeper into our signal processing tools, like Wavelet Denoising from the Wavelet Toolbox-- which retains even more of the edges while also removing more of the noise.

So here you can see how in the jaggedy signal those edges are almost fully preserved. At the same time, looking at signal-to-noise ratio, the Wavelet Denoising has the highest-- better than Savitzky-Golay and much better than the pretty basic moving average filter.

So let's see that in action and look at another demo. So here, we are in the demo with vibration data. If you were in the last session, this is a quick reminder-- otherwise a quick introduction.

So we are looking here at vibration data from an industrial machine-- three channels. And, well, in blue is after the maintenance. So that's the normal operation. Whereas in red is before maintenance. And we take that as a proxy for anomalies. And here this is channel one. You can see how before maintenance.

So the anomalous data, they differ. You have all these spikes. And similarly on channel two, big spikes. Here in blue, red, small cluster of spikes. Whereas in channel three, it's much more overlapped. So let's see what noise filtering can do here.

We'll read in just a sample of that data. And then one easy interactive way to try out different methods is this smooth data life task. You can find that here on the Insert tab task. There's a whole number of data preprocessing.