EP4338050A1 - Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem - Google Patents

Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem

Info

Publication number
EP4338050A1
EP4338050A1 EP22728819.8A EP22728819A EP4338050A1 EP 4338050 A1 EP4338050 A1 EP 4338050A1 EP 22728819 A EP22728819 A EP 22728819A EP 4338050 A1 EP4338050 A1 EP 4338050A1
Authority
EP
European Patent Office
Prior art keywords
container
input
metadata
output
data set
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
EP22728819.8A
Other languages
English (en)
French (fr)
Inventor
Thomas Holm
Jan JENKE
Nikolai FALKE
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.)
Wago Verwaltungs GmbH
Original Assignee
Wago Verwaltungs 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 Wago Verwaltungs GmbH filed Critical Wago Verwaltungs GmbH
Publication of EP4338050A1 publication Critical patent/EP4338050A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
    • G05B19/4188—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM] characterised by CIM planning or realisation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/547—Remote procedure calls [RPC]; Web services
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM]
    • G05B19/4183—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS], computer integrated manufacturing [CIM] characterised by data acquisition, e.g. workpiece identification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources

Definitions

  • the invention generally relates to the field of industrial automation technology and in particular to methods and techniques for dynamic management of runtime containers for operating an industrial automation system.
  • a technical field namely industrial automation technology (AT)
  • these approaches have hardly been used to date.
  • cloud solutions are also increasingly being used in industrial automation technology for analysis, administration and sometimes even for controlling the components of automation environments.
  • data is usually generated by industrial control devices at runtime and sent to one or more cloud systems.
  • An industrial control device can be a programmable logic controller (PLC), for example.
  • PLC programmable logic controller
  • Such a device is typically communicatively connected and implemented with one or more sensors and/or actuators 2
  • a cloud system can generally include a computer system that is remote from the control device. Examples include the WAGO Cloud, Microsoft Azure, Amazon AWS (“Amazon Web Services”), the SAP Cloud or the IBM Cloud.
  • the received data is usually stored, evaluated and/or made available to users prepared for any end device.
  • EP 3249481 Bi a system for executing a closed control loop on data for cloud-based applications. It describes how an industrial controller interacts with a cloud environment and forms a closed loop to perform complex calculations in a cloud without burdening the industrial controller. This is achieved in that so-called cloud variables are generated in the controller, which are forwarded by a cloud agent in the controller for processing in the cloud.
  • EP 3 249481 Bi considers the processing logic on the industrial controller and the cloud application to be monolithic components that hardly affect one another.
  • the present invention is therefore based on the problem of providing methods that allow an industrial control device to access external resources more flexibly.
  • Claim 1 relates to a method in an industrial automation system.
  • An industrial control device sends an input data set to a container manager, the input data set comprising at least (or only) input metadata.
  • the container manager determines a runtime container for processing input data from the industrial control device.
  • Output data is generated based on the input data by an application of the runtime container.
  • the container manager creates an output data set, the output data set including at least output metadata.
  • the container manager sends the output record to the industrial control device.
  • the input data to be processed can be sent directly in the input data record from the industrial control device to the container manager, which can then send them to the runtime container.
  • the data exchange via the container manager can represent a bottleneck in terms of data transmission, which can increase the communication effort.
  • the container manager can send an address of the runtime container to the industrial control device.
  • an address of the industrial control device can be communicated to the runtime container. This can be contained in the metadata of the control device or alternatively be determined by the container manager.
  • the input data can then be passed from the industrial controller directly to the runtime container (i.e. without the involvement of the container manager) and optionally an address of the controller can be passed.
  • the runtime container can send the generated output data to the container manager, which in turn sends it to the industrial control device in the output data set.
  • the runtime container can send the output data directly to an address of the control device.
  • the address can either be known directly from the control program or through the container manager.
  • the invention thus deals with a method and devices in which an industrial control device, in particular a function module thereof, for example from an IEC programming, preferably IEC 61131, is set up in such a way to access external resources.
  • an industrial control device in particular a function module thereof, for example from an IEC programming, preferably IEC 61131, is set up in such a way to access external resources.
  • exemplary embodiments of the invention include the orchestration, ie starting, configuring, monitoring and/or stopping of (software) applications encapsulated in containers from an industrial controller, preferably by the 4
  • Control logic of the real-time system located on the industrial controller can also be run on a different hardware infrastructure (e.g. in a cloud).
  • a method which is carried out by a container manager in an industrial automation system comprises: receiving an input data set from an industrial control device, the input data set comprising at least input metadata; determine, based on the input metadata, a runtime container for processing input data; generating an output data set, the output data set comprising at least output metadata; and sending the output data set to the industrial control device.
  • a corresponding method which is carried out by an industrial control device in an industrial automation system, comprises: Sending an input data set to a container manager, the input data set comprising at least input metadata, the input metadata allowing the container manager to use a runtime container for generating output data determine based on input data; receiving an output record from the container manager, the output record including at least output metadata.
  • the input metadata may include a container type.
  • the developer of the runtime program on the industrial control device can use the container type to define which functionality is to be swapped out in a container. 5
  • the input metadata may also include an input identifier, such as a timestamp, where the output data set includes output metadata, and where the output metadata includes the same input identifier as the associated input metadata. This serves to associate the output data produced by the container with the original input data (e.g. by a timestamp). This enables synchronization despite the asynchronous mode of operation.
  • an input identifier such as a timestamp
  • the input metadata may include a return address, a container identifier, and/or a policy.
  • a policy can define the conditions under which a new container is to be started, an existing container is to be restarted, stopped and/or removed, and allows the control device or its programmer extensive control over the container.
  • the output dataset includes output metadata, it may also include a status.
  • Designating a runtime container to process the input data may include starting a new runtime container or selecting an already running runtime container.
  • determining a runtime container for processing the input data can be based on a current utilization of processing resources for operating runtime containers.
  • the invention further provides a system in its entirety and the above-mentioned devices, each with means for carrying out the methods described herein.
  • a computer program is also provided with instructions for implementing the methods described herein.
  • Fig. 1 A schematic representation of a system environment for a first
  • Fig. 2 A schematic representation of a system environment for a second
  • the system comprises an industrial control device 300, which can be, for example, a programmable logic controller (PLC).
  • PLC programmable logic controller
  • Such a device 300 is typically communicatively connected to one or more sensors and/or actuators and implements tasks in the context of automation technology.
  • An input process image 310 can be created from the sensor data and an output process image 330 can be generated by appropriate processing.
  • a function module (see the module “FUB” in FIG. 1) 320 for communication with the container manager 100 is configured within the control logic of the industrial controller 300 . Data from the control logic can be selected via the module 320 and forwarded to the container manager 100 in a predetermined format as an input data record 210 (see the “input packet type 1” in FIG. 1 and the “input packet” in FIG. 2).
  • Such input packets 210 include at least input metadata in both embodiments (FIGS. 1 and 2).
  • This input metadata can include:
  • a selected container type which specifies the type of container that is to provide the desired functionality (eg specific algorithm).
  • the container type can either be specified by the function module 300 or, in the case of a generic function module 300, specified by the user. Examples of container types can be: anomaly detection algorithms, prediction functions, procedures for phase analysis of the power consumption of cyclic/periodic processes, neural networks, trend/drift detection, dashboards, data loggers and/or programs from other companies in a defined container. 7
  • policies can define, among other things, under what conditions a new container is started, an existing container is restarted, stopped and/or removed.
  • Example 1 As soon as no more data is sent to the container for a defined period of time, it is terminated.
  • Example 2 As soon as no more data is sent to the container for a defined period of time, it is removed.
  • Example 3 The container is never terminated and deleted except by an explicit command.
  • Example 4 The container can be used by several FUBs + combinations with example 1-3.
  • Example 5 The container can only be used by one FUB + combinations with example 1-3.
  • the input packet 210 also includes the actual input data from the control logic (hereinafter also referred to as “input data”), ie the data that is to be processed.
  • input data are sent separately from the control device 300 to the corresponding container 400 (see the "input packet type 2" 215 in FIG. 1). 8th
  • Container manager Message from container manager to FUB - Permanent subscription of the FUB to get status changes.
  • Container manager provides permanent status information, so that the FUB can derive actions when no more status information comes:
  • the task of the container manager 100 is to manage the available containers 400, taking into account the available resources, and to forward the incoming input packets 210 to the containers 400.
  • the container manager 100 decides whether to start a container 400 based on the container type, the policy and/or the container ID. If no container exists yet for the requested container type, a container of this type is typically started. If a container already exists and the policy allows the use of a "shared" container, this can be used.
  • a ContainerID can be used to specify that exactly one container with this ContainerID is used. If this already exists, it will be used, otherwise a new container will be started with this ContainerID. Other rules can be adjusted depending on the application.
  • the input data is forwarded to the appropriate container 400.
  • FIG. The data packets are preferably assigned according to the container type and the container ID.
  • the containers 400 return their results to the container manager 100 and these are inserted by the container manager 100 into output records 220 (see the "Output Packet" in Figure 2).
  • An output data record 220 can include the input ID and/or the status of the corresponding container.
  • the container 400 can also send the output data directly to the industrial control device 300 (see the “Type 2 output packet” 225 in FIG. 1).
  • the status mentioned above can, for example, indicate errors caused by inappropriate input data or program crashes. A status that indicates that the container is still being initialized or that indicates the computing load is also conceivable.
  • the container manager 100 sends the output packets 220 to the appropriate return address(es) specified in the input packet 210 .
  • the function module 320 can then make this data available to the control logic of the industrial controller 300 so that the data is processed there.
  • the container manager 100 container 400 in particular stateless container, on the 10 distribute the hardware available to him so that it can be used in parallel.
  • the container manager 100 can identify the load of the incoming input packets 210 and start another (identical) container 400 if necessary. This distributes the load across multiple containers 400 .
  • the container manager 100 can also be responsible for terminating and/or removing containers 400 that are no longer required, or, if necessary, not creating new containers 400 and rejecting requests from the function modules 320, for example if the hardware is overloaded to operate more containers. In this case, the container manager 100 can take into account the policies contained in the input packets 210 .
  • the invention provides functional building blocks 320 that can be selected by the (IEC) programmer and processed with a SW/HW resource. Everything else is done by the container manager 100.
  • the container manager 100 manages the SW/HW resources and uses the metadata stored in the function modules 320 to select which SW/HW resources are required for the functions required in the function module 320 .
  • These SW/HW resources can be located in a cloud or in an automation network or in a normal GG cluster.
  • An anomaly detection algorithm can be computationally intensive and implemented in a special programming language, so that it should be operated in a container away from the industrial control.
  • the input data could be temperatures and/or vibration in this example.
  • This data is evaluated by the anomaly detection algorithm and the evaluation is sent to the industrial controller.
  • a function module can be used in the usual way, because ideally the container manager provides the anomaly detection in a container in the background.
  • the function block 11 then communicates with the anomaly detection container and forwards the results to the control program.
  • a container can be provided by the container manager, which directly receives the data of the function block and sends the results to it, for example a container with a low-code development environment, such as a Node-RED container.
  • a dashboard container can be provided by the container manager, which directly receives and visualizes the data of the function module. This enables an insight into the process data with little or no effort.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

Ein Verfahren in einem industriellen Automatisierungssystem, umfassend: Senden eines Eingabedatensatzes (210) von einer industriellen Steuerungsvorrichtung (300) an einen Containermanager (100), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst; Bestimmen, durch den Containermanager (100) und basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers (400) zum Verarbeiten von Eingabedaten; Erzeugen von Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers (400); Erzeugen eines Ausgabedatensatzes (220) durch den Containermanager (100), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes (220) von dem Containermanager (100) an die industrielle Steuerungsvorrichtung (300).

Description

1
Verwaltung von Laufzeitcontainem für ein industrielles Automatisierungs System l. Technisches Gebiet
Die Erfindung betrifft allgemein das Gebiet der industriellen Automatisierungstechnik und insbesondere Verfahren und Techniken zur dynamischen Verwaltung von Laufzeitcontainern für den Betrieb eines industriellen Automatisierungssystems.
2. Hintergrund
Im Bereich der allgemeinen Informationstechnologie (IT) sind bereits Techniken bekannt, um Applikationen schnell und unabhängig von der darunterliegenden Hardwareinfrastruktur zu entwickeln. Beispielsweise dienen Ansätze wie „Continuous Depl oyment“ dazu, komplexe Softwareprojekte in weitverteilten
Rechnerinfrastrukturen zu verwalten. Unterstützt werden diese Ansätze typischerweise durch in sog. „Container“ gekapselte Softwareapplikationen. Diese virtualisieren im Gegensatz zu virtuellen Maschinen das Betriebssystem anstelle der Hardware und ermöglichen dadurch Software portierbar und effizient zu gestalten. Eine Technologie, die dabei oft zum Einsatz kommt, ist z.B. die Docker-Technologie, welche primär auf die Virtualisierung mit Linux ausgerichtet ist.
In einem anderen technischen Gebiet, nämlich der industriellen Automatisierungstechnik (AT), werden diese Ansätze bislang kaum verwendet. Andererseits werden im Zuge der vierten industriellen Revolution und der alles durchdringenden Digitalisierung auch in der industriellen Automatisierungstechnik zunehmend Cloud- Lösungen zur Analyse, Verwaltung und teils sogar zur Steuerung der Komponenten von Automatisierungsumgebungen eingesetzt. Hierbei werden üblicherweise von industriellen Steuerungsvorrichtungen zur Laufzeit Daten erzeugt und an ein oder mehrere Cloud-Systeme gesendet. Bei einer industriellen Steuerungsvorrichtung kann es sich beispielsweise um eine speicherprogrammierbare Steuerung (SPS) handeln. Eine solche Vorrichtung ist typischerweise mit einem oder mehreren Sensoren und/ oder Aktoren kommunikativ verbunden und realisiert 2
Aufgaben im Kontext der Automatisierungstechnik. Ein Cloud-System kann im Rahmen der Erfindung allgemein ein von der Steuerungsvorrichtung entferntes Computersystem umfassen. Als Beispiele seien die WAGO Cloud, Microsoft Azure, Amazon AWS („Amazon Web Services“), die SAP Cloud oder die IBM Cloud genannt. Innerhalb des Cloud-Systems werden die empfangenen Daten üblicherweise gespeichert, ausgewertet und/oder Benutzern für beliebige Endgeräte aufbereitet zur Verfügung gestellt.
Beispielsweise ist aus EP 3249481 Bi ein System zur Ausführung eines geschlossenen Regelkreises auf Daten für Cloud-basierte Anwendungen bekannt. Darin wird beschrieben, wie eine Industriesteuerung mit einem Cloud-Umfeld interagiert und einen geschlossenen Regelkreis bildet, um komplexe Berechnungen in einer Cloud durchzuführen, ohne die Industriesteuerung zu belasten. Dies wird dadurch erreicht, dass in der Steuerung sog. Cloud-Variablen erzeugt werden, die von einem Cloud- Agenten in der Steuerung zur Bearbeitung in der Cloud weitergeleitet werden. Die EP 3 249481 Bi betrachtet hierbei die Verarbeitungslogik auf der Industriesteuerung und die Cloud- Anwendung jedoch jeweils als monolithische Komponenten, die kaum Einfluss aufeinander haben.
Der vorliegenden Erfindung liegt deshalb das Problem zugrunde, Verfahren bereitzustellen, die es einer industriellen Steuerungsvorrichtung erlauben, flexibler auf externe Ressourcen zuzugreifen.
3. Zusammenfassung der Erfindung
Dieses Problem wird durch die Gegenstände der unabhängigen Patentansprüche gelöst, wobei die Unteransprüche bevorzugte Weiterbildungen betreffen.
So betrifft Anspruch 1 ein Verfahren in einem industriellen Automatisierungssystem. Eine industrielle Steuerungsvorrichtung sendet einen Eingabedatensatz an einen Containermanager, wobei der Eingabedatensatz mindestens (oder auch nur) Eingabe- Metadaten umfasst. Der Containermanager bestimmt basierend auf den Eingabe- Metadaten einen Laufzeitcontainer zum Verarbeiten von Eingabedaten aus der industriellen Steuerungsvorrichtung. Es werden Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers erzeugt. Der Containermanager erzeugt einen Ausgabedatensatz, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst. Der Containermanager sendet den Ausgabedatensatz an die industrielle Steuerungsvorrichtung. 3
In einer besonders schlichten Implementierung können die zu verarbeitenden Eingabedaten direkt im Eingabedatensatz von der industriellen Steuerungsvorrichtung an den Containermanager gesendet werden, welcher diese dann an den Laufzeitcontainer senden kann. In dieser Ausführungsform kann jedoch der Datentausch über den Containermanager einen Flaschenhals bezüglich der Datenübermittlung darstellen, wodurch sich der Kommunikationsaufwand erhöhen kann. Es ist deshalb alternativ vorgesehen, dass der Containermanager an die industrielle Steuerungsvorrichtung eine Adresse des Laufzeitcontainers senden kann. Optional kann dem Laufzeitcontainer eine Adresse der industriellen Steuerungsvorrichtung mitgeteilt werden. Diese kann in den Metadaten der Steuerungsvorrichtung enthalten sein oder alternativ durch den Containermanager bestimmt werden. Die Eingabedaten können dann von der industriellen Steuerungsvorrichtung direkt an den Laufzeitcontainer übermittelt werden (d.h. ohne Beteiligung des Containermanagers) und optional kann eine Adresse der Steuerungsvorrichtung übermittelt werden.
Auch für die Kommunikation von Ausgabedaten sind zwei Möglichkeiten vorgesehen.
In einer schlichten Implementierung kann der Laufzeitcontainer die erzeugten Ausgabedaten an den Containermanager senden, welcher diese wiederum in dem Ausgabedatensatz an die industrielle Steuerungsvorrichtung sendet. Hierbei ergeben sich dieselben Nachteile bezüglich des Containermanagers als Flaschenhals wie bereits auf der Eingabeseite beschrieben. Alternativ ist es deshalb vorgesehen, dass der Laufzeitcontainer die Ausgabedaten direkt an eine Adresse der Steuerungsvorrichtung senden kann. Die Adresse kann entweder direkt aus dem Steuerungsprogramm oder durch den Containermanager bekannt sein.
Selbstverständlich können beide oben beschriebene Ansätze auch gemischt werden, d.h. die Kommunikation der Eingabedaten kann über den Containermanager stattfinden, wobei die Ausgabedaten direkt übertragen werden, und umgekehrt.
Die Erfindung behandelt somit ein Verfahren und Vorrichtungen, in denen eine industrielle Steuerungsvorrichtung, insbesondere ein Funktionsbaustein davon, beispielsweise aus einer IEC-Programmierung, bevorzugt IEC 61131, derart eingerichtet ist, um auf externe Ressourcen zuzugreifen.
Im Allgemeinen umfassen Ausführungsbeispiele der Erfindung das Orchestrieren, d.h. Starten, Konfigurieren, Überwachen und/oder Stoppen von in Containern gekapselten (Software-)Applikationen aus einer Industriesteuerung heraus, vorzugsweise durch die 4
Steuerungslogik des auf der Industriesteuerung befindlichen Echtzeitsystems. Die in einem Container gekapselte (Software-)Applikation kann dabei abweichend auch auf einer anderen Hardwareinfrastruktur ausgeführt werden (zum Beispiel in einer Cloud).
Durch die Möglichkeit, in Containern gekapselte (Software-)Applikationen aus dem PLC-Programm der industriellen Steuerungsvorrichtung heraus zu starten, zu überwachen und/ oder zu stoppen, werden die Systeme (IT und AT) weiter miteinander vereint. Des Weiteren sind Softwarekomponenten durch Nutzung von Container- Technologien dynamisch aus dem PLC-Programm hinzuladbar, abschaltbar und/oder entfernbar. Letzteres ermöglicht eine konsequente Ausnutzung des Speichers. Außerdem bietet die Auslagerung von in Containern gekapselten Softwareapplikationen eine Brücke zwischen Softwarekomponenten, die in unterschiedlichen Programmiersprachen und Softwareplattformen umgesetzt wurden.
Ebenfalls wird ein Verfahren, welches von einem Containermanager in einem industriellen Automatisierungssystem durchgeführt wird, bereitgestellt. Dieses Verfahren umfasst: Empfangen eines Eingabedatensatzes von einer industriellen Steuerungsvorrichtung, wobei der Eingabedatensatz mindestens Eingabe-Metadaten umfasst; Bestimmen, basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers zum Verarbeiten von Eingabedaten; Erzeugen eines Ausgabedatensatzes, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst; und Senden des Ausgabedatensatzes an die industrielle Steuerungsvorrichtung.
Ein entsprechendes Verfahren, welches von einer industriellen Steuerungsvorrichtung in einem industriellen Automatisierungssystem durchgeführt wird, umfasst: Senden eines Eingabedatensatzes an einen Containermanager, wobei der Eingabedatensatz mindestens Eingabe-Metadaten umfasst, wobei die Eingabe-Metadaten es dem Containermanager erlauben, einen Laufzeitcontainer zum Erzeugen von Ausgabedaten auf Basis von Eingabedaten zu bestimmen; Empfangen eines Ausgabedatensatzes von dem Containermanager, wobei der Ausgabedatensatz mindestens Ausgabe-Metadaten umfasst.
In einem weiteren Aspekt der Erfindung können die Eingabe-Metadaten einen Containertyp umfassen. Anhand des Containertyps kann der Entwickler des Laufzeitprogrammes auf der industriellen Steuerungsvorrichtung definieren, welche Funktionalität in einen Container ausgelagert werden soll. 5
Die Eingabe-Metadaten können auch einen Eingabe-Identifizierer, beispielsweise einen Zeitstempel, umfassen, wobei der Ausgabedatensatz Ausgabe-Metadaten umfasst und wobei die Ausgabe-Metadaten denselben Eingabe-Identifizierer wie die zugehörigen Eingabe-Metadaten umfassen. Dies dient dazu, die durch den Container erzeugten Ausgabedaten den ursprünglichen Eingabedaten zuzuordnen (beispielsweise durch einen Zeitstempel). Hierdurch wird eine Synchronisation trotz der asynchronen Arbeitsweise ermöglicht.
Ferner können die Eingabe-Metadaten eine Rücksendeadresse, einen Container- Identifizierer und/oder eine Policy umfassen. Eine Policy kann definieren, unter welchen Voraussetzungen ein neuer Container gestartet, ein bestehender Container neu gestartet, gestoppt und/ oder entfernt werden soll, und ermöglicht der Steuerungsvorrichtung bzw. deren Programmierer eine weitreichende Kontrolle über die Container.
Wenn der Ausgabedatensatz Ausgabe-Metadaten umfasst, können diese auch einen Status umfassen.
Das Bestimmen eines Laufzeitcontainers zum Verarbeiten der Eingabedaten kann ein Starten eines neuen Laufzeitcontainers oder ein Auswahlen eines bereits laufenden Laufzeitcontainers umfassen.
Ferner kann das Bestimmen eines Laufzeitcontainers zum Verarbeiten der Eingabedaten auf einer momentanen Auslastung von Verarbeitungsressourcen zum Betrieb von Laufzeitcontainern basieren.
Die Erfindung stellt ferner ein System in seiner Gesamtheit und die oben genannten Vorrichtungen bereit, jeweils mit Mitteln zur Ausführung der hier beschriebenen Verfahren. Außerdem wird ein Computerprogramm bereitgestellt mit Anweisungen zum Implementieren der hier beschriebenen Verfahren.
4. Kurze Beschreibung der Zeichnungen
Im Folgenden werden bevorzugte Ausführungsbeispiele der vorliegenden Erfindung unter Bezugnahme auf die begleitenden Figuren erläutert:
Fig. 1: Eine schematische Darstellung einer Systemumgebung für eine erste
Ausführungsform der Eründung. 6
Fig. 2: Eine schematische Darstellung einer Systemumgebung für eine zweite
Ausführungsform der Erfindung.
5. Detaillierte Beschreibung bevorzugter Ausführungsformen
Im Folgenden werden gegenwärtig bevorzugte Ausführungsbeispiele eines erfindungsgemäßen Verfahrens zum Betrieb eines industriellen Automatisierungssystems genauer erläutert.
In Fig. 1 und 2 sind zwei beispielhafte Ausführungsformen eines Automatisierungssystems gezeigt. In beiden Ausführungsformen umfasst das System eine industrielle Steuerungsvorrichtung 300, bei der es sich beispielsweise um eine speicherprogrammierbare Steuerung (SPS) handeln kann. Eine solche Vorrichtung 300 ist typischerweise mit einem oder mehreren Sensoren und/oder Aktoren kommunikativ verbunden und realisiert Aufgaben im Kontext der Automatisierungstechnik. Aus den Sensordaten kann hierbei ein Eingangsprozessabbild 310 erstellt und durch eine entsprechende Verarbeitung ein Ausgangsprozessabbild 330 erzeugt werden.
Innerhalb der Steuerungslogik der Industriesteuerung 300 wird ein Funktionsbaustein (siehe den Baustein „FUB“ in Fig. 1) 320 für die Kommunikation mit dem Containermanager 100 konfiguriert. Über den Baustein 320 können Daten aus der Steuerungslogik ausgewählt und in einem vorgegebenen Format als Eingabedatensatz 210 (siehe das „Inputpaket Typ 1“ in Fig. 1 und das „Inputpaket“ in Fig. 2) an den Containermanager 100 weitergeleitet werden.
Solche Inputpakete 210 umfassen in beiden Ausführungsformen (Fig. 1 und 2) zumindest Eingabe-Metadaten. Diese Eingabe-Metadaten können umfassen:
- Einen ausgewählten Containertyp, welcher die Art des Containers angibt, der die gewünschte Funktionalität (z.B. spezifischer Algorithmus) bereitstellen soll. Der Containertyp kann entweder durch den Funktionsbaustein 300 vorgegeben sein oder im Fall eines generischen Funktionsbausteins 300 durch den Benutzer spezifiziert werden. Beispiele für Container-Typen können sein: Anomalie- Erkennungsalgorithmen, Vorhersage-Funktionen, Verfahren zur Phasenanalyse der Leistungsaufnahme zyklischer/periodischer Prozesse, Neuronale Netze, Trend/Drifterkennung, Dashboards, Daten-Logger und/oder Programme anderer Firmen in einem definierten Container. 7
- Einen eindeutigen Eingabe-Identifizierer (siehe „Input ID“ in Fig. 2), um der Ausgabe das Inputpaket und den Funktionsbaustein im späteren Verlauf zuordnen zu können.
- Eine Rücksendeadresse (sofern erforderlich).
- Einen Container-Identifizierer (siehe „Container ID“ in Fig. 1 und 2; optional und je nach konkreter Umsetzung).
- Eine optionale Policy mit einer oder mehreren Variablen. Solche Policies können unter anderem definieren, unter welchen Voraussetzungen ein neuer Container gestartet wird, ein bestehender Container neu gestartet, gestoppt und/oder entfernt wird.
Beispiel 1: Sobald über einen definierten Zeitraum keine Daten mehr an den Container gesendet werden, wird dieser beendet.
Beispiel 2: Sobald über einen definierten Zeitraum keine Daten mehr an den Container gesendet werden, wird dieser entfernt.
Beispiel 3: Der Container wird nie beendet und gelöscht, außer durch einen expliziten Befehl.
Beispiel 4: Der Container kann von mehreren FUBs verwendet werden + Kombinationen mit Beispiel 1-3.
Beispiel 5: Der Container kann nur von einem FUB verwendet werden + Kombinationen mit Beispiel 1-3.
Es versteht sich, dass in alternativen Ausführungsformen auch nur Teilmengen der obigen Daten als Metadaten Verwendung finden können.
In der Ausführungsform nach Fig. 2 umfasst das Inputpaket 210 ferner auch die eigentlichen Eingabedaten aus der Steuerungslogik (nachfolgend auch als „Inputdaten“ bezeichnet), d.h. denjenigen Daten, die verarbeitet werden sollen. In der Ausführungsform nach Fig. 1 werden die Eingabedaten hingegen separat von der Steuerungsvorrichtung 300 an den entsprechenden Container 400 gesendet (siehe das „Inputpaket Typ 2“ 215 in Fig. 1). 8
Nachfolgend wird eine beispielhafte Realisierung der Datenkommunikation im JSON- Format beschrieben:
Erste Verbindung zum Containermanager:
Json
Topic: ContainerManager
Payload: { 'returnAddress': '...', 'containerType': policy: ', 'containerConfig': , 'projectID':
}
Mitteilung vom Containermanager an FUB - Dauerhafte Subscription des FUB, um Statusänderungen mitzubekommen. Containermanager liefert dauerhaft Statusinformation, sodass der FUB Handlungen ableiten kann, wenn keine Statusinformationen mehr kommen:
Topic: 'Pfcldl/Instanzldl'
Payload: {'time': 'containerStatus':
'inputAddress': 'outputAddress': ,
}
Daten vom FUB:
Topic:
Payload: {
'data': [{'time': '2020-06-29T09:09:54.874Z', 'valuel':
1.2, 'value2': 1.4, ...., 'xyz' : [221, 213, 213]}],
'outputAddress': ,
'sourcelD':
}
Daten vom Modell:
Topic: 'Pfcldl/Instanzldl/output'
Payload: {
'data': [{'time': '2020-06-29T09:09:54.874Z',
'resultl':1.23, 'result2':2.34}],} 9
Die Aufgabe des Containermanagers 100 besteht darin, die verfügbaren Container 400 unter Berücksichtigung der verfügbaren Ressourcen zu verwalten und die eingehenden Inputpakete 210 an die Container 400 weiterzuleiten. Wenn der Containermanager 100 einen neuen Input 210 empfängt, entscheidet er anhand des Containertyps, der Policy und/oder der Container ID, ob ein Container 400 gestartet wird. Wenn für den angeforderten Containertyp noch kein Container existiert, wird typischerweise ein Container dieses Typs gestartet. Sofern ein Container bereits existiert und die Policy die Verwendung eines „geteilten“ Containers zulässt, kann dieser verwendet werden. Durch eine ContainerID kann spezifiziert werden, dass genau ein Container mit dieser ContainerID verwendet wird. Existiert dieser bereits, wird dieser verwendet, andernfalls wir ein neuer Container mit dieser ContainerID gestartet. Weitere Regeln sind je nach Anwendungsfall anpassbar.
In der Ausführungsform nach Fig. 2 werden die lnputdaten an den entsprechenden Container 400 weitergeleitet. Die Zuordnung der Datenpakete erfolgt vorzugsweise nach dem Containertyp sowie der Container ID.
In der Ausführungsform nach Fig. 2 geben die Container 400 ihre Ergebnisse an den Containermanager 100 zurück und diese werden vom Containermanager 100 in Ausgabedatensätze 220 (siehe das „Outputpaket“ in Fig. 2) eingefügt. Ein Ausgabedatensatz 220 kann hierbei die Input ID und/ oder den Status des entsprechenden Containers umfassen. Alternativ dazu kann der Container 400 die Ausgabedaten auch direkt an die industrielle Steuerungsvorrichtung 300 senden (siehe das „Outputpaket Typ 2“ 225 in Fig. 1). Der oben erwähnte Status kann beispielsweise Fehler durch unpassende lnputdaten oder Programmabstürze anzeigen. Denkbar ist auch ein Status, der anzeigt, dass sich der Container noch in der Initialisierung befindet oder die Rechenlast anzeigt.
In beiden Ausführungsformen sendet der Containermanager 100 die Outputpakete 220 an die passende(n) Rücksendeadresse(n), welche im Inputpaket 210 angegeben wurden.
Im Folgenden kann der Funktionsbaustein 320 diese Daten der Steuerungslogik der Industriesteuerung 300 zur Verfügung stellen, sodass die Daten dort verarbeitet werden.
Um eine besonders effiziente Verteilung der Auslastung zu ermöglichen, kann der Containermanager 100 Container 400, insbesondere zustandslose Container, auf die 10 ihm zur Verfügung stehende Hardware verteilen, sodass diese parallel verwendet werden können. Hierfür kann der Containermanager 100 die Last der eingehenden Inputpakete 210 identifizieren und bei Bedarf einen weiteren (identischen) Container 400 starten. Hierdurch wird die Last auf mehrere Container 400 verteilt.
Der Containermanager 100 kann auch dafür verantwortlich sein, nicht mehr benötigte Container 400 zu beenden und/oder zu entfernen, bzw. wenn erforderlich, keine neuen Container 400 zu erstellen und Anfragen aus den Funktionsbausteinen 320 abzulehnen, beispielsweise wenn die Hardware zu stark ausgelastet ist, um weitere Container zu betreiben. Hierbei kann der Containermanager 100 die Policies, die in den Inputpaketen 210 enthalten sind, berücksichtigen.
Ferner können noch weitere Funktionalitäten zum direkten Ansprechen des Containermanagers 100 über zusätzliche Funktionsbausteine 320 ermöglicht werden, beispielsweise den Containerstart, Containerupdate, Löschen sowie Beenden des Containers und/oder eine Übersicht der aktuellen Containerstatus.
Zusammenfassend stellt die Erfindung in einer bevorzugten Ausführungsform Funktionsbausteine 320 bereit, die vom (IEC-)Programmierer ausgewählt werden können und mit einer SW/HW-Ressource verarbeitet werden. Alles weitere wird durch den Containermanager 100 erledigt. Der Containermanager 100 verwaltet die SW/HW- Ressourcen und wählt anhand der in den Funktionsbausteinen 320 hinterlegten Metadaten, welche SW/HW-Ressourcen für die im Funktionsbaustein 320 erforderlichen Funktionen erforderlich sind. Diese SW/HW-Ressourcen können sich sowohl in einer Cloud oder in einem Automatisierungsnetz oder in einem normalen GG- Cluster befinden.
Nachfolgend werden beispielhafte Einsatzszenarien erläutert:
Anomalie-Erkennung: Ein Anomalie-Erkennungsalgorithmus kann rechenintensiv und in einer speziellen Programmiersprache implementiert sein, sodass dieser in einem Container abseits der Industriesteuerung betrieben werden soll. Die Eingabedaten könnten in diesem Beispiel Temperaturen und/oder Vibration sein. Diese Daten werden von dem Anomalie-Erkennungsalgorithmus bewertet und die Bewertung wird an die Industriesteuerung gesendet. Hierbei kann ein Funktionsbaustein in gewohnter Weise genutzt werden, denn idealerweise stellt der Containermanager im Hintergrund die Anomalie-Erkennung in einem Container bereit. Der Funktionsbaustein 11 kommuniziert im Folgenden mit dem Anomalie-Erkennungscontainer und gibt die Ergebnisse in das Steuerungsprogramm weiter.
Einbindung einer dritten Partei: Durch den Containermanager kann ein Container bereitgestellt werden, der direkt die Daten des Funktionsbausteins empfängt und die Ergebnisse an diesen sendet, beispielsweise ein Container mit einer Low-Code Entwicklungsumgebung, wie beispielsweise ein Node-RED-Container.
Dashboard: Durch den Containermanager kann ein Dashboard-Container bereitgestellt werden, der direkt die Daten des Funktionsbausteins empfängt und visualisiert. Hierdurch wird ein Einblick in die Prozessdaten ohne bzw. mit minimalem Aufwand ermöglicht.

Claims

12 Ansprüche
1. Ein Verfahren in einem industriellen Automatisierungssystem, umfassend:
Senden eines Eingabedatensatzes (210) von einer industriellen Steuerungsvorrichtung (300) an einen Containermanager (100), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst;
Bestimmen, durch den Containermanager (100) und basierend auf den Eingabe- Metadaten, eines Laufzeitcontainers (400) zum Verarbeiten von Eingabedaten;
Erzeugen von Ausgabedaten auf Basis der Eingabedaten durch eine Applikation des Laufzeitcontainers (400);
Erzeugen eines Ausgabedatensatzes (220) durch den Containermanager (100), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst; und
Senden des Ausgabedatensatzes (220) von dem Containermanager (100) an die industrielle Steuerungsvorrichtung (300).
2. Ein Verfahren, welches von einem Containermanager (100) in einem industriellen Automatisierungssystem durchgeführt wird und umfasst:
Empfangen eines Eingabedatensatzes (210) von einer industriellen Steuerungsvorrichtung (300), wobei der Eingabedatensatz (210) mindestens Eingabe- Metadaten umfasst;
Bestimmen, basierend auf den Eingabe-Metadaten, eines Laufzeitcontainers (400) zum Verarbeiten von Eingabedaten;
Erzeugen eines Ausgabedatensatzes (220), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst; und
Senden des Ausgabedatensatzes (220) an die industrielle Steuerungsvorrichtung (300). 13
3. Ein Verfahren, welches von einer industriellen Steuerungsvorrichtung (300) in einem industriellen Automatisierungssystem durchgeführt wird und umfasst:
Senden eines Eingabedatensatzes (210) an einen Containermanager (100), wobei der Eingabedatensatz (210) mindestens Eingabe-Metadaten umfasst, wobei die Eingabe-Metadaten es dem Containermanager (100) erlauben, einen Laufzeitcontainer (400) zum Erzeugen von Ausgabedaten auf Basis von Eingabedaten zu bestimmen;
Empfangen eines Ausgabedatensatzes (220) von dem Containermanager (100), wobei der Ausgabedatensatz (220) mindestens Ausgabe-Metadaten umfasst.
4. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe- Metadaten einen Containertyp umfassen.
5. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe- Metadaten einen Eingabe-Identifizierer, insbesondere einen Zeitstempel, umfassen, wobei der Ausgabedatensatz (220) Ausgabe-Metadaten umfasst und wobei die Ausgabe-Metadaten denselben Eingabe-Identifizierer wie die zugehörigen Eingabe- Metadaten umfassen.
6. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe- Metadaten eine Rücksendeadresse umfassen.
7. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe- Metadaten einen Container-Identifizierer umfassen.
8. Das Verfahren nach einem der vorstehenden Ansprüche, wobei die Eingabe- Metadaten eine Policy umfassen.
9. Das Verfahren nach einem der vorstehenden Ansprüche, wobei der Ausgabedatensatz (220) Ausgabe-Metadaten umfasst und die Ausgabe-Metadaten einen Status umfassen.
10. Das Verfahren nach einem der vorstehenden Ansprüche wobei das Bestimmen eines Laufzeitcontainers (400) zum Verarbeiten der Eingabedaten umfasst:
Starten eines neuen Laufzeitcontainers (400); oder
Auswahlen eines bereits laufenden Laufzeitcontainers (400). 14
11. Das Verfahren nach einem der vorstehenden Ansprüche wobei das Bestimmen eines Laufzeitcontainers (400) zum Verarbeiten der Eingabedaten ferner auf einer momentanen Auslastung von Verarbeitungsressourcen zum Betrieb von Laufzeitcontainern (400) basiert.
12. Ein System oder eine Vorrichtung, umfassend Mittel zur Ausführung eines Verfahrens nach einem der Ansprüche 1-11.
13. Ein Computerprogramm, umfassend Befehle, die bei der Ausführung des Programms durch einen Computer diesen veranlassen, ein Verfahren nach einem der Ansprüche 1-11 auszuführen.
EP22728819.8A 2021-05-11 2022-05-11 Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem Pending EP4338050A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021204757.2A DE102021204757A1 (de) 2021-05-11 2021-05-11 Verwaltung von Laufzeitcontainern für ein industrielles Automatisierungssystem
PCT/EP2022/062785 WO2022238482A1 (de) 2021-05-11 2022-05-11 Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem

Publications (1)

Publication Number Publication Date
EP4338050A1 true EP4338050A1 (de) 2024-03-20

Family

ID=81984829

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22728819.8A Pending EP4338050A1 (de) 2021-05-11 2022-05-11 Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem

Country Status (5)

Country Link
US (1) US20240077856A1 (de)
EP (1) EP4338050A1 (de)
CN (1) CN117296044A (de)
DE (1) DE102021204757A1 (de)
WO (1) WO2022238482A1 (de)

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9825949B2 (en) 2014-03-26 2017-11-21 Rockwell Automation Technologies, Inc. Device authentication to facilitate secure cloud management of industrial data
US10516733B2 (en) * 2014-11-25 2019-12-24 Auth0, Inc. Multi-tenancy via code encapsulated in server requests
EP3611581B1 (de) 2016-05-25 2021-11-10 Siemens Aktiengesellschaft Industrielles steuergerät und zur steuerung einer industriellen aktivität konfiguriertes verfahren
US10303492B1 (en) * 2017-12-13 2019-05-28 Amazon Technologies, Inc. Managing custom runtimes in an on-demand code execution system
US10223242B1 (en) 2018-08-27 2019-03-05 Capital One Services, Llc Testing an application in a production infrastructure temporarily provided by a cloud computing environment
US11010149B2 (en) 2019-04-03 2021-05-18 International Business Machines Corporation Shared middleware layer containers

Also Published As

Publication number Publication date
WO2022238482A1 (de) 2022-11-17
CN117296044A (zh) 2023-12-26
US20240077856A1 (en) 2024-03-07
DE102021204757A1 (de) 2022-11-17

Similar Documents

Publication Publication Date Title
DE60318651T2 (de) Verfahren und Vorrichtung zur dynamischen Konfigurationsverwaltung
DE69819211T2 (de) Verteilte interfacearchitektur einer programmierbaren industriellen steuerung
EP3627800B1 (de) Publish-/subscribe-kommunikation von maschinensteuerungsdaten
DE10049504B4 (de) Verfahren und System zur tranparenten Unterstützung von entfernten Eingabe-/Ausgabeeinrichtungen in einem Prozeßsteuersystem
EP3230856B1 (de) Verfahren zum update von firmware von geräten
DE102010029952A1 (de) Verfahren zum Integrieren von zumindest einem Feldgerät in ein Netzwerk der Automatisierungstechnik
DE10251523A1 (de) System und Verfahren zur Bereitstellung von Daten und Diensten für Geräte, sowie Gerät, welches die bereitgestellten Daten und Dienste verwendet
EP2902857B1 (de) Verfahren zur Bereitstellung von Funktionen innerhalb eines industriellen Automatisierungssystems und industrielles Automatisierungsystem
EP3200034B1 (de) Zugriff auf daten oder funktionen einer speicherprogrammierbaren steuerung mittels eines webdienstes
EP1653308B1 (de) System und Verfahren zur Speicherung und Bereitstellung von Informationen
WO2021089310A1 (de) Verfahren und vorrichtung zum verwalten von zugriffen mehrerer softwarekomponenten auf softwareschnittstellen
WO2022238482A1 (de) Verwaltung von laufzeitcontainern für ein industrielles automatisierungssystem
WO2019192844A1 (de) Verfahren und vorrichtung zur darstellung und anpassung von konfigurationen von anlagekomponenten
WO2007009884A2 (de) Verfahren zur dynamischen dienstekonfiguration eines technischen systems
EP1536328A2 (de) Datenverarbeitungssystem mit automatisierbarer Verwaltung und Verfahren zur automatisierten Verwaltung eines Datenverarbeitungssystems
EP1227379B1 (de) Verfahren und Vorrichtung zur Steuerung einer Maschine in einem Fertigungssystem
EP4046340B1 (de) Verfahren zum betreiben eines automatisierungssystems und dateninfrastruktur
WO2016092006A1 (de) Firmware-management-system sowie firmware-management-verfahren zum update von firmware von geräten
DE60315264T2 (de) Durch timebox angesteuertes scheduling von softwarekomponenten in hard-echtzeitsystemen
WO2023001437A1 (de) Verfahren zur automatischen anpassung der internen konfiguration einer externen netzwerkschnittstelle, computerprogrammprodukt und vorrichtung
DE102019202134A1 (de) Verfahren und Vorrichtung zum Übertragen und zum Bereitstellen von Daten in einem Publish-Subscribe-System
WO2023138721A1 (de) Verfahren zum erzeugen eines fähigkeitenprofils einer recheneinheit
EP4332772A1 (de) Data distribution service-fähiger controller
DE102019219031A1 (de) Übertragungsverfahren
WO2020188082A1 (de) Verfahren und vorrichtungen für eine lastzuweisung und überwachung für eine zuzuweisende versorgungssicherheitskritische ressource in einem netzwerk

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: 20231020

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 MK MT NL NO PL PT RO RS SE SI SK SM TR