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.
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
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 ASc or devices DVc, the second group includes unconnected assets ASuc or devices DVuc.
The connected assets ASc or devices DVc 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 ASc or devices DVc, 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:
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
To carry out the “Condition Based Service or Condition Based Maintenance <CBS>”-scenario it is necessary that the assets ASc or devices DVc 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
So, a wireless transmission over wide ranges (e.g. ranges above 20 meters) is typically not feasible because of
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 ASuc or devices DVuc 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 ASuc or devices DVuc 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
These unconnected assets ASuc or devices DVuc 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 ASuc or devices DVuc 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 ASuc or devices DVuc 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
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 ASuc or devices DVuc 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 ASuc or devices DVuc a typical practice is to send a human to the unconnected assets ASuc or devices DVuc. 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 ASuc or devices DVuc would be required.
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
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
Additionally by allowing the preferred “Condition Based Service or a Condition Based Maintenance <CBS>”-scenario on the assets or devices has the following advantages
The proposed solution has furthermore the following benefits:
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.
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
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:
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:
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
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.
Some of the embodiments will be described in detail, with reference to the following figures, wherein like designations denote like members, wherein:
As according to the
The Data-Transfer-System DTFS is now provided to enable the unconnected assets ASuc or devices DVuc 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 ASuc or device DVuc 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
At this point in the context of describing the
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
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
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
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.
As already mentioned, (cf.
Furthermore also already mentioned (cf.
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 ASuc or device DVuc 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 WRIFDSC, WRIFDLD the data source data DSCD from of the data source DSC respectively the unconnected asset ASuc or device DVuc.
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
The encryption of the packed data for the data transfer is done due to the following reasons:
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
The “data source”-related computer-implemented-tool CITDSC 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 WRIFDSC, WRIFDLU used for the DSCD-download are replaced by one wired interface WRIF, which as part of the unconnected asset ASuc or device DVuc respectively the data source DSC is assigned to a “data source”-provided custom software execution container CSECDSC on the unconnected asset ASuc or device DVuc 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 ASuc or device DVuc respectively the data source DSC are also assigned to the “data source”-provided custom software execution container CSECDSC on the unconnected asset ASuc or device DVuc respectively the data source DSC.
The “data source”-provided custom software execution container CSECDSC 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 ASuc or device DVuc 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 CITDSC is an APP and which when being uploaded via a first software-interface-port SWIP1 as part of the unconnected asset ASuc or device DVuc respectively the data source DSC from a software repository SWRP is embedded into the “data source”-provided custom software execution container CSECDSC.
Being embedded in the “data source”-provided custom software execution container CSECDSC the “data source”-related computer-implemented-tool CITDSC 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 ASuc or device DVuc and to enable the aforementioned onload operation.
Now, the “data source”-related computer-implemented-tool CITDSC 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 CITDSC 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 ASuc or device DVuc.
Then within the “data source”-related computer-implemented-tool CITDSC 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 CITDSC 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 CITDSC such that the downloaded data source data DSCD is passed to the processor PRC′CFGC, which
Finally within the “data source”-related computer-implemented-tool CITDSC 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
As already mentioned, (cf.
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.
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.
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.
For this purpose the transfer component TFC includes a processor PRCTFC, a Data-Input-Output-Interface DIOIF and a local persistence LPSTFC, 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 PRCTFC, which temporary stores the onloaded transfer data TFD in local persistence LPSTFC 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.
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.
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 PRCTFC to enable the onload operation or the offload operation.
Also (cf.
As already mentioned, (cf.
Furthermore also already mentioned (cf.
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 PRCC 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.
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 PRCPRCC 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 PRCCFGC, which
Finally the upload component UPLC uploads upl via the wired interfaces WRIFDSN, WRIFULU the data sink data DSND to the data sink DSN respectively the maintenance system MSY or service system SSY.
The “data sink”-related computer-implemented-tool CITDSN replacing essentially the Upload-Unit ULU takes over the tasks of the offload component OFLC, the processing component PRCC and the uploading component UPLC carried out in the Upload-Unit ULU, while the wired interfaces WRIFDSN, WRIFULU 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 CSECDSN 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 CSECDSC on the maintenance system MSY or service system SSY respectively the data sink DSN.
The “data sink”-provided custom software execution container CSECDSN 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 CITDSN 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 CSECDSN.
Being embedded in the “data sink”-provided custom software execution container CSECDSN the “data source”-related computer-implemented-tool CITDSN 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 CITDSN 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 CITDSN the offload component OFLC, when according to the detection of the nearby detection component (cf.
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 CITDSN 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 CITDSN such that the offloaded transfer data TFD is passed to the processor PRC′CFGC, which
Finally within the “data sink”-related computer-implemented-tool CITDSN the upload component UPLC uploads upl via the wired interfaces WRIFDSN, WRIFULU 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.
Number | Date | Country | Kind |
---|---|---|---|
20199409.2 | Sep 2020 | EP | regional |
This application claims priority to PCT Application No. PCT/EP2021/076751, having a filing date of Sep. 29, 2021, which claims priority to EP Application No. 20199409.2, having a filing date of Sep. 30, 2020, the entire contents both of which are hereby incorporated by reference.
Filing Document | Filing Date | Country | Kind |
---|---|---|---|
PCT/EP2021/076751 | 9/29/2021 | WO |