Application

This component is used to store the data transferred from the test bench to the Message Broker in a time series database. If it is experimental data, the measured data is tagged with a special tag so that it is clear for the development of the ML component for which data additional context information is available and can thus be used for training / testing.

To develop and test the individual components of the web application and the ML model, it is essential that historical data can also be imported. In this way, it is possible to continue writing the software regardless of whether the system is in operation or not.

The system architecture is designed in such a way that each sensor of the test facility also plays its measured data on its own "topic". However, the ML model requires a vector as input variable. The data processing component is used to close exactly this gap and to create the required input vector for the ML model. At the same time, a low-pass filtering of the data takes place in it. At this point, we would like to point out again the measured data (second figure on the left), which are very noisy in the raw format (blue line), but can be smoothed very well by an appropriate filtering (yellow line).

This component contains the developed ML model. It should be noted here that the normalization of the measured data is done in this component and not in the data preparation.

MQTT uses so-called »Topics« so that connected clients can exchange information with each other. In the project, the topics were used to exchange both measured data and context information. For the sensors, for example, the units were transferred and for the components used, the parameterization was transferred. The figure on the left shows a section of the »Topic Tree« (element of the user interface for selecting and searching topics).

Scheme

When exchanging data via a Message Broker, there is always the risk that no clear schema has been defined, resulting in instabilities. A classic example is that a component requires numerical values as input, but suddenly a »string« is present on the message broker. In the best case the component crashes, in the worst case the component executes an uncontrolled behavior. For data transmission it was therefore specified that the individual component data must be transmitted in JSON format with the keys »identifier« (name of the sensor as string), »value« (value of the sensor as number) and »timestamp« (timestamp in unix time). The described scheme can be seen on the left in the second figure.

As mentioned above, a web application was developed to monitor the test facility in streaming mode and to start and stop the ML4P pipeline components. Furthermore, the web application provides the possibility to access the structural model of the test facility in order to obtain context information. In the developed version, the web application initially consists of a dashboard on its start page, which displays the current measured values as well as the remaining lifetime of the catalyst. Further information, especially regarding the ML model, was deliberately omitted.

For detailed results of the ML model, a separate tab was created in the web application. The tab first contains a history of the predicted lifetime. Furthermore, the value of the gradient is tapped in the artificial neural network used. This shows which of the sensors used currently has the strongest influence on the prediction result. This additional information enables process experts to deduce how the process needs to be intervened in order, for example, to be able to continue using the catalyst for as long as possible or to increase the methane conversion.

Artificial Neural Network (ANN)

You can learn more about the neural network under the »Architecture of the ML Model«  section of the following linked page:

ML model