DE10255730A1

DE10255730A1 - Kraftstoff-Zapfstation

Info

Publication number: DE10255730A1
Application number: DE10255730A
Authority: DE
Inventors: Tommy W Lewis; Jonathan Clark
Original assignee: Tokheim Corp
Current assignee: Tokheim Holding BV
Priority date: 2001-11-29
Filing date: 2002-11-29
Publication date: 2003-08-07
Also published as: US20030195653A1; GB2384326A; FR2835822A1; GB0227025D0

Abstract

Die Erfindung betrifft ein System, umfassend: DOLLAR A eine Kraftstoff-Zapfeinrichtung mit einer Mehrzahl von Komponenten und ein Agent-Facility, die mit der Kraftstoff-Zapfeinrichtung in Wirkverbindung steht und die derart konfiguriert ist, dass sie eine Überwachungsfunktion und/oder eine Kontrollfunktion der Kraftstoff-Zapfeinrichtung ausübt.

Description

Die Erfindung betrifft eine Kraftstoff-Zapfstation. Sie betrifft insbesondere ein Verfahren, ein System sowie ein Computerprogramm zur Anwendung in Kombination mit einer Betätigungseinheit zum Bereitstellen eines Netz- Managements von Kraftstoff-Abgabepositionen, um die Fernbedienung oder das Fernmanagement einer Zapfanlage zu erleichtern.
Herkömmliche Kraftstoff-Zapfstationen weisen üblicherweise eine Tankeinrichtung auf, die an eine Bedieneinheit mittels einer Leitung angeschlossen ist, welche ihrerseits Kundenwünsche und Steuerbefehle überträgt. Eine Bedieneinheit wie ein sogenanntes Point-of-sale-Terminal (POS) ist üblicherweise derart aufgebaut, daß der Tankwunsch des Kunden durchgeführt wird. Typische Operationen sind das Durchführen einer Autorisierungsprüfung, das Erstellen einer Quittung über die vollzogene Transaktion sowie das Kommunizieren mit dem Kunden bezüglich weiterer Leistungen, wie dem Ergänzen der Tank-Transaktion durch den Kauf von Waren des täglichen Bedarfs.

Herkömmliche Zapfstationen haben jedoch Mängel bezüglich gewisser Managementfunktionen, wie zum Beispiel diagnostischer- und Wartungsoperationen. Diese Managementfunktionen erfüllen Verwaltungsaufgaben, die wesentlich sind, um die Einheitlichkeit und die Bedienungsstandards des Zapfvorganges zu gewährleisten. So ist es beispielsweise notwendig, den Bedienstatus und die Arbeitsweise der Zapfeinheit zu überwachen, um sicherzustellen, daß diese bezüglich gewisser Benchmark- Anforderungen einwandfrei arbeitet. Ein solches Überwachen von Daten muß von einer Diagnoseeinheit durchführbar sein, um Störungen der Zapfeinheit zu erkennen und zu beseitigen, sowie um Wartungsvorgänge zu programmieren.

Solche Diagnoseschritte machen es jedoch notwendig, daß Bedienungspersonal physisch in die Zapfeinheit-Einrichtungen, wie in eine Zapfsäule, eingreift, um unmittelbaren Zugang zu den Bauteilen zu erlangen, und um einen Interface- Anschluß herzustellen unter Verwendung von Sonden oder Abtastwerkzeugen an der Einheit. In jedem Falle muß Personal, das sich an Ort und Stelle befindet, Überwachungsvorgänge von Hand an der Zapfeinheit durchführen.

Bekannte Überwachungseinrichtungen sind im allgemeinen isolierte, freistehende Gebilde. Die Überwachungsdaten lassen sich daher nicht automatisch zum Zwecke der Analyse einem Servicecenter einspeisen. Das Servicepersonal muß bisher die von den Zapfeinheiten erlangten Informationen einer Prozesseinheit übertragen, in welcher eine genauere Datenanalyse durchgeführt werden kann. Diese Folge von Schritten führt dazu, daß eine Entstörung umfangreich und langwierig ist, so dass ein bestimmtes Problem durch das Bedienungspersonal weder schnell identifiziert noch schnell beseitigt werden kann.

Es wäre beispielsweise wünschenswert, einen Wartungsvorgang unverzüglich dann einzuleiten, sobald ein Diagnoseergebnis verfügbar ist. Dann könnte nämlich das identifizierte Problem nicht weiter bestehen und sich auf die Zapfeinheit für eine längere Zeitspanne nachteilig auswirken. Außerdem wäre eine Kontrolleinheit wünschenswert, um eine Kontrolloperation durchzuführen, die vorteilhafter sein kann als eine Wartungsoperation.

Es ist daher eine verbesserte Diagnosemöglichkeit erforderlich, welche eine Diagnose automatisch, rasch und kontinuierlich durchführt. Dabei könnte die Diagnose an der Zapfeinheit selbst oder entfernt hiervon durchgeführt werden. Die Diagnose sollte dabei in der Lage sein, auch die Daten der Komponentenüberwachung automatisch zu erfassen. Ergebnisse jeglicher Datenbewertung sollten aufgeladen werden, um ein Wartungsprogramm zu erstellen, gemäß welchem Wartungsschritte abgerufen werden können. Die Diagnoseeinheit sollte derart gestaltet sein, daß sie automatisch eine Wartungsanforderung oder eine Kontrolloperation in Abhängigkeit vom Diagnoseergebnis einleitet.

Die Notwendigkeit einer verbesserten Diagnose- und Wartungsfunktion bei einer Zapfeinheit ist besonders wichtig im Hinblick auf Gewährleistungsposten. Eine Servicestation umfaßt bekanntlich im allgemeinen eine Mehrzahl von Zapfsäulen, die jeweils mit einer Vielzahl zunehmend komplexer Komponenten ausgestattet sind. Der wirtschaftliche Nutzen einzelner Zapfeinheiten hängt in hohem Maße von der Fähigkeit ab, die Zapfkomponenten auch über eine lange Zeitspanne bei fortwährender Benutzung effizient und zuverlässig arbeiten zu lassen.

Zahlreiche Faktoren verringern jedoch die Lebensdauer einzelner Komponenten. So können sich Umwelteinflüsse auf eine Servicestation nachteilig auswirken. Hierzu gehören extreme Temperaturen, Feuchtigkeit und andere wetterabhängige Effekte. Der wiederholte Gebrauch einzelner Komponenten kann zu einem Ausfall führen, wenn gewisse zeitliche Beschränkungen der Benutzungsdauer überschritten werden.

Jede Komponente einer Zapfanlage weist eine mittlere Zeitspanne bis zum Ausfallen auf (Meantime Between Failure = MTBF). Dieser Wert stellt die zulässige Zeitspanne des Gebrauchs dar.

Hier sind einige Beispiele für MTBF-Werte:
Kartenleseelektronik: 125 000a
Kartenleserkopf: 500 000 Durchgänge
Druckerelektronik: 50 000 000 Impulse
Druckerabrieb: 50 km Papier
Membrantaste: 1 000 000 Tastendrücke

Die genannten MTBF-Werte lassen sich jedoch normalerweise nur dann erreichen, wenn die Komponenten ständig gewartet werden. Es wäre wünschenswert, ein System zu haben, das anzeigt, wenn ein Wartungsschritt durchzuführen ist.

Aber auch dann, wenn der MTBF-Wert noch nicht erreicht ist, kann eine Komponente unter gewissen Umständen vorzeitig ausfallen, beispielsweise bei ungewöhnlichen Umwelteinflüssen, latenten Konstruktionsmängeln, unsachgemäßer Montage oder Fehlbedienung. Die Teile sollten daher regelmäßig, d. h. in periodischen Zeitabständen oder gar kontinuierlich, überwacht werden, um Probleme zu identifizieren und Wartungen durchzuführen. Es versteht sich, daß Diagnose und Wartung gemeinsam eine entscheidende Rolle spielen, wenn es darum geht, die Unversehrtheit der Zapfanlage zu gewährleisten und die Servicequalität der Komponenten beizubehalten.

Es ist daher notwendig, ein Diagnosesystem zu erstellen, das den Zustand und die Arbeitsweise der Komponenten kontinuierlich überwacht, und zwar auch dann, wenn der MTBF-Wert noch nicht erreicht ist. Ferner ist ein Wartungsprogramm erforderlich, um das Diagnoseprogramm zu ergänzen, so daß gewisse Schritte, wie Reparaturen oder Abstellen von Mängeln sowie andere Korrekturen vorgenommen werden können, um ein einwandfreies Arbeiten der beteiligten Komponenten sicherzustellen.

Was bisher bei Zapfeinheiten im allgemeinen ebenfalls fehlt, ist die Fähigkeit, selektiv die Zapfkomponenten zu beeinflussen, d. h. einzustellen oder zu regulieren, wie dies den Ergebnissen von Diagnosevorgängen entspricht. Solche Eingriffe können beispielsweise das Verändern eines Parameters einer Komponente beinhalten. Derzeitige Kontrollen sind beschränkt auf ein ganz bestimmtes Kontrollglied zwischen dem POS-Terminal und der Zapfstation; hierbei ist ein manuelles Sichten und Eingreifen notwendig. Es gibt keine zentralisierte oder automatisierte Möglichkeit, um die Kontrollen der verschiedenen Zapfpositionen automatisch zu koordinieren, zu überwachen und durchzuführen.

Es wäre bei einer Zapfanlage beispielsweise wünschenswert, durch einen Programmierer oder sonstiges Bedienungspersonal die Arbeitseigenschaften der Zapfeinrichtung selektiv zu modifizieren. Hierzu gehört beispielsweise das Verändern der Durchsätze von Kraftstoffpumpen und/oder -ventilen, oder von Abdampf-Rückgewinnungseinrichtungen. Die bei herkömmlichen Zapfanlagen verwendeten Vorkehrungen sind üblicherweise Routinekontrollen, die in EPROMS eingeschlossen sind. Dies macht es aber nicht praktikabel, Programmierwugs oder Software-Updates zu fixieren, weil dann nämlich die existierende EPROM gegen eine neue EPROM mit den gewünschten Software-Modulen ausgetauscht werden müßte. Der Konstrukteur betrachtet daher die bestehende Zapfanlage als statische Konfiguration ohne die Möglichkeit, Updates oder Rekonfigurationen periodisch durchzuführen.

Der Erfindung liegt daher die Aufgabe zugrunde, ein Management zu schaffen, das Software-bezogene Änderungen ermöglicht, ohne eine physischen Eingriff notwendig zu machen, um hierdurch die Software-bezogene Funktionalität zu verbessern und auszuweiten.

Weiterhin soll ein Netzwerk-Management geschaffen werden, das sich in eine Zapfanlage integrieren läßt und das Netzwerkoperationen erleichtert oder stützt, wie beispielsweise Rekonfigurationen der Profile von Einheiten, dynamisches Updaten der Kontrollprozesse und der Programm-Anweisungen sowie automatisches Software-Herabladen. Eine brauchbare Funktion eines solchen Management-Netzes beinhaltet die Fähigkeit des Rekonfigurierens der Betriebsparameter und der Software-Prozesse, die in den Einheiten laufen.

Es ist aber nicht nur notwendig, an einer Zapfanlage eine Möglichkeit einzurichten, um an Ort und Stelle Managementfunktionen zu schaffen, wie beispielsweise Diagnose, sondern es ist auch unerlässlich, daß dieses Merkmal einem universalen oder globalen "Administrator" einverleibt wird, der das gesamte System der Zapfanlage überblickt und überwacht. Diese Notwendigkeit hat sich im Zusammenhang mit der raschen Globalisierung des Handels herausgestellt. Die Expansion in neue geographische Märkte bedeutet, daß einzelne Geschäftseinheiten, wie Zapfstationen, nicht nur auf einen einzigen Inlandsmarkt beschränkt sind, sondern zunehmend ein internationales Geschäft berücksichtigen.

Hierzu ist es notwendig, eine administrative Möglichkeit zu schaffen, um von einem zentralen Punkt aus, die verschiedenen Managementaufgaben, die mit einer jeden Zapfsäule verbunden sind, zu bewältigen. Deshalb ist eine netzumfassende System-Managementfunktion notwendig, um die Vorgänge an zahlreichen Zapfeinrichtungen fernzusteuern, in Zusammenarbeit mit örtlichen Managementfunktionen.

Gemäß der Erfindung wird ein Verfahren, ein System sowie ein Computerprogramm geschaffen, um unterschiedliche Managementaufgaben in Bezug auf die Komponenten der Kraftstoff-Zapfpositionen zu bewältigen. Eine Betätigungseinheit (Agent Facility), die geeignete Softwareprozesse verwendet, ist derart konfiguriert, daß sie die Zapfpositionen überwacht, um Informationen über Vorgänge zu sammeln, daß sie Diagnoseoperationen ausführt bezüglich der Komponentendaten, die die Vorgangsinformationen begleiten, und daß sie entsprechende Wartungsvorgänge, je nach Ergebnis der Diagnoseergebnisse, ausführt.

Gemäß der Erfindung verarbeitet das Diagnosetestverfahren die vorgangsspezifische, variable Information gemäß dem erfassten Vorgang und den zugeordneten Komponentendaten. Die variable Handhabung wird üblicherweise als Datenverarbeitungsvorgang durchgeführt, beispielsweise auf der Basis eines variablen Wertes oder eines erfaßten Wertes, der dem erfaßten Vorgang zugeordnet ist. Die variable Information kann in Gestalt einer variablen Tabelle vorliegen, die eine Mehrzahl von aufgezeichneten Daten aufweist, die ihrerseits mit einem entsprechenden Vorgang oder Ereignis verbunden sind. Jede Aufzeichnung kann auch wichtige variable Werte oder erfaßte/berechnete Werte umfassen. Der Inhalt der variablen Tabelle kann auf jegliche geeignete Weise wiedergegeben werden.

Das Diagnosetestsystem verwendet ein regelgestütztes Bewertungsverfahren oder einen Algorithmus, der die verarbeitete/behandelte variable Information auf vorgangspezifische Regeln anwendet, die mit dem erfaßten Vorgang zusammenhängen. Diese Regeln können beispielsweise eine vergleichende Analyse bezüglich vorgegebener Bezugsmessungen oder andere geeignete entscheidungstypische Regeln enthalten.

Gemäß einer weiteren Konfiguration werden die Regeln in Gestalt einer Ereignis- oder Vorgangstabelle implementiert, umfassend eine Mehrzahl von Aufzeichnungen, deren jede einem entsprechenden Ereignis zugeordnet ist. Jede Aufzeichnung umfaßt beispielsweise Anweisungen bezüglich der Art des Datenverarbeitungsvorganges, der auszuführen ist, sowie Anweisungen von der Art des Bewertungsverfahrens, auszuführen bei den derart verarbeiteten Daten. Außerdem enthält jede Aufzeichung Anweisungen bezüglich der Art des Wartungsvorganges und/oder des Kontrollvorganges, die in Abhängigkeit vom Ergebnis der derart durchgeführten Bewertung durchzuführen sind.

Die "Agent Facility" weist zahlreiche Merkmale auf, die vorteilhaft sind. So kann die "Agent Facility" beispielsweise als Kundenmaschine konfiguriert werden, zur Anwendung bei einem Kunden-Server-Architekturmodell. Die variable Tabelle und die Tabelle der Vorgänge/Ereignisse sind am besten derart programmierbar, daß die Tabellen selektiv und justierbar wiedergegeben werden können. Auf diese Weise lassen sich beispielsweise die Diagnoseregeln abwandeln oder auf dem laufenden halten, um Änderungen der Benchmark-Bewertungskriterien zu berücksichtigen.

Die "Agent Facility" ist vorzugsweise an eine entfernte Station angeschlossen, die eine Managementanwendung aufweist, um ein Netz-Managementsystem zu errichten, das verschiedene Managementaufgaben und Verwaltungsdienste aus einem bestimmten Abstand vornimmt. Die Netz-Managementfunktionen umfassen Aufgaben wie das Konfigurieren der Kraftstoff-Zapfeinrichtung, Herabladen von Software-Updates, um Vorrichtungen und Prozessor-Komponenten an der Zapfstation zu kontrollieren, Überwachen des Status und der Arbeitsweise der Kraftstoff-Zapfeinrichtung bezüglich der Tankoperationen, Ausführen einer Diagnose und Ausführen von Entstörungen und anderen Problemen sowie das Einrichten oder Programmieren von Wartungsschritten sowie weitere Service- Aktivitäten entsprechend Diagnosebewertungen.

Die ferngelegene Managementstation führt ihre verschiedenen Netz- Managementfunktionen in Verbindung mit einer Mehrzahl bestimmter Software- Einheiten aus, deren jede an einer Zapfstation sitzt. Innerhalb eines Netz- Management-Rahmens wird die Kraftstoff-Zapfeinrichtung an den einzelnen Zapfstationen von der Management-Station als Netzobjekt oder -vorrichtung betrachtet.

Die Kommunikationsglieder zwischen der "Agent Facility" und den Zapfstationen sowie zwischen der "Agent Facility" und der ferngelegenen Management-Station können jegliche Art von Verbindungen sein, wie zum Beispiel ein "Packet-based Network" (beispielsweise das Internet), oder ein Hochgeschwindigkeitskommunikationsmedium großer Bandbreite (zum Beispiel Ethernet Link) unter Verwendung des standardisierten Transmission Control Protocol/Internet Protocol (TCP/IP).

Die erfindungsgemäße Lösung ist in den Ansprüchen definiert.

Die Regelfunktion umfaßt eine Mehrzahl von Regeln, deren jede einen bestimmten Ereignis zugeordnet ist. Jede Regel definiert jeweils: (i) eine diagnostische Funktion, die derart konfiguriert ist, daß sie einen Diagnosevorgang durchführt in Abhängigkeit von einer vom Prozessor verarbeiteten Information; (ii) eine Wartungsabrufoperation, die derart konfiguriert ist, daß sie wenigstens eine Wartungsaufgabe, die auf die Kraftstoffzapfstation bezogen ist, entsprechend den Ergebnissen der Diagnoseoperation ausführt und/oder einleitet; (iii) eine Kontrolloperation, die derart konfiguriert ist, daß sie wenigstens eine Kontrollaufgabe, die sich auf die Kraftstoffzapfposition bezieht, gemäß den Ergebnissen der Diagnoseoperation ausführt und/oder einleitet; oder (iv) jegliche Kombination von (i) bis (iii).

Das System kann ferner eine variable Tabelle umfassen sowie eine Ereignistabelle, die mit der "Agent Facility" in Wirkverbindung steht.

Die variable Tabelle umfaßt eine Mehrzahl von ereignisspezifischen Aufzeichnungen. Jede Aufzeichnung enthält jeweils (i) einen Ereignisanzeiger, der das jeweilige, hiermit verbundene Ereignis anzeigt, und (ii) eine variable Information, die sich auf das betreffende Ereignis bezieht.

Die Ereignistabelle beinhaltet eine Mehrzahl von ereignisspezifischen Aufzeichnungen. Jede Aufzeichnung umfaßt wenigstens eine der folgenden Positionen: (i) ein Ereignisfeld, das ein Ereignis anzeigt, das der Aufzeichnung zugeordnet ist; (ii) ein Aktionsfeld, das Instruktionen liefert, die eine Datenverarbeitungsoperation definieren, welche in Verbindung mit relevanter, variabler Information aus der variablen Tabelle durchzuführen ist; (iii) ein Testfeld, das Instruktionen liefert, die eine Analyseoperation zum Durchführen in Verbindung mit den Ergebnissen der Datenverarbeitungsoperation definiert; (iv) ein Testergebnisfeld, das einen vorgegebenen Testwert definiert zur Verwendung bei der Analyseoperation; und (v) ein Eskalations-Ereignisfeld, das Instruktionen liefert, die wenigstens eine Aufgabe definieren, welche in Abhängigkeit vom Ergebnis der Analyseoperation durchzuführen ist.

Das System kann weiterhin eine entfernte Station umfassen, umfassend eine Managementaufgabe. Diese entfernte Station (remote facility) ist in einem Abstand von der Kraftstoffzapfstation angeordnet. Die Managementstation ist derart konfiguriert, daß sie das Management wenigstens einer Komponente der Kraftstoffzapfstation in Zusammenarbeit mit der "Agent Facility" wahrnehmen kann. Zwischen "Agent Facility" und der entfernten Station ist ein Kommunikationsglied geschaltet.

Die Erfindung betrifft ferner ein System zur Anwendung bei einer Zapfanlage oder Tankanlage. Die Zapfanlage umfaßt eine Mehrzahl von Kraftstoffabgabeeinrichtungen (Zapfsäulen), deren jede eine entsprechende Anzahl von Komponenten aufweist. Das System umfaßt ein Managementsystem, derart konfiguriert, daß es ein operatives Management der Zapfanlage ermöglicht. Das Managementsystem umfaßt eine Managementanwendung in Kombination mit einer "Agent Facility". Die "Agent Facility" steht in einer Netz-Management- Konfiguration in Verbindung mit wenigstens einer Kraftstoff-Zapfeinrichtung.

Die Managementanwendung kann von der Zapfanlage und der "Agent Facility" innerhalb der Zapfanlage entfernt angeordnet sein.

Die Erfindung betrifft ferner eine Vorrichtung, die in Kombination eine Kraftstoff- Zapfstation und eine dieser zugeordneten "Agent Facility" umfaßt.

Die "Agent Facility" kann ferner in Kombination ein Mittel zum Aufnehmen von Ereignisinformationen aus der Kraftstoff-Zapfstation aufweisen, ein Diagnosetestprogramm, das an die Aufnahmeeinrichtung angeschlossen ist sowie ein Wartungsablaufprogramm, das dem Diagnosetestprogramm zugeordnet ist.

Die "Agent Facility" kann ferner in Kombination ein Mittel zum Aufnehmen von Ereignisinformationen von der Kraftstoff-Zapfstation umfassen, einen Datenprozessor, der an das Aufnahmemittel angeschlossen ist, und ein Datenanalysegerät, das an den Datenprozessor angeschlossen ist.

Die "Agent Facility" kann ferner in Kombination ein Mittel zum Aufnehmen von Ereignisinformationen von der Kraftstoff-Zapfstation aufweisen, eine Dateneinrichtung mit einer Mehrzahl von Informationselementen, deren jede einem entsprechenden Ereignis zugeordnet ist, einen Prozessor, der mit dem Aufnahmemittel und der Dateneinrichtung in Wirkverbindung steht sowie eine Regelstation, die Regeln enthält, und die mit dem Prozessor in Wirkverbindung steht (Rules Facility). Die Rules Facility beinhaltet eine Mehrzahl von Regeln, deren jede einem bestimmten Ereignis zugeordnet ist. Jede Regel enthält jeweils einen ersten Satz von ausführbaren Instruktionen, definierend ein Bewertungsverfahren, sowie einen zweiten Satz von ausführbaren Instruktionen, definierend eine Managementaufgabe. Die Managementaufgabe enthält eine ausführbare Regelaufgabe und/oder eine ausführbare Wartungsaufgabe.

Die "Agent Facility" kann ferner in Kombination ein Mittel zum Aufnehmen einer Ereignisinformation von der Kraftstoff-Zapfstation enthalten, eine Dateneinrichtung, die eine Mehrzahl von Informationselementen umfaßt, deren jedes einem entsprechenden Ereignis zugeordnet ist, einen Prozessor, der mit dem Aufnahmemittel und der Dateneinrichtung in Wirkverbindung steht, sowie eine Regeleinrichtung (Rules Facility), die mit dem Prozessor in Wirkverbindung steht. Die Rules Facility umfaßt eine Mehrzahl von Regeln, deren jede einem entsprechenden Ereignis zugeordnet ist. Jede Regel umfaßt jeweils (i) einen ersten Programmiercode, der eine Diagnoseoperation definiert, (ii) einen zweiten Programmiercode, der eine Wartungsoperation in Bezug auf die Kraftstoff- Zapfstation definiert, und (iii) einen dritten Programmiercode, der eine Kontrolloperation in Bezug auf die Kraftstoff-Zapfstation definiert.

Die Vorrichtung kann weiterhin ein Kraftstoff-Zapf-Kontrollprogramm aufweisen, das mit der "Agent Facility" in Wirkverbindung steht.

Die Vorrichtung kann weiterhin eine variable Tabelle und eine Ereignistabelle aufweisen, die mit der "Agent Facility" in Wirkverbindung stehen.

Die variable Tabelle umfaßt eine Mehrzahl von ereignisspezifischen Aufzeichnungen. Jede Aufzeichnung umfaßt jeweils (i) einen Ereignisanzeiger, der das hiermit verbundene jeweilige Ereignis anzeigt, und (ii) variable Informationen, die sich auf das jeweilige Ereignis beziehen.

Die Ereignistabelle umfaßt eine Mehrzahl von ereignisspezifischen Aufzeichnungen. Jede Aufzeichnung enthält jeweils wenigstens eine der folgenden Positionen: (i) ein Ereignisfeld, das ein mit der Aufzeichnung verbundenes Ereignis anzeigt; (ii) ein Aktionsfeld, das Instruktionen liefert, welche eine Datenverarbeitungsoperation definiert, umfassend variable Informationen von der variablen Tabelle; (iii) eine Testfeld, das Instruktionen liefert, die eine Analyseoperation in Verbindung mit den Ergebnissen der Datenverarbeitungsoperation definieren; (iv) ein Testwertfeld, das einen vorgegebenen Testwert zur Verwendung bei der Analyseoperation definiert; und (v) ein Escalation Event Field, das Instruktionen liefert, definierend wenigstens eine durchzuführende Aufgabe, abhängig vom Ergebnis der Analyseoperation.

Die Vorrichtung kann weiterhin eine entfernte Einrichtung mit einer Managementanwendung umfassen. Die entfernte Einrichtung (Remote Facility) befindet sich in einem räumlichen Abstand von der Kraftstoff-Zapfstation. Zwischen diesen beiden ist ein Kommunikationsglied geschaltet.

Die Erfindung betrifft ferner ein Verfahren zur Anwendung bei einer Kraftstoff- Abgabestation in Kombination mit einer Betätigungseinheit (Agent Facility). Gemäß diesem Verfahren erhält die Betätigungseinheit von der Kraftstoff- Zapfstation eine Information über die dortigen Abläufe (Event Information), verarbeitet sodann diese Information und bewertet sie schließlich.

Gemäß einer Ausführungsform der Erfindung führt die Betätigungseinheit eine Wartungsaufgabe und/oder eine Kontrollaufgabe entsprechend dem Ergebnis der Bewertung durch. Zusätzlich übermittelt die Betätigungseinheit die Vorgangsinformation und/oder die Bewertungsergebnisse an eine entfernte Station, die sich im Abstand von der Kraftstoff-Abgabestation befindet.

Die Betätigungseinheit kann weiterhin an die Kraftstoff-Abgabestation Steuerbefehle liefern, und zwar in Abhängigkeit von wenigstens einer Direktive, die von einer entfernten Station empfangen wurde, die ihrerseits in einem Abstand von der Kraftstoff-Abgabestation angeordnet ist. Die Betätigungseinheit kann außerdem wenigstens eine Managementaufgabe bezüglich der Kraftstoff- Abgabestation liefern, wiederum abhängig von wenigstens einer Instruktion von einer entfernten Managementanwendung, entfernt von der Kraftstoff- Abgabestation.

Das Verarbeiten beinhaltet das Definieren von ereignisspezifischen, variablen Informationen, das Zuordnen dieser variablen Informationen zu der Ereignisinformation und das Handhaben der variablen Information gemäß der Ereignisinformation. Der Handhabungsschritt beinhaltet das Justieren eines ereignisbezogenen, variablen und/oder ereignisbezogenen Zählers. Die ereignisbezogene Variable zeigt einen Betriebsparameter und/oder einen Betriebszustand der Kraftstoff-Abgabestation an, während der ereignisbezogene Zähler ein Maß für eine Zahl eines auftretenden Ereignisses ist.

Der Bewertungsschritt beinhaltet das Bestimmen der Zulässigkeit der verarbeiteten Ereignisinformation in vergleichender Beziehung zu einer Bezugsinformation. Alternativ kann der Bewertungsschritt das Durchführen einer auf einer Regel beruhenden Analyse der verarbeiteten Ereignisinformation beinhalten. Gemäß einer alternativen Ausführungsform beinhaltet der Bewertungsschritt die Schritte des Definierens einer Mehrzahl von ereignisspezifischen Regeln, das Erfassen eines Ereignisses, das auf der Ereignisinformation basiert, und von der Kraftstoff-Zapfstation kommt, sowie das Anwenden der verarbeiteten Ereignisinformation auf wenigstens eine von mehreren ereignisspezifischen Regeln, spezifiziert durch das erfaßte Ereignis.

Gemäß einer weiteren Ausführungsform beinhaltet der Bewertungsschritt das Erstellen einer variablen Tabelle, eingeschlossen eine Mehrzahl von ereignisspezifischen Aufzeichnungen sowie das Erstellen einer Ereignistabelle, die eine Mehrzahl von ereignisspezifischen Aufzeichnungen enthält; dabei definiert jede Ereignistabellenaufzeichnung ein ausführbares Bewertungsverfahren.

Jede variable Tabellenaufzeichnung beinhaltet jeweils (i) einen Ereignisanzeiger, der das zugeordnete jeweilig Ereignis angibt, und (ii) eine ereignisspezifische variable Information, die sich auf ein entsprechendes Ereignis bezieht.

Jede Ereignistabellenaufzeichnung beinhaltet jeweils eine der folgenden Positionen: (i) ein Ereignisfeld, das ein mit der Aufzeichnung verbundenes Ereignis anzeigt; (ii) ein Aktionsfeld, das Angaben liefert, definierend eine Datenverarbeitungsoperation zum Durchführen in Verbindung mit relevanter variabler Information der variablen Tabelle, wobei die Datenverarbeitungsoperation vom Ereignisinformationsverarbeitungsschritt benutzt wird; (iii) ein Testfeld, das Instruktionen liefert, die ihrerseits eine Analyseoperation definieren, zum Durchführen in Verbindung mit den Ergebnissen der Datenverarbeitungsoperation; (iv) ein Testwertfeld, das einen vorgegebenen Testwert zur Anwendung bei der Analyseoperation definiert; und (v) ein Escalation Event Field, das Instruktionen liefert, die wenigstens eine Aufgabe definieren, durchzuführen entsprechend dem Ergebnis der Analyseoperation.

Das Verfahren beinhaltet ferner den Schritt des Verwendens der Ereignistabelle und der variablen Tabelle, um die verarbeitete Ereignisinformation dadurch zu bewerten, daß ein von der Ereignisinformation angegebenes Ereignis einer relevanten, ereignisspezifischen Aufzeichnung der Ereignistabelle zugeordnet wird, wobei das entsprechende Bewertungsverfahren, definiert durch die relevante Ereignistabellenaufzeichnung, durchgeführt wird.

Die Erfindung bezieht sich weiterhin auf ein Verfahren zur Anwendung bei einer Kraftstoff-Zapfstation in Kombination mit einer Betätigungseinheit (Agent Facility). Gemäß diesem Verfahren erhält die "Agent Facility" eine Ereignisinformation von der Kraftstoff-Zapfstation. Sie führt sodann ein Diagnosetestverfahren in Bezug auf die von der Kraftstoff-Zapfstation erhaltene Ereignisinformation aus. Die Betätigungseinheit kann weiterhin eine Wartungsoperation und/oder eine Kontrolloperation in Bezug auf die Kraftstoff-Zapfstation durchführen, je nach den Ergebnissen des Diagnosetestverfahrens.

Gemäß einer weiteren Ausführungsform beinhaltet das Diagnosetestverfahren das Definieren einer Mehrzahl von ereignisspezifischen Regeln, das Erfassen eines Ereignisses, basierend auf der Ereignisinformation, die von der Kraftstoff- Zapfstation empfangen wurde; schließlich wird wenigstens eine der zahlreichen ereignisspezifischen Regeln, spezifiziert durch das erfaßte Ereignis, um die Ereignisinformation zu verarbeiten und/oder zu bewerten.

Der Schritt des Definierens einer Regel beinhaltet die Schritte des Erstellens einer variablen Tabelle, umfassend eine Mehrzahl von ereignisspezifischen Aufzeichnungen, sowie das Erstellen einer Ereignistabelle, umfassend eine Mehrzahl ereignisspezifischer Aufzeichnungen.

Gemäß einer weiteren Ausführungsform beinhaltet das Diagnosetestverfahren das Definieren ereignisspezifischer, variabler Informationen, das Zuordnen dieser Informationen zu den Ereignisinformationen und das Handhaben der variablen Information gemäß der Ereignisinformation sowie das Bewerten der behandelten variablen Information.

Die Erfindung betrifft weiterhin ein Computerprogramm zur Anwendung bei einer Betätigungseinheit (Agent Facility), aufweisend ein Computer-Umfeld. Die Betätigungseinheit ist einer Kraftstoff-Zapfstation operativ zugeordnet. Das Computerprogramm umfaßt ein computerfähiges Medium mit einem computerlesbaren Programmcode, handhabbar vom Computer-Umfeld. Der computerlesbare Programmcode beinhaltet in Kombination einen ersten Programmcode zum Verarbeiten von Ereignisinformation, empfangen von der Betätigungseinheit von der Kraftstoff-Zapfstation, sowie einen zweiten Programmcode zur Bewertung der verarbeiteten Ereignisinformation.

In einer weiteren Ausführungsform beinhaltet der computerlesbare Programmcode einen Programmcode zum Ausführen einer Wartungsaufgabe und/oder einer Kontrollaufgabe bezüglich der Kraftstoff-Zapfstation, entsprechend den Ergebnissen der vom zweiten Programmcode gelieferten Bewertung.

Gemäß einer weiteren Ausführungsform beinhaltet der lesbare Computer- Programmcode einen Programmcode zum Definieren einer Mehrzahl ausführbarer ereignisspezifischer Regeln, einen Programmcode zum Erfassen eines Ereignisses, basierend auf der Ereignisinformation, empfangen von der Kraftstoff- Zapfstation, und einen Programmcode zum Anwenden der verarbeiteten Ereignisinformation auf wenigstens eine relevante aus einer Mehrzahl von ereignisspezifischen Regeln, spezifiziert durch das erfaßte Ereignis, zwecks dessen Durchführung.

Das Computerprogramm kann weiterhin eine erste Dateneinrichtung aufweisen, umfassend eine variable Tabelle mit einer Mehrzahl ereignisspezifischer Aufzeichnungen, und eine zweite Dateneinrichtung, umfassend eine Ereignistabelle mit einer Mehrzahl ereignisspezifischer Aufzeichnungen. Jede Ereignistabellenaufzeichnung definiert jeweils ein ausführbares Bewertungsverfahren. Der zweite Programmcode beinhaltet ferner einen dritten Programmcode zur Verwendung der Ereignistabelle und der variablen Tabelle im Hinblick auf das Bewerten der verarbeiteten Ereignisinformation, und zwar durch Zuordnen eines von der Ereignisinformation angezeigten Ereignisses zu einer relevanten, ereignisspezifischen Aufzeichnung der Ereignistabelle, und sodann durch Ausführen des entsprechenden Bewertungsverfahrens, definiert durch die relevante Ereignistabellenaufzeichnung.

Jede variable Tabellenaufzeichnung beinhaltet jeweils (i) einen Ereignisanzeiger, der das jeweilige hiermit verbundene Ereignis anzeigt, und (ii) ereignisspezifische, variable Information, die das entsprechende Ereignis betrifft. Jede Ereignistabellenaufzeichnung beinhaltet jeweils wenigstens eine der folgenden Positionen: (i) ein Ereignisfeld, das ein mit der Aufzeichnung verbundenes Ereignis anzeigt; (ii) ein Aktionsfeld, das Instruktionen liefert, definierend eine Datenverarbeitungsoperation zum Durchführen in Verbindung mit der relevanten variablen Information von der variablen Tabelle; (iii) ein Testfeld, das Instruktionen liefert, definierend eine Analysenoperation, durchzuführen in Verbindung mit den Ergebnissen der Datenverarbeitungsoperation; (iv) ein Testwertfeld, definierend einen vorgegebenen Testwert zur Anwendung bei der Analyseoperation; und (v) ein Eskalationsereignisfeld (Escalation Event Field), das Informationen liefert, definierend wenigstens eine auszuführende Aufgabe, je nach dem Ergebnis der Analyseoperation.

Die Erfindung betrifft ferner ein Computerprogramm zur Anwendung bei einer Betätigungseinheit (Agent Facility) mit einem Computer-Umfeld. Die Betätigungseinheit steht in operativer Verbindung mit einer Kraftstoff-Zapfstation. Das Computerprogramm umfaßt ein computerverwendbares Medium mit einem computerlesbaren Programmcode, ausführbar von der Computer-Umgebung. Der computerlesbare Programmcode beinhaltet einen ersten Programmcode zum Definieren und Durchführen eines Diagnosetestverfahrens in Bezug auf Ereignisinformation von der Kraftstoff-Zapfstation.

Gemäß einer weiteren Ausführungsform beinhaltet der computerlesbare Programmcode weiterhin einen Programmcode zum Durchführen einer Wartungsoperation und/oder einer Kontrolloperation in Verbindung mit der Kraftstoff-Zapfstation entsprechend den Ergebnissen des Diagnosetestverfahrens, geliefert vom ersten Programmcode.

Gemäß einer alternativen Ausführungsform beinhaltet der erste Programmcode in Kombination einen Programmcode zum Definieren einer Mehrzahl ausführbarer ereignisspezifischer Regeln, eine Programmcode zum Erfassen eines Ereignisses, basierend auf der Ereignisinformation von der Kraftstoff-Zapfstation, sowie einen Programmcode, um zu Veranlassen, daß wenigstens eine relevante aus einer Mehrzahl ereignisspezifischer Regeln spezifiziert wird durch das erfaßte Ereignis, um die Ereignisinformation zu verarbeiten und zu bewerten.

Gemäß einer weiteren Ausführungsform beinhaltet der erste Programmcode in Kombination einen zweiten Programmcode zum Definieren ereignisspezifischer, variabler Informationen, einen dritten Programmcode zum Zuordnen der variablen Information zur Ereignisinformation, einen vierten Programmcode zum Handhaben der variablen Information gemäß der Ereignisinformation, und einen fünften Programmcode zum Bewerten der behandelten variablen Information.

Der vierte Programmcode kann einen Programmcode zum Justieren eines ereignisbezogenen, variablen Zählers und/oder eines ereignisbezogenen Zählers. Die ereignisbezogene Variable zeigt einen Betriebsparameter und/oder einen Betriebszustand der Kraftstoff-Zapfstation an, während der ereignisbezogene Zähler eine Zählung des Ereignisgeschehens anzeigt.

Das Computerprogramm kann ferner eine erste Dateneinrichtung enthalten, umfassend eine variable Tabelle mit einer Mehrzahl ereignisbezogener Aufzeichnungen, und eine zweite Dateneinrichtung mit einer ereignisbezogenen Tabelle, die eine Mehrzahl ereignisspezifischer Aufzeichnungen umfaßt. Jede Ereignistabellenaufzeichnung definiert jeweils ein ausführbares Bewertungsverfahren. Der erste Programmcode beinhaltet ferner eine Programmcode zur Nutzung der Ereignistabelle und der variablen Tabelle zwecks Verarbeitens und Bewertens der Ereignisinformation durch Zuordnen eines Ereignisses, angezeigt durch die Ereignisinformation zu einer relevanten ereignisspezifischen Ereignistabellenaufzeichnung, und anschließendes Durchführen des entsprechenden Bewertungsverfahrens, definiert durch die relevante Ereignistabellenaufzeichnung.

Jede variable Tabellenaufzeichnung beinhaltet (i) eine Ereignisanzeige bezüglich des entsprechenden, hiermit verbundenen Ereignisses, und (ii) eine ereignisbezogene, variable Information, die sich auf das entsprechende Ereignis bezieht.

Jede Ereignistabellenaufzeichnung beinhaltet dem gemäß wenigstens eine der folgenden Positionen: (i) ein Ereignisfeld zum Anzeigen eines mit der Aufzeichnung verbundenen Ereignisses; (ii) ein Aktionsfeld, das Instruktionen liefert, die eine Datenverarbeitungsoperation definieren, durchzuführen in Verbindung mit relevanter variabler Information der variablen Tabelle; (iii) ein Testfeld, das Instruktionen liefert, definierend eine Analyseoperation, auszuführen in Verbindung mit Ergebnissen der Datenverarbeitungsoperation; (iv) ein Testfeld, definierend einen vorgegebenen Testwert zur Verwendung bei der Analyseoperation und (v) ein Eskalationsereignisfeld (Escalation Event Field) zum Liefern von Instruktionen, definierend wenigstens eine Aufgabe, die je nach Ergebnis der Analyseoperation durchzuführen ist.

Ein Vorteil der Erfindung besteht darin, daß die auf der Zapfstation basierende Betätigungseinheit (Agent Facility) die Zapfstationen kontinuierlich überwachen und Diagnosetestverfahren sowie zugeordnete Wartungsaufgaben automatisch ausführen kann, so daß Servicepersonal diese Operationen nicht von Hand durchführen muß.

Ein weiterer Vorteil der Erfindung besteht darin, daß eine Funktionalität bei verschiedenen abwechselnden Konfigurationen durchführbar ist. Hierzu gehört beispielsweise das Einbeziehen der Betätigungsfunktion als positionsspezifischer Prozess in jede Zapfstation zum Überwachen der hiermit verbundenen Komponentenanordnung, das Einbetten der Betätigungsfunktion als komponentenspezifischen Prozess in jede Komponente, oder das Schaffen einer zentralisierten, zapfstationenspezifischen Betätigungseinheit für ein systemweites Management der Zapfstationen innerhalb einer Tankanlage.

Ein weiterer Vorteil der Erfindung besteht darin, daß die Betätigungseinheit bekannte Software-Module mit re-programmierbaren Merkmalen umfassen kann, so daß eine Selektivrekonfiguration der Regeln möglich ist, die die regelgestützten Bewertungsoperationen beim Diagnosetestverfahren definieren, so daß Änderungen der Benchmark-Bewertungskriterien angepaßt werden können.

Ein weiterer Vorteil der Erfindung besteht darin, daß der Einsatz einer Betätigungseinheit (Agent Facility) das Entwickeln eines netzgestützten Management-Systems ermöglicht, wobei die einzelnen Zapfstationen als Objekte des Management behandelt werden und die Betätigungseinheit mit einer entfernten Einheit zusammenwirkt, die ihrerseits eine Management-Aufgabe oder Anwendung löst. Hierdurch ist es möglich, Standard-Managementverfahren anzuwenden, beispielsweise gemäß dem Simple Network Management Protocol (SNMP).

Ein weiterer Vorteil der Erfindung besteht in einer verbesserten Zuverlässigkeit, Dauerhaftigkeit und Wartungsfähigkeit der Komponenten, da die Betätigungseinheit sicherstellt, daß die gesamte Einrichtung eine entsprechende Wartung erfährt. Hierdurch bekommt man Garantie- und Reparaturkosten in den Griff und verbessert die Wirtschaftlichkeit der gesamten Tankanlage.

Ein weiterer Vorteil der Erfindung besteht darin, daß die Betätigungseinheit als Bestandteil eines globalen Management-Systems fungieren kann, wobei eine entfernte Einheit die Operationen der verschiedenen Betätigungseinheiten, die zu einem umfassenden Netz von Tankstellen gehört, überwachen, steuern oder anderweitig koordinieren kann.

Ein weiterer Vorteil der Erfindung besteht darin, daß die Betätigungseinheit als Fern-Management-Anwendung einsetzbar ist, um eine Vielzahl von Managementfunktionen durchzuführen, beispielsweise das Überwachen des Betriebes sowie des laufenden Status der Zapfeinrichtung, das Herunterladen von Software-Updates sowie das routinemäßige Rekonfigurieren, das Beseitigen von Störungen und das Durchführen von Diagnoseoperationen, basierend auf Daten der Anlage, die von der Zapfstation heruntergeladen wurden, und das Einplanen von Service- und Wartungsarbeiten, je nach Ergebnis der Diagnose. Schließlich ist das Koordinieren von Managementaufgaben zu nennen; hiermit lassen sich gleichzeitig Managementaufgaben an den einzelnen Zapfstationen bewältigen.

Ein weiterer Vorteil der Erfindung besteht darin, daß Standard-Netzmanagement-Tools verwendet werden können. Die Zapfstationen lassen sich nämlich in eine Netz-Konfiguration einbinden, wobei die einzelnen Zapfkomponenten (z. B. programmierbare Ventile und Kraftstoffpumpen) als Netz-Elemente betrachtet werden, die ein Fern-Management steuern kann.

Ein weiterer Vorteil der Erfindung besteht darin, daß das Management-System rasch adaptiert werden kann zum Anschluß an irgendein Netz (beispielsweise an das Internet oder an ein weltweites Netz), unter Verwendung bekannter Netz- Verbindungs-Tools, so daß Zugang zu einem praktisch unbegrenzten Benutzerkreis online sowie zu Netz-Resourcen (z. B. Servern) gewonnen wird.

Die Erfindung ist anhand der Zeichnungen näher erläutert. Darin ist im einzelnen folgendes dargestellt:
Fig. 1 ist ein Blockschaltbild, das eine Zapfanlage veranschaulicht, umfassend eine ortsspezifische Betätigungseinheit (Agent Facility).
Fig. 2 ist ein Blockschaltbild einer Zapfanlage mit komponentenspezifischen Agent Facilities gemäß einem weiteren Ausführungsbeispiel der Erfindung.
Fig. 3 ist ein Blockschaltbild, das eine Komponentenkonfiguration wiedergibt zur Anwendung mit der Agent Facility Konstruktion gemäß Fig. 1 - gemäß einer weiteren Ausführungsform der Erfindung.
Fig. 4 ist ein Blockschaltbild, das eine Konfiguration der in Fig. 1 dargestellten Agent Facility Konstruktion wiedergibt - als weiteres Ausführungsbeispiel der Erfindung.
Fig. 5 ist ein Blockschaltbild, das eine weitere Konfiguration der in Fig. 1 dargestellten Agent Facility Konstruktion zeigt - gemäß einem weiteren Ausführungsbeispiel.
Fig. 6 ist ein Fließschema, das einen Ablauf der Operationen der Erfindung zeigt.
Fig. 7 ist ein Blockschaltbild eines globalen Zapf-Management-System zum Einbinden in das Netz einer zentralen Systemverwaltung mit mehreren Zapfanlagen, die bestimmte Agent Facilities aufweisen - gemäß einem weiteren Gedanken der Erfindung.
Entsprechende Teile sind in den einzelnen Figuren mit gleichen Bezugszeichen versehen.
Die in Fig. 1 dargestellte Zapfanlage 8 umfaßt Zapfstationen 12, die jeweils mit einer Mehrzahl von Komponenten 14 ausgestattet sind. Jede Zapfstation 12 kann einen Zapf- oder Tankvorgang ausführen und beispielsweise ein Fahrzeug auftanken. Zu diesem Zweck können die Zapfstationen 12 jeweils eine Mehrzahl von Komponenten 14 umfassen, die den Zapfvorgang erleichtern.
Gemäß einem Ausführungsbeispiel der Erfindung dient eine Agent Facility 10 zum Anschluß an Zapfstationen 12 und steht daher mit diesen in Verbindung - außerdem mit zugeordneten Komponenten. Das Verbindungsglied zwischen der Agent Facility 10 und den Zapfstationen 12 erlaubt bidirektionale Verbindungen, z. B. die Übertragung und den Empfang von Daten und Steuersignalen. Jede Betätigungseinheit (Facility) führt eine Reihe von Managementfunktionen in Bezug auf die Zapfstationen 12 aus, insbesondere im Hinblick auf das Überwachen und Kontrollieren der zugeordneten Komponenten 14. Außerdem ist die Agent Facility 10 an wenigstens eine Operator-Facility an Ort und Stelle angeschlossen, beispielsweise an ein POS-Terminal 16. Jedoch ist auch ein Anschließen an eine andere Einheit innerhalb der Zapfanlage 8 möglich.
Die Management-Operationen einer Agent Facility 10 enthalten beispielsweise das Überwachen des augenblicklichen Status sowie die Arbeitsweise der Zapfstationen 12, das Sammeln oder sonstige Aufnehmen von Ereignis- Informationen der Zapfstationen 12, das Durchführen von Diagnosetests über ereignisbezogene Informationen sowie das Leiten der Durchführung von Korrekturen in Abhängigkeit der Ergebnisse der Diagnosetests. Derartige Korrekturen haben die Gestalt einer Wartungsaufgabe oder einer Kontrollaufgabe (z. B. das Regeln des Verhaltens einer Zapfkomponente durch Justieren eines Betriebsparameters). Die von Agent Facility 10 durchgeführte Management- Tätigkeit kann auch Routinemaßnahmen und Verfahren jeglicher Art beinhalten, insbesondere dann, wenn die Agent Facility 10 in einer Computer Plattform angeordnet ist, mit einer Mehrzahl von re-programmierbaren Merkmalen, so daß die Management-Politik verändert oder auf einen neuen Stand gebracht werden kann.
Die in Gestalt von Agent Facility 10 implementierte Management-Politik funktioniert in Zusammenarbeit mit Ereignissen, die bei der Zapfanlage 8 auftreten, besonders in Verbindung mit einzelnen Komponenten 14. Die Agent Facility 10 nimmt somit eine Ereignis-Information auf, umfassend die Identifizierung eines Ereignisses, sowie zugehörende ereignisspezifische Information. Jede Facility 10 verwendet das Ereignis-ID sowie ereignisbezogene Daten, um entsprechende Diagnosetests durchzuführen, und leitet sodann eine korrigierende Operation ein, basierend auf den Diagnosetestergebnissen.
Wie in Fig. 1 ferner gezeigt, koordiniert die einzelne Agent Facility 10 die verschiedenen Managementaufgaben, die den einzelnen Zapfstationen 12 zugeordnet sind, oder handhabt anderweitig derartige Aufgaben. Die einzelnen Zapf-spezifischen Managementaufgaben werden parallel zueinander gelöst, was die Agent Facility 10 dazu in die Lage versetzt, mehrere Zapf-spezifische Managementaufgaben gleichzeitig oder zeitlich überlappend durchzuführen. Zu jeder Zapfstation 12 arbeitet die Agent Facility 10 als gegebene Einheit, da die anderen Zapf-Managementaufgaben bezüglich der Zapf-Position transparent sind.
Die Agent Facility 10 schafft eine systemweite oder ortsgebundene Funktionalität, wobei die Agent-Managementaufgaben, die den Zapfstationen 12 zugeordnet sind, innerhalb einer einzigen Einheit, nämlich der Agent Facility 10, zentralisiert sind. Diese Zentralisierung erlaubt es einer einzigen Host-Plattform, in Gestalt der Agent Facility 10, Zugriff auf die Zapfkomponenten 14 zu nehmen und an diesen Managementaufgaben auszuführen. Hierdurch wird das Fern-Management der Zapfstationen 12 weiterhin erleichtert, da die Management-Anwendung 18 lediglich mit der Agent Facility 10 kommunizieren muß, um Zugang zum gesamten Sammeln der Objekte des Managements zu erlangen, d. h. zu den Zapfstationen 12.
Gemäß einer Ausführungsform der Erfindung ist die Management-Facility 10 einer Management-Anwendung 18 operativ zugeordnet, die an einer entfernten Einheit 20 angeordnet ist, um ein umfassendes Netz-Management-System zu schaffen. Auf diese Weise läßt sich die gesamte Anordnung der Kraftstoff-Zapfausrüstung erkennen und anderweitig durch die Management-Anwendung 18 als Konfiguration von dem Management unterliegenden Netz-Vorrichtungen betrachten. Die Management-Anwendung 18 braucht daher nicht auf einen bestimmten Kunden zugeschnitten oder speziell angepaßt zu sein zur Anwendung beim Managen der Kraftstoff-Zapfausrüstung. Die vorliegende Erfindung erlaubt stattdessen die Anwendung von Standard-Netz-Management-Tools, Modulen und Paketen. Eine ferne Einheit 20 (Remote Facility) ist typischerweise in einem Abstand von der Zapfanlage 8 angeordnet, kann jedoch auch an einer anderen geeigneten Stelle angeordnet sein.
Als Bestandteil eines solchen Netz-Management-Systems arbeitet Agent 10 in Zusammenarbeit mit der Management-Anwendung 18, um ein Fern-Management der Zapfstationen 12 zu stützen. Dies kann beispielsweise bei den folgenden Funktionen geschehen: Abgeben von Wartungsanforderungen an ein Service Center, das über die Fern-Einheit 20 zugänglich ist, Hochladen von Diagnose- und Überwachungsinformationen zur Management-Anwendung 18 zwecks weiterer Analyse und Archivierung, Antworten auf Befehle und andere Anforderungen, die von der Management-Anwendung 18 ausgehen (z. B. Geben von Anweisungen zum Implementieren einer Komponenten-Rekonfiguration), und Aufnehmen von Software-Herabladungen zwecks Updating der Software-Plattform von Agent 10.
Gemäß einer Ausführungsform der Erfindung stellt Agent 10 eine Abstraktion von Resourcen dar und läßt sich daher auf eine vielfältige Weise implementieren. Agent 10 kann beispielsweise implementiert werden in Gestalt einer Routine eines Algorithmus oder eines Verfahrens (z. B. einer Software-Anwendung) oder als eingebetteter Code (z. B. eine sogenannte Firmware oder ein logistische Schaltung). Zusätzlich kann Agent 10 bleibender Bestandteil einer Computereinrichtung sein, einer Speichereinheit (z. B. einer programmierbaren ROM), eines Computerumfeldes oder anderer Vorrichtungen. Es kann beispielsweise ausreichend sein, Agent 10 in eine Form zu implementieren, die ganz einfach als eine Art von Informationsmakler fungiert, Vermittler, oder geeignetes Interface zwischen Netz-Management-Tool (d. h. der Management- Anwendung) und der gemanagten Vorrichtung (d. h. der in der Tankanlage 8 dargestellten Einrichtung).
Gemäß einer Ausführungsform ist Agent 10 derart gestaltet, daß er SNMP (Simple Network Management Protocol) unterstützt. Wie bekannt, definiert SNMP die Art und Weise, in welcher SNMP-Management-Anwendungen (wie beispielsweise Management-Anwendung 18) mit SNMP-Agents kommunizieren, um Daten, Befehle, Anforderungen, Instruktionen, Antworten, Anfragen und andere Informationen im Rahmen des Ausführens verschiedener Managementfunktionen zu erleichtern.
Auf "Newton's Telecom Dictionary" von Harry Newton, veröffentlicht durch Miller Freeman Inc., New York, (Februar 1999) wird verwiesen. Hierdurch werden weitere Beschreibungen von Netzwerk-Merkmalen gegeben.
Die Erfindung läßt sich natürlich auch durchführen und anderweitig implementieren gemäß konventioneller Kommunikations- und Managementprozesse, Protokolle und/oder Anwendungen, zusätzlich zu SNMP.
Die dargestellte Management-Anwendung 18 (und die zugeordnete, entfernt befindliche Einheit 20) stellen ein umfassendes System von Verfahren, Prozessen, Software, Einrichtungen und Funktionen dar, um verschiedene Managementaufgaben in Bezug auf die Tankanlage 8 zu erleichtern und durchzuführen. Die Management-Anwendung 18 kann beispielsweise eine Software-Anwendung beinhalten, angeordnet an oder in einem Computer, der die Netzeinrichtung mit Unterstützung von Agent 10 managt (beispielsweise die Hardware/Software-Ausrüstung, veranschaulicht durch die Komponenten 14).
Die durch die Management-Anwendung 18 ausgeführten Funktionen können beispielsweise die Überwachung des Betriebes und des aktuellen Status der Tankanlage beinhalten, unter Verwendung von Informationen, die von Agent 10 geliefert wurden, das Herabladen von Software-Updates an Agent 10, das Rekonfigurieren der Zapfeinrichtungen in Zusammenarbeit mit Agent 10, das Entstören sowie Diagnoseoperationen, basierend auf Daten der Einrichtungen, heraufgeladen von der Zapfstation über Agent 10, das Einplanen von Wartungsarbeiten in Abhängigkeit von der Diagnosebewertung oder auf Anforderung von Agent 10 im Anschluß an einen von Agent 10 durchgeführten Diagnosetest, sowie weiteres Warten und Kontrollieren der Zapfstation-Operationen.
Eine bevorzugte Ausführungsform ist die ferninstallierte Einheit 20, derart konfiguriert, daß sie konkurrierend Managementaufgaben erledigen kann, die mehrfach-Tankanlagen 8 betreffen.
Fig. 2 zeigt ein Blockschaltbild einer Station 22. Hierbei umfaßt jede Zapfkomponente einen bestimmten, an Ort und Stelle befindlichen Agent 24, als weitere Ausführungsform der Erfindung.
Die in Fig. 2 gezeigte Konfiguration stellt eine Alternative zu jener gemäß Fig. 1 dar. Wie oben erwähnt, zeigt Fig. 1 eine Anordnung, bei welcher ein einziger Agent 10 ein zentralisiertes Management mehrerer Zapfstationen 12 besorgt. Auf diese Weise sorgt Agent 10 für eine den Ort betreffende Management-Funktion, bei welcher er Management-Leistungen erfüllt, eingeschlossen die gesamte Ausrüstungsinstallation der Zapfanlage 8.
Im Vergleich hierzu beschreibt Fig. 2 eine aufgeteilte Agent-Funktion, bei welcher jede Komponente (oder wenigstens eine Zapfkomponente) einer Zapfstation einen bestimmten installierten Agent 24 aufweist, der derart konfiguriert ist, daß er komponentenspezifische Managementaufgaben löst. Was die Management- Eigenschaften anbetrifft, so arbeitet Agent 24 in gleicher Weise wie die Agent Facility 10 gemäß Fig. 1.
Wie gezeigt, vermag Agent 24 mit der dargestellten Komponenten-Plattform 26 zu kommunizieren, die ihrerseits einen Mikroprozessor 28, eine Regler 30, einen Speicher 32 und eine I/O-Schaltung 34 aufweist. Die Komponenten-Plattform 26kann jegliche herkömmliche Anordnung aufweisen. Fig. 2 zeigt zwar die Komponenten-Konfiguration, die eine dargestellte Zapfstation 22 betrifft. Andere Zapfstationen der Zapfanlage könnten natürlich ähnlich oder gleich aufgebaut sein.
Die Zapfanlage kann wahlweise ein an Ort und Stelle befindliches Management- Modul (SMM) 36 umfassen, beispielsweise als Kundenmaschine. SMM 36 dient als Interface zwischen den Zapfstationen (insbesondere die Schar von komponentenspezifischen Agents 24), und einer im Abstand angeordneten Einheit, wie einem Server, einer Management-Anwendung und/oder einem Systemadministrator. SMM 36 kann weiterhin an anderen Einheiten der Zapfanlage angeschlossen sein, beispielsweise an eine Betriebsposition, z. B. an ein POS-Terminal.
Fig. 3 zeigt ein Blockschaltbild einer Komponentenkonfiguration zur Anwendung bei der Agent Facility Gestaltung gemäß Fig. 1 als weiteres Ausführungsbeispiel.
Auf der Seite der Zapfstation ist Agent Facility 10 an eine periphere Zapfeinheit 38 angeschlossen, und zwar zum Erleichtern einer Zapfoperation, die vom Kunden abgerufen wird. Die durch die Einheit 38 veranschaulichte Komponentenkonfiguration ist jedoch nur beispielshalber. An der Zapfstation können auch andere Komponenten und Untereinheiten angeordnet und über das Netz an Agent Facility 10 angeschlossen sein, so daß zugeordnete Managementaufgaben durch die Agent Facility 10 gesteuert werden.
Die dargestellte Einheit 38 ist von konventioneller Gestalt. Sie umfaßt eine zapfbezogene Untereinheit, beispielsweise umfassend ein Leistungsmanagement-Modul 40 (Power Management Module), ein Zapf-Interface 42, das ein Benutzer- kompatibles Interface für die Einrichtung schafft, ein Hauptcomputer-Board 44, das die Computerfunktionen der Zapfstation anzeigt, eine Systemlevel-Vorrichtung 46, die autorisierten Eingang und Zugriff zu Sicherheitsabteilen ermöglicht und eine systemweite Aktivierung ("boot-up") der Dispenser Station erleichtert, ein Kraftstoff-Kontroll-Modul 48, eine Dampf-Rückgewinnungsvorrichtung 50, eine Temperatur-Kontrolle 52 (wie z. B. eine ATC-Sonde), einen Zapfregler 54 sowie zahlreiche Kommunikationsschaltungen 46, die erforderlich sind, um die Vorrichtungen gemäß den herkömmlichen Anforderungen miteinander zu verbinden.
Die Einheit 38 kann ferner verschiedene periphere oder Hilfskomponenten umfassen, beispielsweise eine Schalttafel oder ein Tastenfeld 58, eine Kartenleser 60, der mit Daten-encodierten Karten (z. B. Kreditkarten oder Debitkarten) kommuniziert, ein Display 62, einen Drucker 64 und eine Radiofrequenz- Identifikationseinrichtung 66 (RFID), beispielsweise als Transceiver konfiguriert, um den Datentransfer zwischen einem Kunden-Transceiver und einem Zapf-Transceiver über ein drahtloses Glied zu ermöglichen.
Einheit 38 kann ferner ein herkömmliches Benutzerinteraktives Zahlungsterminal 68 umfassen. Dieses ermöglicht es einem Kunden, einen Zapfvorgang abzurufen, die Zahlungsweise zu wählen, eine Zahlungsinformation zu übermitteln, Art, Zusammensetzung und Menge des Kraftstoffes zu wählen, Käufe jenseits des Kraftstoffes zu tätigen, und auf Anfragen durch POS-Personal zu antworten.
Ein geeigneter Interface-Mechanismus 70 herkömmlicher Art lässt sich wahlweise verwenden, um eine Verbindung zwischen den verschiedenen Vorrichtungen der Einheit 38 und der Plattform, auf welcher Agent Facility 10 implementiert ist, zu erleichtern. Ein solcher Interface-Mechanismus 70 kann beispielsweise eine geeignete Bus-Topologie und geeignete Interface-Schaltungen umfassen, um die Einheit 38 mit dem Agent 10 dann zu verbinden, wenn eine Comuter-Umgebung Agent 10 aufnimmt.
Auf der Seite der Bedienungsposition kann Agent 10 an ein POS-Interface 72 angeschlossen sein, das innerhalb eines POS-Terminal-Umfeldes konfiguriert ist.
Agent 10 kann ferner an eine Managereinheit 74 angeschlossen sein, die beispielsweise zentralisierte und auf den Ort bezogene POS-Funktionen der Tankanlage ausführt. Die Managereinheit 74 kann beispielsweise Transaktionsvorgänge sämtlicher Zapfstationen sammeln und Software- Downloads zur Verteilung an die Betreiberpositionen (z. B. POS-Terminals) über Agent 10 liefern.
Gemäß einem Merkmal der Erfindung überwacht Agent 10 die Komponenten und Vorrichtungen innerhalb der Zapfanlage (d. h. an der Bedienungsseite und der Zapfseite), um die Anwesenheit von Ereignissen zu erfassen, die innerhalb oder in Verbindung mit den relevanten Zapfstationen und POS-Terminals ablaufen. Anzeigen sowie sonstige Wiedergaben dieser Ereignisse oder Vorkommnisse werden Agent 10 in Gestalt von Ereignis-bezogenen Nachrichten 80 eingegeben.
Solche Ereignis-bezogenen Nachrichten werden im Rahmen der vorliegenden Ausführungen dahingehend verstanden, dass sie jegliche Kommunikation beinhalten, die von der Zapfstation empfangen wurde und die eine Anzeige eines Ereignisses und/oder einer hierauf bezogenen Information beinhaltet. Der Ereignisanzeiger kann jegliche Form haben. Er kann beispielsweise als Code vorliegen, der von Agent 10 erkennbar ist, und der Agent 10 übermittelt wird. Der Code gibt beispielsweise einen entsprechenden Zustand der relevanten Einrichtung, d. h. der Komponente, wieder.
Der Ereigniscode (event code) ist üblicherweise von Event-Information begleitet, die sich auf das Ereignis bezieht. Zeigt beispielsweise ein Eventcode das Auftreten eines Ereignisses an (z. B. geringe Leistung, schlechte Stromversorgung), so geben die zugeordneten Event-Daten den Wert eines Event-bezogenen Parameters wieder (z. B. den tatsächlichen Wert der Leistungsabgabe). Die Art und Weise des Übertragens dieser Information zu Agent 10 lässt sich durch bekannte Mittel durchführen.
Ein Eventindikator kann ganz einfach in den Event-bezogenen Daten enthalten sein. So kann beispielsweise dem Empfang eines Parameters wie einer Leistungsabgabe eine vorläufige Wert-Prüfung folgen, um festzustellen, dass ein Ereignis eingetreten ist, nämlich ein Zustand niedriger Leistung. Der Parameterwert selbst zeigt das Auftreten eines Ereignisses an.
Der Empfang und das Sammeln von Ereignis-bezogenen Nachrichten kann auf jegliche bekannte Weise stattfinden. So kann beispielsweise Agent 10 interaktiv den Status, die Arbeitsweise oder die Reihenfolge der Arbeitsschritte von Komponenten überwachen, und zwar auf jeglicher zeitlicher Basis, d. h. beispielsweise kontinuierlich, periodisch und/oder regelmäßig in vorgegebenen Zeitintervallen. Auf diese Weise erfasst Agent 10 aktiv die Zapfstation- Komponenten, um die Tankanlage bezüglich des Auftretens von Ereignissen zu überwachen. Agent 10 kann beispielsweise eine Befragung der Zapfstation vornehmen, um zu ermitteln, ob irgendwelche überwachbaren Ereignisse stattgefunden haben. Gegebenenfalls fordert Agent 10 die Übertragung der relevanten Ereignis-bezogenen Nachricht an.
Alternativ lassen sich die Zapfstations-Komponenten programmieren oder anderweitig konfigurieren, um automatisch an Agent 10 Ereignis-Meldungen weiterzugeben, im Anschluss an das Auftreten eines entsprechenden Ereignisses, ohne jeglichen Anstoß durch Agent 10. Zum Zwecke des Übermittelns von Ereignis-Nachrichten an Agent 10 sind die Zapfstations-Komponenten mit entsprechenden Einrichtungen ausgerüstet, die bestens bekannt sind, um Ereignis-Anzeiger und Ereignis-bezogene Daten zu Agent 10 übertragen zu können, entweder von selbst oder auf Anforderung. Ein geeignetes Software- Verfahren kann derart gestaltet werden, dass es eine Ereignis-Nachricht bildet, und zwar durch Sammeln von Ereignis-Anzeigen mit Ereignis-bezogenen Daten, sobald ein Ereignis aufgetreten ist. Die Komponenten können ferner mit entsprechenden Einrichtungen ausgestattet sein, um zu ermitteln, ob ein Ereignis aufgetreten ist.
Jegliche Art von Ereignis kommt hierbei in Betracht, beispielsweise jeglicher Umstand, jegliches Szenario, jeglicher Status oder jegliche Situation, die in Verbindung mit der Zapfanlage auftreten kann. Die Definition eines Ereignisses kann dem Benutzer überlassen werden und ist daher modifizierbar. Ein Zustand niedriger Leistung lässt sich beispielsweise in Gestalt eines entsprechenden Spannungswertes definieren, der unterhalb eines unteren Grenzwertes liegt oder der anderweitig nicht gewisse Kriterien erfüllt. Die Definition dieses Ereignisses lässt sich jedoch ändern durch Justieren des unterst zulässigen Spannungswertes. Eine solche Justierung lässt sich mit jeglichen bekannten Mitteln durchführen, beispielsweise durch Re-Programmieren von Benutzer- definierten Ereignis-Definitionen, die in Programmcode-Anweisungen enthalten sind.
Ein auftretendes Ereignis lässt sich in Bezug auf verschiedene Einzelheiten, Merkmale, Umstände und/oder Charakteristika der Tankanlage definieren. So kann ein Ereignis, sobald es auftritt, beispielsweise einer Konfiguration, einem Status, einem Zustand, einem Verhalten, Eingangs-/Ausgangs-Variablen, Betriebsparameter, Arbeitsparameter oder einer Kombination hieraus in Bezug auf ein Gerät oder ein Verfahren zugeordnet werden. Zusätzlich lassen sich Ereignisse als mehrdimensionale Szenarien definieren, wobei mehrere Unter- Ereignisse auftreten können, um ein bestimmtes Parentalereignis zu erzeugen.
Im folgenden soll auf Fig. 4 eingegangen werden. Das dort dargestellte Blockschaltbild zeigt eine Agent-Architektur 100 zum Implementieren einer Agent Facility 10 gemäß Fig. 1 als weiteres Ausführungsbeispiel der Erfindung.
Die veranschaulichte Agent-Architektur 100 beinhaltet einen Agent-Computer 98, eine Diagnoseeinheit 102, eine Wartungseinheit 104, eine Regel- und/oder Steuereinheit 106 und eine Dateneinheit 96. Agent-Architektur 100 umfasst ferner einen Prozessor 108, einen Ereignisdetektor 110, eine I/O-Schaltung 112 sowie eine Einrichtung 114 für variable Informationsdaten, umfassend Zähldaten 116 und variable Daten 118. Jegliche Kombination von Hardware, Software, firmeneigener Hard- oder Software sowie eine logische Schaltung lassen sich verwenden, um die Agent-Architektur 100 zu implementieren.
Die dargestellte Diagnoseeinheit 102 beinhaltet eine Diagnoseeinrichtung 120, ein Diagnosetestverfahren 122, ein Datenverarbeitungs-Instruktionsmodul 124 sowie ein Regelwerk gestütztes Bewertungsinstruktionsmodul 126. Die Diagnoseeinheit 102 führt im allgemeinen ein Ereignis-bezogenes Diagnosetestverfahren in Abhängigkeit auf Diagnose-Information aus, empfangen von einer Zapfstation. Zu diesem Zwecke definiert das Diagnosetestverfahren 122 eine Mehrzahl von Diagnoseroutinen, deren jede einem entsprechenden Ereignis zugeordnet ist. Diese Routinen lassen sich beispielsweise in Gestalt geeigneter Software-Codes implementieren.
Gemäß einer bestimmten Ausführungsform ist jede Ereignis-spezifische Diagnoseroutine, dargestellt im Diagnosetestverfahren 122, von einer Ausgangsdaten-Verarbeitungsoperation definiert, gefolgt von einer Bewertungsoperation. Zu diesem Zwecke beinhaltet das Diagnosetestverfahren 122 eine erste Software-Code-Subeinheit (d. h. ein Datenverarbeitungs- Instruktionsmodul 124) sowie eine zweite Software-Code-Subeinheit (d. h. ein Regelwerk gestütztes Bewertungsinstruktionsmodul 126), um Instruktionen zu liefern, die dazu geeignet sind, Datenverarbeitungsoperationen bzw. Bewertungsoperationen auszuführen.
Die Diagnoseeinheit 120 stellt ein geeignetes Interface mit Agent-Computer 98 bereit und erleichtert die Durchführung einer geeigneten Diagnosetestroutine, bestimmt durch den Ereignisanzeiger. Zu diesem Zweck wird die Diagnoseeinheit 120 derart konfiguriert, dass sie den Betrieb oder Lauf des Diagnosetestverfahrens 122 dirigiert (und damit die Module 124 und 126), beispielsweise durch Aufrufen der betreffenden Ereignis-spezifischen Testroutine innerhalb des Diagnosetestverfahrens 122.
Zahlreiche Datenverarbeitungsoperationen sind in Datenverarbeitungs- Instruktionsmodul 124 enthalten, zur Durchführung eines Diagnosetests. So lassen sich beispielsweise in Kombination mit Dateneinheit 96 Datenmanipulationen auf Zählerdaten 116 und variablen Daten 118 durchführen, zugeordnet der variablen Informationsdateneinheit 114. Zu diesem Zweck ist die Dateneinheit 96 mit Ereignis-spezifischen variablen Informationen durch Zähldaten (count data) 116 und variable Daten 118 definiert.
Count data 116 gibt Ereignis-spezifische Zählwerte wieder, die justiert werden (z. B. reset, incremented, decremented), gemäß den jeweiligen Datenverarbeitungsinstruktionen der betreffenden Diagnosetestroutine. Variable Daten 118 geben Ereignis-spezifische variable Werte wieder, die entsprechend den jeweiligen Datenverarbeitungsinstruktionen der betreffenden Diagnosetestroutine justiert werden. Die Justierung der variablen Datenwerte findet üblicherweise als Funktion der Ereignis-bezogenen Daten statt, wendet sodann gewisse Ereignis-spezifische Eingangsdaten an (dies sind Ereignis- spezifische variable Informationen) auf ausgewählte Kombinationen von Datenmanipulationsoperationen zum Erzielen Ereignis-spezifischer, bearbeiteter Daten, die sodann bewertet werden.
Das Regelwerk gestützte Bewertungsinstruktionsmodul 126 beinhaltet zahlreiche Bewertungsverfahren zur Anwendung beim Durchführen eines Diagnosetests. Modul 126 definiert eine Mehrzahl Entscheidungs-wesentlicher Regeln, die die bearbeiteten Daten bewerten, die ihrerseits in Zusammenhang mit der Durchführung der Verarbeitungsoperationen bereitgestellt werden, definiert durch Modul 124. Jedes Regelwerk beinhaltet eine Form einer Vergleichsanalyse, die die verarbeiteten Daten in Bezug auf gewisse Bewertungskriterien bewertet. Die Bewertungskriterien können beispielsweise in Gestalt von Grenzwerten vorliegen, zulässigen Bereichen oder zulässigen Abweichungen von einem Bezugspunkt. Die Bewertungskriterien können Ereignis-spezifisch sein. Gemäß einer Ausführungsform wird das Entscheidungs-typische Regelwerk ausgedrückt in Gestalt einer WENN JA, DANN-Aussage, die bestimmt, ob ein gewisser spezifizierter Zustand eingetreten ist (d. h., der WENN JA-Teil der Regel), worauf die Durchführung einer Handlung vorgenommen wird (d. h. die Entscheidung gemäß der DANN-Klausel), wenn die Bedingungsklausel (der WENN JA-Teil) zutrifft. Der WENN JA-Teil der Aussage beinhaltet Bewertungs- und/oder Analyse- Berechnungen bezüglich der verarbeiteten Daten. Die durch die WENN JA, DANN-Aussage kann gemäß einer Ausführungsform der Erfindung die Durchführung einer Wartungsbezogenen Handlung mittels der Wartungseinheit 104 und/oder einer Regel- oder Steuerbezogenen Aufgabe durch die Regel- Steuer-Einheit 106 betreffen.
Die dargestellte Wartungseinheit 104 beinhaltet eine Wartungseinrichtung 130, ein Wartungsverfahren 132 und ein Wartungsruf-Instruktionsmodul 134. Die Wartungseinheit 104 arbeitet im allgemeinen derart, dass sie eine Ereignisbezogene Wartungsaufgabe oder ein Verfahren in Abhängigkeit von Ergebnissen der Diagnosetests durchführt, ausgeführt durch die Diagnoseeinheit 102. Die Diagnoseeinheit 102 gibt an die Wartungseinheit 104 eine Verfahrensanforderung, so dass die Einheit 104 eine bestimmte Wartungsaufgabe durchführt. Diese Anforderung kann beispielsweise als Teil der DANN-Klausel-Entscheidung in Bezug auf die WENN JA, DANN-Regel von Modul 126 auftreten.
Zu diesem Zwecke definiert das Wartungsverfahren 132 eine Mehrzahl durchzuführender Wartungsaufgaben, die jeweils einem bestimmten Ereignis zugeordnet sind. Diese Routinen lassen sich z. B. in Gestalt geeigneter Software- Codes implementieren, wie in Gestalt jenes Codes, der durch das Wartungsanforderungs-Instruktionsmodul 134 wiedergegeben ist. Modul 134 beinhaltet eine Mehrzahl Ereignis-spezifischer Programmcode-Module, deren jede der Durchführung einer spezifischen Wartungsaufgabe in Bezug auf ein spezifisches Ereignis gewidmet ist.
Die verschiedenen Wartungsaufgaben können sich beziehen auf das Anfordern von Wartungsleistungen, (wie beispielsweise eine Fernmanagementanwendung oder ein Anforderungszentrum) auf das Abgeben eines Kommandos an die Zapfstation, eine Software-bezogene Wartungsoperation durchzuführen (beispielsweise ein Computer-Scanning an einem Gerät durchzuführen oder nach Viren oder anderen Unregelmäßigkeiten zu forschen) oder andere ähnliche Operationen.
Die Wartungseinheit 130 erzeugt ein geeignetes Interface mit Agent-Computer 98 und erleichtert die Durchführung geeigneter Wartungsaufgaben, bestimmt durch Wartungsdirektiven von der Diagnoseeinheit 102. Zu diesem Zwecke ist die Wartungseinheit 130 derart konfiguriert, dass sie Operationen des Wartungsverfahrens 132 steuert (und damit Instruktionsmodul 134), z. B. durch Abrufen einer entsprechenden Ereignis-spezifischen Wartungsroutine in Elemente 132, 134.
Die dargestellte Regel-Steuereinheit 106 (control unit) umfasst eine Regel- Steuereinrichtung 140, ein Regel-Steuerverfahren 142 und ein Regel-Steuer- Instruktionsmodul 144. Einheit 106 führt im allgemeinen eine Ereignis-bezogene Steueraufgabe oder Regelaufgabe in Abhängigkeit von Ergebnissen der in der Diagnoseeinheit 102 durchgeführten Diagnose aus. Die Diagnoseeinheit 102 gibt eine Anforderung an die Einheit 106 zum Durchführen einer bestimmten Steuer-, Regel-, oder Kontrollaufgabe. Diese Anforderung kann beispielsweise als Teil der DANN-Klauselentscheidung auftreten, im Zuge der WENN JA, DANN-Regel von Modul 126.
Zu diesem Zweck definiert das Kontrollverfahren 142 eine Mehrzahl durchzuführender Kontrollaufgaben, deren jede einem bestimmten Ereignis zugeordnet ist. Diese Routinen lassen sich beispielsweise in Gestalt geeigneter Software-Codes implementieren, wie durch jenen Code, der durch das Kontrollinstruktionsmodul 144 wiedergegeben wird. Modul 144 beinhaltet eine Mehrzahl Ereignis-spezifischer Programmcodemodule, deren jede für die Durchführung einer bestimmten Kontrollaufgabe in Bezug auf ein bestimmtes Ereignis vorgesehen ist.
Die verschiedenen Kontrollaufgaben können beispielsweise das Abgeben eines Steuerbefehls oder Kontrollbefehls an eine Kraftstoffzapfstation beinhalten, einen Komponentenparameter zu ändern, das Abgeben eines Kontrollbefehls an eine Zapfstation, eine Komponenten-Rekonfiguration zu erleichtern, oder anderweitig das Verhalten einer Zapfkomponente zu beeinflussen. Kontrollbefehle können auch den Status gewisser Komponenten beeinflussen, beispielsweise ein Aktivieren oder Deaktivieren einleiten. Die Steuereinheit 140 sorgt für ein geeignetes Interface mit Agent-Computer 98 und erleichtert die Durchführung geeigneter Kontrollaufgaben, so wie bestimmt durch Kontrolldirektiven, aufgenommen von der Diagnoseeinheit 102. Zu diesem Zwecke ist die Kontrolleinheit 140 derart konfiguriert, dass sie den Betrieb des Kontrollverfahrens 142 (und damit Instruktionsmodul 144) steuert, beispielsweise durch Veranlassen einer entsprechenden Ereignis-bezogenen Kontrollroutine, enthalten in den Elementen 132 und 134.
Prozessor 108 erleichtert das Durchführen von Programmcodeinstruktionen, die sich in der Agent-Architektur 100 befinden, und erleichtert auch die Ausführung von Rechenoperationen, die von den verschiedenen Modulen der Agent- Architektur 100 abgerufen werden. Zu diesem Zwecke und zu anderen, dem Fachmann geläufigen Zwecken, arbeitet Prozessor 108 auf herkömmliche Weise in Verbindung mit Agent-Computer 98, um die verschiedenen Computerbezogenen Funktionen durchzuführen, die der Agent-Architektur 100 zugeordnet sind.
Der dargestellte Ereignisdetektor 110 kann jegliche geeignete Form aufweisen, um Ereignisnachrichten von der Tankanlage aufzunehmen, beispielsweise von den Kraftstoffzapfstationen und den POS-Terminals. Wie zuvor erwähnt, können die Ereignisnachrichten oder -meldungen in jeglicher geeigneter Form geliefert werden, die das Auftreten eines Ereignisses in Bezug auf die Tankanlage notiert, anzeigt oder weitergibt. Ereignisdetektor 110 vermag ferner die Ereignisnachricht zu verarbeiten, um einen Ereignisindikator zu extrahieren (beispielsweise einen erkennbaren, Ereignis-spezifischen Code oder einen Ereignis-Identifikator) sowie Ereignis-bezogene Information wie beispielsweise Komponentenparameter, die dem Ereignis zugeordnet sind.
Die Ereignis-bezogenen Daten des Ereignisdetektors 110 werden sodann den anderen Elementen der Agent-Architektur 100 zugänglich gemacht. Insbesondere wird die Ereignis-bezogene Nachricht von der Diagnoseeinheit 102, der Wartungseinheit 104 und der Kontrolleinheit 106 benutzt, um die hiermit verbundenen, notwendigen Ereignis-spezifischen Operationen durchzuführen. Die Diagnoseeinheit 102 nutzt beispielsweise den Ereignisindikator aus, um die entsprechende Ereignis-bezogene Diagnoseroutine des Diagnosetestverfahrens 122 auszuwählen.
Die Agent-Architektur 100 kommuniziert mit der Tankanlage über die I/O- Schaltung 112. Die I/O-Schaltung 112 kann in jeglicher geeigneter Form vorliegen, sofern sie die Agent-Architektor 100 dazu in die Lage versetzt, ein Interface zu bilden oder anderweitig die verschiedenen überwachten Einheiten in der Tankanlage miteinander zu verbinden, d. h. die Zapfstationen und die POS- Terminals. Die I/O-Schaltung 112 kann ferner eine Netzverbindung an örtliche oder ferne Einheiten herstellen, wie an das Internet, an das World Wide Web und an entfernte Managementanwendungen. Die Agent-Architektur 100 verlassende Nachrichten gehen auch über die I/O-Schaltung 112. Beispiele solcher Kommunikationen beinhalten Zapfkontrollanforderungen der Kontrolleinheit 106 sowie Wartungsanforderungen der Wartungseinheit 104.
Während einer Operation kann der Ereignisdetektor 110 beispielsweise eine Ereignisnachricht von einer Kraftstoffzapfstation über die I/O-Schaltung 112 erhalten. Der Ereignisindikator (das ist der Ereignis-ID) und Ereignis-bezogene Daten werden der Diagnoseeinheit 102 über den Agent-Computer 98 übermittelt. Die Diagnoseeinheit 102 verwendet daraufhin den Ereignis-ID, um die geeignete Ereignis-spezifische Diagnoseroutine aus einer Mehrzahl von Routinen des Diagnosetestverfahrens 122 auszuwählen. Die entsprechende Ereignisspezifische variable Information zur Anwendung durch die Diagnoseeinheit 102 wird aus der Dateneinheit 96 gewonnen.
Die Diagnoseeinheit 102 wendet sodann die Ereignis-spezifische variable Information (gewonnen von der Dateneinheit 96) und die Ereignis-bezogenen Daten (gewonnen als Teil der Ereignisnachricht) auf die ausgewählte Diagnoseroutine an. Die Ergebnisse der durchgeführten Diagnoseroutine entsprechen einer gelieferten Entscheidung, die wiedergibt, welche Handlung vorzunehmen ist. Die Diagnoseeinheit 102 gibt beispielsweise eine Direktive entweder an die Wartungseinheit 104 und/oder an die Kontrolleinheit 106. Die entsprechende Einheit 104, 106 nimmt die Direktive auf und verwendet die Ereignis-ID von Ereignisdetektor 110, um geeignete Programmcodeinstruktionen aufzunehmen und durchzuführen, entsprechend der jeweiligen Wartungsaktion und/oder Kontrollaktion.
Weitere Ereignisnachrichten können von der Agent-Architektur auf ähnliche Weise aufgenommen und verarbeitet werden.
Im folgenden soll auf Fig. 5 eingegangen werden. Man erkennt ein Blockschaltbild einer Agent-Architektur 200 zum Implementieren einer Agent- Facility 10 von Fig. 1 als weiteres Ausführungsbeispiel der Erfindung.
Die dargestellte Agent-Architektur 200 beinhaltet eine variable Präventiv- Wartungstabelle (PMVT) 200 sowie eine Präventiv-Wartungs-Ereignistabelle (PMET) 202. Die anderen Elemente der Agent-Architektur 200 haben einen ähnlichen Aufbau und eine ähnliche Funktionsweise in Bezug auf die mit denselben Bezugszeichen versehenen Elemente der Agent-Architektur 100 von Fig. 4. Die variable Tabelle 200 und die Ereignistabelle 202 haben, die Form von Aufzeichnungs-Einheiten, bei welchen die Aufzeichnung einem jeweiligen Ereignis entspricht.
Die Ereignistabelle 202 definiert voll und ganz die Ereignis-spezifischen Diagnoseroutinen und die Korrekturroutinen (beispielsweise Wartungs- und Kontrollanforderungen) zum Überwachen und zum Antworten auf Ereignisse, die in der Tankanlage auftreten. Die Ereignistabelle 202 beinhaltet die Funktionalitäten und Datenstrukturen, die sich auf die Diagnoseinheit 102, die Wartungseinheit 104 und die Kontrolleinheit 106 in der Agent-Architektur von Fig. 4 befinden.
Die variable Tabelle 200 definiert vollständig die Ereignis-bezogenen variablen Informationen zur Anwendung in Verbindung mit den Diagnoseroutinen der Ereignistabelle 202. Die variable Tabelle 200 beinhaltet die Funktionalitäten und Datenstrukturen, die sich auf die Dateneinheit 96 in der Agent-Architektur von Fig. 4 befinden.
Wie oben behandelt, arbeiten die Ereignistabelle 202 und die variable Tabelle 200 derart zusammen, dass sie die Art und Weise bestimmen, in welcher die Komponentendaten gesammelt und analysiert werden, um zu ermitteln, welche Handlung nach dem Durchführen der Analyse vorzunehmen ist. Anders ausgedrückt verwendet die Agent-Architektur 200 einen Software-gestützten Agent zum Erleichtern der Diagnose- und Wartungsaktivitäten bezüglich der Tankanlage.
Die nachstehende Diskussion bezüglich der variablen Tabelle 200 betrifft Tabelle 1. Die nachstehende Diskussion bezüglich der Ereignistabelle 202 betrifft die Tabellen A und B in Verbindung mit den Tabellen 2 und 3.

Variable Tabelle bezüglich der präventiven Wartung

Die variable Tabelle 200 beinhaltet eine Sammlung von Datenaufzeichnungen, die ihrerseits jeweils Daten enthalten, die einem überwachten oder erfassten Ereignis entsprechen. Pro überwachtem Ereignis kann mehr als eine einzige Aufzeichnung vorliegen. Für jede Aufzeichnung in der variablen Tabelle muß jedoch wenigstens eine Aufzeichnung in Ereignistabelle 202 vorliegen, um anzugeben, auf welche Weise die Daten der variablen Tabelle zu behandeln sind. Die variable Information, wiedergegeben durch die variable Tabelle 200, gibt Daten wieder, die durch die Diagnoseroutine, bezüglich des erfassten Ereignisses verarbeitet werden. Wie unten in Bezug auf die Ereignistabelle 202 beschrieben, wird der jeweilige Diagnosetest zum Verarbeiten der variablen Information durch das Aktionsfeld der relevanten Ereignis-bezogenen Aufzeichnung der Ereignistabelle 202 identifiziert.
Die variable Information von Tabelle 200 wird in zwei Arten unterteilt:
Zählerinformation und variable Information. Die Behandlung der Zählerinformation beinhaltet beispielsweise das Zurückstellen eines Zählerwertes und das Inkrementieren/Dekrementieren eines Zählerwertes in schrittweisen Einheiten.
Im folgenden wird eine Beschreibung der sechs einzelnen Felder wiedergegeben, die in der variablen Tabelle 200 angegeben sind, wiedergegeben in Tabelle 1. Das angezeigte Format dient lediglich Illustrationszwecken. Tabelle 1 Variable Tabelle

EREIGNISCODE

Dieses Feld (Spalte 1) enthält einen Code, der ein gewisses Systemereignis identifiziert, entsprechend der Überwachung. Die variable Tabelle 200 verwendet dieselben Ereigniscodes wie die Ereignistabelle 202. Diese gemeinsame Codeverwendung erleichtert einen raschen Zugang und ein Suchen der variablen Tabelle; ein einwandfreies Identifizieren der Ereignis-bezogenen Aufzeichnung wird durch die Diagnoseroutine herbeigeführt, d. h. je nach Anforderung durch das Aktionsfeld (action type field) der Ereignistabelle.
Je nach Inhalt der entsprechenden Ereignistabellenaufzeichnung können in der variablen Tabelle mehrere Aufzeichnungen mit ein und demselben Ereigniscode vorliegen. Eine solche Situation liegt beispielsweise dann vor, wenn ein Ereignis lediglich durch die Anwendung mehrerer Parameter voll und ganz charakterisiert wird. In diesem Falle erfordert eine einwandfreie Diagnose des Ereignisses das gleichzeitige Verarbeiten mehrerer Variabler, die aus der variablen Tabelle aufgespürt wurden.

ZEIT

Der Inhalt dieses Feldes (Spalte 2) zeigt die letzte Zeit, die geändert wurde. Es kann eine absolute oder eine relative Zeitangabe verwendet werden.

ZÄHLER

Dieses Feld (Spalte 3) enthält einen Zähler, der die Ergebnisse einer Zählaktion wiedergibt, durchgeführt durch die Agent-Facility im Anschluß an einen zählerbezogenen Diagnosetest.
In Tabelle 2 sind die Diagnoseroutinen wiedergegeben, die eine Zähleroperation verwenden, angezeigt durch die folgenden Funktionsabrufdesignatoren:
PMET_ACTION_TYPE_ADD_COUNT;
PMET_ACTION_TYPE_SET_COUNT; und
PMET_ACTION_TYPE_MULTIPLE_ADD_COUNT.
Dieses Feld wird dann nicht zurückgestellt, wenn das zugeordnete Ereignis eskaliert.

WERT

Dieses Feld (Spalte 4) enthält eine Variable, die Ergebnisse der variablen Aktion wiedergibt, ausgeführt durch die Agent-Facility im Anschluß an einen variablen Diagnosetest. Solche variablen Tests beinhalten im allgemeinen das Austauschen oder die Justierung des Inhalts des WERT-Feldes.
Tabelle 2 zeigt die Diagnoseroutinen an, die eine Zähleroperation verwenden, wiedergegeben durch die folgenden Funktionsabrufdesignatoren:
PMET_ACTION_TYPE_ADD_VALUE;
PMET_ACTION_TYPE_SET_MAX_VALUE;
PMET_ACTION_TYPE_SET_MIN_VALUE;
PMET_ACTION_TYPE_SET_VALUE; und
PMET_ACTION_TYPE_MULTIPLE_ADD_VALUE.
Dieses Feld wird dann nicht zurückgestellt, wenn das zugehörende Ereignis eskaliert.

TRIP-ZÄHLUNG

Ähnlich dem Zählfeld enthält dieses Feld (Spalte 5) einen Zähler, der die Ergebnisse der Zählaktion wiedergibt, durchgeführt durch die Agent-Facility im Anschluß an einen Zähler-Diagnosetest. Je nach Inhalt des escalation reset flag field in der Ereignistabelle, und anders als beim Zählerfeld, lässt sich dieses Feld dann zurückstellen, wenn das Ereignis eskaliert.
Wie das Zählerfeld, so wird auch dieses Feld üblicherweise benutzt, um eine laufende akkumulierte Zählung eines Ereignisses aufrecht zu erhalten. Die Trip-Zählung wird jedoch dann zurückgestellt, sobald das Ereignis eskaliert, d. h. dann, wenn ein Benchmark-Bewertungskriterium erreicht und ein Wartungsruf ergangen ist. Ein Eskalationsereignis kann beispielsweise dann auftreten, wenn die Anzahl von Kartenlesezugängen eine vorgegebene Schwelle erreicht hat und ein Reinigungsvorgang angefordert wurde. Zu diesem Zeitpunkt wird die Trip-Zählung rückgestellt, um den erneuten Zustand des Kartenlesers wiederzugeben und um eine neue laufende Zählung einzuleiten.

TRIP-WERT

Ähnlich dem WERT-Feld enthält dieses Feld (Spalte 6) eine Variable, die die Ergebnisse der variablen Aktion wiedergibt, durchgeführt durch die Agent-Facility im Anschluss an einen variablen Diagnosetest. Je nach dem Inhalt des escalation reset flag field in der Ereignistabelle und anders als beim WERT-Feld kann dieses Feld jedoch zurückgestellt werden, wenn das Ereignis eskaliert.
Wie beim WERT-Feld wird auch dieses Feld üblicherweise dazu verwendet, den Wert einer Variablen beizubehalten, wie beispielsweise einen Komponenten- Parameter. Der Trip-Wert wird jedoch dann zurückgestellt, wenn das Ereignis eskaliert, d. h. wenn ein Benchmark-Bewertungskriterium erreicht und ein Wartungsruf abgegeben wurde.
Ein Eskalationsereignis kann beispielsweise dann auftreten, wenn die Gesamtzahl von elektronischen Druckerimpulsen (nach dem zuletzt vermerkten Wartungsruf) einen vorgegebenen Grenzwert erreicht hat, wobei eine neue Wartungsanforderung ausgelöst wird. Der Gesamtlauf der Impulse wird akkumuliert, beispielsweise unter Verwendung der PMET_ACTION_TYPE_ADD_VALUE-Aktion (siehe Ereignistabelle), wobei die Agent-Facility mit Interimimpuls-Gesamtzählungen in regelmäßigen periodischen Zeitabständen versorgt wird. Die Interim-Impulszählung wird sodann dazu verwendet, die laufende gesamte Impulszählung hochzurechnen, d. h., es wird die Interim-Zählung der gespeicherten Zählung hinzuaddiert, um bei einer neuen, hochgerechneten Zählung zu landen.
Zeigt die Diagnoseoperation an, dass die Anzahl von Impulsen eine bestimmte Grenze überschritten hat, und dass eine Wartungsanforderung vermutlich ausgeführt wurde, so wird zu diesem Zeitpunkt der TRIP-Wert zurückgestellt, um den aktuellen Zustand der Komponente wiederzugeben (d. h. des Druckers), und um ein neues Messen des Gesamtimpulses zu starten.

Ereignistabellen bezüglich präventiver Wartung

In der folgenden Diskussion werden die verschiedenen Ereignistabellen erläutert, die dem Durchführen von Diagnosevorgängen in Verbindung mit Informationen von der Tankanlage zugeordnet sind. Die Tabellen A und B beschreiben jeweils die Ereignistabellen, die sich auf zwei beispielhafte Diagnoseprogramme beziehen.
Ereignistabelle 202 wird eingeleitet durch Aufzeichnungen, welche die zu überwachenden Ereignisse wiedergeben.
Das erste Diagnoseverfahren überwacht Ereignisse, welche drei Hauptfunktionalbereiche betreffen, nämlich das Leistungsmanagement (Tabelle A-1), das POS-Interface (Tabelle A-2) und ein Zapf-lnterface (Tabelle A-3). Diese Tabellen bilden gemeinsam eine Konfiguration einer Ereignistabelle 202, um ein entsprechendes Diagnoseprogramm zu implementieren. Dies ist ein weiteres Ausführungsbeispiel der Erfindung.
Das zweite Diagnoseverfahren überwacht Ereignisse, welche siebzehn Hauptfunktionsbereiche betreffen, nämlich Leistungsmanagement, Hauptschalttafel, System, Kraftstoffkontrolle, Dampfrückgewinnung, Temperaturkontrolle, Kommunikation, magnetischer Kartenleser, Tastenfeld, Drucker, Realzeitdisplay, VGA-Display, Bargeld-Acceptor, Schuldmodul, RFID, Manager-Arbeitsweise und Managers key arming device. Diese funktionalen Bereiche sind jeweils in den Tabellen B-1 bis B-17 wiedergegeben. Diese Tabellen bilden gemeinsam eine weitere Konfiguration einer Ereignis-Tabelle 202, um ein entsprechendes Diagnoseprogramm zu implementieren. Dies ist ein weiteres Ausführungsbeispiel der Erfindung.
Jede Ereignis-Tabellenaufzeichnung beinhaltet die folgenden Felder EVENT, ACTION TYP , INTERVAL, TEST TYPE, TEST VALUE, TEST EVENT, ESCALATION EVENT, ESCALATION E-MAIL FLAG und ESCALATION RESET FLAG. In Verbindung mit Tabelle 2 soll das ACTION TYPE-Feld diskutiert werden. Eine Diskussion des TEST TYPE-Feldes wird in Verbindung mit Tabelle 3 gegeben. TABELLE A-1 Leistungsmanagement

Tabelle A-2 POS-Interface

Tabelle A-3 Zapf-Interface

Tabelle B-1 Leistungsmanagement

Tabelle B-2 Hauptschalttafel

Tabelle B-3 SYSTEM

Tabelle B-4 KRAFTSTOFF-KONTROLLE

Tabelle B-5 Dampfrückgewinnung

Tabelle B-6 TEMPERATUR-KONTROLLE

Tabelle B-7 KOMMUNIKATION

Tabelle B-8 Magnetischer Kartenleser

Tabelle B-9 Tastenfeld

Tabelle B-10 Drucker

Tabelle B-11 REALZEIT-DISPLAY

Tabelle B-12 VGA-DISPLAY

Tabelle B-13 BARGELD-ACCEPTOR

Tabelle B-14 BELASTUNGS-MODUL

Tabelle B-15 RFID

Tabelle B-16 MANAGER-MODE

Tabelle B-17 MANAGER'S KEY ARMING DEVICE
Es folgt eine Beschreibung bezüglich der Aufzeichnungs-Feld-Definitionen für die Ereignis-Tabelle 202.

EREIGNIS-CODE

Die in der Ereignisfeldspalte (Spalte 1) angegebenen Ereignisse einer jeden Ereignistabelle in den Tabellen A und B beziehen sich auf überwachbare Ereignisse, die in Bezug auf die angegebene Komponente auftreten können.
Die in den Tafeln A und B wiedergegebenen Aufzeichnungen beinhalten eine Beschreibung eines jeden Ereignisses im EREIGNIS-Feld. Man beachte jedoch, dass diese Beschreibungen lediglich zur Veranschaulichung dienen, da eine Implementierung von Tabellen normalerweise das Einführen eines Ereignisspezifischen Codes in die EREIGNIS-Felder bedingen, ähnlich in der Art und Weise, wie das EREIGNISCODE-Feld der variablen Tabelle bestückt wird (Tabelle 1).
Dabei läßt sich jegliche Art von Codesprache, Descriptor, Terminologie, Format oder Ereignisindikator verwenden, solange dasselbe Vokabular von Kennworten in der gesamten Agent-Facility-Umgebung verwendet wird, um dieselben Ereignisse zu identifizieren. Die Ereignistabelle und die variable Tabelle akzeptieren dasselbe Kennwortvokabular, um eine Korrespondenz, eine Zuordnung usw. zwischen Tabellenaufzeichnungen zu ermöglichen, die sich auf ein und dasselbe Ereignis beziehen.

HANDLUNGSART (ACTION TYPE)

Der Inhalt dieses Feldes bestimmt, welche Aktion die Agent Facility durchführt bezüglich der variablen Informationsaufzeichnungen, die dem jeweiligen, gerade aufgenommenen Ereignis zugeordnet sind. Die Aktionen definieren verschiedene Formen von Datenmanipulationen oder Datenverarbeitungsvorgängen, ausgeführt im Hinblick auf Ereignis-bezogene variable Information (von der variablen Tabelle 200) im Hinblick auf Ereignis-bezogene Daten (von der Tankanlage), und zwar vor der Bewertung. Tabelle 2 ist natürlich nur ein Beispiel.
Die nachstehende Tabelle 2 enthält mögliche Werte dieses Feldes. Beim ACTION-Feld (Spalte 3) beziehen sich "Zählung" und "Wert" je nach dem auf die Inhalte der Felder ZÄHLER, WERT, TRIP ZÄHLER oder TRIP WERT in der anwendbaren Ereignis-spezifischen Aufzeichnung aus der variablen Tabelle 200. Die Bezugnahme im ACTION-Feld auf "im Ereignis enthaltene Menge" oder andere ähnliche Ausdrucksweise betrifft Ereignis-bezogene Daten, die die Nachricht begleiten, die ihrerseits von der Tankanlage aufgenommen wurde. Solche Ereignis-bezogenen Daten werden insbesondere von der Tankanlage in Verbindung mit dem Auftreten oder dem Vorliegen eines Ereignisses erzeugt.
Wie gezeigt, beziehen sich die Aktionen, die numeriert sind mit den Werten 0-5, im allgemeinen auf die Justierung der "Zählung" oder des "Wertes" in der beschriebenen Weise. Die Werte 6-7 beziehen sich auf das Hinzufügen neuer, Ereignisbezogener Aufzeichnungen zur variablen Tabelle 200.
Die in Spalte 3 angegebenen Aktionen werden in Form von entsprechenden auszuführenden Programmcodes implementiert. Tabelle 2 ARTEN VON MANIPULATIONEN, DURCHGEFÜHRT MIT DEN VARIABLEN TABELLENDATEN: INHALTE DES AKTIONSFELDES IN DER EREIGNISTABELLE

INTERVAL

Die Inhalte dieses Feldes zeigen an, wie lang die variablen Tabellenaufzeichnungen, die dem laufenden, erfaßten Ereignis zugeordnet sind, Gültigkeit haben. Die Agent Facility entfernt sämtliche ausgelaufenen variablen Aufzeichnungen vor Durchführung einer Aktion. Die Maßeinheit kann Minute sein; "0" zeigt an, dass die variablen Aufzeichnungen nicht auslaufen.

TEST TYPUS

Der Inhalt dieses Feldes gibt an, welchen Diagnosetest die Agent Facility ausführt, wenn ein bestimmtes Ereignis aufgenommen wird. Das Feld zeigt insbesondere den Typus der Rechenwerk gestützten Entscheidungs-Bewertung an, auszuführen auf der variablen Information, die zuvor verarbeitet wurde gemäß Datenverarbeitungsinstruktionen, die geliefert wurden in Verbindung mit dem ACTION-Feld.
Es kann im allgemeinen unterstellt werden, dass dieses Feld eine Funktion liefert, welche Informationen bewertet, analysiert und/oder interpretiert, beispielsweise durch Operationen wie Vergleiche und Berechnungen. Tabelle 3 dient natürlich auch nur zur Veranschaulichung. Andere Arten von Bewertungsverfahren sind denkbar.
Die nachstehende Tabelle 3 enthält die möglichen Werte für dieses Feld.
Im TEST-Feld (Spalte 3) von Tabelle 3 bezieht sich die Angabe "Zählung" und "Wert" je nach dem auf die Inhalte des betreffenden Feldes "ZÄHLUNG, WERT, TRIP-ZÄHLUNG oder TRIP-WERT in der anwendbaren Ereignis-spezifischen Aufzeichnung aus der variablen Tabelle 200, so wie laufend modifiziert oder anderweitig justiert durch vorausgegangene Datenbearbeitungsoperationen, die dem laufenden Ereignis zugeordnet sind.
Die Bezugnahme im TEST-Feld auf den "Testwert" bezieht sich auf Inhalte des TEST-WERT-Feldes (wie nachstehend diskutiert) bei der anwendbaren Ereignistabellen-Aufzeichnung. Die Bezugnahme im TEST-Feld auf den "Wert" des "Testereigniscodes" und die "Zählung des Testereigniscodes" bezieht sich auf die Inhalte des TESTEREIGNIS-Feldes (wie nachstehend diskutiert) in der anwendbaren Ereignistabellenaufzeichnung.
Wie man sieht, haben die TEST-Feld-Inhalte die Form einer Bewertungsoperation (z. B. sie vergleichen oder berechnen) im Hinblick auf eine Bezugs-Benchmark (z. B. einen Testwert oder einen Test-Ereigniscode-Wert/Zählung), gefolgt von einer Entscheidung oder Beurteilung in Gestalt einer FALLS-DANN . . . Entscheidung. Derartige Testaktionen werden in Form entsprechender durchzuführender Programmcodes implementiert. Tabelle 3 TYPEN VON BEWERTUNGSTESTS, DURCHGEFÜHRT MIT AUFBEREITETEN DATEN INHALTE DES TEST-FELDES IN DER EREIGNISTABELLE

TESTWERT

Die Inhalte dieses Feldes werden von der Agent Facility verwendet, während der vom TEST-Feld vorgeschriebene Test durchgeführt wird. Die Art und Weise, in welcher die TESTWERT-Inhalte ausgenutzt werden, ist gegeben durch die Inhalte des TEST-Feldes der anwendbaren Ereignis-spezifischen Aufzeichnung.

TESTEREIGNIS

Dieses Feld enthält einen Code, der ein Systemereignis identifiziert, das überwacht wird. Führt die Agent Facility einen Test aus, der eine zweite variable Aufzeichnung von der variablen Tabelle 200 erfordert, so wird der Identifikator in diesem Feld dazu verwendet, diese Aufzeichnung aufzuspüren. Auf die Beschreibung des TEST-TYPUS-Feldes zur Bestimmung des für dieses Feld erforderlichen Testes wird verwiesen.
Dieses Feld muß nicht gleich null sein, um als wirksamer Identifikator zu dienen.

ESKALATIONSEREIGNIS

Dieses Feld enthält einen Code, der ein Systemereignis identifiziert. Führt die Agent Facility einen Test aus, der ein zu eskalierendes Ereignis erfordert, so werden die Inhalte dieses Feldes dazu benutzt, das neue Eskalationsereignis zu identifizieren.
Dieses Feld darf nicht null sein, um ein brauchbarer Identifikator zu sein.
Dieses Feld kann auszuführende Programmcode-Instruktionen enthalten, um einen entsprechenden Wartungs- oder Kontrollvorgang im Anschluß an das Vollenden eine Diagnoseoperation durchzuführen.

ESCALATION E-MAIL FLAG

Die Inhalte dieses Feldes zeigen der Agent Facility an, ob oder ob nicht eine E-Mail-Nachricht dann zu senden ist, wenn ein Ereignis eskaliert wird, wie z. B. eine Fern-Management-Anwendung.

ESCALATION RESET FLAG

Die Inhalte dieses Feldes zeigen der Agent Facility an, ob oder ob nicht die variable Tabellenaufzeichnung dann zurückzusetzen ist, wenn ein Ereignis eskaliert ist.
Die Fig. 5 ist gemeinsam mit dem Fließschema von Fig. 6 zu betrachten. Ein Ereignisdetektor 110 nimmt während des Betriebes eine Ereignisnachricht von der Tankanlage auf, dass das Eintreten und/oder die Anwesenheit eines überwachbaren und erfaßbaren Systemereignisses anzeigt (Schritt 300). Ereignisdetektor 110 liefert einen Ereignisidentifikator (ID), der das Ereignis anzeigt oder repräsentativ hierfür ist. Ereignisdetektor 110 liefert ferner Ereignisbezogene Daten, die die Ereignisnachricht begleiten, wie beispielsweise Komponentenparameterwerte.
Der Ereignis-ID, der von Ereignisdetektor 110 geliefert wurde, wird von Agent-Computer dazu ausgenutzt, die anwendbare Ereignis-spezifische Aufzeichung in Ereignistabelle 202 zu identifizieren - Schritt 304. Gleichzeitig wird Ereignis-ID auch dazu ausgenutzt, die anwendbare Ereignis-spezifische variable Aufzeichnung in der variablen Tabelle 200 zu identifizieren - Schritt 302.
Sobald die zutreffenden Ereignis- und variablen Aufzeichnungen identifiziert und aufgespürt wurden, wird der Datenverarbeitungsvorgang, angezeigt durch das AKTIONSTYPUS-Feld der Ereignistabellenaufzeichnung, mit den betreffenden Inhalten der variablen Tabellenaufzeichnung durchgeführt - Schritt 306. So werden beispielsweise relevante Diagnoseprogrammcode-Instruktionen entsprechend dem AKTIONSTYPUS-Feld, und dieses implementierend, auf den Prozessor 108 gelagert und ausgeführt. Prozessor 108 empfängt zu diesem Zweck ebenfalls die anwendbare variable Information sowie Ereignis-bezogene Daten.
Sodann wird die Bewertungsoperation, angezeigt durch das TESTTYPUS-Feld der Ereignistabellenanzeige, durchgeführt - Schritt 306. Die relevanten Diagnoseprogrammcode-Instruktionen, die dem TESTTYPUS-Feld entsprechen und dieses implementieren, werden beispielsweise auf den Prozessor 108 geladen und durchgeführt. Zu diesem Zweck empfängt Prozessor 108 die verarbeiteten Daten und andere Eingänge, die notwendig sind, um das Regelwerk auszuführen, wie den Testwert und die Testereigniscode-Zählung/Wert.
Je nach dem Ergebnis der Bewertungsoperation kann die Ereignistabelle 202 die Notwendigkeit einer Ereigniseskalation anzeigen - Schritt 308. Ist beispielsweise der FALLS-DANN-Regel Genüge getan, so werden die relevanten Wartungsprogrammcode-Instruktionen, die dem ESKALATIONS-EVENT-Feld entsprechen und dieses implementieren, auf den Prozessor 108 geladen und ausgeführt.
Weitere Ereignismeldungen werden in gleicher Weise aufgenommen und verarbeitet. Es ist vorteilhaft, die Agent-Architektur 200 mit einem re-programmierbaren Merkmal auszustatten, das es erlaubt, dass die Inhalte der variablen Tabelle 200 und der Ereignistabelle 202 verändert, abgewandelt oder justiert werden. Dieses Merkmal ist besonders dann vorteilhaft, wenn es zum Rekonfigurieren der Ereignistabelle 202 angewendet wird, um die Bewertungsregeln zu entfernen, etwas hinzuzufügen oder diese abzuwandeln. Solche Änderungen würden sich auch bei Datenverarbeitungen (ACTION-TYPUS-Feld) und bei Bewertungskriterien (TEST-WERT-Feld) anwenden.
Es versteht sich, dass die vorausgegangenen Funktionen und Operationen der Agent-Architektur 200 der Weisung, Überwachung, Koordinierung und Führung durch Agent-Computer 98 auf herkömmliche Weise unterliegen.
Die Routinewartung muß beispielsweise bei einem Kartenleser während dessen Lebensdauer durchgeführt werden, oder sie erreicht nicht einen Durchschnitt von beispielsweise 500.000 Einfügsteckungen. Die Wartung besteht im allgemeinen aus einer sorgfältigen Reinigung. Es besteht jedoch das Problem, zu welchem Zeitpunkt die Wartung vorzusehen ist, da der Kartenleserverschleiß innerhalb und ohne die Station stark schwankt.
Gemäß der Erfindung läßt sich eine Regel aufstellen, die das Verhältnis schlechter Kartenlesungen gegenüber der Gesamtzahl von Kartenlesungen errechnet, um einen Prozentsatz zu ermitteln. Zu diesem Zwecke läßt sich ein Ereignis definieren, das auf das Auftreten einer schlechten Kartenauslesung gerichtet ist, angezeigt oder gemessen durch irgendein Kriterium. Eine falsche Kartenlesung kann beispielsweise durch die Abwesenheit von genügend aufgefundenen Informationen angezeigt werden, wenn der Leser die Karte abtastet. Tritt dies ein, so wird eine Ereignisnachricht ausgelöst oder anderweitig erzeugt, die das Auftreten einer falschen Kartenauslesung anzeigt. Die akkumulierte Gesamtzahl schlechter Kartenlesungen kann von der Agent-Facility in einer diesbezüglichen variablen Tabellenanzeige als Update-Zählung festgehalten werden.
Ein anderes diesbezügliches Ereignis läßt sich definieren, das eine laufende Zählung sämtlicher Kartenauslesungen festhält, ob gut oder schlecht. Dies erlaubt einen Vergleich schlechter Kartenauslesungen mit der Gesamtzahl von Auslesungen. So kann beispielsweise ein Ereignisanzeiger ausgelöst (und eine entsprechende Ereignisnachricht der Agent-Facility eingespeist) werden, wann immer ein Kartenleserzugang vorgenommen wird. Auf diese Weise wird die Gesamtzahl von Kartenleserzugängen festgehalten. Dieser Gesamtzugang wird gleichermaßen von der Agent-Facility als Zählung in der anwendbaren, Ereignisspezifischen variablen Tabellenaufzeichnung festgehalten.
Die beispielhafte Regel, die das Verhältnis schlechter Kartenauslesungen zur Gesamtzahl von Kartenauslesungen errechnet, um ein Verhältnis zu ermitteln, entsprechend einem Prozentsatz, läßt sich in Gestalt einer geeigneten Ereignisspezifischen Ereignistabellenanzeige implementieren, wobei die gewünschte Verhältnisberechnung im TEST-TYPUS-Feld angegeben ist. Die schlechte Kartenauslesungs-Zählung und der Gesamt-Leser-Zugriff werden durch entsprechende Diagnoseinstruktionen im ACTION-TYPUS-Feld hochgerechnet, und zwar vor dem Ermitteln des Prozentwertes.
Die FALLS-DANN-Aussage des TEST-TYPUS-Feldes zeigt in gleicher Weise an, welche Korrekturmaßnahmen notwendig sind, wenn das berechnete Verhältnis einen bestimmten Wert überschreitet, der im TEST-WERT-Feld angegeben ist. Die Handlung (beispielsweise das Eskalationsereignis) kann beispielsweise das Benachrichtigen eines Service-Technikers beinhalten, wonach der Kartenleser eine Reinigung benötigt.
Das in Fig. 7 gezeigte Blockschaltbild zeigt ein globales Zapfmanagementsystem 400 zum Netzbetreiben eines zentralisierten System-Administrators 402 mit verschiedenen Tankanlagen 404, die Agent-Facilities 408 aufweisen, als weiteres Beispiel der Erfindung.
Wie dargestellt, beinhaltet das System 400 einen Administrator 402 in Gestalt eines Netz-Management-Systems wie beispielsweise einer Fernmanagementanwendung. Administrator 402 dient der Kommunikation mit einer Mehrzahl einzelner Zapfstationen 402, deren jede mehrere Zapfpositionen 406 (Zapfsäulen) aufweist.
Jede Zapfstation 404 ist mit einer Agent-Facility 408 ausgerüstet, deren Aufbau, Betrieb und Funktionsweise ähnlich jener wie in Verbindung mit den Fig. 1-6 gestaltet sind. Agent 408 stützt oder erleichtert die administrativen Vorgänge, Serviceleistungen und andere Managementfunktionen, die in Verbindung mit den Netz-Management-System 402 durchgeführt werden.

Claims

1. System, umfassend:
eine Kraftstoff-Zapfeinrichtung mit einer Mehrzahl von Komponenten; und
eine Agent-Facility, die mit der Kraftstoff-Zapfeinrichtung in Wirkverbindung steht und die derart konfiguriert ist, dass sie eine Überwachungsfunktion und/oder eine Kontrollfunktion der Kraftstoff-Zapfeinrichtung ausübt.

2. System nach Anspruch 1, dadurch gekennzeichnet, dass die Agent-Facility in folgender Weise konfiguriert ist:

1. 2.1 sie empfängt eine Ereignisinformation von der Kraftstoff-Zapfeinrichtung;

2. 2.2 sie verarbeitet die Ereignisinformation;

3. 2.3 sie bewertet und/oder analysiert die verarbeitete Ereignisinformation;

4. 2.4 sie führt eine Wartungsaufgabe entsprechend den Ergebnissen der Bewertung und/oder Analyse aus;

5. 2.5 sie führt eine Kontrollaufgabe gemäß den Ergebnissen der Bewertung und/oder Analyse aus, oder

6. 2.6 sie führt eine Kombination der Schritte gemäß 2.1 bis 2.5 aus.

3. System nach Anspruch 1, dadurch gekennzeichnet, dass die Agent-Facility weiterhin die folgenden Funktionen ausführt:

1. 3.1 eine Diagnoseoperation in Bezug auf Ereignis-Information, aufgenommen von der Kraftstoff-Zapfstation;

2. 3.2 und/oder Veranlassen einer Wartungsoperation in Bezug auf die Kraftstoff- Zapfstation gemäß dem Ergebnis der Diagnoseoperation.

4. System nach Anspruch 3, dadurch gekennzeichnet, dass die Ereignis- Information erste Daten umfaßt, die ein Ereignis anzeigen, zweite Daten, die den Status, den Parameterwert, den Zustand, die Arbeitsweise, das Maß oder irgendeine Kombination hieraus in Bezug auf wenigstens eine Komponente der Kraftstoff-Zapfstation anzeigen.

5. System nach Anspruch 3, dadurch gekennzeichnet, dass die Wartungsoperation das Ausgeben eines Befehls zum Rekonfigurieren wenigstens einer Komponente beinhalten, das Ausgeben eines Befehls zum Kontrollieren wenigstens einer Funktion einer Kraftstoff-Zapfoperation an der Kraftstoff-Zapfstation, das Abgeben und/oder zeitliche Veranlassen einer Service-Anforderung, das Abgeben einer Nachricht eines Wartungsbereit-Zustandes oder einer Kombination hiervon.

6. System nach Anspruch 1, dadurch gekennzeichnet, dass die Agent-Facility derart gestaltet ist, dass sie die folgenden Funktionen ausübt:

1. 6.1 von der Kraftstoff-Zapfstation einer Ereignis-Nachricht, die ein Ereignis anzeigt, das hierin auftritt und/oder einer Ereignis-Nachricht, die sich auf ein Ereignis bezieht, angegeben durch die Ereignis-Nachricht;

2. 6.2 Handhaben variabler Informationen, die dem Ereignis zugeordnet sind, angezeigt durch die Ereignis-Nachricht entsprechend der Ereignis- Nachricht und/oder der Ereignis-Information;

3. 6.3 Bewerten der gehandhabten variablen Information; und

4. 6.4 Ausführen wenigstens einer Aufgabe gemäß den Bewertungsergebnissen.

7. System nach Anspruch 6, wobei die Handhabung (Manipulation) der variablen Information das Justieren eines Ereignis-bezogenen variablen und/oder Ereignis-bezogenen Zählers umfaßt, wobei die Ereignis-bezogene Variable eine Anzeige eines Betriebsparameters und/oder eines Betriebszustandes der Kraftstoff-Zapfstation ist, und der Ereignis-bezogene Zähler eine Anzeige einer Zählung eines Ereignis-Auftretens.

8. System nach Anspruch 6, wobei die Bewertung der gehandhabten variablen Information das Analysieren der gehandhabten variablen Information in Bezug auf vorgegebene Testinformation beinhaltet.

9. System nach Anspruch 6, wobei das Durchführen der wenigstens einen Aufgabe das Veranlassen des Durchführens wenigstens einer Kontrollaufgabe in der Kraftstoff-Zapfstation beinhaltet.

10. System nach Anspruch 1, weiterhin umfassend eine variable Tabelle, die mit der Agent-Facility in Wirkverbindung steht und die eine Mehrzahl von Ereignis-spezifischen Aufzeichnungen aufweist, wobei jede Aufzeichnung umfaßt:

1. 10.1 einen Ereignis-bezogenen Indikator bezüglich des jeweiligen Ereignisses, das hiermit verbunden ist;

2. 10.2 variable Information, die sich auf das betreffende Ereignis bezieht;

3. 10.3 eine Ereignis-spezifische Tabelle, die mit der Agent-Facility in Wirkverbindung steht und die eine Mehrzahl von Ereignis-spezifischen Aufzeichnungen umfaßt, deren jede wenigstens eine der folgenden Positionen umfaßt:
ein Ereignis-Feld eines mit der Aufzeichnung verbundenen Ereignisses, ein Aktionsfeld, das Instruktionen liefert, die eine Datenverarbeitungsoperation zum Durchführen in Verbindung mit der relevanten variablen Information der variablen Tabelle definiert, ein Testfeld, das Instruktionen liefert, die eine Analyseoperation zum Durchführen in Verbindung mit Ergebnissen der Datenverarbeitungsoperation definiert, ein Testwertfeld, das einen vorgegebenen Testwert zur Anwendung bei der Analyseoperation definiert, und ein Eskalationsereignisfeld, das Instruktionen liefert, die wenigstens eine durchzuführende Aufgabe definiert, abhängig vom Ergebnis der Analyseoperation.

11. System nach Anspruch 1, dadurch gekennzeichnet, dass die Agent-Facility ferner umfaßt:

1. 11.1 Mittel zum Aufnehmen von Ereignis-Informationen von der Kraftstoff- Zapfstation;

2. 11.2 eine Dateneinrichtung mit einer Mehrzahl von Informationselementen, deren jede einem entsprechenden Ereignis zugeordnet ist;

3. 11.3 einen Prozessor, der derart konfiguriert ist, dass er wenigstens ein Informationselement der Dateneinrichtung gemäß Ereignis-Information verarbeitet, empfangen von der Kraftstoff-Zapfstation und

4. 11.4 eine Regelwerk-Facility, umfassend eine Mehrzahl von Regeln, deren jede einem entsprechenden Ereignis zugeordnet ist und jeweils eine Bewertungsfunktion umfaßt, derart konfiguriert, dass sie die Information bewertet, die vom Prozessor verarbeitet wurde und/oder eine Aufgabenfunktion, die derart konfiguriert ist, dass sie wenigstens eine Aufgabe gemäß den Ergebnissen der Bewertungsfunktion ausführt.

12. System nach Anspruch 11, dadurch gekennzeichnet, dass die Regel- Facility ein programmierbares Element aufweist, das eine selektive Modifikation der Mehrzahl von Regeln ermöglicht, oder eine selektive Entfernung von Regeln und/oder ein selektives Hinzufügen von Regeln.

13. System nach Anspruch 1, dadurch gekennzeichnet, dass die Agent-Facility ferner umfaßt:

1. 13.1 Mittel zum Aufnehmen von Ereignis-Informationen von der Kraftstoff- Zapfstation;

2. 13.2 eine Daten-Facility, umfassend eine Mehrzahl von Informationselementen, deren jede einem entsprechenden Ereignis zugeordnet ist;

3. 13.3 einen Prozessor, der derart konfiguriert ist, dass er wenigstens ein Informationselement der Daten-Facility gemäß Ereignis-Information von der Kraftstoff-Zapfstation verarbeitet und

4. 13.4 eine Regel-Facility, die eine Mehrzahl von Regeln umfaßt, deren jede einem entsprechenden Ereignis zugeordnet ist, wobei jede Regel jeweils definiert:
eine Diagnosefunktion, die derart konfiguriert ist, dass sie eine Diagnoseoperation in Bezug auf vom Prozessor verarbeitete Information durchführt;
eine Wartungsrufoperation, die derart konfiguriert ist, dass sie die Durchführung wenigstens einer Wartungsaufgabe ausführt oder veranlaßt, die sich auf die Kraftstoff-Zapfstation bezieht, und zwar gemäß den Ergebnissen der Diagnoseoperation;
eine Kontrolloperation, die derart konfiguriert ist, dass sie wenigstens eine Kontrollaufgabe ausführt oder veranlaßt, die sich auf die Kraftstoff- Zapfstation bezieht, und zwar in Bezug auf die Ergebnisse der Diagenoseoperation;
oder jegliche Kombination hieraus.

14. System nach Anspruch 1, weiterhin umfassend:
eine entfernte Einrichtung mit einer Management-Anwendung, wobei die entfernte Einrichtung in einem Abstand von der Kraftstoff-Zapfstation angeordnet ist und die Management-Anwendung derart konfiguriert ist, dass sie das Management wenigstens einer Komponente der Kraftstoff- Zapfstation in Zusammenarbeit mit der Agent-Facility ermöglicht; und
ein Kommunikationsglied zwischen der Agent-Facility und der entfernten Einrichtung.

15. System nach Anspruch 14, dadurch gekennzeichnet, dass die Agent-Facility eine Kundeneinheit umfaßt, und dass die entfernte Einheit eine Server-Einheit umfaßt.

16. System nach Anspruch 15, dadurch gekennzeichnet, dass die Agent-Facility und die entfernte Einheit derart konfiguriert sind, dass sie Management-Funktionen entsprechend der Simple Network Management Protocol (SNMP) ausführen.

17. Vorrichtung, umfassend:
eine Kraftstoff-Zapfstation; und
eine Agent-Facility, die mit der Kraftstoff-Zapfstation in Wirkverbindung steht.

18. Vorrichtung nach Anspruch 17, dadurch gekennzeichnet, dass die Agent- Facility ferner umfaßt:
Mittel zum Aufnehmen von Ereignis-Informationen von der Kraftstoff- Zapfstation;
ein Diagnose-Testprogramm, das betrieblich an die Aufnahmemittel angeschlossen ist; und
ein Wartungsablaufprogramm, das betrieblich an das Diagnose- Testprogramm angeschlossen ist.

19. Vorrichtung nach Anspruch 17, dadurch gekennzeichnet, dass die Agent- Facility weiterhin umfaßt:
Mittel zum Aufnehmen von Ereignis-Informationen von der Kraftstoff- Zapfstation;
einen Datenprozessor, der betrieblich an das Aufnahmemittel angeschlossen ist; und
einen Datenanalysator, der betrieblich an den Datenprozessor angeschlossen ist.

20. Vorrichtung nach Anspruch 17, weiterhin umfassend:
ein Kraftstoff-Zapfkontrollprogramm, das der Agent-Facility betrieblich zugeordnet ist.

21. Vorrichtung nach Anspruch 17, weiterhin umfassend:
eine Ereignistabelle, die der Agent-Facility betrieblich zugeordnet ist.

22. Vorrichtung nach Anspruch 21, weiterhin umfassend:
eine variable Tabelle, die der Ereignistabelle betrieblich zugeordnet ist.

23. Vorrichtung nach Anspruch 22, gekennzeichnet durch die folgenden Merkmale:

1. 23.1 die variable Tabelle umfaßt eine Mehrzahl von Ereignis-spezifischen Aufzeichnungen;

2. 23.2 jede Aufzeichnung umfaßt einen Ereignisindikator bezüglich des jeweiligen, hiermit verknüpften Ereignisses sowie variable Information, die sich auf das betreffende Ereignis bezieht;

3. 23.3 die Ereignistabelle beinhaltet eine Mehrzahl Ereignis-spezifischer Aufzeichnungen;

4. 23.4 jede Aufzeichnung beinhaltet wenigstens eine der folgenden Positionen:
ein Ereignisfeld, das ein mit der Aufzeichnung verknüpftes Ereignis betrifft;
ein Aktionsfeld, das Instruktionen liefert, die eine Datenverarbeitungsoperation definieren, umfassend variable Informationen von der variablen Tabelle;
ein Testfeld, das Instruktionen liefert, definierend eine Analysenoperation in Verbindung mit den Ergebnissen der Datenverarbeitungsoperation;
ein Testwertfeld, das einen vorgegebenen Testwert zur Anwendung bei der Analyseoperation definiert; und
ein Eskalations-Ereignisfeld, das Instruktionen liefert, definierend wenigstens eine durchzuführende Aufgabe je nach Ergebnis der Analyseoperation.

24. Vorrichtung nach Anspruch 17, dadurch gekennzeichnet, dass die Agent- Facility weiterhin umfaßt:

1. 24.1 Mittel zum Aufnehmen von Ereignis-Informationen von der Kraftstoff- Zapfstation;

2. 24.2 eine Dateneinrichtung, umfassend eine Mehrzahl von Informationselementen, deren jede einem entsprechenden Ereignis zugeordnet ist;

3. 24.3 einen Prozessor, der in betrieblicher Verbindung mit dem Aufnahmemittel und der Dateneinrichtung ist; und

4. 24.4 eine Regelwerk-Einrichtung, die in betrieblicher Verbindung mit dem Prozessor ist, und die eine Mehrzahl von Regeln umfaßt, jeweils einem entsprechenden Ereignis zugeordnet, wobei jede Regel einen ersten Satz auszuführender Instruktionen beinhaltet, definierend ein Bewertungsverfahren, sowie einen zweiten Satz auszuführender Instruktionen, definierend eine Management-Aufgabe, wobei die Management-Aufgabe eine auszuführende Kontrollaufgabe und/oder eine auszuführende Wartungsaufgabe beinhaltet.