System for support in the event of intermittent connectivity, a corresponding local device and a corresponding cloud computing platform

This application claims priority to PCT Application No. PCT/EP2015/067218, having a filing date of Jul. 28, 2015, based off of German application No. DE 102014218215.8 having a filing date of Sep. 11, 2014, the entire contents of which are hereby incorporated by reference.

The following relates to a system in which, without a network connection, documents can also be processed locally and in which the documents stored offline can then be synchronized when a network connection is available.

In the case of computer clouds or cloud computing, services and data are relocated and are available via the Internet or an intranet. In such a case, the user thus needs to have a network connection in order to be able to use a cloud application. In certain application scenarios, such as in the automotive or mobile sector, for example, users typically do not have a permanent, uninterrupted connection to the Internet, however. Further, in the case of automation systems, for example, there are high demands on availability and there is the desire for such systems to be intended to continue to operate autonomously even without a connection to a network.

In general, it is known practice to provide redundant network connections, e.g. multiple cables or a landline network connection and a mobile radio connection. In the event of failure of one network, it is thus possible to use the second network to communicate.

Further, it is known practice to provide redundant servers in a computer center, so that a redundant substitute server can undertake service provision in the event of failure of a server. High-availability solutions of this kind are complex, however, and therefore expensive and not available generally in the case of cloud services.

In Shi et al. Computing in Cirrus Clouds: The Challenge of Intermittent Connectivity. In Proceedings of MCC 2012. ACM. 2012, applications are normally executed locally on the terminal and, on connection to a cloud, these applications can be relocated to the cloud as required.

In the case of the cloud-based application “Google Docs” it is possible to configure an offline mode, see https://support.google.com/drive/answer/1628467?hl=de. In this context, activation is possible such that documents are processable locally even without a network connection, with the documents stored offline then being synchronized when a network connection is available.

An aspect relates to specifying a system for support in the event of intermittent connectivity between a local device and a cloud computing platform, in which the highest possible availability is achieved with the lowest possible complexity and in which cloud services can continue to be used with the least possible restrictions and transparently for the user even in the event of connection interruptions.

Embodiments of the invention essentially relates to a system in which a request, e.g. a computation, is processable both in a cloud service and autonomously or locally by a client and, in this case, the network quality, for example the presence of delay, is monitored and in which, on the basis of the current availability of the cloud platform, a local substitute computation is possibly performed, which may be slower or, in the case of real-time demands, has a lower quality than the corresponding cloud service, and the result of which is then used temporarily as a substitute by the client. This allows cloud services to be buffered locally and hence connection interruptions between terminal and cloud platform to be cushioned, which means that cloud services can be used by the user transparently even in the event of connection interruptions, possibly with only a slight restriction, and hence further application scenarios can be opened up for cloud computing or the quality of service of known scenarios/applications can be improved. Embodiments of the invention can be used, by way of example, for the evaluation of image data in the medical sphere, for route computations in the navigation field, for image recognition in the automobile sphere and for computer games.

Some of the embodiments will be described in detail, with reference to the following figure, wherein like designations denote like members, wherein:

FIG. 1 shows an overview depiction to explain an embodiment of a system; and

FIG. 2 shows a depiction to explain an optional embodiment detail from the system.

In this case, a cloud platform CP covers the various embodiments Infrastructure-as-a-Service (I-a-a-S), Platform-as-a-Service (P-a-a-S) and Software-as-a-Service (S-a-a-S).

A local device LG is intended to be understood to mean e.g. a smartphone, laptop, industrial control installations and automobiles.

FIG. 1 shows a local device LD that executes a cloud application App locally, which cloud application makes a request to a cloud service CS by transmitting a request message 1 , and this request message 1 receives a response with an appropriate response message 4 .

According to embodiments of the invention, the request is duplicated locally on the device LD by a substitute provision unit or replacement dispatcher RD, and one request 2 a is transmitted to the local substitute functionality unit LCSR of the cloud service CS and the other request 2 b is transmitted to the actual cloud service CS. The substitute provision unit RD accordingly receives two response messages 3 a (local response) and 3 b (cloud service response) for these requests.

The replacement dispatcher RD provides the application App with one of the two responses according to a prescribable substitution guideline (Replacement Dispatcher Policy). It is optionally also possible for not, as depicted here, both services CS and LCSR (Cloud Service, Local CS Replacement) to receive the request, but rather for only one of the two to receive a request on the basis of the substitution guideline.

This has the advantage that the application App itself does not have to be produced or adapted specifically for intermittent network communication. It is also not necessary for the app itself to provide the logic of the cloud service, since the substitute computation is produced by a specific component LCSR.

In one variant, the substitution guideline is provided for the replacement dispatcher RD by the cloud service.

Diverse variants are conceivable concerning which criteria are used to make a substitution guideline decision

A network/cloud service monitor M monitors the quality, particularly signal delay, throughput and, indirectly, signal strength, transmission method and own position of the network connection to the cloud service or the response time of the cloud service. On the basis of this, a request by the application App is provided for the local substitute functionality unit LCSR of the cloud service CS or for the cloud service CS itself. A request by the app is buffer-stored and transmitted to the cloud service CS. A timer is started. If an associated response from the cloud service is not received within a prescribable time, then the buffer-stored request is provided for the local substitute service (local CS replacement) and the response thereof is returned to the app. If, however, an associated response from the cloud service is received within the prescribable time, then it is returned to the app. A request by the app is buffer-stored and transmitted to the cloud service and to the local substitute service (local CS replacement). A timer is started. A response by the local substitute service is buffer-stored as a substitute response. If an associated response from the cloud service is not received within a prescribable time, then the buffer-stored substitute response is returned to the app. If, however, an associated response from the cloud service is received within the prescribable time, then it is returned to the app and the buffer-stored substitute response is erased.

Applications with great resource requirements but without real-time demands, for example evaluation of image data in the medical sphere or route calculation in the field of navigation, are executed on the cloud platform CP as standard in this case and the results of these applications are sent to the terminal LD. If the local device LD cannot access the cloud platform CP, then the local device LD performs the calculations locally in this case and, as a result, usually more slowly or with increased battery loading.

Applications with great resource requirements and high real-time demands, for example image recognition in the automotive sphere and computer games with reducible graphics performance, are likewise executed at full power on the cloud platform CP as standard and the results of these applications are sent to the terminal LD. If the local device LD cannot access the cloud platform CP or the real time demands cannot be observed by the cloud platform and/or the current network connection, then the local device performs substitute computations locally and, if need be, in poor quality in this case, as a result of which the real time demands are observed.

Such an application may, in a manner comparable to P-a-a-S, be installed both on the cloud platform side and on the local device LD side, and the processed data or the results need to be synchronized when the terminal LD is connected to the cloud. In the event of disconnection, the local application App is automatically continued based on the data delivered by the cloud platform CP.

The local substitute functionality LCSR can optionally also be provided by a virtual machine that has been provided by the cloud platform CP. When the client or the local device LD registers with a cloud service CS, the cloud service can provide a virtual machine therefor that is hosted locally on the client. If the cloud service does not respond to a request in good time when used or the network connection is too poor, then the local substitute functionality in the form of a local replica of the virtual machine is used instead.

In a variant, a virtual machine image, i.e. program code and data for performing the local substitute functionality, is provided by the cloud service. This can be updated by the cloud service in one variant.

The local device LD may be provided as a physical unit, e.g. in a housing. However, it is also possible for the local unit to be provided in the form of interconnected components. These may be arranged e.g. in a switchgear cabinet, on a top hat rail, in a rack, e.g. 19″ rack, or in a switchroom. They may be connected e.g. via a data connection, e.g. a serial interface, a parallel interface, via Ethernet or wirelessly, e.g. via Bluetooth, Zigbee or WLAN.

Embodiments of the invention checks not only whether or not connectivity is available, but also the quality of an available connection, for example the presence of delay, as a result of which it additionally monitors whether the real-time properties are observed.

In general, a real-time checking criterion is monitored. This may be the response time of a cloud service. This means the period of time after sending a message to the cloud service after which the associated response message is received. In this case, the response time is dependent on the transmission delay to the cloud service and from the cloud service and on the processing time by the cloud service. The transmission delay is dependent not only on the signal transmission delay, e.g. via cables or optical fibers or via radio, but also on delays by intermediate components on the transmission link, e.g. switches or routers. Alternatively, the real-time checking criterion used may be a different measure, such as latency (delay) on the transmission link or part of the transmission link, a piece of load information for a transmission link or section of the transmission link, a piece of load information for the cloud service or the cloud platform, a piece of interference source information (interferers, e.g. for radio transmission) or a piece of denial-of-service attack recognition information.

FIG. 2 in turn shows firstly a local device LD and secondly a cloud platform CP, the cloud service CS from FIG. 1 in this case being in the form of a virtual machine VM and the substitute functionality unit LCSR from FIG. 1 being in the form of a local replica LVM of the virtual machine VM, provided by the cloud platform CP, however. The synchronization of the data of the local virtual machine LVM with the corresponding virtual machine VM is preferably provided by the cloud platform CP, the operating data of the local virtual machine LVM being synchronized with the cloud platform CBP.

In this context, in a manner comparable to I-a-a-S, an identical or functionally associated virtual machine runs on the local device LD and the cloud platform CP, which virtual machine is synchronized in the event of connection of the local device to the cloud. When the local device LD is connected to the cloud platform CP, the virtual machine VM that is on the cloud platform is executed and the states of this virtual machine VM are synchronized to the local virtual machine LVM on the local device LD. In the event of disconnection, the virtual machine VM in the cloud platform CP is stopped and the virtual machine LVM on the terminal is started with the currently synchronized state. All state changes on the local virtual machine LVM are recorded until the local device LD has a connection to the cloud platform again. In the event of a connection, all buffered state changes are synchronized to the cloud platform CP. The virtual machine VM in the cloud platform CP is then executed again and the local virtual machine LVM on the local device LD is stopped.

The local virtual machine LVM can be executed on the same computation unit (CPU or CPU core) as the application App. Similarly, it is possible for the local virtual machine LVM to be executed on another computation unit of the local device LD. In a variant, the local device contains a dedicated computation unit for executing the local virtual machine LVM.

The locally hosted replica LVM of the virtual machine VM can be automatically checked for updates. If need be, the cloud platform CP provides a delta version, i.e. a compact representation of the differences. However, it is optionally also possible to provide a complete updated virtual machine.

It is optionally possible for different authorization checks, e.g. service level agreement of the cloud user, platform configuration attestation of the local cloud platform, data structure or use data of the local replica LVM, to be performed in order to decide whether a local replication of this kind for a cloud service is admissible.

Although the present invention has been disclosed in the form of preferred embodiments and variations thereon, it will be understood that numerous additional modifications and variations could be made thereto without departing from the scope of the invention.

For the sake of clarity, it is to be understood that the use of “a” or “an” throughout this application does not exclude a plurality, and “comprising” does not exclude other steps or elements.