Dies ist Teil 1 einer mehrteiligen Serie, welche beispielhaft zeigt, wie mit Hilfe von maschinellen Lernverfahren eine K.I. trainiert wird, die den Zustand einer Maschine in Echtzeit überwachen kann (Condition Monitoring). Die Teile sind folgende:

Problemstellung, Lösungsweg und Datenerhebung (dieser)
Training und Evaluation mit Tensorflow 2.0
Deployment und Anwendungsbeispiel mit Tensorflow Serving in Amazon ECS

Dabei wird ein Neuronales Netz mit Tensorflow 2.0 angelernt, als Tensorflow Serving gepackt und in Amazon Elastic Container Service (ECS) in der Cloud Deployed. Außerdem wird eine simple Beispielanwendung die Sensordaten an den Cloud Endpunkt übertragen und den Maschinenzustand visualisieren.

Problemstellung: Condition Monitoring von Maschinen & Anlagen

Der Standardfall (sofern man kein Hersteller ist) ist, dass man eine Maschine in Betrieb hat, welche zwar Sensoren für viele prozessrelevante Kenngrößen hat, der Hersteller aber keine Schnittstellen (APIs) oder Datenabgriff ermöglicht. Daher wird in diesem Beispiel gezeigt, wie man eine Maschine mit eigener Zusatzsensorik ausstattet, welche ein Condition Monitoring ermöglicht. Der Maschinenzustand soll automatisiert überwacht werden und eine K.I. soll erkennen, ob die Maschine ordnungsgemäß arbeitet oder ein Fehler aufgetreten ist.

Für dieses Tutorial ist die Maschine ein balancierender Lego N.X.T. Roboter, welcher ähnlich eines Segways aufrecht steht. Dies ist der Normalzustand. Ein fehlerhafter Zustand wäre beispielsweise, wenn der Roboter nicht mehr aufrecht steht. Die K.I. soll dies als Fehlerzustand erkennen und in Echtzeit detektieren können.

Lego Mindstorm Segway (zu überwachender Prozess) mit Tinkerforge IMU2.0 (Sensorik)

Die nachgelagerte Anwendung ist dann Business Case spezifisch, z.B. könnte eine einfache 24/7 Zustandsüberwachung Einblicke in die Verfügbarkeit der Maschine geben und schon der Mehrwert sein, den man zur Prozessverbesserung erheben möchte. Stichwort Condition Monitoring oder wenn man den Zustand nicht nur klassifiziert sondern quantifiziert dann mit Vorhersage auch Predictive Maintenance. Aber auch ein Fehler-Reporting oder das Absetzen einer automatisierten Reparatur-Anforderung kann nachgelagert ausgelöst werden.

Lösungsweg

Oftmals ist es so, dass in einem K.M.U. Maschinen eines Herstellers stehen, in dessen Sensoren/Schnittstellen man nicht ohne weiteres eingreifen kann. Daher wird eine Maschine oft mit Zusatzsensorik nachträglich “smart” gemacht. Das nachträgliche Ausstatten hat auch den Vorteil, dass man relativ schnell und kostengünstig eigene Sensorik nutzen kann. In diesem Beispiel soll die Maschine mit der Tinkerforge IMU 2.0 ausgestattet werden, welche Beschleunigung in 3 Raumrichtungen misst, Drehraten um 3 Achsen sowie Magnetfelder in 3 Raumrichtungen sowie zusätzlich Sensorfusionsalgorithmen implementiert hat.

For privacy reasons Vimeo needs your permission to be loaded.

Die Sensorik wird an der Maschine befestigt und erhebt die Daten, während der eigentliche Prozess unbeeinflusst bleibt.

Als maschinelles Lernverfahren wird ein Neuronales Netz, implementiert in Tensorflow 2.0, gewählt. Es gäbe unzählige andere Verfahren, welche sich gut oder besser eigenen würden, allerdings ergeben sich durch dieses Setup einige Vorteil.

Neuronales Netz zur Detektion des Maschinenzustands mit Eingangsdaten und Ausgabe der Wahrscheinlichkeit, ob die Maschine läuft (w) oder nicht läuft (nw)

Eingangsdaten sind die von der IMU gemessenen Sensorwerte. Der Ausgang des Classification Netzwerks ist die Wahrscheinlichkeit für den Zustand der Maschine (w=working, nw=not working).

Datenerhebung zum Training

Eine K.I. basierte Anwendung basiert immer auf Daten. Diese müssen erhoben und in strukturierter Form vorgehalten werden, damit ein maschinelles Lernverfahren eingesetzt werden kann. Das Training ist ein vorgelagerter Prozess, der nichts mit dem späteren Einsatz zu tun hat und völlig zeitlich und örtlich unabhängig zum späteren Einsatzort erfolgt.

In diesem Fall erfolgt die Datenerhebung so, dass die Sensordaten der IMU während des ordnungsgemäß laufenden Prozesses aufgezeichnet werden und in eine Textdatei gespeichert werden. In einer zweiten Datei werden Sensordaten gespeichert, während die Maschine nicht korrekt läuft. In der Realität wird die Maschine (hoffentlich) 99% der Zeit laufen und nur sehr selten, vielleicht alle paar Jahre, defekt sein. Es ist also nicht ratsam über Jahre Daten zu sammeln, während die Maschine korrekt läuft und vielleicht nur 5min dabei hat, in denen ein Fehlerfall auftritt. Die Datenmenge für beide Fälle sollte ausgewogen sein. Es bietet sich beispielsweise an Daten an einer defekten Maschine zu erheben und in etwa gleicher Menge noch mal nach erfolgreicher Reparatur.

Wichtig ist, dass relevante Prozessdaten erhoben werden, welche sich auch als Features für das maschinelle Lernverfahren eignen. Es muss ein Zusammenhang zwischen Eingangs- und Ausgangsdaten vorliegen (Kausalität), da die K.I. sonst keine sinnvollen Ergebnisse liefern kann.

Beispielhaft ist es in diesem Fall sinnvoll die Beschleunigung in die x, y, z Richtung zu messen, die Temperatur der IMU allerdings weniger. Für andere Prozesse kann es relevant sein die Temperatur zu erfassen. Dieses Expertenwissen über sinnvolle Prozessparameter muss vor jedem K.I. Projekt bekannt sein, da sonst der beste Algorithmus nichts sinnvolles in den Daten finden wird, außer zufälliger Korrelation.

Python Script

#!/usr/bin/env python
# -*- coding: utf-8 -*-

# Basierend auf dem Beispiel der Tinkerforge GmbH
# Quelle: https://www.tinkerforge.com/de/doc/Software/Bricks/IMUV2_Brick_Python.html

from tinkerforge.brick_imu_v2 import BrickIMUV2
from tinkerforge.ip_connection import IPConnection
import time

HOST = "localhost"
PORT = 4223
UID = "5Xaeob"  # UID of your IMU Brick 2.0


LOGFILE = './data.csv'

with open(LOGFILE, 'w', encoding='utf-8') as logfile:
    logfile.write(
        'timestamp,ax [m/s²],ay [m/s²],az [m/s²],rx [°/s],ry [°/s],rz [°/s],mx [µT],my [µT],mz [µT],y [°],r [°],p [°]\n')


def cb_all_data(acceleration, magnetic_field, angular_velocity, euler_angle, quaternion,
                linear_acceleration, gravity_vector, temperature, calibration_status):

    with open(LOGFILE, 'a', encoding='utf-8') as logfile:
        logfile.write('%s,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f,%.2f\n' % (
            str(time.time()),
            acceleration[0]/100.0,
            acceleration[1]/100.0,
            acceleration[2]/100.0,
            angular_velocity[0]/16.0,
            angular_velocity[1]/16.0,
            angular_velocity[2]/16.0,
            magnetic_field[0]/16.0,
            magnetic_field[1]/16.0,
            magnetic_field[2]/16.0,
            euler_angle[0]/16.0,
            euler_angle[1]/16.0,
            euler_angle[2]/16.0
        )
        )


if __name__ == "__main__":
    ipcon = IPConnection()  # Create IP connection
    imu = BrickIMUV2(UID, ipcon)  # Create device object

    ipcon.connect(HOST, PORT)  # Connect to brickd
    # Don't use device before ipcon is connected

    # Register all data callback to function cb_all_data
    imu.register_callback(imu.CALLBACK_ALL_DATA, cb_all_data)

    # Set period for all data callback to 0.1s (100ms)
    imu.set_all_data_period(100)

    input("Writing to \'%s\'. Press key to exit\n" % LOGFILE)
    ipcon.disconnect()

Fazit

Eine bestehende Maschine wurde mit kostengünstiger Sensorik ausgestattet, welche relevante Prozessdaten erheben kann. Die Sensorwerte für den funktionsfähigen und den Fehlerfall wurden strukturiert abgelegt und können im nächsten Schritt zum Training einer K.I. genutzt werden. Es gibt nun Messdaten von den 2 Zuständen, welche von der K.I. auch erkannt werden sollen: