DE69901626T2 - Fall-basiertes deduktives system, verfahren und gerät für sensor-prediktion in einem technischen prozess, insbesondere in einem zementofen - Google Patents

Description

• Die Erfindung betrifft ein Verfahren und eine Vorrichtung für ein System zum fallbasierten Schließen (CBR = Case-Based Reasoning), das insbesondere für die Aufgabe der Sensorwertvorhersage in einem Zementofensteuersystem entwickelt ist.
• Durch die Bereitstellung präziser Vorhersagen des Zementofenverhaltens über einen begrenzten Zeitraum in die Zukunft hinein, z. B. etwa 1 Stunde, kann ein Schaltwart des Zementofens in die Lage versetzt werden, besser informierte Entscheidungen zu treffen, und auch eine Basis zur automatisierteren Steuerung in einer Zementherstellungsanlage bereitstellen. Die Erfindung liefert eine Alternative für existierende Technologien, wie etwa regelbasierte Steuersysteme, die unvertretbar hohe Installations- und Wartungskosten erfordern.
• Als Teil eines existierenden Systems, das umfangreiche Supporteinrichtungen für die Steuerung einer Zementherstellungsanlage liefert, werden routinemäßig alle Sensordaten für den Zementofen und damit verbundene Maschinen in einer Datenbank gespeichert. Die Daten werden als Gleitkommazahlen mit Zeitstempel dargestellt.
• Als ein Beispiel für den Datenumfang, der in einem sensorbasierten technischen Prozeß verarbeitet werden muß, liegt die Sensorabtastrate in einem Zementofen in der Regel bei einmal pro Minute oder häufiger, in dem Zementofen und den damit verbundenen Vorrichtungen befinden sich in der Regel über 400 Sensoren und in dem Datenarchiv können Daten über einen Zeitraum von mehr als 1 Jahr hinweg gespeichert sein. Dies bedeutet, daß die Rohdaten in der Größenordnung von 10&sup8; → 10&sup9; Gleitkommazahlen sein können. Jedes automatisierte Verfahren, das diese Daten ausnutzt, um eine Sensorwertvorhersage durchzuführen, muß deshalb in der Lage sein, eine große Menge unstrukturierter Sensordaten bewältigen zu können.
• Die Erfindung eignet sich ganz besonders für technische Prozesse, in die ein Mensch eingreift. Der Zementofen in einer aktiven Zementherstellungsanlage wird in der Regel etwa alle 10-15 Minuten von einem menschlichen Experten überwacht und gesteuert. Wegen der hohen Anzahl der verwendeten Sensoren ist es für einen menschlichen Experten schwierig, einen hinreichenden Überblick über den Status des Ofens zu erhalten, weshalb ein Bedarf nach automatisierter Unterstützung bei der Aufgabe der Analyse besteht. Insbesondere bei Auftreten von ungewöhnlichem Verhalten, wenn beispielsweise Sensorwerte vorbestimmte Bereiche verlassen oder bei einer abrupten Änderung von Sensorwerten, ist Unterstützung erforderlich, um zu bestimmen, was die wahrscheinlich/möglichen Folgen des ungewöhnlichen Verhaltens sind, als auch welche korrigierenden Aktionen der menschliche Experte durchführen sollte. Um dies zu unterstützen, ist ein automatisiertes System erforderlich, das die Werte aller Sensoren für einen wesentlichen Zeitraum, z. B. > 1 Stunde, präzise in die Zukunft projizieren kann.
• Dennoch kann der Benutzer zu jedem beliebigen Zeitpunkt eine reduzierte Teilmenge von Signatursensoren dynamisch auswählen, die vermutlich die hervorstechendsten Informationen enthalten, um den aktuellen Zustand des technischen Prozesses zu kennzeichnen. Das automatisierte Vorhersagesystem muß somit so flexibel sein, daß es auf diese dynamische Benutzerauswahl reagieren kann.
• Die für einen technischen Prozeß gesammelten Sensordaten können oftmals problematisch sein. Wegen der relativen unmittelbaren Nähe vieler der Sensoren im Zementofen gibt es beispielsweise bei den Informationen, die in den für verschiedene Sensoren gespeicherten Daten dargestellt werden, eine erhebliche Redundanz. Es muß auch ein bestimmtes Niveau an Zufallsrauschen in den aufgezeichneten Daten toleriert werden. Es ist vielleicht noch wichtiger, daß nicht garantiert werden kann, daß alle Werte für alle Sensoren immer verfügbar sind. Es gibt einige Zeiträume, in denen keine Sensorwerte aufgezeichnet werden, z. B. aufgrund eines Ausfalls der Datenbank. Häufiger kommt vor, daß es für einen einzelnen Sensor für einen Zeitraum keine Werte gibt, z. B. aufgrund eines Ausfalls des eigentlichen Sensors. Das Vorhersagesystem muß diese Unreinheiten in den Rohdaten tolerieren können.
• Die letzte Komplexität des Problems besteht darin, daß jede Anwendung des Vorhersagesystems auf einen neuen Fall eines technischen Prozesses eine gewisse Neukalibrierung erfordert. So weist beispielsweise jeder Zementofen seine eigenen Verhaltenscharakteristiken auf. Es ist sogar wahrscheinlich, daß der enthaltene Satz von Sensoren sich von Zementofen zu Zementofen ändert. Das Sensorwertvorhersagesystem muß somit an jede Zementanlage, in der es installiert wird, neu angepaßt werden, was für jede Technik auf Modellbasis eine teure Vorgehensweise ist. Weiterhin ist wie bei vielen anderen Arten von Herstellungsvorrichtungen ein einzelner individueller Zementofen der Alterung unterworfen. Mit anderen Worten verschieben sich die Verhaltenscharakteristiken eines einzelnen Zementofens bekannterweise allmählich im Lauf der Zeit. Jedes für einen individuellen Zementofen entwickelte Verhaltensmodell muß zur Anpassung an diese Änderungen somit periodisch in Ordnung gebracht werden; auch dies stellt ein potentiell teures Wartungsproblem dar.
• Modellbasierte Techniken in Verbindung mit der Technologie der Künstlichen Intelligenz, wie etwa neuronale Netze und Fuzzy Logik, stellen den Stand der Technik für automatisierte Steuersysteme für Zementwerke dar. Bei dieser Art von Ansatz besteht das Hauptproblem darin, daß das allgemeine Modell des in dem Vorhersagesystem eingebetteten technischen Systems zur Anwendung in einem bestimmten Zementwerk von hochqualifizierten Experten angepaßt und parametrisiert werden muß. Wegen der Verschiebung des Verhaltens eines einzelnen Zementofens im Lauf der. Zeit muß das Modell außerdem periodisch gewartet, z. B. neu parametrisiert, werden, damit es einige Zeit lang zuverlässig bleibt. Die Nachteile der hohen Anwendungs- und Wartungskosten ergeben sich mit Wahrscheinlichkeit bei allen modellbasierten Techniken.
• Eine allgemeine Alternative zu von Hand konstruierten und angepaßten Modellen sind Maschinenlerntechniken, die an bestehenden Daten trainiert werden können. Die populärsten derartiger Maschinenlernansätze sind künstliche neuronale Netze, mit denen diagnostische Aufgaben auf der Grundlage von Sensordaten in ähnlichen Anwendungsfeldern wie dem der vorliegenden Erfindung erfolgreich ausgeführt worden sind. Bei künstlichen neuronalen Netzen bestehen dennoch weiterhin einige grundlegende Probleme, die ihre Verwendung für die Anwendung bei der Steuerung von Zementöfen ernsthaft verbieten:
• - Die Fähigkeit, fehlende Daten zu verarbeiten: Zur Erzeugung von fehlenden Sensorwerten gibt es einige Techniken, wie etwa die lineare Interpolation. Dennoch kann das Trainieren künstlicher neuronaler Netze durch den Grad an Rauschen in den Anwendungsdaten möglicherweise behindert werden. Außerdem ist es nicht klar, wie ein künstliches neuronales Netz die dynamische Auswahl einer Teilmenge relevanter Sensoren bewältigen kann.
• - Interpretierung von Ergebnissen: Die Basis hinter den von einem Schaltwart vorhergesagten und von einem künstlichen neuronalen Netz erzeugten Ergebnissen läßt sich von einem menschlichen Experten nicht leicht nachvollziehen. Ein Steuerungsexperte ist somit nicht in der Lage, die Zuverlässigkeit der Vorhersage zu bewerten. Aus diesem Grund eignen sich neuronale Netze besser für vollständig automatisierte Anwendungen, bei denen eine menschliche Untersuchung der Vorhersagen nicht erforderlich ist.
• - Fähigkeit zur Vorhersage ungewöhnlichen Verhaltens: Ein trainiertes künstliches neuronales Netz kann die allgemeinen Trends, die innerhalb der Trainingsdaten häufig wieder auftreten, im allgemeinen gut erkennen, reproduziert aber selten auftretende ungewöhnliche Umstände schlecht. Dennoch ist oftmals seltenes Verhalten das wichtigste, das bezüglich des Stands der Technik vorausgesagt werden muß, und die Aufgaben der Erfindung sind ein neues Verfahren und eine neue Vorrichtung zur Prozeßoptimierung, insbesondere in einem Zementofen, auf der Basis der von Sensoren erzeugten Daten.
• Aus EP 0 582 069 A2 ist ein Verfahren zum Steuern eines Prozesses mit Stell- und Steuergrößen bekannt, wobei die Steuergrößen Zielwerte aufweisen, die von dem eingestellten Wert der Stellgrößen abhängen. Der Prozeß wird in Echtzeit durch eine Prozeßsteuerung unter dem Betrieb eines Computers gesteuert. Das Steuerverfahren umfaßt die folgenden Schritte: Festlegen eines ersten Leistungsindexes zum Berechnen des Absolutwerts der Abweichung für jede Steuergröße in dem Prozeß von ihrem Zielwert über einen spezifizierten Zeithorizont; Erzeugen eines ersten linearen Programmiermodells, dessen Lösung den ersten Leistungsindex minimiert; Lösen des ersten linearen Programmiermodells; Festlegen eines zweiten Leistungsindexes zum Berechnen der absoluten Änderung des Werts jeder Stellgröße von ihrem vorausgegangenen Wert für jede Steuergröße über ein spezifiziertes Zeitintervall; Erzeugen eines zweiten linearen Programmiermodells, dessen Lösung den zweiten Leistungsindex minimiert; Integrieren mindestens einer dynamischen Nebenbedingung in das zweite lineare Programmiermodell, berechnet aus der Lösung des ersten linearen Programmiermodells und gleich einem Wert über Null und nicht größer als der Wert der Lösung des ersten linearen Programmiermodells plus einem vorbestimmten Betrag; Lösen des zweiten linearen Programmiermodells mit der dynamischen Nebenbedingung; und Einstellen der Stellgrößen als Reaktion auf die Lösung des zweiten linearen Programmiermodells zum Treiben der Steuergrößen zu den Zielwerten.
• Aus EP 0 745 916 A1 ist ein Verfahren zum Steuern eines technischen Prozesses bekannt, bei dem die Prozeßgrößen als Datenmengen gemessen und mit gespeicherten Datenmengen verglichen und/oder berechnet werden, um Steuerparameter zur Prozeßoptimierung zu erhalten. Die Datenmengen werden in Speichern gespeichert, und derartige Fälle von Datenmengen werden gewählt, die ein Ziel erfüllen. Die Fälle werden in einem mdimensionalen Raum als ein Polytop gespeichert, wobei nur solche Datenmengen zum Erhalten von Steuerparametern verwendet werden, die auf der Oberfläche eines Polytops liegen.
• Aus EP 0 529 307 A1 ist ein Verfahren zum Steuern des Betriebs eines Prozesses mit verflüssigtem Neutralgas bekannt, bei dem mit Gasturbinen angetriebene Kühlkompressoren verwendet werden. Das Verfahren umfaßt die folgenden Schritte: Bestimmen der Umgebungslufttemperatur an der Stelle des Verflüssigungsprozesses zu einem gegebenen Zeitpunkt; Bestimmen der optimalen Betriebsbedingungen des Verflüssigungsprozesses einschließlich dem Sollwert der Rückkopplungssteuerschleife zu dem gegebenen Zeitpunkt und Betreiben des Verflüssigungsprozesses mit den optimalen Betriebsbedingungen einschließlich dem Sollwert der Rücckopplungssteuerschleife; Vorhersagen der Umgebungslufttemperatur zu dem zukünftigen Zeitpunkt; Bestimmen neuer optimaler Betriebsbedingungen des Verflüssigungsprozesses einschließlich eines neuen Sollwerts der Rückkopplungssteuerschleife zu dem zukünftigen Zeitpunkt und Ändern der optimalen Betriebsbedingungen in die neuen optimalen Betriebsbedingungen einschließlich Ändern des Sollwerts in den neuen Sollwert; Betreiben des Verflüssigungsprozesses bei den neuen optimalen Betriebsbedingungen einschließlich dem neuen Sollwert; und Wiederholen der obenerwähnten Schritte bei einem durch die zeitliche Differenz zwischen dem gegebenen Zeitpunkt und dem zukünftigen Zeitpunkt definierten Zeitintervall.
• Aus EP 0 477 490 A2 ist eine Ungefähr-Schließ-Vorrichtung bekannt, bei der eine Beziehung zwischen Faktoren und Schlußfolgerungen, die aufgetreten sind, darstellende Daten in einem Speicher angesammelt werden, wodurch es möglich wird, eine Wissensbasis zu revidieren, die bereits, z. B. bei der Auslegungsstufe, unter Verwendung der angesammelten Daten festgelegt worden ist. Da die Wissensbasis unter Verwendung von Daten revidiert wird, die die Beziehungen zwischen Faktoren und Schlußfolgerungen darstellen, die tatsächlich aufgetreten sind, wird ein präziseres ungefähres Schließen möglich. Da die Revidierung der Wissensbasis automatisch durchgeführt wird, ist außerdem die Wartung einer Wissensbasis ohne die Hilfe von Experten möglich.
• Aus US 5,574,638 ist ein Verfahren bekannt, das eine robuste Steuerung eines Prozesses bereitstellt, mit den folgenden Schritten: Berechnen einer Menge von Skalierfaktoren für die Stellgrößen und die Prozeßgrößen. Die Steuerung wird mit der Menge von Skalierfaktoren initialisiert, wobei die Skalierfaktoren die relative Wichtigkeit der Stellgrößen und der Prozeßgrößen für den Prozeß bestimmen. Die robuste Steuerung wird so initialisiert, daß sie vorbestimmte Nebenbedingungen der Stellgrößen und der Steuergrößen aufweist. Dann werden die aktuellen Werte der Stellgrößen und der Steuergrößen erhalten. Neue Werte werden für die Steuergrößen für eine vorbestimmte Anzahl von Punkten in der Zukunft derart berechnet, daß die Werte der Steuergrößen innerhalb des vorbestimmten Bereichs liegen, wodurch für die resultierende Steuerung eine optimale Robustheit erhalten wird.
• Aus WO 93/21587 ist ein Maschinenlernsystem bekannt, das ein dem fallbasierten System ähnliches Schließsystem mit einer relationalen Datenbank implementiert. Eine relationale Datenbank kann einen Satz von Aufzeichnungen und einen Satz von Feldern umfassen, wobei jedes Feld in jeder Aufzeichnung einen Wert, wie etwa einen Zahlenwert, umfassen kann. Fälle in einem fallbasierten Schließsystem können durch Aufzeichnungen wie solche in der relationalen Datenbank dargestellt werden, und ein Merkmal eines Falls kann durch die Felder der Aufzeichnung dargestellt werden. In der Fallbasis kann ein Fall durch Aufzeichnungen in der relationalen Datenbank dargestellt werden, während Fälle, auf die man treffen kann und die möglicherweise der Fallbasis entsprechen, durch Aufzeichnungen dargestellt werden können, die der relationalen Datenbank entsprechen können. Wenn eine Fall an die Fallbasis angepaßt werden soll, kann eine Suchbezeichnung zusammengestellt und so angewendet werden, daß eine Suchmenge von Aufzeichnungen hergestellt wird, die ähnliche Fälle darstellen. Eine dieser Aufzeichnungen kann als die prädiktive Aufzeichnung gewählt werden, die den Fall darstellt, bei dem es sich um die beste Entsprechnung handelt. Wenn die die beste Entsprechung darstellende Aufzeichnung gewählt wird, können die vorhergesagten Felder die vorgeschriebene Aktion für diesen Fall darstellen. So können beispielsweise bei einem Helpdesk-System die vorhergesagten Felder eine Sprachreaktionsnachricht und ein dem Anrufer zu präsentierendes Auswahlmenü angeben.
• Aus US 5,587,897 ist ein Optimierungsverfahren bekannt, das einen Schritt zum Eingeben einer Zielfunktion umfaßt, die einen zu optimierenden Parameter enthält und ein Objekt zum Suchen einer optimalen Lösung ist, wobei eine geforderte Präzision eine Präzision angibt, die beim Suchen der optimalen Lösung gefordert wird, und ein Suchgebiet zum Suchen der optimalen Lösung für die Objektfunktion, um die Zielfunktion zu einer konvexen Funktion zu machen; einen Schritt zum Eingeben der konvexen Zielfunktion zum Erfassen eines Suchstartpunkts zum Starten einer Suche der optimalen Lösung aus dem Suchgebiet der optimalen Lösung und einen Schritt zum Erfassen der optimalen Lösung auf der Basis des erfaßten Suchstartpunkts.
• Diese Aufgaben werden in den Prozeßansprüchen und den entsprechenden Vorrichtungsansprüchen offenbart.
• Die Erfindung wird in Verbindung mit den Darstellungen, die einen Überblick über die Vorrichtung, sechs Flußdiagramme und eine beispielhafte grafische Darstellung praktischer Ergebnisse enthalten, näher beschrieben. Der spezifische Inhalt ist wie folgt:
• Fig. 1 ist eine Vorrichtung für die Fallbasisoptimierung
• Fig. 2 ist auf der obersten Ebene der Fluß des in der Vorrichtung von Fig. 1 ausgeführten Verfahrens
• Fig. 3 ist der Trainingsfluß
• Fig. 4 ist der Auswertungsfluß
• Fig. 5 ist der Fluß zum Extrahieren der Fallbasis
• Fig. 6 ist der Fluß zum Erzeugen von Sensorvorhersagen
• Fig. 7 ist der Fallabruffluß
• Fig. 8 ist ein Diagramm mit Ergebnissen des erfindungsgemäßen Verfahrens und der erfindungsgemäßen Vorrichtung.
• Der in dem erfindungsgemäßen System verwendete Ansatz besteht darin, auf Sensorvorhersage ein fallbasiertes Schließen (CBR = Case-Based-Reasoning) anzuwenden. Das Prinzip hinter CBR besteht darin, alte Problemlösungen wieder zu verwenden. Die Wissensbasis des CBR-Systems ist eine Sammlung von problemlösenden Fällen. Jeder Fall besteht aus zwei getrennten Teilen:
• - Eine Problembeschreibung - die Sammlung von Merkmalen (Symptomen), die das Problem kennzeichnen
• - Die Problemlösung - eine Beschreibung, welches die Lösung des Problems war und wahlweise, wie die Lösung abgeleitet wurde.
• Das Prinzip hinter CBR besteht darin, daß ähnliche Probleme ähnliche Lösungen haben. Zur Lösung eines neuen Problems, wo nur eine Problembeschreibung existiert, wird dieses neue Problem somit über eine bestimmte domainenspezifische Ähnlichkeitsfunktion mit allen existierenden Problemen verglichen. Nachdem ein oder mehrere ähnliche, vorher gelöste Probleme, d. h. Fälle, gefunden worden sind, werden die Lösungen auf das neue Problem wieder angewendet.
• Das hier beschriebene System ist insoweit einmalig, als es CBR auf das Problem der Sensorvorhersage in technischen Problemen anwendet. Die Wissensbasis wird direkt auf das Archiv der Sensordaten derart aufgebaut, daß die Fälle in der Fallbasis und die tatsächlichen Sensordaten gekoppelt sind. Dies bedeutet, daß das System die aktuellsten Sensordaten ohne Notwendigkeit einer manuellen Modifizierung direkt ausnutzen kann. Auf diese Weise reagiert das System auf eine Verschiebung des Verhaltens des technischen Prozesses, wie durch die Sensordaten wiedergegeben.
• Das System vergleicht den aktuellen Zustand des technischen Prozesses, wie er in den Sensordaten wiedergegeben wird, mit allen zurückliegenden, beispielhafte frühere Zustände darstellenden Fällen, um den einen oder die mehreren ähnlichsten früheren Zustände des technischen Prozesses zu extrahieren. Eine Reihe alternativer früherer Zustände kann gleichzeitig für den aktuellen Zustand abgerufen und einem menschlichen Experten als mögliche alternative Vorhersagen vorgelegt werden. Bei dem Abrufen früherer Zustände gibt es einen relativ hohen Grad an Flexibilität; er kann auf einem Vergleich über alle 400+ Sensoren oder auf einer kleinen. Anzahl von von einem Benutzer ausgewählten Signatursensoren basieren. Der aktuelle Zustand und jeder frühere Zustand können grafisch aufgetragen werden. Da beispielsweise aktuelle Zementofendaten als Basis für die Vorhersage wiederverwendet werden, können die Ergebnisse von einem menschlichen Experten leicht interpretiert werden.
• Der CBR-Ansatz hat sich bei der Anwendung auf den Zementofen als erfolgreich und robust herausgestellt. Versuchsläufe haben gezeigt, daß das System in der Lage ist, bis zu 1 Stunde in die Zukunft hinein und darüber hinaus präzise Vorhersagen anzustellen. Außerdem wurde durch Experimente verifiziert, daß ein CBR-Ansatz in der Lage ist, allgemeine Trends, wie etwa stabile Sensorwerte, sowie seltene Ereignisse, wie etwa globale Änderungen an dem Zustand des Zementofens, die durch ein einzelnes Ereignis ausgelöst werden, vorherzusagen.
• Bei dem System werden die Fälle als teilweise virtuelle Ansichten der Daten in dem Sensordatenarchiv definiert. Jeden Sensor kann man sich als eine Folge von Werten mit Zeitstempel denken. Ein einzelner Fall stellt ein bestimmtes Zeitfenster in den Daten für alle Sensoren dar. In dem Zeitfenster eines einzelnen Falls gibt es zwei aufeinanderfolgende Zeiträume:
• - Der vorausgegangene Zeitraum - der die Folge von Sensorwerten darstellt, die dazu verwendet werden, um einen früheren Fall mit einer aktuellen Situation in dem technischen Prozeß, z. B. einem Zementofen, zu vergleichen
• - Der projizierte Zeitraum - der den Zustand des technischen Prozesses, z. B. eines Zementofens, über einen Zeitraum unmittelbar nach dem vorausgegangenen Zeitraum darstellt.
• Bei einer zweiten Version der Erfindung wird eine Reihe abstrakterer Merkmale, z. B. die Zahl der Schwingungen in dem vorausgegangenen Zeitraum, automatisch aus den Sensordaten extrahiert und als Teil in die Fallbeschreibung aufgenommen, um die Genauigkeit des Fallvergleichs zu verbessern.
• Im Hinblick auf die frühere Beschreibung von CBR stellt der vorausgegangene Zeitraum die Problembeschreibung für einen Fall und der projizierte Zeitraum die Problemlösung dar. Die eigentliche Zeitspanne für vorausgegangenen und projizierten Zeitraum wird durch Systemparameter definiert und kann für eine bestimmte Anwendung konfiguriert werden.
• Der Zeitpunkt, der die Grenze zwischen dem vorausgegangenen und dem projizierten Zeitraum markiert, wird in diesem Text als die Fallzeit bezeichnet. Nachdem für die aktuelle Situation in einem technischen Prozeß, z. B. dem Prozeß des Zementofens, ein früherer Fall abgerufen worden ist, wird seine Fallzeit auf den letzten aufgezeichneten Sensorwert synchronisiert, damit sein projizierter Zeitraum dann als Vorhersage für das zukünftige Verhalten des technischen Prozesses verwendet werden kann.
• Prinzipiell kann in der Fallbasis für jeden Zeitpunkt, zu dem ein getrennter Sensorwert aufgezeichnet wird, ein neuer Fall erzeugt werden. In Wirklichkeit wird dies zu einer übermäßigen Anzahl überlappender Fälle führen. In der Praxis werden wegen der üblicherweise langsamen Zustandsänderungsgeschwindigkeit in einem Zementofen in der Regel nur ein oder zwei Fälle benötigt, um das Verhalten über eine bestimmte Stunde hinweg zu kennzeichnen, obwohl bei ungewöhnlichen Gelegenheiten eine viel höhere Dichte von Fällen erforderlich ist, z. B. dann, wenn das Verhalten des Ofens eine größere Änderung erfährt. Um eine beste Vorhersageleistung zu erhalten, wird über das Sensordatenarchiv hinweg eine Wahrscheinlichkeitsverteilung von Fällen eingesetzt. Die Wahrscheinlichkeit der Erzeugung eines Falls bei einem bestimmten Zeitpunkt hängt von zwei Faktoren ab:
• - Dem Zeitraum seit der Erzeugung des letzten Falls
• - Einer Metrik der Informationsmenge in den Sensorwerten, z. B. Fluktuationsgrad, in der Nähe des Zeitpunkts.
• In der Regel werden bei Zeitpunkten, an denen das Verhalten des technischen Prozesses, z. B. des Zementofens, am dynamischsten ist, mehr Fälle erzeugt, während einige Fälle in stabilen Gebieten weiterhin beibehalten werden. Durch diese "intelligente" Verteilung von Fällen in dem Datenarchiv erhält man eine verbesserte Leistung bezüglich einer gleichmäßigen Verteilung der gleichen Anzahl von Fällen.
• Eine typische Anwendung enthält mehrere tausend frühere Fälle. Trotz der relativ laxen Nebenbedingungen hinsichtlich der Zeit, die benötigt wird, um eine neue Vorhersage in der Größenordnung von 1-2 Minuten zu erzeugen, ist das Lesen einzelner Sensorwerte aus einer Datenbank immer noch zu langsam. Deshalb müssen einige Sensordaten in dem örtlichen Speicher des Systems reproduziert werden, um das Abrufen von Fällen zu erleichtern. Dies wird als der Fallindex bezeichnet. Bei dem erfundenen System stellt der Fallindex die kleinste Menge an Sensorinformationen aus dem vorausgegangenen Zeitraum dar, die erforderlich ist, um ein zuverlässiges Abrufen früherer Fälle zu produzieren. Die Extrahierung des entsprechenden Fallindexes wird über eine vollautomatisierte Optimierungstechnik (unten beschrieben) erhalten. Es muß jedoch angemerkt werden, daß das System selbst ohne einen Fallindex, d. h. unter Verwendung aller Sensorinformationen für den Fallabruf, wenn auch nicht ganz optimal, so doch erfolgreich arbeiten kann. Das Fallbasisoptimierungssystem kann somit als ein Prozeß betrachtet werden, mit dem zuerst die Systemleistung verbessert wird, nachdem das System einige Wochen in Betrieb gewesen ist, und das als Offline-Mittel zum gelegentlichen Neukalibrieren des Steuersystems als Reaktion auf allmähliche Änderungen beim Verhalten des technischen Prozesses, z. B. des Prozesses des Zementofens, verwendet werden kann.
• Das Ziel der fallbasierten Optimierung besteht darin, die Menge der in der Fallbasis replizierten Daten ohne Reduzieren der Qualität des Fallabrufs zu minimieren. Datenreduzierung bedeutet:
• i) Verwerfen irrelevanter Sensoren;
• ii) Bei relevanten Sensoren Bestimmen des kleinsten Zeitraums früherer Werte des Sensors, der für ein präzises Abrufen verglichen werden muß. Aus mehreren praktischen Gründen ist es wichtig, Daten zu reduzieren:
• - Speichernutzung ist reduziert (Kompression) - Die Datenmenge, die in dem Arbeitsspeicher des Systems gehalten werden kann, ohne daß man es mit hohen Graden von Speicherblättern zu tun hat, wird durch die Begrenzungen der gegenwärtigen Computerhardwaretechnologie begrenzt.
• - Abrufgeschwindigkeit - indem pro Fall weniger Sensorwerte verglichen werden, wird das Abrufen der ähnlichsten früheren Fälle beschleunigt.
• - Vorhersagequalität - Es existieren eine Reihe von Gründen, weshalb das Reduzieren der Menge explizit gespeicherter Daten pro Fall die Präzision des Systems erhöht. Zunächst werden durch die Begrenzungen hinsichtlich der Größe des Arbeitsspeichers effektiv die Anzahl der Fälle begrenzt, die auf einem gegebenen Datenarchiv erzeugt werden können - d. h. es bestimmt, wie spärlich Fälle im Datenarchiv verteilt sind. Durch Reduzieren der Datenmenge pro Fall können mehr Fälle erzeugt werden, weshalb der durchschnittliche Zeitraum zwischen erzeugten Fällen reduziert ist. Dies wiederum führt zu einer größeren Vorhersagepräzision, da im Durchschnitt eine präzisere zeitliche Ausrichtung früherer Fälle auf die aktuelle Situation möglich ist. Außerdem besteht ein weiterer Vorzug des Optimierungsprozesses darin, daß er im allgemeinen solche Sensoren eliminiert, die den geringsten Informationsgehalt haben, d. h. die hohe Grade an Rauschen aufweisen, oder hochredundante Informationen bezüglich anderer Sensoren haben. Die Präzision des Abrufens wird bezüglich der Situation, in der alle Sensorwerte verwendet werden, durch die Eliminierung irrelevanter Informationen allgemein verbessert.
• Die Fallbasisoptimierung beginnt mit einem Trainingsarchiv aus Sensordaten von dem technischen Prozeß, z. B. dem Prozeß eines Zementofens. Auf diesen Daten wird eine Trainingsfallbasis und eine Testfallbasis erzeugt, die von einander getrennt sind, d. h. in der Zeitspanne des Falls existiert keine Überlappung. Zu Anfang enthält der Index für jede Fallbasis alle Sensoren und alle Werte für jeden Sensor in dem vorausgegangenen Zeitraum.
• Da die Testfälle auf archivierten Daten basieren, ist das eigentliche Verhalten jedes Testfalls in seinem projizierten Zeitraum bekannt. Es ist deshalb für jeden Testfall möglich, im voraus zu bestimmen, welche Trainingsfälle den ähnlichsten projizierten Zeitraum aufweisen, indem z. B. ein Standardmaß für die Kurvennähe verwendet wird, wie etwa der mittlere quadratische Fehler. Somit können die idealen Abrufergebnisse für jeden Testfall, d. h. eine Anordnung über alle Trainingsfälle hinweg, erzeugt werden.
• Für einen gegebenen Index wird die tatsächliche Abrufanordnung von Trainingsfällen für einen gegebenen Testfall über einen Vergleich der vorausgegangenen Zeiträume erhalten. Ein allgemeines Maß für die "Eignung" einer gegebenen Indexbeschreibung für eine gegebene Trainingsfallbasis und Testfallbasis ist durch die durchschnittliche Nähe der Abrufanordnung von Trainingsfällen pro Testfall bezüglich der im voraus berechneten idealen Anordnungen von Trainingsfällen gegeben. Diese "Eignung" wird bei jedem Zyklus in dem Fallbasisoptimierungsprozeß berechnet.
• Bei einem einzelnen Optimierungszyklus wird ein einzelner Sensor zufällig ausgewählt, und die Anzahl der Werte für diesen Sensor in dem Index jedes Falls wird halbiert. Dann wird die resultierende "Eignung" der Fallbasis bestimmt. Falls keine Reduzierung der "Eignung" der Fallbasis eintritt, wird die Reduzierung der Anzahl der Sensorwerte akzeptiert, ansonsten wird die erfolglose Anzahl von Werten eine Untergrenze für die Anzahl erforderlicher Werte für diesen Sensor. Somit konvergiert die Optimierung über einen strengen "Bergauf"-Ansatz - d. h. die Informationsmenge in den Sensoren, die verwendet wird, ist monoton reduziert, während keine Verschlechterung der Abrufqualität toleriert wird. Ein striktes "Bergauf" wird hauptsächlich deshalb implementiert, um eine Effizienz des Optimierungsprozesses sicherzustellen - bessere Ergebnisse können über eine Abänderung der Erfindung erhalten werden, die einen globaleren Optimierungsalgorithmus verwendet, wie etwa simuliertes Glühen.
• Der Optimierungsprozeß läuft solange weiter, bis die erforderliche Anzahl von Werten für jeden Sensor konvergiert - wegen des strengen "Bergauf"-Charakters des Algorithmus ist eine Konvergenz garantiert. Irrelevante Sensoren weisen am Ende keine erforderlichen Werte auf.
• Aus anfänglichen Versuchen an den Zementofendaten geht hervor, daß in dem Fallindex ungefähr nur 50% aller Sensoren aufgenommen sein müssen. Es ist wichtig, daß die Informationsmenge, die für jeden verbleibenden Indexsensor erforderlich ist, stark variiert. Die meisten aufgenommenen Sensoren erfordern nur, daß nur die jüngsten ein oder zwei Werte verglichen werden, während eine kleine Anzahl von Schlüsselsensoren eine hohe Anzahl (30 → 60) Werte erfordern. Aus den anfänglichen Versuchen wird eine Gesamtkompression auf nur 5-10% der anfänglichen Menge aller Sensorwerte innerhalb der optimierten Fallindizes erzielt. Dies bedeutet effektiv, daß 10-20 Mal mehr Fälle für eine gegebene Arbeitsspeicherkapazität in die Fallbasis aufgenommen werden können, wodurch die Genauigkeit des Systems erhöht wird. Die Genauigkeit wird außerdem durch die Eliminierung von Rauschen erhöht.
• Viele CBR-Systeme strukturieren ihren Fallspeicher im Voraus, um eine schnelle Fallabfrage zu unterstützen, z. B. durch die Verwendung von Entscheidungsbäumen zum Trennen der zugrundeliegenden Fälle. Für diese Erfindung wird jedoch leider eine derartige Vorstrukturierung des Speichers durch die in jedem Fall gespeicherte massive Datenmenge zusammen mit der Notwendigkeit zur Flexibilität beim Abrufen von Fällen, z. B. die Echtzeitauswahl relevanter Sensoren durch einen Benutzer, extrem erschwert. Der implementierte Abrufmechanismus beinhaltet somit eine lineare Suche durch alle gespeicherten Fälle. Ein Ähnlichkeitsfunktion berechnet einen normierten Ähnlichkeitswert für jeden gespeicherten Fall bezüglich des aktuellen Zustands des technischen Prozesses, z. B. des Zementofens, und bezüglich der von einem Benutzer als relevant ausgewählten Sensoren. Das Ergebnis des Abrufens ist eine auferlegte ähnlichkeitsbasierte Anordnung über alle gespeicherten Fälle hinweg. Eine effizientere Abwandlung der Erfindung besteht darin, diese Anordnung nur für eine begrenzte Anzahl, z. B. 20, der besten früheren Fälle zu verwenden.
• Der Schlüssel beim Abrufen ist die verwendete Ähnlichkeitsfunktion. Die Ähnlichkeitsfunktion wirkt auf den Fallindex. Die Ähnlichkeit der aktuellen Situation mit einem gespeicherten Fall ist gleich der normierten Summe der Ähnlichkeiten jedes Paars entsprechender Indexsensoren. Die Ähnlichkeit der Wertmengen für zwei entsprechende Sensoren kann durch standardmäßige mathematische Funktionen, z. B. den quadratischen Mittelwert, berechnet werden.
• In einer erweiterten Version der Erfindung werden Sensoren nicht nur durch ihre Wertemengen, sondern auch durch aus diesen Wertemengen extrahierte Merkmale, z. B. die Anzahl der Fluktuationen in dem vorausgegangenen Zeitraum, repräsentiert. Derartige Merkmale können auch unter Einsatz spezialisierter Ähnlichkeitsfunktionen verglichen und mit der Ähnlichkeit zwischen Wertemengen kombiniert werden, um zwischen zwei entsprechenden Sensoren ein Gesamtähnlichkeitsmaß zu erhalten. Es hat sich gezeigt, daß die Aufnahme derartiger extrahierter Sensormerkmale die Gesamtpräzision des Abrufmechanismus verbesserte.
• In Fig. 1 ist das Fallbasisoptimierungsrahmenwerk gezeigt, das die Fallbasis 100, einen Testgenerator 101, einen Optimierer 102, einen Auswerter 103 und einen Akzeptor 104 enthält. Die Einheiten 101 bis 104 sind interaktiv an die Fallbasis 100 angekoppelt. Der Testgenerator 101 löst den Optimierer 102 aus, der Signale erzeugt. Der Optimierer 102 aktiviert den Auswerter 103 und den Akzeptor 104. Signale von dem Akzeptor 104 werden zu dem Optimierer 102 zurückkanalisiert, um eine zyklische Aktivierung der Einrichtungen auszulösen.
• Die Fig. 2 bis 7 enthalten eine Reihe von Flußdiagrammen, die die Aktivitäten der Hauptkomponenten definieren, und Datenressourcen, die das Verhalten des neuen Systems definieren.
• Die Figuren werden unten getrennt beschrieben.
• Fig. 2 zeigt die oberste Ebene der Architektur des beanspruchten Verfahrens. Sie umfaßt:
• - eine alle Sensordaten enthaltende Datenbank 201;
• - eine Datenbank 202, die Gruppierungen (Cluster) der Sensoren enthält;
• - eine Datenbank 203, die die generische Beschreibung (Index) jedes Falls in Form der erforderlichen Sensorwerte enthält;
• - eine Datenbank 204, die alle von dem Vorhersage- und Steuersystem verwendeten individuellen Fälle enthält;
• - eine Datenbank 205, die die vorübergehende Sammlung abgerufener Fälle enthält, die dem aktuellen Zustand des Zementofens entsprechen;
• - eine Trainingseinheit 206, die die Datenbanken 202 und 203 auf der Basis der Sensordaten in 201 erzeugt;
• - eine Fallextrahiereinheit 207, die die von dem Steuersystem verwendete Fallbasis 204 aus den Sensordaten 201 extrahiert;
• - eine Vorhersageeinheit 208, die eine Menge von Vorhersagen erzeugt, nämlich die Datenbank 205, auf der Grundlage der in den Datenbanken 201, 202, 203 und 204 gespeicherten Informationen;
• - eine Einheit 209, die die in der Datenbank 205 gespeicherten Vorhersagen zusammen mit den Sensordaten in 201 als Basis zur automatisierten Steuerung des Zementofens verwendet;
• - eine Einheit 210, die die in Datenbank 205 gespeicherten Vorhersagen zusammen mit den Sensordaten in 201 als Basis für ein grafisches Display der Vorhersagen zur Unterstützung eines Schaltwarts verwendet.
• Fig. 2 stellt das Verhalten des neuen Steuersystems auf der obersten Ebene dar. Es ist anzumerken, daß das System im normalen Betrieb drei mögliche Zyklen aufweisen wird:
• - Der langfristige Wartungszyklus kann bei der Installation des Systems einmal durchgeführt werden und dann selten, wenn überhaupt, um das System als Reaktion auf größere Änderungen in dem zugrundeliegenden technischen Prozeß, z. B. dem Zementofen, völlig neu zu trainieren. Das System lernt unter anderem einen neuen, optimalen Fallindex.
• - Der mittelfristige Wartungszyklus gestattet die Hinzufügung neuer Fälle zu der Fallbasis, ändert aber nicht die Definition des Fallindexes. Dieser Zyklus kann beispielsweise täglich durchgeführt werden, um die Fallbasis aktuell zu halten.
• - Der normale Vorhersagezyklus stellt die normale Verwendung des neuen Systems dar. Dieser Zyklus kann so regelmäßig wie einmal pro Minute durchgeführt werden, um die von dem System erzeugte Vorhersage aktuell zu halten.
• Die Ergebnisse des Systems werden als eine hinsichtlich der Ähnlichkeit geordnete Folge früherer Fälle dargestellt. Dadurch erhält man die grundlegenden Informationen, die das Extrahieren der relevantesten alten Sensorwerte aus der zugrundeliegenden Datenbank des technischen Prozesses gestatten. Extrahierte Daten können entweder einem menschlichen Experten als Hilfe bei der manuellen Prozeßsteuerung vorgelegt oder alt Eingabe zu einem automatisierten Steuersystem zum Führen computerbasierter Entscheidungen verwendet werden.
• Fig. 3 zeigt die interne Architektur der Trainingseinheit 206 von Fig. 2. Sie umfaßt:
• - eine Datenbank 301, die eine vorübergehende Fallbasis ist, mit der Vorhersagen während des Trainingszeitraums ausgewertet werden;
• - eine Datenbank 302, die eine zweite vorübergehende Fallbasis für Fälle ist, für die während des Trainingszeitraums Vorhersagen getroffen werden müssen;
• - eine Datenbank 303, die die bestmögliche Vorhersage für jeden aus den Sensordaten der Datenbank 201 von Fig. 2 extrahierten Testfall speichert;
• - eine Fallextrahiereinheit 304, die eine Abwandlung der Einheit 207 von Fig. 2 ist und die die in der Datenbank 201 von Fig. 2 gespeicherten Sensordaten trennt, um die beiden neuen Fallbasen 301 und 302 zu erzeugen;
• - eine Einheit 305, die die Gruppen von Sensoren erzeugt, die in der Datenbank 202 von Fig. 2 gespeichert sind, und zwar auf der Basis korrelierter Trends in den in der Datenbank 201 gespeicherten Sensorwerten;
• - eine Einheit 306, die den Anfangszustand des in der Datenbank 203 von Fig. 2 gespeicherten generischen Fallindexes in Form der größten Anzahl von Sensorwerten erzeugt, die in einem einzelnen Fall berücksichtigt werden sollten.
• - eine Einheit 307, die die Sensordaten von 201 auswertet, um die bestmöglichen Vorhersagen jedes Testfalls, die in der Datenbank 303 gespeichert sind, zu bestimmen;
• - eine Einheit 308, die einen Sensor zufällig auswählt, und eine Einheit 309, die die Anzahl der Werte des entsprechenden Sensors, die in dem in 203 gespeicherten generischen Fallindex enthalten sind, vorübergehend reduziert;
• - eine Auswerteinheit 310, die bestimmt, ob die frühere Reduzierung der Sensorwerte durch die Einheit 309 bezüglich der idealen Ergebnisse zu einer verbesserten Vorhersageleistung geführt hat;
• - eine Einheit 311, die die von 309 durchgeführte und in der Datenbank 303 gespeicherte letzte Änderung im Fall einer positiven Auswertung durch die Einheit 310 permanent macht und eine Einheit 312, die die von der Einheit 309 vorgenommene letzte Änderung im Fall einer negativen Auswertung durch die Einheit 310 rückgängig macht;
• - eine Einheit 313, die bestimmt, wann der Trainingszeitraum enden sollte, d. h., es ist keine weitere Verbesserung des generischen Fallindexes der Datenbank 203 möglich.
• Fig. 3 stellt das relativ komplexe innere Verhalten der Trainieraktivität des erfundenen Systems dar. Aus den rohen Sensordaten kann eine Test- und Trainingsfallbasis zusammen mit der Menge von Sensorclustern konstruiert werden. Das System verfeinert dann iterativ den Fallindex derart, daß eine kleinste Menge an Sensordaten in den Fallindex aufgenommen wird, ohne daß es zu einer Verschlechterung der Genauigkeit beim Abrufen kommt.
• Das Herz des Trainingsprozesses ist die in Fig. 4 gezeigte Auswertaktivität. Fig. 4 zeigt die interne Architektur der zentralen Auswerteinheit 310 von Fig. 3 der Trainingseinheit 206 von Fig. 2. Sie umfaßt weiterhin:
• - eine Datenbank 401, die die aus der Testfallbasis 302 ausgewählten aktuellen Fälle vorübergehend darstellt;
• - eine Einheit 402, die nacheinander jeden der in 302 von Fig. 3 gespeicherten Testfälle auswählt und sie in 401 plaziert;
• - eine Einheit 403, die einen Fallabruf aus den in 301 gespeicherten Trainingsfällen auf der Basis des aktuellen Testfalls in 401 und des aktuellen Zustands des generischen Fallindexes in 203 durchführt, um die in 205 von Fig. 2 gespeicherten vorübergehenden Abrufergebnisse zu erzeugen;
• - eine Einheit 404, die bestimmt, welche der in 303 von Fig. 3 gespeicherten idealen Ergebnisse auf den gegenwärtig in 401 gespeicherten Testfall angewendet werden können;
• - eine Einheit 405, die ein numerisches Maß der Differenz bei der Vorhersage berechnet, die für den Testfall von 401 durch die entsprechenden Abrufergebnisse der Datenbank 205 von Fig. 2 angestellt wurde, und zwar bezüglich der entsprechenden idealen Ergebnisse in der Datenbank 303 von Fig. 3;
• - eine Einheit 406, die die kombinierte numerische Auswertung über alle Testfälle von 302 hinweg in eine Boolesche Entscheidung dahingehend umsetzt, ob die Auswertung positiv war oder nicht.
• Die Auswertung nimmt nacheinander jeden Fall der Testfallbasis und führt einen Abruf aus der Trainingsfallbasis durch. Die resultierende Abrufanordnung wird mit einer im voraus berechneten idealen Anordnung von Trainingsfällen für den Testfall verglichen. Für den Entsprechungsgrad der beiden Anordnungen wird ein Zahlenwert berechnet und zu einem kombinierten Auswertungswert für den ganzen Testfall addiert.
• Fig. 5 zeigt die interne Architektur der Einheit 207, siehe auch 304, mit der eine Fallbasis in der obersten Ebene der Architektur extrahiert wird. Sie umfaßt folgendes:
• - eine Einheit 501, die einen numerischen "Interessewert" für jeden Zeitpunkt der in der Datenbank 201 gespeicherten Sensorwerte berechnet;
• - eine Einheit 502, die bestimmt, ob der Interessepegel jedes Zeitpunkts einen gegebenen Schwellwert übersteigt;
• - eine Einheit 503, die verwendet wird, wenn die Einheit 502 bestimmt, daß der Schwellwert überstiegen worden ist, um einen neuen Fall zu erzeugen und den Fall in die Datenbank 204 einzufügen.
• Fig. 5 zeigt die Art und Weise, wie eine Fallbasis aus der Datenbank von Sensorwerten für den technischen Prozeß extrahiert wird. Der Prozeß iteriert von einer Startzeit zu einer Endzeit und erzeugt einen Fall bei jedem Zeitpunkt, der bezüglich einer berechneten Metrik als "interessierend" definiert ist. Normalerweise iteriert die Extraktion von den ersten gespeicherten Sensorwerten bis zu den jüngsten Daten. Um die Trainings- und Testfallbasen zu erzeugen, müssen die Daten in getrennte Test- und Trainingszeiträume getrennt werden.
• Fig. 6 zeigt die interne Architektur der Einheit 208 von Fig. 2, mit der Sensorwertvorhersagen vorgenommen werden. Sie umfaßt:
• - eine Datenbank 601, die einen neuen Fall darstellt, für den eine Vorhersage angestellt werden muß,
• - eine Einheit 602, durch die auf der. Basis der in der Datenbank 202 gespeicherten Sensorgruppierungen eine Teilmenge aller Sensoren als zum Abrufen relevant bestimmt werden kann;
• - eine Einheit 603, die in der Datenbank 601 einen neuen Fall erzeugt, der die in der Datenbank 201 gespeicherten jüngsten Sensorwerte darstellt;
• - eine Abrufeinheit 604, die Fallabrufoperationen für den neuen Fall in der Datenbank 601 aus der Fallbasis 204 auf der Grundlage der in den Datenbanken 202, 203 gespeicherten Informationen durchführt. Die Ergebnisse werden in der Datenbank 205 gespeichert.
• Fig. 6 stellt das innere Verhalten der Hauptaktivität, zukünftige Sensorwerte vorherzusagen, dar. Der Vorhersageprozeß entspricht dem Prozeß des Abrufens von Fällen. Das einzige, was hinzukommt, ist, daß der Benutzer zuerst mit dem System interagieren kann, um diejenigen Sensoren auszuwählen, die gegenwärtig von Interesse sind. Beim Abrufen der relevanten zurückliegenden Fälle werden dann nur diese Sensoren berücksichtigt.
• Fig. 7 zeigt die interne Architektur der Abrufeinheit 604 von Fig. 6. Sie umfaßt:
• - eine Datenbank 701, in der jeder gespeicherte Fall während des Abrufprozesses vorübergehend gespeichert wird;
• - eine Datenbank 702, die die Werte für einen ausgewählten Sensor des in der Datenbank 701 gespeicherten alten Falls darstellt;
• - eine Datenbank 703, die die Werte für einen ausgewählten Sensor des in der Datenbank 601 von Fig. 6 gespeicherten neuen Falls darstellt;
• - eine Einheit 704, die die in der Datenbank 205 gespeicherten Abrufergebnisse vor dem neuen Abrufprozeß löscht;
• - eine Einheit 705, die nacheinander jeden der in der Datenbank 204 gespeicherten Fälle auswählt und den alten Fall in der Datenbank 701 plaziert;
• - eine Einheit 706, die nacheinander jedes entsprechende Paar Sensoren aus dem alten Fall der Datenbank 701 und dem neuen Fall der Datenbank 601 auswählt, wobei sie die ausgewählten Sensorgruppierungen in 202 berücksichtigt, und dann die entsprechende Anzahl von Werten gemäß dem in der Datenbank 203 gespeicherten generischen Fallindex extrahiert, wobei die Sensorwertfolgen in den Datenbanken 702 bzw. 703 gespeichert werden;
• - eine Einheit 707, die einen Ähnlichkeitszahlenwert für die Entsprechung zwischen den in den Datenbanken 702 und 703 gespeicherten Sensorwertfolgen berechnet;
• - eine Einheit 708, die die von der Einheit 707 erzeugten Ergebnisse zu einem internen Fallähnlichkeitswert addiert;
• - eine Einheit 709, die einen alten Fall aus der Datenbank 701 zu den in der Datenbank 205 gespeicherten neuen Fallabrufergebnissen addiert unter Sicherstellung, daß die alten Fälle bezüglich abnehmender Ähnlichkeit zu dem neuen Fall in der Datenbank 601 geordnet sind.
• Fig. 7 stellt den Fallabrufprozeß dar. Dabei werden gegenwärtig alle gespeicherten Fälle in einer gegebenen Fallbasis linear durchsucht. Jeder dieser Fälle wird mit einem gegebenen neuen Fall verglichen. Die Ähnlichkeit zwischen einem alten und neuen Fall basiert auf der Summierung von Ähnlichkeiten von Paaren von Sensoren zwischen den beiden Fällen. Der Fallindex spezifiziert sowohl, welche Sensoren es Wert sind, beim Abrufen berücksichtigt zu werden, als auch, wieviele Werte für jedes Paar von Sensoren für ein zuverlässiges Ähnlichkeitsmaß verglichen werden müssen.
• Wie oben angegeben, ist das Ergebnis des Abrufens eine geordnete Liste früherer Fälle für den technischen Prozeß, z. B. den Zementofen. Der eine oder die mehreren ähnlichsten Fälle liefern die Basis, auf der eine Auswertung des wahrscheinlichsten zukünftigen Zustands des technischen Prozesses erfolgen kann und folglich die entsprechenden Steuerentscheidungen getroffen werden können. Während das erfundene System im Prinzip als Teil eines vollautomatisierten Steuersystems arbeiten könnte, ist die Hauptbetriebsart in Zusammenarbeit mit einem menschlichen Experten - das erfundene Steuersystem legt dem Experten die abgerufenen Fälle in einem klar verständlichen Format vor, z. B. einer grafischen Darstellung, und der menschliche Experte trifft die informierten Steuerentscheidungen. Dies befreit den menschlichen Experten von der zeitraubenden, fehleranfälligen und mühsehligen Aufgabe, zu versuchen, die ähnlichsten früheren Zustände des technischen Prozesses, z. B. des Prozesses des Zementofens, wie sie in dem Datenarchiv gespeichert sind, zu finden, wobei seine Intuition und sein Verständnis des technischen Prozesses am besten ausgenutzt werden können.
• Ein Beispiel der grafischen Darstellung ist in Fig. 8 angegeben.
• Der Benutzer ist in Wirklichkeit nicht darauf beschränkt, sich nur die durch den Umfang eines Falls definierten Zeiträume anzusehen. Das System enthält eine Allzweckbetrachtungsvorrichtung zum Browsen der Zementofendatenbank. Die vorhergehenden und projizierten Zeiträume eines abgerufenen Falls werden als vertikale Linien einer kontinuierlicheren Kurve von Sensorwerten überlagert. Auf diese Weise gestattet der Browser, einen viel längeren Zeitraum in die Vergangenheit hinein zu betrachten, als durch den vorhergehenden Zeitraum eines Falls definiert ist, was wiederum ein umfasserendes Verständnis der Ähnlichkeit zwischen der aktuellen Situation und einem abgerufenen Fall ermöglicht. Es ist weiterhin möglich, über den projizierten Zeitraum für den vorausgegangenen Fall hinauszublicken, um eine längere Vorhersage für das zukünftige Verhalten des Zementofens zu erhalten. Dies wird zwar nicht allgemein empfohlen, da die Genauigkeit der Vorhersage allgemein mit der Entfernung in die Zukunft abnimmt, doch ist das erfundene System oftmals in der Lage, in einem technischen Prozeß langfristige Trends vorherzusagen. So lieferte das erfundene System beispielsweise allgemein Vorhersagen hinsichtlich des Zementofens, die länger gültig waren als für die eingestellten Projektionszeiträume von 1 Stunde für die Fälle.
• Die "Ergebniskurven" von Fig. 8 sind ein typisches Beispiel für die Ergebnisse des neuen Systems während des Auswertungszeitraums. Fig. 8 zeigt auf der rechten Seite die für drei ausgewählte Sensoren, Sensor 41, Sensor 59 und Sensor 92 getroffene Vorhersage für einen von einem menschlichen Experten ausgewählten Auswertfall. Die tatsächlichen Daten sind für einen Vergleich entlang der vorhergesagten Daten aufgetragen, während bei normalem Betrieb im Gegensatz zu der Auswertphase jenseits des Ähnlichkeitszeitraums nur vorhergesagte werte zur Verfügung stehen und somit gezeigt werden.
• Fig. 8 veranschaulicht eine Reihe von Schlüsselcharakteristiken des Systems:
• - Vorhersagen bleiben oftmals länger als der erforderliche Vorhersagezeitraum von 1 Stunde gültig - bei dem Beispiel beginnt die Verschlechterung der Qualität erst nach etwa 3 Stunden in die Zukunft
• - die zeitliche Ausrichtung zwischen Vorhersage und tatsächlichem Verhalten ist nicht immer präzise - es kann z. B. eine Differenz von etwa 10 Minuten zwischen der vorhergesagten und tatsächlichen Anstiegsflanke des Sensors 92 deutlich beobachtet werden
• - das System erfaßt erfolgreich die Beziehungen zwischen Sensoren - die erfolgreiche Vorhersage der Anstiegsflanke des Sensors 92 kann beispielsweise nicht allein auf die Ähnlichkeit in diesem Sensor zurückgeführt werden, da die vorausgegangenen Werte für den Sensor 92 alle Null sind. Die Ähnlichkeit zwischen den beiden Situationen muß von den anderen Sensoren herrühren, entweder Sensor 41 oder 53, oder von einem oder mehreren der nicht angezeigten Sensoren.
• Das System ist ein einzigartiger Versuch, die CBR-Technologie auf die Aufgabe der Sensorvorhersage in einem technischen Prozeß, insbesondere einem Zementofen, anzuwenden. Folgendes sind die Vorteile des Ansatzes:
• - Vorhersagen basieren auf konkreten Beispielen aus der Vorgeschichte des Zementofens. Die Vorhersagen können deshalb von einem menschlichen Experten untersucht und verstanden werden.
• - Das System ist direkt an die zugrunde liegenden Sensordaten im Datenarchiv angekoppelt, weshalb das System auf eine etwaige Verschiebung in dem Zementofenverhalten automatisch reagiert.
• - Das System erfordert zum Anstellen von Vorhersagen kein allgemeines Bereichsmodell, weshalb die Installations- und Wartungskosten gering sind.
• - Das System kann allgemeine Trends und ungewöhnliche Ereignisse vorhersagen.
• - Das System liefert eine Menge alternativer Vorhersagen für jede neue Situation. Die CBR-Annahme, daß ähnliche Probleme ähnliche Lösungen erfordern, hat sich bei der Zementofenanwendung als gültig herausgestellt. Das Abrufen ähnlicher Situationen führt zu Vorhersagen, die im allgemeinen über einen langen Zeitraum hinweg, z. B. über eine Stunde, gültig bleiben und in den allgemeineren Trends der Sensoren interessante Details erfassen.
• Das System stellt nicht nur durch seine Verwendung von CBR für diese Art von Problemen eine allgemeine Innovation dar, es waren auch eine Reihe mehr technischer Innovationen erforderlich, um die massive Menge vorliegender Rohdaten zu bearbeiten:
• - Die Definition von halbvirtuellen Fällen als zeitüberspannenden Ansichten der zugrunde liegenden Sensordaten
• - Ein Selbstoptimierungsalgorithmus für die Fallbasis zum Extrahieren der kleinsten Menge erforderlicher Indexinformationen.
• Das Potential für diese Technologie ist sehr hoch. Die Zementofenanwendung selbst kann in der Zukunft ausgeweitet werden. Innerhalb des zugrunde liegenden Datenarchivs sind auch die Steuerentscheidungen aufgezeichnet, die die den Zementofen überwachenden menschlichen Experten getroffen haben. Beim Abrufen eines früheren Falls kann das System daher nicht nur das Mittel zum Vorhersagen eines zukünftigen Ofenverhaltens, sondern auch zur Wiederverwendung von Steuerentscheidungen bereitstellen. Dies kann bei Zementfabriken die Basis für ein automatisierteres Steuersystem liefern. Das System könnte aber auch als Trainingssystem für neue Schaltwarte verwendet werden, mit dem sie untersuchen können, wie existierende Experten in verschiedenen Situationen tatsächlich reagiert haben.
• Weiterhin werden in dem zugrundeliegenden Datenarchiv auch Qualitätsmetriken mit Zeitstempel routinemäßig gespeichert. Es werden beispielsweise routinemäßig Proben der hergestellten Zementklinker genommen und in einem Labor geprüft. Die Ergebnisse dieser Prüfungen gestatten es, eine Klassifizierung dahingehend anzustellen, wie erfolgreich der Zementofen zu einem beliebigen gegebenen Zeitpunkt gearbeit hat. Derartige Auswertungen könnten in den Fallabrufmechanismus integriert werden, um Fälle als "gut" oder "schlecht" zu klassifizieren. Das System könnte somit einen Benutzer dahingehend führen, daß er erfolgreiche Steuerentscheidungen wiederverwendet, während es gleichzeitig vor der Wiederverwendung von Steuerentscheidungen warnt, die sich in der Vergangenheit als nicht erfolgreich herausgestellt haben. Dies sollte insgesamt zu einer Verbesserung der Leistung des Zementofens führen.
• Die Auslegung des Systems ist überhaupt nicht auf die Bedürfnisse der Zementofenanwendung spezialisiert. Für die Definition der Fälle wird ein hochgenerisches Modell von Sensordaten mit zeitlichen Trends verwendet. Das System könnte somit leicht auf die Vorhersage von Sensordaten in anderen Bereichen wieder angewendet werden. Folgendes sind die Bedingungen, unter denen das System mit größter Wahrscheinlichkeit die beste Implementierungswahl darstellt:
• - Sensordaten werden routinemäßig in einem maschinenlesbaren Datenarchiv gespeichert
• - Die Komplexität des Systems macht modellbasierte Techniken zu aufwendig oder praktisch unmöglich
• - Die zeitlichen Nebenbedingungen für die Erzeugung einer Vorhersage sind nicht zu streng - Die Zeit zum Treffen einer Vorhersage muß wesentlich kürzer sein als der Zeitraum, für den diese Vorhersage gültig bleibt. Das System ist gegenwärtig unter der Annahme eines Überwachungszyklus des Zementofens von 15 Minuten so ausgelegt, daß es in 1-2 Minuten eine Vorhersage trifft. Diese Geschwindigkeit hängt von der verfügbaren Computerhardware ab. z. B. der Größe des Speichers und von der Größe und Komplexität der in dem Datenarchiv gespeicherten Daten. Das System eignet sich gegenwärtig jedoch nicht für Anwendungen, die eine sehr schnelle Reaktion (< < 1 Sekunde) erfordern.
• - Die Interpretierbarkeit von Vorhersagen durch einen menschlichen Experten wird ein Hauptfaktor. Deshalb werden c.f.-neuronale Netze usw. verwendet.
• Außerdem sollte die Wiederanwendung des CBR-Ansatzes außer auf sensorbasierte Daten auf andere Arten von Informationen mit zeitlichen Trends möglich sein. Beispiele für derartige Informationen sind: Aktientrends, Markttrends, Teilnehmernachfragen in einem Stromversorgungsnetz usw.

Claims (16)

1. Verfahren zum Steuern eines technischen Prozesses, insbesondere zur Steuerung eines Zementofens, wobei der technische Prozeß eine große Anzahl Sensorwerte erzeugt, die aufgezeichnet und in einem Sensordatenarchiv (201) gespeichert werden, wobei aus den aufgezeichneten Sensordaten das Verhalten des technischen Prozesses darstellende Fälle erzeugt werden, wobei aus dem Sensordatenarchiv (201) eine Fallbasis extrahiert wird, die mindestens eine Teilmenge aller früher erzeugten Fälle enthält, wobei ein neuer Fall erzeugt wird, der einen aktuellen Zustand des technischen Prozesses darstellt, für den eine Vorhersage gemacht werden muß, und wobei der neue Fall mit den früheren Fällen als Basis der Vorhersage für das zukünftige Verhalten des technischen Prozesses verglichen wird, gekennzeichnet durch das Aufzeichnen von Folgen von Sensorwerten mit Zeitstempel und Speichern der Daten in dem Sensordatenarchiv (201), Erzeugen von Fällen, die ein Zeitintervall in den Daten für alle Sensorwerte darstellen und durch eine Fallzeit definiert sind, die die Grenze zwischen einem vorausgegangenen und einem nachfolgenden projizierten Zeitraum des Zeitintervalls markiert, Bestimmen eines Fallähnlichkeitswerts für jeden der früheren Fälle aus der Fallbasis mit dem neuen Fall durch Vergleichen der Sensorwertfolgen der früheren Zeiträume des neuen Falls und der früheren Fälle, Durchführen eines Fallabrufs aus der Fallbasis durch Ordnen der früheren Fälle bezüglich abnehmender Ähnlichkeit mit dem neuen Fall, Synchronisieren der Fallzeit des einen oder der mehreren ähnlichsten Fälle mit dem letzten aufgezeichneten Sensorwert des neuen Falls, und Verwenden des projizierten Zeitraums des ähnlichsten Falls als Vorhersage für das künftige Verhalten des technischen Prozesses.

2. Verfahren nach Anspruch 1, gekennzeichnet durch das Anzeigen des vorhergesagten Verhaltens des technischen Prozesses als Basis, auf der von einem menschlichen Experten eine Steuerentscheidung getroffen werden kann.

3. Verfahren nach Ansprüch 1 oder 2, gekennzeichnet durch das Auswählen einer relevanten Teilmenge aller Sensoren, die gegenwärtig von Interesse sind, und Verwenden nur der Wertfolge der relevanten Sensoren zum Bestimmen von Fallähnlichkeitswerten.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Bestimmung eines Fallähnlichkeitswerts folgende Schritte umfaßt: Auswählen eines entsprechenden Paars Sensoren aus dem früheren Fall und dem neuen Fall, Extrahieren der Anzahl von Sensorwerten gemäß einem Fallindex, wobei der Fallindex spezifiziert, welche Sensoren es Wert sind, während des Fallabrufs berücksichtigt zu werden, und wieviele Werte für jedes Paar Sensoren für eine zuverlässige Ähnlichkeitsbestimmung verglichen werden müssen, Berechnen eines Ähnlichkeitszahlenwerts für die Entsprechung zwischen den Sensorwertfolgen des ausgewählten Paars von Sensoren gemäß dem Fallindex, Aufsummieren der Ähnlichkeitszahlenwerte für alle Paare von Sensoren gemäß dem Fallindex auf den Fallähnlichkeitswert.

5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Extrahieren einer Fallbasis aus dem Sensordatenarchiv (201) die folgenden Schritte umfaßt: Berechnen eines numerischen Interessewerts für jeden Zeitpunkt der Sensorwerte, Bestimmen, ob der Interessewert jedes Zeitpunkts einen gegebenen Schwellwert übersteigt, Erzeugen eines Falls, wenn der Schwellwert überschritten worden ist und Einfügen des Falls in die Fallbasis.

6. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das Extrahieren einer Fallbasis aus dem Sensordatenarchiv (201) die folgenden Schritte umfaßt: Verwenden einer Wahrscheinlichkeitsverteilung von Fällen über das Sensordatenarchiv (201) hinweg, wobei die Wahrscheinlichkeit des Erzeugens eines Falls bei einem gegebenen Zeitpunkt von dem Zeitraum seit der Erzeugung des letzten Falls und einer Metrik der Informationsmenge in den Sensorwerten in der Nähe des Zeitpunkts abhängt.

7. Verfahren nach einem der Ansprüche 4 bis 6, dadurch gekennzeichnet, daß das Extrahieren eines Fallindexes die folgenden Schritte umfaßt: Erzeugen einer Trainingsfallbasis (301) auf dem Sensordatenarchiv (201), mit der Vorhersagen ausgewertet werden, und einer Testfallbasis (302), für die Vorhersagen angestellt werden müssen, wobei die Trainings- und Testfallbasis voneinander getrennt sind, Erzeugen eines Fallindexes, der anfänglich alle Sensoren und alle Werte für jeden Sensor in den vorhergehenden Zeiträumen der Fälle enthält, Bestimmen des die bestmögliche Vorhersage für jeden Testfall darstellenden idealen Abrufergebnisses auf der Basis des bekannten Verhaltens der Testfälle in ihren projizierten Zeiträumen, Verfeinern des Fallindexes durch Auswahl eines Sensors, Reduzieren der Anzahl von Werten in dem Fallindex für den Sensor, Auswerten, ob das Reduzieren von Sensorwerten zu einem verbesserten Abrufergebnis bezüglich des idealen Abrufergebnisses führt, Annehmen der reduzierten Anzahl von Sensorwerten in dem Fallindex, falls die Auswertung positiv ist, ansonsten Rückgängigmachen des Reduzierens.

8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, daß die Auswertung, ob das Reduzieren von Sensorwerten zu einem verbesserten Abrufergebnis führt, die folgenden Schritte umfaßt: Auswählen eines Testfalls aus der Testfallbasis (302), Durchführen eines Fallabrufs aus der Trainingsfallbasis (301) auf der Grundlage des Testfalls und des Fallindexes, wodurch ein tatsächliches Abrufergebnis erzeugt wird, Berechnen eines Zahlenwerts für den Entsprechungsgrad des tatsächlichen Abrufergebnisses bezüglich des idealen Abrufergebnisses, Addieren der Zahlenwerte aller Testfälle zu einem kombinierten Auswertungswert und Umsetzen des kombinierten Auswertungswerts in eine Entscheidung, ob die Auswertung positiv ist.

9. Verfahren nach einem der Ansprüche 4 bis 8, dadurch gekennzeichnet, daß das Extrahieren eines Fallindexes in einem langfristigen Wartungszyklus durchgeführt wird, bevorzugt einmal bei der Installation des Systems, dann selten, wobei das Extrahieren einer Fallbasis in einem mittelfristigen Wartungszyklus durchgeführt wird, bevorzugt täglich, und die Vorhersage für das zukünftige Verhalten des technischen Prozesses in einem normalen Vorhersagezyklus durchgeführt wird, bevorzugt so regelmäßig wie einmal pro Minute.

10. Vorrichtung zum Implementieren des Verfahrens nach Anspruch 1 oder einem der Ansprüche 2 bis 9, mit einer alle Sensordaten enthaltenden Datenbank (201), einer Datenbank (204), die alle von dem Vorhersage- und Steuersystem verwendeten individuellen Fälle enthält, einer Vorhersageeinheit (208), die eine Menge von Vorhersagen erzeugt, einer Einheit (603), die einen neuen Fall erzeugt, und einer Abrufeinheit (604), die Fallähnlichkeitswerte bestimmt und den Fallabruf durchführt.

11. Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, daß sie weiterhin eine Einheit (210) enthält, die die Vorhersagen als Basis einer grafischen Anzeige der Vorhersagen zum Unterstützen eines Schaltwarts verwendet.

12. Vorrichtung nach Anspruch 10 oder 11, dadurch gekennzeichnet, daß sie weiterhin eine Einheit (602) umfaßt, die das Bestimmen einer Teilmenge aller Sensoren als für das Abrufen relevant gestattet.

13. Vorrichtung nach einem der Ansprüche 10 bis 12, dadurch gekennzeichnet, daß sie weiterhin folgendes enthält: eine Einheit (706), die jedes entsprechende Paar von Sensoren aus dem früheren und neuen Fall auswählt und dann die entsprechende Anzahl von Werten gemäß einem Fallindex extrahiert, eine Einheit (707), die einen Ähnlichkeitszahlenwert berechnet, und eine Einheit (708) die das Ergebnis der Einheit (707) zu einem Fallähnlichkeitswert addiert.

14. Vorrichtung nach einem der Ansprüche 10 bis 13, dadurch gekennzeichnet, daß sie weiterhin folgendes enthält: eine Einheit (207), die die Fallbasis (204) aus den Sensordaten (201) extrahiert, wobei die Fallextrahiereinheit (207) eine Einheit (501) enthält, die einen numerischen Interessewert für jeden Zeitpunkt des Sensordatenarchivs (201) berechnet, eine Einheit (502), die bestimmt, ob der Interessewert jedes Zeitpunkts einen gegebenen Schwellwert übersteigt, und eine Einheit (503), die einen Fall erzeugt, wenn der Schwellwert überschritten worden ist, und die den Fall in die Fallbasis (204) einfügt.

15. Vorrichtung nach einem der Ansprüche 10 bis 14, dadurch gekennzeichnet, daß sie weiterhin folgendes enthält: eine Trainingseinheit (206) zum Extrahieren eines Fallindexes, wobei die Trainingseinheit (206) weiterhin eine Trainingsfallbasis (301) und eine Testfallbasis (302) enthält, eine Einheit. (306), die den Anfangszustand des Fallindexes erzeugt, eine Einheit (307), die die bestmögliche Vorhersage jedes Testfalls bestimmt, eine Einheit (308), die einen Sensor auswählt, eine Einheit (309), die die Anzahl der Werte des entsprechenden Sensors reduziert, die in dem Fallindex enthalten sind, eine Auswerteinheit (310), die bestimmt, ob das Reduzieren der Sensorwerte bezüglich der bestmöglichen Vorhersage zu einer Verbesserung der Vorhersageleistung führt, eine Einheit (311), die das Reduzieren im Fall einer positiven Auswertung durch die Einheit (310) permanent macht, und eine Einheit (312), die das Reduzieren im Fall einer negativen Auswertung rückgängig macht.

16. Vorrichtung nach einem der Ansprüche 10 bis 15, dadurch gekennzeichnet, daß sie weiterhin folgendes enthält: eine Einheit (402), die jeden der Testfälle auswählt, eine Einheit (403), die einen Fallabruf durchführt, um ein tatsächliches Abrufergebnis zu erzeugen, eine Einheit (405), die ein numerisches Maß der Differenz bei der Vorhersage durch das tatsächliche Abrufergebnis bezüglich des idealen Abrufergebnisses berechnet, und eine Einheit (406), die die kombinierte Zahlenauswertung in eine Entscheidung umsetzt, ob die Auswertung positiv war oder nicht.