DE102020118246A1

DE102020118246A1 - Verfahren, System und Computerprogramm zum synchronisierten Verarbeiten von Dateneinheiten einer Mehrzahl von Datenquellen

Info

Publication number: DE102020118246A1
Application number: DE102020118246.5A
Authority: DE
Inventors: Mike Vogt; Frank Marten
Original assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Current assignee: Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date: 2020-07-10
Filing date: 2020-07-10
Publication date: 2022-01-13

Abstract

Ausführungsbeispiele der vorliegenden Offenbarung befassen sich mit einem computerimplementierten Verfahren, System und Computerprogramm zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen. Das Verfahren umfasst ein Empfangen (110) von Dateneinheiten von der Mehrzahl von Datenquellen. Jede Dateneinheit ist bis zu einem definierten End-Zeitpunkt gültig. Die empfangenen Dateneinheiten werden einem Satz von Dateneinheiten hinzugefügt (115) und dem Satz von Dateneinheiten angehören, solange die jeweiligen Dateneinheiten gültig sind. Von jeder Datenquelle ist je zumindest eine Dateneinheit in dem Satz von Dateneinheiten umfasst. Das Verfahren umfasst ferner ein Bestimmen (120), als Reaktion auf das Hinzufügen einer Dateneinheit zum Satz von Dateneinheiten, eines frühesten End-Zeitpunkts unter den Dateneinheiten des Satzes von Dateneinheiten. Das Verfahren umfasst ferner ein Verarbeiten (130) des Satzes von Dateneinheiten, falls der früheste End-Zeitpunkt später ist als ein frühester End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde.

Description

Technisches Gebiet
Ausführungsbeispiele der vorliegenden Offenbarung befassen sich mit einem computerimplementierten Verfahren, System und Computerprogramm zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen.
Hintergrund
Die Synchronisierung von mehreren Computer-Prozessen in Bezug auf Daten und Zeit ist ein häufig benötigter Vorgang. Wenn mehrere Prozesse verteilt berechnet werden und miteinander kommunizieren müssen, muss auf die Synchronisierung der Daten und der Zeiten Rücksicht genommen werden. Die Prozesse müssen dabei nicht zwangsweise auf verschiedenen Maschinen befinden, allerdings ist es bedeutend einfacher, wenn sie auf derselben Maschine ausgeführt werden, da dies die Zeitsynchronisierung erleichtert. Die Prozesse tauschen häufig auch Daten untereinander aus, beispielsweise in den folgenden Szenarien. Solch ein Datenaustausch wird beispielsweise bei der gemeinsamen, verteilten Simulation eines komplexen Modells durchgeführt. Dort werden alle Simulatoren synchronisiert, da es sonst zu Fehlern in der Simulation kommen kann, die falsche Ergebnisse zur Folge haben und nicht direkt erkennbar sind. Von sogenannten Crowd-Computing-Anwendungen (Anwendungen, die von einer Gruppe ausgeführt werden) wie Folding@Home, über Computerspiele mit einer hohen Anzahl von weltweit verteilten Nutzern, bis hin zu Sensornetzwerken ist eine solche Synchronisierung nicht nur Wünschenswert, sondern für die Funktionalität häufig zwingend erforderlich.
Dabei ist ein Aspekt die Reihenfolge der Abarbeitung, d.h. wenn ein einzelnes System viele verschiedene Anfragen bekommt, muss es entscheiden, welche Anfrage zu welchem Zeitschritt bearbeitet wird. Dies kann beispielsweise „In-Order“ (in der Reihenfolge) passieren, da es sonst, bei manchen Algorithmen, zu Fehlern in der Berechnung kommen kann. Sensordatenverarbeitungssysteme könnten beispielsweise veraltete Werte vor den aktuellen verarbeiten und fatale Entscheidungen treffen, es könnte in einer verteilten Simulation ein falsches Modell verarbeitet werden oder ein „Treffer“ wird in einem Computerspiel registriert, obwohl der entsprechende Spieler bereits in Deckung war.
Zur Synchronisierung steht bereits eine Vielzahl von Ansätzen zur Verfügung. Ein Ansatz mit dem Titel „global event-driven“ (wörtliche Übersetzung: „global ereignisgetrieben“) basiert auf diskreten Ereignisses, wobei ein globaler Ereignis-Koordinator als Zeit-Referenz und Koordinator genutzt wird (siehe: H. Lin et al: „GECO: Global Event-Driven Co-Simulation Framework for Interconnected Power System and Communication Network,“). Eine globale Liste wird von diesem Koordinator erzeugt und nur ein Prozess darf gleichzeitig ausgeführt werden. Auf dieser Liste basierend wird die Kontrolle an den entsprechenden Prozess übertragen. Dies führt zu einer einfachen Koordination und zu einer Vermeidung von Kollisionen, gleichzeitig ist die Ausführung jedoch auf den einen Prozess beschränkt, womit vorhandene Ressourcen nicht effizient genutzt werden können.
„Discrete Events“ (DEVS, wörtliche Übersetzung: „Diskrete Ereignisse“, siehe: A. C. Chow und B. P. Zeigler: „Parallel Devs: A Parallel, Hierarchical, Modular Modeling Formalism“), ist ein „timed events system“ (System für zeitgesteuerte Ereignisse). Sein modularer und hierarchischer Formalismus wird benutzt, um Systeme zu modellieren und zu analysieren. Die Synchronisation wird durch einen besonderen Kopplungsalgorithmus erreicht. Es existieren verschiedene Algorithmen, allen gemein ist, dass die Prozessberechnung durch Ereignisse ausgelöst wird, welche wiederum weitere Ereignisse erzeugen. Außerdem werden zukünftige interne „transits“ (neue interne Zustände) geplant. Dabei ist für die Nutzung ein tiefes Verständnis der Mechanismus benötigt, auch das zu lösende Problem muss mathematisch formuliert werden, was die Komplexität der Umsetzung erhöht. Durch das Verständnis des Mechanismus wird jedoch auch eine gute Einschätzbarkeit des Verhaltens der Komponenten in verschiedenen Situationen ermöglicht.
In dem Ansatz „Time Stepped“ (Zeitschritt) werden viele verschiedene Synchronisationspunkte vorab definiert. Prozesse laufen zeitlich unabhängig, bis sie einen solchen Punkt erreichen und anhalten, um Informationen auszutauschen. Wenn Informationsaustausch zwischen diesen Punkten nötig wird, muss der Prozess bis zum nächsten Punkt warten, was in unvermeidbaren Verzögerungen resultiert.
Der Ansatz „Conservative“ (Konservativ, siehe: S. Ciraci et al: „Synchronization Algorithms for Co-Simulation of Power Grid and Communication Networks“), wird erreicht durch einen zentralen Makler (der nur Ereignisse zwischen Teilnehmern austauscht). Jeder Berechnungsschritt wird in zwei-Phasen unterteilt und darauf basierend synchronisiert. Die erste Phase wird ausgeführt, wenn alle Prozesse mit ihren Berechnungen fertig sind und der nächste Zeitschritt geplant wird. Ereignisse werden nun verteilt und die zweite Phase wird ausgeführt bevor die Prozesse beginnen den nächsten Zeitschritt zu planen. Dieser Zeitschritt, aus der ersten Phase, wird mit einem der folgenden Algorithmen bestimmt:

Mit dem Algorithmus „Conservative“ (Konservativ) wird auf den kleinsten gemeinsamen Zeitschritt aller Prozesse synchronisiert. Wenn die Berechnung beginnt bestimmen alle Teilnehmer die Zahl der Ereignisse, die sie Senden und Empfangen müssen. Dadurch können sie bestimmen, ob Ereignisse noch übertragen werden müssen; wenn das nicht der Fall ist, dann kann die Berechnung voranschreiten. Dadurch wird eine In-Order-Ausführung ermöglicht, es können jedoch sogenannte „Deadlocks“ (Stillstände) passieren, da immer Nachrichten ausgetauscht werden, wenn Ereignisse fehlen.

Der Algorithmus „Active Set Conservative“ (Konservativ auf der aktiven Menge) funktioniert analog zum Vorherigen, allerdings erlaubt diese Methode das Verarbeiten von Ereignissen zwischen Synchronisations-Punkten. Auch hier ist eine In-Order-Verarbeitung gegeben, zudem ist eine schnellere Reaktion möglich, allerdings können auch hier Deadlocks auftreten.
Der Algorithmus „Reactive Conservative“ (Reaktiv konservativ) funktioniert analog zur ersten Methode, jedoch müssen Prozesse nicht nach jedem Zeitschritt Ereignisse generieren. Der Prozess wird (nur) reagieren, wenn etwas empfangen wurde, oder wenn der nächste Synchronisations-Punkt erreicht wird. Dadurch wird eine schnelle Reaktion ermöglicht, jedoch ist der Ablauf schwer kontrollierbar, und es ist unklar, wann Prozesse agieren sollen.
Im Algorithmus „Speculative Recompute“ (spekulative Neuberechnung) müssen Prozesse nur synchronisieren, wenn sie Ereignisse austauschen. Ein spekulativer Prozess wird verwendet, um diesen Zeitpunkt vorherzusagen. Ansonsten laufen die Prozesse ohne Synchronisation. Wenn ein sehr häufiger Austausch detektiert wird, wird „Conservative“ verwendet. Ein solcher Ansatz kann die Leistung erhöhen, jedoch ist solch ein spekulativer Prozess schwer zu entwickeln, und der Leistungsgewinn ist stark von dem Szenario abhängig.
HLA (High-Level Architecture, Architektur auf hohem Niveau, siehe Z. Jiang: „A Novel Simulation Time and Wall Clock Time Synchronization Algorithm for HLA‟), als Standard (IEEE, Institute of Electrical and Electronics Engineers, Institut der Elektro- und Elektronikingenieure, 1518) verwendet verschiedene Algorithmen zur Synchronisation. Dabei wird auf ein komplexes Schema gesetzt, und auf eine Runtime Infrastructure (RTI, Laufzeit-Infrastruktur), die eine dieser Schemata voraussetzt. Dabei werden die Komponenten in Föderationen unterteilt und können über die RTI kommunizieren. Dieser Ansatz ist gut erforscht, jedoch muss die HLA-Struktur übernommen werden, was die Komplexität der Implementierung erhöht.
Der Ansatz „mosaik“ (siehe A. M. Kosek et al: „Evaluation of smart grid control strategies in co-simulation — integration of IPSYS and mosaik‟) funktioniert ähnlich wie „Global Ereignis Driven“. Jeder Prozess liefert eine Beschreibung mit. Basierend auf dieser Beschreibung berechnet mosaik einen Fahrplan mit vordefinierten Synchronisations-Punkten und sendet Berechnungsstart-Befehle zu jedem Prozess. Dies ermöglicht eine einfachere Koordination sowie eine Kollisionsvermeidung. Jedoch können nur zu bestimmten Zeitpunkten Ereignisse ausgetauscht werden, auch wird zentrale Komponente benötigt, die die Befehle verteilt, was einen „single point of failure“ (Einzelner Versagenspunkt) darstellt. Zudem müssen Prozesse auf andere warten.
Der Ansatz „Models of Computation“ (Berechnungsmodelle, siehe C. Ptolemaeus: „System Design, Modeling, and Simulation Using Ptolemy II“), definiert neun verschiedene Modi, die austauschbar sind und gemeinsam arbeiten können. Grundsätzlich unterscheiden sie sich durch ihre Art wie sie die Zeit voranschreiten lassen: „untimed“ (reaktiv) und „timed“ (dicht gepackte Zeit). Jeder Prozess benötigt einen „Direktor“, der für die Ausführung verantwortlich ist. Je nach Auswahl des Modus besteht die Wahl zwischen keiner Synchronisation oder einer sehr komplexen Synchronisation, die mehrere Zeitskalen definiert, um parallele Ereignisse eindeutig zu identifizieren. Dabei werden zusätzliche Komponenten für die Ausführung benötigt, auch ist eine In-Order-Ausführung nicht immer gewährleistet. Jedoch kann eine sehr feine zeitliche Aufteilung ermöglicht werden.
Der Ansatz „EPOCHS“ (Epochen, siehe K. Hopkinson et al: „EPOCHS: A Platform For Agent-Based Electric Power And Communication Simulation Built From Commercial Off-The-Shelf Components“) basiert auf einer Middleware (Vermittlungssoftware), die dieses Problem löst, indem alle Prozesse ausgeführt werden können, bis ein vorab definierter Zeitpunkt von allen Prozessen erreicht wird, die dann Ereignisse austauschen und danach weiterarbeiten dürfen bis zum nächsten Zeitpunkt, der von der Middleware definiert wird. Dadurch kann eine Kollisionsvermeidung gelingen, zudem besteht eine erhöhte Kontrolle. Allerdings können Ereignisse wiederum nur zu bestimmten Zeitpunkten ausgetauscht werden und Prozesse müssen auf andere warten.
Das „Client - Server Modell“ beschreibt eine Klasse an Algorithmen, die einen zentralen Entscheider haben. Dieser entscheidet, wann Daten ausgetauscht werden und ruft jeden Prozess einzeln auf. Dabei geht, durch das Warten auf andere Prozesse, viel Rechenleistung verloren, jedoch ist der Ansatz einfach zu Implementieren.
Zusammenfassung
Es besteht der Bedarf nach einem verbesserten Konzept zur synchronisierten Verarbeiten von Dateneinheit durch eine Mehrzahl von Prozessen.
Diesem Bedarf wird durch den Gegenstand der unabhängigen Ansprüche Rechnung getragen.
Ausführungsbeispiele der vorliegenden Offenbarung schaffen ein computerimplementiertes Verfahren zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen. Das Verfahren umfasst ein Empfangen von Dateneinheiten von der Mehrzahl von Datenquellen. Jede Dateneinheit ist bis zu einem definierten End-Zeitpunkt gültig. Die empfangenen Dateneinheiten werden einem Satz von Dateneinheiten hinzugefügt und dem Satz von Dateneinheiten angehören, solange die jeweiligen Dateneinheiten gültig sind. Von jeder Datenquelle ist je zumindest eine Dateneinheit in dem Satz von Dateneinheiten umfasst. Das Verfahren umfasst ferner ein Bestimmen, als Reaktion auf das Hinzufügen einer Dateneinheit zum Satz von Dateneinheiten, eines frühesten End-Zeitpunkts unter den Dateneinheiten des Satzes von Dateneinheiten. Das Verfahren umfasst ferner ein Verarbeiten des Satzes von Dateneinheiten, falls der früheste End-Zeitpunkt später ist als ein frühester End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde. Durch ein solches Verfahren kann jeweils ein Satz von Daten zusammengestellt werden, der zusammen ausschließlich gültige Dateneinheiten umfasst. Diese Dateneinheiten können dann jeweils zusammen blockweise verarbeitet werden.
Beispielsweise kann jede Dateneinheit Information über den definierten End-Zeitpunkt der Dateneinheit umfassen. Diese Informationen kann verwendet werden, um einerseits die Dateneinheit aus dem Satz von Dateneinheiten zu entfernen, wenn sie nicht mehr gültig ist. Andererseits kann die Berechnung des frühesten End-Zeitpunkts durchgeführt werden.
Beispielsweise kann der Satz von Dateneinheiten zusammen verarbeitet werden. Beispielsweise kann der Satz von Dateneinheiten jeweils ausschließlich Dateneinheiten umfassen, die gleichzeitig gültig sind, und die daher auch problemlos zusammen verarbeitete werden können.
In manchen Ausführungsbeispielen kann die Mehrzahl von Datenquellen, und damit auch die Dateneinheiten des Satzes von Dateneinheiten, vordefiniert sein. Somit kann festgestellt werden, ob der Satz von Dateneinheiten vollständig sind, d.h. dass der Satz von Dateneinheiten von jeder Datenquelle zumindest eine gültige Dateneinheit umfasst.
Beispielsweise können die Dateneinheiten Zwischenergebnisse einer verteilten Simulation sein. Das Verarbeiten des Datensatzes kann einem Ausführen eines Teils der verteilten Simulation durch einen Rechenknoten entsprechen. Die Datenquellen können weitere Rechenknoten zum Berechnen der verteilten Simulation sein. In verteilten Simulationen wird meist von jedem Rechenknoten ein Teil der Simulation durchgeführt. Dieser Teil der Simulation benötigt jedoch meist die Ergebnisse seiner Nachbarn, so dass das vorliegend vorgestellte Verfahren genutzt werden kann, um die Daten zwischen den Rechenknoten zeit-synchronisiert auszutauschen.
In manchen Ausführungsbeispielen umfasst das Verfahren ferner ein Bereitstellen eines Ergebnisses des Teils der verteilten Simulation als Dateneinheit an ein oder mehrere weitere Rechenknoten. Somit kann das von dem jeweiligen Rechenknoten berechnete Zwischenergebnis den anderen Rechenknoten weitergeleitet werden.
In einem anderen Ausführungsbeispiel können die Dateneinheiten Sensordaten von Sensoren einer Maschine oder einer Anlage sein. Das Verarbeiten des Satzes von Dateneinheiten kann Berechnen und Bereitstellen eines Steuersignals für die Maschine oder Anlage basierend auf den Sensordaten umfassen. Auch für die Bereitstellung eines Steuersignals für eine Maschine oder Anlage ist es von hoher Relevanz, dass jeweils ausschließlich Daten zusammen verarbeitet werden, die auch „zusammengehören“, also gleichzeitig gültig sind.
Ausführungsbeispiele der vorliegenden Offenbarung schaffen ferner ein Programm mit einem Programmcode zum Durchführen des Verfahrens, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Ausführungsbeispiele der vorliegenden Offenbarung schaffen ferner ein computerimplementiertes System zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen. Das System umfasst eine Schnittstelle und ein oder mehrere Prozessoren. Das System ist ausgebildet zum Ausführen des zuvor vorgestellten Verfahrens.
Figurenliste
Einige Beispiele von Vorrichtungen und/oder Verfahren werden nachfolgend bezugnehmend auf die beiliegenden Figuren lediglich beispielhaft näher erläutert. Es zeigen:

1a zeigt ein Flussdiagramm eines Ausführungsbeispiels eines computer-implementierten Verfahrens zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen;
1b zeigt ein schematisches Blockdiagramm eines Ausführungsbeispiels eines computer-implementierten Systems zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen;
2 zeigt ein schematisches Diagramm einer Gültigkeit von verschiedenen Dateneinheiten entlang einer Zeitachse; und
3 zeigt ein schematisches Diagramm einer Interaktion zwischen verschiedenen Datenquellen.

Beschreibung
Verschiedene Beispiele werden nun ausführlicher Bezug nehmend auf die beiliegenden Figuren beschrieben, in denen einige Beispiele dargestellt sind. In den Figuren können die Stärken von Linien, Schichten und/oder Bereichen zur Verdeutlichung übertrieben sein. Gleiche oder ähnliche Bezugszeichen beziehen sich in der gesamten Beschreibung der Figuren auf gleiche oder ähnliche Elemente, die bei einem Vergleich miteinander identisch oder in modifizierter Form implementiert sein können, während sie die gleiche oder eine ähnliche Funktion bereitstellen.
Es versteht sich, dass, wenn ein Element als mit einem anderen Element „verbunden“ oder „gekoppelt“ bezeichnet wird, die Elemente direkt, oder über ein oder mehrere Zwischenelemente, verbunden oder gekoppelt sein können. Wenn zwei Elemente A und B unter Verwendung eines „oder“ kombiniert werden, ist dies so zu verstehen, dass alle möglichen Kombinationen offenbart sind, d. h. nur A, nur B sowie A und B, sofern nicht explizit oder implizit anders definiert. Eine alternative Formulierung für die gleichen Kombinationen ist „zumindest eines von A und B“ oder „A und/oder B“. Das Gleiche gilt, mutatis mutandis, für Kombinationen von mehr als zwei Elementen.
Sofern nicht anderweitig definiert, werden alle Begriffe (einschließlich technischer und wissenschaftlicher Begriffe) hier in ihrer üblichen Bedeutung auf dem Gebiet verwendet, zu dem Beispiele gehören.
1a zeigt ein Flussdiagramm eines Ausführungsbeispiels eines computer-implementierten Verfahrens zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen 20. Das Verfahren umfasst ein Empfangen 110 von Dateneinheiten von der Mehrzahl von Datenquellen. Jede Dateneinheit ist bis zu einem definierten End-Zeitpunkt gültig. Die empfangenen Dateneinheiten werden einem Satz von Dateneinheiten hinzugefügt 115. Die empfangenen Dateneinheiten gehören dem Satz von Dateneinheiten an, solange die jeweiligen Dateneinheiten gültig sind. Von jeder Datenquelle ist je zumindest eine Dateneinheit in dem Satz von Dateneinheiten umfasst. Das Verfahren umfasst ferner ein Bestimmen 120, als Reaktion auf das Hinzufügen einer Dateneinheit zum Satz von Dateneinheiten, eines frühesten End-Zeitpunkts unter den Dateneinheiten des Satzes von Dateneinheiten. Das Verfahren umfasst ferner ein Verarbeiten 130 des Satzes von Dateneinheiten, falls der früheste End-Zeitpunkt später ist als ein frühester End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde.
1b zeigt ein schematisches Blockdiagramm eines Ausführungsbeispiels eines entsprechenden computer-implementierten Systems 10 zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen. Das System umfasst eine Schnittstelle 12 und ein oder mehrere Prozessoren 14. Das System ist ausgebildet zum Ausführen des Verfahrens von 1a. insbesondere können die ein oder mehreren Prozessoren ausgebildet sein, um die funktionalen Schritte des Verfahrens auszuführen, während die entsprechenden Daten oder Signale über die Schnittstelle empfangen oder bereitgestellt werden können.
Die folgende Beschreibung bezieht sich sowohl auf das Verfahren von 1a als auch auf das entsprechende System der 1b.
Ausführungsbeispiele der vorliegenden Offenbarung beziehen sich auf ein computerimplementiertes Verfahren, auf ein computer-implementiertes System und ein Computerprogramm zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen. Dabei bezieht sich der Term „synchronisiertes Verarbeiten“ darauf, dass Dateneinheiten, die zu einem gemeinsamen Zeitpunkt gültig sind, zusammen verarbeitet werden, wodurch eine Zeitsynchronisierung in der Verarbeitung der Daten erreicht wird. In anderen Worten werden durch das synchronisierte Verarbeiten des Satzes von zu verarbeitenden Dateneinheiten die Dateneinheiten des Satzes in einer zeitsynchronisierten Weise zusammen verarbeitet. Zudem werden die Daten von verschiedenen Datenquellen zur Verarbeitung kombiniert, wodurch eine Datensynchronisierung erreicht wird.
Das Verfahren basiert auf dem Konzept des „Satzes von Dateneinheiten“, der mehrere Dateneinheiten umfasst, und der (ausschließlich) Dateneinheiten umfasst, die gültig sind. Dabei umfasst der Satz von Dateneinheiten beispielsweise eine vordefinierte Menge von Dateneinheiten. Eine Dateneinheit kann beispielsweise einem Datenpaket, einer zusammenhängenden Sequenz von Datenpaketen oder einem Signal entsprechen. Eine Dateneinheit kann beispielsweise Zwischenergebnisse einer Simulation oder Mess- oder Stellwerte eines Sensors oder Aktors umfassen. Diese Dateneinheiten können einem bestimmten Thema (auch engl. Topic) zugewiesen sein. Findet die Datenverarbeitung als verteilte Simulation statt, so können mögliche Themen beispielsweise „Simulationszwischenergebnis von Knoten A“, oder „Simulationszwischenergebnis von Knoten B“ sein. Findet die Datenverarbeitung im Rahmen einer Steuerung/Reglung einer Anlage oder Maschine statt, so können mögliche Themen beispielsweise „Messwert von Sensor A“ oder „Eingabewert von Eingabequelle B“ sein. In anderen Worten definieren die Themen eines Satzes von Dateneinheiten diejenigen Dateneinheiten, die benötigt werden, um die Verarbeitung durchzuführen. In anderen Worten kann der Satz von Dateneinheiten eine Mehrzahl von Themen, und damit auch eine Mehrzahl von Dateneinheiten, definieren, die benötigt werden, um die Verarbeitung durchzuführen. In anderen Worten können die Mehrzahl von Datenquellen, und damit auch die Dateneinheiten des Satzes von Dateneinheiten, oder die Themen des Satzes von Dateneinheiten, vordefiniert sein.
Dabei stammen die Mehrzahl von Dateneinheiten von der Mehrzahl von Datenquellen. Dabei können beispielsweise ein oder mehrere Dateneinheiten von der gleichen Datenquelle stammen. Beispielsweise kann der Satz von Datenquellen beispielsweise zu jedem Thema nur eine einzige Dateneinheit umfassen. Dies kann etwa dadurch geschehen, dass jede Dateneinheit bis zu einem definierten End-Zeitpunkt gültig ist. Dabei kann der definierte End-Zeitpunkt von einem Zeitpunkt abhängig sein, an dem eine aktuellere Dateneinheit zu dem gleichen Thema verfügbar (und gültig ist). In anderen Worten kann der definierte End-Zeitpunkt davon abhängen, ab wann eine nachfolgende Dateneinheit von der Datenquelle (zu dem gleichen Thema) verfügbar ist. Dabei kann der definierte End-Zeitpunkt beispielweise ein absoluter Zeitpunkt sein (etwa ein Zeitpunkt in einem von den Datenquellen und dem System genutzten Zeitsystem), oder ein Zeitpunkt relativ zu dem Empfang der jeweiligen Dateneinheit. Dies kann beispielsweise bei Sensoren der Fall sein, die in vordefinierten Abständen Messwerte erfassen und als Dateneinheiten bereitstellen. Alternativ kann der definierte Zeitpunkt von einem Zeitpunkt abhängig sein, an dem eine nachfolgende Dateneinheit von der gleichen Datenquelle (und zu dem gleichen Thema) empfangen wird. Dies kann beispielsweise in einer verteilten Simulation angewendet werden. Dabei kann jede Dateneinheit eine Information über den definierten End-Zeitpunkt der Dateneinheit umfasst.
Das Konzept der Datenquellen und des Systems kann im Rahmen der vorliegenden Offenbarung weit ausgelegt werden. Die Datenquellen können beispielsweise Computer-Prozesse sein, die auf dem System oder auf anderen Systemen ausgeführt werden. Alternativ können die Datenquellen beispielsweise Sensoren oder Aktoren sein, etwa Sensoren oder Aktoren einer Maschine oder einer Anlage.
Die Dateneinheiten werden dem Satz von Dateneinheiten hinzugefügt, wenn sie empfangen werden. Zudem können die Dateneinheiten nach dem jeweiligen definierten End-Zeitpunkt aus dem Satz von Dateneinheiten entfernt werden. Dabei kann der Satz von Dateneinheiten jeweils diejenigen Daten umfassen, die gleichzeitig gültig sind. Diese Dateneinheiten können nun nachfolgend verarbeitet werden.
Zunächst kann bestimmt werden, inwiefern sich die Datenlage durch das Hinzufügen der jeweiligen Dateneinheit geändert hat. Das Verfahren umfasst das Bestimmen 120, als Reaktion auf das Hinzufügen einer Dateneinheit zum Satz von Dateneinheiten, eines frühesten End-Zeitpunkts unter den Dateneinheiten des Satzes von Dateneinheiten. In anderen Worten wird von denjenigen Dateneinheiten, die nach dem Hinzufügen der Dateneinheit dem Satz von Dateneinheiten angehörigen, der früheste End-Zeitpunkt bestimmt. Dabei ist der früheste End-Zeitpunkt von den definierten End-Zeitpunkten der Dateneinheiten des Satzes derjenige, der zeitlich am frühesten liegt. Diese Aufgabe wird jedes Mal ausgeführt, wenn eine neue Dateneinheit hinzugefügt wird. Der dabei bestimmte späteste End-Zeitpunkt kann dabei jeweils gespeichert werden, zum Vergleich mit einem frühesten End-Zeitpunkt einer nachfolgenden Dateneinheit. Ist dieser früheste End-Zeitpunkt später als ein früherster End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde, so kann die Verarbeitung des Satzes von Dateneinheiten durchgeführt werden. Ist dies nicht der Fall, dann wird der neu zusammengesetzte Satz von Dateneinheiten nicht verarbeitet.
Das Verfahren umfasst ferner das Verarbeiten 130 des Satzes von Dateneinheiten, falls der früheste End-Zeitpunkt später ist als ein frühester End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde. Im Umkehrschluss kann die Verarbeitung des Satzes von Dateneinheiten unterbleiben, falls der früheste End-Zeitpunkt nicht später (also früher oder zeitgleich) ist als der früheste End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde. Dabei ist der früheste End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde, derjenige früheste End-Zeitpunkt, aufgrund dessen zuletzt eine Verarbeitung durchgeführt wurde. Als weitere Bedingung kann gestellt werden, dass der Satz von Dateneinheiten vollständig ist. In anderen Worten kann der Satz von Dateneinheiten in manchen Ausführungsbeispielen (nur) verarbeitet werden, wenn der Satz von Dateneinheiten vollständig ist, d.h. falls zu jedem Thema eine gültige Dateneinheit vorliegt.
Der Satz von Dateneinheiten wird in zumindest einigen Ausführungsbeispielen zusammen verarbeitet. In anderen Worten kann die Verarbeitung auf allen Dateneinheiten des Satzes von Dateneinheiten basieren. Dazu wird beispielsweise der Satz von Dateneinheiten, wie er zu einem bestimmten Zeitpunkt (etwa dem frühesten definierten End-Zeitpunkt) zusammengestellt ist, zusammen verarbeitet, etwa indem der Satz von Dateneinheiten kopiert und der Verarbeitung übergeben wird.
Wie bereits zuvor angedeutet wurde, kann der vorliegende Ansatz in einer Vielzahl von Datenverarbeitungsszenarien angewandt werden. Im Folgenden werden lediglich zwei dieser Szenarien beispielhaft herausgestellt - die verteilte Berechnung von Simulationen, und die Steuerung einer Maschine oder Anlage. In manchen Ausführungsbeispielen kann das vorliegende Konzept beispielsweise auch in Mehrspieler-Computerspielen eingesetzt werden. In diesem Fall können die Datenquellen die ausgeführten Distanzen des Computerspiels sein, die an einer Partie des Computerspiels beteiligt sind.
In komplexen Simulationen wird die Simulation oftmals in Teilprobleme zerlegt, die parallel auf mehrere Rechenknoten berechnet werden können. Jeder Rechenknoten berechnet einen zusammenhängenden Rechenschritt der Simulation, im Anschluss werden Zwischenergebnisse ausgetauscht, und basierend auf den Zwischenergebnissen der anderen Knoten kann die Simulation fortgeführt werden. Dabei lässt sich die Simulation, in vielen Fällen, so aufteilen, dass jeder Rechenknoten für den nächsten Rechenschritt Zwischenergebnisse (nur) eines Teils der Rechenknoten benötigt. Diese Zwischenergebnisse können im Rahmen der vorliegenden Offenbarung als Dateneinheiten des Satzes von Dateneinheiten gesehen werden, wobei der Satz von Dateneinheiten für den jeweiligen Rechenknoten diejenigen Zwischenergebnisse definiert, die benötigt werden, um den nächsten Rechenschritt ausführen zu können. In anderen Worten, die Dateneinheiten können Zwischenergebnisse einer verteilten Simulation sein. Folglich kann das Verarbeiten des Datensatzes 130 einem Ausführen 140 eines Teils der verteilten Simulation durch einen Rechenknoten entsprechen, etwa eines Verarbeitungsschritts der verteilten Simulation. Wie bereits zuvor ausgeführt kann der Rechenknoten zum Ausführen des Teils der verteilten Simulation Zwischenergebnisse von anderen Rechenknoten benötigen. Folglich können die Datenquellen weitere Rechenknoten zum Berechnen der verteilten Simulation sein (d.h. die Dateneinheiten von weiteren Rechenknoten, die zum Berechnen der verteilten Simulation eingesetzt werden, empfangen werden). Entsprechend kann das Verfahren ferner ein Bereitstellen 145 eines Ergebnisses des Teils der verteilten Simulation (d.h. das Ergebnis der Verarbeitung des Satzes von Dateneinheiten) als Dateneinheit an ein oder mehrere weitere Rechenknoten umfassen. Die weiteren Rechenknoten können nun wiederum diese Dateneinheiten nutzen, um ihren nächsten Verarbeitungsschritt der Simulation zu berechnen.
Alternativ kann das Verfahren zur Steuerung einer Maschine genutzt werden. Beispielsweise können die Dateneinheiten Sensordaten von Sensoren oder Stelldaten von Aktoren einer Maschine oder einer Anlage sein. Dabei können die Sensoren beispielsweise an verschiedenen Komponenten der Maschine oder Anlage angeordnet sein und verschiedene Eigenschaften messen. Beispielsweise kann die Anlage eine Industrieanlege sein, und die Sensoren können einen Luftdruck, eine Temperatur, eine Flussmenge, einen Füllstand eines Tanks etc. messen. Entsprechend können die Dateneinheiten jeweils Information über den Luftdruck, die Temperatur, die Flussmenge, oder den Füllstand eines Tanks umfassen. Diese Informationen können nun zentral verarbeitet werden, um die Steuerung der Maschine oder der Anlage anzupassen, etwa um eine Kühlung anzupassen, um eine Verarbeitungsgeschwindigkeit zu ändern etc. Entsprechend kann das Verarbeiten 130 des Satzes von Dateneinheiten ein Berechnen 150 und Bereitstellen 155 eines Steuersignals für die Maschine oder Anlage basierend auf den Sensordaten umfassen. Dabei kann das Steuersignal dazu vorgesehen sein, ein oder mehrere Aktoren der Maschine oder Anlage zu steuern. Das Steuersignal kann genutzt werden, um zumindest eine Komponente der Maschine oder Anlage, in Reaktion auf den Satz von Dateneinheiten, zu regeln.
Die Schnittstelle 12 kann beispielsweise einem oder mehreren Eingängen und/oder einem oder mehreren Ausgängen zum Empfangen und/oder Übertragen von Informationen entsprechen, etwa in digitalen Bitwerten, basierend auf einem Code, innerhalb eines Moduls, zwischen Modulen, oder zwischen Modulen verschiedener Entitäten.
In Ausführungsbeispielen können die ein oder mehreren Prozessoren 14 einem beliebigen Controller oder Prozessor oder einer programmierbaren Hardwarekomponente entsprechen.
Beispielsweise kann eine Funktionalität der ein oder mehreren Prozessoren auch als Software realisiert sein, die für eine entsprechende Hardwarekomponente programmiert ist. Insofern können die ein oder mehreren Prozessoren 14 als programmierbare Hardware mit entsprechend angepasster Software implementiert sein. Dabei können beliebige Prozessoren, wie Digitale Signalprozessoren (DSPs) zum Einsatz kommen. Ausführungsbeispiele sind dabei nicht auf einen bestimmten Typ von Prozessor eingeschränkt. Es sind beliebige Prozessoren oder auch mehrere Prozessoren zur Implementierung der ein oder mehreren Prozessoren 14 denkbar.
Mehr Details und Aspekte des Verfahrens, des Systems und des Computerprogramms werden in Verbindung mit dem Konzept oder Beispielen genannt, die vorher oder nachher beschrieben werden. Das Verfahren, das System und das Computerprogramm kann ein oder mehrere zusätzliche optionale Merkmale umfassen, die ein oder mehreren Aspekten des vorgeschlagenen Konzepts oder der beschriebenen Beispiele entsprechen, wie sie vorher oder nachher beschrieben wurden.
Ausführungsbeispiele der vorliegenden Offenbarung befassen sich mit einem Verfahren, System und Computerprogramm zur Synchronisation von verteilten Rechenprozessen.
Zumindest manche Ausführungsbeispiele der vorliegenden Offenbarung basieren darauf, dass „Topics“ (Themen) definiert werden (das sind die „Themen“ für die Ereignisse (engl. Events) generiert werden und über die sich die Simulationsteilnehmer unterhalten), wie etwa Trafo Nr. 13 oder Position Spieler 3. Dabei kann ein Satz von Dateneinheiten beispielsweise eine Mehrzahl von „Topics“ umfassen, wobei die einzelnen Dateneinheiten die „Ereignisse“ sind. Jedes Ereignis hat einen absoluten Zeitstempel „bis wann“ dieses Ereignis gültig ist oder wann der nächste Ereignis kommen wird (also einen definierten End-Zeitpunkt für die Gültigkeit der Dateneinheit). Dieser Zeitpunkt kann eine sogenannte „Time to live“ (Lebenszeit, ein definierter Zeitpunkt, bis zu dem das Ereignis gültig ist) definieren. Dieser ergibt sich meist aus der Art Berechnung die angestellt wird, um das Ereignis (die Dateneinheit) zu generieren. Beispielsweise kann ein Steuersignal alle 15 Min ausgegeben werden, oder eine Position wird alle 100ms aktualisiert.
Ein dynamisches Verändern des Aufbaus ist in manchen Fällen nicht ohne weiteres möglich. Beispielsweise, wenn drei Prozesse miteinander synchronisiert werden sollen, so kann im Verlauf der Berechnung nicht einfach ein vierter Prozess hinzugefügt oder ein bereits vorhandener entfernt werden. Jeder Prozess benötigt (neue) Ereignisse zu all seinen Topics, bevor er seine Ereignisse neu berechnen kann. Folglich kann ein Prozess so lange warten, bis er genügend unverarbeitete Ereignisse zu den entsprechenden Topics empfangen hat.
Im Folgenden ist beispielhaft ein Algorithmus dargestellt, der eine entsprechende Synchronisierung von Prozessen unterstützt.
Dabei wird in der ersten Zeile „Clock [C_E,0,C_L,0] = [0, 0]“ das aktuell betrachtete Zeitintervall [C_E,0,C_L,0] auf [0, 0] gestellt. Clock gibt dabei den zeitlichen Rahmen der Berechnung an, C_E und C_L, sind die frühste Clock und die späteste Clock in einem Zeitrahmen. In der zweiten Zeit wird eine sogenannte „For“-Schleife eröffnet, die durch das „End-for“ in der letzten Zeile terminiert wird, und die für jedes noch nicht verarbeitete Ereignis ausgeführt wird („for every unprocessed event“). In der dritten Zeile wird ein Satz S_E von allen möglichen Ereignissen Y definiert. In der vierten Zeile wird der früheste End-Zeitpunkt für die Gültigkeit eines Ereignisses des Satzes von Dateneinheiten ermittelt und ELT_i zugewiesen. L(X) gibt den Zeitstempel für das Event X aus, ELT_i: ist das Minimum aller Zeitstempel eines Daten / Event Satzes, für den Zeitpunkt i. Dann wird das aktuelle Zeitintervall neu definiert - dieses spannt von einem in einer vorherigen Iteration ermittelten frühesten End-Zeitpunkt ELT_i-1 bis zu dem in dieser Iteration der For-Schleife ermittelten frühesten End-Zeitpunkt ELTi. Falls ELT_i nach ELT_i-1 liegt wird der Satz von Daten für den Zeitpunkt ELT_i verarbeitet. Danach wird die nächste Iteration der For-Schleife ausgeführt.
Vorab wird definiert, für welche Topics Ereignisse ausgetauscht werden (oder genauer, zu welchen Topics Ereignisse von diesem Prozess empfangen werden). Jedes Ereignis umfasst beispielsweise die folgenden Informationen:

1. TimeToLive (bis wann die Daten gültig sind, L(x))
2. Einen eindeutigen Identifikator
3. Daten

Nun können Prozesse Ereignisse austauschen. Dazu werden alle empfangenen Ereignisse in eine Liste gepackt. Für alle Ereignisse aus dieser Liste wird nun das Minimum der TimeToLive (= ELT_i) gebildet. Die interne Uhr des Prozesses darf nun voranschreiten von jetzt bis zum vorher bestimmten Minimum, jedoch auch nur falls dieses Minimum größer ist als das zuvor bestimmte. Andernfalls wird einfach gewartet bzw. nichts getan, bis neue Ereignisse empfangen werden.
Ein Spezialfall nimmt der Start ein, dieser erfordert, dass alle Prozesse Ereignisse mit einem gültigen TimeToLive versenden, obwohl sie (noch) nicht gearbeitet haben. Wie dies realisiert wird, bleibt dem Prozess Entwickler überlassen.
Im Folgenden wird ein Anwendungsbeispiel gezeigt. 2 zeigt ein schematisches Diagramm einer Gültigkeit von verschiedenen Dateneinheiten entlang einer Zeitachse für dieses Anwendungsbeispiel. Dieses Anwendungsbeispiel bezieht sich auf eine Konstellation aus drei Simulatoren (Sim 1, 2 und 3), die an einer gemeinsamen Simulation arbeiten. Jeder dieser Prozesse schickt Ereignisse (x{_a,b,c}) mit den Ergebnissen der jeweiligen Berechnungen, die wiederum die Eingabe für die nächste Berechnung darstellen. Simulator 3 berechnet viele sehr „kurzlebige“ Ereignisse. Simulator 2 erzeugt sehr langlebige Ereignisse und Simulator 1 liegt dazwischen. Jedes Ereignis X, hat also eine Startzeit (E(x)) und eine Endzeit (L(x)), die durch die in 2 gezeigten Balken dargestellt werden. In 2 ist ferner das Zeitintervall [ti,ti+1] zu sehen, zu dem die Ereignisse der drei Simulatoren gleichzeitig gültig sind.
Um eine Simulation nun erfolgreich auszuführen sind folgende Kriterien zu erfüllen:

a) Jeder Simulator generiert Ereignisse (dies entspricht erfolgreichen Berechnungen, bzw. er sollte funktionieren und nicht „abgestürzt“ sein).
b) Die Zeit steigt kontinuierlich, d.h. es kommt nicht zu negativen Zeitsprüngen
c) Jeder Simulator verarbeitet die Ereignisse „In-Order“, d.h. wenn ein Ereignis X vor Y ist, so kann er auch vor Y verarbeitet werden. Sind sie Zeitgleich bzw. „parallel“, dann können sie in beliebiger Reihenfolge verarbeitet werden.

Konkret bedeutet dies nun für beispielsweise Simulator 3 dass er seine Berechnung durchführen kann zum Zeitpunkt t_i+1, um ein neues Ereignis zu generieren. Allerdings würde für die Berechnung eines weiteren Ereignisses, die nächsten Ereignisse von Simulator 1 fehlen. Bezogen auf ein KFZ kann Simulation 2 die Motortemperatur sein, Simulation 3 die Drehzahl und Simulation 1 die Stellung des Gaspedals. Nun kann beispielsweise auf Basis dieser Ereignisse eine resultierende Motorleistung berechnet werden. Bezogen auf verteilte Simulationen (wie Folding@Home) wären die einzelnen Simulatoren private Computer, die verschiedene Pakete verarbeiten.
Die im vorgeschlagenen Konzept angewandte Vorgehensweise verhindert Deadlocks, also das zirkuläre Warten von Simulator 1, auf Simulator 2, der wiederum auf Simulator 3 wartet, der auf Simulator 1 wartet. Dies kann dadurch erreicht werden, dass vorab bekannt ist, welche Ereignisse empfangen werden müssen. Zudem kann immer eine Liste an gültigen Ereignissen an den Simulator übergeben werden. Somit kann ein gegenseitiges Warten verhindert werden. Dieses Deadlock-Risiko ist eine der größten Schwächen der konservativen Synchronisation. Bisherige Algorithmen lösen dieses Problem nur mit extremen Aufwand oder hoher Komplexität.
Ein weiterer Vorteil ist die garantierte „In-Order“ Ausführung von Ereignissen in Ausführungsbeispielen. Dabei wird zwischen gleichzeitigen und nacheinander ankommenden Ereignisse unterschieden. Bei gleichzeitigen Ereignissen ist per Definition die Ausführungsreihenfolge egal. Allerdings kann bei nacheinander ankommenden Ereignissen sichergestellt sein, dass diese in der richtigen Reihenfolge passieren. Zudem kann es als vorteilhaft angesehen werden, dass es keine vorab fest definierten Zeitpunkte zur Synchronisation gibt. Folglich können Prozesse Ereignisse austauschen, wenn diese fertig berechnet sind und sie können auf ankommende Ereignisse reagieren, auch wenn diese ankommen bevor die Time-To-Live des vorherigen Ereignisse abgelaufen ist.
3 zeigt ein weiteres schematisches Diagramm einer Interaktion zwischen verschiedenen Datenquellen. Hier benötigt eine Simulation Y Dateneinheiten eines Reglers A und einer Simulation X. Sowohl der Regler als auch die Simulationen stellen regelmäßig Ereignisse bereit (als vertikale Striche auf den Zeitlinien dargestellt), wobei zwischen zwei Ereignissen von Regler A der Zeitraum T₂ liegt, zwischen zwei Ereignissen von Simulation X der Zeitraum T1 und zwischen zwei Ereignissen der Simulation Y der Zeitraum T₃. Das Diagramm befasst sich vorwiegend mit Simulation Y, daher sind dort die Zeitschritte t₀ bis t₃ aufgetragen, an denen die Ereignisse von Simulation Y generiert und bereitgestellt werden sollen. Im Zeitraum zwischen t₁ und t₂ empfängt Simulation Y Nachrichten von Regler A und Simulation X, die jeweils einen End-Zeitpunkt aufweisen (als „delta“ markiert).
Verwendet werden kann die vorgestellte Technologie zum Synchronisieren von verschiedenen Prozessen, über beliebige Distanzen. Darunter fallen Simulationen, die in Echtzeit arbeiten, oder Simulatoren die schneller / langsamer als Echtzeit arbeiten. Computerspiele, die mehrere Teilnehmer zusammenspielen lassen und dafür ständig Daten austauschen müssen, verteilte Berechnungen, die sehr komplexe Probleme bearbeiten und sicherstellen müssen (z.B. Folding@Home), oder Sensornetzwerke die verteilt Daten aufnehmen und bearbeiten (z-B- im KFZ, Wetterdaten Sensor Netzwerke, ...). Weitere Gebiete sind Sektorenkopplung, Netzberechnung und -Optimierung, CAD Modellrechnungen in der Automobilbranche und Modellrechnungen in CAD / CAM Tools.
Die Aspekte und Merkmale, die zusammen mit einem oder mehreren der vorher detaillierten Beispiele und Figuren beschrieben sind, können auch mit einem oder mehreren der anderen Beispiele kombiniert werden, um ein gleiches Merkmal des anderen Beispiels zu ersetzen oder um das Merkmal in das andere Beispiel zusätzlich einzuführen.
Beispiele können weiterhin ein Computerprogramm mit einem Programmcode zum Ausführen eines oder mehrerer der obigen Verfahren sein oder sich darauf beziehen, wenn das Computerprogramm auf einem Computer oder Prozessor ausgeführt wird. Schritte, Operationen oder Prozesse von verschiedenen, oben beschriebenen Verfahren können durch programmierte Computer oder Prozessoren ausgeführt werden. Beispiele können auch Programmspeichervorrichtungen, z. B. Digitaldatenspeichermedien, abdecken, die maschinen-, prozessor- oder computerlesbar sind und maschinenausführbare, prozessorausführbare oder computerausführbare Programme von Anweisungen codieren. Die Anweisungen führen einige oder alle der Schritte der oben beschriebenen Verfahren aus oder verursachen deren Ausführung. Die Programmspeichervorrichtungen können z. B. Digitalspeicher, magnetische Speichermedien wie beispielsweise Magnetplatten und Magnetbänder, Festplattenlaufwerke oder optisch lesbare Digitaldatenspeichermedien umfassen oder sein. Weitere Beispiele können auch Computer, Prozessoren oder Steuereinheiten, die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind, oder (feld-)programmierbare Logik-Arrays ((F)PLAs = (Field) Programmable Logic Arrays) oder (feld-)programmierbare Gate-Arrays ((F)PGA = (Field) Programmable Gate Arrays), die zum Ausführen der Schritte der oben beschriebenen Verfahren programmiert sind, abdecken.
Durch die Beschreibung und Zeichnungen werden nur die Grundsätze der Offenbarung dargestellt. Weiterhin sollen alle hier aufgeführten Beispiele grundsätzlich ausdrücklich nur illustrativen Zwecken dienen, um den Leser beim Verständnis der Grundsätze der Offenbarung und der durch den (die) Erfinder beigetragenen Konzepte zur Weiterentwicklung der Technik zu unterstützen. Alle hiesigen Aussagen über Grundsätze, Aspekte und Beispiele der Offenbarung sowie konkrete Beispiele derselben umfassen deren Entsprechungen.
Ein als „Mittel zum...“ Ausführen einer bestimmten Funktion bezeichneter Funktionsblock kann sich auf eine Schaltung beziehen, die ausgebildet ist zum Ausführen einer bestimmten Funktion. Somit kann ein „Mittel für etwas“ als ein „Mittel ausgebildet für oder geeignet für etwas“ implementiert sein, z. B. ein Bauelement oder eine Schaltung ausgebildet für oder geeignet für die jeweilige Aufgabe.
Funktionen verschiedener in den Figuren gezeigter Elemente einschließlich jeder als „Mittel“, „Mittel zum Bereitstellen eines Signals“, „Mittel zum Erzeugen eines Signals“, etc. bezeichneter Funktionsblöcke kann in Form dedizierter Hardware, z. B „eines Signalanbieters“, „einer Signalverarbeitungseinheit“, „eines Prozessors“, „einer Steuerung“ etc. sowie als Hardware fähig zum Ausführen von Software in Verbindung mit zugehöriger Software implementiert sein. Bei Bereitstellung durch einen Prozessor können die Funktionen durch einen einzelnen dedizierten Prozessor, durch einen einzelnen gemeinschaftlich verwendeten Prozessor oder durch eine Mehrzahl von individuellen Prozessoren bereitgestellt sein, von denen einige oder von denen alle gemeinschaftlich verwendet werden können. Allerdings ist der Begriff „Prozessor“ oder „Steuerung“ bei Weitem nicht auf ausschließlich zur Ausführung von Software fähige Hardware begrenzt, sondern kann Digitalsignalprozessor-Hardware (DSP-Hardware; DSP = Digital Signal Processor), Netzprozessor, anwendungsspezifische integrierte Schaltung (ASIC = Application Specific Integrated Circuit), feldprogrammierbare Logikanordnung (FPGA = Field Programmable Gate Array), Nurlesespeicher (ROM = Read Only Memory) zum Speichern von Software, Direktzugriffsspeicher (RAM = Random Access Memory) und nichtflüchtige Speichervorrichtung (storage) umfassen. Sonstige Hardware, herkömmliche und/oder kundenspezifische, kann auch eingeschlossen sein.
Ein Blockdiagramm kann zum Beispiel ein grobes Schaltdiagramm darstellen, das die Grundsätze der Offenbarung implementiert. Auf ähnliche Weise können ein Flussdiagramm, ein Ablaufdiagramm, ein Zustandsübergangsdiagramm, ein Pseudocode und dergleichen verschiedene Prozesse, Operationen oder Schritte repräsentieren, die zum Beispiel im Wesentlichen in computerlesbarem Medium dargestellt und so durch einen Computer oder Prozessor ausgeführt werden, ungeachtet dessen, ob ein solcher Computer oder Prozessor explizit gezeigt ist. In der Beschreibung oder in den Patentansprüchen offenbarte Verfahren können durch ein Bauelement implementiert werden, das ein Mittel zum Ausführen eines jeden der jeweiligen Schritte dieser Verfahren aufweist.
Es versteht sich, dass die Offenbarung mehrerer, in der Beschreibung oder den Ansprüchen offenbarter Schritte, Prozesse, Operationen oder Funktionen nicht als in der bestimmten Reihenfolge befindlich ausgelegt werden soll, sofern dies nicht explizit oder implizit anderweitig, z. B. aus technischen Gründen, angegeben ist. Daher werden diese durch die Offenbarung von mehreren Schritten oder Funktionen nicht auf eine bestimmte Reihenfolge begrenzt, es sei denn, dass diese Schritte oder Funktionen aus technischen Gründen nicht austauschbar sind. Ferner kann bei einigen Beispielen ein einzelner Schritt, Funktion, Prozess oder Operation mehrere Teilschritte, -funktionen, -prozesse oder -operationen einschließen und/oder in dieselben aufgebrochen werden. Solche Teilschritte können eingeschlossen sein und Teil der Offenbarung dieses Einzelschritts sein, sofern sie nicht explizit ausgeschlossen sind.
Weiterhin sind die folgenden Ansprüche hiermit in die detaillierte Beschreibung aufgenommen, wo jeder Anspruch als getrenntes Beispiel für sich stehen kann. Während jeder Anspruch als getrenntes Beispiel für sich stehen kann, ist zu beachten, dass - obwohl ein abhängiger Anspruch sich in den Ansprüchen auf eine bestimmte Kombination mit einem oder mehreren anderen Ansprüchen beziehen kann - andere Beispiele auch eine Kombination des abhängigen Anspruchs mit dem Gegenstand jedes anderen abhängigen oder unabhängigen Anspruchs umfassen können. Solche Kombinationen werden hier explizit vorgeschlagen, sofern nicht angegeben ist, dass eine bestimmte Kombination nicht beabsichtigt ist. Ferner sollen auch Merkmale eines Anspruchs für jeden anderen unabhängigen Anspruch eingeschlossen sein, selbst wenn dieser Anspruch nicht direkt abhängig von dem unabhängigen Anspruch gemacht ist.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Nicht-Patentliteratur

High-Level Architecture, Architektur auf hohem Niveau, siehe Z. Jiang: „A Novel Simulation Time and Wall Clock Time Synchronization Algorithm for HLA‟ [0011]
A. M. Kosek et al: „Evaluation of smart grid control strategies in co-simulation — integration of IPSYS and mosaik‟ [0012]

Claims

Computerimplementiertes Verfahren zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen, das Verfahren umfassend: Empfangen (110) von Dateneinheiten von der Mehrzahl von Datenquellen, wobei jede Dateneinheit bis zu einem definierten End-Zeitpunkt gültig ist, wobei die empfangenen Dateneinheiten einem Satz von Dateneinheiten hinzugefügt (115) werden und dem Satz von Dateneinheiten angehören, solange die jeweiligen Dateneinheiten gültig sind, wobei von jeder Datenquelle je zumindest eine Dateneinheit in dem Satz von Dateneinheiten umfasst ist; Bestimmen (120), als Reaktion auf das Hinzufügen einer Dateneinheit zum Satz von Dateneinheiten, eines frühesten End-Zeitpunkts unter den Dateneinheiten des Satzes von Dateneinheiten, und Verarbeiten (130) des Satzes von Dateneinheiten, falls der früheste End-Zeitpunkt später ist als ein frühester End-Zeitpunkt, der als Reaktion auf das Empfangen einer zuvor empfangenen Dateneinheit bestimmt wurde.
Das Verfahren gemäß Anspruch 1, wobei jede Dateneinheit Information über den definierten End-Zeitpunkt der Dateneinheit umfasst.
Das Verfahren gemäß einem der Ansprüche 1 oder 2, wobei der Satz von Dateneinheiten zusammen verarbeitet wird.
Das Verfahren gemäß einem der Ansprüche 1 bis 3, wobei die Mehrzahl von Datenquellen, und damit auch die Dateneinheiten des Satzes von Dateneinheiten, vordefiniert sind.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei die Dateneinheiten Zwischenergebnisse einer verteilten Simulation sind, wobei das Verarbeiten des Datensatzes (130) einem Ausführen (140) eines Teils der verteilten Simulation durch einen Rechenknoten entspricht, wobei die Datenquellen weitere Rechenknoten zum Berechnen der verteilten Simulation sind.
Das Verfahren gemäß Anspruch 5, umfassend Bereitstellen (145) eines Ergebnisses des Teils der verteilten Simulation als Dateneinheit an ein oder mehrere weitere Rechenknoten.
Das Verfahren gemäß einem der Ansprüche 1 bis 4, wobei die Dateneinheiten Sensordaten von Sensoren einer Maschine oder einer Anlage sind, wobei das Verarbeiten (130) des Satzes von Dateneinheiten ein Berechnen (150) und Bereitstellen (155) eines Steuersignals für die Maschine oder Anlage basierend auf den Sensordaten umfasst.
Ein Programm mit einem Programmcode zum Durchführen des Verfahrens gemäß einem der vorhergehenden Ansprüche, wenn der Programmcode auf einem Computer, einem Prozessor, einem Kontrollmodul oder einer programmierbaren Hardwarekomponente ausgeführt wird.
Ein computerimplementiertes System (10) zum synchronisierten Verarbeiten von einem Satz von zu verarbeitenden Dateneinheiten einer Mehrzahl von Datenquellen (20), das System umfassend eine Schnittstelle (12) und ein oder mehrere Prozessoren (14), wobei das System ausgebildet ist zum Ausführen des Verfahrens gemäß einem der Ansprüche 1 bis 7.