System, Device, Method and Datastack for managing applications that manage operation of assets

The present disclosure is directed, in general, to the management of applications for assets and specifically to managing data by the applications.

With advent of cloud computing technology and edge/fog computing technology, a large number of devices are connected to a cloud computing platform or a fog computing platform via the wired/wireless network. For example, the devices can be equipments, sensors, actuators, robots, machinery in an industrial set-up (s). The devices can be medical devices and equipments in a healthcare unit. The devices can be communication devices, home appliances or office appliances in a residential/commercial establishment. The devices are also commonly known as 'assets'.

The cloud computing platform and fog computing platform may host multiple applications for configuring, monitoring, controlling, and maintaining connected assets. In certain scenarios, a single controller may be used to run the applications and thereby manage operation of the assets.

Generally, the applications may provide different services while operating on the same datapoints or same series of datapoints. Sharing datapoints across multiple applications may pose challenges in arriving at meaningful results. Such systems and methods may benefit from improvements.

Variously disclosed embodiments include system, device, method and datastack to facilitate management of applications by managing sharing of data between the applications.

In an example, a method for sharing data between at least two applications is disclosed. The method comprises, through operation of at least one processor: generating by a first application, of the at least two applications, one or more metadata stacks associated with one or more assets, wherein the metadata stacks include at least one metadata string generated based on the operation of the assets; and enabling access to the metadata stacks by the first application, whereby a second application, of the at least two applications, is capable of accessing the metadata stack and datapoints associated with the metadata stack.

In another example, a computing platform for managing at least two applications, the computing platform comprising: a shared service between the at least two applications in a distributed computing environment, wherein the shared service is configured to enable access to at least one metadata stack generated by a first application of the at least two applications, wherein the applications are configured to manage operation of at least one asset using the computing platform and, wherein the metadata stack includes at least one metadata string generated based on the operation of the assets.

In another example, a device for managing at least two applications, the device comprising: a firmware module comprising: an operating system including one or more native tools configured to perform at least one command, wherein the command may include one of a copy command, a paste command and a snip command; a first application of the at least two applications to: generate at least one metadata stack associated with operation data of the asset; wherein the first application enables access to the operation data via the metadata stack using the native tools and wherein the metadata stack includes at least one metadata string generated based on the operation of the assets.

In yet another example, a metadata stack for managing at least two applications one or more metadata strings associated with at least one asset, wherein the metadata strings comprise at least one of: asset identifier; and timestamp; and a unique identifier that is referenceable by one or more applications.

A further example may include a non-transitory computer readable medium encoded with executable instructions (such as a software component on a storage device) that when executed, causes at least one processor to carry out this described method.

Before describing the suggested convention in more detail, it should be understood that various definitions for certain words and phrases are provided throughout this patent document, and those of ordinary skill in the art will understand that such definitions apply in many, if not most, instances to prior as well as future uses of such defined words and phrases. While some terms may include a wide variety of embodiments, the appended claims may expressly limit these terms to specific embodiments. It should also be appreciated that features explained in the context of the suggested method may also be comprised by the suggested system by appropriately configuring and adapting the system and vice versa.

As used herein "metadata" refers to data that describes the heterogenous data streams. The metadata may be tags that add meaning to one or more data points in the heterogenous data streams. Metadata examples include unique identification number, type of asset, firmware version, warranty version, anti-virus software, security certificates, software patches, and/or components of the asset. For example, the metadata are generated using multiple annotation techniques. In another example, the metadata may be generated by performing a sensitivity analysis on the data points in the heterogenous data streams. In yet another example, the metadata may be autonomously learnt using associative networks. As used herein, applications refer to software programs that are used to provide a particular function or service. The applications may be interactive or non-interactive. The applications may be executable/executed on the same device or on different devices at different time instants. Example applications may include an application for monitoring operation of robots in a manufacturing facility. The application may be capable of analyzing the data collected from the robots over a period of time. Another application may be related to anomaly detection in the operation of robots. Both the condition monitoring application and the anomaly detection application may use the same operation data associated with the robots.

Copying of data from one application to another may result in copying of individual datapoints. Further, the first application may not necessarily use the operation data in contiguous time-series form (also referred as time-series data). In an example, an anomaly detection application may need a predetermined amount of training data to learn operating conditions associated with the assets. In this scenario, it may take considerable amount of time such as two months to learn the operating conditions. In certain circumstances it may be preferable to use only few datapoints from the two months of the time-series data. For example, consider that there was a failure associated with the assets, failure data may not be preferred as training data. Accordingly, the present invention excludes the failure data while generating the meta data stack. Therefore, the present invention advantageously assembles datapoints of interest, which may not be contiguous, and which may span over multiple assets. Therefore, the present invention advantageously enables accumulation of observations across multiple applications without manual search and selection in the individual applications.

Further, the present invention advantageously enables the applications to reference the datapoints between the applications without explicitly calling the datapoints. The datapoints selected in one application, for example, the condition monitoring application can be consumed by the outlier detection application using the metadata stack.

The metadata stack is shared or referenced by the applications with m:n (many to many) relationship between the application and the metadata stack. By sharing the metadata stacks, semantically correct response of the applications is assured with the same metadata stack used by the applications. The present invention enables two or more applications to analyse the same datapoints without having to transmit all the datapoints. Thereby, saving computing and network resources.

In an embodiment, the metadata stack is generated by identifying the metadata string of interest associated with the assets. The metadata string comprises the datapoints generated from data sensing and monitoring devices associated with the assets. For example, the metadata string comprises sensor data of the assets in an industrial plant. Further, for referencability, the metadata string is associated with a unique identifier. Accordingly, the metadata stack may be considered as an aggregation of datapoints of interest in timeseries sensor data.

In an example, the metadata string may be generated by an operator while collecting suspicious datapoints. Properties of the datapoints are used to generate metadata string and thereby the metadata stack. This metadata stack may be shared with a domain expert. In another example, the operator and the domain expert may want to analyze multiple datapoints from operation of multiple assets to determine a common anomaly. In yet another example, the domain expert may identify areas of interest in a distribution of the time- series sensor data. These areas of interest may be used to generate the metadata stack. Further, associated datapoints may be accumulated based on the metadata stack. In an embodiment, the metadata string is identified by enabling selection of datapoints of interest in the operation data. Further, the metadata string comprising properties of the selected datapoints is generated to include the asset identifier, the asset state of the assets and time stamp of the event. The selection may be made using a Graphical User Interface (GUI) that enables an operator/user to select the datapoints. The datapoints may be selected based on user interest and/or an event associated with the assets. It will be appreciated by a person skilled in the art that the term operator/user does not refer only to human and may include machine or humanoid that are able to select the datapoints of interest.

In an embodiment, the selection of datapoints may be done automatically based on the event. As used herein, the event includes occurrence of an anomaly or occurrence of a predetermined condition. In certain scenarios, an unknown anomaly may be identified by condition monitoring application using pattern recognition algorithms. Accordingly, the condition monitoring application selects the datapoints for the creation of the metadata string. Further, the condition monitoring application may be able to identify the datapoints that represent the event based on a pre-determined threshold.

As used herein, the predetermined threshold may include the number of datapoints that precede and follow the event detection. Example of the predetermined threshold may include 100 of datapoints before and after the event detection. In another example, the predetermined threshold may include 100 datapoints prior to event detection. The identified datapoints may be used to simulate the event and selected for the metadata stack based on the simulation. Simulation of the event may be performed on the shared service when the datapoints are identified in the first application.

In an embodiment, the metadata stack may also include access policies indicating the applications that access to the metadata stack. Also, the metadata stack may include organization information associated with the assets. In an embodiment, the metadata stack may include a flag to indicate one or more contents of the metadata stack have been changed. Further, the metadata stack may include a generated location of the operation data and a stored location of the operation data.

After the metadata stacks are generated, they are available for the applications for referencing and/or consumption. In an embodiment, the metadata stack may be referenced or made accessible by publishing the metadata string to the shared service between the first application and the second application. As used herein, the shared service includes a central service hosted on a computing platform and/or native tools of operating system of the first application and the second application. The shared service may be configured with commands such as create, read, update and delete.

In an embodiment, the shared service may be configured to receive a publication request from the first application to publish the metadata stacks. Further, the shared service may be configured to receive an access request from a second application of the at least two applications. Furthermore, the shared service may be configured to add some intelligence to the metadata stack. For example, the shared service may list common parameters across the assets referenced in the metadata stack. Further, the shared service may be configured with an application programming interface (API) functionality to retrieve the datapoints that are referred in the metadata stack. Furthermore, the shared service is configured to update existing API functionalities to recognize non contiguous datapoints associated with a single asset.

The computing platform hosting the shared service may be either a cloud computing platform or a fog computing platform. The cloud computing platform includes an operating system that connects, collects and gets context from the operation data of the assets. Applications may be hosted on the cloud computing platform to visualize the operating data in real-time and also generate analytic results in one centralized location. The fog computing platform may include condition monitoring application that may interact with the applications on the cloud computing platform. For example, the condition monitoring application may enable easy engineering for data analytics applications hosted on the cloud computing platform. The metadata stack may be generated using the condition monitoring application on the fog computing platform, which may be used by the data analytics applications hosted on the cloud computing platform.

As used herein, "cloud computing" refers to a processing environment comprising configurable computing physical and logical re-sources, for example, networks, servers, storage, applications, services, etc., and data distributed over the network, for example, the internet. The cloud computing system provides on-demand network access to a shared pool of the configurable computing physical and logical resources. The network is, for example, a wired network, a wireless network, a communication network, or a network formed from any combination of these networks.

As used herein, "fog computing" refers to a network of edge devices in a facility that may act as a gateway to the cloud computing platform. The edge devices may be light weight, low cost devices which collect data from various sensors and actuators deployed in a plant, store and buffer the collected data, conduct analysis of the collected data, and perform an action (e.g., issuing a control command) based on the outcome of analysis. The edge devices may also be configured to aggregate, filter, selectively report, compress, encrypt, and/or otherwise pre-process the plant data, resulting in less data and/or value added data being communicated to the IoT cloud platform. This may lead to consumption of less network communication and backend storage and processing resources than may have been required or consumed absent such pre-processing. Typically, each of the edge devices may perform the above functions using one or more software applications deployed therein.

Some applications are configured to execute using metadata stacks as their input. In certain scenarios, the metadata stacks may be configured to restrict operations that can be performed using it. In other scenarios, the metadata stacks may contain insufficient datapoints for some applications. The decision whether the metadata stacks are valid input or contains sufficient datapoints for a given application may be determined using the shared service. The shared service may be configured to enable the second application to decide whether the metadata stacks as suitable for execution without accessing the referenced datapoints (i.e. datapoints associated with the metadata stacks) by simulation (also referred as dry run). Accordingly, the shared service enables the second application to understand whether the metadata stack is a valid input. Access to the datapoints is provided when the metadata stacks is not suitable for adequate execution of the second application.

The shared service acts as a connection between the different applications. Considering the example of the first and second application, the shared service can be accessed via a GUI. The GUI may be generated through a display device that enables a user to access and modify the metadata stacks. In an embodiment, the shared service is indicated as an item in the toolbar of the first application and the second application. For example, the shared service is represented as a cart indicating the list of metadata stacks that are accessible. The features of the GUI may be modified to indicate that the metadata stacks are available. Modification examples may include flashing/blinking or change of color of the item in the toolbar.

In an embodiment, the shared service is configured to indicate active metadata stacks to the applications. As used herein, the active metadata stacks refer to metadata stacks that are available in a given session that is active between the first and second applications. For example, the metadata stacks that are available in the item of the toolbar may be considered as active metadata stacks. Further, the first and second applications are able to change the contents of the active metadata stack. In some scenarios, the first or second application may be able to change the status of the metadata stack, using the shared service, from active to inactive or vice versa.

In some embodiments, the first and second applications may be used to generate the metadata strings. The datapoints of interest may be selected by operating the first and second applications in the same session. The metadata string is generated based on the datapoints of interest. During the session, the metadata stack may be generated by associating the metadata strings with the unique identifier. The metadata stack may be open for modifications by the first and second applications. The first and second application may modify the metadata strings in the metadata stack. In such situations, the metadata stack may be considered as active.

In an embodiment, the shared service is provided part of the Operating System that is used for the execution of the first application and the second application. For example, the first application relates to generation of correlation co efficient in the operation data of the assets. The second application relates to monitoring of tasks associated with the assets. Both the applications may be executed on the device that is used for managing operation of the assets. The shared service refers to the native tools in the Operating system of the device. The native tools are configured to perform one or more commands, such as copy command, a paste command and a snip command. In an example, the first application enables the datapoints/region of interest to be copied to a clipboard of the Operating System. The second application is configured to recognise the metadata stack based on the datapoints copied on the clipboard. The present invention advantageously shares observations via the metadata stacks across the first application and the second application without requiring manual copying and saving/pasting of the referenced datapoints.

The present invention is advantageous in a distributed computing environment, especially in case of cloud computing and fog computing. In distributing computing environments, micro-service based applications may be used to replace monolithic applications. Interaction between the applications in such an environment may be achieved using direct API calls. However, such applications may need to be tightly coupled and cannot be seen as completely independent services. Further, the user context is the same (no exchange between entities that work independently) . The present invention enables non-interactive, independent applications in such a distributed environment to function smoothly. Users and application developers can use non-contiguous data in the applications and share the same with other users/applications. The metadata stack may also be used to design applications such that data can be shared seamlessly.

The foregoing has outlined rather broadly the technical features of the present disclosure so that those skilled in the art may better understand the detailed description that follows. Additional features and advantages of the disclosure will be described hereinafter that form the subject of the claims. Those skilled in the art will appreciate that they may readily use the conception and the specific embodiments disclosed as a basis for modifying or designing other structures for carrying out the same purposes of the present disclosure. Those skilled in the art will also realize that such equivalent constructions do not depart from the scope of the disclosure in its broadest form.

Below, the invention is described using the embodiments illustrated in the figures. Fig. 1 illustrates a system and device for managing applications configured to manage operations associated with assets, according to an embodiment of the present invention;

Fig. 2 illustrates a metadata stack, according to an embodiment of the present invention;

Fig. 3 illustrates Graphical User interfaces (GUIs) for applications configured to manage operations associated with assets, according to an embodiment of the present invention;

Fig. 4 illustrates a flow diagram of an example methodology of managing data between applications, according to an embodiment of the present invention; and

Fig. 5 illustrates a flow diagram of an example methodology of managing data between applications, according to an embodiment of the present invention.

Hereinafter, embodiments for carrying out the present invention are described in detail. The various embodiments are described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purpose of explanation, numerous specific details are set forth in order to provide a thorough understanding of one or more embodiments. It may be evident that such embodiments may be practiced without these specific details.

Fig. 1 illustrates a system 100 and device 130 for managing applications 102 and 104 configured to manage operations associated with assets 160, 162, 164, 170 and 180, according to an embodiment of the present invention. The assets 160, 162, 164, 170 and 180 can be equipments, actuators, robots, machinery in an industrial set-up (s). The devices can be medical devices and equipments in a healthcare unit. The devices can be home appliances or office appliances in a residential/commercial establishment. The operation of the assets 160, 162, 164, 170 and 180 may be measured using sensors and is herein referred to as operation data comprising one or more datapoints.

The 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, fleet management applications, etc. The applications 102 and 104 may be executed on separate devices 140 and 150, respectively. In another embodiment, the applications 102 and 104 may be executed on the device 130 with operating system 132.

The system 100 includes a cloud computing platform 110 that hosts a shared service 120. The shared service 120 is used to communicate metadata stacks between the applications 102 and 104. A metadata stack includes properties associated with one or more contiguous or non contiguous datapoints in the operation data of at least one of the assets 160, 162, 164, 170 and 180.

The metadata stack may be generated by either one of the applications 102 or 104 or both. For example, the application 102 generates a distribution of the operation data of asset 162. Further, the application 104 generates a distribution of the operation data of asset 164. The metadata stack may be generated by identifying regions of interest in the distribution of the operation data associated the asset 162.

The shared service 120 may be configured with features such as create, read, update and delete to enable generation of the centrally managed metadata stack from the region of interest or by selecting datapoints of interest. In some embodiments, the shared service 120 may be configured to provide additional parameters based on the metadata stack. Example parameters include list of common properties across the assets in the metadata stack. For example, if operation data of assets 162, 164 were referenced in th metadata stack, the shared service 120 may additionally add the parameter of the relationship with the asset 160 that is communicatively coupled to assets 162 and 164.

Further, the shared service 120 may be configured with Application Programming Interface (API) functionality to retrieve the operation data referred in the metadata stack. Furthermore, the shared service 120 may be configured with APIs to extract operation data from associated with more than one asset, such as assets 162 and 164. When the applications 102 or 104 are to be executed using the metadata stack, the shared service 120 may be configured to provide a simulation environment to a dry run the application 102 or 104 to check whether the metadata stack is suitable for the application 102 or 104.

The contents of the metadata stack may be used to determine whether the metadata stack is suitable for an application. The contents of the metadata stack is described herein after. Fig. 2 illustrates a metadata stack 200, according to an embodiment of the present invention. The metadata stack 200 includes a metadata string 210, asset identifier 220, time stamp 230 and a unique identifier 240.

The metadata string 210 includes datapoints in the operation data generated from the sensors associated with the assets 160, 162, 164, 170 and 180. For example, the metadata string comprises the operation data of asset 170 in time series from a first-time instance to a second time instance. The metadata string 210 may be generated by an operator while collecting suspicious datapoints in the operation data of more than one asset such as asset 160, 162 and 164. Properties of the datapoints are used to generate the metadata string 210 and thereby the metadata stack 200.

The asset identifier 220 provider indicates the assets referenced in the metadata stack 200. For example, the asset identifier 220 may also include asset type and model. For example, asset 170 is a turbine and asset 180 is a pump. The asset identifier 220 may comprise identifier for the asset 170 and asset 180, type of asset i.e. turbine and pump, and model of the turbine and the pump. In some embodiments, the asset identifier 220 may also include information regard the manufacture and design of the assets 160, 162, 164, 170 and 180.

The time stamp 230 is used to identify the time at which the metadata stack was generated. The time stamp 230 may be used to manage multiple versions of the metadata stack 200. Further, for easy referencing of the metadata stack 200 across the applications 102 and 104 the unique identifier 240 is provided.

The metadata stack 200 is advantageous for an operator to be able to collect suspicious datapoints from multiple assets and share it with a domain expert. The metadata stack 200 enables an operator want to collect datapoints while viewing the operation data or statistical models of the operation data without exiting the application. By not restricting asset types, the metadata stack 200 can be scaled to large set-ups with varied assets. The metadata stack 200 enables resolution of dis-ambiguities like common variable names across different and non-related assets.

Further, the unique identifier 240 may be used to incorporate a short description of the metadata stack 200. Thereby, the meaning of the metadata stack 200 may be understood by multiple applications/users over a period of time. Accordingly, the metadata stack 200 may be used to obtain a preview of the datapoints that are referenced. This enables applications to determine whether the metadata stack 200 is valid input without manually downloading all the referenced datapoints.

Fig. 3 illustrates Graphical User interfaces (GUIs) 310 and 320 for applications configured to manage operations associated with a fleet of assets, according to an embodiment of the present invention.

The applications are exemplary applications that relate to a fleet management application/solution and an anomaly detection (AD) application. The fleet management (FM) application may be used to monitor fleet operation data of the fleet of assets. The FM application may be configured to automatically issues alerts based on events identified in the fleet operation data. The AD application may be a separate service that is called by the FM application to identify anomalies or unusual patterns in the fleet operation data. The AD application may be enabled to detect unknown anomalies through rule-free analysis, detecting the first signs of unknown operation data, on any machine across the fleet of assets.

The GUIs 310 and 320 are herein after referred as FM GUI 310 and AD GUI 320 for the FM application and the AD application, respectively. The FM GUI 310 includes an asset field 330 that indicates the fleet of assets. The FM GUI 310 includes a time series chart that indicates the field operation data with respect to time. The time series chart is used to select datapoints of interest 340. Further, the FM GUI 310 includes a stack-create tool 360. The stack-create tool 360 includes a drop-down 350. The stack-create tool 360 is used to generate a metadata stack.

The AD GUI 320 indicates a pressure and temperature distribution associated with the datapoints of interest 340. The distribution is generated by the AD application using the data defined by the metadata stack generated by the stack- create tool 360.

It will be appreciated by a person skilled in the art that the GUIs 310 and 320 are mere examples. The stack-create tool 360 may be indicated on the GUI directly or may be called when a user inputs a command, such as copy/snip.

In operation, when the datapoints of interest 340 are selected, stack-create tool 360 may be displayed at the selected location. The stack-create tool 360 enables the FM and AD applications to be "stack aware". In other words, the FM application may initiate/enable initiation of the metadata stack generation. In an embodiment, a user may proceed with the generation of the metadata stack by clicking on the stack-create tool 360.

In another embodiment, the FM application may be configured to determine whether the datapoints 340 are datapoints of interest or not. The determination may be made based on a predetermined threshold. The predetermined threshold may provide minimum number of datapoints that are required for the metadata stack. In case an event is identified by the FM application, the predetermined threshold may include the number of datapoints that precede and follow the event. For example, the predetermined threshold may include 100 of datapoints before and after the event detection. The identified datapoints may be used to simulate the event and is then selected as datapoints of interest 340.

The metadata stack is generated by a shared service that is linked to the stack-create tool 360. The metadata stack is generated using the datapoints of interest 340. The metadata stack includes a metadata string with properties of the datapoints of interest 340, unique identifier and a time stamp. The AD application is informed of the metadata stack via the stack-create tool 360 provided on the AD GUI 320. The AD application may receive application program interface (API) for using the metadata stack from the shared service. The AD application may directly import the metadata stack for execution. In an embodiment, a dry run of the AD application is performed using the shared service. The dry run is used to decide whether the metadata stack is valid input for the AD application. Further, the dry run is used to decide whether the datapoints of interest 340, referenced in the metadata stack need to be downloaded. This is relevant in case the metadata stack is created with restrictions on the usage of the metadata stack.

To summarize Fig. 3 illustrates transportation of the operation data of the assets across heterogenous applications (such as FM application and AD application). The application consuming the metadata stack is configured to determine semantically correct operations. The shared service is a stack management server that enables extraction of the metadata stack even if the applications are not executed in the same session.

Fig. 4 illustrates a flow diagram 400 of an example methodology that managing data between applications associated with assets in an industrial setup, according to an embodiment of the present invention. Example assets are pumps and a turbine. Operation data from the assets are indicated by numerals pump 402, pump 404 and turbine 406. Further, the operation data may be appended with an asset status 408.

The method begins with step 405, with detection of an event in an asset management application. An operator/expert may want to drill down to identify a cause of the event. At step 410, the detected event is selected, and a copy instruction initiated via/by the asset management application. For example, at step 410, the event is selected by pressing command for copy e.g. CTRL+C.

At step 420, the asset management application recognizes that an event is selected. The asset management application generates a metadata string representing the event and including asset identifiers of the pumps 402, 404 and turbine 406 that are associated with the event. Further, at step 420 the asset management application sends a POST request to a shared service and transmits the generated metadata string. In an example, the POST request may include the following instructions {assets: ["Turbine"], timeRange:{ from: "2019-09-30. to: "2019-10-02... "}

}

A metadata stack is generated using the metadata string and is associated with a unique identifier.

At step 430, a second application such as a data analysis application is used to further analyze the event. The data analysis application may initiate/enable a paste operation such as CTRL+V. Through this operation, the data analysis application is made aware of the metadata stack.

At step 432, a determination is made whether the data analysis application is connected to a shared service hosted on a computing platform. Step 434 addresses the possibility that there is no connection to the shared service on the computing platform. At step 434, native tools, such as clip board, of operating system of the device is considered as the shared service. This example enables the functionality without access to the computing platform. By copying the metadata stack instead of datapoints/operation data to the clipboard, the present method saves computing resources. For example, several gigabytes of operation data may be used to determine the event. The API of the metadata stack providing enables the data analysis application to retrieve only an aggregation (i.e. the metadata stack) which reduces the data to only a few megabytes. Further, the data analysis application can be configured to accept the metadata stack as a valid input and therefore by default only the metadata stack is fetched from the clipboard. Accordingly, by sharing metadata stack only a small subset of the operation data referenced has to be received.

At step 436, the shared service on the cloud computing platform is accessed. For example, the shared service may be accessed using a Hypertext Transfer Protocol (HTTP) Uniform Resource Locator (URL). Both steps 434 and 436 result in step 438 with the data analysis application sending a HTTP GET request to the shared service (including native tools) to receive the metadata stack. Further step 438 may also include retrieving the operation data referenced in the metadata stack. At step 440, the data analysis application generates a visualization based on the metadata stack and the operation data selected at step 420.

Fig. 5 illustrates a flow diagram 500 of an example methodology that managing data between applications, according to an embodiment of the present invention. The method begins at step 510 with identifying datapoints of interest in operation data associated with assets. The datapoints of interest associated with the assets may be identified in a first application that uses the operation data. For example, a domain expert may identify areas of interest in a distribution of the operation data. The area of interest is used to identify the datapoints of interest. In another example, the datapoints of interest may be determined based on detection of an event or anomaly in the operation data.

At step 520, the metadata stacks are generated based on the datapoints of interest. Particularly, the metadata stacks are generated from metadata strings including properties of the datapoints of interest. Accordingly, at step 520 metadata string associated with the assets is generated. For example, the metadata string includes one of device identifier, device state of the assets and time stamp of the event. Further, for referencability, the metadata string is associated with a unique identifier. Accordingly, the metadata stack may be considered as an aggregation of datapoints of interest in the operation data.

At step 530, the metadata stacks are published to a shared service between a first application and a second application. The shared service is a common service that may be accessed via the operating system of the device executing the first and second application. Alternatively, the shared service may be accessed via a network that communicatively connects the first and second application to a computing platform that hosts the shared service. In an embodiment, at step 530, a graphical user interface (GUI) may be generated through a display device that enables access and modification of the metadata stacks by the first application and/or the second application .

At step 540, access to the metadata stacks is enabled whereby the first and second applications are capable of accessing the metadata stack and datapoints associated with the metadata stack. Further, features of the GUI may be modified to indicate that the metadata stacks are accessible. The datapoints associated with/referenced in the metadata stacks are accessed based on a dry run of the first/second application. Accordingly, step 540 includes determining that the first/second application is not adequately executable using the metadata stacks and transmitting the datapoints to the first/second application based on the determination.

The present invention can take a form of a computer program product comprising program modules accessible from computer- usable or computer-readable medium storing program code for use by or in connection with one or more computers, processors, or instruction execution system. For the purpose of this description, a computer-usable or computer-readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation mediums in and of themselves as signal carriers are not included in the definition of physical computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, random access memory (RAM), a read only memory (ROM), a rigid magnetic disk and optical disk such as compact disk read-only memory (CD-ROM), compact disk read/write, and DVD. Both processors and program code for implementing each aspect of the technology can be centralized or distributed (or a combination thereof) as known to those skilled in the art.