METHOD AND DATA-TRANSFER-SYSTEM FOR TRANSFERRING DATA BETWEEN A DATA SOURCE AND A DATA SINK

Abstract

To transfer data source data of a data source being destined for a data sink, from the data source to the data sink spaced from each other within a business premises it is proposed to download the data source data from of the data source, configure the data source data by packing the data source data with data source-related meta-information, encrypting the packed data source data and storing the configured data source data as transfer data for the transfer, onload the stored transfer data onto a transfer-data-carrier transferring the transfer data for an offload operation, offload the transfer data from the transfer-data-carrier, process offloaded transfer data by decrypting and unpacking the configured data source data and transforming the decrypted and unpacked data source data with the meta-information into data sink data to execute a data source data-related transaction in the data sink, and upload the data sink data.

Description

FIELD OF TECHNOLOGY

The following refers to a method for transferring data between a data source and a data sink according to the preamble of claim 1 and a Data-Transfer-System for transferring data between a data source and a data sink.

BACKGROUND

A typical, well-known example of the numerous ones being conceivable in the context of transferring data between a data source and a data sink is depicted in FIG. 1 as state of the art and starting point of observation for the present invention.

FIG. 1 shows a business premises BP, which can be formed as a shop-floor SF, a plant PT, a shop-floor-site SFS or a factory site FTS each including an IT-System ITS as an electronical system processing data. Within the business premises BP and regarding the processing of data there could be in principle at least one data source DSC as the source of data and at least one data sink DSN as the entity for processing the data within the ITS-System, although in the FIG. 1 only one data sink DSN is depicted. The at least one data source DSC being spread over the business premises BP are assets or devices delivering data to be processed, while the one data sink DSN is a maintenance system MSY or service system SSY processing the data. The assets or devices of the business premises BP are two motors, a first motor MOT1 and a second motor MOT2, a drive DRV, a pump PUM and three valves, a first valve VAL1, a second valve VAL2 and a third valve VAL3.

From the listed assets or devices there are a first group, which are connected either directly or indirectly via a control system CSY of the IT-System ITS with the maintenance system MSY or service system SSY of the IT-System ITS, and a second group, which have no connection to the maintenance system MSY or service system SSY.

While the first group includes connected assets AS_c or devices DV_c, the second group includes unconnected assets AS_uc or devices DV_uc.

The connected assets AS_c or devices DV_c comprise the second valve VAL2, the third valve VAL3 and the second motor MOT2, wherein the second valve VAL2 and the second motor MOT2 are connected over a wired-based online-connection via the control system CSY with the maintenance system MSY or service system SSY. The third valve VAL3, however, is connected over a wireless-based online-connection with the maintenance system MSY or service system SSY.

Why are these assets or devices connected with the maintenance system MSY or service system SSY?

The connected assets AS_c or devices DV_c, like the cited valves VAL2, VAL3 and the cited motor MOT2, being installed in business premises, like factories, plants or buildings do not last forever and need to be maintained or replaced over time. There are existing for example three simple and well-known strategies to counteract this, however each with different drawbacks:

• • 1. Run to failure: Use the asset until it fails. This will cause an unplanned outage with potential damage to other machines or people and impact on current production or contracts.
  • 2. Regular maintenance: In order to avoid unplanned outages, the assets AS_c or devices DV_c can be maintained according to a maintenance plan (e.g. with regard to an internal combustion engine replace oil each 1000 operating hours or replace the engine after 10 years). Maintenance plans are typically designed to be “on the safe side”. This means that the engine (asset or device) in principle could run longer but is maintained earlier. This leads to over-maintenance. Still there is a risk that the engine (asset or device) will break and cause an unplanned outage.
  • 3. Condition Based Service <CBS>, sometimes also called as Condition Based Maintenance: CBS helps to reduce over-maintenance and potentially can uncover risks of the asset or device breaks early. For this reason detailed data about the asset or device and the operating condition needs to be present in order to feed an algorithm that is able to predict the next maintenance or failure. This algorithm is based on a “Condition Based Service or Condition Based Maintenance <CBS>”-data evaluation executed in the maintenance system MSY or service system SSY as the data sink DSN. Carrying out this CBS-strategy is called as “Condition Based Service or Condition Based Maintenance <CBS>”-scenario.

In the following the “Condition Based Service or Condition Based Maintenance <CBS>”-scenario (as the third strategy) will be observed in more detail according to the FIG. 1 depicting the connections between the assets AS_c or devices DV_c and the maintenance system MSY or service system SSY.

To carry out the “Condition Based Service or Condition Based Maintenance <CBS>”-scenario it is necessary that the assets AS_c or devices DV_c need to provide their data to the maintenance system MSY or service system SSY running the predictive maintenance algorithm and thereby executing the “Condition Based Service or Condition Based Maintenance <CBS>”-data evaluation. The online-connection (wireless- or wired-based) via network protocols is the most convenient way, but expensive to realize as each asset requires in the case of the wired-based online-connection a separate cabling to a communication network (e.g. Ethernet-connection). So the wired-based online-connection between the second valve VAL2 or the second motor MOT2 and the maintenance system MSY or service system SSY via the control system CSY is thus for instance an Ethernet-connection.

The wireless-based online-connection—as depicted in the FIG. 1—between the third valve VAL3 and the maintenance system MSY or service system SSY has other drawbacks.

So, a wireless transmission over wide ranges (e.g. ranges above 20 meters) is typically not feasible because of

• • high electromagnetic emissions of the assets or devices,
  • interference influences caused e.g. by the electrical operation of the assets or devices being packed very densely in an area of operation and/or
  • construction-related attenuation of a wireless signal.

The drawback according to the second mirror line might not apply fortunately for the depicted wireless-based online-connection between the third valve VAL3 with the maintenance system MSY or service system SSY and the drawback according to the first mirror line could be overcome for instance by a “Wireless Local Area Network <WLAN>”-connection.

Nevertheless, plenty of assets or devices are running without the possibility to apply convenient CBS-measures, because of a non-existing connection to the maintenance system MSY or service system SSY.

These assets or devices are the already mentioned unconnected assets AS_uc or devices DV_uc of the second group being called sometimes according to the “Condition Based Service or Condition Based Maintenance <CBS>”-scenario as “brownfield-assets or -devices”. Now, these unconnected assets AS_uc or devices DV_uc should be observed in more detail in the extent of the present invention. For this purpose and because of their special invention-related interest they are called each more generally as the data source DSC.

This means that according to the FIG. 1 the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM are the remaining assets or devices, which belong to the second group and thus are unconnected assets AS_uc or devices DV_uc or more generally one data source DSC each. In each data source DSC respectively in the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM there are data source data DSCD destined for the data sink DSN for executing the “Condition Based Service or the Condition Based Maintenance <CBS>”-data evaluation discussed and mentioned above.

These unconnected assets AS_uc or devices DV_uc having no connection to the maintenance system MSY or service system SSY as the data sink DSN are thus without any possibility to apply convenient CBS-measures, i.e. a data connection for the data transfer between the data source DSC and the data sink DSN is non-existing.

It is challenging against the background of the drawbacks with regard to the wired-based online-connection or the wireless-based online-connection to the maintenance system MSY or service system SSY discussed above to establish a data connection between the unconnected assets AS_uc or devices DV_uc as the data source DSC each and the maintenance system MSY or service system SSY as the data sink DSN. This applies in particular to the wireless-based online-connection between the unconnected assets AS_uc or devices DV_uc and the maintenance system MSY or service system SSY due to the discussed wireless-based online-connection drawbacks. Especially because according to the depiction in the FIG. 1 the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM are packed very densely in an area of operation for a wireless transmission over wide ranges (e.g. ranges above 20 meters), so that thereby an interference area IFA would arise.

This however is problematic for executing the “Condition Based Service or the Condition Based Maintenance <CBS>”-data evaluation based on a data transfer from the unconnected assets AS_uc or devices DV_uc to the maintenance system MSY or service system SSY

Nevertheless, to execute anyway the “Condition Based Service or the Condition Based Maintenance <CBS>”-data evaluation for the unconnected assets AS_uc or devices DV_uc a typical practice is to send a human to the unconnected assets AS_uc or devices DV_uc. The human can either protocol operation conditions in an operation sheet by reading local measures (e.g. regarding the first motor MOT1 as the data source by reading rpm-data, temperature-data, etc.) or by connecting a computer to a local diagnosis port in order to download diagnostic data.

This approach is time consuming and can't be realized in short time intervals (e.g. hourly).

In order to achieve a high-frequency data evaluation for the “Condition Based Service or the Condition Based Maintenance <CBS>” an online connection for the predictive maintenance algorithm implemented in the maintenance system MSY or service system SSY to the data DSCD of the unconnected assets AS_uc or devices DV_uc would be required.

SUMMARY

An aspect relates to a method and a Data-Transfer-System for transferring data between a data source and a data sink, by which the data transfer is enabled at least more or less online without the data source and the data sink are connected and without any of the discussed drawbacks concerning the data transfer.

The main idea of the invention in order to transfer data source data of a data source being destined for a data sink, in particular for a “Condition Based Service or a Condition Based Maintenance <CBS>”-data evaluation executed in the data sink, from the data source to the data sink spaced from each other within a business premises, in particular a shop-floor, a plant, a shop-floor-site, a factory site etc. each including an IT-System, is to

• • download the data source data from the data source,
  • configure the data source data by packing the data source data with data source-related meta-information, encrypting the packed data source data
  • [Remark: The encryption of the packed data for the data transfer is done due to the following reasons:
    • Protection against stealing data from the transfer-data-carrier
    • Protection against unauthorized access towards the data
    • Protection against unwanted changes of the data to be transported (either caused by hardware issues or by manipulation). This data integrity is kept.]
  • and storing the configured data source data as transfer data for the transfer,
  • onload the stored transfer data (an onload operation) onto a transfer-data-carrier transferring the transfer data for an offload operation,
  • offload the transfer data from the transfer-data-carrier,
  • process the offloaded transfer data by decrypting and unpacking the configured data source data and transforming the decrypted and unpacked data source data with the meta-information into data sink data to execute a data source data-related transaction in the data sink,
  • upload the data sink data to the data sink.

This is an offline data transfer of data source data of the data source being destined for the data sink, in particular to enable a “Condition Based Service or a Condition Based Maintenance <CBS>”-scenario.

The advantage of the proposed solution is that assets or devices being each the data source of the data (i) being destined for the data sink as the entity regarding a data evaluation, in particular executing predictive maintenance algorithm according to a “Condition Based Service or a Condition Based Maintenance <CBS>”-scenario, and (ii) accordingly being collected and transferred within the business premises don't need to be connected online to a communication network which

• • Avoids costs for additional cablings and installation effort
  • Increase security as attackers could not reach the asset via an online connection
  • Increases flexibility as further assets or devices could be involved in a Data-Transfer-System over time individually

Additionally by allowing the preferred “Condition Based Service or a Condition Based Maintenance <CBS>”-scenario on the assets or devices has the following advantages

• • Avoid over-maintenance and therefore decreases maintenance cost
  • Uncovers potential asset failures early and avoids unplanned outages
  • Safe the environment as assets can be used efficiently in their whole lifetime period which avoids production of new ones (i.e. less carbon-dioxide emissions, material demand, etc.)

The proposed solution has furthermore the following benefits:

• • Brownfield enablement of existing assets to act in a connected world.

As an example: A typical chemical plant has roughly 1000 valves installed in the process. Only 500 of them are connected to a control system via a wire. This means half of the valves acting in the process without knowing the concrete actual state. It is too costly for the plant operator to connect them via wire or to send out personnel for regular checks. An automated solution would basically help tremendously to gain transparency and enable new use cases.

• • Avoid over-maintenance of assets or devices and therefore decreases maintenance cost.
  • Uncover potential asset or device failures early and avoid unplanned outages.
  • Safe the environment as assets or devices can be used in their whole lifetime and doesn't need to be replaced with new ones (who would provide built-in connectivity)

Furthermore, the invention can be used in various scenarios. First and foremost, thereby referring to the claims 6 and 18, it should be mentioned and the invention with its underlying methodology and technology is focused but not limited to the “Condition Based Service or Condition Based Maintenance <CBS>”-scenario discussed in the context of the FIG. 1 in in the introductory part of the application.

Basically the same approach can be applied to any scenario that requires data from assets or devices as a data source that not needs to have a real-time access as it is the case when they are connected to a data sink performing the data evaluation.

So according to the claims 7 to 9 or 19 to 21 alternative scenarios are for example:

• • (claims 7 and 19): A “displaying machine status”-scenario, e.g. in a “Supervisory Control and Data Acquisition <SCADA>”-environment, according to which within the business premises the data source is a dashboard and the data sink is a central monitoring station.
  • (claims 8 and 20): An “Update Push”-scenario, such as updating firmware, configuration changes or non-real-time-critical commands, according to which within the business premises the data source is an update-database and the data sink is a device to be updated.
  • (claims 9 and 21): A “data analytics”-scenario, according to which within the business premises the data source is a machine or device generating various kind of data to be analyzed and the data sink is a central location for running the analysis.

Independently from the cited scenarios, the invention can be applied to, the transfer data is onloaded onto the transfer-data-carrier as a transport medium between the onload and offload operation (which are carried out at different times) to overcome the spatial distance between the data source and the data sink and is offloaded from the transfer-data-carrier either—according to the claims 2 and 11—via a wireless data connection and this wireless data connection is in order to avoid the drawbacks regarding such a connection discussed in the introductory part of the application in particular a “Near Field Communication <NFC>”-connection or a “Bluetooth <BT>”-connection or a “Wireless Local Area Network <WLAN>”-connection or alternatively—according to the claims 3 and 12—via a wired data connection such as a “Universal Serial Bus <USB>”-connection.

The transfer-data-carrier as the transport medium is—according to the claims 4 and 13—is a wireless device, such as a smartphone or a tablet (e.g. with each an Android- or iOS-operating system), assignable to a human or robot and thereby used for being carried along a walkway of the business premises between the data source and the data sink. Alternatively, it is also possible that the transfer-data-carrier is a drone to overcome the spatial distance between the data source and the data sink, which includes a wireless device.

A complete other way to overcome the spatial distance between the data source and the data sink is—according to the claims 4 and 15—a Wireless-Mesh-Network with wireless cells, which are based on “Wireless Local Area Network <WLAN>”-cells or “Bluetooth <BT>”-cells, wherein the wireless cells of the Wireless-Mesh-Network are set up by at least one Download-Unit and at least one Upload-Unit.

A frequent data transfer with a Data-Transfer-System (cf. claim 10) to apply any of the cited scenarios and especially the CBS-scenario on unconnected assets or devices is enabled by combining multiple aspects together:

• • Identification or detection of a regular “visit” or pass-by of either a human such as service person or visitor, or a robot or a drone or an autonomous transport vehicle with the wireless device in the business premises serving as the transfer-data-carrier.
  • Equip the human, the robot, the drone or the autonomous transport vehicle with the wireless device such as the smartphone or the tablet including a processor (a computing unit) with a local persistence or storage and a wireless transceiver as the transfer-data-carrier.
  • Equip the data sources respectively the unconnected (offline) assets or devices with a Download-Unit including a wireless transmitter (sender) that sends operational data (data of operating conditions) and/or diagnostic data as data source data.
  • Provide an Upload-Unit, e.g. a computer, a server or even an app on a notebook, where the human or robot can plug the wireless device and controlled by the computing unit its local persistence or storage gets emptied (the offload operation) and where the offloaded data is uploaded to the data sink respectively the maintenance system or service system executing the predictive maintenance algorithm.

The wireless transmitter (sender) of the Download-Unit broadcast the current operational data and/or diagnostic data. Whenever the human, the robot, the drone or the autonomous transport vehicle with the wireless device in the business premises serving as the transfer-data-carrier passes by it automatically receives the broadcasted data and stores the data in the local persistence or storage. The data on the with the wireless device can be cyclically offloaded and afterwards uploaded using the Upload-Unit, e.g. by

• • the human regularly replaces the wireless device when passing by the Upload-Unit
  • the human when finish working or changing the working shift
  • the robot when coming back e.g. for charging

This approach allows to get the operational data and/or the diagnostic data to feed the predictive maintenance algorithm executed in the maintenance system or service system constantly with new data to enable the “Condition Based Service or the Condition Based Maintenance <CBS>”—scenario for the unconnected assets or devices.

The Data-Transfer-System according to the claim 10 can be configured either completely as a hardware-based System or in the course of digitization according to the claims 14 and 17 as a hardware- and software-based System the components included in the Download-Unit, the transfer-data-carrier and the Upload-Unit are formed as a computer-implemented-tool, which is an APP and which when being uploaded is embedded into a custom software execution container. The custom software execution container is a technology of a software system to provide the access to hardware resources (i.e. CPU, RAM, Disk, I/O-interface) to a defined software process running inside a hosting (software) system such as a data source and/or a data sink. The access of a software process running in a container towards other processes running the hosting software system can be precisely controlled by the hosting software system. For the Data Transfer System the container can be realized by for example virtual machines (like VMware), container frameworks (like Docker) or operating system namespaces (like Linux Namespaces; used to partition resources to a software process). Such a container environment for the custom software execution is necessary as a prerequisite in case the software required by the Data Transfer System is to be provided as software-only-package provided by a Software Repository.

BRIEF DESCRIPTION

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

FIG. 1 with the corresponding explanations, arise out of the following description of embodiments of the invention according to FIGS. 2 to 8;

FIG. 2 based on the FIG. 1 a Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario between the unconnected assets or devices each as the data source and the maintenance system or service system as the data sink;

FIG. 3 shows the structure of a Download-Unit as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the unconnected asset or device as the data source;

FIG. 4 shows the configuration of a “data source”-related computer-implemented-tool replacing essentially the Download-Unit according to the FIG. 3 as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the unconnected asset or device as the data source;

FIG. 5 shows the structure of a transfer-data-carrier as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on overcoming a spatial distance between the unconnected asset or device as the data source and the maintenance system or service system as the data sink;

FIG. 6 shows the configuration of a mesh-scenario replacing the transfer-data-carrier according to the FIG. 5 as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on overcoming a spatial distance between the unconnected asset or device as the data source and the maintenance system or service system as the data sink;

FIG. 7 shows the structure of an Upload-Unit as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the maintenance system or service system as the data sink; and

FIG. 8 shows the configuration of a “data sink”-related computer-implemented-tool replacing essentially the Upload-Unit according to the FIG. 5 as part of the Data-Transfer-System enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the maintenance system or service system as the data sink;

DETAILED DESCRIPTION

FIG. 2 shows based on the FIG. 1 and its figure description a Data-Transfer-System DTFS enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario between the unconnected assets AS_uc or devices DV_uc each as the data source DSC and the maintenance system MSY or service system SSY as the data sink DSN within the business premises BP. These unconnected assets AS_uc or devices DV_uc—called as “brownfield-assets or -devices”—are running without the possibility to apply convenient CBS-measures, because of a non-existing connection to the maintenance system MSY or service system SSY.

As according to the FIG. 1 the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM of the second group of assets or devices are the unconnected assets AS_uc or devices DV_uc or more generally one data source DSC each. In each data source DSC respectively in the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM there are the data source data DSCD destined for the data sink DSN for executing the “Condition Based Service or the Condition Based Maintenance <CBS>”-data evaluation already discussed and mentioned by the description of the FIG. 1.

The Data-Transfer-System DTFS is now provided to enable the unconnected assets AS_uc or devices DV_uc to have a data connection to the maintenance system MSY or service system SSY as the data sink DSN are thus they have the possibility to apply the convenient CBS-measures.

For this purpose the Data-Transfer-System DTFS includes first of all a Download-Unit DLU, which is wire-connected each with the unconnected asset AS_uc or device DV_uc and thus to the first motor MOT1, the drive DRV, the first valve VAL1 and the pump PUM of the second group of assets or devices respectively each to the data source DSC as the source of the data source data DSCD for downloading the data source data DSCD.

How this downloading is realized will be described later on according to the description of FIGS. 3 and 4.

At this point in the context of describing the FIG. 2 it should be mentioned in advance that the Download-Unit DLU is being able to establish inter alia a wireless data connection WLDC (according to the FIGS. 3 and 4 it will be seen that also a wired data connection is possible) within the Data-Transfer-System DTFS for enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario. The wireless data connection WLDC is

• • (i) with regard to the explanations by describing the FIG. 1 in the context of interference drawbacks caused e.g. by the electrical operation of the unconnected assets AS_uc or devices DV_uc and the Download-Unit DLU with the wireless data connection WLDC being packed very densely in an area of operation depicted in both figures, the FIG. 1 and the FIG. 2, as the interference area IFA and
  • (ii) with regard to the also discussed emission drawbacks of the unconnected assets AS_uc or devices DV_uc DV_uc and the Download-Unit DLU with the wireless data connection WLDC a “Near Field Communication <NFC>”-connection or a “Bluetooth <BT>”-connection or a “Wireless Local Area Network <WLAN>”-connection.

Furthermore regarding the cited purpose the Data-Transfer-System DTFS includes an Upload-Unit ULU, which is wire-connected with the maintenance system MSY or service system SSY as the data sink DSN for uploading the data source data DSCD, when the data source data DSCD is transferred from the Download-Unit DLU to the Upload-Unit ULU.

Firstly, how this uploading is realized will be described later on according to the description of FIGS. 7 and 8.

Secondly, how the data transfer from the Download-Unit DLU to the Upload-Unit ULU is realized will be described next.

At this point in the context of describing the FIG. 2 it should be mentioned in advance that also the Upload-Unit DLU is being able to establish inter alia the wireless data connection WLDC (according to the FIGS. 7 and 8 it will be seen that also here a wired data connection is possible) within the Data-Transfer-System DTFS for enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario. The wireless data connection WLDC is also here

• • (i) with regard to the explanations by describing the FIG. 1 in the context of interference drawbacks of the maintenance system MSY or service system SSY and the Upload-Unit DLU with the wireless data connection WLDC and
  • (ii) with regard to the also discussed emission drawbacks of the maintenance system MSY or service system SSY and the Upload-Unit DLU with the wireless data connection WLDC a “Near Field Communication <NFC>” or a “Blue-tooth <BT>”-connection or a “Wireless Local Area Network <WLAN>”-connection.

Now, how the data transfer from the Download-Unit DLU to the Upload-Unit ULU is realized. For this purpose the Data-Transfer-System DTFS includes a transfer-data-carrier TFDC. The transfer-data-carrier TFDC is a wireless device WLD, which can be a smartphone or a tablet and which is assigned to a human or robot and thereby used for being carried along a walkway WW of the business premises BP between the Download-Unit DLU respectively the data source DSC and the Upload-Unit ULU respectively the data sink DSN.

The human can be for instance a person of working or service staff working at the business premises.

At this point in the context of describing the FIG. 2 it should be mentioned in advance that also the transfer-data-carrier TFDC due to the implementation as the wireless device WLD is being able to establish inter alia the wireless data connection WLDC (according the FIG. 5 it will be seen that also a wired data connection is possible) within the Data-Transfer-System DTFS for enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario, wherein the wireless data connection WLDC is also here a “Near Field Communication <NFC>”-connection or a “Bluetooth <BT>”-connection or a “Wireless Local Area Network <WLAN>”-connection.

Due to this implementation the transfer-data-carrier TFDC as a transport medium between the Download-Unit DLU and the Upload-Unit ULU it is possible to overcome the spatial distance between the data source DSC and the data sink DSN respectively the Download-Unit DLU and the Upload-Unit ULU.

When the transfer-data-carrier TFDC is carried along the walkway WW and enters in a wireless distance to the Download-Unit DLU (i.e. the transfer-data-carrier TFDC comes round or passes the Download-Unit DLU and is in a transmission range to Download-Unit DLU) in the effective range of the wireless data connection WLDC, then it comes to an onload operation concerning the data transfer between the Download-Unit DLU and transfer-data-carrier TFDC.

Moreover when the transfer-data-carrier TFDC is carried further along the walkway WW and enters in a further or the same wireless distance to the Upload-Unit ULU (i.e. the transfer-data-carrier TFDC comes round or passes the Upload-Unit DLU and is in a further transmission range to the Upload-Unit DLU) in the effective range of the wireless data connection WLDC then it comes to an offload operation concerning the data transfer between the Upload-Unit DLU and transfer-data-carrier TFDC.

These onload and offload operations can be carried out as often as necessary, so for instance in regular time intervals, e.g. one hour or a day and they can be carried out quiet seamlessly.

Alternatively, to the human or robot carrying the wireless device it is also possible that a drone with the wireless device is used to overcome the spatial distance between the data source DSC and the data sink DSN respectively the Download-Unit DLU and the Upload-Unit ULU.

It is also possible to let multiple of those transfer-data-carrier run through the business premises. It is moreover possible to have multiple Upload-Units available in order to increase the chance of pass-by's of a walkway participant.

As soon as transfer-data-carrier has uploaded data packages to the Upload-Unit the data kept locally on the transfer-data-carrier gets deleted to free up disk space for the next data collection run.

The same thing happens at the Download-Unit connected with data source. So, as soon as the Download-Unit has onloaded data packages to the transfer-data-carrier the data kept locally on the Download-Unit gets deleted to free up disk space for the next data collection run

In the meantime new data source data could be recorded by the Download-Unit.

FIG. 3 shows the structure of the Download-Unit DLU as part of the Data-Transfer-System DTFS being power supplied PWS and enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the unconnected asset AS_uc or device DV_uc as the data source DSC.

As already mentioned, (cf. FIG. 2 with the corresponding description) the Download-Unit DLU is wire-connected with the unconnected asset AS_uc or device DV_uc. This wire-connection includes a “to data source”-related wired interface WRIF_DSC as part of the Download-Unit DLU and a “to download-unit”-related wired interface WRIF_DLU as part of the data source DSC.

Furthermore also already mentioned (cf. FIG. 5 with the corresponding description) the Download-Unit DLU is being able to establish the wireless data connection WLDC. For establishing this wireless data connection WLDC the Download-Unit DLU includes at least one wireless port WLP, which according to the type of the wireless data connection WLDC is at least one of a “Near Field Communication <NFC>”-port, a “Bluetooth <BT>”-port and a “Wireless Local Area Network <WLAN>”-port.

Alternatively to the established wireless data connection WLDC it is also possible that the Download-Unit DLU can establish a wired data connection WRDC, which is a “Universal Serial Bus <USB>”-connection. For establishing this wired data connection WRDC the Download-Unit DLU includes a wired port WRP, which according to the type of the wired data connection WRDC is a “Universal Serial Bus <USB>”-port.

Moreover to download the data source data DSCD from the unconnected asset AS_uc or device DV_uc and to enable the aforementioned onload operation the Download-Unit DLU includes a downloading component DWLC, a configuring component CFGC and an onload component ONLC.

These components form a functional unit to enable based on the data source data DSCD the cited onload operation.

First of all the downloading component DWLC downloads dwl via the wired interfaces WRIF_DSC, WRIF_DLD the data source data DSCD from of the data source DSC respectively the unconnected asset AS_uc or device DV_uc.

Then the downloaded data DSCD is passed to the configuring component CFGC for configuring cfg the data source data DSCD. For this purpose the configuring component CFGC includes a processor PRCCFGC, a One-Time-Configuration-Module OTCMCFGC and a local persistence LPSCFGC, which functionally form the configuring component CFGC such that the downloaded data source data DSCD is passed to the processor PRCCFGC, which

• • packs pck the data with data source-related meta-information MIF received from the One-Time-Configuration-Module OTCMCFGC to packed data DSCD+MIF,
  • encrypts ecr the packed data DSCD+MIF by using an encryption key ECRK also received from the One-Time-Configuration-Module OTCMCFGC,
  • stores str the packed data DSCD+MIF being encrypted as transfer data TFD in the local persistence LPSCFGC.

The encryption of the packed data for the data transfer is done due to the following reasons:

• • Protection against stealing data from the transfer-data-carrier
  • Protection against unauthorized access towards the data
  • Protection against unwanted changes of the data to be transported (either caused by hardware issues or by manipulation). Thus data integrity is kept.

Finally the onload component ONLC onloads onl by accessing the stored transfer data TFD and by therefore using the wireless port WLP or alternatively the wired port WRP for the cited onload operation by which according to FIG. 5 the transfer data TFD is onloaded to the transfer-data-carrier.

FIG. 4 shows the configuration of a “data source”-related computer-implemented-tool CIT_DSC replacing essentially the Download-Unit DLU according to the FIG. 3 as part of the Data-Transfer-System DTFS enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the unconnected asset AS_uc or device DV_uc as the data source DSC.

The “data source”-related computer-implemented-tool CIT_DSC replacing essentially the Download-Unit DLU takes over the tasks of the downloading component DWLC, the configuring component CFGC and the onload component ONLC carried out in the Download-Unit DLU, while the wired interfaces WRIF_DSC, WRIF_DLU used for the DSCD-download are replaced by one wired interface WRIF, which as part of the unconnected asset AS_uc or device DV_uc respectively the data source DSC is assigned to a “data source”-provided custom software execution container CSEC_DSC on the unconnected asset AS_uc or device DV_uc respectively the data source DSC.

The same happened to the wireless port WLP and the optionally used wired port WRP used for the TFD-onload, which again as part of the unconnected asset AS_uc or device DV_uc respectively the data source DSC are also assigned to the “data source”-provided custom software execution container CSEC_DSC on the unconnected asset AS_uc or device DV_uc respectively the data source DSC.

The “data source”-provided custom software execution container CSEC_DSC is a technology of a software system to provide the access to hardware resources (i.e. CPU, RAM, Disk, I/O-interface) to a defined software process running inside a hosting (software) system such as the unconnected asset AS_uc or device DV_uc respectively the data source DSC. The access of a software process running in a container towards other processes running the hosting (software system) can be precisely controlled by the hosting (software) system. For the Data Transfer System the container can be realized by for example virtual machines (like VMware), container frameworks (like Docker) or operating system namespaces (like Linux Namespaces; used to partition resources to a software process). Such a container environment for the custom software execution is necessary as a prerequisite in case the software required by the Data Transfer System is to be provided as software-only-package provided by a Software Repository.

The “data source”-related computer-implemented-tool CIT_DSC is an APP and which when being uploaded via a first software-interface-port SWIP1 as part of the unconnected asset AS_uc or device DV_uc respectively the data source DSC from a software repository SWRP is embedded into the “data source”-provided custom software execution container CSEC_DSC.

Being embedded in the “data source”-provided custom software execution container CSEC_DSC the “data source”-related computer-implemented-tool CIT_DSC is used—by taking over the cited component tasks of the Download-Unit DLU—to download the data source data DSCD from the unconnected asset AS_uc or device DV_uc and to enable the aforementioned onload operation.

Now, the “data source”-related computer-implemented-tool CIT_DSC forms the functional unit to enable based on the data source data DSCD the cited onload operation.

First of all within the “data source”-related computer-implemented-tool CIT_DSC the downloading component DWLC downloads dwl via the wired interfaces WRIF the data source data DSCD from of the data source DSC respectively the unconnected asset AS_uc or device DV_uc.

Then within the “data source”-related computer-implemented-tool CIT_DSC the downloaded data DSCD is passed to the configuring component CFGC for configuring cfg the data source data DSCD. For this purpose the configuring component CFGC of the “data source”-related computer-implemented-tool CIT_DSC includes a processor PRC′CFGC, a One-Time-Configuration-Module OTCM′_CFGC and a local persistence LPS′_CFGC, which functionally form the configuring component CFGC of the “data source”-related computer-implemented-tool CIT_DSC such that the downloaded data source data DSCD is passed to the processor PRC′_CFGC, which

• • packs pck the data with data source-related meta-information MIF received from the One-Time-Configuration-Module OTCM′_CFGC to packed data DSCD+MIF,
  • encrypts ecr the packed data DSCD+MIF by using an encryption key ECRK also received from One-Time-Configuration-Module OTCM′_CFGC,
  • stores str the packed data DSCD+MIF being encrypted as transfer data TFD in the local persistence LPS′_CFGC.

Finally within the “data source”-related computer-implemented-tool CIT_DSC the onload component ONLC onloads onl by accessing the stored transfer data TFD and by therefore using the wireless port WLP or alternatively the wired port WRP for the cited onload operation by which according to FIG. 5 the transfer data TFD is onloaded to the transfer-data-carrier.

FIG. 5 shows the structure of a transfer-data-carrier TFDC as part of the Data-Transfer-System DTFS enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on overcoming a spatial distance between the unconnected asset AS_uc or device DV_uc as the data source DSC and the maintenance system MSY or service system SSY as the data sink DSN.

As already mentioned, (cf. FIG. 2 with the corresponding description) the transfer-data-carrier TFDC due to its implementation as wireless device WLD is being able to establish the wireless data connection WLDC. For establishing this wireless data connection WLDC the wireless device WLD of the transfer-data-carrier TFDC includes at least one wireless port WLP, which according to the type of the wireless data connection WLDC is at least one of a “Near Field Communication <NFC>”-port, a “Bluetooth <BT>”-port and a “Wireless Local Area Network <WLAN>”-port.

Alternatively to the established wireless data connection WLDC it is also possible that the transfer-data-carrier TFDC can establish a wired data connection WRDC, which is a “Universal Serial Bus <USB>”-connection. For establishing this wired data connection WRDC the transfer-data-carrier TFDC includes a wired port WRP, which according to the type of the wired data connection WRDC is a “Universal Serial Bus <USB>”-port.

Moreover to enable the aforementioned (cf. FIG. 2 with the corresponding description) onload operation and offload operation the transfer-data-carrier TFDC includes a nearby detection component NBDC and a transfer component TFC.

These components form a functional unit to enable the onload operation and the offload operation.

First of all the nearby detection component NBDC detects when the transfer-data-carrier TFDC is in a transmission range (cf. FIG. 2 with the corresponding description) to the Download-Unit DLU for receiving the stored transfer data TFD from the Download-Unit DLU to enable the onload operation.

Then, as soon as the transfer-data-carrier TFDC is in the transmission range to the Download-Unit DLU, the onload operation happens and the onloaded transfer data TFD is passed via the wireless port WLP or alternatively the wired port WRP to the transfer component TFC for the later on offload operation (cf. FIG. 2 with the corresponding description).

For this purpose the transfer component TFC includes a processor PRC_TFC, a Data-Input-Output-Interface DIOIF and a local persistence LPS_TFC, which functionally form the transfer component TFC such that the onloaded transfer data TFD is passed from the wireless port WLP or alternatively the wired port WRP over the Data-Input-Output-Interface DIOIF to the processor PRC_TFC, which temporary stores the onloaded transfer data TFD in local persistence LPS_TFC for the for the later on offload operation, while the transfer-data-carrier TFDC is carried along the walkway in direction to the data sink respectively the maintenance system or service system (cf. FIG. 2 with the corresponding description).

Now, the nearby detection component NBDC detects when the offload operation can be carried out as soon as the transfer-data-carrier TFDC is in a further transmission range (cf. FIG. 2 with the corresponding description) to the Upload-Unit ULU, so that the Upload-Unit ULU can receive the transfer data TFD stored in local persistence LPS_TFC of the transfer component TFC to enable the offload operation.

The nearby detection works such that in regular cycles (i.e. 100 ms) a broadcast-signal is sent out with the request of an answer of Download-Unit or Upload-Unit. If the Download-Unit or Upload-Unit answers, the nearby detection activates processor PRC_TFC to enable the onload operation or the offload operation.

Also (cf. FIG. 4 regarding the Download-Unit and FIG. 82 each with the corresponding description) with regard to the transfer-data-carrier TFDC it is possible that the nearby detection component NBDC and the transfer component TFC of the transfer-data-carrier TFDC are formed as a “transfer-data-carrier”-related computer-implemented-tool CIT_TFPC, which when being assigned to the transfer-data-carrier TFDC by an upload of the “transfer-data-carrier”-related computer-implemented-tool CIT_FDC and thus embedded into a “transfer-data-carrier”-provided custom software execution container CSEC_TFNDC uses either the wireless port WLP or the wired port WRP of the wireless device WLD for receiving the transfer data TFD and carrying out the offload operation for offloading the transfer data TFD.

FIG. 6 shows the configuration of a mesh-scenario replacing the transfer-data-carrier TFDC according to the FIG. 5 as part of the Data-Transfer-System DTFS enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on overcoming a spatial distance between the unconnected asset or device as the data source and the maintenance system or service system as the data sink. The transfer-data-carrier TFDC is a Wireless-Mesh-Network WMN with wireless cells WLC, which are based on “Wireless Local Area Network <WLAN>”-cells or “Bluetooth <BT>”-cells and wherein the wireless cells WLC of the Wireless-Mesh-Network WMN are set up by at least one Download-Unit DLU and at least one Upload-Unit ULU.

FIG. 7 shows the structure of the Upload-Unit ULU as part of the Data-Transfer-System DTFS being power supplied PWS and enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the maintenance system MSY or service system SSY as the data sink DSN.

As already mentioned, (cf. FIG. 2 with the corresponding description) the Upload-Unit ULU is wire-connected with the maintenance system MSY or service system SSY. This wire-connection includes a “to data sink”-related wired interface WRIF_DSN as part of the Upload-Unit DLU and a “to upload-unit”-related wired interface WRIF_ULU as part of the data sink DSN.

Furthermore also already mentioned (cf. FIG. 2 with the corresponding description) the Upload-Unit ULU is being able to establish the wireless data connection WLDC. For establishing this wireless data connection WLDC the Upload-Unit ULU includes at least one wireless port WLP, which according to the type of the wireless data connection WLDC is at least one of a “Near Field Communication <NFC>”-port, a “Bluetooth <BT>”-port and a “Wireless Local Area Network <WLAN>”-port.

Alternatively to the established wireless data connection WLDC it is also possible that the Upload-Unit DLU can establish a wired data connection WRDC, which is a “Universal Serial Bus <USB>”-connection. For establishing this wired data connection WRDC the Upload-Unit DLU includes a wired port WRP, which according to the type of the wired data connection WRDC is a “Universal Serial Bus <USB>”-port.

Moreover to enable the aforementioned offload operation and to upload the data sink data DSND to the maintenance system MSY or service system SSY the Upload-Unit ULU includes an offload component OFLC, a processing component PRC_C and an uploading component UPLC.

These components form a functional unit to enable based on the offload operation the cited upload of the data sink data DSND.

First of all the offload component OFLC, when according to the detection of the nearby detection component (cf. FIG. 5 with the corresponding description) the Upload-Unit ULU is in the further transmission range to the transfer-data-carrier (cf. FIG. 2 with the corresponding description), receives via the wireless port WLP or alternatively the wired port WRP the transfer data TFD for carrying out ofl the cited offload operation.

Then the offloaded transfer data TFD is passed to the processing component PRCC for processing prc the transfer data TFD. For this purpose the processing component PRCC includes a processor PRC_PRCC and a One-Time-Configuration-Module OTCMCFGC, which functionally form the processing component PRCC such that the offloaded transfer data TFD is passed to the processor PRC_CFGC, which

• • decrypts dcr the transfer data TFD by using a decryption key DCRK received from the One-Time-Configuration-Module OTCM_PRCC,
  • unpacks upck the decrypted transfer data TFD with the data source-related meta-information MIF,
  • transforms trf the decrypted and unpacked data source data DSCD with the meta-information MIF into the data sink data DSND to execute a data source data-related transaction in the data sink DSN.

Finally the upload component UPLC uploads upl via the wired interfaces WRIF_DSN, WRIF_ULU the data sink data DSND to the data sink DSN respectively the maintenance system MSY or service system SSY.

FIG. 8 shows the configuration of a “data sink”-related computer-implemented-tool CIT_DSN replacing essentially the Upload-Unit ULU according to the FIG. 7 as part of the Data-Transfer-System DTFS enabling the “Condition Based Service or the Condition Based Maintenance <CBS>”-scenario on the maintenance system MSY or service system SSY as the data sink DSN.

The “data sink”-related computer-implemented-tool CIT_DSN replacing essentially the Upload-Unit ULU takes over the tasks of the offload component OFLC, the processing component PRC_C and the uploading component UPLC carried out in the Upload-Unit ULU, while the wired interfaces WRIF_DSN, WRIF_ULU used for the DSND-upload are replaced by one wired interface WRIF, which as part of the maintenance system MSY or service system SSY respectively the data sink DSN is assigned to a “data sink”-provided custom software execution container CSEC_DSN on the maintenance system MSY or service system SSY respectively the data sink DSN.

The same happened to the wireless port WLP and the optionally used wired port WRP used for the offload operation of the transfer data TFD, which again as part of the maintenance system MSY or service system SSY respectively the data sink DSN are also assigned to the “data source”-provided custom software execution container CSEC_DSC on the maintenance system MSY or service system SSY respectively the data sink DSN.

The “data sink”-provided custom software execution container CSEC_DSN is also a technology of a software system to provide the access to hardware resources (i.e. CPU, RAM, Disk, I/O-interface) to a defined software process running inside a hosting (software) system such as the maintenance system MSY or service system SSY respectively the data sink DSN. The access of a software process running in a container towards other processes running the hosting (software system) can be precisely controlled by the hosting (software) system. For the Data Transfer System the container can be realized by for example virtual machines (like VMware), container frameworks (like Docker) or operating system namespaces (like Linux Namespaces; used to partition resources to a software process). Such a container environment for the custom software execution is necessary as a prerequisite in case the software required by the Data Transfer System is to be provided as software-only-package provided by a Software Repository.

The “data sink”-related computer-implemented-tool CIT_DSN is also an APP and which when being uploaded via a second software-interface-port SWIP2 as part of the maintenance system MSY or service system SSY respectively the data sink DSN from a software repository SWRP is embedded into the “data sink”-provided custom software execution container CSEC_DSN.

Being embedded in the “data sink”-provided custom software execution container CSEC_DSN the “data source”-related computer-implemented-tool CIT_DSN is used—by taking over the cited component tasks of the Upload-Unit ULU—to enable based on the cited offload operation the cited upload of the data sink data DSND to the maintenance system MSY or service system SSY respectively the data sink DSN.

Now, the “data sink”-related computer-implemented-tool CIT_DSN forms the functional unit to enable based on the cited offload operation the cited upload of the data sink data DSND.

First of all within the “data sink”-related computer-implemented-tool CIT_DSN the offload component OFLC, when according to the detection of the nearby detection component (cf. FIG. 5 with the corresponding description) the Upload-Unit ULU is in the further transmission range to the transfer-data-carrier (cf. FIG. 2 with the corresponding description), receives via the wireless port WLP or alternatively the wired port WRP the transfer data TFD for carrying out ofl the cited offload operation.

Then the offloaded transfer data TFD is passed to the processing component PRCC for processing prc the transfer data TFD. For this purpose the processing component PRCC of the “data sink”-related computer-implemented-tool CIT_DSN includes a processor PRC′_PRCC and a One-Time-Configuration-Module OTCM′_CFGC, which functionally form the processing component PRCC of the “data sink”-related computer-implemented-tool CIT_DSN such that the offloaded transfer data TFD is passed to the processor PRC′_CFGC, which

• • decrypts dcr the transfer data TFD by using a decryption key DCRK received from the One-Time-Configuration-Module OTCM′ PRCC,
  • unpacks upck the decrypted transfer data TFD with the data source-related meta-information MIF,
  • transforms trf the decrypted and unpacked data source data DSCD with the meta-information MIF into the data sink data DSND to execute a data source data-related transaction in the data sink DSN.

Finally within the “data sink”-related computer-implemented-tool CIT_DSN the upload component UPLC uploads upl via the wired interfaces WRIF_DSN, WRIF_ULU the data sink data DSND to the data sink DSN respectively the maintenance system MSY or service system SSY.

Although the present invention has been disclosed in the form of 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.

Claims

1. A method for transferring data between a data source and a data sink, by which the data source and the data sink are spaced from each other within a business premises each including an IT-System, in the data source there are data source data destined for the data sink and a data connection for the data transfer between the data source and the data sink is non-existing, the method comprising: a) downloading the data source data from the data source;b) configuring the data source data by packing the data source data with data source-related meta-information, encrypting the packed data source data and storing the configured data source data as transfer data for the transfer;c) onloading the stored transfer data onto a transfer-data-carrier transferring the transfer data for an offload operation;d) offloading the transfer data from the transfer-data-carrier;e) processing the offloaded transfer data by decrypting and unpacking the configured data source data and transforming the decrypted and unpacked data source data with the meta-information into data sink data to execute a data source data-related transaction in the data sink; and,f) uploading the data sink data to the data sink.

2. The method according to claim 1, wherein the transfer data is onloaded and offloaded via a wireless data connection the wireless data connection being a Near Field Communication (NFC) connection or a Bluetooth (BT) connection or a Wireless Local Area Network (WLAN) connection.

3. The method according to claim 1, wherein the transfer data is onloaded and offloaded via a wired data connection the wired data connection being a Universal Serial Bus (USB) connection.

4. The method according to one of the claim 1, wherein the transfer-data-carrier is either a wireless device, the wireless device being a smartphone or a tablet, assignable to a human or robot and thereby used for being carried along a walkway of the business premises between the data source and the data sink, or a drone to overcome a spatial distance between the data source and the data sink, which includes a wireless device.

5. The method according to claim 1, wherein the transfer-data-carrier is a Wireless-Mesh-Network (WMN) with wireless cells based on “Wireless Local Area Network <WLAN>”-cells or “Bluetooth <BT>”-cells.

6. The method according to claim 1, wherein a Condition Based Service or a Condition Based Maintenance (CBS) scenario according to which within the business premises the data source is an asset or device, a motor, a drive, a valve, or a pump, and the data sink is a maintenance system or a service system.

7. The method according to claim 1, wherein a displaying machine status: scenario, according to which within the business premises the data source (DSC) is a dashboard and the data sink is a central monitoring station.

8. The method according to claim 1, wherein scenario updating firmware, configuration changes or non-real-time-critical commands, according to which within the business premises the data source is an update-database and the data sink is a device to be updated.

9. The method according to claim 1, wherein a data analytics scenario, according to which within the business premises the data source is a machine or device generating various kind of data to be analyzed and the data sink is a central location for running the analysis.

10. A Data-Transfer-System for transferring data between a data source and a data sink, by which the data source and the data sink are spaced from each other within a business each including an IT-System, in the data source there are data source data destined for the data sink and a data connection for the data transfer between the data source and the data sink is non-existing, the Data-Transfer-System comprising: whereina) a download unit including: a1) a downloading component for downloading (dwl) the data source data from the data source,a2) a configuring component for configuring the data source data by packing the data source data with data source-related meta-information), encrypting the packed data source data and storing the configured data source data as transfer data the transfer, anda3) an onload component for onloading (onl) the stored transfer data; b) a transfer-data-carrier including:b1) a nearby detection component detecting when the transfer-data-carrier is in a transmission range to the download unit for receiving the stored transfer data from the download unit,b2) a transfer component to receive the onloaded transfer data on the transfer-data-carrier and to offload the transfer data for an offload operation from the transfer-data-carrier, andb3) the nearby detection component for detecting when the offload operation can be carried out;c) an upload unit including: c1) an offload component to receive the transfer data when according to the detection of the nearby detection component the upload unit is in a further transmission range to the transfer-data-carrier for carrying out the offload operation,c2) a processing component for processing the offloaded transfer data by decrypting and unpacking the configured data source data and transforming the decrypted and unpacked data source data with the meta-information into data sink data to execute a data source data-related transaction in the data sink, andc3) an uploading component for uploading the data sink data to the data sink.

11. The Data-Transfer-System according to claim 10, wherein the download unit and the upload unit include each at least one wireless port, wherein the onload component and the offload component use the wireless ports for onloading and offloading the transfer data according to a wireless data connection.

12. The Data-Transfer-System according to claim 10, wherein the download unit and the include each a wired port, wherein the onload component and the offload component the wired ports for onloading and offloading (ofl) the transfer data according to a wired data connection.

13. The Data-Transfer-System according to claim 10, wherein the transfer-data-carrier is either a wireless device, the wireless device being a smartphone or a tablet, assignable to a human or robot and thereby used for being carried along a walkway of the business premises between the data source and the data sink, or a drone to overcome a spatial distance between the data source the data sink, which includes a wireless device, wherein the wireless device includes at least one wireless port, orat least one wireless port and a wired port, such thatthe nearby detection component uses the wireless port either for detecting when the transfer-data-carrier is in the transmission range to the download unit or for detecting when the transfer-data-carrier in the further transmission range to the upload unit andthe transfer component uses either the wireless port or the wired port for receiving the transfer data and the offload operation for offloading the transfer data.

14. The Data-Transfer-System according to claim 10, wherein the nearby detection component and the transfer component of the transfer-data-carrier are formed as a transfer-data-carrier-related computer-implemented-tool, which when being assigned to the transfer-data-carrier by an upload of the transfer-data-carriers related computer-implemented-tool and thus embedded into a transfer-data-carrier provided custom software execution container uses either the wireless port or the wired port of the wireless device for receiving the transfer data and the offload operation for offloading the transfer data.

15. The Data-Transfer-System according to claim 10, wherein the transfer-data-carrier is a Wireless-Mesh-Network with wireless cells, based on Wireless Local Area Network-cells or Bluetooth (BT)-cells, wherein the wireless cells of the Wireless-Mesh-Network are set up by at least one download unit and at least one unit.

16. The Data-Transfer-System according to claim 10, wherein the downloading component includes a wired data source interface to the data source and the uploading component includes a wired data sink interface the data sink.

17. The Data-Transfer-System according to claim 10, the downloading component, the configuring component and the onload component of the download unit are formed as a data source related computer-implemented-tool, which when being assigned to the data source by an upload of the data source-related computer-implemented-tool and thus being embedded into a data source-provided custom software execution container, onloads the stored transfer data either according to a wireless data communication or to a wired data communication, and/orthe offload component, the processing component and the uploading component of the Upload-Unit are formed as a data sink related computer-implemented-tool, which when being assigned to the data sink by an upload of the data sink-related computer-implemented-tool thus being embedded into a data sink-provided custom software execution container as well as to carry out the offload operation receives the stored transfer data either according to a wireless data communication, or to a wired data communication.

18. The Data-Transfer-System according to claim 10, wherein a Condition Based Service or a Condition Based Maintenance (CBS)-scenario according to which within the business premises the data source is an asset or device, the device being a motor, a drive, a valve, or a pump, and the data sink is a maintenance system or service system.

19. The Data-Transfer-System according to claim 10, wherein a displaying machine status scenario, according to which within the business premises the data source is a dashboard, and the data sink is a central monitoring station.

20. The Data-Transfer-System according to claim 10, wherein a scenario including updating firmware, configuration changes or non-real-time-critical commands, according to which within the business premises the data source is an update-database, and the data sink is a device to be updated.

21. The Data-Transfer-System according to claim 10, wherein a data analytics-scenario, according to which within the business premises the data source is a machine or device generating various kind of data to be analyzed and the data sink is a central location for running the analysis.