DE10333886A1

DE10333886A1 - Verfahren zur schichtorientierten und kopierfreien Bearbeitung von Daten

Info

Publication number: DE10333886A1
Application number: DE2003133886
Authority: DE
Inventors: Thomas Jachmann; Uwe RÜCKL
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2003-07-22
Filing date: 2003-07-22
Publication date: 2005-02-24
Also published as: WO2005010752A1

Abstract

Um ein Verfahren zum Austauschen von Daten zwischen einem Ausgangsmodul (7, 8, 9) und einem Zielmodul (2, 3, 4) bereitzustellen, bbei dem das Ausgangsmodul (7, 8, 9) eine aus wenigstens einem Auftrag bestehende Anfrage erzeugt, die Anfrage einer aus nacheinander ablaufenden Bearbeitungsroutinen (11a, 11b, 11c, 11d) bestehenden Bearbeitungskette (11) übergeben wird, und jeder Auftrag anschließend auf das ihm mittels einer Zielmoduladresse zugeordnete Zielmodul (2, 3, 4) zugreift, mit dem aufwendige Kopiervorgänge in der Bearbeitungskette (11) bei der Bearbeitung der Anfrage vermieden sind, wird vorgeschlagen, dass für jeden Auftrag bereits vor der Übergabe der Anfrage an die Bearbeitungskette (11) ein dem jeweiligen Auftrag zugeordneter Zusatzspeicherbereich reserviert wird.

Description

Die Erfindung betrifft ein Verfahren zum Austauschen von Daten zwischen einem Ausgangsmodul und einem Zielmodul, bei dem das Ausgangsmodul eine aus wenigstens einem Auftrag bestehende Anfrage erzeugt, die Anfrage einer aus nacheinander ablaufenden Bearbeitungsroutinen bestehenden Bearbeitungskette übergeben wird, und jeder Auftrag anschließend auf das ihm mittels einer Zielmoduladresse zugeordnete Zielmodul zugreift.

Ein solches Verfahren ist aus dem landläufigen Stand der Technik bereits bekannt. Ausgangspunkt des Datenaustauschs, also eines Lese-, Schreib- oder sonstigen Prozesses, ist ein Ausgangsmodul. Das Ausgangsmodul erzeugt eine Anfrage, die mit Hilfe einer vorbekannten Adressenangabe auf ein Zielmodul zugreift. Vor dem Zugriff auf das adressierte Zielmodul durchläuft die Anfrage in der Regel eine Bearbeitungskette. Die Bearbeitungskette prüft beispielsweise den zur Anmeldung in das Laufzeitsystem eingegebenen Benutzernamen sowie das diesbezügliche Kennwort auf die Berechtigung zum Empfang von Prozesswerten des ausgewählten Bauteils. Auf diese Weise können diese Prozesswerte von der Kenntnisnahme bestimmter Benutzer abgeschirmt werden. Darüber hinaus sind Bearbeitungsketten bekannt, die mit einer sogenannten Fehleranalyse ausgerüstet sind, mit deren Hilfe die Bearbeitungskette das Vorliegen von Inkompatibilitäten verwendeter Bauteile oder von Softwaremodulen anzeigt und gegebenenfalls Lösungswege zur Behebung solcher Mängel aufzeigt.

In der Automatisierungstechnik findet eine auf den Austausch von Daten basierende Kommunikation zwischen verschiedenen Softwaremodulen oder zwischen Softwaremodulen und einer Hardwarekomponente statt. Bei einer solchen Kommunikation handelt es sich beispielsweise um den Zugriff auf Prozesswerte einer Leitstellenanlage, die aus Hardware- und Softwarekomponenten zusammengesetzt ist. Solche Leitstellenanlagen dienen in der Regel zur Überwachung und Steuerung großräumiger Netze wie beispielsweise Energieversorgungsnetze, Wasserversorgungsleitungen und Schienensysteme. Auch größere Immobilien können zur Steuerung von Klimaanlagen, Aufzügen, Lichtsystemen oder dergleichen mit Leitstellenanlagen ausgerüstet sein. Die zur Steuerung solcher verzweigten Anlagen notwendigen Bauteile sind daher in der Regel ebenfalls dezentral oder mit anderen Worten großflächig verteilt aufgestellt und über ein Laufzeitsystem miteinander verbunden. Dabei verfügt das Laufzeitsystem in der Regel über zumindest ein zweckmäßiges Kommunikationsnetz und speicherprogrammierbare Recheneinheiten, auf denen zweckmäßige Laufzeitprogramme den Austausch der Daten ermöglichen. Üblicherweise dienen Hardwareschnittstellen zum Datenaustausch zwischen den beispielsweise Prozesswerte liefernden Bauteilen oder Hardwarekomponenten einerseits und den Softwarekomponenten des Laufzeitsystems andererseits.

Dem vorbekannten Verfahren haftet der Nachteil an, dass jede Bearbeitungsroutine die Anfrage in ihre Bestandteile zergliedert. Dabei werden die Daten der Anfrage umkopiert, bearbeitet und an die nachfolgende Bearbeitungsroutine übergeben. Diese zergliederte Datenstruktur muss häufig solange beibehalten werden, bis Antwortdaten des Zielmoduls die Bearbeitungskette in umgekehrter Reihenfolge durchlaufen haben, so dass dem Ausgangsmodul die Antwortdaten in einer der Anfrage entsprechenden Form zur Verfügung gestellt werden können.

Speicherintensives Umkopieren und Speichern von Anfragen in jeder Bearbeitungsroutine sind die Folge, wodurch das System in seiner Leistungsfähigkeit beeinträchtigt wird.

Aufgabe der Erfindung ist es daher, ein Verfahren der eingangs genannten Art bereitzustellen, mit dem aufwendige Kopiervorgänge bei der Bearbeitung der Anfrage in der Bearbeitungskette vermieden sind.

Die Erfindung löst diese Aufgabe dadurch, dass für jeden Auftrag bereits vor der Übergabe der Anfrage an die Bearbeitungskette ein dem jeweiligen Auftrag zugeordneter Zusatzspeicherbereich reserviert wird.

Im Gegensatz zum Stand der Technik wird erfindungsgemäß bereits vor der Verarbeitung der Anfrage durch die Bearbeitungskette Speicherplatz zur Aufnahme von zusätzlichen Daten bereitgestellt. Dieser Speicherplatz oder Zusatzspeicherbereich ist jeweils einem Auftrag zugeordnet. Bei den im Zusatzspeicherbereich aufgenommenen zusätzlichen Daten kann es sich beispielsweise um auftragsspezifische Antwortdaten des Zielmoduls handeln. Auf Grund des bereits vor der Verarbeitung reservierten Speicherbereichs ist gewährleistet, dass alle Bearbeitungsroutinen der Bearbeitungskette auf den selben Speichebereich zugreifen können. Ein ständiges Umkopieren von Daten bei der Bearbeitung durch die Bearbeitungskette ist auf diese Weise vermieden. Die Anfrage ist zweckmäßigerweise in einem dynamischen Speicherbereich abgelegt, der beispielsweise von einem permanent ablaufenden Laufzeitprogramm eines dezentralen Laufzeitsystems verwaltet wird.

Als Ausgangsmodul kommen beliebige Softwarekomponenten oder Hardwareeinheiten in Betracht. So kann das Ausgangsmodul bei spielsweise ein Einzelplatzrechner sein, in dem die Anfrage seitens eines Benutzers über die Tastatur eingegeben wird. Das Ausgangsmodul kann jedoch auch eine Softwarekomponente sein, die zum Zugriff auf das Zielmodul veranlasst wird oder den Zugriff selbsttätig ohne manuelle Aufforderung durchführt. Im Rahmen der Erfindung ist es ferner zweckmäßig, dass die Softwarekomponenten dezentral beispielsweise über ein Netzwerk verteilt angeordnet sind. Solche Netzwerke sind insbesondere im Bereich der Leitstellentechnik erforderlich.

Auch das Zielmodul kann erfindungsgemäß sowohl eine Hardwarekomponente als auch eine Softwarekomponente sein. So ist das Zielmodul beispielsweise ein Steuerungsprogramm mit Alarmen oder Ereignissen, auf welche das Ausgangsmodul zugreift. Abweichend davon kann das Zielmodul auch ein Register einer Hardwareeinheit sein. Weiterhin kommen beliebige Treiber, Schnittstellenprogramme oder dergleichen in Betracht.

Ein Auftrag einer Anfrage kann weiterhin sogenannte Metadaten oder Verweise auf Metadaten enthalten. Diese Metadaten dienen beispielsweise als Stellparameter zur Steuerung der Verarbeitung des jeweiligen Auftrags durch die Bearbeitungsroutine oder Bearbeitungsroutinen.

Vorteilhafterweise wird im Auftrag eine Quelldatenkennung beigelegt, wobei wenigstens eine Bearbeitungsroutine der Bearbeitungskette eine Zwischenspeicherroutine ist, in der Ergebnisse einer Auftragsverarbeitung mit jeweils einer Speicherdatenkennung zwischengespeichert sind. Die Zwischenspeicherroutine vergleicht die Quelldatenkennung mit der in ihr gespeicherten Speicherdatenkennung und reicht die der Speicherdatenkennung zugeordneten Ergebnisse der Auftragsverarbeitung als Antwort dem Ausgangsmodul zurück. Handelt es sich bei der Quelldatenkennung beispielsweise um eine Bauteilkennung, mit der das Zielmodul genau bestimmt ist, ist es beispielsweise möglich, bei einer Abfrage bestimmter Prozesswerte des Zielmoduls einer Leitstellenanlage die Bearbeitungsroutine zu veranlassen, bestimmte Prozesswerte zwischenzuspeichern oder mit anderen Worten zu „cachen". Bei den zwischengespeicherten Prozesswerten handelt es sich beispielsweise um sich im Vergleich zur Abfragehäufigkeit nur langsam ändernde oder um gar nicht ändernde Prozesswerte oder aber um Parameter, die von einem zugriffberechtigten Dritten eingegeben wurden. Bei einer erneuten Abfrage stellte die Zwischenspeicher- oder auch Caching-Routine genannte Bearbeitungsroutine den angeforderten Prozesswert zur Verfügung, ohne dass von dem Ausgangsmodul auf das Zielmodul zugegriffen wurde. Auf diese Weise wird der Datenaustausch beschleunigt.

Weiterhin sind zahlreiche weitere Bearbeitungsroutinen vorstellbar, die an dieser Stelle nicht abschließend aufgezählt werden können. So kann eine Bearbeitungsroutine beispielsweise eine sogenannte Enrichment-Routine sein, die kodierte Daten des Zielmoduls in benutzerverständliche Daten umwandelt. Dabei legt die Enrichment-Routine die zusätzlichen benutzerverständlichen Daten in dem Zusatzspeicherbereich jedes Auftrags ab.

Zweckmäßigerweise ist wenigstens eine der Bearbeitungsroutinen eine Fehleranalyseroutine, welche jeden Auftrag auf das Vorliegen von Fehlern hin überprüft. Hierbei kann es sich um jedes beliebige Fehleranalysetool handeln. So können die Daten beispielsweise dahingehend überprüft werden, ob statt einer natürlichen Zahl oder eines Integers, Buchstaben oder dergleichen eines Benutzers eingegeben wurden. Die Fehlerana lyseroutine kann jedoch auch die Kompatibilität von Protokollen zwischen dem Ausgangsmodul und dem Zielmodul überwachen.

Vorteilhafterweise ist wenigstens eine Bearbeitungsroutine eine Überwachungsroutine, welche die Aufträge jeder Anfrage sowie gegebenenfalls die den Aufträgen zugeordneten Meta- oder Antwortdaten in einer Überwachungsdatei speichert, so dass auf diese Weise dokumentiert werden kann, welches Ausgangsmodul auf welches Zielmodul zugegriffen hat.

Zur Festlegung des Ablaufs der Bearbeitungsroutinen der Bearbeitungskette ist es erfindungsgemäß beispielsweise möglich, eine sogenannte Konfigurationsdatei vorzusehen, auf die vor der Bearbeitung der Anfrage durch die Bearbeitungskette zugegriffen wird. Die Konfigurationsdatei kann beispielsweise in einem dynamischen Speicherbereich abgelegt sein, der von einem permanent ablaufenden Laufzeitprogramm eines dezentralen Laufzeitsystems verwaltet wird.

Gemäß einer bevorzugten Weiterentwicklung der Erfindung wird in dem Zusatzspeicherbereich eine steuernde Bearbeitungskennung gespeichert, die von jeder Bearbeitungsroutine gelesen wird, bevor diese den zugeordneten Auftrag bearbeitet. Durch die Bearbeitungskennung ist eine von der Reihenfolge des Aufrufs der Bearbeitungsroutinen unabhängige Steuerung der Bearbeitungskette ermöglicht.

Gemäß einer diesbezüglichen Weiterentwicklung wird als Bearbeitungskennung vor der Übergabe des Auftrags an die Bearbeitungskette eine Anfangsbearbeitungskennung gespeichert, die von jeder Bearbeitungsroutine als unbearbeiteter Zustand erkannt wird. Erkennt eine Bearbeitungsroutine einen Auftrag im unbearbeiteten Zustand so prüft die Bearbeitungsroutine an hand einer ihr immanenten inneren Logik gegebenenfalls unter Zugriff auf Metadateien, ob sie und für eine Bearbeitung des Auftrags eingerichtet ist. Gelangt die Bearbeitungsroutine bei der Prüfung des unbearbeiteten Auftrags zur Erkenntnis, dass sie diesen Auftrag bearbeiten kann, wird der Auftrag von der Bearbeitungsroutine schließlich bearbeitet.

Gemäß einer diesbezüglichen Weiterentwicklung wird als Bearbeitungskennung vor der Übergabe des Auftrags an die Bearbeitungskette eine Anfangsbearbeitungskennung gespeichert, die von einer bestimmten Bearbeitungsroutine als eigene Bearbeitungskennung erkannt wird und für eine Bearbeitung des Auftrags durch diese Bearbeitungsroutine sorgt. Auf diese Weise kann bereits vor der Übergabe der Anfrage an die Bearbeitungskette festgelegt, welcher Auftrag von welcher Bearbeitungsroutine bearbeitet wird. Dabei wird der Auftrag nur von der Bearbeitungsroutine bearbeitet der seine eigene, also seine ihm zugewiesene Bearbeitungskennung, erkennt.

Weiterhin kann es zweckmäßig sein, dass von die jeweils bearbeitende Bearbeitungsroutine eine neue Bearbeitungskennung in den Zusatzspeicherbereich einschreibt. Anhand der neuen Bearbeitungskennung erkennt eine nachfolgende Bearbeitungsroutine, dass die Aufgabe bereits durch eine andere Bearbeitungsroutine bearbeitet wurde und kann von einer weiteren Bearbeitung absehen. Bei der neuen Bearbeitungskennung kann es sich beispielsweise um die eigene Kennung der Bearbeitungsroutine handeln.

Gemäß einer weiteren vorteilhaften Weiterentwicklung wird von einer den jeweiligen Auftrag bearbeitenden Bearbeitungskennung als Bearbeitungskennung eine Aufrufkennung eingeschrieben, mit der die Bearbeitung des Auftrags durch eine be stimmte nachfolgende Bearbeitungsroutine oder eines Zielmoduls festgelegt ist. Auf diese Weise kann die Bearbeitung der Aufträge durch die Bearbeitungsroutinen selbst festgelegt werden. Zur Änderung der Bearbeitung müssen lediglich die Bearbeitungsroutinen, die beispielsweise in einem dynamischen Speicherbereich eines Laufzeitsystems abgelegt sind, verändert werden. Eine gesonderte Konfigurationsdatei zur Festlegung des Aufrufs der Bearbeitungsroutinen kann somit überflüssig werden. Auf diese Art und Weise kann auch ein unnötiger Zugriff eines Auftrags auf ein Zielmodul vermieden werden.

Zweckmäßigerweise speichert das Zielmodul in dem Zusatzspeicherbereich Antwortdaten. Der Speicherbereich der Antwortdaten wird somit bereits vor der Bearbeitung der Anfrage durch die Bearbeitungskette festgelegt, so dass ein wiederholtes Umkopieren der Antwortdaten bei der Bearbeitung der zum Ausgangsmodul zurücklaufenden Anfrage vermieden ist.

Zweckmäßigerweise ist eine der Bearbeitungsroutinen eine Multiplexroutine, wobei das Zielmodul aus verteilt angeordneten Zielmodul-Untereinheiten besteht. Eine solche Multiplexroutine ist beispielsweise dann vorteilhaft, wenn sich eine Anfrage auf verteilt angeordnete Zielmodul-Untereinheiten bezieht. Ist das Ausgangsmodul beispielsweise eine Kommunikationseinheit, beispielsweise ein Einzelplatzrechner, möchte der Nutzer des Einzelplatzrechners nicht mit den einzelnen Untereinheiten des Zielmoduls getrennt kommunizieren. Die Multiplexschicht stellt daher eine zentrale Anfragestelle für das Ausgangsmodul bereit, die auf eine Anfrage hin auf die unterschiedlichen Zielmodul-Untereinheiten zugreift und für das Zielmodul einheitliche Anfragedaten bereitstellt. Die Multiplexroutine setzt nun die zweckmäßige Bearbeitungsken nung der unterliegenden Zielmoduleinheiten fest und gibt dann die Anfrage an alle Zielmoduluntereinheiten weiter.

Vorteilhafterweise sind das Ausgangsmodul und das Zielmodul Teile eines dezentralen Laufzeitsystems. Das dezentrale Laufzeitsystem besteht üblicherweise sowohl aus Hardware- als auch aus Softwarekomponenten. Hierbei handelt es sich beispielsweise um eine aus lokalen Schutzgeräten sowie einer zentralen Leitstelle bestehende Leitstellenanlage, die zur Steuerung und Überwachung der Schutzgeräte vorgesehen ist. Die Schutzgeräte sind beispielsweise mit Spannungs- oder Stromwandlern verbunden, die primärseitig mit einem Netzzweig eines Energieverteilungsnetzes gekoppelt sind. Sekundärseitig sind die Stromwandler mit Stromunterbrechern verbunden, die den Stromfluss im Netzzweig unterbrechen, wenn, beispielsweise im Kurzschlussfall, ein Schwellenwert überschritten wird.

Gemäß einer diesbezüglichen Weiterentwicklung weist das Laufzeitsystem wenigstens einen Netzserver mit einem Serverprogramm und wenigstens einen Clientrechner mit einem Browserprogramm auf, wobei jedes Browserprogramm auf das Serverprogramm über das Internet zugreift. Auf diese Weise ist es beispielsweise möglich, auf bestimmte Prozesswerte einer Leitstellenanlage über das Internet abzufragen.

Gemäß einer bevorzugten Weiterentwicklung werden jedem Auftrag Lokalisationsdaten beigelegt, mit denen der Weg der Anfrage im Laufzeitsystem bestimmt ist, wobei eine der Bearbeitungsroutinen eine Tracing-Routine, welche den Weg der Anfrage anhand der Lokalisationsdaten überprüft und in Abhängigkeit der Überprüfung Sicherheitsparameter erzeugt. Aufgrund dieser Sicherheitsparameter kann nun entweder die An zeige oder die Weiterleitung der Anfrage gesteuert werden. Ist beispielsweise ein Nutzer des Ausgangsmoduls über ein sogenanntes Intranet an das Laufzeitsystem angeschlossen, sind in der Regel weniger Bedenken hinsichtlich der Datensensibilität oder -sicherheit erforderlich, da der Zugang zum Intranet durch Unberechtigte in der Regel erschwert ist. Bei lokalen Anwendungen können Sicherheitsbedenken nahezu vollständig aufgehoben sein, während bei einem Zugriff über das Internet nur unsensible Daten oder Prozesswerte angezeigt werden.

Vorteilhafterweise ist wenigstens eine der Bearbeitungsroutinen eine Scheduling-Routine, welche die Anfrage auf verschiedene Stationen des Laufzeitsystems verteilt, wobei jede Station einen Teil der Anfrage bearbeitet. Die Scheduling-Routine kann beispielsweise anhand der Bearbeitungskennung festlegen, welche der nachfolgenden Bearbeitungsroutinen einer ersten Station und welche der nachfolgenden Bearbeitungsroutinen einer zweiten oder dritten Station für welchen Auftrag der Anfrage zuständig ist. Auf diese Weise wird die Bearbeitung der Anfrage von mehreren Stationen parallel durchgeführt und somit beschleunigt, wobei eine redundante oder doppelte Bearbeitung eines Auftrags von verschiedenen gleich arbeitenden Stationen des Laufzeitsystems vermieden ist. Die Stationen sind vorzugsweise einander entsprechend oder identisch aufgebaute Hardwarekomponenten des Laufzeitsystems und vorzugsweise verschiedene parallel arbeitende CPU-Einheiten.

Weitere zweckmäßige Ausgestaltungen und Vorteile der Erfindung sind Gegenstand der nachfolgenden Beschreibung mit Bezug auf die Figuren der Zeichnungen, wobei
1 ein Flussdiagramm zur schematischen Darstellung des erfindungsgemäßen Verfahrens zeigt.
1 zeigt ein Flussdiagramm zur Verdeutlichung des erfindungsgemäßen Verfahrens. Schematisch ist eine Leitstellenanlage 1 dargestellt, die aus lokalen Schutzgeräten 2 und 3 sowie einer zentralen Leitstelle 4 zur Steuerung und Überwachung der Schutzgeräte 2, 3 besteht. Die Schutzgeräte 2 und 3 sind mit figürlich nicht dargestellten Stromwandlern verbunden, die primärseitig mit einem ebenfalls nicht gezeigten Netzzweig eines Energieverteilungsnetzes gekoppelt sind. Der zum Strom im Netzzweig proportionale sekundärseitige Wandlerstrom wird von einer Messwerterfassungseinheit des Schutzgerätes 2 unter Gewinnung von Abtastwerten abgetastet und die Abtastwerte anschließend zu digitalen Stromwerten digitalisiert. Die Schutzgeräte 2 oder 3 können zweckmäßige Schalter oder Stromunterbrecher auslösen, die den Stromfluss im Netzzweig unterbrechen, wenn beispielsweise die digitalen Stromwerte, etwa in einem Kurzschlussfall, einen Schwellenwert überschreiten. Dabei sind die Schutzgeräte 2 oder 3 in unmittelbarer Umgebung des Netzzweiges also des Primärleiters angeordnet.
Die Leitstelle 4 ist zur Überwachung und Steuerung der Schutzgeräte 2 oder 3 vorgesehen. Dazu ist sie über ein zweckmäßiges figürlich nicht dargestelltes Kommunikationsnetzwerk mit den Schutzgeräten 2 und 3 verbunden. Zur Gewährleistung eines sicheren Datenaustauschs zwischen den Schutzgeräten 2 oder 3 und der Leitstelle 4 ist ein fortwährend ablaufendes Laufzeitprogramm 5 vorgesehen, das über die Hardwarekomponenten des Laufzeitsystems verteilt ist. Dabei greift das Laufzeitprogramm 5 über Hardwaretreiber 6 auf Hardwareschnittstellen der Bauteile 2, 3, 4 der Leitstellenanlage 1 zu. So sind beispielsweise digitale Stromwerte des Schutzgerätes 2 in einem Register des Schutzgerätes 2 abge legt und können der Leitstelle 4 über das nicht dargestellte Kommunikationsnetzwerk zugeführt werden, wobei die Hardwaretreiber 6 zusammen mit dem Laufzeitprogramm 5 die Adressierung und die Steuerung des Datenflusses übernehmen.
Um die Zustände der Bauteile 2, 3 oder 4 der Leitstellenanlage 1 von außen, also von nicht in das Kommunikationsnetz der Leitstellenanlage 1 eingebundenen Standorten überwachen zu können, sind Kommunikationseinheiten wie beispielsweise ein ortsfester Einzelplatzrechner 7, ein Laptop 8 oder ein sogenanntes PDA 9 vorgesehen, die direkt oder über einen Modemanschluss, ISDN, DSL oder einer schnurlosen lokalen Netzverbindung an das sogenannte Internet angeschlossen sind. Das Laufzeitsystem umfasst einen Internet-Rechner, auf dem ein Serverprogramm des Laufzeitprogramms 5 abläuft. Die Kommunikationseinheiten greifen mittels ihrer Browserprogramme 14 auf das Serverprogramm über die Leitungen des Internets zu. Einem Nutzer ist es daher möglich, über das Internet Prozesswerte der Leitstellenanlage 1 abzufragen und/oder diese zu steuern.
Zur Steuerung des Datenaustauschs zwischen den Komponenten 2, 3 und 4 der Leitstellenanlage 1 und den Kommunikationseinheiten 7, 8 und 9 ist eine Bearbeitungskette 10 vorgesehen, die aus nacheinander ablaufenden Bearbeitungsroutinen 11 zusammengesetzt ist. Um einen reibungslosen Datenaustausch zwischen den Bearbeitungsroutinen 11 bei beliebiger Reihenfolge zu ermöglichen, weisen diese softwareseitig jeweils eine einheitliche Eingangsschnittstelle auf, wobei die zu steuernden und überwachenden Daten von der jeweils bearbeitenden Bearbeitungsroutine der Eingangsschnittstelle der nachfolgenden, anschließend aufgerufenen Bearbeitungsroutine übergeben werden.
Zur Abfrage des vom Schutzgerät 2 digitalisierten Stromwertes stellt ein Anwender beispielsweise mit dem PDA 9 über eine drahtlose sogenannte Bluetooth-Verbindung den physikalischen Anschluss seines PDAs an das Internet her. Anschließend meldet sich der Nutzer über sein PDA 9 unter Angabe seines Benutzernamens und seines Kennwortes am Laufzeitprogramm 5 an. Anschließend wählt er beispielsweise aus einem ihm angezeigten Schutzgerätebaum das Schutzgerät 2 und den vom Schutzgerät 2 benötigten Prozesswert aus. Das Laufzeitprogramm 5 erzeugt in Abhängigkeit der Auswahl am PDA 9 eine Bauteilkennung als Quelldatenkennung, die für das Schutzgerät 2 spezifisch ist. Mit anderen Worten wird eine Bauteiladresse in Abhängigkeit der Auswahl seitens des Benutzers erzeugt. Weiterhin wird eine Registeradresse zur Auswahl des gewünschten Stromwertes generiert. Das Laufzeitprogramm 5 erzeugt ferner Steuerungsdaten, in diesem Fall ein sogenanntes „Read-Signal", mit dem der adressierten Hardwareschnittstelle mitgeteilt wird, dass das adressierte Register ausgelesen werden soll. Vor dem Durchlaufen der Bearbeitungskette 10 wird den Daten weiterhin eine Benutzerkennung in Abhängigkeit des Benutzernamens beigelegt.
Bei einer Anfrage auf Darstellung des digitalen Stromwertes des Schutzgerätes 2 durchlaufen diese Anfragedaten die Bearbeitungskette 10 in eine Anfragerichtung 12.
In dem gezeigten Ausführungsbeispiel ist die erste Bearbeitungsroutine eine Sicherheitsroutine 11a, welche die Anfrage an ihrer Eingangsschnittstelle von dem Laufzeitprogramm 5 entgegennimmt. Die Sicherheitsroutine 11a stellt fest, ob der Benutzer zur Datenabfrage berechtigt ist. Dazu vergleicht die Sicherheitsroutine 11a die Benutzerkennung der Abfragedaten mit in der Sicherheitsroutine eingebetteten Listen und gibt nur bei Übereinstimmung der Nutzerkennung mit einem Eintrag in dieser Liste die Daten an die Ausgabeschnittstelle der Sicherheitsroutine 11a weiter.
Von dort aus gelangen die Daten der Anfrage zu der Eingangsschnittstelle einer Zwischenspeicherroutine 11b. Die Zwischenspeicherroutine 11b überprüft, ob es sich bei den angeforderten Prozesswerten um bestimmte Prozessparameter handelt, die softwareseitig beim Erstellen der Zwischenspeicherroutine festgelegt wurden. Solche Prozesswerte sind beispielsweise sich im Vergleich zum Zeitabstand zwischen zwei aufeinander folgenden Abfragen nur langsam oder gar nicht ändernde Prozesswerte. Stellt die Zwischenspeicherroutine 11b fest, dass ein solcher in ihr von einer vorherigen Abfrage gespeicherter bestimmter Prozessparameter abgefragt wird, stellt sie diesen bereits früher abgefragten Prozessparameter zur Verfügung und bricht die weitere Abfrage ab. Andernfalls gibt sie die Daten über ihre Ausgangsschnittstelle direkt an eine Benutzerroutine 11c weiter. Die Benutzerroutine 11c gibt die Daten in der Anfragerichtung 12 ohne Bearbeitung der Daten an eine sogenannte Tracing-Routine 11d weiter, von der das Laufzeitprogramm 5 die bearbeiteten Daten wieder übernimmt. In der Anfragerichtung 12 findet auch durch die Tracing-Routine 11d keine Bearbeitung der Daten statt.
Anschließend greift das Laufzeitprogramm 5 über die zugeordnete Hardwareschnittstelle 6 auf die Prozesswerte des ausgewählten Bauteils 2, des Zielmoduls zu und legt den Daten einen Stromwert als Antwortdaten bei. Anschließend übergibt das Laufzeitprogramm 5 die Daten mit dem Stromwert der Eingangsschnittstelle der Tracing-Routine 11d. Die Daten durchlaufen die Bearbeitungskette 10 nun in Richtung 13. Die Tra cing-Routine 11d überprüft anhand der Anfragedaten, von welcher Stelle aus der Benutzer auf das Laufzeitprogramm 5 zugreift. Hat sich der Benutzer beispielsweise über ein lokales, von außen nur sehr schwer zugängliches Netz an dem Laufzeitprogramm 5 angemeldet, werden die Anzeigemöglichkeiten des Laufzeitprogramms durch Tracing-Routine 11d nicht beschränkt. In dem vorliegenden Beispiel ist der Nutzer des PDAs 9 jedoch über das Internet an dem Laufzeitprogramm 5 angemeldet, so dass aus Gründen der Sicherheit nur eingeschränkt Informationen zur Anzeige gelangen sollen. Dazu legt die Tracing-Routine 11d dem abgefragten Stromwert und den restlichen Anfragedaten weitere Sicherheitsdaten bei, mit denen ein bestimmtes Anzeigeformat des Laufzeitprogramms 5 erzeugt wird. Der Weg der Anfrage von dem PDA 9 bis zum gewählten Bauteil 2 kann anhand von Knotendaten oder Lokalisationsdaten, die jedem Auftrag beigelegt sind, von der Tracing-Routine 11d nachvollzogen werden.
Anschließend gelangen die Daten zur Benutzerroutine 11c, die den Daten je nach der Rolle des Benutzers Anzeigeparameter beilegt. In dem gezeigten Ausführungsbeispiel ist der Nutzer ein Parametrierer, für den auch hochspezialisierte Anzeigedaten, beispielsweise zur Feststellung von Fehlern, hilfreich sein könnten, die für den normalen Benutzer hingegen verwirrend sind. Die Benutzerroutine 11 legt den Anfragedaten daher solche Anzeigeparameter bei, die das Laufzeitprogramm 5 zur Anzeige sämtlicher Daten veranlassen.
Von der Benutzerroutine 11c gelangen die Daten dann zur Zwischenspeicherroutine 11b. In der gezeigten Pfeilrichtung 13 bearbeiten die Zwischenspeicherroutine 11b und die Sicherheitsroutine 11a die Daten nicht. Die Sicherheitsroutine 11a gibt diese schließlich an das Laufzeitprogramm 5, das ent sprechend den Bearbeitungsparametern die Daten auf dem PDA 9 zur Anzeige bringt.
Um ein häufiges Umkopieren der Daten zu vermeiden wird ein bestimmtes Format der Anfrage gewählt, das im Folgenden anhand eines Beispiels beschrieben werden soll. Hierbei ist die Anfrage in einem dynamischen Speicherbereich abgelegt, der von dem Laufzeitprogramm 5 verwaltet wird. Die Bearbeitungsroutinen der Bearbeitungskette greifen in einer Reihenfolge auf die Anfrage zu, die in der Konfigurationsdatei festgelegt ist. Die Anfrage besteht aus einzelnen Aufträgen. Jedem Auftrag ist bereits vor seiner Übergabe an die Bearbeitungskette ein Zusatzspeicherbereich zugeordnet.
Eine gemäß dem erfindungsgemäßen Verfahren aufgebaute Anfrage weist beispielsweise folgende Struktur auf.
Die dargestellte Anfrage weist drei Aufträge auf, wurde beispielsweise von dem PDA 9 als Ausgangsmodul erzeugt und über das Browserprogramm 14 der Bearbeitungskette 11 zugeführt. Die Bearbeitungskette 11 soll der Übersichtlichkeit halber nunmehr aus einer Sicherheitsroutine, einer Zwischenspeicherroutine sowie einer Multiplexroutine bestehen.
1. Bearbeitung durch die Sicherheitsroutine
Von einer Konfigurationsdatei wird zunächst die Sicherheitsroutine aufgerufen. Da als Anfangsbearbeitungskennung in al len Drei Zeilen "Nicht zugeordnet" steht, ist die Sicherheitsroutine unter Berücksichtigung ihrer internen Logik für alle drei Zeilen zuständig. Die Anforderungen in den ersten beiden Zeilen werden von der Sicherheitsroutine anhand der den Datenendpunkten zugeordneten Metadaten als unbedenklich angesehen. Die Anforderung der letzten Zeile, also des dritten Auftrags, wird zurückgewiesen. In der Bearbeitungskennung der letzten Zeile wird die Bearbeitungskennung der Sicherheitsroutine und in dem Speicherbereich für die Antwortdaten der Wert "Zugriff verweigert" geschrieben.
2. Bearbeitung durch die Zwischenspeicherroutine
Da in der Bearbeitungskennung der dritten Zeile schon die Kennung der Sicherheitsroutine steht, kann die Zwischenspeicherroutine nur noch die erste und zweite Zeile, also den ersten und den zweiten Auftrag der Anfrage, bearbeiten. Anhand der Metadaten kann die Zwischenspeicherroutine feststellen, ob die angeforderten Werte bereits in einem Zwischenspeicherbereich dem sogenannten „Cache" stehen und sie dort gegebenenfalls eintragen. In diesem Beispiel steht der erste angeforderte Wert, nämlich der Prozesswert A des Schutzgerätes 1, bereits im Cache und wird deshalb von der Zwischenspeicherroutine in dem Zusatzspeicherbereich des ersten Auftrags als Antwortdatum eingetragen. Als Bearbeitungskennung schreibt die Zwischenspeicherroutine ihre eigenen Bearbeitungskennung in den Zusatzspeicherbereich. Es ergibt sich eine veränderte Anfrage gemäß folgender Tabelle:
3. Bearbeitung durch die Multiplex-Routine
Da in der ersten und dritten Zeile der obigen Anfrage weder die Kennung "Nicht zugeordnet" noch die der Multiplex-Routine zugeordnete Kennung steht, ist die Multiplex-Routine nur noch für den Vorgang des Auftrags gemäß der zweiten Zeile zuständig. Anhand der Metadaten, die zum zugehörigen Datenendpunkt gehören, erkennt die Multiplex-Routine, dass das Schutzgerät 2 für den Auftrag gemäß der zweiten Zeile der Anfrage zuständig ist. Die Multiplex-Routine trägt deshalb als Bearbeitungskennung "Schutzgerät 2" in den Zusatzspeicherbereich des Auftrags gemäß der zweiten Zeile ein, der für Antwortdaten vorgesehene Unterabschnitt des Zusatzspeicherbereichs des zweiten Auftrags wird jedoch noch nicht beschrieben und unverändert gelassen.
Es ergibt sich eine Anfrage gemäß:
4. Bearbeitung durch das eigentliche Zielmodul
Die in den Aufträgen der Anfrage adressierten Zielmodule, die hier ausschließlich aus Hardwarekomponenten bestehen, sind jetzt nur noch für solche Aufträge zuständig, die als Bear beitungskennung im Zusatzspeicherbereich die Bearbeitungskennung des jeweiligen Zielmoduls aufweisen. Die Bearbeitungskennung der Zielmodule wurde zuvor bereits durch die Multiplex-Routine eingefügt. Das adressierte Schutzgerät 2 sucht nun alle Zeilen der Anfrage, in dem seine eigene Kennung im Feld Bearbeitungskennung steht, und schreibt den eigentlichen Prozesswert in das Feld Antwortdaten. Man erhält folgende Struktur:
5. Nochmalige Bearbeitung durch die Zwischenspeicherroutine
Nachdem alle Bearbeitungsschichten durchlaufen wurden, führt die Bearbeitungsschicht 11 auf dem Rückweg der Anfrage abschließende Bearbeitungsschritte durch. Hierbei liest die Zwischenspeicherroutine die Antwortdaten des Zusatzspeicherbereichs des zweiten Auftrags gemäß der zweiten Zeile obiger Anfrage und schreibt diese Daten in ihren Cache. Darüber hinaus erneuert die Zwischenspeicherroutine die Metadaten dieses Datenendpunktes. Die Anfrage selbst bleibt jedoch unverändert.

Claims

Verfahren zum Austauschen von Daten zwischen einem Ausgangsmodul (7, 8, 9) und einem Zielmodul (2, 3, 4), bei dem das Ausgangsmodul (7, 8, 9) eine aus wenigstens einem Auftrag bestehende Anfrage erzeugt, die Anfrage einer aus nacheinander ablaufenden Bearbeitungsroutinen (11a, 11b, 11c, 11d) bestehenden Bearbeitungskette (11) übergeben wird, und jeder Auftrag anschließend auf das ihm mittels einer Zielmoduladresse zugeordnete Zielmodul (2,3,4) zugreift, dadurch gekennzeichnet, dass für jeden Auftrag bereits vor der Übergabe der Anfrage an die Bearbeitungskette (11) ein dem jeweiligen Auftrag zugeordneter Zusatzspeicherbereich reserviert wird.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass in dem Zusatzspeicherbereich eine steuernde Bearbeitungskennung gespeichert wird, die von jeder Bearbeitungsroutine (11a, 11b, 11c, 11d) gelesen wird, bevor diese den Auftrag bearbeitet.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass als Bearbeitungskennung vor der Übergabe des Auftrags an die Bearbeitungskette (11) eine Anfangsbearbeitungskennung gespeichert wird, die von jeder Bearbeitungsroutine (11a, 11b, 11c, 11d) als unbearbeiteter Zustand erkannt wird.
Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass als Bearbeitungskennung vor der Übergabe des Auftrags an die Bearbeitungskette (11) eine Anfangsbearbeitungskennung gespeichert wird, die von einer bestimmten Bearbeitungsroutine (11a, 11b, 11c, 11d) als eigene Bearbeitungskennung erkannt wird und für eine Bearbeitung des Auftrags durch diese Bearbeitungsroutine (11a, 11b, 11c, 11d) sorgt.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass von einer den jeweiligen Auftrag bearbeitenden Bearbeitungsroutine (11a, 11b, 11c, 11d) als Bearbeitungskennung eine Aufrufkennung eingeschrieben wird, mit welcher die Bearbeitung des Auftrags durch jeweils eine bestimmte nachfolgende Bearbeitungsroutine (11a, 11b, 11c, 11d) oder eines Zielmoduls (2, 3, 4) festgelegt ist.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Zielmodul (2, 3, 4) in dem Zusatzspeicherbereich Antwortdaten speichert.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass eine der Bearbeitungsroutinen (11a, 11b, 11c, 11d) eine Multiplexroutine ist, wobei das Zielmodul (2, 3, 4) aus verteilt angeordneten Zielmoduluntereinheiten besteht.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Ausgangsmodul und das Zielmodul (2, 3, 4) Teile eines dezentralen Laufzeitsystems (1) sind.
Verfahren nach Anspruch 8, dadurch gekennzeichnet, dass das Laufzeitsystem (1) einen Netzserver mit einem Serverprogramm und wenigstens einen Client-Rechner mit einem Browserprogramm aufweist, wobei jedes Browserprogramm auf das Serverprogramm über das Internet zugreift.
Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass wenigstens eine der Bearbeitungsroutinen (11a, 11b, 11c, 11d) eine Scheduling-Routine ist, welche die Anfrage auf verschiedene Stationen des Laufzeitsystems verteilt, wobei jede Station einen Teil der Anfrage bearbeitet.