Herzlichen Glückwunsch zu Ihrer Entscheidung, moderne Analysemethoden in Ihrem Werk zum Einsatz kommen zu lassen!

Um aus der Analysennutzung das Beste zu machen, schlagen wir vor, dass Sie sich etwas Zeit nehmen, um sich mit dem verfahrenstechnischen Prozess vertraut zu machen und darüber nachzudenken, wie Sie diese Lösung am besten in Ihre bestehende Organisation integrieren. Ein neues Leistungspotenzial einzusetzen ist weitaus komplexer, als nur ein neues Softwarepaket zu installieren.

Bei Ihrer Planung sollten Sie u.a. Folgendes berücksichtigen:

1. Eine Software-Installation braucht IT-Experten, die das Programm zum Laufen bringen und die Berechtigungen einrichten.
2. Ingenieure werden die Daten auswählen, die modelliert werden sollen.
3. Prozessexperten werden das Modell überprüfen, werden es feinjustieren und über seine Eignung entscheiden.
4. Die Anwender der Software müssen trainiert und angeleitet werden, um sie optimal zu nutzen.
5. Das Management wird über die Anwendungspolitik zu entscheiden haben.
6. Aktionspläne müssen im Rahmen eines Change Managements entworfen und umgesetzt werden, damit die Ergebnisse der Analysen auch praktisch genutzt werden können.
7. Der gewonnene Nutzen und die gemachten Erfahrungen müssen dem Unternehmen als Feedback rückgekoppelt werden.
8. Mit algorithmica technologies wird man Kontakt aufnehmen, wenn es nötig ist, das Modell oder die Software den eigenen Erfordernissen kundenspezifisch anzupassen.

Wir möchten Sie deshalb dazu ermuntern, dies alles als eine Aufgabe des Projektmanagements anzusehen, bei dem es Stakeholders, ein Führungsteam, einen Projektmanager und diverse Teamplayer gibt. Wir behandeln in diesem Handbuch das Thema des Projektmanagements nicht im Detail und gehen vielmehr davon aus, dass Ihr Unternehmen diese Kompetenz bereits beherrscht.

Die Einführung eines Analyse-Programms wird jedenfalls für eine Reihe von Leuten Veränderungen ihrer Arbeitsumgebung notwendig machen. Es wird also eine Umstellung erfordern, diese Mitarbeiter mit neuen Arbeitsmethoden vertraut zu machen und die neue Technologie in den Arbeitsablauf zu integrieren. Ein Mindestmaß an Change Management wird somit erforderlich sein, um das Programm im Unternehmen fest zu verankern.

Das Projekt, die neue Software in Ihrem Unternehmen einzuführen, beinhaltet sechs Phasen:

1. Die Software muss installiert und konfiguriert werden. Das wird im Kapitel über die Installation näher beschrieben.
2. Es muss festgelegt werden, auf welche Tags das Modell ausgerichtet werden soll, und für jedes dieser Tags müssen einige Informationen definiert werden. Welche Informationen das sind, wird im Installations-Kapitel kurz angesprochen und im Umsetzungs-Kapitel näher ausgeführt.
3. Historische Daten müssen vorbereitet und für die ausgewählten Tags hochgeladen werden. Das Modell wird erlernt auf der Basis dieser historischen Daten.
4. Das Modell wird verwendet und bewertet aufgrund seiner Qualität und seiner Tauglichkeit. Allerdings wird dann noch eine Feinjustierung der Modellparameter notwendig sein, damit das Modell die tatsächliche Situation präzise beschreibt und das anstehende Problem auch tatsächlich lösen kann.
5. Ist das Modell ausreichend angepasst, kann die Software in produktiver Weise eingesetzt werden, indem man sie an die Quellen der aktuellen Daten anschließt, so dass sie periodisch die Antworten auf die gestellten Fragen berechnen kann.
6. Jetzt ist zwar die Aufgabe der Anwendungs-Installation beendet, doch beginnt nun – mit Hilfe des Change-Managements – die Aufgabe, die Lösung in den Arbeitsprozess des Unternehmens zu integrieren.

Es wird nachdrücklich empfohlen, ein Projektmanagement-Team ins Leben zu rufen, um die moderne analytische Software im Unternehmen einzuführen. Wie oben bereits kurz angedeutet, wird dieses Projekt es nötig machen, dass eine Reihe von technischen und innerbetrieblichen Funktionsträgern an diesem Prozess teilnehmen und einige Entscheidungen getroffen werden, die ein gemeinschaftliches Agieren dieser Funktionsträger erfordern.

Dem Projekt sollte ein Projektmanager vorstehen, der die Verantwortung dafür übernimmt, dass die nötigen Aufgaben erfüllt werden, und der auch die Autorität innehat, die am Projekt Beteiligten aufzufordern, ihre jeweiligen Inputs zu geben. Das Projekt kann mittels Leistungsindikatoren (engl. key performance indicators, oder KPI) gesteuert werden, die von der Software vorgeschlagen werden – wie etwa die Zahl der Optimierungsvorschläge, die Zahl der bereits umgesetzten Vorschläge, die Genauigkeit des Modells usw .

Die Phasen des Projektes wurden weiter oben bereits kurz eingeführt. Phasen 1 und 5 werden federführend von der IT übernommen und erfordern die Kooperation der IT-Abteilung. Phase 3 ist im Wesentlichen die Aufgabe der Person, die die historischen Daten verwaltet; aber auch hier könnte die Zusammenarbeit der IT-Abteilung notwendig sein.

Phasen 2 und 4 erfordern tiefergehende Kenntnisse und Erfahrungen im Bereich von Prozessveränderungen. Wir empfehlen dazu, Phase 2 als Workshop durchzuführen, der vom Prozessmanager sowie von Ingenieuren und Anlagenbetreibern besucht wird. Diese Personen können dort im Detail die notwendigen Informationen besprechen (wie sie im Kapitel über Know-How beschrieben werden). Phase 4 beinhaltet die Bewertung der Qualität und Passgenauigkeit des Modells bzw. auch seine Feinjustierung für den Fall, dass die Qualität noch verbessert werden muss. Wir empfehlen, dass dieser Schritt von einem Prozess-Experten durchgeführt wird. Im Allgemeinen wird ein Prozess-Experte seine persönliche Philosophie haben, wie die Dinge funktionieren, und diese Philosophie wird ihn auch bei der Abstimmung des Modells leiten. Dieser Person sollte man ausreichend Zeit geben, um der Aufgabe gerecht zu werden und sich in die Details einzuarbeiten. Diese Phase stellt einen kritischen Schritt dar, um die Software korrekt zu konfigurieren. Zuvor unterlaufene Fehler und Versäumnisse können jetzt noch korrigiert werden. Fehler, die in dieser entscheidenden Phase noch gemacht werden, können später zu Problemen führen.

Phase 6 ist die Phase des Change Managements. Hier wird das Modell in die tagtäglichen Abläufe der Anlage eingeführt. Das könnte es erfordern, Richtlinien und Verfahrensabläufe zu verändern und entsprechende Management-Absicherungen einzuholen. In jedem Fall wird es nötig sein, die Anlagenfahrer davon zu überzeugen, die Modelle zu akzeptieren und ihnen auch zu vertrauen. Damit die Modelle wirklich von Nutzen sind, sollten die Software-Ergebnisse entsprechende menschliche Handlungen nach sich ziehen. Bei Vorhandensein einer Advanced Process Optimizer (APO) Software müssen die diesbezüglichen Vorschläge umgesetzt werden. Im Falle von IHM beispielsweise muss man den Alarmsignalen nachgehen, und es werden gegebenenfalls auch Wartungsarbeiten notwendig sein. Das Management und die Anlagenfahrer müssen sich über die zu verfolgende Vorgehensweise verständigen und darin übereinstimmen. Diese Phase ist der kritische Punkt, an dem es sich entscheiden wird, ob die Software wirklich nutzbringend zum Einsatz kommt. Wir empfehlen, dass der Prozess der Nutzer-Anwendung gemessen wird, und zwar mit objektiven, numerischen KPIs – wie etwa die Zahl der umgesetzten Vorschläge (APO) oder die Zahl der Alarmsignale, auf die reagiert wurde (IHM).

Der ganze Prozess kann vernünftigerweise innerhalb von drei Monaten umgesetzt werden. Wir empfehlen, dass das Projektteam einen ebensolchen Zeitrahmen anstrebt; denn die Erfahrung hat gezeigt, dass die Projektzufriedenheit und die Benutzerakzeptanz bei viel längeren Projektlaufzeiten sinkt.

Dieses Kapitel beschreibt, wie die Software so zu installieren ist, damit sie korrekt läuft. Nach der Installation muss die Software allerdings noch für den speziellen Anwendungsfall konfiguriert werden, wie dies im Kapitel über die individuellen Lösungen beschrieben wird.

Die Software-Anwendung läuft auf einem 64-Bit Microsoft Windows Betriebssystem. Wir empfehlen Windows Server 2008R2 oder eine spätere Version. Der Server sollte für die historischen und die zukünftigen Daten genügend Speicherplatz haben. Dazu empfehlen wir mindestens 1 TB freie Speicherkapazität. Prozessor und Speicher können handelsüblich sein, etwa ein i7-Prozessor und ein 16GB RAM-Speicher. Falls Rechnergeschwindigkeit ein Problem darstellen sein sollte, kann man dies durch eine schnelle high-end GPU Grafikkarte von Nvidia erreichen, weil wir deren CUDA/CULA-Support nützen können. Das ist viel effizienter, als wenn man eine high-end CPU kauft.

Wir empfehlen, dass der Server ein RAID-System beinhaltet, um Datenverlust wegen Speicherausfall zu verhindern. Wir empfehlen ferner, dass regelmäßig ein Daten-Backup der Datenbank vorgenommen wird, um einen Systemverlust auszuschließen.

Die Firewall zwischen dem OPC-Server und der Anwendung muss ebenso geöffnet sein wie die Firewall zwischen der Anwendung und dem Office Netzwerk des Nutzers.

algorithmica benötigt ein Nutzerkonto des Servers mit Administratorenrechten.

Am Tag der ersten Software-Installation benötigt der Server vollen Internetzugang, um die Ruby-on-Rails-Umgebung korrekt zu installieren. Nach dieser anfänglichen Installation kann der Internetzugang für alle Zeit gekappt werden.

Um fortlaufende Updates/Upgrades-Dienste zu leisten, Beratung zu geben und kundenspezifische Anpassungen vornehmen zu können, benötigt algorithmica Fernzugriff auf den Server.

Hier ist eine Checkliste der notwendigen Voraussetzungen:

• Hardware
  • Mindestens 1 TB freier Speicherplatz
  • Standardprozessor, z.B. i7 920 oder besser
  • Mindestens 16GB RAM
  • Optional eine NVIDIA GPU
  • Optional ein RAID-System
  • Optional ein regelmäßiger Daten-Backup
• Software
  • 64-Bit Microsoft Windows Betriebssystem
  • algorithmica Nutzerkonto mit Administratorenrechten
  • Offene Firewall zwischen OPC-Server und der Anwendung
  • Offene Firewall zwischen der Anwendung und dem Office Netzwerk
  • Internetzugang am Tag der Software-Installation
  • Fernzugriff für algorithmica

Die Software-Installation wird vollautomatisch vom Installer-Programm vorgenommen, das Ihnen von algorithmica technologies zur Verfügung gestellt wird. Dazu brauchen Sie nichts weiter zu tun, als Ihren Computer mit einer Internetverbindung auszustatten und den Installer auszuführen.

Der Installer wird die folgenden Programme installieren

1. PostgreSQL: Die Datenbank-Management-Software, die sämtliche Daten enthält.
2. pgAdmin: Die Administrationskonsole für PostgreSQL.
3. Ruby: Die Sprache hinter dem Nutzer-Interface.
4. Ruby on Rails: Das Framework, mit dem das Nutzer-Interface geschrieben wurde.
5. Bundler: Der Package-Manager für Ruby on Rails.
6. Git: Ein Versionierungswerkzeug, mit der aktuelle Versionen von Plug-ins geladen werden.
7. Node.js: Eine Javascript-Bibliothek, die für das Nutzer-Interface benötigt wird.
8. Sqlite: Eine Datenbank-Management-Software, die zwar nicht angewendet wird, aber einen integralen Teil von Rails darstellt.
9. SQL Server Support: Notwendiges Rails-Hilfsprogramm, um die Verbindung zur Datenbank herzustellen.
10. Rails DevKit: Notwendiges Rails-Hilfsprogramm, um einige Plug-ins zusammenzustellen, die in Codeform dargestellt werden.
11. Gems: Eine große Zahl von Erweiterungen für Ruby on Rails, bekannt als "gems".
12. AI: Die Software von algorithmica technologies für maschinelles Lernen, welche die Analyse hinter den Anwendungen vornimmt.
13. Softing OPC: Der OPC Client, der zum Datenlesen verwendet wird, nutzt das OPC Toolkit der Softing AG, für den algorithmica eine Entwicklungs-Lizenz hat.

Alle diese Programme sind lizensiert durch Lizenzen von MIT, BSD oder GNU LPGL. Diese können für kommerzielle Zwecke ohne Zusatzkosten genutzt werden. Alle diese Programme werden nur verwendet, um Daten zu speichern und ein Nutzer-Interface anzubieten. Alle mathematischen Analysen werden von der Software durchgeführt, die algorithmica technologies entworfen hat – und zwar ohne Verwendung von Komponenten Dritter.

Der Installer erstellt auf dem Computer ein neues Nutzer-Konto mit dem Namen "postgres" und dem Passwort "admin". Dieses Konto ist wichtig und wird von der Datenbank benötigt. Innerhalb der Datenbank wird der Installer einen neuen User erstellen mit Namen "viewer" und dem Passwort "viewer".

Die Software ist nun lokal installiert. Wollen Sie jetzt die Software testen, brauchen Sie mit dem Einrichten des Netzwerkes nicht fortzufahren. Wollen Sie hingegen von anderen Computern aus die Oberfläche anschauen, ist das Einrichten des Netzwerkes notwendig.

Die Oberfläche überträgt seine Webseite auf Port 3000. Damit Sie von einem anderen Computer die Oberfläche anschauen können, benötigt der andere Computer Zugang zur IP-Adresse des Anwendungscomputers, und der Anwendungscomputer muss in der Lage sein, seine Inhalte zurückzusenden. Das könnte es erforderlich machen, die Firewalleinstellung zu verändern. Weil dies von der Netzwerkkonfiguration abhängt, sollten Sie diesbezüglich mit Ihrer IT-Abteilung sprechen. Am Anwendungscomputer muss Port 3000 für das HTML-Protokoll geöffnet sein, um seine Inhalte zu übertragen.

Bitte überprüfen Sie die erfolgreiche Installation, indem Sie Ihren Browser starten und eingeben: "http://localhost:3000". Jetzt sollten Sie eine Login-Seite sehen. Das ist die Oberfläche. Loggen Sie sich ein als "admin" und mit dem Passwort "admin". Wenn dieses Login funktioniert, ist die Software korrekt lokal installiert.

Um zu überprüfen, ob die Netzwerkeinrichtung auch richtig funktioniert, laden Sie die Seite erneut, indem Sie die IP-Adresse des Computers in denselben Browser tippen, d.h. "http://[IP-Adresse]:3000". Wenn Sie jetzt bei derselben Login-Seite landen, funktioniert auch die Netzwerkeinrichtung, und Sie sollten jetzt in der Lage sein, von jedem anderen Computer Ihres Büronetzwerkes auf die Oberfläche zuzugreifen, wenn Sie die IP-Adresse in den Browser eingeben. Sollte das jedoch nicht funktionieren, obwohl der vorherige Schritt erfolgreich war, so müssen die Netzwerkeigenschaften geändert werden. Bitte setzen Sie sich mit Ihrer IT-Abteilung in Verbindung, um in dieser Sache unterstützt zu werden.

Der Installer wird für das Interface auch einen Windows-Service einrichten. Wird der Computer je neu gestartet, wird auch die Oberfläche automatisch zusammen mit dem Neustart des Computers gestartet. Somit kann auf die Oberfläche jederzeit zugegriffen werden, sobald der Computer eingeschaltet ist.

Damit ist die Software-Installation beendet.

In dieser Phase kann es verschiedene Probleme geben:

1. Der Installer stürzt ab mit einer Fehlermeldung.Bitte überprüfen Sie, ob Sie Administratorenrechte für den Computer besitzen, auf dem Sie den Installer gestartet haben. Bitte prüfen Sie auch, ob Ihre Internet-Verbindung funktioniert oder in irgendeiner Weise eingeschränkt ist. Überprüfen Sie zudem, ob Ihr Betriebssystem ein 64-Bit-Microsoft-Windows-System ist.
2. Der Installer wird ohne Fehlermeldung beendet, aber die Seite "http://localhost:3000" zeigt nichts an.Abhängig von Ihrem System kann es eine Zeitverschiebung von wenigen Minuten geben zwischen dem Ende der Installation und dem Start des Webservers. Warten Sie bitte bis zu fünf Minuten, nachdem der Installer sich abschaltet, und versuchen Sie es dann erneut. Wenn sich die Seite immer noch nicht laden lässt, ist der Webserver nicht eingeschaltet. Um ihn manuell zu starten, starten Sie bitte eine Eingabeaufforderung, navigieren Sie dann zum Installationsordner und führen Sie den Befehl "rails s -b [IP-Adresse]" aus, um den Webserver zu starten. Warten Sie zwei Minuten, um ihn zu starten und die Webpage dann neu zu prüfen. Die Webseite sollte nun ganz normal hochfahren – oder aber die Eingabeaufforderung wird eine Nachricht enthalten, die Ihnen die Ursache des Problems nennt.
3. Die Seite "http://localhost:3000" wird gut angezeigt, die Seite "http://[IP-Adresse]:3000" jedoch nicht.Die Software und der Oberflächenserver arbeiten einwandfrei. Das Problem besteht allerdings im Routing zur IP-Adresse. Setzen Sie sich bitte mit Ihrem IT-Netz-Administrator wegen der Öffnung des Port 3000 fürs HTML-Protokoll in Verbindung.
4. Die Seite "http://[IP-address]:3000" wird am lokalen Computer gut angezeigt, aber nicht auf den anderen Computern. Es gibt ein Problem mit der Netzverbindung und höchst wahrscheinlich mit der Firewall. Setzen Sie sich bitte mit Ihrem IT-Netz-Administrator in Verbindung.
5. Es besteht ein anderes Problem; oder eines der oben genannten Probleme bleibt bestehen.Setzen Sie sich mit algorithmica technologies in Verbindung und bitten Sie um Hilfestellung. Geben Sie genaue und detaillierte Informationen über Ihr System, was Sie bisher getan haben und wie sich das Problem genau darstellt. Vielen Dank für Ihre Geduld!

Jede Datenanalyse hängt von der Qualität der zur Verfügung gestellten Daten ab. Wir gehen in zunächst davon aus, dass alle wichtigen Aspekte des Prozesses oder der Maschinerie im Datensatz aufgenommen werden. Fehlen wichtige Daten, wird die Modellierung nicht so gut funktionieren wie wenn diese Daten bereitstehen. Auf der anderen Seite ist es auch nicht gut, das Modell mit einer Vielzahl von unwichtigen Messungen zu überfrachten. Die wichtigste Tätigkeit zur Modellierung ist eine vernünftige Auswahl der Tags, die für die Modellierung bereit stehen sollen. Wir können sagen, dass bei einer Industrieanlage mit einem komplexen Leitsystem weniger als 10% aller verfügbaren Messungen für die modellhafte Darstellung des Prozesses nötig und wichtig sind.

Falls Sie im Zweifel darüber sind, ob eine Messung berücksichtigt werden soll oder nicht, sollten Sie sich eher für (und nicht gegen) diese Messung entscheiden. Der Grund dafür ist derselbe, der auch für menschliches Lernen entscheidend ist: Wenn Sie irrelevante Informationen bereitstellen, mag das zeitaufwändig und irritierend sein, aber diese Informationen werden Sie nicht daran hindern, Zusammenhänge zu begreifen. Fehlen aber wichtige Informationen, so kann es sein, dass Sie kein ausreichendes Verständnis gewinnen. Im Zweifelsfall ist es also besser, Messdaten mit einzubeziehen als sie wegzulassen.

Die meisten Archivsysteme verfolgen die Regel, nach der sie den neuen Wert eines bestimmten Tags nur dann aufzeichnen, wenn es von dem letzten aufgezeichneten Wert um einen Mindestbetrag abweicht. Diesen Mindestbetrag bezeichnet man als den Kompressionsfaktor. Das bedeutet, dass manche Messungen häufig aufgezeichnet werden und andere nur selten. Für den Zweck des Aufzeichnens ist dies ein enorm platzsparender Mechanismus.

Für die Analyse und das maschinelle Lernen müssen wir die Daten allerdings zeitlich abgleichen. Für jeden Zeitstempel müssen wir den Wert jedes Tags zu dieser Zeit kennen. Die meisten Methoden des maschinellen Lernens erfordern es, dass der Zeitabstand zwischen den fortlaufenden Messungen immer derselbe ist.

Um von der üblichen historischen Datenaufzeichnung zu dieser Tabelle der abgeglichenen Daten zu kommen, verwenden wir die allgemeine Regel, dass der Wert eines Tags solange als derselbe angenommen wird, bis wir einen neuen Wert erhalten. Eine Zeitreihe kann dann wie eine Treppe aussehen. In den meisten Fällen führt diese Datenauflistung zu einem Wachstum des gesamten Datenvolumens, weil viele Werte oftmals erscheinen. Das wird man aber nicht verhindern können.

Aus diesem Grund wählen wir ein vernünftiges Datenintervall. Das heißt, dass die Zeitabstände zwischen den sukzessiven Ablesungen in dieser Tabelle nicht zu klein sein dürften, um nicht zu viele Daten anzusammeln, aber auch nicht zu groß, weil sonst der dynamische Prozess nicht sichtbar wird. Das Zeitintervall sollte deshalb mit Sorgfalt ausgewählt werden, möglichst basierend auf der Erfahrung der inhärenten Zeitskala des Prozesses, den man modellieren möchte.

Ein Datensatz muss einen Anfang und ein Ende haben. Um ein IHM-Modell zu trainieren, wählen wir sorgfältig eine Trainingsperiode aus, so dass wir für eine bestimmte Zeitspanne das reibungslose Verhalten der zu überprüfenden Maschine aufzeigen können. Sind wir davon überzeugt, dass externe Bedingungen, etwa die Jahreszeiten, für eine genaue Darstellung des Prozesses von entscheidender Bedeutung sind, so benötigen wir Daten für diese verschiedenen Bedingungen. Um den reibungslosen Zustand einer Maschine genau darzustellen, reicht in der Regel eine Zeitspanne von drei bis sechs Wochen aus. Diese Wochen müssen nicht unbedingt fortlaufend sein. Fallen saisonale Veränderungen ins Gewicht, wählen wir je eine Woche aus dem Frühling, dem Sommer, dem Herbst und dem Winter. Für ein Optimierungs-Modell empfehlen wir allerdings ein ganzes Jahr aufzuzeichnen, um die saisonalen Varianten ausreichend einzubeziehen.

Für die Zeitspannen, die wir für das Training des Modells auswählen, kann es aber vorübergehende Zustände geben, die wir nicht zugrunde legen sollten. Wenn eine Maschine beispielsweise jeden Abend abgeschaltet wird, wollen wir das Modell natürlich nicht auf diese Zeit ausrichten, während der die Maschine nicht funktionsbereit ist. Aus diesem Grund bietet die Software Ausschlussmöglichkeiten für bestimmte Messwerte an. Man könnte etwa bestimmen, dass alle Datenpunkte, bei denen die Rotationsrate einer Turbine weniger als 500 U/min beträgt, vom Modell ausgeklammert werden sollen. Die für solche Entscheidungen notwendigen Tags müssen dann in den Datensatz aufgenommen werden.

Nachdem diese Entscheidungen getroffen wurden, müssen die ausgewählten Tags dem Modell bekannt gemacht werden, indem gewisse Informationen bereitgestellt werden. Neben einigen verwaltungstechnischen Informationen wie Name und Werteinheit benötigen wir noch einige zusätzliche Fakten. Weil es zuweilen Messfehler gibt, müssen wir die erlaubte Bandbreite der Messungen kennen, damit sehr niedrige oder sehr hohe Messwerte als Ausreißer identifiziert und ausgeklammert werden können. Wir benötigen auch die Messunsicherheit, damit wir diese Unsicherheit in den Ergebnissen der Analyse (als Ergebnisunsicherheit) berücksichtigen können. Wenn Sie mehr darüber wissen möchten, schauen Sie im Abschnitt über den mathematischen Hintergrund nach. Für IHM müssen wir auch wissen, welche Messungen dynamische Begrenzungen erhalten sollen, die einen Alarm auslösen. In der Praxis werden die allermeisten Messungen des Modells keine Alarmsignale hervorrufen, sie liefern aber Informationen und den Kontext für diejenigen Messungen, die Alarme hervorrufen sollen. Für APO etwa müssen wir wissen, welche Tags direkt vom Anlagenfahrer kontrolliert werden können und welche nicht kontrolliert werden können.

Als Alternative könnten Sie für jede Messung bis zu drei statische Alarm-Spielräume spezifizieren. Das ist notwendig, damit IHM die traditionelle Zustandsüberwachung unterstützen kann – zusätzlich zum Ansatz der dynamischen Grenzwerte. Dieses System von Analyse und Alarm unterscheidet sich von der Modellanalyse und ist als völlig optional zu betrachten. Diese Bandbreiten werden am besten in der Grafik unten erklärt.

Summa Summarum: dies sind die Entscheidungen, die Sie zu Beginn im Hinblick auf Ihren Datensatz treffen müssen:

1. Welche Tags sollen aufgenommen werden?
2. Welcher Zeitabstand soll benutzt werden?
3. Über welchen Zeitraum soll der Datensatz laufen?
4. Über welchen Zeitraum soll das Training laufen?
5. Welche allgemeinen Zustände sollen ausgeklammert werden?
6. Welche Zustände sollen für den jeweiligen Tag ausgeklammert werden?
7. Für jeden Tag gilt es zu fragen:
   1. Welches soll die erlaubte Bandbreite der Messwerte sein?
   2. Wie unscharf ist die Messung?
   3. Soll dieser Tag modelliert werden und Alarme auslösen?
   4. Kann dieser Tag direkt vom Anlagenfahrer kontrolliert werden?
   5. Als Option: Welches sind die Bandbreiten für die statischen Alarmmeldungen bei gelben, orange und roten Alarmsignalen?

Die Software hat drei Hauptkomponenten. Die zentrale Datenbank, in der alle Daten und Modellinformationen gespeichert werden, ist eine PostgreSQL-Datenbank. Die Daten werden von einem Kommandozeilenprogramm analysiert, das Daten aus der Datenbank ausliest und die Ergebnisse der Analyse wiederum in die Datenbank speichert. Der Nutzer interagiert mit diesem System durch eine Browserbasierte graphische Oberfläche auf der Basis von Ruby-on-Rails.

Alle drei Komponenten werden typischerweise auf einem einzelnen Computer auf dem Gelände der Institution des Nutzers installiert. Alle Nutzer können mittels irgendeines Webbrowsers auf die Oberfläche zugreifen, und zwar von jedem Gerät aus, das mit dem Intranet der Institution verbunden ist, vorausgesetzt, die entsprechende Firewall erlaubt diesen Zugang. Weil die Software auf dem Gelände installiert wird, stellt dies keinen Cloud-Service dar, und die Daten bleiben vor Ort. Es gibt also kein Sicherheitsrisiko, sei es durch den Verlust firmeneigener Daten oder durch Hacker-Angriffe.

Die drei Komponenten können auch auf unterschiedlichen Servern installiert werden, falls der Nutzer den Datenbank-Server zwecks Speicherplatz und den zur Berechnung notwendigen Server zwecks Rechnergeschwindigkeit optimieren möchte, aber notwendig ist das nicht.

Anfangs wird davon ausgegangen, dass die historischen Daten in Gestalt einer Datei zur Verfügung gestellt werden. Der Grund dafür ist, dass ein Datenexport mit anschließendem Datenimport erfahrungsgemäß effizienter ist als eine direkte Datenverbindung etwa mittels OPC-HDA.

Das normale Lesen von Echtzeitdaten sollte aber mittels OPC-DA erfolgen. Zu diesem Zweck muss der OPC-Server spezifiziert werden (ein Beispiel ist opcda:///Softing.OPCToolboxDemo_ServerDA.1/{2E565242-B238-11D3-842D-0008C779D775}), und eine zwischengeschaltete Firewall muss entsprechend geöffnet werden. Auch muss der volle Name jeder Tag auf dem OPC-Server spezifiziert werden, um die Daten lesen zu können.

Dieses Kapitel beschreibt verschiedene praktische Aufgaben, die jeweils unabhängig voneinander durchzuführen sind:

1. Die Anlage definieren.Um ein Modell zu erschaffen, muss es eine Anlage geben bzw. diese muss definiert werden.
2. Vorbereitung der Daten.Die wichtigste Aufgabe bei diesen modernen Analyse-Methoden ist es, die zu analysierenden Daten vorzubereiten und zu beschreiben.
3. OPC-Verbindung.Um Daten in Echtzeit zu analysieren, müssen diese durch OPC mit einer Datenquelle verbunden sein.
4. Online stellen.Für Echtzeit-Analysen muss die Anwendung online gestellt werden.

Die Anlage ist die Einheit, die Ihren Datensatz definiert. Um ein Modell zu konstruieren, muss dafür als Erstes eine Anlage geschaffen werden.

Um diese Anlage benennen zu können, stehen Ihnen vier Textfelder zur Verfügung: Unternehmen, Einheit, Anlage und Equipment. Das sind lediglich Etiketten, mit deren Hilfe Sie mehrere Modelle in einer Oberfäche organisieren und Nutzerrechte verwalten können, um individuelle Modelle anzuschauen. Sie können auch ein Feld für Kommentare nutzen, um dort ausführlichere Erklärungen über Sinn und Zweck des jeweiligen Modells zu vermerken. Während einer Test- oder Tuningphase möchten Sie vielleicht mehrere Modelle konstruieren, um sie miteinander vergleichen zu können. Das Kommentarfeld ist auch nützlich, um im Auge zu behalten, welches Modell wie aufgebaut wurde.

Der kundenspezifische Code ist eine fünfstellige Zahl, die algorithmica technologies Ihnen zur Verfügung stellt, wenn Sie die Software-Lizenz für diese Anlage erworben haben; ihr Zweck ist es, jeden kundenspezifischen Schritt zu identifizieren, der für Sie geschrieben wurde und der in der Analyse-Software enthalten ist. Wenn Sie die Software testen, haben Sie diesen Code allerdings (noch) nicht, so dass Sie dieses Feld leer lassen können.

Die maximale Zeitverzögerung ist nur bei Nutzung des IHM (Intelligent Health Monitor) relevant. Die Auswahl unabhängiger Variablen, die der IHM verwendet, kann automatisch vorgenommen werden und er kann optional eine Zeitverzögerung beinhalten. Diese Option spezifiziert die maximale Zeitverzögerung in Form von so und so vielen Zeitstufen. Bitte beachten Sie die Beschreibung des IHM-Modells zwecks weiterer Details.

Die drei Felder "OPC-Name", "OPC-DA-Version" und "Subscriptions-Frequenz" sind für die OPC-Verbindung zu einer Datenquelle relevant. Relevant ist dies allerdings nur, wenn die Software in Echtzeit verwendet wird. Wenn Sie mehr Informationen benötigen, um das System online zu stellen, konsultieren Sie bitte den "How-to"-Abschnitt.

Die drei Zeitperioden, die Anfang und Ende der Referenz-Laufzeit und den Start der Betriebslaufzeit definieren, sind Konzepte, die vom APO benutzt werden, um den Erfolg der Vorschläge zu beurteilen. Die Referenz-Laufzeit ist der Zeitrahmen für die Daten, die gebraucht werden, um das Modell aufzubauen; und die Betriebslaufzeit beginnt, wenn die vom APO gemachten Vorschläge tatsächlich umgesetzt werden.

Beim maschinellen Lernen werden historische Daten analysiert, um gewisse Muster zu erkennen und um diese Muster in ein mathematisches Modell zu konvertieren. Damit das funktionieren kann, bedarf es nicht nur der historischen Daten, sondern auch einiger zusätzlicher Informationen über diese Daten. In diesem Abschnitt wird beschrieben, wie man das alles vorbereiten soll, damit sich dieser Lerneffekt ergibt.

Die Situation, die wir modellieren wollen, wird im Allgemeinen viele Eigenschaften haben, die von Sensoren gemessen werden und die wir für unser Modell verwenden können. Der erste Schritt wäre, die Datenquellen auszuwählen, die für die Analyse relevant erscheinen. Der zweite Schritt wäre, jede dieser Datenquellen mit relevanten Eigenschaften zu versehen – etwa die erlaubte Bandbreite der Messwerte. Der dritte und letzte Schritt wäre es, eine Tabelle mit historischen Messwerten für jede der Datenquellen zu erstellen.

Um Ihre Modell-basierte Lernerfahrung zu starten, wählen Sie die Tags aus, die für Ihr Modell berücksichtigt werden sollen. An Ihrer Anlage wurden zahlreiche Sensoren installiert, die eine Vielzahl von Eigenschaften messen. Viele davon werden für das Modellieren jedoch nicht relevant sein. Um Ihnen die Auswahl zu erleichtern, sollten Sie die folgenden Richtlinien beachten:

1. Tags, die die Anlagenfahrer regelmäßig modifizieren, sollten für das Modell berücksichtigt werden.
2. Tags, die wichtige Randbedingungen für den Prozess repräsentieren, sollten ebenfalls in das Modell einbezogen werden.
3. Tags, die für Sicherheit, Qualität, Effizienz und Geldwert relevant sind, sollten auch ins Modell einfließen.
4. Tags, die nur für das An- und Abfahren der Anlage oder für Notfälle verwendet werden, dürften für den normalen Betrieb irrelevant sein und müssen nicht berücksichtigt werden.
5. Tags, die für Condition Monitoring oder ähnliche Zwecke verwendet werden, dürften für Optimierungsmodelle auch nicht relevant sein.

Nach unserer Faustregel dürften bis zu 90% der Tags fürs Modellieren irrelevant sein. In den meisten Fällen erfordert ein Prozess-Modell nur ein paar hundert Tags, obwohl viele tausend Tags verfügbar sind.

Wenn Sie im Zweifel darüber sind, ob Sie ein Tag fürs Modellieren benötigen, berücksichtigen Sie es lieber. Zu viele Daten sind besser als zu wenige Daten. Allerdings: Je mehr Tags einbezogen werden, umso schwerfälliger und zeitaufwändiger wird das Modellieren und deshalb ist es in Ihrem Interesse, die Zahl der Tags relativ niedrig zu halten.

Wenn Sie die Tags ausgesucht haben, die Sie einbeziehen wollen, müssen Sie als nächstes einige Informationen über jeden Tag angeben. Die meisten davon sind relativ unkompliziert.

Es gibt zwei Arten, wie Sie diese Daten vorbereiten können:

1. Sie können die Taginformation direkt mittels der Oberfläche angeben oder editieren, indem Sie auf Anlage -> Tags editieren klicken. Dieses Formular erlaubt es Ihnen, neue Tags hinzuzufügen oder die Informationen jeden Tag zu editieren. Vergessen Sie nicht, Ihre Arbeit abzuspeichern! Das ist die bequemste Art, diese Informationen zu definieren. Beachten Sie bitte, dass die Tabelle die Funktion kopieren/einfügen unterstützt, aber seien Sie vorsichtig, wenn Sie kopieren/einfügen für große Informationsmengen verwenden, weil es dann Probleme mit der Ausrichtung geben kann.
2. Sie können eine Datei vorbereiten, in der die Informationen enthalten sind und die Sie dann in einem Zug in die Datenbank hochladen können. Diese Datei wird eine Textdatei sein, die 16 abgegrenzte TAB-Spalten enthält. Werden nur normale ASCII-Zeichen verwendet, kann man diese Datei als ASCII sichern, aber wenn non-ASCII-Zeichen nötig sind (etwa die deutschen Umlaute ä, ö, ü oder Symbole wie ° or µ), dann sollte man die Datei im UTF8 Format abspeichern. Diese Datei kann eine Kopfzeilen-Reihe mit Namen der jeweiligen Spalten enthalten.

Hier folgt nun eine kurze Erläuterung für jede Spalte und ob sie überhaupt nötig ist

table class="manualtable">SpaltennameErfordernisBeschreibungTagerforderlichDer eindeutige Identifikator für eine Zeitreihe. Das ist oft eine alphanumerische Zeichenkette, die vom Leitsystem oder Archivsystem verwendet wird, um den Tag zu kennzeichnen.PLS TagerforderlichDies ist oft dasselbe wie die Spalte "Tag" und stellt den eindeutigen Identifikator dar, der vom OPC-Server verwendet wird. algorithmica verwendet diese Spalte, um in der OPC-Datenquelle nach dem aktuellen Wert diesen Tag zu fragen. Deshalb muss es alle OPC-Informationen enthalten.NameempfohlenEine kurze Beschreibung, worum es bei diesem Tag geht.BeschreibungoptionalEine längere Beschreibung, worum es bei diesem Tag geht.EinheiterforderlichDie physikalischen Einheiten des Tags, z.B. "°C"MinimumerforderlichDer kleinste erlaubte Wert. Alle Werte, die niedriger als dieser sind, werden als physikalisch nicht möglich ignoriert. Für eine ausführlichere Diskussion zum Konzept von Minimum und Maximum siehe bitte den entsprechenden Abschnitt im Kapitel über Terminologie.MaximumerforderlichDer größte erlaubte Wert. Alle Werte größer als dieser werden als physikalisch nicht möglich ignoriert.KontrollierbarkeiterforderlichBestimmt, ob dieser Tag direkt vom Anlagenfahrer kontrolliert, überhaupt nicht kontrolliert oder nur indirekt kontrolliert werden kann.niedriges grünoptionalInnerhalb der Bandbreite von erlaubten Werten [minimum, maximum] können wir drei Gruppen von fest fixierten Alarmstufen (von innen nach außen) definieren: grün, gelb und orange. Bitte sehen Sie sich das Bild unten zum besseren Verständnis an.hohes grünoptionalniedriges gelboptionalhohes gelboptionalniedriges orangeoptionalhohes orangeoptionalDeltaerforderlichDie Messunsicherheit dieses Tags wird in denselben Einheiten dargestellt wie der Wert selbst. Wenn Sie dies beim ersten Mal einrichten, lesen Sie bitte die ausführlicheren Erläuterungen dieses Konzepts im Kapitel über Terminologie.GrenzwerterforderlichDiese Spalte ist entweder "TRUE" oder "FALSE" abhängig davon, ob dieser Tag durch IHM einen dynamischen Grenzwert erhält oder nicht.

Spalten, die nicht nötig sind, können leer bleiben. Vor allem die Optimierung durch APO berücksichtigt nicht die farbigen Begrenzungen. Ein Beispiel dafür befindet sich in den Installationsdateien.

Die Datendatei ist eine ASCII-Datei. Die erste Spalte ist ein Zeitstempel. Die weiteren Spalten enthalten Gleitkommazahlen, eine für jeden Tag des Modells. Die Datei ist Semikolon-begrenzt. Die Datei kann eine Kopfzeile mit den Spaltennamen enthalten. Es ist von essentieller Bedeutung, dass die Anordnung der Spalten in der Datendatei dieselbe ist wie die Reihenanordnung der Tagdatei.

Der Zeitstempel kann in zwei Formaten erscheinen:

1. Die übliche europäische Zeitdarstellung: dd.mm.yyyy hh:MM:ss.xxx
2. Das ISO 8601-Format: yyyy-mm-dd hh:MM:ss.xxx

In beiden Fällen ist der Gebrauch von Millisekunden ,.xxx‘ optional.

Hier ist eine beispielhafte Datei, die Semikolon-begrenzt ist.

Eine beispielhafte Datei ist in den Installationsdateien enthalten.

Um Ihr Modell in Echtzeit zu aktualisieren, benötigt das Modell Zugang zu den laufenden Daten mittels einer OPC Verbindung. Wir gehen davon aus, dass Ihr Leitsystem, Ihr Archivsystem oder eine andere Datenquelle Ihnen den Zugang zu einem OPC-Server ermöglicht. Algorithmica bietet Ihnen einen OPC Client an, damit Sie diese Daten lesen können.

Die grundlegenden Daten einer Anlage (klicken Sie auf Anlage -> editieren) beinhalten drei Felder, die für die OPC-Verbindung relevant sind:

1. OPC Name. Das ist der volle Name des OPC-Servers in Ihrem Netz. Ein Beispielname ist opcda:///Softing.OPCToolboxDemo_ServerDA.1/{2E565242-B238-11D3-842D-0008C779D775}.
2. OPC DA version. OPC beinhaltet mehrere Protokolltypen. Algorithmicas Anwendungen benutzen nur den DA-Typ, der den Datenzugang ermöglicht. Er wird dazu verwendet, den aktuellsten Wert eines einzelnen Tags zu erfragen. Dieses Protokoll ist verfügbar in den Versionen 2 oder 3. Bitte spezifizieren Sie, welche Version Ihr OPC-Server unterstützt.
3. Frequenz des Abonnement. Dies ist eine Sekundenzahl, die anzeigt, um wie viele Sekunden wir warten sollten, bevor wir einen neuen Wert erfragen. Bitte wählen Sie diese Zahl sorgfältig aus. Denn die Anwendung wird jeden Tag in dieser von Ihnen ausgewählten Häufigkeit erfragen, die erfragten Werte in der Datenbank abspeichern und die Modellberechnungen entsprechend durchführen. Eine niedrige Zahl könnte nicht nur die Rechnerkapazitäten Ihres Netzes überfordern, sondern wahrscheinlich auch keinen praktischen Nutzen erzielen, weil die menschliche Reaktionszeit nicht ausreichend ist, damit umzugehen. Wenn Sie allerdings eine zu große Zahl wählen, kann dies einen erheblichen Zeitverzug nach sich ziehen zwischen dem modellierten physikalischen Effekt und einer möglichen Reaktion darauf. Wenn Sie im Zweifel darüber sind, welche Sekundenzahl Sie eingehen sollen, empfehlen wir eine Zeit zwischen 300 und 900 Sekunden, also 5 bis 15 Minuten. Idealerweise sollte dieser Wert derselbe sein wie die Datenkadenz, die für den historischen Datensatz ausgewählt wurde.

Wenn Sie es noch nicht gemacht haben, geben Sie bitte diese Werte in die Oberfläche ein und speichern Sie sie. Wir gehen davon aus, dass Sie jeden Tag mit dem Feld "PLS Tag" ausgestattet haben, das ist der vollständige OPC Objektname dieses Tags. Die Kombination der Information des OPC-Servers und des OPC-Objektes (OPC item) eines jeden Elementes (tag) ermöglicht es der Anwendung, die Werte auszulesen.

Beachten Sie bitte, dass der Anwendungscomputer in der Lage sein muss, über das Netz Zugriff auf den OPC-Server zu erhalten. Das könnte es erfordern, an der Firewall Ihres Netzes Veränderungen vorzunehmen.

Um festzustellen, ob der OPC-Server erreicht werden kann und die Objekte sich korrekt lesen lassen, gehen Sie bitte zu Anlage -> OPC Diagnostik. Dieses Formular sollte Ihnen einige grundlegende Informationen über den OPC-Server und den aktuellen Wert eines jeden Tags anzeigen. Finden Sie ein Häkchen neben dem Serverstatus und neben jedem Tag, ist die Verbindung gut und die Objektnamen wurden alle gefunden. Befindet sich neben dem Serverstatus jedoch ein X, ist entweder der Servername falsch oder er kann über das Netz nicht erreicht werden. Konsultieren Sie in diesem Fall Ihren Netz-Administrator. Befindet sich ein Häkchen neben dem Serverstatus, aber ein X neben einigen Tags, so können die entsprechenden Objekte nicht auf dem OPC-Server gefunden werden. Bitte überprüfen Sie dann die Objektnamen und korrigieren Sie sie, indem Sie zu plant -> edit tags

wechseln. Auch wenn Sie alle diese Informationen erfolgreich abgeliefert bzw. deren Richtigkeit und Funktionsfähigkeit überprüft haben, wird die Echtzeit-Berechnung noch nicht sofort einsetzen. Denn: Sie können die Echtzeit-Berechnung jederzeit an- und ausschalten auch unabhängig von den für deren Verwendung notwendigen Informationen.

Um festzustellen, ob Ihre Anwendung aktuell in Echtzeit läuft oder nicht, gehen Sie bitte auf Anlage -> OPC an/aus. Der dort angezeigte Status wird Sie darüber informieren, ob der Prozess gegenwärtig läuft, wann die letzten Daten abgelesen wurden und auf welchen Rhythmus die Ablesung eingestellt ist.

Aufgrund von Netzverzögerungen und zeitweiligen Kommunikationsunterbrechungen im Computernetz gehen wir von folgender Definition aus, um zu entscheiden, ob die OPC-Datenverbindung online ist oder nicht: Wenn seit der letzten Datenablesung nicht mehr Zeit verstrichen ist als zwei Ableseintervalle, betrachten wir die Verbindung als online. Ist die letzte Ablesung hingegen länger her als zwei Ableseintervalle, so betrachten wir die Verbindung als offline.

Je nachdem, welcher Status vorliegt, können Sie mit Hilfe eines Buttons den Echtzeit-Prozess an- oder ausschalten. Haben Sie diesen Button angeklickt, sollten Sie ein wenig warten, bis die Verbindung hergestellt oder getrennt ist. Das kann – abhängig von Ihrem Netz – ein paar Minuten dauern. Wenn Sie diese Seite aktualisieren, können Sie anschließend den Verbindungsstatus erkennen.

Diese Seite bietet Ihnen auch die Option, die OPC Logdatei zu konsultieren. Dieser zeichnet wichtige Vorgänge Ihrer OPC-Verbindung auf. Es gibt aber in der Regel keinen Grund, diese Datei zu konsultieren, es sei denn, es besteht ein Problem mit der Verbindung.

Eine Anlage zu betreiben ist eine komplexe Aufgabe für die Anlagenfahrer, die alle paar Minuten detaillierte Entscheidungen zu treffen haben, wie sie die Sollwerte der Anlage einstellen müssen, um auf gewisse externe Faktoren zu reagieren. Die Anlage soll ja stets die Erwartungen erfüllen, welche die Kunden verlangen, und sie muss auf Wetterveränderungen ebenso reagieren wie auf die Qualität des Rohmaterials, um nur zwei Faktoren zu nennen.

Das gilt nicht nur aufgrund der unterschiedlichen Überzeugungen der verschiedenen Schichtteams. Es hat auch zu tun mit dem Überangebot an Informationen, da eine Anlage zigtausende von Sensoren haben kann, die menschliche Anlagenfahrer unmöglich alle im Auge behalten können. Deshalb muss jeder Anlagenfahrer aufgrund von Ausbildung und Erfahrung darüber entscheiden, welche wenigen Sensoren er für seine Entscheidung heranzieht. Diese wenigen Sensoren bieten ihm zwar zahlreiche Informationen, aber keineswegs alle.

Automatisierungen und Leitsysteme beschränken sich in der Regel auf lokal eng begrenzte Bereiche und sind eher darauf angelegt, von unten nach oben zu funktionieren. Sie funktionieren am besten bei in sich abgeschlossenen Systemen wie bei einer Turbine, einem Hochofen, einem Boiler u.ä. Eine übergreifende Methodologie für solche Systeme einzurichten ist schwierig und wird selten in Betracht gezogen. Es ist aber gerade beim Zusammenspiel zwischen den verschiedenen Komponenten einer Anlage, dass das Optimierungspotenzial noch weitgehend ungenutzt bleibt.

Aus diesem Grund sollten wir die ganze Anlage als ein einzelnes komplexes System betrachten. Sie ist ja ein physikalischer Apparat, der den Naturgesetzen gehorcht. Aus diesem Grund kann eine Anlage mit Hilfe von Differentialgleichungen beschrieben werden. Diese sind zwar sehr kompliziert, aber existent. Das Gleichungssystem, mit dessen Hilfe die Anlage beschrieben wird, nennen wird das Modell der Anlage. Weil dieses Modell die Anlage in ihren wichtigsten Eigenschaften repräsentiert, nennt man es oft den digitalen Zwilling der Anlage.

Es gibt zwei grundlegende Arten, ein solches Modell zu erstellen. Bei der ersten Methode geht man Stück-für-Stück vor und erstellt einfache Modelle von Pumpen, Kompressoren und anderen Systemen und fügt diese Modelle zu einem größeren Modell zusammen. Diesen Ansatz nennen wir den First-Principles-Approach. Es erfordert allerdings viel Zeit und Anstrengung seitens der Fachingenieure, um dieses Modell anfänglich zu erstellen und dann über die ganze Laufzeit der Anlage aktuell zu halten.

Die zweite Möglichkeit basiert auf der Basis der vom Leitsystem erhobenen Prozessdaten, die genutzt werden, um aus ihnen ein empirisch-basiertes Modell zu erstellen. Diese Methode kann automatisch durch einen Computer erfolgen, und zwar ohne auf menschliche Expertise angewiesen zu sein. Dieses Modell kann schnell erstellt werden und ist zudem in der Lage, sich selbst jederzeit auf den neuesten Stand zu bringen. Diesen Ansatz nennen wir maschinelles Lernen

Zweck des maschinellen Lernens ist es, von einer Anlage eine mathematische Darstellung zu entwickeln, bei der die Messdaten des Prozessleitsystems genutzt werden. Diese Darstellung muss notwendigerweise den extrem wichtigen Zeitfaktor berücksichtigen, denn die Anlage enthält komplexe Ursache-Wirkungs-Verhältnisse, die von einem Modell dargestellt werden müssen. Und diese vollziehen sich über unterschiedliche Zeitskalen. Das heißt, dass die Zeit zwischen Ursache und Wirkung manchmal Sekunden dauert, manchmal Stunden und manchmal Tage. Die Modellierungseffekte der verschiedenen Zeitskalen stellen eine komplizierte Eigenschaft der Daten dar.

Das Modell sollte so gestaltet sein, dass wir den Zustand der Anlage zu einem zukünftigen Zeitpunkt aufgrund des Zustandes der Anlage in der Vergangenheit und in der Gegenwart berechnen können. Diese Art von Modell kann dann zyklisch betrieben werden, so dass wir den Zustand für jeden Zeitpunkt in der Zukunft berechnen können.

Der Zustand der Anlage besteht aus den gesammelten Daten der Tags, die für den Betrieb der Anlage wichtig sind. Typischerweise gibt es mehrere tausend Tags in und an der Anlage, die wichtig sind. Diese Tags fallen in drei Kategorien. Da sind zum einen die Randbedingungen. Das sind die Tags, über welche die Anlagenfahrer keine Kontrolle haben. Beispiele dafür sind das Wetter oder die Qualität der Rohmaterialien. Zum andern haben wir die Sollwerte. Das sind die Tags, die von den Anlagenfahrer im Leitsystem direkt eingestellt werden können und die die Funktionsfähigkeit der Anlage bestimmen. Drittens haben wir die Istwerte. Das sind alle anderen Messungen, die von den Bedienern beeinflusst werden können (da sie keine Randbedingungen sind), wenngleich nicht direkt (es sind keine Sollwerte), da sie sich aufgrund der Interdependenz der Anlage selbst verändern, je nachdem, wie sich die äußeren Randbedingungen und Sollwerte mit der Zeit verändern. Ein typisches Beispiel hierfür ist eine Schwingungsmessung. – Alle diese Daten werden vom maschinellen Lernen dazu verwendet, vom gesamten Anlagenprozess ein Modell zu erstellen.

Ist das Modell erst einmal erstellt, wollen wir es freilich dazu benutzen, die Leistung der Anlage zu optimieren. Hierfür benötigen wir eine genaue Definition von "Leistung". Das könnte irgendein numerisches Konzept sein. Manchmal ist es eine physikalische Größe wie die Abgabe von Schadstoffen (z.B. NOX, SOX) oder eine Ingenieursquantität wie der Gesamtwirkungsgrad der ganzen Anlage, oder eine geschäftliche Quantität wie die Wirtschaftlichkeit. Wir können diese Leistungswerte auf der Grundlage des Zustands der Anlage für jeden möglichen Zeitpunkt berechnen.

Nun haben wir eine genau definierte Optimierungsaufgabe: Finde diejenigen Sollwerte heraus, die eine maximale Leistung ermöglichen, wobei zu berücksichtigen ist, dass die Randbedingungen so sind, wie sie sind. Zusätzlich zu den natürlichen Randbedingungen (wir können das Wetter nicht ändern) könnte es noch weitere Randbedingungen geben, die etwa mit Sicherheitsvorschriften oder anderen Prozessbegrenzungen zu tun haben.

Das ist ein komplexes, in höchstem Maße nicht-lineares, multidimensionales und vielfältigen Bedingungen unterworfenes Optimierungsproblem, das wir mit Hilfe des Simulated Annealing lösen. Das Wesen dieser Aufgabe erfordert eine sogenannte heuristische Optimierungsmethode, da eine exakte Lösung der Aufgabe viel zu komplex wäre. Das sogenannte Simulated Annealing enthält einige einzigartige Eigenschaften. Es konvergiert zum globalen Optimum und kann auch in begrenzter Zeit eine sinnvolle Lösung anbieten.

Bei der realpraktischen Vorgehensweise messen wir in regelmäßigen Abständen (etwa einmal pro Minute) den Zustand der Anlage, indem wir die Messwerte vom OPC-Server abrufen, dann das Modell entsprechend aktualisieren, den optimalen Messwert herausfinden und schließlich einen Bericht darüber erstellen, welche Sollwerte neu eingestellt werden müssen. Das kann als offene Schleife (open-loop) angeboten werden, damit die Anlagenfahrer die empfohlene Aktion von Hand eingeben, oder besser noch: als geschlossene Schleife (closed-loop), wobei die Justierung direkt vom Leitsystem vorgenommen wird. Sobald eine Veränderung einsetzt, etwa das Wetter, werden die notwendigen Justierungen berechnet und entsprechend berichtigt. Auf diese Weise kann die Anlage jederzeit mit den für eine optimale Leistung notwendigen Sollwerten gefahren werden.

Wenn der Algorithmus des maschinellen Lernens das Modell erlernt, entnimmt er die historischen Daten Punkt für Punkt aus der Datenbank. Jeder "Punkt" wird zuerst korrigiert und anschließend validiert. Nur validierte Punkte werden vom maschinellen Lernen erfasst, während invalide Punkte ignoriert werden.

Nehmen Sie beispielsweise ein Ventil bzw. der Tag, welcher misst, wie weit das Ventil offen steht. Ein ganz geöffnetes Ventil verbucht eine 100-prozentige Öffnung, und ein ganz geschlossenes Ventil verbucht eine 0-prozentige Öffnung. Demzufolge betragen die Minimal- und Maximalwerte für dieses Tag 0 und 100. Allerdings gibt uns die Datenbank – aus verschiedenen Gründen – Ergebniswerte, die zuweilen etwas unter 0 oder etwas über 100 liegen. Das sind keineswegs Messfehler oder Fehlpunkte. Wir sollten diese Daten darum nicht aussortieren, sondern korrigieren. Das heißt: Ein Messwert unter 0 ist eigentlich 0, und ein Messwert über 100 ist tatsächlich nur 100. Das wissen wir, weil wir die Funktionsweise des Ventils kennen, weshalb wir solche Werte korrigieren. Korrekturregeln sind Regeln, die den Zahlenwert eines Tags zu einem festen Wert korrigieren, sofern der aufgezeichnete Wert unter oder über einem bestimmten Schwellenwert liegt. Standardmäßig sind keine Korrekturen an den Daten programmiert. Sind Korrekturen also nötig, müssen sie manuell vorgenommen werden.

Der Algorithmus des maschinellen Lernens sollte nur solche Betriebsbedingungen lernen, die vernünftig sind, und zwar in dem Sinn, dass sie dem Modell gestatten, die Einstellungen so zu programmieren, dass diese Bedingungen der Anlage auch zu einem zukünftigen Zeitpunkt erreicht werden. Jeder Ausnahmezustand, in der sich die Anlage zu gewissen Zeiten befunden haben mag und den wir nicht für wünschenswert halten, sollte darum vom maschinellen Lernen ausgespart bleiben. Auch Zustände, bei denen die Anlage offline ist, nicht produktiv ist, gewartet wird oder bei denen andere abnormale Bedingungen vorliegen, sollten als nicht valide markiert werden. Eine Validierungsregel erfordert es, dass ein bestimmter Tag sich innerhalb zu spezifizierender Grenzwerte befinden muss. Standardmäßig muss jeder Tag einen Wert zwischen dem minimalen und maximalen Wert ergeben, um valide zu sein.

Zusätzlich zu den standardmäßigen Validierungsregeln können wir von Hand noch weitere hinzufügen. Diese zusätzlichen Regeln müssen nicht immer gelten, und wir können spezifizieren, dass eine Regel nur dann anzuwenden ist, wenn ein Tag sich oberhalb oder unterhalb eines bestimmten Wertes befindet. Diese Geltungsfunktion erlaubt es Ihnen, auch komplexe Regeln einzugeben, die jeweils unter bestimmten Bedingungen gelten. Zum Beispiel könnten Sie eine Vorgabe machen, nach der ein Prozess bei Volllast eine hohe Temperatur haben und bei Halblast nur eine niedrige Temperatur haben soll.

Zweck der Prozessoptimierung ist es, Sie darüber in Kenntnis zu setzen, welche Sollwerte Sie modifizieren müssen, damit Ihre Anlage den besten Betriebspunkt erreicht. Um das zu ermöglichen, müssen Sie definieren, was Sie mit besten meinen. Jede in Zahlen ausgedrückte Quantität kann dafür in Frage kommen, z.B. Effizienz, Ertrag, Gewinn usw.

APO wird dann die Zielquantität jeweils maximieren, weshalb es wichtig ist, wie Sie Ihr Ziel formulieren. Wenn Sie allerdings möchten, dass APO eine bestimmte Quantität minimieren soll, z.B. Kosten, brauchen Sie nur ein Minus-Zeichen vor die Zahl setzen. In dem Falle wandelt sich die Maximierung in eine Minimierung um.

Alle Informationen, die benötigt werden, um die Zielfunktion zu evaluieren, müssen auf der Datenbank abrufbar ein. Nehmen wir als Beispiel den Umsatz durch den Verkauf von Strom. Auf der einen Seite benötigen wir einen Tag, das die produzierte Strommenge bemisst. Das dürfte in der Regel ohnehin Teil des Prozess-Modells sein. Wir benötigen aber auch den finanziellen Wert einer verkauften Stromeinheit. Dieser Wert ist in der Regel kein Teil des Prozess-Modells. Um ihn aber als Teil der Zielfunktion einzubeziehen, müssen Sie diesen Tag auch in die Datenbank einbeziehen. Beachten Sie, dass finanzielle Werteinheiten auch Tags (und nicht Konstanten) sind, da Preise/Kosten sich im Laufe der Zeit verändern.

Die Zielfunktion von APO ist die Summe von so vielen Summanden wie Sie sie haben wollen, wobei jeder Summand drei Bestandteile enthält, die miteinander multipliziert werden.

1. Der Faktor ist eine Zahl, mit der Einheiten umgewandelt werden oder mit der ein statischer Multiplikator aufgenommen wird, der aus chemischen oder sonstigen Gründen nötig ist. Er bietet auch die Möglichkeit, ein Minuszeichen einzufügen, so dass dieser Wert von der Zielfunktion abgezogen statt hinzuaddiert wird.
2. Der erste Tag ist der Haupttag dieses Summanden.
3. Der zweite Tag ist optional. Er wird vor allem für eine Zielfunktion gebraucht, die den Gewinn berechnet, so dass wir bei jedem Summanden die Menge mit dem Preis multiplizieren müssen.
4. Es ist sehr wichtig, dass jeder Summand in den gleichen physikalischen Einheiten evaluiert wird, so dass die Addition der Summanden zu einer Summe einen aussagefähigen Sinn ergibt. In der Oberfläche können Sie auch einen Kommentar für jeden Summand hinterlegen, um Ihre Eingabe zu dokumentieren.

   Das Formular erlaubt es Ihnen, eine Zeitspanne zu spezifizieren, über die hinweg die Summanden der Zielfunktion evaluiert und als Gesamtergebnis miteinander addiert werden sollen. Das dient nur dem Überprüfen und wird das Modell in keinster Weise beeinflussen. Bitte nutzen Sie dieses Möglichkeit, um die Plausibilität der Werte zu überprüfen. In der Praxis stellen wir oft fest, dass Tags in anderen Einheiten aufgezeichnet werden, als man eigentlich erwarten würde (beispielsweise Tonnen statt kg), und das führt dann zu großen Abweichungen in den numerischen Werten. Zusätzlich dazu wird zuweilen ein korrektiver Faktor für die molare Masse einer Substanz nötig sein.

   Jedes in der Zielfunktion verwendeter Tag sollte idealerweise semi-kontrollierbar sein. Ist ein Tag kontrollierbar, kann der Optimierer es einfach auf seinen maximalen Wert einstellen. Ist ein Tag gar nicht kontrollierbar, kann man hinsichtlich dieses Zielaspektes ohnehin nichts machen. Diese Empfehlung ist allerdings nur eine Richtlinie und keine strenge Vorschrift. Wenn es – zur korrekten Gewinnberechnung – beispielsweise notwendig ist, einige unkontrollierbare Tags einzubeziehen, dann müssen diese eben auch mit einbezogen werden.

   Die Zielfunktion ist das Kernstück von APO und wird Sie bei jeder Entscheidung leiten. Darum muss sie mit großer Sorgfalt spezifiziert werden. Entspricht diese Funktion Ihren eigentlichen Geschäftszielen, wird APO Sie genau dorthin bringen.

Das Modell zu trainieren ist ein automatischer Prozess. Sie können das Training des Modells auslösen entweder über den APO Wizard oder über das APO-Menü, indem Sie die Modell-Option selektieren.

Das Formular wird Sie dazu auffordern, diejenige Methode auszuwählen, nach der Sie vorgehen wollen. In beiden Fällen wird das aktuelle Modell gelöscht und ein neues auf der Basis der historischen Daten erstellt. Die Methode nur modellieren wird genau das tun, aber nicht mehr. Bei dieser Vorgehensweise bleiben alle bereits gemachten Vorschläge und alle per Hand eingegebenen Reaktionen der Anlagenfahrer erhalten. Diese Option ist dann für Sie die richtige, wenn APO bereits einige Zeit gelaufen ist und Sie das Modell lediglich aktualisieren wollen, wobei Sie die in der Vergangenheit vorgeschlagenen und umgesetzten Empfehlungsanweisungen beibehalten möchten. Die Methode Neuberechnung wird hingegen nicht nur das alte Modell, sondern auch alle bislang gemachten Empfehlungen sowie per Hand eingegebenen Veränderungen löschen. Es wird dann alles neu erzeugen, nachdem das neue Modell erstellt ist. Das ist die geeignete Option, wenn Sie APO zum ersten Mal einsetzen oder wenn Sie Ihr Modell feinjustieren wollen.

Die Zeitbegrenzung kann verwendet werden, um die Neuberechnung aller historischen Empfehlungen zu beschleunigen, indem Sie nur eine Zeitspanne wählen zwischen dem Anfang der historischen Daten bis hin zu einem einzugebenden Zeitpunkt. Wir empfehlen diese Option allerdings nicht, sondern schlagen vor, das Modell aufgrund aller akkumulierten Daten zu erstellen.

Bitte beachten Sie, dass das Training eine beträchtliche Zeit in Anspruch nimmt. Die Zeit ist direkt und linear proportional zu der Anzahl von Datenpunkten der Datenbank. Der Prozess wird dominiert von der Lese- bzw. Schreibgeschwindigkeit der Datenbankvorgänge und somit von der Geschwindigkeit der Festplatte. Seien Sie geduldig.

Am Ende des Trainings, wird das Modell auf der Datenbank abgespeichert. Haben Sie Neuberechnung ausgewählt, werden Sie nun in der Lage sein, sich die neu berechneten Empfehlungen anzusehen und die Qualität des Modells zu bewerten. Wir empfehlen Ihnen nachdrücklich, dass Sie das auch wirklich tun.

Es gibt drei Schritte, um die Qualität eines trainierten APO-Modells zu bewerten:

1. Plausibilität prüfen
2. Den Modellbericht lesen
3. Das Modell feinjustieren

Die Modell-Plausibilität schaut sich die historischen Daten im Verhältnis zu den Spezifikationen an, die für jeder Tag gemacht wurden, und versucht dann zu prüfen, ob diese Spezifikationen Sinn machen. Das Erste, was überprüft wird, ist dieMessspanne eines jeden Tags. Aufgrund der historischen Daten wird berechnet, wie viele Punkte innerhalb und wie viele außerhalb der Spanne zwischen Minimum und Maximum liegen. Diese Spanne hat den Zweck, alle normalen und angemessenen Werte zu markieren. Aus diesem Grund sollte nur eine kleine Minderheit von historischen Beobachtungen außerhalb dieser Spanne liegen. Allerdings stellen wir in der Praxis häufig fest, dass manche Tags zahlreiche Punkte aufweisen, die außerhalb dieser Spanne liegen.

Die minimalen und maximalen Werte sind deshalb wichtig, weil jeder Punkt außerhalb der erlaubten Spannbreite von der Modellierung ausgeschlossen bleibt. Im Allgemeinen müssen diese Werte angepasst werden, bevor genügend valide Punkte verfügbar sind, um ein sinnvolles Prozessmodell zu trainieren. Im Plausibilitätsformular werden Sie nicht nur die Prozentzahlen der historischen Punkte ablesen können, die außerhalb der Spannbreite liegen, sondern auch die jeweils kleinsten und größten Werte für den jeweiligen Tag. Diese Informationen sollen Ihnen helfen, die zweckdienlichen Korrekturen vorzunehmen.

Die zweite Überprüfung betrifft die Messunsicherheiten der unkontrollierbaren Tags. Das Modell gruppiert die vorhandenen historischen Daten auf der Basis der Messwerte und Unsicherheiten der unkontrollierbaren Tags in sogenannte Cluster. Für alle so gruppierten Cluster wird ein separates Optimierungsmodell erstellt. Das ist notwendig, damit keine operationalen Bedingungen vorgeschlagen werden, die unrealistisch und unerreichbar sind, weil eines oder mehrere der unkontrollierbaren Tags verschieden sind. Weil sie unkontrollierbar sind, stellen sie für den Prozess Randbedingungen dar. Je mehr Tags als unkontrollierbar markiert werden und je kleiner deren Unsicherheit ist, umso größere Restriktionen bedeuten sie für das Modell. Aber ein restriktives Modell wird weniger optimieren können.

Bei dieser Prüfung sollten Sie die unkontrollierbaren Tags überprüfen. Einige von ihnen könnten aus dem Modell entfernt werden, sofern sie nicht wirkliche Randbedingungen darstellen. Schauen Sie sich bitte die Unsicherheiten dieser Tags an. Das Plausibilitätsformular wird Ihnen sagen, wie viele Cluster auf der Basis des jeweiligen Tags gebildet wurden. Wenn Sie darüber im Zweifel sind, beginnen Sie lieber mit höheren Unsicherheitswerten, um ein vernünftiges Modell zu gewinnen. Diese Werte können später immer noch gesenkt werden, um das Modell restriktiver zu gestalten.

Der dritte Plausibilitätscheck betrifft die Validität der historischen Daten. Nur valide Punkte werden für das Training verwendet. Ein Punkt ist valide, wenn alle kontrollierbaren Tags innerhalb ihrer (minimalen und maximalen) Bandbreite liegen und wenn alle Validitätsregeln beachtet wurden. Vielleicht haben Sie auch eine Anzahl von maßgeschneiderten Bedingungen, die erfüllt werden müssen. Eine übliche maßgeschneiderte Bedingung ist, der Anlage einen stabilen Zustand vorzuschreiben, um die Validität zu erreichen. Das würde alle transienten Zustände vom Lernprozess ausschließen. Haben wir zu wenige valide Punkte in den historischen Daten, kann es sein, dass es zu wenige Daten gibt, von denen das Modell lernen kann. Weil der Betrieb einer Anlage im Allgemeinen einen Normalzustand erfordert, folgt daraus, dass, wenn es nur wenige valide Punkte gibt, einige Einstellungen korrigiert werden müssen.

Wenn diese drei Prüfungen zur Zufriedenheit durchgeführt wurden, sollte das maschinelle Lernen in der Lage sein, ein vernünftiges Prozessmodell zu trainieren. Bitte trainieren Sie nun das Modell und schauen Sie sich dann den Modellbericht an.

Nachdem Sie das Modell trainiert haben, können Sie APO den Modellbericht generieren lassen. Entweder stellt dies den letzten Schritt im APO-Wizard dar oder Sie können diesen Bericht erhalten, indem Sie im APO-Menü die Option Bericht auswählen. Der Berichtgenerator erfordert es, dass man einen Zeitraum für den Bericht wählt und auch die Granularität des Berichts. Standardmäßig wird die gesamte Zeitperiode ausgewählt, für die es in der Datenbank Daten gibt. Der Bericht wird für diese Zeitspanne erstellt; und die Statistiken werden erhoben entsprechend der als Granularität angegebenen Häufigkeitsabständen.

Der Bericht selbst enthält eine Erläuterung seiner Datentabellen und Grafiken. Er befasst sich vor allem mit der Analyse von Optimierungspotenzialen, wie sie ihm von APO bereitgestellt werden. Jede Empfehlung bietet eine Gelegenheit, die Leistung der Anlage zu verbessern. Wird diese Empfehlung umgesetzt, wird aus diesem Potential ein tatsächlicher Gewinn. Diese Potentiale und tatsächlichen Gewinne werden im Bericht zusammengefasst. Bitte überprüfen Sie aber auch, ob die Dimension der Verbesserung tatsächlich realistisch ist. Ist die Verbesserung zu groß, könnte es sein, dass das Modell noch nicht alle Restriktionen oder Randbedingungen kennt, denen der Verarbeitungsprozess unterliegt. Sind die Verbesserung zu gering, kann es sein, dass die Restriktionen, denen das Modell unterliegt, strenger sind als in Wirklichkeit. Eine detailliertere Analyse der eigentlichen Empfehlungen folgt im Laufe der Feinjustierung, aber schon jetzt sollte eine Bewertung der groben Verbesserungswerte vorgenommen werden, die der Bericht bereitstellt.

Der Bericht wird auch eine Liste der gebräuchlichsten Empfehlungen enthalten. Eine einzelne Empfehlung kann mehrere Zeilen von Veränderungen enthalten. Diese Veränderungen werden hier als ermittelter Durchschnitt aufgeführt und danach sortiert, wie oft sie auftreten. Sie werden sehen, wie oft die Tags verändert werden und um welchen Durchschnittswert sie verändert wurden. Dieser Durchschnittswert wird mit einer Standardabweichung zur Verfügung gestellt, so dass Sie daraus ersehen können, wie viel Abweichung von diesem Durchschnitt vorkommt. Tags, die in fast jeder Empfehlung erscheinen, haben wahrscheinlich einen Unsicherheitsfaktor, der zu klein ist und deshalb nahezu jeden Wert sub-optimal macht. Tags, die in so gut wie keiner Empfehlung erscheinen, dürften keinen großen Einfluss auf den Betriebsprozess haben und sollten vielleicht sogar ignoriert werden. Auf der anderen Seite könnten sie eine Unsicherheit haben, die zu groß ist, so dass ihr wahrer Einfluss unerkannt bleibt. Sind die Veränderungen oftmals sehr groß, so gibt es vielleicht begrenzende Faktoren, die man dem Modell aufnötigen soll.

Wenn Sie Ihr Modell erstellt haben und es sich in einem guten Zustand befindet – nämlich auf der Basis der Einstellungen der Tags, der Plausibilitätsüberprüfungen und des Modellberichts – so ist es Zeit, die Feinjustierung durchzuführen. Das ist ein Prozess, der einige Zeit in Anspruch nehmen kann und bei dem es darum geht, sich viele einzelne Empfehlungen genauer anzuschauen; aber es ist dieser Prozess, der Sie in die Lage versetzt und Ihnen das Vertrauen geben wird, das Modell in der Praxis tatsächlich einzusetzen.

Wählen Sie bitte aus dem APO-Menü die Option für die Feinjustierung (fine tuning). Um die Feinjustierung für die Anlage zu beginnen, klicken Sie bitte auf den Knopf Initialisieren. Nun werden Ihnen 100 zufällig ausgewählte historische Empfehlungen präsentiert, die Sie überprüfen können. Sie sind im Überblick der Feinjustierung gelistet. Sie können diese Liste weiter reduzieren, indem Sie im Formular den Knopf Filteranklicken. Sie können die Empfehlungen filtern, indem Sie entweder einen Empfehlungs-Zeitraum auswählen oder indem Sie prüfen, ob eine Empfehlung als "ok" markiert ist oder als "nicht ok". Zu Anfang sind alle Empfehlungen als "nicht ok" markiert.

Nun sollten Sie sich jede der Empfehlungen sorgfältig anschauen. Beachten Sie, dass jede Empfehlung zu einer besonderen Zeit, die in der Vergangenheit liegt, gemacht wurde, und zwar in Reaktion auf einen ganz bestimmten Zustand der Anlage und seiner Umgebung. Wenn Sie diese Empfehlung nun überprüfen, sollten Sie sich diese besondere Situation in Erinnerung rufen. Die Fragen, die Sie sich hinsichtlich jeder Empfehlung stellen sollten, sind diese:

1. Hätten alle die hier aufgeführten Empfehlungen tatsächlich umgesetzt werden können?
2. Welche Einstellungen im Modell müssen modifiziert werden, um unrealistische Empfehlungen zu verhindern?

Eine Empfehlung ist selbsterklärend. Beachten Sie, dass jede Empfehlung immer nur etwas empfiehlt, was die Anlage in einen Zustand versetzt, den sie in der uns bekannten Historie zumindest einmal durchlaufen hat. Diese frühere Erfahrung ereignete sich zu einer Zeit, die in der Tabelle als "Vorige Erscheinung" markiert ist. Wenn Sie auf diesen Zeitstempel klicken, erscheint ein Vergleich mit Einzelheiten zwischen dem derzeitigen Zeitpunkt und jenem historischen Zeitpunkt, so dass Sie beide Zustände miteinander vergleichen können. Das ist nützlich, um zu verstehen, welchen vergleichbaren Zustand das Modell für sich heranzieht, um vielleicht die eine oder andere Veränderung am Modell vorzunehmen, oder um einfach zu verstehen, auf welcher Grundlage die Empfehlung basiert.

Wenn Sie alle Empfehlungen durchgegangen sind und eine Reihe von Veränderungen gesammelt haben, die Sie am Modell vornehmen möchten, führen Sie diese Veränderungen durch und trainieren Sie das Modell dann noch einmal unter den nun geänderten Bedingungen. Das Modell wird nun alle Empfehlungen neu berechnen. Gehen Sie dann noch einmal zurück zum Überblick der Feinjustierung und klicken Sie auf den Knopf Aktualisieren. Hier können Sie nun die angepassten Versionen der ausgewählten Empfehlungen nachlesen, die Sie sich zuvor angeschaut hatten.

Schauen Sie sich alle diese Empfehlungen also ein zweites Mal an. Diejenigen, die zuvor schon mit ok gekennzeichnet waren, werden auch jetzt noch ok sein und müssen nicht überprüft werden. Diejenigen, die zuvor nicht ok waren, sollten jetzt verbessert sein. Sind Sie Ihrer Meinung nach jetzt okay, markieren Sie sie auch als ok. Diese Vorgehensweise sollten Sie solange wiederholen, bis alle Empfehlungen als ok markiert sind. An diesem Punkt ist das Modell ausreichend angepasst da eine signifikante und repräsentative Menge an Empfehlungen als gut und praktikabel befunden wurden.

Sie können Ihre zu Ende gebrachte Arbeit jederzeit überprüfen, indem Sie auf Überblick klicken, damit Sie dort schnell nachzählen können, wie viele der Empfehlungen nach jedem Durchlauf als ok gekennzeichnet sind. Sie können auch auf den Bericht klicken, um einen ausführlichen und längeren Bericht über die Entwicklung einer jeden Empfehlung und all Ihrer Kommentare zu erhalten.

Am Ende der Feinjustierung kann das Modell für den realen Anlagenbetrieb verwendet werden. Wir empfehlen, dass Sie dieses Modell zunächst ein paar Tage lang als eine Art Probelauf betreiben, für den Fall, dass irgend ein Wesensmerkmal sich erst im laufenden Betrieb zeigt.

Der Intelligent Health Monitor (IHM) macht die Zustandsüberwachung smart, indem er diese ins Zeitalter des maschinellen Lernens versetzt. Eine normale Zustandsüberwachung (condition monitoring) leidet darunter, dass immer wieder ein falscher Alarm ausgelöst wird, dass trotz schlechten Zustands gar kein Alarm ausgelöst wird und dass ein solches Monitoring erhebliche menschliche Expertise erfordert, um eingerichtet und aufrecht erhalten zu werden. Der IHM löst alle drei Probleme, indem er effektive, effiziente und präzise Methoden einsetzt, um den Gesundheitszustand der Geräte zu überprüfen. Das tut er, indem er die Definition des Gesundheitszustandes verändert: nämlich von Grenzwerten, die von Menschen für jeden Tag gesondert spezifiziert werden, hin zu einer ganzheitlichen Definition, die auf der in der Vergangenheit liegenden Leistung der Maschinerie basiert.

Ungesunde Zustände werden aufgespürt, weil beim ganzheitlichen Modellansatz die verschiedensten Messwerte einbezogen werden. Beispielsweise bieten Temperatur, Druck und Rotationsrate wertvolle Hinweise darüber, ob eine Vibration akzeptabel ist oder nicht. Durch diesen Ansatz werden falsche Alarm-Auslösungen verhindert. Weil diese Methode auf historischen Daten basiert, müssen Wartungsingenieure Alarmgrenzen nicht länger spezifizieren, warten und dokumentieren.

Als Folge der zunehmenden Verlässlichkeit hinsichtlich der Erkennung des Gesundheitszustands steigert sich die Verfügbarkeit der Maschinen und der ganzen Anlage. Mit der gesteigerten Verfügbarkeit verbessert sich auch die tatsächliche Produktionskapazität der Anlage. Weil es nun möglich wird, die maschinelle Ausrüstung proaktiv zu warten, kann die Wartung zunehmend vorausgeplant und darum auch kostengünstiger werden. Weil die maschinelle Ausrüstung seltener ausfällt, sondern proaktiv gewartet und repariert werden kann, werden Kollateralschäden vermieden und Wartungskosten erheblich gesenkt.

Wenn wir in einer Industrieanlage technische Maschinen betreiben, sind wir ständig darum besorgt, ob diese Maschinen sich jederzeit in gutem Betriebszustand befinden. Tätigkeiten, die damit zu tun haben, diesen gesunden Betriebszustand zu ermitteln, fassen wir unter dem Begriff Condition Monitoring zusammen. Das wird im Allgemeinen dadurch erzielt, dass wir an den Maschinen Sensoren anbringen, die Quantitäten wie Vibration, Temperatur, Druck, Durchfluss usw. messen. Diese Messwerte werden an das Leitsystem übertragen und gewöhnlich in einem Archivsystem gespeichert.

Im Zusammenspiel zwischen dem Leitsystem und dem Archivsystem werden die laufend eingehenden Daten analysiert, um den Zustand der Maschinerie zu bestimmen. Zu diesem Zweck definiert man in der Regel eine Ober- und Untergrenze für jeden Tag zur Auslösung eines Alarms. Bewegen sich die Messwerte jenseits der Ober- bzw. Untergrenzen, wird ein Alarm ausgelöst.

Wird ein Alarm ausgelöst, schaut sich ein Wartungsingenieur die Daten an und entscheidet dann, ob und was in diesem Fall zu tun ist. Entscheidet sich der Ingenieur dafür, nichts zu tun, handelt es sich gewöhnlich um einen falschen Alarm. Befindet sich die Maschinerie allerdings in keinem guten Zustand, ohne dass ein Alarm ausgelöst wird, sprechen wir von einem fehlenden Alarm. Beide Fälle sind problematisch. Der falsche Alarm ist unerwünscht, weil er Zeit und Ressourcen verschwendet. Der fehlende Alarm ist gefährlich, weil er wahrscheinlich zu einem ungeplanten Ausfall führt, der Kollateralschäden und Produktionsverlust nach sich zieht.

Der Grund für beide, den falschen Alarm und den fehlenden Alarm, liegt gewöhnlich in der zu simplen Art der Analyse: Die statische Beschaffenheit der Ober- und Untergrenzen ist nicht in der Lage, die Komplexität der verschiedenen Betriebsbedingungen industrieller Maschinen zu erfassen. Hinzu kommt, dass wenn jeder Messwert individuell analysiert wird, dies einen großen Nachteil bedeutet. Alle Messungen, die an einer einzelnen Maschine vorgenommen werden, sind naturgemäß irgendwie miteinander verbunden. Wenn diese natürliche Verbindung ignoriert wird, verzichtet die Analyse auf eine wichtige Informationsquelle.

Diesen Mangel kann man teilweise abstellen durch das, was man Event Framing nennt. Dabei werden bestimmte Betriebsbedingungen einer Maschine als zu einer Gruppe gehörig definiert, und man bestimmt dann die Ober- und Untergrenze für diese Gruppe. Beispielsweise kann man die Daten einer Turbine entsprechend in Volllast, Teillast und Leerlauf aufteilen, indem man eine Zustandsbedingung der Rotationsrate definiert. Obwohl das schon eine gewisse Verbesserung bedeutet, wird dadurch die handwerkliche Arbeit vermehrt, die nötig ist, um diese Art von Analyse einzurichten und zu erhalten. Bei Werksanlagen mit zehntausenden von Messwerten wird das allerdings schnell unermesslich und fehleranfällig.

Wir können resümieren, dass normales Condition Monitoring den Gesundheitszustand eines Maschinenteils auf der Basis von Messungen definiert, für die – nach dem menschlichem Ermessen von Ingenieursfachleuten – gewisse Grenzwerte gesetzt werden. Doch diese Definition für den Gesundheitszustand ist in seiner Wirksamkeit begrenzt und erfordert erheblichen menschlichen Aufwand, und zwar nicht nur anfänglich, sondern fortlaufend.

Der Intelligent Health Monitor (IHM) konstruiert ein Modell des maschinellen Lernens für eine Zeitreihe als Funktion von mehreren solchen Zeitreihen einer ganzen Anlage oder einer Maschine. Wenn die zugrunde liegende Physik und Chemie des industriellen Prozesses über längere Zeiträume dieselbe bleibt, wird der Modellprozess ein genaues, präzises und zuverlässiges Modell für die betreffende Messung abliefern können.

Dieses Modell wird auf der Basis eines Zeitraums konstruiert, innerhalb dem die Maschinerie bekanntermaßen gesund war. Somit wird dieses Modell als Definition des gesunden Zustands für den jeweiligen Tag zugrunde gelegt, das ja modelliert werden soll – statt dass man als gesunden Zustand die statischen Grenzwerte heranzieht wie beim normalen Condition Monitoring.

Das Modell wird in Echtzeit evaluiert und erbringt einen Erwartungswert für jeden relevanten Tag. Ein Konfidenzintervall wird um diesen erwarteten Wert herum berechnet, woraus sich eine Bandbreite von Werten ergibt (hellgrünes Band in der obigen Grafik), die als gesund gelten. Liegt der gemessene Wert innerhalb dieser Bandbreite, ist die Maschinerie gesund. Liegt der gemessene Wert außerhalb dieser Bandbreite, wird ein Alarm ausgelöst. Das steht in Kontrast zum üblichen Condition Monitoring, bei dem Alarme auf der Basis von Grenzwerten ausgelöst werden, die sich im Laufe der Zeit nicht verändern, wie normale gelb, orange oder rote Regionen, wie man sie in vielen Condition Monitoring Programmen findet. Das ist der Grund, weshalb wir diesen Ansatz als dynamische Grenzwerte bezeichnen. Schauen Sie sich bitte das Bild oben für eine visuelle Darstellung dieses Prozesses an.

Sollten Sie daran interessiert sein zu erfahren, wie das Modell selbst zustande kommt, können Sie sich das in der Sektion zum mathematischen Hintergrund ansehen.

Die Methoden des maschinellen Lernens nutzen empirische Daten, die in der Vergangenheit an einer Maschine gemessen wurden, als diese Maschine sich erwiesenermaßen in einem gesundem Zustand befand. Aus diesen Daten konstruieren die Methoden des maschinellen Lernens automatisch und ohne menschliches Zutun eine mathematische Repräsentation der Beziehungen aller Parameter rund um diese Maschine.

Es kann mathematisch bewiesen werden, dass ein neuronales Netz in der Lage ist, einen komplexen Datensatz mit großer Genauigkeit darzustellen, solange das Netz groß genug ist und die Daten stets denselben Gesetzen gehorchen. Weil die Maschine den Naturgesetzen unterliegt, ist diese Voraussetzung natürlich gegeben. Aus diesem Grund verwenden wir ein neuronales Netz als Rahmenwerk, bei dem jede einzelne Messung an der Maschine im Zusammenhang mit den anderen Messungen der Maschine modelliert wird. Der Algorithmus des maschinellen Lernens findet die richtigen Werte für die Modell-Parameter, so dass das neuronale Netz die Daten genau repräsentiert.

Die Auswahl der Messungen, die für die Modellierung einer ganz bestimmten Messung in Betracht gezogen werden, kann automatisch erfolgen. Dazu benutzen wir eine Kombination zwischen Korrelationsmodellierung und Hauptkomponentenanalyse.

Das Ergebnis ist, dass jeder Tag der Maschine eine Formel erhält, mit deren Hilfe der erwarteten Wert dieser Tag berechnet werden kann. Weil diese Formel auf Daten basiert, die sich erwiesenermaßen als gesund herausstellten, gilt diese Formel als die Definition des Gesundheitszustandes der Maschine. Ungesunde Zustände werden dann als Abweichungen von diesem Gesundheitszustand betrachtet.

Es ist wichtig, den optimalen Gesundheitszustand zu modellieren und nach Abweichungen von diesem Ausschau zu halten, da diese Gesundheit ja als der normale Zustand gilt, und für das normale, gesunde Verhalten liegen ja auch sehr viele Daten vor. Wenige Daten gibt es indes für Zustände, die ungesund sind, und überdies sind diese Daten auch sehr verschiedenartig – aufgrund einer Unzahl von unterschiedlichen Fehlfunktionen. Solche Fehlfunktionen unterscheiden sich je nach Hersteller und Modell einer Maschine, was die umfassende Darstellung von möglichen Fehlerquellen sehr komplex macht. Fehlerhafte Zustände zu beschreiben ist also weniger ein Problem der Datenanalyse als vielmehr ein Problem der Datenverfügbarkeit. Darum ist dieses Problem von fundamentaler Bedeutung, das in der Praxis aber kaum umfassend angegangen werden kann.

Wir können jederzeit den erwarteten gesunden Wert mit dem gemessenen Sensorwert vergleichen. Weil sich der erwartete Wert aus dem Modell ergibt, kennen wir die Wahrscheinlichkeitsverteilung der Abweichungen, d.h. wir können vorhersagen, wie wahrscheinlich es ist, dass eine Messung von dem erwarteten (gesunden) Wert um einen bestimmten Betrag abweichen wird. Von dieser Wahrscheinlichkeitsverteilung können wir somit die Wahrscheinlichkeit eines gesunden Zustands berechnen oder, umgekehrt, das Konfidenzintervall dazu nutzen, um einzuschätzen, ob ein Sensorwert zu weit vom gesunden Zustand abweicht. In einem solchen Fall wird ein Alarm ausgelöst.

Der Alarm kann noch ergänzt werden durch die Information darüber, wie ungesund der Zustand ist, indem die Wahrscheinlichkeit eines schlechten Gesundheitszustands angegeben wird. Da der erwartete Zustand auf der Basis einer (gewöhnlich kleinen) Anzahl anderer Maschinen-Parameter berechnet wurde, ist es im Allgemeinen möglich, die Ursache einem anderen Messwert zuzuschreiben. Damit wird dem menschlichen Ingenieur eine Hilfestellung gegeben, der sich bei Auslösen eines Alarms um die Diagnose des Problems bemühen wird und eine Gegenmaßnahme ergreifen will.

Bei einem üblichen Condition Monitoring zeigt sich in der Praxis oft, dass, wenn eine Maschine von einem stabilen Zustand in einen anderen stabilen Zustand wechselt, dann zahlreiche (falsche) Alarme ausgelöst werden, da ein einfacher Analyseansatz mit den sich schnell verändernden Bedingungen nicht fertig wird. Ein neuronales Netz hingegen kann ohne Weiteres extrem nicht-lineare Beziehungen darstellen; sogar ein Hochfahren der Maschine oder ein Lastwechsel können präzise modelliert werden, ohne dass ein Alarm ausgelöst wird, solange sonst alles so ist, wie es sein soll.