EP4005160A1 - Effizienter heartbeat-mechanismus für cloud-anwendungen - Google Patents

Effizienter heartbeat-mechanismus für cloud-anwendungen

Info

Publication number
EP4005160A1
EP4005160A1 EP20746913.1A EP20746913A EP4005160A1 EP 4005160 A1 EP4005160 A1 EP 4005160A1 EP 20746913 A EP20746913 A EP 20746913A EP 4005160 A1 EP4005160 A1 EP 4005160A1
Authority
EP
European Patent Office
Prior art keywords
gateway
cloud service
central cloud
message
communication
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
EP20746913.1A
Other languages
English (en)
French (fr)
Inventor
Thomas Gollackner
Daniel Bögli
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 Schweiz AG
Original Assignee
Siemens Schweiz AG
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 Schweiz AG filed Critical Siemens Schweiz AG
Publication of EP4005160A1 publication Critical patent/EP4005160A1/de
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources

Definitions

  • the invention relates to a method for checking the operational readiness of a communication link between a gateway and a central cloud service.
  • the invention also relates to a gateway set up to carry out the method.
  • Gateways are also used to connect networks (e.g. networks at corresponding customers) with a cloud infrastructure. This allows network nodes, for example, to access services from cloud applications.
  • a message is periodically sent over the connection to check the operational readiness of the communication connection (heartbeat function).
  • MQTT Message Queuing Telemetry Transport
  • a gateway comprising a communication component which is set up for a data communication with a central cloud service, a check message (heartbeat) being able to be sent from the communication component to the central cloud service to check the operational readiness of the communication connection between the gateway and the central cloud service, the check message being useful information ( payload) from further components of the gateway. If useful information (payload) from other components of the gateway is available or available, this useful information is transmitted together with the verification message.
  • the verification message advantageously has a corresponding data format or a data protocol in order to transmit the useful information.
  • the gateway is advantageously an edge device (edge device computer, edge device, edge gateway).
  • the gateway can also be a correspondingly set up and configured "general purpose" computer with processor, memory, input / output means, communication means.
  • the gateway according to the invention enables one adaptive heartbeat mechanism for cloud applications that can be scaled according to communication requirements
  • the gateway is advantageously a node or a device in a network, e.g. a network of devices (e.g. IoT devices) for building automation.
  • the gateway advantageously provides a communication connection (corresponding hardware and software ) of the network to the Internet or to a cloud infrastructure (e.g. for retrieval or Activation of cloud services).
  • a first advantageous embodiment of the invention is that the data communication to the central cloud service is established by the communication component of the gateway becomes.
  • the fact that the data connection to the cloud is initialized from the gateway (or from the gateway) increases the security of the data connection.
  • the communication connection is advantageously an outgoing connection with bidirectional logic.
  • the communication connection is set up physically from the gateway.
  • the communication link is physically unidirectional, but logically bidirectional.
  • Verification messages and the associated user data can be buffered, compressed or encrypted in the cloud, but also in the gateway.
  • the useful information is an event and / or a change in value and / or a change in status in the gateway.
  • the useful information can therefore be of different data types and values.
  • a further advantageous embodiment of the invention is that the useful information is provided by a corresponding application interface (API) or programming interface for cloud-based applications. Services and applications in the cloud can access the useful information through the application interface (API) or programming interface and use this to provide their services and applications.
  • API application interface
  • API programming interface
  • a further advantageous embodiment of the invention is that the communication component is set up to receive a confirmation from the central cloud service in response to a sent verification message. With the confirmation, the gateway recognizes that the communication connection is ready for operation.
  • the confirmation includes usage formation (payload) of cloud services or cloud applications for the gateway or for components of the gateway.
  • the communication component is set up to send the check message (heartbeat) periodically to the central cloud service at definable time intervals.
  • the interval for checking the operational readiness of the communication connection can thus be changed.
  • the interval of checking the operational readiness of the communication link can advantageously be flexibly adapted to the existing framework conditions or requirements.
  • the time intervals between the verification message (heartbeat) can be set or changed by the gateway or by applications on the gateway.
  • the time intervals for the verification message (heartbeat) can, however, also be set or changed by cloud services, advantageously depending on the requirements (e.g. with regard to the required reliability of the communication connection).
  • a further advantageous embodiment of the invention is that the communication component is set up to send the check message (heartbeat) when requested by the central cloud service.
  • Implementation is advantageously carried out using container technology.
  • Container technology is a software environment , in which the entire code with all dependencies is bundled and can easily be operated on different CPU platforms. This software environment contains all parts for the operation of an application: operating system, code, runtime, system tools, libraries and Settings. This software environment completely isolates the software application from the environment and thus guarantees a high level of security with regard to insulation lation of this process.
  • An alternative term for container technology is the term "sandbox".
  • a container can be updated independently and as a whole, without other containers that are on the same CPU are in operation. It is advantageous to implement it in a container network, comprising containers both in the device (eg edge device) and in the cloud.
  • a further advantageous embodiment of the invention is a computer with memory, processor and communication means, set up to implement a gateway according to the invention.
  • the computer can be a correspondingly set up and configured general purpose computer, eg be a desktop computer, laptop, edge device (edge device, edge device computer, e.g. a set-top box).
  • edge device edge device, edge device computer, e.g. a set-top box
  • any commercially available computer can be configured to act as a gateway according to the invention.
  • the gateway according to the invention in particular connects a building automation network to the Internet.
  • a large number of electronic devices for monitoring and controlling the conditions in a building are provided in the building automation network, in particular for security, fire and flood protection, lighting, heating, ventilation and air conditioning (HVAC).
  • HVAC heating, ventilation and air conditioning
  • the gateway advantageously comprises a local network interface which is configured to connect the gateway to the building automation network for communicating with the plurality of electronic devices, a wide area network interface which is configured to connect the gateway to the Internet, a host Network unit that is configured to provide a host network on which at least one local service that corresponds to the monitoring and control of at least one of the conditions in the building runs, a container network unit that is configured to provide a container network for at least one remote To provide service (remote / remote service), in particular a cloud computing service that is provided by an endpoint device or a cloud on the Internet for at least one of the electronic devices, a loopback network unit that is configured to be a Provide a loopback network interconnecting the host network and the container network, and a selection unit configured to select a connection mode of the gateway by either connecting at least one of the electronic devices to the Internet via the local network interface is or at least one of the electronic hen devices is connected to the Internet via the wide area network interface.
  • a host Network unit that is configured to provide a host network
  • the object is also achieved by a method for checking the operational readiness of a communication connection between a gateway and a central cloud service, with a communication component of the gateway sending a check message (heartbeat) to the central one periodically or on request at definable time intervals Cloud service is sent, wherein the verification message can include useful information (payload) from further components of the gateway.
  • the method does not require a standing communication link between the gateway and the central cloud service or the cloud infrastructure that provides or hosts (implemented) the central cloud service.
  • the communication link can thus also be implemented, for example, by a 3G or 4G network. 5G is not absolutely necessary.
  • the method is particularly suitable for mobile data Usage can be used or optimized so that as little traffic as possible occurs on the communication link.
  • the Message Queuing Telemetry Transport (MQTT) message protocol requires a permanent connection.
  • a further advantageous embodiment of the invention is that the central cloud service sends a confirmation message to the gateway after receiving the verification message, the confirmation being able to include useful information (payload) from further cloud services.
  • Useful information can be, for example, commands, further queries for status (system status) or configuration data.
  • a simple “lean” heartbeat can include further “enriched” useful information (payload). The heartbeat mechanism can thus be flexibly, adaptively and scalably expanded or adapted to the useful information to be transmitted.
  • a further advantageous embodiment of the invention is that the confirmation message is stored in the communication component of the gateway and is made available for further components of the gateway or for applications on the gateway. This can take place, for example, via a suitable user (API) or programming interface.
  • API user
  • time intervals from the central cloud service can be defined and changed.
  • the interval for checking the operational readiness of the communication connection can advantageously be flexibly adapted to existing framework conditions or requirements.
  • the time intervals of the verification message (heartbeat) can be defined or changed by the central cloud service, advantageously depending on the requirements (for example with regard to the required reliability of the communication connection).
  • the time intervals between the verification message (heartbeat) can also be set or changed by the gateway or by applications on the gateway.
  • check message is sent when requested by the central cloud service.
  • the check message can be sent "on demand” (after request). This can be useful in emergencies, for example.
  • the communication connection is advantageously an outgoing connection with bidirectional logic.
  • the communication connection is set up physically from the gateway.
  • the communication link is physically unidirectional, but logically bidirectional.
  • Verification messages and the associated user data can be buffered, compressed or encrypted in the cloud, but also in the gateway.
  • FIG. 1 shows an exemplary gateway, set up to check the operational readiness of the communication connection between the gateway and a central cloud service
  • FIG. 2 shows an exemplary flow chart for a method for checking the operational readiness of a communication connection between a gateway and a central cloud service.
  • FIG. 1 shows an exemplary gateway G, set up to check the operational readiness of the communication connection KV1 between the gateway G and a central cloud service A that is "hosted" or provided in a cloud infrastructure CI.
  • the exemplary gateway G comprises a communication component B, which is set up for data communication with a central cloud service A, whereby to check the operational readiness of the communication connection KV1 between the gateway G and the central cloud service A a check message HBN (heartbeat message) from the Communication component B can be sent to the central cloud service A, and the verification message HBN can optionally include useful information NI1 (payload) from further components D, D ′, D ′′ of the gateway G.
  • NI1 useful information
  • the communication connection KV1 is advantageously a connection KV1 originating from the gateway G with a bidirectional logic.
  • the communication connection is set up physically from the gateway G.
  • the communication connection KV1 is physically unidirectional, but logically bidirectional.
  • the communication link KV1 can be, for example, a correspondingly suitable radio link, e.g. based on 3G, 4G or 5G networks.
  • the components B and A used for the communication link KV1 have corresponding buffers or stacks (e.g. communication stacks or FIN stacks) for carrying out the data traffic on the communication link KV1 or for storing or temporarily storing the useful information NI1, NI2.
  • buffers or stacks e.g. communication stacks or FIN stacks
  • the verification messages HBN and the associated optional user data NI1 can each in the cloud CI, but also be buffered, compressed or encrypted in the gateway G.
  • the central cloud service A advantageously sends a confirmation message Ack to the gateway G after receiving the verification message HBN, the confirmation message Ack optionally sending useful information NI2 (payload) from further cloud services C,
  • the further cloud services C, C ' may include.
  • the further cloud services C, C ' can access the central cloud service A through suitable communication connections KV2 or KV3.
  • the useful information NI1, NI2 can be, for example, commands, further queries for statuses (system states) or configuration data.
  • a simple “lean” heartbeat can further comprise “growing” useful information (payload).
  • the heartbeat mechanism can thus be expanded or adapted flexibly, adaptively and scalably to the useful information NI1, NI2 to be transmitted in each case.
  • the confirmation message Ack is advantageously stored in the communication component B of the gateway G and made available for further components D, D ′, D ′′ of the gateway G or for applications on the gateway G. This can be done, for example, via a suitable user (API) or programming interface and suitable communication connections KV4 or KV5.
  • the components or applications B, D, D ', D' 'of the gateway G are advantageously implemented as containers and are advantageously connected via a loopback network.
  • the implementation as a loopback network prevents, among other things, a compromise from outside.
  • an exemplary communication link KV6 to an exemplary customer network KN is established via the application D ′′.
  • the communication connection KV6 is advantageously a TCP / IP connection.
  • the customer network KN is, for example, a building automation network with a large number of electronic devices for monitoring and controlling the conditions in a building, in particular for security, fire and flood protection, lighting, heating, ventilation and air conditioning (HVAC).
  • the time intervals from the central cloud service A can advantageously be defined and changed.
  • the interval of checking the operational readiness of the communication link KV1 can advantageously be flexibly adapted to the existing framework conditions or requirements.
  • the time intervals of the check message HBN can be set or changed by the central cloud service A, advantageously depending on the requirements (e.g. with regard to the required reliability of the communication link KV1).
  • the time intervals of the check message HBN can, however, also be defined or changed by the gateway G or by applications D, D ', D' 'on the gateway G.
  • the check message HBN (heartbeat) is sent at the request of the central cloud service A.
  • the check message HBN (heartbeat) can be sent "on demand" (upon request). This can be useful in emergencies, for example.
  • Communication component B is advantageously set up, the check message HBN (heartbeat) on request of the central cloud service A to send the. This “heatbeat on demand” is particularly useful in emergency situations.
  • the useful information NI1, NI2 can be an event and / or a change in value and / or a change in status in the gateway G or in the cloud applications or cloud services C, C '.
  • the useful information NI1, NI2 is advantageously provided by a corresponding application interface (API) for cloud-based applications.
  • API application interface
  • the communication component B of the gateway G is advantageously set up to receive an acknowledgment Ack from the central cloud service A in response to a sent verification message HBN.
  • the communication component B is advantageously set up to send the check message HBN (heartbeat) periodically to the central cloud service A at definable time intervals.
  • the gateway G is advantageously an edge device (edge device computer, edge device, edge gateway).
  • the gateway can also be a correspondingly set up and configured “general purpose” computer (all-purpose computer) with processor, memory, input / output means, communication means commercially available computers with appropriately set up software.
  • FIG. 2 shows an exemplary flow chart for a method for checking the operational readiness of a communication connection between a gateway and a central cloud service
  • VS1 where a communication component of the gateway sends a check message (heartbeat) to the central cloud service at definable time intervals periodically or on request, and
  • the method does not require a standing communication link between the gateway and the central cloud service or the cloud infrastructure that provides or hosts (implemented) the central cloud service.
  • the communication connection can therefore also be implemented via a 3G or 4G network, for example.
  • a 5G network is not absolutely necessary to carry out the procedure.
  • the method can be used or optimized in particular for mobile data usage, so that as little traffic as possible occurs on the communication link.
  • the central cloud service After receiving the verification message, the central cloud service advantageously sends a confirmation message to the gateway, the confirmation being able to include useful information (payload) from other cloud services.
  • useful information can be, for example, commands, further queries for status (system status) or configuration data.
  • a simple “lean” heartbeat can contain “growing” useful information (payload). The heartbeat mechanism can thus be expanded or adapted flexibly, adaptively and scalably to the useful information to be transmitted.
  • the confirmation message is advantageously stored in the communication component of the gateway and made available for further components of the gateway.
  • the time intervals from the central cloud service can advantageously be defined and changed.
  • the check message (heartbeat) is advantageously sent on request (i.e. on demand) from the central cloud service.
  • the gateway is advantageously an edge device (edge device computer, edge device, edge gateway).
  • the gateway can also be an appropriately set up and configured "general purpose" computer with processor, memory, input / output means, communication means.
  • the gateway and the corresponding method can thus be implemented using an appropriately set up commercially available computer and an appropriately set up cloud infrastructure with appropriately set up software.
  • a gateway represents a component with the appropriate hardware and software in order to connect two systems or networks with one another in terms of data.
  • the gateway can also be a router with the appropriate functionality.
  • Exemplary scenario (use case) method (in connection with FIG. 1): a.
  • a central component on the device (B) periodically sends a message with status information to a central cloud service (A) and expects a confirmation.
  • the device component (B) will make messages available in the confirmation buffer via an interface (API, programming interface) for the device components (D, D ').
  • API programming interface
  • a component (D) or (D ') can thus pick up the messages locally without having to poll a cloud service cyclically.
  • the method according to the invention and the gateway according to the invention offer the following advantages, among others:
  • the communication link to the cloud can also take place in a third or fourth generation mobile network
  • the contents of the data packets are supplemented adaptively as required.
  • the contents of the data packets are made available to the clients on the cloud and at the gateway for further processing - so every application can process the information it needs.
  • Method for checking the operational readiness of a communication connection between a gateway and a central cloud service with a communication component of the gateway sending a check message (heartbeat) to the central cloud service periodically or on request at definable time intervals , wherein the verification message can include useful information (payload) from further components of the gateway.
  • Gateway comprising a communication component which is set up for data communication with a central cloud service, with a check message (heartbeat) from the communication component to check the operational readiness of the communication connection between the gateway and the central cloud service the central cloud service can be sent, wherein the verification message can include useful information (payload) from further components of the gateway.
  • KV1 - KV6 communication link HBN heartbeat message NI1, NI2 useful information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Verfahren, zur Überprüfung der Betriebsbereitschaft einer Kommunikationsverbindung zwischen einem Gateway und einem zentralen Cloud-Dienst, wobei von einer Kommunikationskomponente des Gateways in definierbaren Zeitabständen periodisch oder auf Anfrage eine Überprüfungsnachricht (Heartbeat) an den zentralen Cloud-Dienst gesendet wird, wobei die Überprüfungsnachricht Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann. Gateway, umfassend eine Kommunikationskomponente, welche eingerichtet ist für eine Datenkommunikation mit einem zentralen Cloud-Dienst, wobei zur Überprüfung der Betriebsbereitschaft der Kommunikationsverbindung zwischen dem Gateway und dem zentralen Cloud-Dienst eine Überprüfungsnachricht (Heartbeat) von der Kommunikationskomponente an den zentralen Cloud-Dienst sendbar ist, wobei die Überprüfungsnachricht Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann.

Description

Effizienter Heartbeat-Mechanismus für Cloud-Anwendungen
Die Erfindung betrifft ein Verfahren zur Überprüfung der Be- triebsbereitschaft einer Kommunikationsverbindung zwischen ei- nem Gateway und einem zentralen Cloud-Dienst . Weiterhin be- trifft die Erfindung ein Gateway, eingerichtet zur Durchfüh- rung des Verfahrens.
In der Informationstechnologie (IT) erfolgt der Datenaustausch zwischen Netzwerken, insbesondere bei Netzwerken unterschied- lichen Typs, üblicherweise über entsprechend eingerichtete Ga- teways. Gateways werden auch verwendet, um Netzwerke (z.B. Netzwerke bei entsprechenden Kunden) mit einer Cloud- Infrastruktur zu verbinden. Dadurch können z.B. Netzwerkknoten auf Dienste (Services) von Cloud-Applikationen zugreifen.
Um zu verifizieren, ob ein Gateway noch eine funktionierende Verbindung zur Cloud hat, wird periodisch über die Verbindung eine Nachricht gesendet, um die Betriebsbereitschaft der Kom- munikationsverbindung zu überprüfen (Heartbeat-Funktion) .
Nachrichtenprotokolle wie MQTT (Message Queuing Telemetry Transport) benötigen eine permanent bestehende Verbindung, was aber zu einem kontinuierlichen Datenverkehr und zu hohem Traf- fic führt.
Es ist daher die Aufgabe der vorliegenden Erfindung, einen ef- fizienten Mechanismus zur Überprüfung der Betriebsbereitschaft (Heartbeat) zwischen einem Netzwerkgateway und einer Cloud- Infrastruktur bereitzustellen.
Die Aufgabe wird gelöst durch ein Gateway, umfassend eine Kom- munikationskomponente, welche eingerichtet ist für eine Daten- kommunikation mit einem zentralen Cloud-Dienst, wobei zur Überprüfung der Betriebsbereitschaft der Kommunikationsverbin- dung zwischen dem Gateway und dem zentralen Cloud-Dienst eine Überprüfungsnachricht (Heartbeat) von der Kommunikationskompo- nente an den zentralen Cloud-Dienst sendbar ist, wobei die Überprüfungsnachricht Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann. Wenn Nutzinformation (payload) von weiteren Komponenten des Gateways vorhanden ist bzw. bereitsteht, wird diese Nutzinformation zusammen mit der Überprüfungsnachricht übertragen. Mit Vorteil weist die Über- prüfungsnachricht ein entsprechendes Datenformat oder ein Da- tenprotokoll auf, um die Nutzinformation zu übertragen. Beim Gateway handelt es sich mit Vorteil um ein Edge-Gerät (Edge- Gerätecomputer, Edge Device, Edge Gateway) . Im Prinzip kann es sich beim Gateway aber auch um einen entsprechend eingerichte- ten und konfigurierten „General Purpose"-Computer (Allzweck- computer) mit Prozessor, Speicher, Ein-/Ausgabemittel , Kommu- nikationsmittel handeln. Das erfindungsgemässe Gateway ermög- licht einen adaptiven und nach Kommunikationsbedarf skalierba- ren Heartbeat-Mechanismus für Cloud-Anwendungen . Durch den He- artbeat-Mechanismus kann nicht nur die Betriebsbereitschaft einer Kommunikationsverbindung festgestellt werden, sondern bei Bedarf können durch den Heartbeat-Mechanismus auch Nutzda- ten transportiert werden. Dies reduziert u.a. den Traffic auf der Kommunikationsverbindung. Mit Vorteil ist das Gateway ein Knoten, bzw. ein Gerät eines Netzwerks, z.B. eines Netzwerkes von Geräten (z.B. IoT-Geräten) zur Gebäudeautomatisierung. Mit Vorteil stellt das Gateway eine Kommunikationsverbindung (ent- sprechende Hardware und Software) des Netzwerks zum Internet oder zu einer Cloud-Infrastruktur (z.B. zum Abrufen oder Akti- vieren von Cloud-Diensten) bereit.
Eine erste vorteilhafte Ausgestaltung der Erfindung liegt da- rin, dass die Datenkommunikation zum zentralen Cloud-Dienst durch die Kommunikationskomponente des Gateways hergestellt wird. Dadurch, dass die Datenverbindung zur Cloud aus dem Ga- teway (bzw. vom Gateway) initialisiert wird, wird die Sicher- heit der Datenverbindung erhöht.
Mit Vorteil handelt es sich bei der Kommunikationsverbindung um eine ausgehende Verbindung mit bidirektionaler Logik. Die Kommunikationsverbindung wird vom Gateway aus physikalisch eingerichtet. Die Kommunikationsverbindung ist physikalisch unidirektional , aber logisch bidirektional.
Überprüfungsnachrichten und die dazu gehörigen Nutzdaten kön- nen jeweils in der Cloud, aber auch im Gateway gepuffert, kom- primiert, oder verschlüsselt werden.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass es sich bei der Nutzinformation um ein Ereignis und/oder eine Wertänderung und/oder eine Zustandsänderung im Gateway handelt. Bei der Nutzinformation kann es sich somit um unterschiedliche Datentypen und Werte handeln.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Nutzinformation durch eine entsprechende An- wendungsschnittstelle (API) bzw. Programmierschnittstelle für Cloud basierte Anwendungen bereitgestellt wird. Dienste und Anwendungen in der Cloud können durch die Anwendungsschnitt- stelle (API) bzw. Programmierschnittstelle auf die Nutzinfor- mationen zugreifen und diese für die Bereitstellung ihrer Dienste und Anwendungen verwenden.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Kommunikationskomponente eingerichtet ist, als Antwort auf eine gesendete Überprüfungsnachricht eine Bestäti- gung vom zentralen Cloud-Dienst zu empfangen. Durch die Bestä- tigung erkennt das Gateway, dass die Kommunikationsverbindung betriebsbereit ist. Optional umfasst die Bestätigung Nutzin- formation (payload) von Cloud-Diensten oder Cloud-Anwendungen für das Gateway bzw. für Komponenten des Gateways.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Kommunikationskomponente eingerichtet ist, die Überprüfungsnachricht (Heartbeat) periodisch in definierbaren Zeitabständen an den zentralen Cloud-Dienst zu senden. Das In- tervall der Überprüfung der Betriebsbereitschaft der Kommuni- kationsverbindung kann somit verändert werden. Mit Vorteil ist das Intervall der Überprüfung der Betriebsbereitschaft der Kommunikationsverbindung flexibel an vorhandene Rahmenbedin- gungen oder Anforderungen anpassbar. Die Zeitabstände der Überprüfungsnachricht (Heartbeat) können vom Gateway bzw. von Applikationen auf dem Gateway festgelegt bzw. verändert wer- den. Die Zeitabstände der Überprüfungsnachricht (Heartbeat) können aber auch von Cloud-Diensten festgelegt bzw. verändert werden, mit Vorteil in Abhängigkeit von vorliegenden Anforde- rungen (z.B. hinsichtlich einer erforderlichen Zuverlässigkeit der Kommunikationsverbindung) .
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Kommunikationskomponente eingerichtet ist, die Überprüfungsnachricht (Heartbeat) auf Anforderung des zentra- len Cloud-Dienstes zu senden. Somit kann die Überprüfungsnach- richt (Heartbeat) „on demand" (nach Aufforderung) gesendet werden. Dies kann z.B. bei Notfällen sinnvoll sein. Mit Vor- teil erfolgt die Implementierung durch Container-Technologie. Unter Container-Technologie versteht man eine Softwareumge- bung, in der der gesamte Code mit allen Abhängigkeiten gebün- delt ist und einfach auf verschiedenen CPU-Plattformen betrie- ben werden kann. Diese Softwareumgebung beinhaltet alle Teile für den Betrieb einer Applikation: Betriebssystem, Code, Run- time, System Tools, Bibliotheken und Einstellungen. Diese Softwareumgebung isoliert die SW-Applikation komplett von der Umgebung und gewährleitest so hohe Sicherheit betreffend Iso- lierung dieses Prozesses. Ein alternativer Begriff für Contai- ner-Technologie ist die Bezeichnung „Sandbox". Ein Vorteil der Container-Technologie ist beim Update auf eine neuere Version: Ein Container kann unabhängig und gesamthaft aktualisiert wer- den, ohne dabei andere Container, die auf der gleichen CPU in Betrieb sind, zu stören. Mit Vorteil erfolgt eine Implementie- rung in einem Container-Netzwerk, umfassend Container sowohl im Gerät (z.B. Edge-Device) , als auch in der Cloud.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt in einem Computer mit Speicher, Prozessor und Kommunikationsmit- tel, eingerichtet ein erfindungsgemässes Gateway zu realisie- ren. Beim Computer kann es sich um einen entsprechend einge- richteten und konfigurierten Allzweckcomputer (General Purpose Computer) handeln, z.B. um einen Desktop-Computer, Laptop, Edge-Gerät (Edge Device, Edge-Gerätecomputer, z.B. eine Set- Top-Box) handeln. Prinzipiell kann jeder handelsübliche Compu- ter konfiguriert werden, um als erfindungsgemässes Gateway zu agieren.
Durch das erfindungsgemässe Gateway erfolgt insbesondere eine Anbindung eines Gebäudeautomationsnetzwerkes an das Internet. Im Gebäudeautomationsnetzwerk sind eine Vielzahl von elektro- nischen Vorrichtungen zur Überwachung und Steuerung der Bedin- gungen in einem Gebäude vorgesehen, insbesondere für Sicher- heit, Brand- und Hochwasserschutz, Beleuchtung, Heizung, Lüf- tung und Klimatisierung (HVAC) .
Mit Vorteil umfasst das erfindungsgemässe Gateway eine lokale Netzwerkschnittstelle, die konfiguriert ist, um das Gateway mit dem Gebäudeautomatisierungsnetzwerk zum Kommunizieren mit der Vielzahl von elektronischen Vorrichtungen zu verbinden, eine Weitverkehrsnetzwerkschnittstelle, die konfiguriert ist, um das Gateway mit dem Internet zu verbinden, eine Host- Netzwerkeinheit, die konfiguriert ist, um ein Host-Netzwerk bereitzustellen, auf dem mindestens ein lokaler Dienst, der der Überwachung und Steuerung mindestens einer der Bedingungen im Gebäude entspricht, läuft, eine Containernetzwerkeinheit, die konfiguriert ist, um ein Containernetzwerk für mindestens einen Remote-Service (remote/entfernter Dienst) bereitzustel- len, insbesondere einen Cloud-Computing-Dienst, der von einer Endpunktvorrichtung oder einer Cloud im Internet für mindes- tens eine der elektronischen Vorrichtungen bereitgestellt wird, eine Loopback-Netzwerkeinheit, die konfiguriert ist, um ein Loopback-Netzwerk bereitzustellen, das das Host-Netzwerk und das Containernetzwerk miteinander verbindet, und eine Aus- wahleinheit, die konfiguriert ist, um einen Verbindungsmodus des Gateways auszuwählen, indem entweder mindestens eine der elektronischen Vorrichtungen über die lokale Netzwerkschnitt- stelle mit dem Internet verbunden wird oder die mindestens ei- ne der elektronischen Vorrichtungen über die Wide Area Net- work-Schnittstelle mit dem Internet verbunden wird.
Die Aufgabe wird weiterhin gelöst durch ein Verfahren, zur Überprüfung der Betriebsbereitschaft einer Kommunikationsver- bindung zwischen einem Gateway und einem zentralen Cloud- Dienst, wobei von einer Kommunikationskomponente des Gateways in definierbaren Zeitabständen periodisch oder auf Anfrage ei- ne Überprüfungsnachricht (Heartbeat) an den zentralen Cloud- Dienst gesendet wird, wobei die Überprüfungsnachricht Nutzin- formation (payload) von weiteren Komponenten des Gateways um- fassen kann. Für das Verfahren ist keine stehende Kommunikati- onsverbindung zwischen dem Gateway und dem zentralen Cloud- Dienst bzw. der Cloud-Infrastruktur, die den zentralen Cloud- Dienst bereitstellt bzw. hosted (implementiert) nötig. Die Kommunikationsverbindung kann somit z.B. auch durch ein 3G o- der 4G Netz realisiert werden. 5G ist nicht unbedingt erfor- derlich. Das Verfahren ist insbesondere für eine mobile Daten- nutzung einsetzbar bzw. optimiert, damit möglichst wenig Traf- fic auf der Kommunikationsverbindung anfällt.
Das Nachrichtenprotokoll Message Queuing Telemetry Transport (MQTT) verlangt dagegen eine permanente Verbindung.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass der zentrale Cloud-Dienst nach Empfang der Über- prüfungsnachricht eine Bestätigungsnachricht an das Gateway sendet, wobei die Bestätigung Nutzinformation (payload) von weiteren Cloud-Diensten umfassen kann. Nutzinformationen kön- nen z.B. Kommandos, weitere Abfragen für Stati (Anlagenzustän- de) oder Konfigurationsdaten sein. Ein einfacher „schlanker,, Heartbeat kann weiter „angereicherte" Nutzinformation (pay- load) umfassen) . Der Heartbeat-Mechanismus kann somit flexi- bel, adaptiv, und skalierbar an jeweils zu übertragende Nutz- informationen erweitert bzw. angepasst werden.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Bestätigungsnachricht in der Kommunikations- komponente des Gateways gespeichert wird und für weitere Kom- ponenten des Gateways bzw. für Applikationen auf dem Gateway bereitgestellt wird. Dies kann z.B. über eine geeignete Anwen- der- (API) bzw. Programmierschnittstelle erfolgen.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Zeitabstände vom zentralen Cloud-Dienst defi- nierbar und änderbar sind. Mit Vorteil ist das Intervall der Überprüfung der Betriebsbereitschaft der Kommunikationsverbin- dung flexibel an vorhandene Rahmenbedingungen oder Anforderun- gen anpassbar. Die Zeitabstände der Überprüfungsnachricht (He- artbeat) können vom zentralen Cloud-Dienst festgelegt bzw. verändert werden, mit Vorteil in Abhängigkeit von vorliegenden Anforderungen (z.B. hinsichtlich einer erforderlichen Zuver- lässigkeit der Kommunikationsverbindung) . Die Zeitabstände der Überprüfungsnachricht (Heartbeat) können aber auch vom Gateway bzw. von Applikationen auf dem Gateway festgelegt bzw. verändert werden.
Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt darin, dass die Überprüfungsnachricht (Heartbeat) auf Anforde- rung des zentralen Cloud-Dienstes gesendet wird. Somit kann die Überprüfungsnachricht (Heartbeat) „on demand" (nach Auf- forderung) gesendet werden. Dies kann z.B. bei Notfällen sinn- voll sein.
Mit Vorteil handelt es sich bei der Kommunikationsverbindung um eine ausgehende Verbindung mit bidirektionaler Logik. Die Kommunikationsverbindung wird vom Gateway aus physikalisch eingerichtet. Die Kommunikationsverbindung ist physikalisch unidirektional , aber logisch bidirektional.
Überprüfungsnachrichten und die dazu gehörigen Nutzdaten kön- nen jeweils in der Cloud, aber auch im Gateway gepuffert, kom- primiert, oder verschlüsselt werden.
Die Erfindung sowie vorteilhafte Ausführungen der vorliegenden Erfindung werden am Beispiel der nachfolgenden Figur erläu- tert. Dabei zeigt:
FIG 1 ein beispielhaftes Gateway, eingerichtet zur Über- prüfung der Betriebsbereitschaft der Kommunikations- verbindung zwischen dem Gateway und einem zentralen Cloud-Dienst, und
FIG 2 ein beispielhaftes Flussdiagramm für ein Verfahren zur Überprüfung der Betriebsbereitschaft einer Kom- munikationsverbindung zwischen einem Gateway und ei- nem zentralen Cloud-Dienst. Figur 1 zeigt ein beispielhaftes Gateway G, eingerichtet zur Überprüfung der Betriebsbereitschaft der Kommunikationsverbin- dung KV1 zwischen dem Gateway G und einem zentralen Cloud- Dienst A, der in einer Cloud-Infrastruktur CI „gehosted" bzw. bereitgestellt wird. Das beispielhafte Gateway G, umfasst eine Kommunikationskomponente B, welche eingerichtet ist für eine Datenkommunikation mit einem zentralen Cloud-Dienst A, wobei zur Überprüfung der Betriebsbereitschaft der Kommunikations- verbindung KV1 zwischen dem Gateway G und dem zentralen Cloud- Dienst A eine Überprüfungsnachricht HBN (Heartbeat-Nachricht ) von der Kommunikationskomponente B an den zentralen Cloud- Dienst A sendbar ist, und wobei die Überprüfungsnachricht HBN optional Nutzinformation NI1 (Payload) von weiteren Komponen- ten D, D', D'' des Gateways G umfassen kann.
Mit Vorteil handelt es sich bei der Kommunikationsverbindung KV1 um eine vom Gateway G ausgehende Verbindung KV1 mit bidi- rektionaler Logik. Die Kommunikationsverbindung wird vom Gate- way G aus physikalisch eingerichtet. Die Kommunikationsverbin- dung KV1 ist physikalisch unidirektional , aber logisch bidi- rektional. Bei der Kommunikationsverbindung KV1 kann es sich z.B. um eine entsprechend geeignete Funkverbindung handeln, z.B. basierend auf 3G-, 4G- oder 5G-Netzen.
Die für die Kommunikationsverbindung KV1 verwendeten Komponen- ten B bzw. A verfügen über entsprechende Puffer oder Stacks (z.B. Kommunikations-Stacks oder FIN Stacks) zur Durchführung des Datenverkehrs auf der Kommunikationsverbindung KV1 bzw. zum Speichern oder Zwischenspeichern der Nutzinformationen NI1, NI2.
Die Überprüfungsnachrichten HBN und die dazu gehörigen optio- nalen Nutzdaten NI1 können jeweils in der Cloud CI, aber auch im Gateway G gepuffert, komprimiert, oder verschlüsselt wer- den .
Mit Vorteil sendet der zentrale Cloud-Dienst A nach Empfang der Überprüfungsnachricht HBN eine Bestätigungsnachricht Ack an das Gateway G, wobei die Bestätigungsnachricht Ack optional Nutzinformation NI2 (payload) von weiteren Cloud-Diensten C,
C' umfassen kann. Die weiteren Cloud-Dienste C, C' können durch geeignete Kommunikationsverbindungen KV2 bzw. KV3 auf den zentralen Cloud-Dienst A zugreifen.
Die Nutzinformationen NI1, NI2 können z.B. Kommandos, weitere Abfragen für Stati (Anlagenzustände) oder Konfigurationsdaten sein. Ein einfacher „schlanker,, Heartbeat kann weiter „wach- sende,, Nutzinformation (payload) umfassen) . Der Heartbeat- Mechanismus kann somit flexibel, adaptiv, und skalierbar an jeweils zu übertragende Nutzinformationen NI1, NI2 erweitert bzw. angepasst werden.
Mit Vorteil wird die Bestätigungsnachricht Ack in der Kommuni- kationskomponente B des Gateways G gespeichert und für weitere Komponenten D, D', D'' des Gateways G bzw. für Applikationen auf dem Gateway G bereitgestellt. Dies kann z.B. über eine ge- eignete Anwender- (API) bzw. Programmierschnittstelle und ge- eignete Kommunikationsverbindungen KV4 bzw. KV5 erfolgen.
Mit Vorteil sind die Komponenten bzw. Applikationen B, D, D', D'' des Gateways G als Container realisiert und sind mit Vor- teil über ein Loopback-Netzwerk verbunden. Die Realisierung als Loopback-Netzwerk verhindert u.a. eine Kompromittierung von Aussen.
Durch die Verwendung von Container-Technologie im Gateway G wird eine Isolierung der Applikationen B, D', D'' erreicht wodurch eine Kompromittierung von Aussen (z.B. durch einen Ha- ckerangriff) vermieden wird.
In der Darstellung gemäss Figur 1 wird über die Applikation D'' eine exemplarische Kommunikationsverbindung KV6 zu einem beispielhaften Kundennetzwerk KN hergestellt. Bei der Kommuni- kationsverbindung KV6 handelt es sich mit Vorteil um eine TCP/ IP-Verbindung . Das Kundennetzwerk KN handelt es sich z.B. um ein Gebäudeautomationsnetzwerk mit einer Vielzahl von elektronischen Vorrichtungen zur Überwachung und Steuerung der Bedingungen in einem Gebäude, insbesondere für Sicherheit, Brand- und Hochwasserschutz, Beleuchtung, Heizung, Lüftung und Klimatisierung (HVAC) .
Mit Vorteil sind die Zeitabstände vom zentralen Cloud-Dienst A definierbar und veränderbar. Mit Vorteil ist das Intervall der Überprüfung der Betriebsbereitschaft der Kommunikationsverbin- dung KV1 flexibel an vorhandene Rahmenbedingungen oder Anfor- derungen anpassbar. Die Zeitabstände der Überprüfungsnachricht HBN (Heartbeat) können vom zentralen Cloud-Dienst A festgelegt bzw. verändert werden, mit Vorteil in Abhängigkeit von vorlie- genden Anforderungen (z.B. hinsichtlich einer erforderlichen Zuverlässigkeit der Kommunikationsverbindung KV1 ) .
Die Zeitabstände der Überprüfungsnachricht HBN (Heartbeat) können aber auch vom Gateway G bzw. von Applikationen D, D', D'' auf dem Gateway G festgelegt bzw. verändert werden.
Optional wird die Überprüfungsnachricht HBN (Heartbeat) auf Anforderung des zentralen Cloud-Dienstes A gesendet. Somit kann die Überprüfungsnachricht HBN (Heartbeat) „on demand" (nach Aufforderung) gesendet werden. Dies kann z.B. bei Not- fällen sinnvoll sein. Mit Vorteil ist die Kommunikationskompo- nente B eingerichtet, die Überprüfungsnachricht HBN (Heart- beat) auf Anforderung des zentralen Cloud-Dienstes A zu sen- den. Dieser «Heatbeat on demand» ist insbesondere bei Notfall- situationen sinnvoll.
Bei der Nutzinformation NI1, NI2 kann es sich um ein Ereignis und/oder eine Wertänderung und/oder eine Zustandsänderung im Gateway G oder in den Cloud-Anwendungen bzw. Cloud-Diensten C, C' handelt.
Mit Vorteil werden die Nutzinformationen NI1, NI2 durch eine entsprechende Anwendungsschnittstelle (API) für Cloud basierte Anwendungen bereitgestellt.
Mit Vorteil ist die Kommunikationskomponente B des Gateways G eingerichtet, als Antwort auf eine gesendete Überprüfungsnach- richt HBN eine Bestätigung Ack vom zentralen Cloud-Dienst A zu empfangen .
Mit Vorteil ist die Kommunikationskomponente B eingerichtet, die Überprüfungsnachricht HBN (Heartbeat) periodisch in defi- nierbaren Zeitabständen an den zentralen Cloud-Dienst A zu senden .
Beim Gateway G handelt es sich mit Vorteil um ein Edge-Gerät (Edge-Gerätecomputer, Edge Device, Edge Gateway) . Im Prinzip kann es sich beim Gateway aber auch um einen entsprechend ein- gerichteten und konfigurierten „General Purpose"-Computer (Allzweckcomputer) mit Prozessor, Speicher, Ein-/Ausgabe- mittel, Kommunikationsmittel handeln. Das Gateway G kann somit durch einen entsprechend eingerichteten handelsüblichen Compu- ter mit entsprechend eingerichteter Software realisiert wer- den . Figur 2 zeigt ein beispielhaftes Flussdiagramm für ein Verfah- ren zur Überprüfung der Betriebsbereitschaft einer Kommunika- tionsverbindung zwischen einem Gateway und einem zentralen Cloud-Dienst,
(VS1) wobei von einer Kommunikationskomponente des Gate- ways in definierbaren Zeitabständen periodisch oder auf Anfra- ge eine Überprüfungsnachricht (Heartbeat) an den zentralen Cloud-Dienst gesendet wird, und
(VS2) wobei die Überprüfungsnachricht Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann. Für das Verfahren ist keine stehende Kommunikationsverbindung zwischen dem Gateway und dem zentralen Cloud-Dienst bzw. der Cloud-Infrastruktur, die den zentralen Cloud-Dienst bereit- stellt bzw. hosted (implementiert) nötig. Die Kommunikations- verbindung kann somit z.B. auch durch ein 3G- oder 4G-Netz re- alisiert werden. Ein 5G-Netz ist nicht unbedingt erforderlich zur Durchführung des Verfahrens. Das Verfahren ist insbesonde- re für eine mobile Datennutzung einsetzbar bzw. optimiert, da- mit möglichst wenig Traffic auf der Kommunikationsverbindung anfällt.
Mit Vorteil sendet der zentrale Cloud-Dienst nach Empfang der Überprüfungsnachricht eine Bestätigungsnachricht an das Gate- way, wobei die Bestätigung Nutzinformation (payload) von wei- teren Cloud-Diensten umfassen kann. Nutzinformationen können z.B. Kommandos, weitere Abfragen für Stati (Anlagenzustände) oder Konfigurationsdaten sein. Ein einfacher „schlanker,, He- artbeat kann weiter „wachsende,, Nutzinformation (payload) um- fassen) . Der Heartbeat-Mechanismus kann somit flexibel, adap- tiv, und skalierbar an jeweils zu übertragende Nutzinformatio- nen erweitert bzw. angepasst werden.
Mit Vorteil wird die Bestätigungsnachricht in der Kommunikati- onskomponente des Gateways gespeichert und für weitere Kompo- nenten des Gateways bereitgestellt. Mit Vorteil sind die Zeitabstände vom zentralen Cloud-Dienst definierbar und änderbar sind.
Mit Vorteil wird die Überprüfungsnachricht (Heartbeat) auf An- forderung (d.h. on demand) des zentralen Cloud-Dienstes gesen- det .
Beim Gateway handelt es sich mit Vorteil um ein Edge-Gerät (Edge-Gerätecomputer, Edge Device, Edge Gateway) . Im Prinzip kann es sich beim Gateway aber auch um einen entsprechend ein- gerichteten und konfigurierten „General Purpose"-Computer (Allzweckcomputer) mit Prozessor, Speicher, Ein-/Ausgabe- mittel, Kommunikationsmittel handeln. Das Gateway und das ent- sprechende Verfahren kann somit durch einen entsprechend ein- gerichteten handelsüblichen Computer und einer entsprechend eingerichteter Cloud-Infrastruktur mit entsprechend eingerich- teter Software realisiert werden.
Ein Gateway, wie es in dieser Patentanmeldung verwendet wird, stellt eine Komponente dar, mit entsprechender Hardware und Software, um zwei Systeme bzw. Netzwerke datentechnisch mitei- nander zu verbinden. Beim Gateway kann es sich auch um einen Router mit entsprechender Funktionalität handeln.
Beispielhaftes Szenario (use case, Anwendungsfall) erfindungs- gemässe Verfahren (in Verbindung mit Figur 1) : a. Eine zentrale Komponente auf dem Gerät (B) sendet perio- disch eine Nachricht mit Status Informationen zu einem zentralen Cloud-Service (A) und erwartet eine Bestäti- gung .
b. Weitere Cloud-Services (C, C ' ) schicken ihre Nachrichten die zu den Geräte-Komponenten geschickt werden sollen zu (A) wo diese zwischengespeichert werden. Wenn ausgehende Nachrichten vorhanden sind, werden diese Information in der Bestätigung (Ack) zu (B) von (A) hinzugefügt.
c. Die Geräte-Komponente (B) wird Nachrichten in der Bestä- tigen Zwischenspeichern über eine Schnittstelle (API, Programmierschnittstelle) für die Geräte-Komponenten (D, D') zu Verfügung stellen. Eine Komponente (D) bzw. (D') kann somit die Nachrichten lokal abholen, ohne zyklisch einen Cloud-Service abfragen zu müssen.
d. Falls im Gerät (Gateway G) ein Ereignis ansteht / Wertän- derung / Zustandsänderung wird dieses Ereignis in der Nachricht von (B) verpack und an (A) versendet.
e. Der Inhalt dieser Nachricht wird nun als API für weitere Cloud basierte Anwendungen bereitgestellt, auch können verschiedene Anwendungen notifiziert werden.
f. (A) muss nicht verändert werden, wenn neue Cloud-Services Nachrichten an das Gerät (Gateway G) schicken möchten. g. Die zentralen Komponenten (A) und (B) agieren nur als
Vermittler. Diese Komponenten sind agnostisch gegenüber den Services (C, C ' ) in der Cloud und den Komponenten (D, D') auf dem Gerät (Gateway G) . Es können also deshalb dy- namisch (adaptiv) weitere Services und Komponenten hinzu- gefügt werden, ohne dass (A) oder (B) angepasst werden muss .
Das erfindungsgemässe Verfahren, sowie das erfindungsgemässe Gateway bieten u.a. folgende Vorteile:
- Geringe Verbindungskosten und optimierter Datenverkehr (in Bezug auf Anzahl der Verbindungen und zu übertragen- der Datenmenge) vom Gateway zur Cloud. - Keine permanente Verbindung zur Cloud erforderlich, wodurch wenig Datenverkehr anfällt (Traffic wird redu- ziert).
- Die Kommunikationsverbindung zur Cloud kann auch in einem Mobilnetz der dritten oder vierten Generation erfolgen
(3G / 4G) . 5 G ist nicht erforderlich.
- Reduzierung des Datenverkehrs und der dadurch entstehen- den Kosten.
Inhalte der Datenpakete werden adaptiv nach Bedarf er- gänzt.
Inhalte der Datenpakete werden auf der Cloud und am Gate- way den Clients zur weiteren Verarbeitung bereitgestellt - so kann jede Applikation die Informationen verarbeiten, die sie benötigt.
- Adaptierbarer und skalierbarer Heartbeat-Mechanismus für Cloud-Anwendungen.
Verfahren, zur Überprüfung der Betriebsbereitschaft einer Kom- munikationsverbindung zwischen einem Gateway und einem zentra- len Cloud-Dienst, wobei von einer Kommunikationskomponente des Gateways in definierbaren Zeitabständen periodisch oder auf Anfrage eine Überprüfungsnachricht (Heartbeat) an den zentra- len Cloud-Dienst gesendet wird, wobei die Überprüfungsnach- richt Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann. Gateway, umfassend eine Kommunikati- onskomponente, welche eingerichtet ist für eine Datenkommuni- kation mit einem zentralen Cloud-Dienst, wobei zur Überprüfung der Betriebsbereitschaft der Kommunikationsverbindung zwischen dem Gateway und dem zentralen Cloud-Dienst eine Überprüfungs- nachricht (Heartbeat) von der Kommunikationskomponente an den zentralen Cloud-Dienst sendbar ist, wobei die Überprüfungs- nachricht Nutzinformation (payload) von weiteren Komponenten des Gateways umfassen kann. Bezugszeichen
G Gateway
CI Cloud-Infrastruktur
A, C, C' Dienste
B, D, D', D" Applikation
VS1, VS2 Verfahrensschritt
KV1 - KV6 Kommunikationsverbindung HBN Heartbeat-Nachricht NI1, NI2 NutzInformation
Ack Bestätigungsnachricht
KN Kundennetzwerk

Claims

Patentansprüche
1. Gateway (G) , umfassend eine Kommunikationskomponente (B) , welche eingerichtet ist für eine Datenkommunikation (KV1) mit einem zentralen Cloud-Dienst (A) , wobei zur Überprüfung der Betriebsbereitschaft der Kommunikationsverbindung (KV1) zwi- schen dem Gateway (G) und dem zentralen Cloud-Dienst (A) eine Überprüfungsnachricht (HBN) von der Kommunikationskomponente (B) an den zentralen Cloud-Dienst (A) sendbar ist, wobei die Überprüfungsnachricht (HBN) Nutzinformation (NI) von weiteren Komponenten (D, D') des Gateways (G) umfassen kann.
2. Gateway (G) nach Anspruch 1, wobei die Datenkommunikation zum zentralen Cloud-Dienst (A) durch die Kommunikationskompo- nente (B) hergestellt wird.
3. Gateway (G) nach einem der vorstehenden Ansprüche, wobei es sich bei der Nutzinformation (NI1) um ein Ereignis und/oder eine Wertänderung und/oder eine Zustandsänderung im Gateway (G) handelt.
4. Gateway (G) nach Anspruch 3, wobei die Nutzinformation durch eine entsprechende Anwendungsschnittstelle (API) für Cloud basierte Anwendungen bereitgestellt wird.
5. Gateway (G) nach einem der vorstehenden Ansprüche, wobei die Kommunikationskomponente (B) eingerichtet ist, als Antwort auf eine gesendete Überprüfungsnachricht (HBN) eine Bestäti- gung (Ack) vom zentralen Cloud-Dienst (A) zu empfangen.
6. Gateway (G) nach einem der vorstehenden Ansprüche, wobei die Kommunikationskomponente (B) eingerichtet ist, die Über- prüfungsnachricht (HBN) periodisch in definierbaren Zeitab- ständen an den zentralen Cloud-Dienst (A) zu senden.
7. Gateway (G) nach einem der vorstehenden Ansprüche, wobei die Kommunikationskomponente (B) eingerichtet ist, die Über- prüfungsnachricht (HBN) auf Anforderung des zentralen Cloud- Dienstes (A) zu senden.
8. Computer mit Speicher, Prozessor und Kommunikationsmittel, eingerichtet ein Gateway (G) nach einem der vorstehenden An- sprüche zu realisieren.
9. Verfahren, zur Überprüfung der Betriebsbereitschaft einer Kommunikationsverbindung (KV1) zwischen einem Gateway (G) und einem zentralen Cloud-Dienst (A) , wobei von einer Kommunikati- onskomponente (B) des Gateways (G) in definierbaren Zeitab- ständen periodisch oder auf Anfrage eine Überprüfungsnachricht (HBN) an den zentralen Cloud-Dienst (A) gesendet wird, wobei die Überprüfungsnachricht (HBN) Nutzinformation (NI1) von wei- teren Komponenten (D, D') des Gateways (G) umfassen kann.
10. Verfahren nach Anspruch 9, wobei der zentrale Cloud-Dienst (A) nach Empfang der Überprüfungsnachricht (HBN) eine Bestäti- gungsnachricht (Ack) an das Gateway (G) sendet, wobei die Be- stätigungsnachricht (Ack) Nutzinformation (NI2) von weiteren Cloud-Diensten (C, C ' ) umfassen kann.
11. Verfahren nach Anspruch 9 oder 10, wobei die Bestätigungs- nachricht (Ack) in der Kommunikationskomponente (B) des Gate- ways (G) gespeichert wird und für weitere Komponenten (D, D') des Gateways (G) bereitgestellt wird.
12. Verfahren nach einem der Ansprüche 9 bis 11, wobei die Zeitabstände vom zentralen Cloud-Dienst (A) definierbar und änderbar sind.
13. Verfahren nach einem der Ansprüche 9 bis 12, wobei die Überprüfungsnachricht (HBN) auf Anforderung des zentralen Cloud-Dienstes (A) gesendet wird.
EP20746913.1A 2019-07-31 2020-07-17 Effizienter heartbeat-mechanismus für cloud-anwendungen Pending EP4005160A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102019211395.8A DE102019211395B4 (de) 2019-07-31 2019-07-31 Effizienter Heartbeat-Mechanismus für Cloud-Anwendungen
PCT/EP2020/070318 WO2021018636A1 (de) 2019-07-31 2020-07-17 Effizienter heartbeat-mechanismus für cloud-anwendungen

Publications (1)

Publication Number Publication Date
EP4005160A1 true EP4005160A1 (de) 2022-06-01

Family

ID=71842645

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20746913.1A Pending EP4005160A1 (de) 2019-07-31 2020-07-17 Effizienter heartbeat-mechanismus für cloud-anwendungen

Country Status (5)

Country Link
US (1) US20220321444A1 (de)
EP (1) EP4005160A1 (de)
CN (1) CN114145000A (de)
DE (1) DE102019211395B4 (de)
WO (1) WO2021018636A1 (de)

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2363548A (en) * 2000-06-15 2001-12-19 Int Computers Ltd Computer systems, in particular virtual private networks
EP1394985A1 (de) * 2002-08-28 2004-03-03 Siemens Aktiengesellschaft Testverfahren für Nachrichtenpfade in Kommunikationsnetzen sowie Netzelement
DE10339279A1 (de) * 2003-08-26 2005-03-31 Siemens Ag Verfahren zur Steuerung von hochverfügbaren Teilnehmerzugangsnetzen durch eine paketbasierte Vermittlungsstelle
US8042147B2 (en) * 2005-10-05 2011-10-18 Bryes Security Network security appliance
US20070214273A1 (en) * 2006-03-10 2007-09-13 Pronto Networks Across firewall communication system and method
US7907533B2 (en) * 2007-11-28 2011-03-15 Tekelec Methods, systems, and computer program products for performing IP link proving using heartbeat messages
US20140310243A1 (en) * 2010-08-16 2014-10-16 Mr. Steven James McGee Heart beacon cycle
US10084678B2 (en) * 2016-04-19 2018-09-25 International Business Machines Corporation Managing connections for data communications using heartbeat messaging
US10417102B2 (en) * 2016-09-30 2019-09-17 Commvault Systems, Inc. Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, including virtual machine distribution logic
US10778530B2 (en) * 2018-12-27 2020-09-15 Intel Corporation Device discovery using heartbeat signals

Also Published As

Publication number Publication date
DE102019211395A1 (de) 2021-02-04
CN114145000A (zh) 2022-03-04
DE102019211395B4 (de) 2021-03-04
WO2021018636A1 (de) 2021-02-04
US20220321444A1 (en) 2022-10-06

Similar Documents

Publication Publication Date Title
US10938937B2 (en) Multi-datacenter message queue
US8331223B2 (en) Method and system for controlling network traffic within the same connection with different packet tags by varying the policies applied to a connection
DE69805952T2 (de) Vorrichtung zur steuerung von verbindungen zwischen netzwerken
DE68919872T2 (de) Verfahren und Vorrichtung zur Verbindung von SNA-Endgeräten mit einem SNA-Hostrechner über ein paketvermitteltes Nachrichtennetz.
US7562146B2 (en) Encapsulating protocol for session persistence and reliability
US20030123394A1 (en) Flow control between performance enhancing proxies over variable bandwidth split links
US7555558B1 (en) Method and system for fault-tolerant transfer of files across a network
DE112015003004B4 (de) Hybrider Ansatz für leistungssteigernde Proxies
US7693998B2 (en) System and method for message-based scalable data transport
US20100185586A1 (en) Message-based scalable data transport protocol
KR20060103829A (ko) 서브큐를 이용한 로컬 메시지 프로세싱 개선
US6952731B2 (en) Remote control of a device over the internet
WO2001093508A1 (en) System for remotely managing network through serial ports
DE102019211395B4 (de) Effizienter Heartbeat-Mechanismus für Cloud-Anwendungen
KR102709540B1 (ko) Sdn 기반 메시지 전송 시스템 및 방법
EP1286513B1 (de) Nachrichten-Vermittler
KR20180028648A (ko) 단방향 데이터 송신 장치, 단방향 데이터 수신 장치 및 이를 이용한 단방향 데이터 전송 방법
CN202160197U (zh) 一种基于广域网vpn加速网关的加速通信装置
DE102009050767A1 (de) Verfahren und Vorrichtung zur Datenübertragung
CN114679472A (zh) 通信系统、方法、装置、存储介质及电子设备
WO2018047410A1 (ja) データダイオードシステム及びデータダイオードシステムにおけるデータ送信方法
KR100279716B1 (ko) 멀티인터페이스망관리시스템
CN102624753B (zh) 企业服务总线的分布式文件传输方法和设备
US7673067B2 (en) Pipeline for data exchange between medical image applications
WO2021254842A1 (de) Gerät zum einsatz im internet der dinge

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

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

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20250416