EP4662616A1 - Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation - Google Patents

Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation

Info

Publication number
EP4662616A1
EP4662616A1 EP24710643.8A EP24710643A EP4662616A1 EP 4662616 A1 EP4662616 A1 EP 4662616A1 EP 24710643 A EP24710643 A EP 24710643A EP 4662616 A1 EP4662616 A1 EP 4662616A1
Authority
EP
European Patent Office
Prior art keywords
data set
integration device
event
external
integration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP24710643.8A
Other languages
English (en)
French (fr)
Inventor
Ralf WESTPHAL
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens Mobility GmbH
Original Assignee
Siemens Mobility GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens Mobility GmbH filed Critical Siemens Mobility GmbH
Publication of EP4662616A1 publication Critical patent/EP4662616A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06313—Resource planning in a project environment
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • G06F13/382—Information transfer, e.g. on bus using universal interface adapter
    • G06F13/387—Information transfer, e.g. on bus using universal interface adapter for adaptation of different data processing systems to different peripheral devices, e.g. protocol converters for incompatible systems, open system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations
    • G06Q10/06315—Needs-based resource requirements planning or analysis

Definitions

  • a conventional approach in this direction is to create a large holistic model of the entire system including all subsystems. Sometimes this approach even goes a step further and tries to create a single application or application framework in which all aspects are integrated.
  • Another conventional approach is based on the use of files to exchange data between tools and processes. This approach involves the definition of file formats and exchange protocols. In addition, as toolchains become more complex, a corresponding management system must be introduced that tracks the information flow of files.
  • an integration device which comprises: i) at least one memory (in particular an event-based memory); and ii) at least one control device (in particular comprising at least one processor) which is coupled to the memory (in particular wired or wirelessly).
  • the integration device is designed to: a) communicate (in particular wired or wirelessly) with a plurality of external units (in particular a project planning unit, e.g. an engineering tool), wherein the communication comprises: ai) receiving a data set (in particular concerning at least one event) from one of the external units (at the control device of the integration device), wherein the data set is associated with the external unit (or is indicative of this specific external unit; corresponds to it), aii) storing the data set (in the memory of the integration device), and aiii) outputting (by the control device of the integration device) a further data set (in particular which is associated with a further one of the external units and/or which at least partially comprises the data set) to the external unit, and b) providing and/or triggering a provision (e.g. by means of an agent functionality) of status information concerning the external unit (and/or the (further) data set).
  • a project planning unit e.g. an engineering tool
  • an integration system data exchange system
  • the system comprising: i) an integration device as described above; and ii) the plurality of external units (which comprise the external unit and the further external unit).
  • the plurality of external units are coupled (to one another) via the integration device.
  • a use of an integration device and/or an integration system as described above in a project relating to the field of infrastructure, in particular rail infrastructure, is described.
  • a computer program product which has instructions which, when the program is executed by a computer, cause the computer to carry out the method described above.
  • the term "status information” can refer in particular to information (or message) relating to a status of one of the external units (in particular with regard to the organization of one or more data sets).
  • the status information can relate to one or more status information aspects. This can indicate, for example, whether these aspects have been completed or not (yet) completed.
  • the term “dataset” may refer in particular to a plurality of information and/or data (items). In particular, these data may be related to the development of a technical project, e.g. from the rail infrastructure sector.
  • the data set can be event-based and refer to a specific event or represent a mere message.
  • the data set can be assigned to a specific topic.
  • topic can refer in particular to a specific aspect of the project.
  • a topic can, for example, refer to a class of entities and/or objects.
  • signals would be a topic that can refer to the information of a large number of individual signal entities. Two or more external entities can therefore refer to the same topic and/or to the same entities/objects within a topic.
  • the term "further data set” may refer to a data set that is indicative of another external entity.
  • the state information may thus indicate whether the external entity has requested and received the further data set from another external entity within the system.
  • the further data set may also include (at least in part) the data set of the external entity, e.g. after it has been processed by another entity.
  • the present approach can also have the following advantages:
  • the integration device can have an overview of which tasks have been completed and which ones still need to be completed. This also allows the status of the overall system to be assessed quickly and efficiently. In particular, it can be determined whether a unit has already transferred (all) of its data records to the integration device. It can also be determined whether a unit has already retrieved all (relevant) data records of (other) units from the integration device. It can also be determined whether the status of a unit and/or a specific data record is already satisfactory (e.g. completed, processed, consistent, etc.).
  • the provided status information is indicative of whether a completed state or an incomplete state exists.
  • the presence of the completed state in all status information aspects puts the external unit into a completed state. This can have the advantage that a particularly efficient and reliable assessment of the project status can be carried out.
  • a project domain (external unit) is considered complete if all three status information aspects (see above) are completed ("true"). Furthermore, if all status information in all external units involved is completed (“true"), the entire project can be considered as completed or at least as consistent at this point in time.
  • the provided state information in particular a state information aspect, has a flag, in particular a Boolean value.
  • a flag in particular a Boolean value.
  • each state information aspect can have a flag which has the state "completed (true)” or "not completed (false)".
  • Such a Boolean value can be represented in different ways, e.g. 0/1, red/green, +/-, etc.
  • the data set is a file-based data set, in particular where the external unit operates on a file-based basis.
  • the integration device further comprises: an agent functionality which is configured to at least partially transfer a file-based data set into an event-based data set and/or to at least partially transfer an event-based data set into a file-based data set.
  • an agent functionality which is configured to at least partially transfer a file-based data set into an event-based data set and/or to at least partially transfer an event-based data set into a file-based data set.
  • agent functionality in the context of this document can refer in particular to hardware and/or software which is configured to act as an interface between the integration device and an external unit, in particular wherein the external unit is configured to provide file-based data sets.
  • the agent functionality can be configured as part of the integration device/control device, or can also be an independent area of the integration system. In one example (see Figure 3), the agent functionality is configured to transfer/translate between file-based data sets and event-based data sets. In one example, the agent functionality can independently provide status information and/or be triggered by the integration device to do so.
  • pull agents react to new messages in the event system by reading its data streams (topics) and creating updated interface files based on the data read from the event system.
  • Manual executions or externally triggered agent calls are also possible alternatives.
  • the at least one memory has an event store (event store, e.g.
  • the event store stores a large number of events as a series of blocks. This allows an established technology to be implemented directly.
  • data records within the event-based memory are essentially not changed.
  • the data is stored as intended and not manipulated, so that it can be restored at any time with its complete history.
  • all data manipulation - if necessary - only takes place during output from the integration device.
  • Event-based systems such as Apache Kafka are known to exchange data between tools and processes to achieve decoupling.
  • such systems natively do not offer any additional functions that would allow a conclusion about the completeness and consistency of the engineering. When used in their original way, event systems lack functions to evaluate completeness and consistency.
  • Known systems can track the messages sent, but have no way of ensuring that the messages have been processed and integrated into the engineering data of all parties involved.
  • the integration system further comprises: an agent functionality which is coupled to the integration device, in particular wherein the integration device is configured to trigger the agent functionality to provide the state information.
  • the agent functionality is not assigned to the integration device, but is independent within the integration system. Nevertheless, the integration device can, in one example, trigger a provision of state information aspects by the agent functionality.
  • the Agent functionality (at least partially) independently provides state information (aspects).
  • the integration device has an artificial intelligence (AI) module.
  • AI artificial intelligence
  • AI can refer in particular to computer-based approaches to mimicking cognitive functions of a human mind, in particular learning and problem solving.
  • a variety of various mathematical algorithms and computational models have been developed to implement AI functionalities, for example machine learning, deep learning, neural networks, genetic algorithms, kernel regression, etc.
  • the main purpose of these approaches can be seen in improving an existing algorithm by training it with training data so that a learning effect occurs and the problem-solving ability of the algorithm improves over time. This can happen with or without human intervention (e.g., refining).
  • Figure 1 shows an integration system in which a plurality of external units communicate with an integration device, according to an exemplary embodiment of the invention.
  • Figure 2 shows a provision of status information by means of the integration device to the plurality of external units, according to an exemplary embodiment of the invention.
  • Figure 3 shows a transfer between a file-based data set and an event-based data set within the integration system, according to an exemplary embodiment of the invention.
  • spatially relative terms such as “front” and “back”, “top” and “bottom”, “left” and “right”, etc. are used to describe the relationship of one element to another element as shown in the figures.
  • the spatially relative terms can apply to orientations used that differ from the orientation shown in the figures. illustrated orientation.
  • these spatially relative terms refer only to simplify the description and to the orientation shown in the figures and are not necessarily limiting, since a device according to an embodiment of the invention can assume other orientations than those illustrated in the figures, particularly when used.
  • a native application 138 operates event-based, outputs event-based data records, and can therefore establish a direct connection to the integration device 100 with the event-based storage 120.
  • These native applications 138 are developed from the outset with an event-driven architecture in mind.
  • a plug-in based application 135 has a plug-in to connect existing applications via the plug-in interface with the integration device 100 with the event-based storage 120 in order to enable event-driven data processing.
  • a legacy application 131 operates file-based and has no plug-in for an interface.
  • an agent functionality 140 can be used to connect the existing legacy application 131 with the integration device 100 with the event-based storage 120.
  • the agent functionality 140 hereby transfers a file-based data set at least partially into an event-based data set.
  • This translation can be performed autonomously and without additional user interaction.
  • agent functionality 140 is standalone and coupled to the integration device 100. In another example, the agent functionality 140 is integrated into the integration device 100.
  • the integration system 150 thus has the following "levels”: i) project planning units 130 (applications, engineering tools), ii) files 160 (management), iii) agent functionality (integrating) 140, iv) integration device 100.
  • the integration device 100 acts as an interface for organizing the status information 180 regarding the majority of external units 130 within the project.
  • the responsibility for determining the completeness and consistency information is shared between the units or the agent functionalities 160 and the integration device 100.
  • three status information aspects are determined within the framework of the status information 180, which can then be stored as Boolean values (flags) in the integration device 100, e.g.:
  • -Status 183 true if the unit 130 has processed all data retrieved from the event system (integration device 100) and is finally in a consistent state with respect to its own engineering domain and its own data model, otherwise false.
  • units 130 are responsible for validating these flags 181, 182, 183:
  • the unit 130 can set its transmit flag 181 to "true”.
  • Figure 3 shows a transfer of a file-based data set 160 into an event-based data set within the integration system 150, according to an exemplary embodiment of the invention.
  • file-based operating units 131 are just ordinary units that have the same three flags as part of the status information 180 to evaluate completeness and consistency.
  • rule engines can use data models or other suitable methods to check whether the configuration follows the features predefined by the overall system, or whether additional dependencies between subsystems are correctly taken into account.
  • the agent functionality 140 can transmit in both directions file -> event and event -> file.
  • the agent functionality 140 can provide the status information and/or be triggered by the integration device 100.
  • the agent functionality 140 can be used as an interface between external Unit 131 and integration device 100 act and transmit, for example, the following status information aspects: i) Transfer (push): read, transform, produce, ii) Request (pull): consume, transform, write, iii) report status.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Theoretical Computer Science (AREA)
  • Economics (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • General Business, Economics & Management (AREA)
  • General Engineering & Computer Science (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Biodiversity & Conservation Biology (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

Es wird eine Integrationsvorrichtung (100) beschrieben, welche aufweist: i) zumindest einen Speicher (120); und ii) zumindest eine Steuervorrichtung (110), insbesondere einen Prozessor, welche mit dem Speicher (120) gekoppelt ist. Die Integrationsvorrichtung (100) ist eingerichtet zum: a) Kommunizieren mit einer Mehrzahl von externen Einheiten (130), wobei das Kommunizieren jeweils aufweist: ai) Erhalten eines Datensatzes von einer der externen Einheiten (130), wobei der Datensatz mit der externen Einheit (130) assoziiert ist, aii) Speichern des Datensatzes, und aiii) Ausgeben eines weiteren Datensatzes, insbesondere welcher mit einer weiteren der externen Einheiten (130) assoziiert ist, an die externe Einheit (130), und b) Bereitstellen und/oder Triggern eines Bereitstellens einer Zustandsinformation (180) betreffend die externe Einheit (130).

Description

Vorrichtung zum Koordinieren einer Mehrzahl von Einheiten mittels Zustandsinformation
Technisches Gebiet
Die Erfindung bezieht sich auf eine Integrationsvorrichtung, welche zumindest einen Speicher und eine Steuervorrichtung aufweist . Ferner bezieht sich die Erfindung auf ein Integriersystem ( Datenaustausch-System) für eine Proj ektierung, wobei das System eine Mehrzahl von externen ( Pro ektierungs- ) Einheiten aufweist , die über die Integrationsvorrichtung gekoppelt sind . Weiterhin bezieht sich die Erfindung auf ein Verfahren für eine Pro ektierung . Zusätzlich bezieht sich die Erfindung auf ein Verwenden der Integrationsvorrichtung und/oder des Integrationssystems in einer Proj ektierung, welche eine Infrastruktur, insbesondere Schieneninfrastruktur, betri f ft .
Die Erfindung kann sich somit auf das technische Gebiet der Kommunikationstechnologie beziehen, insbesondere im Hinblick auf Kommunikation zwischen Proj ektierungseinheiten, z . B . bezüglich einer Schieneninfrastruktur .
Technischer Hintergrund
Eine Viel zahl von Proj ekten ( insbesondere Großproj ekte , welche die Infrastruktur betref fen) benötigt bei der Proj ektierung eine Viel zahl von ( Pro j ektierungs- ) Einheiten, welche miteinander interagieren . Beispielsweise bei der Proj ektierung (Engineering) komplexer interdis ziplinärer Proj ekte wie Schieneninfrastrukturinstallationen sind mehrere Engineering Tools und Prozesse an der Konfiguration der verschiedenen Produkte und Subsysteme beteiligt . Die Sicherstellung der Datenintegrität und -konsistenz über all diese Tools und Prozesse hinweg kann j edoch eine besondere technische Heraus forderung darstellen . Um Zeit zu sparen und die time-to-market des zu entwickelnden Systems zu verkürzen, sollte der Datenaustausch zwischen den Tools und Prozessen möglichst flexibel sein und einen häufigen Austausch, insbesondere ständige Aktualisierung, zwischen den Pro ektierungseinheiten ermöglichen, ohne hierbei die Integrität zu beeinträchtigen .
Ein konventioneller Ansatz in diese Richtung ist es , ein großes ganzheitliches Modell des Gesamtsystems einschließlich aller Subsysteme zu erstellen . Manchmal geht dieser Ansatz sogar noch einen Schritt weiter und versucht eine einzige Anwendung oder ein Anwendungs framework zu erstellen, in dem alle Aspekte integriert sind .
Ein weiterer konventioneller Ansatz basiert auf der Verwendung von Dateien zum Austausch von Daten zwischen Tools und Prozessen . Dieser Ansatz geht einher mit der Definition von Datei formaten und Austauschprotokollen . Darüber hinaus muss bei komplexer werdenden Toolchains ein entsprechendes Verwaltungssystem eingeführt werden, welches den Informations fluss von Dateien verfolgt .
Das Alignment von komplexen Modellen im Stand der Technik nimmt in der Regel viel Zeit in Anspruch und es folgt eine Implementierungsphase , welche ebenfalls lange andauern kann . Daher kommen solche komplexen Systeme oft zu spät , und das Engineering hat bereits ohne sie begonnen . Als Konsequenz werden Workarounds erstellt , die manchmal bis zum Ende des Proj ekts andauern . Sobald das komplexe Modell und die Toolchain eingerichtet sind, sind sie aber in der Regel schwer zu ändern, da viele Abhängigkeiten untereinander bestehen.
Zusammenfassung der Erfindung
Es kann ein Bedarf bestehen, eine effiziente Projektierung (insbesondere eine Pro ektierung im Bereich der Schieneninfrastruktur) mit einer Mehrzahl von beteiligten Pro j ektierungseinheiten bereitzustellen.
Eine Integrationsvorrichtung, ein Integrationssystem, ein Verfahren, und ein Verwenden werden im Folgenden beschrieben.
Gemäß einem ersten Aspekt der Erfindung wird eine Integrationsvorrichtung beschrieben, welche aufweist: i) zumindest einen Speicher (insbesondere einen Ereignisbasierten Speicher) ; und ii) zumindest eine Steuervorrichtung (insbesondere aufweisend zumindest einen Prozessor) , welche mit dem Speicher gekoppelt ist (insbesondere verdrahtet oder drahtlos) .
Die Integrationsvorrichtung ist eingerichtet zum: a) Kommunizieren (insbesondere verdrahtet oder drahtlos) mit einer Mehrzahl von externen Einheiten (insbesondere Projektierungseinheit, z.B. ein Engineering Tool) , wobei das Kommunizieren jeweils aufweist: ai) Erhalten eines Datensatzes (insbesondere betreffend zumindest ein Ereignis) von einer der externen Einheiten (an der Steuervorrichtung der Integrationsvorrichtung) , wobei der Datensatz mit der externen Einheit assoziiert ist (bzw. für diese bestimmte externe Einheit indikativ ist; zu ihr korrespondiert) , aii) Speichern des Datensatzes (im Speicher der Integrationsvorrichtung) , und aiii) Ausgeben (von der Steuervorrichtung der Integrationsvorrichtung) eines weiteren Datensatzes (insbesondere welcher mit einer weiteren der externen Einheiten assoziiert ist und/oder welcher zumindest teilweise den Datensatz aufweist) , an die externe Einheit, und b) Bereitstellen und/oder Triggern eines Bereitstellens (z.B. mittels einer Agent-Funktionalität) einer Zustandsinformation betreffend die externe Einheit (und/oder den (weiteren) Datensatz) .
Gemäß einem zweiten Aspekt der Erfindung wird ein Integrationssystem (Datenaustausch-System) beschrieben, insbesondere für eine Projektierung (weiter insbesondere im Bereich von Schieneninfrastruktur) , das System aufweisend: i) eine Integrationsvorrichtung wie oben beschrieben; und ii) die Mehrzahl von externen Einheiten (welche die externe Einheit und die weitere externe Einheit) umfassen. Hierbei sind die Mehrzahl von externen Einheiten über die Integrationsvorrichtung (miteinander) gekoppelt.
Gemäß einem dritten Aspekt der Erfindung wird ein Verfahren für eine Pro ektierung beschrieben (zum Organisieren von Datensätzen für eine Projektierung) , das Verfahren aufweisend: i) Kommunizieren (insbesondere Datenübertragung) einer Mehrzahl von externen Einheiten mit einer Integrationsvorrichtung, wobei das Kommunizieren jeweils aufweist : ia) Erhalten eines Datensatzes von einer externen Einheit, wobei der Datensatz mit der externen Einheit assoziiert ist, ib) Speichern des Datensatzes, und ic) Ausgeben eines weiteren Datensatzes, insbesondere welcher mit einer weiteren der externen Einheiten assoziiert ist, an die externe Einheit; und ii ) Bereitstellen und/oder Triggern eines Bereitstellens einer Zustandsinformation betref fend die externe Einheit .
Gemäß einem vierten Aspekt der Erfindung wird ein Verwenden beschrieben einer Integrationsvorrichtung und/oder eines Integrationssystems wie oben beschrieben in einer Proj ektierung, welche den Bereich von Infrastruktur, insbesondere Schieneninfrastruktur, betri f ft .
Gemäß einem weiteren Aspekt der Erfindung wird eine Vorrichtung zur Datenverarbeitung beschrieben, welche zumindest einen Prozessor aufweist , und welche eingerichtet das oben beschriebene Verfahren aus zuführen .
Gemäß einem weiteren Aspekt der Erfindung wird ein Computerprogrammprodukt beschrieben, welches Befehle aufweist , die bei der Aus führung des Programms durch einen Computer diesen veranlassen, das oben beschriebene Verfahren aus zuführen .
Im Kontext dieses Dokuments kann sich der Begri f f „Integrationsvorrichtung" insbesondere auf eine Vorrichtung bzw . Struktur beziehen, welche mit einer Mehrzahl von externen Einheiten koppelbar ist und diese externen Einheiten dadurch untereinander indirekt koppeln kann . In anderen Worten kann die Integrationsvorrichtung als Schnittstelle zwischen verschiedenen ( Pro ektierungs- ) Einheiten wirken . In einem Beispiel werden Datensätze der externen Einheiten an die Integrationsvorrichtung übertragen/gesendet und dann gespeichert . In einem weiteren Beispiel werden Datensätze aus dem Speicher gezogen ( angefordert ) und an eine weitere externe Einheit übertragen/gesendet . Zu diesem Zweck kann die Integrationsvorrichtung zumindest eine Steuervorrichtung und den Speicher aufweisen . Vorzugsweise kann der Speicher ein Ereignis-basierter Speicher sein, welcher kontinuierlich Datensätze als Ereignisse speichert, so dass eine Historie von Ereignissen für die Projektierung vorliegen kann. In einem konkreten Ausführungsbeispiel kann die Integrationsvorrichtung als „integrated framework" bezeichnet werden. Ferner kann die Integrationsvorrichtung, insbesondere die Steuervorrichtung, eine Agent-Funktionalität aufweisen oder mit einer solchen koppelbar sein. Hierbei kann die Steuervorrichtung eingerichtet sein ein Bereitstellen von Zustandsinformation betreffend eine bestimmte externe Einheit (und/oder ein oder mehr Datensätze) durchzuführen und/oder ein solches zu triggern .
Im Kontext dieses Dokuments kann sich der Begriff „Zustandsinformation" insbesondere auf eine Information (bzw. Nachricht) beziehen, welche einen Zustand einer der externen Einheiten (insbesondere in Hinblick auf die Organisation von ein oder mehr Datensätze (n) ) betrifft. Insbesondere kann die Zustandsinformation einen oder mehr Zustandsinformation- Aspekte betreffen. Hierbei kann z.B. indiziert sein, ob diese Aspekte erledigt oder (noch) nicht erledigt wurden
( abgeschlossen/nicht abgeschossen) . Dies kann z.B. mittels Setzens eines Flags besonders effizient durchführbar sein. In einem Beispiel kann die Integrationsvorrichtung im Rahmen der Zustandsinformation übersichtliche Aussagen darüber treffen, ob ein Datensatz bereits von einer Einheit angefordert wurde oder von einer Einheit bereitgestellt wurde. Ferner kann z.B. der Status eines Datensatzes und/oder einer externen Einheit als erledigt oder nicht-erledigt indiziert werden.
Im Kontext dieses Dokuments kann sich der Begriff „Datensatz" insbesondere auf eine Mehrzahl von Informationen und/oder Daten (-Punkten) beziehen. Insbesondere können diese Daten in Zusammenhang mit der Entwicklung eines technischen Projekts, z . B . aus dem Schieneninfrastrukturbereich, stehen . Der Datensatz kann Ereignis-basiert sein und sich auf ein bestimmtes Ereignis beziehen bzw . eine bloße Nachricht darstellen . Ferner kann der Datensatz einer bestimmten Thematik zugeordnet sein . In Kontext dieses Dokuments kann sich der Begri f f „Thematik" insbesondere einen bestimmten Aspekt der Proj ektierung beziehen . Eine Thematik kann sich z . B . auf eine Klasse von Entitäten und/oder Obj ekten beziehen . In einem anschaulichen Beispiel wäre " Signale" eine Thematik die sich auf die Informationen einer Viel zahl individueller Signal-Entitäten beziehen kann . Zwei oder mehr externe Einheiten können sich somit auf dieselbe Thematik und/oder auch auf dieselben Entitäten/Ob j ekte innerhalb einer Thematik beziehen .
Der Begri f f „weiterer Datensatz" kann sich auf einen Datensatz beziehen, welcher für eine weitere externe Einheit indikativ ist . Dadurch kann mittels der Zustandsinformation angegeben werden, ob die externe Einheit den weiteren Datensatz einer weiteren externen Einheit innerhalb des System angefordert und erhalten hat . In einem weiteren Beispiel kann der weitere Datensatz auch ( zumindest teilweise ) den Datensatz der externen Einheit aufweisen, z . B . nachdem dieser von einer weiteren Einheit bearbeitet wurde .
Im Kontext dieses Dokuments kann sich der Begri f f „externe Einheit" insbesondere auf eine Hardware und/oder Software beziehen, welche nicht als Teil der Integrationsvorrichtung anzusehen ist . Eine solche externe Einheit kann direkt oder indirekt mit der Integrationsvorrichtung koppelbar sein ( drahtgebunden oder drahtlos ) . Im vorliegenden Kontext generieren die externen Einheiten Datensätze bzw . Ereignisse , tauschen diese untereinander, verändern diese usw . Auf diese Weise kann ein ef fi zienter Datenaustausch im Rahmen einer Proj ektierung erfolgen . In einem bevorzugten Beispiel können die externen Einheiten daher Entwicklungsapplikationen (Engineering Tools ) wie z . B . AutoCAD, RailML, etc . aufweisen .
Gemäß einem exemplarischen Aus führungsbeispiel kann die Erfindung auf der Idee basieren, dass eine ef fi ziente Pro ektierung ( insbesondere eine Entwicklung im Bereich der Schienenfahrzeuge ) mit einer Mehrzahl von beteiligten Entwicklungseinheiten bereitgestellt werden kann, wenn eine Integrationsvorrichtung als zentrale Schnittstelle wirkt , mit welcher die Mehrzahl von externen Einheiten, die mit Datensätzen operieren, koppelbar sind . Hierbei ist die Integrationsvorrichtung eingerichtet mit den externen Proj ektierungseinheiten zu kommuni zieren, i . e . Daten zu übertragen, und mittels dem Bereitstellen von Zustandsinformationen ein einfaches und doch hoch akkurates Mittel bereitzustellen, um den Zustand einer j eden Einheit in Bezug zu den aus zutauschenden Datensätzen und deren Konsistenz und Integrität zu dokumentieren und ständig zu aktualisieren .
Anders als im Stand der Technik ( siehe oben) wird kein umfassendes Modell des Gesamtsystems mit all seinen Subsystemen und Abhängigkeiten generiert . Dadurch reduziert sich die Komplexität beim Aufbau von Toolchains und Engineering-Prozessen erheblich . Mit dem beschriebenen Ansatz kann es möglich sein, ohne großen Anfangsaufwand frühzeitig mit der Proj ektierung und dem Engineering zu beginnen . Darüber hinaus kann die Toolchain im Proj ektverlauf einfach erweitert und angepasst werden . Der Ansatz kann modernen Domain-Driven- Design-Prinzipien folgen, welche mehrere (bevorzugt zumindest teilweise redundante ) domänenspezi fische , optimierte Modelle ermöglichen und sich auf das Management des Austauschs und der Kommunikation zwischen diesen Domänen konzentrieren . Mit diesem Ansatz können Annahmen über die Vollständigkeit und Konsistenz von Daten getrof fen werden, indem einem verteilten Argumentationsansatz gefolgt wird, ohne dass ein ganzheitliches , komplexes , und System-weites Datenmodell aufgebaut werden muss .
Im Vergleich zum reinen Austausch und der Verwaltung der Kommunikation mit Schnittstellendateien kann der vorliegende Ansatz zudem die folgenden Vorteile haben :
Erstens kann es vermieden werden Datei formate und Dateiaustauschprotokolle im Voraus zu definieren, zu vereinbaren, zu pflegen und zu implementieren, was , ähnlich wie oben beschrieben, viel Zeit bei der Proj ekteinrichtung sparen kann .
Darüber hinaus können mit einem Ereignis-basierten System Daten ausgetauscht werden, sobald sie verfügbar sind . Selbst wenn die Daten zu einem bestimmten Zeitpunkt nicht vollständig sind und nicht verwendet werden können, um eine komplexe Schnittstellendatei konsistent zu füllen, können sie dennoch für andere Prozessschritte wertvoll sein und geteilt werden, damit andere Engineering-Prozesse starten und bereits vorhandene Informationen wiederverwenden können .
Mit dem beschriebenen Ansatz können Daten iterativ über die Zeit vervollständigt und so früh wie möglich von anderen Prozessen und Tools genutzt werden . Schließlich kann auch bei einem Datei-basierten Ansatz kein Overhead erforderlich sein . Stattdessen können Verwaltungs funktionen oder -prozesse implementiert werden, um sicherzustellen, dass Daten zur richtigen Zeit im richtigen Umfang bereitgestellt , genutzt und verarbeitet werden . Exemplarische Ausführungsbeispiele
Gemäß einem Ausführungsbeispiel betrifft die Zustandsinformation zumindest einen der folgenden Zustandsinformation-Aspekte : i) Erhalten des Datensatzes an der Integrationsvorrichtung (Übertragen/Senden, „push") , ii) Ausgeben des weiteren Datensatzes von der Integrationsvorrichtung (Anfordern, „pull") , iii) Status des Datensatzes und/oder der externen Einheit.
Dies kann den Vorteil haben, dass die relevanten Daten für die Datenorganisation innerhalb einer Projektierung jederzeit auf übersichtliche Weise einsehbar sind. Bezüglich jeder Einheit des Integrationssystems kann die Integrationsvorrichtung eine Übersicht darüber haben, welche Aufgaben erfüllt wurden und welche zu erfüllen sind. Dadurch kann auch der Zustand des Gesamtsystems schnell und effizient bewertet werden. Insbesondere kann festgestellt werden, ob eine Einheit bereits (alle) ihre Datensätze an die Integrationsvorrichtung übertragen hat. Ferner kann festgestellt werden, ob eine Einheit bereits alle (relevanten) Datensätze (anderer) Einheiten aus der Integrationsvorrichtung gezogen hat. Weiterhin kann festgestellt werden, ob der Status einer Einheit und/oder eines bestimmten Datensatzes bereits zufriedenstellend (z.B. erledigt, prozessiert, konsistent, etc . ) ist .
Die Zustandsinformation-Aspekte können in der Integrationsvorrichtung gespeichert werden und/oder an die externen Einheiten übermittelt werden. Überträgt z.B. eine weitere Einheit einen weiteren Datensatz, welcher für die externe Einheit von Relevanz ist, so wird deren Zustandsinformation-Aspekt ii) auf „nicht abgeschlossen" gesetzt, bis die externe Einheit den weiteren Datensatz anfordert bzw. erhalten hat. Umgekehrt kann dasselbe für die weitere externe Einheit und den Datensatz gelten.
In einem exemplarischen Ausführungsbeispiel können (zumindest) drei unterschiedliche Zustandsgrößen als Zustandsinformation- Aspekte identifiziert werden (siehe auch Figur 2) :
- Status: Zustand innerhalb einer externen Einheit (Applikation/Pro j ektierungsdomäne ) ,
- Pushed: Zustand der Bereitstellung der (insbesondere alle relevanten) Informationen aus einer externen Einheit (Applikation/Pro j ektierungsdomäne) ,
- Pulled: Zustand der Übernahme der (insbesondere alle relevanten) vorhandenen Informationen in eine externe Einheit.
Gemäß einem weiteren Ausführungsbeispiel ist die bereitgestellte Zustandsinformation (bzw. ein Zustandsinformation-Aspekt) dafür indikativ, ob ein abgeschlossener Zustand oder ein nicht abgeschlossener Zustand vorliegt. Dadurch können die externen Projektierungseinheiten besonders effizient und zuverlässig aufeinander abgestimmt werden. Zu jedem Zeitpunkt kann klar ersichtlich sein, welcher Datensatz bei welcher Einheit vorhanden ist bzw. noch fehlt, und welche Aspekte noch bearbeitet werden müssen.
Gemäß einem weiteren Ausführungsbeispiel versetzt ein Vorliegen des abgeschlossenen Zustands bei allen Zustandsinformation-Aspekten die externe Einheit in einen abgeschlossenen Zustand. Dies kann den Vorteil haben, dass eine besonders effiziente und zuverlässige Bewertung des Pro j ekt zustandes erfolgen kann.
In einem exemplarischen Ausführungsbeispiel gilt eine Projektierungsdomäne (externe Einheit) als abgeschlossen, wenn alle drei Zustandsinformation-Aspekte (siehe oben) abgeschlossen ("true") sind. Ferner, wenn alle Zustandsinformationen in allen beteiligten externen Einheiten abgeschlossen ("true") sind, kann gesamte Projektierung als abgeschlossen oder zumindest als zu diesem Zeitpunkt konsistent angesehene werden.
Gemäß einem weiteren Ausführungsbeispiel weist die bereitgestellte Zustandsinformation, insbesondere ein Zustandsinformation-Aspekt, ein Flag auf, insbesondere einen booleschen Wert. Dies kann den Vorteil haben, dass die Zustandsinformation auf besonders einfache aber doch besonders zuverlässige Weise bereitgestellt werden kann. Wie in Figur 2 gezeigt, kann jeder Zustandsinformation-Aspekt ein Flag aufweisen, welches den Zustand „abgeschlossen (true)" oder „nicht-abgeschlossen (false)" aufweist. Ein solcher boolescher Wert kann verschieden darstellbar sein, z.B. 0/1, rot/grün, +/-, etc.
Gemäß einem weiteren Ausführungsbeispiel ist der Datensatz ein Ereignis-basierter Datensatz, insbesondere wobei die externe Einheit Ereignis-basiert operiert. Dies kann den Vorteil haben, dass eine besonderes übersichtliche und interaktive Organisation der Daten ermöglicht ist.
Gemäß einem weiteren Ausführungsbeispiel ist der Datensatz ein Datei-basierter Datensatz, insbesondere wobei die externe Einheit Datei-basiert operiert. Dies kann den Vorteil haben, dass auch Einheiten, welche nicht in eine Ereignis-basierte Datenverarbeitung eingebunden sind, in das Gesamtsystem integriert werden können, wodurch die Flexibilität und Leistungsfähigkeit des Gesamtsystems deutlich höher ausfallen kann . Gemäß einem weiteren Aus führungsbeispiel weist die Integrationsvorrichtung ferner auf : ein Agent-Funktionalität , welche eingerichtet ist einen Datei-basierten Datensatz zumindest teilweise in einen Ereignis-basierten Datensatz zu übertragen und/oder einen Ereignis-basierten Datensatz zumindest teilweise in einen Datei-basierten Datensatz zu übertragen . Dies kann den Vorteil haben, dass auch Legacy- Anwendungen direkt eingebunden werden können, wobei die Integrationsvorrichtung bestenfalls gar nicht „bemerkt" , dass die Agent-Funktionalität als zusätzliche Schnittstelle notwendig ist .
Der Begri f f „Agent-Funktionalität" kann sich in dem Kontext dieses Dokuments insbesondere auf eine Hardware und/oder Software beziehen, welche eingerichtet ist als Schnittstelle zwischen Integrationsvorrichtung und einer externen Einheit zu fungieren, insbesondere wobei die externe Einheit eingerichtet ist Datei-basierte Datensätze bereitzustellen . Die Agent- Funktionalität kann als Teil der Integrationsvorrichtung/ Steuervorrichtung konfiguriert sein, oder auch ein eigenständiger Bereich des Integrationssystems sein . In einem Beispiel ( siehe Figur 3 ) ist die Agent-Funktionalität eingerichtet zwischen Datei ( File ) basierten Datensätzen und Ereignis-basierten Datensätzen zu übertragen/überset zen . In einem Beispiel kann die Agent-Funktionalität selbstständig eine Zustandsinformation bereitstellen und/oder von der Integrationsvorrichtung dazu getriggert werden .
Während Plugln-basierte oder Ereignis-native Anwendungen bei Bedarf direkt mit der Integrationsvorrichtung kommuni zieren, können Agent-basierte Integrationen einen zusätzlichen Kontrollmechanismus benötigen, um die Agenten zu starten, wenn neue Daten verfügbar sind . In einem Beispiel kann die Aus führung von Push-Agenten ( Datenübertragen) z . B . durch Hooks oder Build-Pipelines des verwendeten Datei-basierten Konfigurationsmanagement-Systems ausgelöst werden . Jedes Mal , wenn eine Schnittstellendatei erstellt oder aktualisiert wird, wird ein Ereignis ausgelöst oder eine Pipeline ausgeführt . Während der Aus führung dieses Ereignisses oder dieser Pipeline verwendet die Agent- Funktionalität die Schnittstellendatei und übersetzt sie in Nachrichten für das Ereignis-System .
In einem Beispiel reagieren Pull-Agenten (Anfordern von Daten) auf neue Nachrichten im Ereignis-System, indem sie dessen Datenströme ( Themen) auslesen und aktualisierte Schnittstellendateien basierend auf den aus dem Ereignis- System gelesenen Daten erstellen . Ebenso sind auch manuelle Aus führungen oder extern ausgelöste Agentenaufrufe mögliche Alternativen .
Gemäß einem weiteren Aus führungsbeispiel weist der zumindest eine Speicher einen Ereignis-Speicher (Event-Store , z . B .
Apache Kafka, etc . ) auf . Gemäß einem weiteren Aus führungsbeispiel speichert der Ereignis-Speicher eine Viel zahl von Ereignissen als Blockreihe speichert . Dadurch kann eine etablierte Technik direkt implementiert werden .
Gemäß einem weiteren Aus führungsbeispiel werden Datensätze innerhalb des Ereignis-basierten Speichers im Wesentlichen nicht verändert . Hierdurch kann sich ein besonderer Vorteil im vorliegenden Kontext ergeben : die Daten werden wie vorgesehen gespeichert und nicht manipuliert , so dass sie j ederzeit mit ihrer vollständigen Historie wiederhergestellt werden können . In einem Beispiel finden alle Datenmanipulationen - falls erforderlich - nur während einem Ausgeben aus der Integrationsvorrichtung statt . Ereignis-basierte Systemen wie z . B . Apache Kafka sind bekannt , um Daten zwischen Tools und Prozessen aus zutauschen, um eine Entkopplung zu erreichen . Nativ bieten solche Systeme j edoch keinerlei zusätzlichen Funktionen, die eine Schluss folgerung über Vollständigkeit und Konsistenz des Engineerings zulassen würden . Wenn Ereignis-Systeme in ihrer ursprünglichen Weise verwendet werden, fehlen ihnen Funktionen, um Vollständigkeit und Konsistenz zu bewerten . Bekannte Systeme können die gesendeten Nachrichten verfolgen, haben aber keine Möglichkeit sicherzustellen, dass die Nachrichten verarbeitet und in die Engineering-Daten aller Beteiligten integriert wurden .
Gemäß einem weiteren Aus führungsbeispiel weist die externe Einheit ein Plug-in auf für eine Ereignis-basierte Datenverarbeitung in Zusammenhang mit dem Ereignis-basierten Speicher . Dies kann den Vorteil haben, dass eine direkte Integration mit einfachen Mitteln gelingt . Dadurch kann auf eine zwischengeschaltete Agent-Funktionalität verzichtet werden . Durch diese Maßnahme kann die Flexibilität und Leistungs fähigkeit des Systems erhöht werden .
Gemäß einem weiteren Aus führungsbeispiel weist das Integrationssystem ferner auf : eine Agent-Funktionalität , welche mit der Integrationsvorrichtung gekoppelt ist , insbesondere wobei die Integrationsvorrichtung eingerichtet ist die Agenten-Funktionalität zu Triggern, die Zustandsinformation bereitzustellen . In diesem Aus führungsbeispiel ist die Agent-Funktionalität nicht der Integrationsvorrichtung zugewiesen, sondern eigenständig innerhalb des Integrationssystems . Dennoch kann die Integrationsvorrichtung, in einem Beispiel , ein Bereitstellen von Zustandsinformation-Aspekten durch die Agenten- Funktionalität triggern . In einem anderen Beispiel kann die Agent-Funktionalität (zumindest teilweise) eigenständig Zustandsinformation (-aspekte) bereitstellen .
Gemäß einem weiteren Ausführungsbeispiel weisen die Mehrzahl von externen Einheiten Projektierungseinheiten, insbesondere Engineering-Tools, auf. Dadurch können verschiedene etablierte Systeme (z.B. AutoCAD, RailML, etc.) , welche bei einer Pro ektierung (im Schieneninfrastrukturbereich) eingesetzt werden, besonders effizient, zuverlässig, und flexibel über die Integrationsvorrichtung gekoppelt werden.
Gemäß einem weiteren Ausführungsbeispiel sind die Mehrzahl von externen Einheiten eingerichtet zumindest eine bereitgestellte Zustandsinformation, insbesondere zumindest einen Zustandsinformation-Aspekt, zu verifizieren. Dies kann den Vorteil von Redundanz bieten. Eine solche Verifizierung kann automatisch und/oder manuell erfolgen.
Gemäß einem weiteren Ausführungsbeispiel versetzt ein Vorliegen des abgeschlossenen Zustands bei allen externen Einheiten die Projektierung in einen abgeschlossenen Zustand. Dies kann eine effiziente und zuverlässige Übersicht über einen Pro j ektstatus bereitstellen .
Gemäß einem weiteren Ausführungsbeispiel weist die Integrationsvorrichtung ein künstliche Intelligenz (KI) Modul auf. Dies kann den Vorteil haben, dass die Algorithmen kontinuierlich verbessert werden können, wodurch dann auch das Gesamtergebnis zuverlässiger werden kann.
Im Kontext dieses Dokuments kann der Begriff „KI" sich insbesondere auf Computer-basierte Ansätze zur Nachahmung kognitiver Funktionen eines menschlichen Geistes beziehen, insbesondere Lernen und Problemlösung. Es wurde eine Vielzahl verschiedener mathematischer Algorithmen und Berechnungsmodelle entwickelt , um Kl-Funktionalitäten zu implementieren, beispielsweise „maschinelles Lernen" , „deep learning" , neuronale Netzwerke , genetische Algorithmen, Kernel Regression, etc . Der Hauptzweck dieser Ansätze kann darin gesehen werden, einen vorhandenen Algorithmus zu verbessern, indem er mit Trainingsdaten trainiert wird, so dass ein Lernef fekt auftritt und sich die Problemlösungs fähigkeit des Algorithmus im Laufe der Zeit verbessert . Dies kann mit oder ohne menschliches Eingrei fen ( z . B . Verbessern) geschehen .
Es ist zu beachten, dass Aus führungs formen der Erfindung unter Bezugnahme auf verschiedene Gegenstände beschrieben wurden . Insbesondere wurden einige Aus führungs formen unter Bezugnahme auf Verfahrensansprüche beschrieben, während andere Aus führungs formen unter Bezugnahme auf Vorrichtungsansprüche beschrieben wurden . Ein Fachmann wird j edoch aus dem Vorstehenden und der folgenden Beschreibung entnehmen, dass , sofern nicht anders angegeben, neben j eder Kombination von Merkmalen, die zu einer Art von Gegenstand gehören, auch j ede Kombination von Merkmalen, die sich auf verschiedene Gegenstände beziehen, als von diesem Dokument of fenbart gilt . Dies insbesondere auch zwischen Merkmalen der Verfahrensansprüche und Merkmalen der Vorrichtungsansprüche .
Die oben definierten Aspekte und weitere Aspekte der vorliegenden Erfindung ergeben sich aus den nachstehend zu beschreibenden Beispielen der Aus führungs formen und werden unter Bezugnahme auf die Beispiele der Aus führungs formen erläutert . Die Erfindung wird im Folgenden unter Bezugnahme auf Aus führungs formen, auf die die Erfindung j edoch nicht beschränkt ist , näher beschrieben . Kurze Beschreibung der Zeichnungen
Figur 1 zeigt ein Integrationssystem, in welchem eine Mehrzahl von externen Einheiten mit einer Integrationsvorrichtung kommuni zieren, gemäß einem exemplarischen Aus führungsbeispiel der Erfindung .
Figur 2 zeigt ein Bereitstellen von Zustandsinformation mittels der Integrationsvorrichtung an die Mehrzahl von externen Einheiten, gemäß einem exemplarischen Aus führungsbeispiel der Erfindung .
Figur 3 zeigt ein Übertragen zwischen einem Dateibasierten Datensatz und einem Ereignis-basierten Datensatz innerhalb des Integrationssystems , gemäß einem exemplarischen Aus führungsbeispiel der Erfindung .
Detaillierte Beschreibung der Zeichnungen
Die Darstellung in den Zeichnungen ist schematisch . Es wird darauf hingewiesen, dass in unterschiedlichen Abbildungen ähnliche oder identische Elemente oder Merkmale mit den gleichen Bezugs zeichen oder mit Bezugs zeichen versehen sind, die sich von den entsprechenden Bezugs zeichen nur innerhalb der ersten Zi f fer unterscheiden . Um unnötige Wiederholungen zu vermeiden, werden Elemente oder Merkmale , die bereits in Bezug auf eine zuvor beschriebene Aus führungs form erläutert wurden, an einer späteren Stelle der Beschreibung nicht noch einmal erläutert .
Darüber hinaus werden räumlich relative Begri f fe wie "vorne" und "hinten" , "oben" und "unten" , " links" und " rechts" usw . verwendet , um die Beziehung eines Elements zu einem anderen Element zu beschreiben, wie in den Abbildungen dargestellt . So können die räumlich relativen Begri f fe auf verwendete Orientierungen zutref fen, die von der in den Abbildungen dargestellten Orientierung abweichen. Offensichtlich beziehen sich diese räumlich relativen Begriffe lediglich auf eine Vereinfachung der Beschreibung und die in den Abbildungen gezeigte Orientierung und sind nicht notwendigerweise einschränkend, da eine Vorrichtung gemäß einer Aus führungs form der Erfindung andere Orientierungen als die in den Abbildungen dargestellten annehmen kann, insbesondere wenn sie verwendet wird .
Figur 1 zeigt ein Integrationssystem 150 mit einer Mehrzahl von externen Einheiten 130 und einer Integrationsvorrichtung 100 gemäß einem exemplarischen Ausführungsbeispiel der Erfindung. Die Integrationsvorrichtung 100 weist eine Steuervorrichtung 110 auf, welche mit einem Ereignis-basierten Speicher 120 gekoppelt ist. Die externen Einheiten 130 sind in diesem Beispiel Projektierungseinheiten, welche unabhängig voneinander und eigenständig sind. Jede Einheit verwendet eine eigene Entwicklungsapplikation (Engineering Tool) , z.B. AutoCAD, RailML, Civil 3D, etc.
Datensätze von den jeweiligen externen Einheiten werden im Zuge des Datenaustauschs während einer Projektierung der Integrationsvorrichtung 100 bereitgestellt („push") . Die Steuervorrichtung 110 ist konfiguriert diese Datensätze zu empfangen und in dem Speicher 120 abzulegen (insbesondere wobei die Identifikationsinformation aber nicht verändert wird; somit wird z.B. keine universelle ID im Gesamtsystem verwendet) . Der Speicher 120 ist Ereignis-basiert und speichert jeden Datensatz als ein Ereignis bzw. eine Nachricht. Dadurch ergibt sich eine Blockreihe von Datensät zen/Ereignissen, so dass die gesamte bisherige Projektierung zugänglich ist und nicht manipuliert wird. Die Ereignisse können z.B. nach Thematiken (insbesondere Klassen von Objekten und/oder Entitäten, etc.) klassifiziert werden können . Beispielsweise können sich Datensätze von verschiedenen externen Einheiten auf die Thematik „Signale" beziehen, während sich andere Datensätze der externen Einheiten auf „Weichen" beziehen .
Während der Proj ektierung können einzelne externe Einheiten bestimmte Datensätze benötigen bzw . anfordern . Diese werden dann von der Integrationsvorrichtung 100 ausgegeben ( „pull" ) .
Im gezeigten Beispiel liegen drei Arten von Pro ektierungseinheiten 130 vor : i ) eine native Anwendung 138 operiert Ereignis-basiert , gibt Ereignis-basierte Datensätze aus , und kann daher eine direkte Verbindung zu der Integrationsvorrichtung 100 mit dem Ereignis-basierten Speicher 120 herstellen . Diese nativen Anwendungen 138 werden von Anfang an unter Berücksichtigung einer Ereignis-gesteuerten Architektur entwickelt . ii ) eine Plug- In basierte Anwendung 135 weist einen Plugin auf , um bestehende Anwendungen über die Plugin-Schnittstelle mit der Integrationsvorrichtung 100 mit dem Ereignis-basierten Speicher 120 zu verbinden, um eine Ereignis-gesteuerte Datenverarbeitung zu ermöglichen . iii ) eine Legacy Anwendung 131 operiert Datei-basiert und weist keinen Plugin für eine Schnittstelle auf . In diesem Fall kann eine Agent-Funktionalität 140 verwendet werden, um die bestehende Legacy-Anwendung 131 mit der Integrationsvorrichtung 100 mit dem Ereignis-basierten Speicher 120 zu verbinden . Die Agent-Funktionalität 140 überträgt hierbei einen Datei-basierten Datensatz zumindest teilweise in einen Ereignis-basierten Datensatz . Bevorzugt kann diese Übersetzung autonom und ohne zusätzliche Benutzerinteraktion ausgeführt werden .
In diesem Beispiel ist die Agenten-Funktionalität 140 eigenständig und mit der Integrationsvorrichtung 100 gekoppelt . In einem anderen Beispiel ist die Agenten- Funktionalität 140 in die Integrationsvorrichtung 100 integriert .
Im Beispiel von Figur 1 weist das Integrationssystem 150 somit folgende „Ebenen" auf : i ) Proj ektierungseinheiten 130 (Anwendungen, Engineering Tools ) , ii ) Dateien 160 (Management ) , iii ) Agent-Funktionalität ( integrierend) 140 iv) Integrationsvorrichtung 100 .
Ein Hauptmerkmal und Vorteil dieses Ansatzes ist der verteilte Wirkungsweise der Organisation von Datenintegrität , Vollständigkeit , und Konsistenz . Die Integrationsvorrichtung 100 verfolgt die Nachrichten/Datensätze , die an die einzelnen Einheiten gesendet werden, die Nachrichten/Datensätze , die von den Einheiten empfangen werden, und den Zustand, ob die Nachrichten/Datensätze vollständig von den Einheiten verarbeitet wurden .
Wenn eine externe Einheit 130 alle Informationen der Integrationsvorrichtung 100 konsumiert ( „pull" ) , verarbeitet/prozessiert ( Status ) und freigegeben ( „push" ) hat , kann die Pro ektarbeit dieser Einheit als abgeschlossen betrachtet werden ( siehe im Detail Figur 2 ) . Sobald alle Einheiten in diesem Sinne abgeschlossen sind, kann die gesamte Proj ektierung (Engineering-Toolchain) als abgeschlossen und konsistent betrachtet werden . Die Integrationsvorrichtung 100 wirkt hierbei als Schnittstelle zum Organisieren der Zustandsinformation 180 bezüglich der Mehrzahl von externen Einheiten 130 innerhalb der Projektierung.
Figur 2 zeigt ein Bereitstellen von Zustandsinformation 180 mittels der Integrationsvorrichtung 100 an die Mehrzahl von externen Einheiten 130, gemäß einem exemplarischen Ausführungsbeispiel der Erfindung. Das Integrationssystem 150 ist aufgebaut wie für Figur 1 beschrieben. Im Detail wird aber nun auf die Zustandsinformation 180 eingegangen.
Die Verantwortung für die Bestimmung der Vollständigkeits- und Konsistenzinformationen wird zwischen den Einheiten bzw. den Agentenfunktionalitäten 160 und der Integrationsvorrichtung 100 geteilt. Für jede Projektierungseinheit 130 werden im Rahmen der Zustandsinformation 180 drei Zustandsinformation- Aspekte bestimmt, welche dann als boolesche Werte (Flags) in der Integrationsvorrichtung 100 gespeichert werden können, z .B. :
-Abgerufen (pulled) 182: zutreffend (true) , wenn alle im Ereignissystem (Integrationsvorrichtung 100) verfügbaren Daten ( -sät ze ) von der Einheit 130 abgerufen werden, andernfalls nicht-zutreffend (false) .
-Übertragen (pushed) 181: zutreffend (true) , wenn alle von der Einheit 130 erstellten oder aktualisierten Daten in das Ereignissystem (Integrationsvorrichtung 100) übertragen werden, andernfalls nicht-zutreffend (false) .
-Status 183: zutreffend (true) , wenn die Einheit 130 alle aus dem Ereignissystem (Integrationsvorrichtung 100) abgerufenen Daten verarbeitet hat und sich schließlich in einem konsistenten Zustand in Bezug auf seine eigene Engineering- Domäne und sein eigenes Datenmodell befindet, andernfalls nicht-zutreffend (false) .
Die Integrationsvorrichtung 100 ist dafür verantwortlich, diese Flags 181, 182, 183 (Zustandsinformation-Aspekte der Zustandsinformation 180) dynamisch und kontinuierlich zu aktualisieren. Beispielsweise können diese wie folgt für ungültig erklärt werden: wenn neue Daten von einer Einheit 130 übertragen werden, setzt die Integrationsvorrichtung 100 die abgerufen Datensätze (pulled) 182 und Status-Flags 183 aller anderen Einheiten, die die gleiche Art von Daten verbrauchen, auf nicht-zutreffend (false) . Zuvor kann die Integrationsvorrichtung 100 prüfen, ob die neuen Nachrichten überhaupt zu einer Änderung der im System gespeicherten Informationen führen.
In einer Ausführung sind die Einheiten 130 für die Validierung dieser Flags 181, 182, 183 verantwortlich:
- sobald alle Daten abgerufen und der Einheit 130 zur Verfügung gestellt wurden, wird das Abgeruf en-Flag 182 auf „zutreffend" gesetzt, was in Bezug auf den Ereignis-Speicher 120 (z.B. Apache Kafka) z.B. dem Set zen/Festschreiben des Consumer-Offsets entsprechen kann.
- wenn eine Einheit 130 die Informationen verarbeitet und einen konsistenten/ fertigen Engineering-Zustand erreicht hat, kann sie dies über einen expliziten API-Aufruf (Status Management API wie in Figur 3 gezeigt) an die Integrationsvorrichtung 100 kommunizieren, indem sie das Status-Flag 183 auf „zutreffend" setzt.
- wenn alle resultierenden Informationen des Engineering- Schritts an die Integrationsvorrichtung 100 zurückgesendet werden, kann die Einheit 130 ihr Übertragen-Flag 181 auf „zutref fend" setzen .
Bei Legacy-Anwendungen ( Datei-basierte Einheiten) 131 , die einem Batch-Prozess folgen und keine direkte Verbindung zur Statusverwaltungs-API (Ereignis-basiert ) haben, kann die Agent-Funktionalität 160 eine wichtige Rolle spielen ( insbesondere getriggert durch die Integrationsvorrichtung 100 ) . Die Agent-Funktionalität 160 kann das Status-Flag 183 basierend auf dem Status und dem Inhalt der Schnittstellendateien der Einheit 131 , und eventuell anderen Informationen die sie aus dem Anwendungskontext lesen kann, setzen .
Figur 3 zeigt ein Übertragen eines Datei-basierten Datensatzes 160 in einen Ereignis-basierten Datensatz innerhalb des Integrationssystems 150 , gemäß einem exemplarischen Aus führungsbeispiel der Erfindung . Aus der Sicht der Integrationsvorrichtung 100 sind Datei-basiert operierende Einheiten 131 nur gewöhnliche Einheiten, welche die gleichen drei Flags im Rahmen der Zustandsinformation 180 haben, um Vollständigkeit und Konsistenz zu bewerten . Intern können solche Rule-Engines anhand von Datenmodellen oder anderen geeigneten Methoden überprüfen, ob die Konfiguration der vom Gesamtsysteme vordefinierten Merkmalen folgt , oder ob zusätzliche Abhängigkeiten zwischen Subsystemen korrekt berücksichtigt werden .
Schematisch ist gezeigt , wie die Agent-Funktionalität 140 in beide Richtungen Datei -> Ereignis und Ereignis -> Datei übertragen kann . Hierbei kann die Agent-Funktionalität 140 die Zustandsinformation bereitstellen und/oder von der Integrationsvorrichtung 100 getriggert werden . Die Agent- Funktionalität 140 kann als Interface zwischen externer Einheit 131 und Integrationsvorrichtung 100 wirken, und z.B. folgende Zustandsinformation-Aspekte übertragen: i) Übertragen (push) : Lesen, Transformieren, Produzieren, ii) Anfordern (pull) : Konsumieren, Transformieren, Schreiben, iii) Status berichten.
Es sei darauf hingewiesen, dass der Begriff "aufweisend" andere Elemente oder Schritte nicht ausschließt und die Verwendung des Artikels "ein" eine Vielzahl nicht ausschließt. Auch Elemente, die in Verbindung mit verschiedenen Aus führungs formen beschrieben werden, können kombiniert werden. Es ist auch darauf hinzuweisen, dass Bezugszeichen in den Ansprüchen nicht so ausgelegt werden sollten, dass sie den Umfang der Ansprüche einschränken.
Unabhängig vom grammatikalischen Geschlecht eines bestimmten Begriffes sind Personen mit männlicher, weiblicher oder anderer Geschlechtsidentität mit umfasst.

Claims

Patentansprüche
1. Eine Integrationsvorrichtung (100) , welche aufweist: zumindest einen Speicher (120) ; und zumindest eine Steuervorrichtung (110) , welche mit dem
Speicher (120) gekoppelt ist; wobei die Integrationsvorrichtung (100) eingerichtet ist zum:
Kommunizieren mit einer Mehrzahl von externen Einheiten
(130) , wobei das Kommunizieren jeweils aufweist:
Erhalten eines Datensatzes von einer der externen Einheiten (130) , wobei der Datensatz mit der externen Einheit (130) assoziiert ist,
Speichern des Datensatzes, und
Ausgeben eines weiteren Datensatzes, insbesondere welcher mit einer weiteren der externen Einheiten (130) assoziiert ist, an die externe Einheit (130) , und
Bereitstellen und/oder Triggern eines Bereitstellens einer Zustandsinformation (180) betreffend die externe Einheit (130) .
2. Die Integrationsvorrichtung (100) gemäß Anspruch 1, wobei die Zustandsinformation (180) zumindest einen der folgenden Zustandsinformation-Aspekte betrifft:
Erhalten des Datensatzes an der Integrationsvorrichtung (100) , Ausgeben des weiteren Datensatzes von der Integrationsvorrichtung (100) , Status des Datensatzes und/oder der externen Einheit (130) .
3. Die Integrationsvorrichtung (100) gemäß Anspruch 1 oder 2, wobei die bereitgestellte Zustandsinformation (180) dafür indikativ ist, ob ein abgeschlossener Zustand oder ein nicht abgeschlossener Zustand vorliegt; und/oder wobei ein Vorliegen des abgeschlossenen Zustands bei allen Zustandsinformation-Aspekten dafür indikativ ist, dass bei der externen Einheit (130) ein abgeschlossener Zustand vorliegt.
4. Die Integrationsvorrichtung (100) gemäß einem beliebigen der vorhergehenden Ansprüche, wobei die bereitgestellte Zustandsinformation (180) , insbesondere ein Zustandsinformation-Aspekt, ein Flag aufweist, insbesondere einen booleschen Wert.
5. Die Integrationsvorrichtung (100) gemäß einem beliebigen der vorhergehenden Ansprüche, wobei der Datensatz ein Ereignis-basierter Datensatz ist, insbesondere wobei die externe Einheit (138) Ereignis-basiert operiert, oder wobei der Datensatz ein Datei-basierter Datensatz ist, insbesondere wobei die externe Einheit (131) Datei-basiert operiert .
6. Die Integrationsvorrichtung (100) gemäß einem beliebigen der vorhergehenden Ansprüche, ferner aufweisend: ein Agent-Funktionalität (140) , welche eingerichtet ist einen Datei-basierten Datensatz zumindest teilweise in einen Ereignis-basierten Datensatz zu übertragen, und/oder einen Ereignis-basierten Datensatz zumindest teilweise in einen Datei-basierten Datensatz zu übertragen.
7. Die Integrationsvorrichtung (100) gemäß einem beliebigen der vorhergehenden Ansprüche, wobei der zumindest eine Speicher (120) einen Ereignis- Speicher aufweist, insbesondere wobei der Ereignis-Speicher eine Vielzahl von Ereignissen als Blockreihe speichert, und/oder wobei Datensätze innerhalb des Ereignis-basierten Speichers im Wesentlichen nicht verändert werden.
8. Die Integrationsvorrichtung (100) gemäß Anspruch 7, wobei die externe Einheit (135) ein Plug-in aufweist für eine Ereignis-basierte Datenverarbeitung in Zusammenhang mit dem Ereignis-basierten Speicher (120) .
9. Ein Integrationssystem (150) , insbesondere für eine Projektierung, das System (150) aufweisend: eine Integrationsvorrichtung (100) gemäß einem beliebigen der vorhergehenden Ansprüche; und die Mehrzahl von externen Einheiten (130) ; wobei die Mehrzahl von externen Einheiten (130) über die Integrationsvorrichtung (100) gekoppelt sind.
10. Das Integrationssystem (150) gemäß Anspruch 9, ferner aufweisend : eine Agent-Funktionalität (140) , welche mit der Integrationsvorrichtung (100) gekoppelt ist, insbesondere wobei die Integrationsvorrichtung (100) eingerichtet ist die Agenten-Funktionalität zu Triggern, die Zustandsinformation (180) bereitzustellen.
11. Das Integrationssystem (150) gemäß Anspruch 9 oder 10, wobei die Mehrzahl von externen Einheiten (130) Pro ektierungseinheiten, insbesondere Engineering-Tools, aufweisen .
12. Das Integrationssystem (150) gemäß einem beliebigen der Ansprüche 9 bis 11, wobei die Mehrzahl von externen Einheiten (130) eingerichtet sind zumindest eine bereitgestellte Zustandsinformation (180) , insbesondere zumindest einen Zustandsinformation-Aspekt, zu verifizieren .
13. Das Integrationssystem (150) gemäß einem beliebigen der Ansprüche 9 bis 12, wobei ein Vorliegen des abgeschlossenen Zustands bei allen externen Einheiten (130) dafür indikativ ist, dass für die Projektierung ein abgeschlossenen Zustand vorliegt.
14. Ein Verfahren für eine Pro ektierung, das Verfahren aufweisend :
Kommunizieren einer Mehrzahl von externen Einheiten (130) mit einer Integrationsvorrichtung (100) , wobei das Kommunizieren jeweils aufweist:
Erhalten eines Datensatzes von einer externen
Einheit (130) , wobei der Datensatz mit der externen Einheit (130) assoziiert ist,
Speichern des Datensatzes, und
Ausgeben eines weiteren Datensatzes, insbesondere welcher mit einer weiteren der externen Einheiten (130) assoziiert ist, an die externe Einheit (130) ; und
Bereitstellen und/oder Triggern eines Bereitstellens einer Zustandsinformation (180) betreffend die externe Einheit (130) .
15. Verwenden einer Integrationsvorrichtung (100) gemäß einem beliebigen der Ansprüche 1 bis 8 und/oder einem Integrationssystem (150) gemäß einem beliebigen der Ansprüche
9 bis 13 in einer Projektierung, welche den Bereich von Schieneninfrastruktur betrifft.
EP24710643.8A 2023-03-27 2024-02-26 Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation Pending EP4662616A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102023202792.5A DE102023202792A1 (de) 2023-03-27 2023-03-27 Vorrichtung zum Koordinieren einer Mehrzahl von Einheiten mittels Zustandsinformation
PCT/EP2024/054796 WO2024199852A1 (de) 2023-03-27 2024-02-26 Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation

Publications (1)

Publication Number Publication Date
EP4662616A1 true EP4662616A1 (de) 2025-12-17

Family

ID=90364091

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24710643.8A Pending EP4662616A1 (de) 2023-03-27 2024-02-26 Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation

Country Status (3)

Country Link
EP (1) EP4662616A1 (de)
DE (1) DE102023202792A1 (de)
WO (1) WO2024199852A1 (de)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10681164B2 (en) 2018-05-03 2020-06-09 Microsoft Technology Licensing, Llc Input and output schema mappings

Also Published As

Publication number Publication date
WO2024199852A1 (de) 2024-10-03
DE102023202792A1 (de) 2024-10-02

Similar Documents

Publication Publication Date Title
DE69315378T2 (de) Einen dynamischen Nachrichtenservice verwendendes objektorientiertes Softwaresystem, besonders für eine Kontroll-/Steuer-Vorrichtung für eine redundante Architektur
DE69131500T2 (de) Regelgesteuertes Transaktionsverwaltungssystem und -verfahren
DE10003015A1 (de) Die Erzeugung von Ereignis-Bedingungs-Aktions-Regeln aus Prozessmodellen
EP0685086B1 (de) Einrichtung zur automatischen erzeugung einer wissensbasis für ein diagnose-expertensystem
EP3699704B1 (de) System und verfahren zum überprüfen von systemanforderungen von cyber-physikalischen systemen
DE112017007370B4 (de) Verfahren zur Erzeugung einer Netzwerkkonfigurationsinformation und Kommunikationsgerät
WO2016141998A1 (de) Vorrichtung und verfahren zum bereitstellen einer digitalen abbildung einer physikalischen entität
EP1674954A1 (de) System und Verfahren zur Wiederverwendung von Projektierungsdaten
EP3441919A1 (de) Verfahren zum austausch von daten zwischen engineering-tools eines engineering-systems sowie engineering-system zur durchführung des verfahrens
DE3689502T2 (de) System und Verfahren zur Programmstrukturierung durch Datentabellenübersetzung.
EP4662616A1 (de) Vorrichtung zum koordinieren einer mehrzahl von einheiten mittels zustandsinformation
DE68905848T2 (de) Speicherprogrammierbare steuerung mit strukturierter programmiersprache.
DE3937532C2 (de) Mehrprozessoranlage
WO2024199853A1 (de) Vorrichtung zum integrieren einer mehrzahl von externen projektierungseinheiten
DE3609925C2 (de)
DE102017207036A1 (de) Verfahren zur rechnergestützten Analyse des Betriebs eines Produktionssystems
Bönisch et al. Towards Model-based Product Engineering: Transformation zwischen OPC UA Informationsmodellen und SysML-v2-Systemmodellen
EP4246326B1 (de) Verfahren, vorrichtung und systemanordnung zur prozessüberwachung in echtzeit
Wallner Monitoring and Forecasting of Time Series Data
DE69626964T2 (de) Verfahren zur Steuerung eines Prozessablaufs nach von einem Rechner spezifizierten Verhalten
EP4621679A1 (de) Verfahren und anordnung zur automatisierten erstellung eines industriellen instanz-modells
DE102024103512A1 (de) Computerimplementiertes Verfahren zur Bereitstellung von Artefakten für eine Simulation eines realen Geräts
DE102024113967A1 (de) Computerstruktur zum Übertragen von Daten zwischen einer Vielzahl von funktionalen Einheiten
WO2025257015A1 (de) Computerimplementiertes verfahren und anordnung zum betreiben eines empfehlungssystems, computerlesbarer datenträger und computerprogrammprodukt
WO2014146686A1 (de) Werkzeug und verfahren zur simulation einer technischen anlage

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250908

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR