Systems, devices, methods, and data stacks for managing applications that govern management of asset operations

Abstract

Systems, devices, methods, and data stacks for managing applications that govern operations of assets are disclosed. The method discloses sharing data between applications (102, 104). The method includes generating, by a first application (102, 310) of the applications (102, 104), one or more metadata stacks (200) associated with one or more assets (160, 162, 164, 179, 180), wherein the metadata stacks (200) include at least one metadata string generated based on an operation of the assets (160, 162, 164, 179, 180); and allowing access to the metadata stacks (200), whereby a second application (104, 320) of the applications (102, 104) is able to access the metadata stacks and data points associated with the metadata stacks.

Description

Technical Field

[0001] This disclosure primarily relates to the management of asset applications, specifically the management of data by these applications. Background Technology

[0002] With the emergence of cloud computing and edge / fog computing technologies, a large number of devices are connected to cloud computing or fog computing platforms via wired / wireless networks. These devices can be equipment, sensors, actuators, robots, and machinery in industrial settings. They can also be medical devices and equipment in the healthcare sector. Furthermore, they can be communication equipment, home appliances, or office supplies in residential / commercial settings. These devices are often referred to as "assets."

[0003] Cloud computing and fog computing platforms can host multiple applications for configuring, monitoring, controlling, and maintaining connected assets. In some cases, a single controller can be used to run the applications, thereby managing the operation of the assets.

[0004] Typically, applications may provide different services when operating on the same data point or the same series of data points. Sharing data points across multiple applications can pose challenges to obtaining meaningful results. Such systems and methods can benefit from improvements. Summary of the Invention

[0005] Various disclosed embodiments include systems, devices, methods, and data stacks to facilitate application management by managing data sharing between applications.

[0006] In one example, a method for sharing data between at least two applications is disclosed. Through the operation of at least one processor, the method includes: a first application among the at least two applications generating one or more metadata stacks associated with one or more assets, wherein the metadata stacks include at least one metadata string generated based on asset operations; and allowing the first application to access the metadata stacks, thereby enabling a second application among the at least two applications to access the metadata stacks and data points associated with the metadata stacks.

[0007] In another example, a computing platform for managing at least two applications includes: a shared service between the at least two applications in a distributed computing environment, wherein the shared service is configured to allow access to at least one metadata stack generated by a first application of the at least two applications, wherein the applications are configured to use the computing platform to manage operations of at least one asset, and wherein the metadata stack includes at least one metadata string generated based on the asset's operations.

[0008] In another example, a device for managing at least two applications includes: a firmware module including an operating system, the operating system including one or more native tools configured to execute at least one command, wherein the command may include one of a copy command, a paste command, and a cut command; a first application among the at least two applications is used to: generate at least one metadata stack associated with operational data of an asset; wherein the first application uses native tools to allow access to the operational data via the metadata stack, wherein the metadata stack includes at least one metadata string generated based on the asset's operations.

[0009] In yet another example, a metadata stack for managing at least two applications includes one or more metadata strings associated with at least one asset, wherein the metadata strings include at least one of the following: an asset identifier; a timestamp; and a unique identifier that can be referenced by one or more applications.

[0010] Another example could include a non-transitory computer-readable medium encoded with executable instructions (such as software components on a storage device) that, when executed, cause at least one processor to perform the described method.

[0011] Before describing the proposed agreement in more detail, it should be understood that various definitions of certain words and phrases are provided throughout the patent document, and those skilled in the art should understand that these definitions apply to numerous (if not most) instances of prior and future use of such words and phrases. While some terms may include multiple embodiments, the appended claims may expressly limit these terms to specific embodiments. It should also be understood that features explained in the context of the proposed method may also be included in the proposed system by appropriate configuration and adaptation of the system, and vice versa.

[0012] As used in this article, "metadata" refers to data that describes heterogeneous data streams. Metadata can be labels that add meaning to one or more data points in a heterogeneous data stream. Examples of metadata include unique identifiers, asset types, firmware versions, warranty versions, antivirus software, security certificates, software patches, and / or asset components. For example, metadata can be generated using various annotation techniques. In another example, metadata can be generated by performing sensitivity analysis on data points in a heterogeneous data stream. In yet another example, metadata can be learned autonomously using correlation networks.

[0013] As used herein, an application refers to a software program designed to provide a specific function or service. Applications can be interactive or non-interactive. An application can be executed / run on the same device or on different devices at different times. Example applications may include applications for monitoring robot operations in a manufacturing facility. An application may be able to analyze data collected from the robot over a period of time. Another application may be related to the detection of anomalies in robot operations. Both condition monitoring applications and anomaly detection applications can use the same operational data related to the robot.

[0014] Copying data from one application to another may result in the duplication of individual data points. Furthermore, the first application may not necessarily use operational data in a continuous time-series format (also known as time series data). In one example, an anomaly detection application might require a predetermined amount of training data to learn operational conditions associated with an asset. In this case, a considerable period, such as two months, might be needed to understand the operational conditions. In some cases, it is preferable to use only a few data points from two months of time-series data. For example, fault data may not be the preferred training data, considering faults associated with the asset. Therefore, the present invention excludes fault data when generating the metadata stack. Consequently, the present invention advantageously assembles relevant data points, which may be discontinuous and may span multiple assets. Therefore, the present invention advantageously allows for the accumulation of observations across multiple applications without the need for manual searching and selection within each application.

[0015] Furthermore, this invention advantageously allows applications to reference data points between applications without explicitly calling the data points. Within an application, such as a condition monitoring application, selected data points can be used by an outlier detection application using the metadata stack.

[0016] The metadata stack is shared or referenced by applications, and there is an m:n (many-to-many) relationship between the applications and the metadata stack. By sharing the metadata stack, applications use the same metadata stack, ensuring semantically correct responses. This invention allows two or more applications to analyze the same data points without having to send all the data points, thus saving computational and network assets.

[0017] In one embodiment, a metadata stack is generated by identifying metadata strings of interest associated with an asset. These metadata strings comprise data points generated from data sensing and monitoring devices associated with the asset. For example, metadata strings might include sensor data from assets in an industrial plant. Furthermore, for referenceability, the metadata strings are associated with unique identifiers. Therefore, the metadata stack can be considered an aggregation of data points of interest from time-series sensor data.

[0018] In one example, a metadata string can be generated by an operator when collecting suspicious data points. The attributes of the data points are used to generate the metadata string, thus creating a metadata stack. This metadata stack can be shared with domain experts. In another example, operators and domain experts might want to analyze multiple data points from operations across multiple assets to identify common anomalies. In yet another example, domain experts can identify regions of interest within the distribution of time-series sensor data. These regions of interest can be used to generate a metadata stack. Furthermore, correlated data points can be accumulated based on the metadata stack.

[0019] In one embodiment, the metadata string is identified by allowing selection of data points of interest within the operational data. Furthermore, a metadata string is generated including attributes of the selected data point, such as an asset identifier, the asset's asset status, and a timestamp of the event. The selection can be made using a graphical user interface (GUI) that allows an operator / user to select the data point. Data points can be selected based on user interest and / or events associated with the asset. Those skilled in the art will understand that the term "operator / user" refers not only to humans but can also include machines or humanoid organisms capable of selecting data points of interest.

[0020] In one embodiment, the selection of data points can be automated based on events. As used herein, events include the occurrence of anomalies or the occurrence of predetermined conditions. In some cases, unknown anomalies can be identified by a condition monitoring application using pattern recognition algorithms. Therefore, the condition monitoring application selects data points to create metadata strings. Furthermore, the condition monitoring application may be able to identify data points representing events based on predetermined thresholds.

[0021] As used herein, a predetermined threshold may include the number of data points before and after event detection. An example of a predetermined threshold could be 100 data points before and after event detection. In another example, the predetermined threshold could include 100 data points before event detection. The identified data points can be used to simulate an event and are selected against the metadata stack based on the simulation. When data points are identified in the first application, the simulation of the event can be performed on the shared service.

[0022] In one embodiment, the metadata stack may further include access policies instructing applications accessing the metadata stack. Additionally, the metadata stack may include organizational information associated with assets. In one embodiment, the metadata stack may include flags indicating that one or more contents of the metadata stack have been modified. Furthermore, the metadata stack may include the location where operational data is generated and the location where operational data is stored.

[0023] After the metadata stack is generated, it becomes available for reference and / or use by applications. In one embodiment, the metadata stack can be referenced or made accessible by publishing the metadata string to a shared service between the first and second applications. As used herein, the shared service includes a central service hosted on a computing platform and / or native tools of the operating systems of the first and second applications. The shared service can be configured with commands such as create, read, update, and delete.

[0024] In one embodiment, the sharing service can be configured to receive a publish request from a first application to publish the metadata stack. Furthermore, the sharing service can be configured to receive access requests from a second application within at least two applications. Additionally, the sharing service can be configured to add intelligence to the metadata stack. For example, the sharing service can list common parameters of assets referenced in the metadata stack. Furthermore, the sharing service can be configured with application programming interface (API) functionality to retrieve data points referenced in the metadata stack. Moreover, the sharing service is configured to update existing API functionality to identify non-contiguous data points associated with individual assets.

[0025] The computing platform for managed shared services can be a cloud computing platform or a fog computing platform. The cloud computing platform includes an operating system that connects to, collects, and derives context from the operational data of the assets. Applications can be hosted on the cloud computing platform to visualize operational data in real time and generate analytics results in a centralized location. The fog computing platform can include condition monitoring applications that can interact with applications on the cloud computing platform. For example, a condition monitoring application can allow for simplified engineering design for data analytics applications hosted on the cloud computing platform. The metadata stack can be generated using condition monitoring applications on the fog computing platform and can be used by data analytics applications hosted on the cloud computing platform.

[0026] As used herein, “cloud computing” refers to a processing environment that includes configurable computing entities and logical assets, such as networks, servers, storage devices, applications, services, etc., and data distributed across a network, such as the Internet. Cloud computing systems provide on-demand network access to a shared pool of configurable computing entities and logical assets. A network is, for example, a wired network, a wireless network, a communication network, or any combination of these networks.

[0027] As used in this article, "fog computing" refers to a network of edge devices within a facility that can act as gateways to cloud computing platforms. Edge devices can be lightweight, low-cost devices that collect, store, and buffer data from various sensors and actuators deployed throughout the factory, analyze the collected data, and perform actions (e.g., issue control commands) based on the analysis results. Edge devices can also be configured to aggregate, filter, selectively report, compress, encrypt, and / or otherwise preprocess factory data, thereby reducing the amount of data and / or value-added data communicating with IoT cloud platforms. This can result in less network communication and backend storage and processing resources being used than would likely be required or used without such preprocessing. Typically, each of the edge devices can perform these functions using one or more software applications deployed within them.

[0028] Some applications are configured to use a metadata stack as their input for execution. In some cases, the metadata stack can be configured to restrict the operations that can be performed using it. In other cases, the metadata stack may contain insufficient data points for some applications. The determination of whether the metadata stack is valid input or contains sufficient data points for a given application can be made using a shared service. A shared service can be configured to allow a second application to determine whether the metadata stack is suitable for execution through simulation (also known as a no-run) without accessing the referenced data points (i.e., the data points associated with the metadata stack). Therefore, the shared service allows a second application to understand whether the metadata stack is valid input. When the metadata stack is not suitable for the full execution of the second application, access to these data points is provided.

[0029] Shared services act as a connection between different applications. Consider the example of a first application and a second application, where shared services can be accessed via a GUI. The GUI can be generated by a display device that allows users to access and modify the metadata stack. In one embodiment, shared services are indicated as items in the toolbars of both the first and second applications. For example, a shared service could be represented by a shopping cart indicating a list of accessible metadata stacks. Characteristics of the GUI can be modified to indicate the availability of the metadata stack. Examples of modification could include flashing / blinking or color changes to items in the toolbar.

[0030] In one embodiment, the shared service is configured to indicate the active metadata stack to the application. As used herein, the active metadata stack refers to the metadata stack available in a given session active between the first and second applications. For example, the metadata stack available in a toolbar item can be considered the active metadata stack. Furthermore, both the first and second applications are capable of modifying the contents of the active metadata stack. In some scenarios, either the first or second application may be able to use the shared service to change the state of the metadata stack from active to inactive, and vice versa.

[0031] In some embodiments, a first application and a second application can be used to generate metadata strings. Data points of interest can be selected by operating the first and second applications within the same session. The metadata strings are generated based on the data points of interest. During the session, a metadata stack can be generated by associating the metadata strings with unique identifiers. The metadata stack can be open for modification by both the first and second applications. Both the first and second applications can modify the metadata strings within the metadata stack. In this case, the metadata stack can be considered active.

[0032] In one embodiment, a shared service is provided as part of the operating system for the execution of a first application and a second application. For example, the first application relates to generating correlation coefficients in operational data of an asset. The second application relates to monitoring tasks related to the asset. Both applications can execute on a device used to manage asset operations. The shared service refers to native tools within the device's operating system. These native tools are configured to execute one or more commands, such as copy, paste, and cut commands. In one example, the first application copies data points / regions of interest to the operating system's clipboard. The second application is configured to identify the metadata stack based on the data points copied to the clipboard. This invention advantageously shares observations across the first and second applications via the metadata stack without requiring manual copying and saving / pasting of referenced data points.

[0033] This invention is advantageous in distributed computing environments, particularly in cloud computing and fog computing. In distributed computing environments, microservice-based applications can replace monolithic applications. In such environments, interaction between applications can be achieved using direct API calls. However, such applications may require tight coupling and cannot be considered completely independent services. Furthermore, the user context is identical (no exchange occurs between independently operating entities). This invention enables non-interactive, independent applications to function smoothly in such distributed environments. Users and application developers can use discontinuous data within applications and share this data with other users / applications. The metadata stack can also be used to design applications so that data can be shared seamlessly.

[0034] The technical features of this disclosure have been summarized quite broadly above to enable those skilled in the art to better understand the detailed description that follows. Additional features and advantages of this disclosure that form the subject matter of the claims will be described below. Those skilled in the art will understand that they can readily use the disclosed concepts and specific embodiments as the basis for modifying or designing other structures to achieve the same purpose of this disclosure. Those skilled in the art will also recognize that such equivalent constructions do not depart from the scope of the broadest form of this disclosure. Attached Figure Description

[0035] The invention will be described below using embodiments shown in the accompanying drawings.

[0036] Figure 1 A system and device for managing an application, configured to manage operations associated with assets, are illustrated according to an embodiment of the present invention.

[0037] Figure 2 The metadata stack according to an embodiment of the present invention is shown;

[0038] Figure 3 A graphical user interface (GUI) for managing an application is shown according to an embodiment of the present invention, the GUI being configured to manage operations associated with assets;

[0039] Figure 4 A flowchart illustrating an example method for managing data between applications according to an embodiment of the present invention is shown; and

[0040] Figure 5 A flowchart illustrating an example method for managing data between applications according to an embodiment of the present invention is shown. Detailed Implementation

[0041] Hereinafter, embodiments for carrying out the invention are described in detail. Various embodiments are described with reference to the accompanying drawings, wherein the same reference numerals are used throughout to refer to the same elements. In the following description, numerous specific details are set forth for purposes of explanation in order to provide a thorough understanding of one or more embodiments. It will be apparent that these embodiments may be practiced without these specific details.

[0042] Figure 1 A system 100 and device 130 for managing applications 102 and 104 are illustrated according to an embodiment of the present invention. The applications are configured to manage operations associated with assets 160, 162, 164, 170, and 180. Assets 160, 162, 164, 170, and 180 may be equipment, actuators, robots, or machinery in industrial settings. These devices may be medical devices and apparatuses in healthcare settings. These devices may be household appliances or office supplies in residential / commercial settings. The operations of assets 160, 162, 164, 170, and 180 can be measured using sensors and are referred to herein as operational data comprising one or more data points.

[0043] Assets 160, 162, 164, 170, and 180 are managed using applications 102 and 104. Example applications may include condition monitoring applications, anomaly detection applications, event management applications, design and configuration applications, cluster management applications, etc. Applications 102 and 104 may execute on separate devices 140 and 150, respectively. In another embodiment, applications 102 and 104 may execute on device 130 having an operating system 132.

[0044] System 100 includes a cloud computing platform 110 that hosts a shared service 120. The shared service 120 is used to transfer a metadata stack between applications 102 and 104. The metadata stack includes attributes associated with one or more consecutive or non-consecutive data points in the operational data of at least one of assets 160, 162, 164, 170, and 180.

[0045] The metadata stack can be generated by one or both of applications 102 and 104. For example, application 102 generates the distribution of operational data for asset 162. Further, application 104 generates the distribution of operational data for asset 164. The metadata stack can be generated by identifying regions of interest in the distribution of operational data associated with asset 162.

[0046] Shared service 120 can be configured with features such as create, read, update, and delete to enable the generation of a centrally managed metadata stack from areas of interest or by selecting data points of interest. In some embodiments, shared service 120 can be configured to provide additional parameters based on the metadata stack. Example parameters include a list of common attributes of assets in the metadata stack. For example, if operational data for assets 162 and 164 is referenced in the metadata stack, shared service 120 can additionally add parameters related to asset 160, which is communicatively coupled to assets 162 and 164.

[0047] Furthermore, shared service 120 may be configured with an application programming interface (API) to retrieve operational data referenced in the metadata stack. Additionally, shared service 120 may be configured with an API to extract operational data associated with more than one asset, such as assets 162 and 164. When the metadata stack is to be used to execute application 102 or 104, shared service 120 may be configured to provide a simulation environment to run application 102 or 104 idle to check if the metadata stack is suitable for application 102 or 104.

[0048] The contents of the metadata stack can be used to determine whether the metadata stack is suitable for the application. The contents of the metadata stack are described below. Figure 2 A metadata stack 200 according to an embodiment of the present invention is shown. The metadata stack 200 includes a metadata string 210, an asset identifier 220, a timestamp 230, and a unique identifier 240.

[0049] Metadata string 210 includes data points from operational data generated from sensors associated with assets 160, 162, 164, 170, and 180. For example, the metadata string includes operational data for asset 170 in a time series from a first time instance to a second time instance. Metadata string 210 can be generated by an operator when collecting suspicious data points from operational data of more than one asset, such as assets 160, 162, and 164. The attributes of the data points are used to generate metadata string 210, thereby generating metadata stack 200.

[0050] The asset identifier 220 provides an indication of the asset referenced in the metadata stack 200. For example, the asset identifier 220 may also include the asset type and model. For instance, asset 170 is a turbine and asset 180 is a pump. The asset identifier 220 may include identifiers for assets 170 and 180, the asset type (turbine and pump), and the model number of the turbine and pump. In some embodiments, the asset identifier 220 may also include information about the manufacture and design of assets 160, 162, 164, 170, and 180.

[0051] Timestamp 230 is used to identify when the metadata stack was generated. Timestamp 230 can be used to manage multiple versions of metadata stack 200. In addition, a unique identifier 240 is provided to allow easy referencing of metadata stack 200 across applications 102 and 104.

[0052] Metadata Stack 200 enables operators to collect suspicious data points from multiple assets and share them with domain experts. It allows operators to collect data points while viewing operational data or statistical models of operational data, without exiting the application. By not restricting asset types, Metadata Stack 200 can scale to large settings with different assets. It also eliminates ambiguity, such as shared variable names across different and unrelated assets.

[0053] Furthermore, the unique identifier 240 can be used to combine a brief description of the metadata stack 200. Therefore, the meaning of the metadata stack 200 can be understood by multiple applications / users over a period of time. Thus, the metadata stack 200 can be used to obtain a preview of the referenced data points. This allows applications to determine whether the metadata stack 200 is valid input without manually downloading all referenced data points.

[0054] Figure 3 Graphical user interfaces (GUIs) 310 and 320 for an application configured to manage operations associated with an asset cluster are shown according to embodiments of the present invention.

[0055] These applications are exemplary applications related to cluster management applications / solutions and anomaly detection (AD) applications. Cluster management (FM) applications are used to monitor cluster operation data of asset clusters. FM applications can be configured to automatically issue alerts based on events identified in the cluster operation data. AD applications can be separate services invoked by FM applications to identify anomalies or abnormal patterns in cluster operation data. AD applications can detect unknown anomalies through ruleless analysis, detecting the initial signs of unknown operational data on any machine in the asset cluster.

[0056] GUIs 310 and 320 are hereinafter referred to as FM GUI 310 for FM applications and AD GUI 320 for AD applications, respectively. FM GUI 310 includes an asset field 330 indicating an asset fleet. FM GUI 310 includes a time-series chart indicating field operational data relative to time. The time-series chart is used to select data points of interest 340. Furthermore, FM GUI 310 includes a stack creation tool 360. The stack creation tool 360 includes a drop-down menu 350. The stack creation tool 360 is used to generate a metadata stack.

[0057] The AD GUI 320 indicates the pressure and temperature distribution associated with the data point of interest 340. This distribution is generated by the AD application using data defined by a metadata stack generated by the stack creation tool 360.

[0058] Those skilled in the art will understand that GUIs 310 and 320 are merely examples. The stack creation tool 360 can be instructed directly on the GUI, or it can be invoked when the user enters a command, such as copy / cut.

[0059] During operation, when the data point of interest 340 is selected, the stack creation tool 360 can be displayed at the selected location. The stack creation tool 360 enables the FM and AD applications to "understand the stack." In other words, the FM application can initiate / allow the generation of the metadata stack. In one embodiment, the user can continue generating the metadata stack by clicking on the stack creation tool 360.

[0060] In another embodiment, the FM application can be configured to determine whether data point 340 is a data point of interest. This determination can be made based on a predetermined threshold. The predetermined threshold can provide the minimum number of data points required by the metadata stack. In the case where an event is identified by the FM application, the predetermined threshold can include the number of data points before and after the event. For example, the predetermined threshold can include 100 data points before and after event detection. The identified data points can be used to simulate the event and then selected as data point of interest 340.

[0061] The metadata stack is generated by a shared service linked to the stack creation tool 360. The metadata stack is generated using data points of interest 340. The metadata stack includes metadata strings with data point of interest 340 attributes, unique identifiers, and timestamps.

[0062] The AD application is notified of the metadata stack via the stack creation tool 360 provided on the AD GUI 320. The AD application can receive an application programming interface (API) from the shared service for using the metadata stack. The AD application can directly import the metadata stack for execution. In one embodiment, a dry run of the AD application is performed using the shared service. The dry run is used to determine whether the metadata stack is valid input to the AD application. Furthermore, the dry run is used to determine whether it is necessary to download the data points of interest 340 referenced in the metadata stack. This is relevant when the creation of the metadata stack is subject to limitations imposed by the metadata stack's usage.

[0063] all in all, Figure 3The transfer of operational data for assets across heterogeneous applications, such as the FM and AD applications, is illustrated. Applications using the metadata stack are configured to determine semantically correct operations. The shared service is a stack management server, allowing the metadata stack to be retrieved even when applications are not running in the same session.

[0064] Figure 4 A flowchart 400 of an example method according to an embodiment of the present invention is shown, wherein the example method manages data between applications associated with assets within an industrial facility. The example assets are pumps and turbines. Operational data from the assets is represented by digital pumps 402, 404, and turbines 406. Furthermore, the operational data may be accompanied by asset status 408.

[0065] The method begins at step 405, detecting events in the asset management application. The operator / expert may want to understand the cause of the event. In step 410, the detected event is selected, and a copy command is initiated via / by the asset management application. For example, in step 410, the event is selected by pressing a copy command such as CTRL+C.

[0066] In step 420, the asset management application identifies the selected event. The asset management application generates a metadata string representing the event, where the metadata string includes asset identifiers for pumps 402, 404, and turbine 406 associated with the event. Furthermore, in step 420, the asset management application sends a POST request to the shared service and sends the generated metadata string. In one example, the POST request might include the following instructions:

[0067] {assets:["Turbine"],

[0068] timeRange:{

[0069] from: "2019-09-30….",

[0070] to: "2019-10-02..."}

[0071] }

[0072] Use the metadata string to generate a metadata stack and associate it with a unique identifier.

[0073] In step 430, a second application, such as a data analysis application, is used to further analyze the event. The data analysis application can initiate / allow paste operations, such as CTRL+V. Through this operation, the data analysis application learns about the metadata stack.

[0074] In step 432, it is determined whether the data analytics application is connected to a shared service hosted on the computing platform. Step 434 addresses the possibility of not being connected to a shared service on the computing platform. In step 434, native tools of the device operating system, such as the clipboard, are considered shared services. This example enables this functionality without access to the computing platform. This approach saves computing assets by copying the metadata stack instead of data points / operational data to the clipboard. For example, several gigabytes of operational data can be used to determine the event. The API provided by the metadata stack allows the data analytics application to retrieve only one aggregation (i.e., the metadata stack), reducing the data to just a few megabytes. Furthermore, the data analytics application can be configured to accept the metadata stack as valid input, thus only retrieving the metadata stack from the clipboard by default. Therefore, by sharing the metadata stack, only a small subset of the referenced operational data needs to be received.

[0075] In step 436, a shared service on the cloud computing platform is accessed. For example, a Hypertext Transfer Protocol (HTTP) Uniform Asset Locator (URL) can be used to access the shared service. Steps 434 and 436 both lead to step 438, where the data analytics application sends an HTTP GET request to the shared service (including native tools) to receive the metadata stack. A further step 438 may also include retrieving operational data referenced in the metadata stack. In step 440, the data analytics application generates a visualization based on the metadata stack and the operational data selected in step 420.

[0076] Figure 5 A flowchart 500 illustrates an example method for managing data between applications according to an embodiment of the present invention. The method begins at step 510, identifying data points of interest in operational data associated with an asset. Data points of interest associated with the asset can be identified in a first application using the operational data. For example, a domain expert can identify regions of interest in the distribution of operational data. Regions of interest are used to identify data points of interest. In another example, data points of interest can be determined based on the detection of events or anomalies in the operational data.

[0077] In step 520, the metadata stack is generated based on data points of interest. Specifically, the metadata stack is generated from metadata strings that include attributes of the data points of interest. Therefore, in step 520, a metadata string associated with the asset is generated. For example, the metadata string includes one of the device identifier, the asset's device status, and the timestamp of the event. Furthermore, for referenceability, the metadata string is associated with a unique identifier. Therefore, the metadata stack can be considered an aggregation of data points of interest in the operational data.

[0078] In step 530, the metadata stack is published to a shared service between the first application and the second application. The shared service is a public service accessible via the operating system of the device executing the first and second applications. Alternatively, the shared service can be accessed via a network that communicatively connects the first and second applications to a computing platform hosting the shared service. In one embodiment, a graphical user interface (GUI) may be generated in step 530 via a display device, allowing the first and / or second applications to access and modify the metadata stack.

[0079] In step 540, access to the metadata stack is granted, thereby enabling the first and second applications to access the metadata stack and the data points associated with it. Furthermore, GUI features can be modified to indicate that the metadata stack is accessible. Access to data points associated with / referenced in the metadata stack is based on the idle execution of the first / second application. Therefore, step 540 includes determining that the first / second application cannot be sufficiently executed using the metadata stack and, based on this determination, sending data points to the first / second application.

[0080] This invention can take the form of a computer program product comprising program modules accessible from a computer-usable or computer-readable medium storing program code for use by or in connection with one or more computers, processors, or instruction execution systems. For illustrative purposes, a computer-usable or computer-readable medium can be any device that can contain, store, communicate, propagate, or convey a program for use by or in connection with an instruction execution system, device, or apparatus. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or device or apparatus), or a signal carrier and a propagation medium that is itself a signal carrier, not included in the definition of a physical computer-readable medium, including semiconductor or solid-state memory, magnetic tape, removable computer floppy disks, random access memory (RAM), read-only memory (ROM), hard disks, and optical disks, such as optical disc read-only memory (CD-ROM), optical disc read / write, and DVD. As those skilled in the art will appreciate, the processor and program code used to implement each aspect of this technology can be centralized or distributed (or a combination thereof).

Claims

1. A method for sharing data between at least two applications (102, 104), wherein the method comprises, through the operation of at least one processor: One or more metadata stacks (200) associated with one or more assets are generated in a distributed computing environment by a first application (102, 310) of the at least two applications (102, 104), wherein the metadata stacks (200) include at least one metadata string generated based on operations on the assets; and Access to the metadata stack (200) is enabled, thereby enabling the second application (104, 320) of the at least two applications (102, 104) to access the metadata stack and the data points associated with the metadata stack. Enabling access to the metadata stack (200) includes: The metadata stack (200) is published to a shared service (120) between the first application (102, 310) and the second application (104, 320), wherein the shared service (120) includes a central service hosted on a computing platform and / or native tools of the operating systems of the first application (102, 310) and the second application (104, 320); Based on whether the second application (104, 320) can execute using the metadata stack (200) without accessing associated data points, the shared service determines that the second application (104, 320) cannot fully execute using the metadata stack (200), wherein the shared service is configured to provide a simulation environment to run the second application idle using the metadata stack, thereby checking whether the metadata stack is a valid input to the second application; and Based on the determination, the data points associated with the metadata stack (200) are sent to the second application (104, 320).

2. The method according to claim 1, wherein, Generating the metadata stack (200) associated with the asset includes: Generate at least one metadata string associated with the asset, wherein the metadata string includes attributes of data points generated from data sensing and monitoring devices associated with the asset; and Associate the metadata string with a unique identifier.

3. The method according to claim 1 or 2, wherein, Generating at least one metadata string associated with the asset includes: The selection of data points of interest is enabled via the first application (102, 310), wherein the data points are selected based on user interest and / or events associated with the asset, wherein the events include one of an anomaly occurring and a predetermined condition occurring; and Generate the metadata string that includes the attributes of the selected data point, wherein the metadata string includes one of the device identifier, the device status of the asset, and the timestamp of the event.

4. The method according to claim 3, wherein, Enabling selection of the data points includes: Based on a predetermined threshold, identify data points in the operational data that represent the event; and The data points are selected by simulating the event using the identified data points.

5. The method according to claim 1 or 2, further comprising: A graphical user interface (GUI) is generated via a display device, which enables access to and modification of the metadata stack (200) by the first application (102, 310) and / or the second application (104, 320); and Modify the GUI features (360) to indicate that the metadata stack (200) is accessible.

6. A computer-readable medium encoded with executable instructions, which, when executed, cause at least one processor to perform the method according to any one of the preceding claims.

7. A computing platform for managing at least two applications (102, 104), said computing platform comprising: A shared service (120) between the at least two applications (102, 104) in a distributed computing environment, wherein the shared service (120) is configured to enable access to one or more metadata stacks (200) generated by a first application (102, 310) of the at least two applications (102, 104), wherein the at least two applications (102, 104) are configured to manage one or more assets using the computing platform, and wherein the one or more metadata stacks (200) include at least one metadata string generated based on the operations of the assets, wherein the shared service is configured to: It is determined that the second application (104, 320) among the at least two applications cannot fully execute using the metadata stack (200), wherein, through the shared service, the metadata stack (200) is determined to be insufficiently executable based on whether the second application (104, 320) can execute using the metadata stack (200) without accessing associated data points. A simulation environment is provided to run the second application idle using the metadata stack, thereby checking whether the metadata stack is a valid input to the second application, and When the second application (104, 320) cannot fully execute using the metadata stack (200), access to data points associated with the metadata stack (200) is enabled.

8. The computing platform according to claim 7, wherein, The shared service (120) is configured as follows: Receive a publish request from the first application (102, 310) to publish the metadata stack (200). Receive an access request from the second application (104, 320) of the at least two applications (102, 104); and Enable the second application (104, 320) to access the metadata stack (200).

Images