HK1255672A1 - Computer systems and methods for sharing asset-related information between data platforms over a network - Google Patents

Description

Computer system and method for sharing asset related information between data platforms over a network

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application claims priority from U.S. provisional patent application No. 62/219,837 entitled "data aggregation and Normalization Platform" filed on 9/17/2015, which is incorporated herein by reference in its entirety.

The present application also relates to the following applications claiming priority from U.S. provisional patent application No. 62/219,837 and filed on the same day as the present application: U.S. non-provisional patent application No. 15/268,333 entitled "Computer system and method for sharing Asset-Related Information Between Data Platforms Over a Network" filed on 2016, 9, 16; and U.S. non-provisional application No. 15/268,354 entitled "Computer Systems and Methods for managing a network of Data Platforms" filed on 16.9.2016. These applications are also incorporated herein by reference in their entirety.

Background

Machines (referred to herein as "assets") are critical to modern economies. From locomotives that transport goods across countries to agricultural equipment that harvest crops, assets play an important role in everyday life.

Monitoring asset-related information is also becoming increasingly popular as assets become more powerful. To facilitate this, organizations interested in monitoring assets may deploy platforms configured to receive and analyze asset-related information from various sources. In one example, this asset-related information may take the form of data indicative of attributes of the asset in operation (e.g., asset operation data, such as signal values output by sensors/actuators at the asset, fault codes generated at the asset, etc.). In another example, such asset-related information may take the form of data indicating transactions associated with the asset, such as whether the asset has been sold, rented, or rented during its lifetime. In yet another example, the asset-related information may take the form of data reflecting maintenance and repairs associated with the asset. For example, this data may indicate that the dealer or repair shop performed some repair on the asset or evaluated some asset condition, such as tire condition, fluid condition, or battery condition. Many other examples are possible.

Disclosure of Invention

As examples, there are numerous organizations that may be interested in receiving and analyzing the types of asset-related information described above, including dealers that sell assets, manufacturers that manufacture assets, and owners and/or users of assets. Indeed, each such organization may wish to deploy its own platform to receive and analyze such asset-related information, which may provide the organization with more freedom and better control how the asset-related information is used. However, with this arrangement, each organization's platform may only be able to receive a subset of the asset-related information available for analysis. For example, the set of assets from which each different platform may receive operational data may be different (e.g., an asset owner's platform may only be able to receive operational data from the owner's particular team of assets and not any other owner's assets, while an asset dealer's platform may only be able to receive operational data from the dealer's particular team of assets, but not other dealers' assets). As another example, each different platform may access certain data sources that are not accessible to other platforms (e.g., an organization may have previously collected and/or generated proprietary asset-related information stored at the organization's platform).

Such limited access to asset-related information is undesirable because the platform may perform various tasks that would benefit from a wider range of asset-related information. For example, a platform may be configured to define and execute statistical models related to asset operation, and the accuracy of these models may depend on the amount and breadth of historical data that may be used to train such models. As another example, a platform may be configured to define and execute various workflows (e.g., conditional alerts) related to asset operations, and a wider range of asset-related information may enable the platform to improve these workflows (e.g., by optimizing the conditions that trigger such workflows). As yet another example, a user of a platform may wish to access a wider range of asset-related information (e.g., in order to make a decision regarding maintenance or purchase of an asset). Many other examples are possible.

Given these benefits, one organization may be interested in obtaining additional asset-related information from one or more other organizations. For example, if an asset owner's platform is only capable of receiving operational data from the owner's particular team of assets, the owner may be interested in obtaining operational data about additional assets from one or more asset dealerships and/or asset manufacturers.

Currently, the main way an organization achieves this is by accessing another organization's platform through an Application Programming Interface (API). However, API data access requires an organization looking for data to perform an active step of "pulling" the data from another organization's platform, which is an inefficient mechanism for sharing data. In fact, this pull mechanism requires the organization to seek data to periodically send requests for new data to other organizations, which is inefficient because the requesting organization will not know whether new data is available. Furthermore, such a pull mechanism may only enable a requesting organization to access data already stored in the persistent storage of other organizations, meaning that the requesting organization may not be able to access data recently introduced by the other organization's platform until the data is persisted. In addition, such pull mechanisms may require the requesting organization to pass the authentication process, which further delays the requesting organization's access to the data. Therefore, a more efficient method of sharing data between platforms is desired.

Systems and methods directed to helping to address these issues are disclosed herein. In accordance with the present invention, multiple organizations may have respective platforms communicatively coupled via a network. In practice, each platform may have a messaging layer for dynamically pushing new data received by the platform to the appropriate modules within the platform, which in turn may be used to provide various services associated with the data. One such module may enable a platform to dynamically push data and/or commands to other platforms in a network.

For example, the first platform may receive new asset-related data at its messaging layer. Based on the received data, the first platform may determine that the given data (e.g., a given portion of the received asset-related data) and/or a given command is to be pushed to the second platform. According to one embodiment, the first platform may make this determination based on a set of rules that specify which data and/or commands are to be pushed to which platforms. In response to this determination, the first platform may prepare the given data and/or the given command for transmission to the second platform, establish a network connection with the second platform, and then push the given data and/or the given command to the second platform via the network connection (which then introduces the given data and/or the given command and continues accordingly). Advantageously, such an event-driven push architecture may enable certain data and/or commands to be exchanged between nearly real-time platforms, which may overcome certain limitations of the API pull mechanisms discussed above.

In accordance with this disclosure, the platform may also be configured to perform various other functions. As one example, each platform may include a data import system configured to perform various pre-processing functions on received asset-related data, such as data mapping, deduplication, and data consolidation, before providing this data to the messaging layer of the platform. As another example, each platform may include a module configured to provide various other services based on received asset-related data (e.g., user alerts or predictive analytics). Other examples are also possible.

According to the present invention, there may also be one "master" (or "seed") platform in the network that is configured to govern the other platforms in the network. For example, the "master" platform may manage whether the new platform may participate in data sharing with other platforms based on factors such as the reliability (or "health") of the stored data of the new platform. As another example, the "master" platform may provide specific logic (e.g., data models, rules, etc.) to other platforms that specify how the platform performs certain functions, such as pre-processing of received asset-related data or triggering certain actions based on received asset-related data. The "master" platform may also perform other abatement functions.

Accordingly, in one aspect, disclosed herein is a method implemented by a platform in a system comprising a plurality of platforms communicatively coupled via a network. One such method may involve (a) receiving, at a first platform, data associated with one or more assets, (b) determining, by the first platform, to push a given portion of the received data to a second platform, and (c) based on the determination, the first platform (i) preparing the given portion of the received data for transmission to the second platform, and (ii) pushing the given portion of the received data to the second platform via a network connection.

Another such method may involve (a) receiving, at a first platform, criteria governing whether the first platform is permitted to share asset-related data with one or more other platforms in the system, wherein the criteria is based on a reliability of the asset-related data stored at the platform; (b) the first platform evaluating reliability of asset-related data stored at the first platform; (c) the first platform applying the received criteria to the evaluated reliability of the asset-related data stored at the first platform and thereby making a determination as to whether the first platform is permitted to share asset-related data with one or more other platforms; and (d) the first platform operates according to the determination.

In another aspect, non-transitory computer-readable media are disclosed herein, each having stored thereon instructions executable to cause a platform to implement the functions disclosed herein.

In another aspect, platforms are disclosed herein, each platform comprising at least one processor, a non-transitory computer-readable medium, and program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor to cause the platform to implement the functions disclosed herein.

These and numerous other aspects will be recognized by those of skill in the art upon reading the following disclosure.

Drawings

FIG. 1 depicts an example network configuration in which example embodiments may be implemented.

FIG. 2 depicts a simplified architecture of an exemplary asset.

FIG. 3 depicts a conceptual illustration of example abnormal-condition indicators and sensor criteria.

FIG. 4 is a block diagram of an exemplary platform architecture.

FIG. 5 is a functional block diagram of an example platform.

FIG. 6 is a functional block diagram illustrating example data inclusion system functions performed by an example platform.

FIG. 7 is a functional block diagram illustrating exemplary data analysis system functions performed by an exemplary platform.

FIG. 8 is a functional block diagram illustrating example data sharing system functions performed by an example platform.

FIG. 9 depicts a flow diagram of an example method for determining whether to share asset-related data with other platforms via a network.

FIG. 10 depicts a flow diagram of an example method for sharing asset-related data with another platform via a network.

Detailed Description

The following disclosure makes reference to the accompanying drawings and several exemplary scenarios. Those skilled in the art will understand that such references are for illustrative purposes only, and thus are not meant to be limiting. Some or all of the disclosed systems, devices, and methods may be reconfigured, combined, added, and/or removed in various ways, each of which is contemplated herein.

I. Example network configuration

Fig. 1 shows an example network configuration 100 including multiple platforms coupled via a communication network. For example, as shown, the network configuration 100 may include a manufacturer platform 102 associated with an asset manufacturer, a dealer platform 104 associated with an asset dealer, and an owner platform 106 associated with an asset owner, all communicatively coupled together via a communication network 108. This example network configuration is illustrated in the context of asset management and describes organizations (e.g., manufacturers, dealers, and owners) that may be interested in accessing information about assets. However, it should be understood that the concepts disclosed herein may be applied in any other context than asset management, where parties and other organizations are interested in sharing data between platforms.

Broadly speaking, each platform 102, 104, 106 may take the form of one or more computer systems configured to receive, analyze, and provide access to asset-related data. For example, a platform may include one or more servers (or the like) having hardware components and software components configured to implement one or more of the functions disclosed herein for receiving, managing, analyzing, and/or sharing asset-related data. Additionally, the platform may include one or more client stations that enable users to interface with the platform. Indeed, these computing systems may be located in a single physical location or distributed among multiple locations and may be communicatively linked via a system bus, a communication network (e.g., a dedicated network), or some other connection mechanism. Further, the platform may be arranged to receive and transmit data according to a data flow technique (e.g., TPL data flow or NiFi), among other examples. The platform may take other forms as well.

In general, the communication network 108 may include one or more computing systems and network infrastructure configured to facilitate the transfer of data between the platforms 102, and the communication network 108 may be or include one or more Wide Area Networks (WANs) and/or Local Area Networks (LANs) and/or wired and/or wireless networks. In some examples, the communication network 108 may include one or more cellular networks and/or the internet, among other networks. The communication network 104 may operate according to one or more communication protocols such as LTE, CDMA, WiMax, WiFi, bluetooth, HTTP, TCP, and so forth. Although the communication network 108 is shown as a single network, it should be understood that the communication network 108 may include a plurality of different networks that are themselves communicatively linked. The communication network 108 may take other forms as well.

As shown in fig. 1, each platform 102, 104, 106 may be configured to receive data from one or more assets 110. These assets can be of various different types, examples of which may include transportation machines (e.g., locomotives, aircraft, semi-trailers, ships, etc.), industrial machinery (e.g., mining equipment, construction equipment, etc.), medical machines (e.g., medical imaging equipment, surgical equipment, medical monitoring systems, medical laboratory equipment, etc.), and utility machines (e.g., turbines, solar farms, etc.), among others. In addition, a given type of asset may have a variety of different configurations (e.g., brand, make, model, etc.). Those skilled in the art will recognize that these are only some examples of assets 110, and numerous other examples are possible and contemplated herein.

In general, each asset 110 may take the form of any device configured to perform one or more operations (which may be defined based on the fields), and may also include an apparatus configured to capture and transmit data indicative of the operation of the asset. Such data may take various forms, examples of which may include operational data such as sensor/actuator data and/or abnormal condition indicators (e.g., fault codes), data identifying the asset 110, location data of the asset 110, and so forth. Representative assets are discussed in further detail below with reference to FIG. 2.

As shown, the platforms 102, 104, and 106 may each receive data from a different set of assets 110. For example, the owner platform 106 may be configured to receive data only from a smaller set of assets 110 that it owns, while the dealer platform 104 may be configured to receive data from a larger set of assets 110 provided by the dealer, and the manufacturer platform 102 may be configured to receive data from a larger set of assets 110 that it manufactures. However, this is merely one example provided for illustration. Which platform receives data from which asset 110 may depend on various factors.

Although fig. 1 shows the platforms 102, 104, and 106 receiving data from one or more assets 110 via the network 108, it should also be understood that the platforms 102, 104, and 106 may receive data via one or more intermediate systems. For example, an organization may operate a separate system configured to receive data from one or more assets 110, and the platform of the organization may then be configured to acquire data from the separate system. Other examples are also possible.

As shown in fig. 1, each platform 102, 104, 106 may be further configured to receive data from an asset-related data source 112 via a network 108. For example, in practice, each platform 102, 104, 106 may receive data from the asset-related data sources 112 by "subscribing" to the services provided by the asset-related data sources 112. However, the platforms 102, 104, 106 may also receive data from the asset-related data sources 112 in other manners.

In general, the asset-related data source 112 may be or include one or more computer systems configured to collect, store, and/or provide data related to one or more assets 110. For example, similar to content provided by the one or more assets 110 themselves, the data may include data indicative of the operation of the one or more assets 110. Additionally or alternatively, the data source 112 may be configured to generate and/or obtain data independent of the asset 110, in which case the data may be referred to herein as "external data. Examples of "external" data sources 112 may include environmental data sources and asset management data sources.

Typically, the environmental data source provides data indicative of some characteristic of the environment in which the one or more assets 110 operate. Examples of environmental data sources include weather data servers, Global Navigation Satellite System (GNSS) servers, map data servers, and terrain data servers, among others, that provide information about natural and man-made features of a given area.

In general, an asset management data source provides data indicative of events or states of entities that may affect the operation or maintenance of one or more assets 110 (e.g., when and where the assets 110 may operate or receive maintenance). Examples of data sources include a traffic data server that provides information about air, water and/or ground traffic, an asset dispatch server that provides information about the expected route and/or location of the asset 110 on a particular date and/or at a particular time, a defect detector system (also referred to as a "hot box" detector) that provides information about one or more operating conditions of the asset passing proximate to the defect detector system, a parts supplier server that provides information about the inventory and price of parts that a particular supplier has, and a repair shop server that provides information about repair shop capabilities, etc., among other examples.

The "external" data source 112 may also take other forms, examples of which may include a power grid server that provides information about power consumption and an external database that stores historical operating data for the asset, among other examples. Those skilled in the art will appreciate that these are only some examples of data sources, and that numerous other examples are possible.

Although FIG. 1 shows that each platform 102, 104, 106 may be configured to receive data from the asset-related data source 112, it should be understood that each platform 102, 104, 106 may access a different set of asset-related data provided by the asset-related data source 112. For example, the owner platform 106 may be provided with only data from the data sources 112 that is relevant to the owner's particular fleet of assets, while the dealer platform 104 and the manufacturer platform 102 may be provided with data from the data sources 112 that are relevant to a broader set of assets. Alternatively, the condition may be that only certain platforms 102, 104, 106 are able to receive data from the asset-related data sources 112. In practice, which data provided by the asset-related data source 112 is accessible by which platform may depend on various factors.

Further, while fig. 1 shows the platforms 102, 104, and 106 receiving data from the asset-related data source 112 via the network 108, it is also understood that the platforms 102, 104, and 106 may receive data via one or more intermediary systems. For example, an organization may operate a separate system configured to receive data from the asset-related data sources 112, and the platform of the organization may then be configured to acquire the data from the separate system. Other examples are also possible.

Further, it should be understood that the platform of a given organization may interface with one or more organization-specific data sources, such as a pre-existing platform (not shown) of the organization, and that the asset-related information obtained from such organization-specific data sources may then be initially available only to the platform of the given organization.

It should be understood that network configuration 100 is one example of a network in which embodiments described herein may be implemented. Numerous other arrangements are possible and contemplated herein. For example, other network configurations may include additional components not shown and/or more or fewer picture elements.

Example assets

Turning to fig. 2, a simplified block diagram illustrating some components that may be included in an example asset 200 is depicted. Any of the assets 110 in FIG. 1 can have a configuration similar to that of the example asset 200. As shown, the asset 200 may include one or more subsystems 202, one or more sensors 204, one or more actuators 205, a central processing unit 206, a data storage 224, a network interface 210, a user interface 212, and a local analytics device 220, all of which may be communicatively linked (directly or indirectly) through a system bus, network, or other connection mechanism. Those skilled in the art will appreciate that the asset 200 may include additional components not shown and/or more or fewer of the depicted components.

Broadly speaking, the asset 200 may include one or more electrical, mechanical, and/or electromechanical components configured to perform one or more operations. In some cases, one or more components may be grouped into a given subsystem 202.

In general, the subsystem 202 may include groups of related components that are part of the asset 200. A single subsystem 202 may perform one or more operations independently, or a single subsystem 202 may operate in conjunction with one or more other subsystems to perform one or more operations. Often, different types of assets, even different types of the same type of asset, may contain different subsystems.

For example, in the context of transportation assets, examples of subsystems 202 may include engines, transmissions, transmission systems, fuel systems, battery systems, exhaust systems, brake systems, electrical systems, signal processing systems, generators, gearboxes, rotors, and hydraulic systems, among numerous other subsystems. In the context of a medical machine, examples of subsystems 202 may include a scanning system, a motor, a coil and/or magnet system, a signal processing system, a rotor, and an electrical system, among numerous other subsystems.

As suggested above, the asset 200 may be equipped with various sensors 204 configured to monitor the operating conditions of the asset 200 and various actuators 205 configured to interact with the asset 200 or components thereof and monitor the operating conditions of the asset 200. In some cases, some of the sensors 204 and/or actuators 205 may be grouped based on a particular subsystem 202. In this manner, the group of sensors 204 and/or actuators 205 may be configured to monitor operating conditions of the particular subsystem 202, and actuators from the group may be configured to interact with the particular subsystem 202 in a manner that may alter the behavior of the subsystem based on those operating conditions.

In general, the sensors 204 may be configured to detect physical attributes that may be indicative of one or more operating conditions of the asset 200, and provide an indication of the detected physical attributes, such as electrical signals. In operation, the sensor 204 may be configured to obtain measurements continuously, periodically (e.g., based on a sampling frequency), and/or in response to some triggering event. In some examples, the sensor 204 may be preconfigured with operating parameters for performing the measurements and/or the measurements may be performed according to operating parameters provided by the central processing unit 206 (e.g., a sampled signal indicative of the sensor 204 obtaining the measurement values). In an example, different sensors 204 may have different operating parameters (e.g., some sensors may sample based on a first frequency while other sensors sample based on a second, different frequency). Regardless, the sensor 204 may be configured to transmit an electrical signal indicative of the measured physical property to the central processing unit 206. The sensor 204 may continuously or periodically provide such signals to the central processing unit 206.

For example, the sensors 204 may be configured to measure physical properties, such as the position and/or movement of the asset 200, in which case the sensors may take the form of GNSS sensors, dead reckoning-based sensors, accelerometers, gyroscopes, pedometers, magnetometers, and the like.

Additionally, various sensors 204 may be configured to measure other operating conditions of the asset 200, examples of which may include temperature, pressure, speed, rate of acceleration or deceleration, friction, power usage, fuel usage, fluid levels, runtime, voltage and current, magnetic fields, electric fields, presence or absence of objects, location of components, and power generation, among other examples. Those skilled in the art will appreciate that these are merely some example operating conditions that a sensor may be configured to measure. Additional or fewer sensors may be used depending on the industrial application or particular asset.

As suggested above, the actuator 205 may be configured in certain aspects similar to the sensor 204. Specifically, the actuator 205 may be configured to detect a physical characteristic indicative of an operating condition of the asset 200 and provide an indication thereof in a manner similar to the sensor 204.

Also, the actuator 205 may be configured to interact with the asset 200, one or more subsystems 202, and/or some components thereof. As such, the actuator 205 may include a motor or the like configured to perform a mechanical operation (e.g., move) or otherwise control a component, subsystem, or system. In particular examples, the actuator may be configured to measure fuel flow and alter fuel flow (e.g., restrict fuel flow), or the actuator may be configured to measure hydraulic pressure and alter hydraulic pressure (e.g., increase or decrease hydraulic pressure). Numerous other example interactions of actuators are also possible and contemplated herein.

Generally, the central processing unit 206 may include one or more processors and/or controllers, which may take the form of general or special purpose processors or controllers. In particular, in an example implementation, the central processing unit 206 may be or include a microprocessor, microcontroller, application specific integrated circuit, digital signal processor, or the like. In turn, the data storage device 110 may be or include one or more non-transitory computer-readable storage media, such as optical, magnetic, organic, or flash memory, among other examples.

The central processing unit 206 may be configured to store, access, and execute computer-readable program instructions stored in the data storage 224 to perform the operations of the assets described herein. For example, as suggested above, the central processing unit 206 may be configured to receive respective sensor signals from the sensors 204 and/or actuators 205. The central processing unit 206 may be configured to store sensor and/or actuator data in the data storage 224 and later access the sensor and/or actuator data from the data storage 224.

The central processing unit 206 may also be configured to determine whether the received sensor and/or actuator signals trigger any abnormal condition indicators, such as fault codes. For example, the central processing unit 206 may be configured to store exception condition rules in the data store 224, each of which includes a given exception condition indicator representing a particular exception condition and a respective trigger criteria that triggers the exception condition indicator. That is, each abnormal-condition indicator corresponds to one or more sensor and/or actuator measurements that must be satisfied before the abnormal-condition indicator is triggered. In practice, the asset 200 may be pre-programmed with abnormal-condition rules and/or may receive new abnormal-condition rules or updates to existing rules from a computing system (e.g., the analytics system 220).

Regardless, the central processing unit 206 may be configured to determine whether the received sensor and/or actuator signals trigger any abnormal-condition indicators. That is, the central processing unit 206 may determine whether the received sensor and/or actuator signals satisfy any triggering criteria. When this determination is positive, the central processing unit 206 may generate abnormal-condition data, and may then also cause the asset's network interface 210 to transmit the abnormal-condition data to the analytics system 108 and/or cause the asset's user interface 212 to output an indication of the abnormal condition, such as a visual and/or audible alert. In addition, the central processing unit 206 may record the occurrence of an abnormal condition indicator triggered in the data storage 110, possibly with a timestamp.

FIG. 3 depicts a conceptual diagram of example abnormal-condition indicators and corresponding trigger criteria for an asset. In particular, FIG. 3 depicts a conceptual diagram of an example fault code. As shown, table 300 includes columns 302, 304, and 306 corresponding to sensor a, actuator B, and sensor C, respectively, and rows 308, 310, and 312 corresponding to fault codes 1, 2, and 3, respectively. The entry 314 then specifies the sensor criteria (e.g., sensor value threshold) corresponding to the given fault code.

For example, when sensor A detects a rotation measurement greater than 135 Revolutions Per Minute (RPM) and sensor C detects a temperature measurement greater than 65 degrees Celsius (C.), fault code 1 will be triggered, when actuator B detects a voltage measurement greater than 1000 volts (V) and sensor C detects a temperature measurement less than 55℃ such that fault code 2 will be triggered, when sensor A detects a rotation measurement greater than 100RPM, fault code 3 will be triggered, actuator B detects a voltage measurement greater than 750V and sensor C detects a temperature measurement greater than 60℃. Those skilled in the art will appreciate that fig. 3 is provided for purposes of example and explanation only, and that numerous other fault codes and/or triggering criteria are possible and contemplated herein.

Referring back to fig. 2, the central processing unit 206 may also be configured to implement various additional functions for managing and/or controlling the operation of the asset 200. For example, the central processing unit 206 may be configured to provide command signals to the subsystem 202 and/or the actuator 205 that cause the subsystem 202 and/or the actuator 205 to perform some operation (e.g., modify throttle position). Additionally, the central processing unit 206 may be configured to modify the rate at which it processes data from the sensors 204 and/or actuators 205, or the central processing unit 206 may be configured to provide instruction signals to the sensors 204 and/or actuators 205 such that the sensors 204 and/or actuators 205, for example, modify the sampling rate. Further, the central processing unit 206 may be configured to receive signals from the subsystem 202, the sensors 204, the actuators 205, the network interface 210, and/or the user interface 212 and cause operations to occur based on such signals. Further, the central processing unit 206 may be configured to receive signals from a computing device, such as a diagnostic device, that cause the central processing unit 206 to execute one or more diagnostic tools according to diagnostic rules stored in the data storage device 110. Other functions of the central processing unit 206 will be discussed below.

The network interface 210 may be configured to provide communication between the asset 200 and various network components connected to the communication network 106. For example, the network interface 210 may be configured to facilitate wireless communication to and from the communication network 106, and thus may take the form of antenna structures and associated apparatus for transmitting and receiving various wireless signals. Other examples are also possible. Indeed, the network interface 210 may be configured according to a communication protocol, such as, but not limited to, any of those described above.

The user interface 212 may be configured to facilitate user interaction with the asset 200, and may also be configured to cause the asset 200 to perform operations in response to user interaction. Examples of user interface 212 include touch-sensitive interfaces, mechanical interfaces (e.g., levers, buttons, scroll wheels, dials, keyboards, etc.), and other input interfaces (e.g., microphones), among other examples. In some cases, the user interface 212 may include or provide connections to output components, such as a display screen, speakers, a headphone jack, and so forth.

The local analytics device 220 may generally be configured to receive and analyze data related to the asset 200, and based on this analysis may cause one or more operations to occur at the asset 200. For example, the local analytics device 220 may receive operational data (e.g., data generated by the sensors 204 and/or actuators 205) about the asset 200 and, based on this data, may provide instructions to the central processing unit 206, the sensors 204, and/or actuators 205 that cause the asset 200 to perform operations.

To facilitate this operation, local analytics device 220 may include an asset interface configured to couple local analytics device 220 to one or more of the one or more on-board systems of the asset. For example, as shown in fig. 2, the local analytics device 220 may have an interface to the asset's central processing unit 206, which may enable the local analytics device 220 to receive operational data from the central processing unit 206 (e.g., operational data generated by the sensors 204 and/or actuators 205 and sent to the central processing unit 206), and then provide instructions to the central processing unit 206. In this manner, local analytics device 220 may indirectly interface with and receive data from other on-board systems of asset 200 (e.g., sensors 204 and/or actuators 205) via central processing unit 206. Additionally or alternatively, as shown in fig. 2, the local analytics device 220 may have an interface to one or more sensors 204 and/or actuators 205, which may enable the local analytics device 220 to communicate directly with the sensors 204 and/or actuators 205. Local analytics device 220 may also otherwise interface with the on-board system of asset 200, including the possibility that the interface illustrated in fig. 2 is facilitated by one or more intermediate systems not shown.

In fact, the local analytics device 220 may enable the asset 200 to locally perform advanced analytics and associated operations that may otherwise be impossible to perform with other on-asset components, such as executing predictive models and corresponding workflows. As such, the local analytics device 220 may help provide additional processing power and/or intelligence to the asset 200.

It should be understood that the local analytics device 220 may also be configured to cause the asset 200 to perform operations unrelated to the predictive model. For example, the local analytics device 220 may receive data from a remote source (e.g., the analytics system 108 or the output system 110) and cause the asset 200 to perform one or more operations based on the received data. One particular example may involve the local analytics device 220 receiving a firmware update for the asset 200 from a remote source and then having the asset 200 update its firmware. Another particular example may involve the local analytics device 220 receiving diagnostic instructions from a remote source, and then causing the asset 200 to execute a local diagnostic tool in accordance with the received instructions. Many other examples are possible.

As shown, in addition to the asset interface(s) discussed above, the local analytics device 220 may include a processing unit 222, a data storage device 224, and a network interface 226, all of which may be communicatively linked through a system bus, network, or other connection mechanism. The processing unit 222 may include one of the components discussed above with respect to the central processing unit 206. In turn, the data storage 224 may be or include one or more non-transitory computer-readable storage media, possibly taking any of the forms of computer-readable storage media discussed above.

The processing unit 222 may be configured to store, access, and execute computer-readable program instructions stored in the data storage 224 to perform the operations of the local analytics device described herein. For example, the processing unit 222 may be configured to receive respective sensor and/or actuator signals generated by the sensors 204 and/or actuators 205, and may execute a predictive model-workflow pair based on such signals. Other functions are described below.

The network interface 226 may be the same as or similar to the network interfaces described above. Indeed, the network interface 226 may facilitate communication between the local analytics device 220 and the analytics system 108.

In some example implementations, the local analytics device 220 may include and/or communicate with a user interface similar to the user interface 212. In practice, the user interface may be located remotely from the local analytics device 220 (and the asset 200). Other examples are also possible.

While fig. 2 shows a local analytics device 220 physically and communicatively coupled to its associated asset (e.g., asset 200) via one or more asset interfaces, it is also understood that this may not always be the case. For example, in some implementations, the local analytics device 220 may not be physically coupled to its associated asset, but may be located remotely from the asset 220. In an example of this implementation, the local analytics device 220 may be wirelessly communicatively coupled to the asset 200. Other arrangements and configurations are also possible.

For more details on the configuration and operation of local analysis devices, reference is made to U.S. application Ser. No. 14/963,207[ Uptake-00051], which is incorporated herein by reference in its entirety.

Those skilled in the art will appreciate that the asset 200 shown in FIG. 2 is only one example of a simplified representation of an asset, and that many other examples are possible. For example, other assets may include additional components not shown and/or more or less components of a picture. Further, a given asset may contain a single asset that may be operated in concert to perform the operations of the given asset. Other examples are also possible.

Exemplary platform

An exemplary platform will now be described with reference to fig. 4 through 5. Any of the platforms 102, 104, 106 from fig. 1 may have a similar configuration as this example platform.

FIG. 4 is a simplified block diagram illustrating some components that may be included in an example platform 400 from a structural perspective. As noted above, a platform may generally comprise one or more computer systems (e.g., one or more servers), and these one or more computer systems may collectively include at least one processor 402, a data storage device 404, a network interface 406, and perhaps a user interface 410, all of which may be communicatively linked via a communication link 408, such as a system bus, network, or other connection mechanism.

The processor 402 may include one or more processors and/or controllers, which may take the form of general or special purpose processors or controllers. In particular, in an example implementation, the processing unit 402 may include a microprocessor, microcontroller, application specific integrated circuit, digital signal processor, or the like.

In turn, data storage 404 may include one or more non-transitory computer-readable storage media, examples of which may include volatile storage media such as random access memory, registers, cache memory, and the like, as well as non-volatile storage media such as read only memory, hard drives, solid state drives, flash memory, optical storage, and the like.

As shown in fig. 4, data storage 404 may be equipped with software components that enable platform 400 to implement the functionality disclosed herein. These software components may generally take the form of program instructions executable by the processor 402 and may be arranged together into an application, software development kit, toolset, and the like. Additionally, the data store 404 may also be associated with one or more databases arranged to store data related to functions implemented by the platform, examples of which include time series databases, file databases, relational databases (e.g., MySQL), key-value databases, and graph databases, among others. One or more databases may also provide multiple language storage.

The network interface 406 may be configured to facilitate wireless and/or wired communication between the platform 400 and various network components coupled to the communication network 108, such as the assets 110 and the asset-related data sources 112. As such, the network interface 406 may take any suitable form to perform these functions, examples of which may include an ethernet interface, a serial bus interface (e.g., firewire, USB2.0, etc.), a chipset and antenna adapted to facilitate wireless communication, and/or any other interface that provides wired and/or wireless communication. Network interface 402 may also include multiple network interfaces supporting a variety of different types of network connections, some examples of which may include Hadoop, FTP, relational databases, high frequency data such as OSI PI, bulk data such as XML, and Base 64. Other configurations are also possible.

In some embodiments, the example platform 400 may support a user interface 410 configured to facilitate user interaction with the platform 400, and may also be configured to facilitate causing the platform 400 to perform operations in response to user interaction. Such a user interface 410 may include or provide connections to various input components, examples of which include touch-sensitive interfaces, mechanical interfaces (e.g., levers, buttons, scroll wheels, dials, keyboards, etc.), and other input interfaces (e.g., a microphone). Additionally, the user interface 410 may include or provide connections to various output components, examples of which may include a display screen, speakers, a headphone jack, and so forth. Other configurations are also possible.

In other embodiments, the user interface 410 may take the form of a client station. The client station may be communicatively coupled to the example platform via a communications network and a network interface of the platform. Other configurations are also possible.

Referring now to FIG. 5, another simplified block diagram is provided to illustrate some components that may be included in an example platform 500 from a functional perspective. For example, as shown, the example platform 500 may include a data inclusion system 502, a data analysis system 504, a data sharing system 506, each of which includes a combination of hardware and software configured to perform particular functions. The platform 500 may also include a plurality of databases 510 contained within and/or otherwise coupled to one or more of the data inclusion system 502, the data analysis system 504, and the data sharing system 506. In practice, on a single computer system or distributed over multiple computer systems.

The data intake system 502 is generally operable to receive asset-related data and then provide at least a portion of the received data to the data analysis system 504. As such, the data intake system 502 can be configured to receive asset-related data from various resources, examples of which can include assets, asset-related data sources, or existing infrastructure of an organization. The data received by the data intake system 502 can take a variety of forms, examples of which can include analog signals, data streams, and/or network data packets. Further, in some examples, the data inclusion system 502 may be configured according to a given data flow technology, such as a NiFi receiver or the like.

In some embodiments, the data broker 508 may be provided to a given source (e.g., an asset-related data source, or an existing infrastructure of an organization) before the data intake system 502 receives data from the data source. In general, the data broker 508 may be a software component for accessing asset-related data at a given source, placing the data in an appropriate format, and then facilitating transmission of the data to the platform 500 for receipt by the data intake system 502. As such, the data broker 508 may cause the given source to perform, for example, compression and/or decompression, encryption and/or decryption, analog-to-digital and/or digital-to-analog conversion, filtering, amplification, and/or data mapping, among other examples. However, in other embodiments, a given source may be able to access, format, and/or transmit asset-related data to the example platform 500 without the aid of a data broker.

The asset-related data received by the data intake system 502 may take various forms. As one example, the asset-related data may include operational data of the asset, such as one or more sensor measurements, one or more actuator measurements, or one or more abnormal condition indicators. As another example, the asset-related data may include external data about the asset, such as asset inventory rental information, warranty information, or maintenance information. As another example, the asset-related data may include certain attributes regarding the source of the asset-related data, such as a source identifier, a timestamp (e.g., date and/or time the information was obtained), and an identifier of the location where the information was obtained (e.g., GPS coordinates). For example, a unique identifier (e.g., a computer-generated letter, number, alphanumeric, or similar identifier) may be assigned to each asset, and possibly to each sensor and actuator, and may be operable to identify the asset, sensor, or actuator from which the data originated. These attributes may be in the form of signal signatures or metadata, among other examples. Asset related data may also take other forms.

The data intake system 502 may also be configured to perform various pre-processing functions on the received asset-related data in an effort to provide clean, up-to-date, consistent, accurate, available, etc. data to the data analysis system 504.

For example, the data inclusion system 502 may map received data into defined data structures and may discard any data that cannot be mapped to these data structures. As another example, the data inclusion system 502 may evaluate the reliability (or "health") of the received data, and take certain actions based on this reliability, such as discarding certain unreliable data. As another example, data inclusion system 502 may "deduplicate" received data by identifying any data that has been received by the platform and then ignoring or discarding such data. As another example, the data inclusion system 502 can determine that the received data relates to data that has been stored in the platform's database 510 (e.g., different versions of the same data) and then merge the received data and the stored data into one data structure or record. As a further example, the data inclusion system 502 can identify an action to take based on the received data (e.g., CRUD action) and then notify the data analysis system 504 of the identified action (e.g., via an HTTP header). As yet another example, the data intake system 502 can split received data into particular data categories (e.g., by placing different data categories in different queues). Other functions may also be performed.

It is also possible that the data agent 508 may perform or assist some of these preprocessing functions in some embodiments. As one possible example, the data mapping function may be performed in whole or in part by the data broker 508 rather than the data intake system 502. Other examples are also possible.

The data intake system 502 may be further configured to store the received asset-related data in one or more of the databases 510 for later retrieval. For example, the data inclusion system 502 may store raw data received from the data broker 508, and may also store data derived from one or more of the preprocessing functions described above. As discussed above, the data intake system 502 storing this data to a database may take various forms, examples of which include time series databases, file databases, relational databases (e.g., MySQL), key-value databases, and graphic databases, among others. In addition, the database may provide multiple language storage. For example, the data intake system 502 can store payloads of received asset-related data in a first type of database (e.g., a time series or document database) and can store associated metadata of the received asset-related data in a second type of database (e.g., a relational database) that allows for faster searching. In this instance, the metadata may then be linked or otherwise associated with asset-related data stored in another database related to the metadata. The database 510 used by the data inclusion system 502 may also take a variety of other forms.

As shown, the data inclusion system 502 can then be communicatively coupled to a data analysis system 504. The interface between the data intake system 502 and the data analysis system 504 can take various forms. For example, the data inclusion system 502 can be communicatively coupled to the data analysis system 504 via an API. Other interface technologies are also possible.

The data analysis system 504 is generally operable to receive asset-related data from the data intake system 502, analyze the data, and then take various actions based on the data. These actions may take various forms.

As one example, based on the received asset-related data, the data analysis system 504 may provide various types of notifications, such as network notifications, email notifications, and so forth. These notifications may relate to the operation of the asset, the operation of the platform, or other relevant subject matter of interest to the user.

As another example, based on the received asset-related data, the data analysis system 504 may train and/or execute a data science model (e.g., a predictive model) that may be implemented in a data science engine. For more detail regarding predictive models related to asset operation, please refer to U.S. application No. 14/732,258, which is incorporated herein by reference in its entirety. The data analysis system 504 may also perform other types of data analysis based on the received asset-related data.

As another example, based on the received asset-related data, data analysis system 504 may cause platform 500 to dynamically push data and/or commands to other platforms in the network. For example, based on the received data, the data analysis system 504 may determine that certain data (e.g., portions of the received asset-related data) and/or some command is to be pushed to another platform, and then responsively push the data and/or command to the data sharing system 506, which may handle the transmission of the data and/or command to another platform.

As another example, based on the received asset-related data, the data analytics system 504 may make certain data available for external access via an API. The data analysis system 504 may also take various other actions based on the received asset-related data.

According to an embodiment, the received asset-related data may pass through the data analytics system 504 via a messaging layer (sometimes referred to as a "universal data bus") that may provide event-driven push communication between different modules of the data analytics system 504. The messaging layer may be configured according to various techniques, one example of which is apache kafka. Further, the data analysis system 504 may analyze the received asset-related data to determine which actions to take based on a set of rules that relate certain data received by the platform 500 to certain actions to be taken by the platform 500. These rules are described in further detail below.

In addition to analyzing the received asset-related data for taking potential actions based on such data, the data analysis system 504 may also be configured to store the received data into one or more of the databases 510. For example, the data analysis system 504 may store the received data in a given database that acts as a master database for providing asset-related data to platform users as well as other platforms.

In some embodiments, the data analytics system 504 may also support a Software Development Kit (SDK) for building, customizing, and adding additional functionality to the platform. This SDK may customize the functionality of the platform over the hard-coded functionality of the platform.

As shown, both the data intake system 502 and the data intake system 504 may be communicatively coupled to a data sharing system 506. The interface of the data sharing system with the data import system 502 and the data analysis system 504 can take various forms. For example, the data sharing system 506 may be communicatively coupled to the data import system 502 and/or the data analysis system 504 via an API. Other interface technologies are also possible.

The data sharing system 506 may generally be used to facilitate communications between the example platform 500 and other platforms via a communications network. For example, as described above, data analysis platform 504 may provide data and/or commands (e.g., for CRUD actions) to data sharing platform 506 for pushing to another platform. In turn, the data sharing platform 506 may be used to prepare data and/or commands for transmission to other platforms (e.g., by creating routing commands, performing data scrubbing, etc.), establish a network connection (such as a TCP or HTTP connection) with another platform, and then push the data and/or commands to the other platform via the network connection.

Accordingly, the data sharing platform 506 may be used to receive, verify, and route data and/or commands pushed from another platform over a communication network. For example, if the data sharing platform 506 receives data pushed from another platform, the data sharing platform 506 may be used to perform certain validation and pre-processing functions on the received data and/or commands, and then push the data and/or commands to the data ingestion platform 502. In turn, data intake platform 502 may perform one or more of the pre-processing functions described above, and then pass the data and/or commands to data analysis system 504, which data analysis system 504 may act accordingly. The data sharing platform 506 may also perform other functions to facilitate communications with other platforms.

Those skilled in the art will appreciate that the example platform shown in fig. 4-5 is merely one example of a simplified representation of components that may be included in a platform, and that numerous other example platforms are possible. For example, other platforms may include additional components not shown and/or more or fewer picture elements. Further, a given platform may include multiple single platforms that operate together to perform the operations of the given platform. Other examples are also possible.

Exemplary procedure

The configuration depicted in fig. 1-5 will now be discussed in more detail below. To facilitate the description of some of these operations, operations that may be performed may be described with reference to functional block diagrams. In some cases, each block may represent a module or portion of program code, which includes instructions executable by the processor to perform specific logical functions or steps in the process. The program code can be stored on any type of computer-readable medium (e.g., a non-transitory computer-readable medium). In other cases, each block may represent circuitry that is wired to perform a particular logical function or step in a process. Moreover, the blocks shown in the flowcharts may be rearranged into a different order, combined into fewer blocks, separated into additional blocks, and/or removed based on the particular embodiments.

The following description may refer to an example in which one or more assets 110 and/or asset-related data sources 112 provide asset-related data to a platform and then push the asset-related data to another platform via the communication network 108. It is to be understood that this is done for clarity and explanation only and is not meant as a limitation. In practice, a platform may typically receive data from multiple sources simultaneously and perform operations based on this aggregation of the received data.

A. Platform deployment and management and control

To enable data sharing among multiple platforms, these platforms first need to be deployed, networked together, and configured (e.g., onboard). In accordance with the present invention, one platform in the network may be designated as a "master" or "seed" platform that may govern how certain of these management functions are implemented at other platforms in the network.

In one aspect, the host platform may specify whether the new platform is allowed to participate in data sharing with other platforms. This may be based on various factors. For example, in a preferred embodiment, the host platform may specify that the ability of the new platform to participate in data sharing is based on the reliability (or "health") of the new platform's stored data. According to this embodiment, the master platform may define a set of one or more reliability conditions that the new platform needs to satisfy in order to participate in the data sharing. This set of reliability conditions may be sent from the master platform to the new platform via the communication network 108, or may be provided to the new platform in some other way. Further, the set of reliability conditions may take various forms. According to one example, the set of reliability conditions may force the number of stored data that require a new platform to successfully map to a new data model during initial data ingestion. According to another example, the set of reliability conditions may impose requirements as to which data fields should be present in the data passed into the data analysis system 504. The set of reliability conditions may also take other forms.

During the on-board process, the new platform may then assess the reliability (or "health") of the new platform's stored data. The new platform can perform this function in various ways. According to one example, a new platform may evaluate the reliability of the stored data of the platform by determining how much proportion of the stored data was successfully mapped to the new data model during the initial data import. According to another example, the new platform may evaluate the reliability of the platform's stored data by checking whether certain preferred data fields are present in the data passed into the data analysis system 504, and then determining how many proportions of this data include the preferred data fields. The new platform may also evaluate the reliability of the stored data of the platform in various other ways.

After evaluating the reliability of the stored data, the new platform may then apply a set of reliability conditions defined by the host platform to determine whether the reliability of the stored data of the new platform is sufficient. If the new platform determines that a set of reliability conditions for the master platform has been met, the new platform may enable (i.e., "turn on") its data sharing capabilities so that it may exchange asset-related data and/or commands with other platforms. Alternatively, if the new platform determines that a set of reliability conditions for the host platform are not met, the new platform may completely disable (i.e., "turn off") its data sharing capabilities, or may impose some limitation on such capabilities. For example, the new platform may disable the ability to send data and/or commands to other platforms, but continue to allow the new platform to receive data and/or commands from other platforms. As another example, the new platform may impose restrictions on the types of data and/or commands that are allowed to be exchanged with other platforms. The new platform may also limit its data sharing functionality in other ways.

After determining whether to enable its data sharing capabilities, the new platform may also send a notification of this determination to the master platform and/or other platforms in the network. Then, another platform in the network may later rely on this notification in deciding whether to share asset-related data with the new platform.

The host platform may also be able to define and send update conditions that allow data sharing, which may cause other platforms to repeat the process described above. Likewise, the platform may be configured to periodically re-evaluate the reliability of its stored data and update its data sharing capabilities appropriately.

In another aspect, the host platform may define and/or provide other platforms with other logic (e.g., data models, rules, etc.) that instructs the other platforms how to perform certain functions. For example, according to one embodiment, the master platform may be responsible for defining and distributing one or more data models (or aspects thereof) for use by other platforms in ingesting and mapping data received from asset-related sources.

According to another embodiment, the host platform may be responsible for defining and distributing logic that instructs other platforms how to perform certain other pre-processing functions. For example, the host platform may define and allocate logic related to data mapping, data cleaning, deduplication, data merging, action recognition, and/or data splitting, among other pre-processing functions. As one possible example, the host platform may define and allocate routing and/or transformation rules to be used during the data mapping process. Many other examples are possible.

According to a further embodiment, the host platform may be responsible for defining and allocating logic that specifies actions to be taken by other platforms based on the received data. For example, the host platform may define and assign certain predefined rules, workflows, predictive models, and so forth. As one possible example, the host platform may define and assign source-to-target rules that specify how certain types of asset-related data are routed within the platform. Other examples are also possible.

The host platform may assign data sharing conditions and/or other logic to the other platforms in various ways. According to one example, the master platform may send the data sharing conditions and/or other logic to the other platforms via the communication network 108. According to another example, the host platform may upload data sharing conditions and/or other logic to a common database accessible by other platforms. Other examples are also possible.

In conjunction with this functionality, the host platform may also provide tools (which may be referred to as "data specialist" tools) by which a user of the host platform may define how other platforms are governed. As one possible example, this tool may take the form of a Graphical User Interface (GUI) that may be accessed by a user via a client station on the communication network 108. Using this tool, a user may input data sharing conditions and/or other logic to be employed by other platforms (as examples), and the master platform may then cause the data sharing conditions and/or other logic to be distributed to the other platforms.

The host platform may also perform other functions in addition to or in place of those described.

B. Data incorporation of asset-related information

FIG. 6 is a functional block diagram 600 illustrating some representative functions that may be implemented after the data intake system 502 receives asset-related data from a source, such as an asset, an asset-related data source, and the like. As shown in fig. 6, these functions may include data mapping 602, data health evaluation 604, data deduplication 606, data consolidation 608, action recognition 610, and data queuing 612. The data intake system 502 may support NiFi or some other data streaming technology to send, receive, route data between functional blocks as needed. Other arrangements are also possible.

While fig. 6 shows these functions occurring in a given order, it is to be understood that this order is provided for purposes of illustration only, and that the illustrated functions may be performed in a variety of other orders, including the possibility that certain functions may be performed in parallel. Further, it should be understood that some of these functions may be skipped and/or added to the process flow.

The mapping function 602 may generally be used to map the received asset-related data to one or more data models for use by the platform 500. Data received from a given source, such as the asset 110 or the asset-related data source 112, may be in a particular format. The particular format may be a standard format or a common format, a format specific to the asset 110 or type of asset 110, a format specific to the asset-related data source 112, a format specific to the platform receiving the data, or a format specific to a manufacturer, dealer, or owner, for example. The mapping function 602 may then convert the format of the asset-related data into a format for use by the platform 500, which may involve storing the received asset-related data fields into appropriate fields of the data model and converting the contents of certain asset-related data fields. These functions may be performed according to routing and/or transformation mapping rules that may be provided by a platform provider, defined by the platform (e.g., based on user input or machine learning), and/or received from another platform.

In general, a data model may be a defined data structure that specifies the manner in which certain data should be organized and/or formatted, thereby enabling a platform to manage data from a variety of different sources. According to one embodiment, the data model may define a data structure including a plurality of data fields, each having, by way of example, specified parameters, such as a specified namespace, a specified data type, a specified unit of measure, and/or a specified data value constraint. These data fields may be configured to accept asset identification data as well as various data related to asset operation, such as sensor/actuator data, on-asset event data (e.g., abnormal condition indicators), location data, inspection/maintenance/repair data, fluid data, weather data, job site data, configuration data, and transaction data, among many other examples. The data model may also take other forms. Additionally, the particular data model used by mapping function 602 may vary depending on the source of the data (e.g., different data models may exist for different types of assets and/or different types of external data sources).

The data model used by mapping function 602 may be defined in various ways. In one example, various aspects of the data model may be predefined by the platform provider. In another example, as described above, various aspects of the data model may be defined by a master or seed platform. In another example, aspects of the data model may be defined by the platform 500 (e.g., based on user input or machine learning). The data model may also be defined in other ways.

The mapping function 602 may additionally discard certain received asset-related data fields that cannot be mapped to fields of the data model, such as received data fields that are not sufficiently labeled, do not match data managed by the data model, are not within a range of values defined by fields in the model, or are otherwise identified as corrupt, incorrect, incomplete, duplicative, or improperly formatted. This functionality (which may be referred to as "data cleanup") may help improve the integrity of asset-related data introduced into the platform 500. It should be understood that other processes within the data import system 502 can also perform data cleanup functions.

In conjunction with the mapping function 602, the platform may also provide a tool (which may be referred to as a "data mapping" tool) by which a user of the platform may define aspects of one or more data models and/or mapping rules used by the mapping function 602. As one possible example, this tool may take the form of a GUI accessible by a user via a client station on the communication network 108. Using this data mapping tool, a user of a given platform may enter instructions on how to map a particular source data field to one or more data models used by mapping function 602, and these instructions may then be employed by mapping function 602 of the given platform. In addition, user input received via such a data mapping tool may also be distributed to and/or used by other platforms depending on the role of a given platform in a network configuration. For example, if a given platform is the primary platform, user input received via the data mapping tool may be allocated for use by all other platforms in the network configuration. Other examples are also possible.

The data health assessment function 604 may generally be used to assess the reliability (or "health") of the received asset-related data and may discard any unreliable data. For example, the data inclusion system 502 may have criteria that it can use to evaluate the reliability of the received data. As one possible example, the data health assessment function 604 may evaluate the reliability of the received asset-related data by determining how much of the proportion of the received asset-related data was successfully mapped to the data model during the mapping function 602. As another example, the data health assessment function 604 may evaluate the reliability of the received asset-related data by checking whether certain preferred data fields are present in the data passed to the data analysis system 504 and then determining how many proportions of this data contain preferred data fields. The data health assessment function 604 may also evaluate the reliability of the received asset-related data in various other ways.

Deduplication function 606 may generally be used to determine whether received data has already been stored, such as whether one was copied in database 510, and if so, whether to update or delete data in the database and replace it with the received data. This process may be performed for all received data, or when metadata associated with the data indicates that deduplication is to be performed. For example, if such deduplication is to be performed, the data inclusion system 502 may check the settings indicated by the metadata associated with the data.

Hashing may be one method for determining whether duplication exists. Hashing may be the process of converting a string into a generally short fixed length value or key representing the original string. In one example, a hash function may be applied to data to generate a unique signature, referred to as a hash, that identifies the data.

The hash function may be applied to the received data and the data in the model. The hash of the received data is then compared to the hash representing the data in the model. The hashing of the data in the model may be performed each time the data is accessed from the model, or once the hashing is performed on the data in the model, the hashes may also be stored in the model for later use. If there is a match, the received data may not be stored in the model because the hash indicates that the data is already in the model. If there is a mismatch, the received data may be stored in the model.

The data merge function 608 may generally be used to determine whether received data is related to data already stored in one of the databases 510 (e.g., a different version of the same data), and then merge any such received data with the stored data. For example, if the data intake system 502 receives new asset-related data for a given asset that contains certain fields that are more complete or up-to-date than the stored asset-related data for the given asset, the data intake system 502 may merge the new data with the stored data. As another example, if the data intake system 502 receives data records for the same given asset from multiple different sources, the data intake system 502 may combine the data records into a single authority for the given asset. Other examples are also possible.

The deduplication function 606 and/or the data merge function 608 may sometimes be referred to as "master data management" (or "MDM"). In conjunction with these MDM functions, the platform 500 may also provide tools by which a user of the platform 500 may define rules for performing certain deduplication and/or consolidation functions, such as rules that specify similarity requirements for data consolidation and/or rules that specify which data records should be considered more authoritative during the deduplication and/or consolidation functions. As one possible example, this tool may take the form of a GUI accessible by a user via a client station on the communication network 108.

The action recognition function 610 may generally be used to recognize what action should be taken based on the received data, and then place the data into a form for notifying the data analysis system 504 of the recognized action. For example, the action recognition function 610 may analyze the data received by the data inclusion system 502 to determine whether it includes, and/or is associated with a command that specifies an action (e.g., CRUD action) that should be taken based on the data. In turn, the action recognition function 610 may place the data into a form, such as a particular API call, that will be used to notify the data analysis system 504 of the recognized action. The action recognition function 610 may also notify the data analysis system 504 of the recognized action in other ways.

Data queuing function 612 is generally operable to separate data into different data categories. For example, the data intake system 502 can separate received data into different queues corresponding to different categories, which can facilitate specific processing by the data analysis system 504 (which receives data from the data intake system 502) based on the categories. For example, the data intake system 502 may employ a first queue for sensor/actuator data (e.g., fuel levels), a second queue for event data (e.g., abnormal condition indicators), and a third queue for asset status information (e.g., location). Other arrangements are possible depending on the level of granularity desired.

As described above, the data inclusion system 502 may perform other functions in addition to those illustrated in fig. 6. For example, the data intake system 502 can also store the received asset-related data in one or more of the databases 510 for subsequent access or archival purposes. In one example, the data may be stored with a timestamp indicating the date and time the data was added to the database. The data may be stored in the database in several ways. For example, data may be stored in chronological order, organized based on data source type (e.g., based on asset, asset type, sensor, or sensor type), or organized by abnormal error indicators, among other examples.

C. Data analysis of asset-related information

FIG. 7 is a functional block diagram 700 illustrating some representative functions that may be performed by the data analysis system 504 after it receives asset-related data from the data intake system 502. As shown in fig. 7, the data analysis system 504 may include a rules engine 704, a routing engine 706, a notification engine 708, a data science engine 710, and a data sharing engine 712, all of which may be interconnected by a messaging layer (e.g., Kafka messaging layer) that pushes data between these functional blocks. Additionally, the data analysis system 504 can include and/or be coupled to at least one of the databases 510, shown here as database 714. The data analysis system 504 may also include other functional components.

The data analysis system 504 may first receive asset-related information from the data intake system 502 via an interface, such as an API. In response, the data analysis system 504 may place the received data on the messaging layer while storing a copy of the received data in a database 714, which may serve as a master database for the platform for providing asset-related data users and other platforms to the platform. As described above, the messaging layer of the data analysis system may provide event-driven push communications between the different engines of the data analysis system 504. In practice, the messaging layer may be comprised of a variety of different topics (not shown) that facilitate this event-driven push communication. For example, the messaging layer may include a plurality of incoming topics, each topic associated with a respective category of data and corresponding to a respective queue in the data intake system 502, in which case the data analysis system 504 may place the received data on the messaging layer by writing the received data to an appropriate intake topic. The messaging layer may then route the received data to the rules engine 704.

In turn, the rules engine 704 may determine what the data analysis system 504 should do with the asset-related data received from the data intake system 502. The determination may take various forms. As one example, based on asset-related information, the rules engine 704 may determine that the data analysis system 504 should provide various types of notifications, such as network alerts and email notifications, among others. These notifications may relate to the operation of the asset, the operation of the platform, or other relevant subject matter of interest to the user. As another example, based on the received asset-related data, the rules engine 704 may determine that asset-related information should be provided to the data science engine. As another example, the rules engine 704 may determine that certain data should be used for external access via an API. As another example, the rules engine 704 may determine that certain data (e.g., portions of the received asset-related data) and/or certain commands should be pushed to another platform via the communication network 108. As another example, the rules engine 704 may determine that asset-related information should be routed to and stored in certain databases in the platform 500.

The rules engine 704 may determine what the data analysis system 504 should do with the asset-related data based on a set of rules. In one embodiment, these rules may be configured in two layers. In general, the first layer of rules may cause the rules engine 704 to make a threshold determination of whether the received data has any possible correlation with other engines of the data analysis system 504, and if the received data does not have any possible correlation with other engines of the data analysis system, then such data is discarded. As such, the first-level rules may generally take the form of setting conditions that define data to be maintained by the rules engine 704. As an example, these conditions may be for the source, type, and/or content of the data. This may allow the data analysis system 504 to effectively narrow down the data set that needs to be further analyzed.

The second layer rules may then enable the rules engine 704 to determine what action to take based on the remaining data. The second tier rules may generally include (1) a set of one or more conditions related to the source, type, and/or content of the received data (among other factors), and (2) corresponding actions to be performed by the platform when this set of conditions is satisfied. These conditions and corresponding actions may take many different forms.

For example, one class of second-layer rules may be directed to generating notifications based on received data. A representative example of such a category of rules may specify that a given user notification is to be generated when the operational data of the asset meets certain content conditions (e.g., when the sensor data values meet certain thresholds or certain abnormal-condition indicators have been received).

Another category of second level rules may run a data science model on the received data. Representative examples of such classes of rules may provide for certain types of asset operation data to be input into a data science engine configured to apply a given data science model (e.g., abnormal condition indicators for sensor data and/or assets to be input into a predictive failure model).

Another category of second layer rules might be directed to pushing certain data (and/or related commands) to other platforms in a network configuration. A representative example of such a category of rules may specify that asset operation data from a certain source of a particular type and/or meeting certain content conditions is to be pushed to a particular list of one or more other platforms in the network configuration (this may be referred to as an "access list"). For example, one real description of this type of rule may provide that when a dealer's platform receives data relating to the operation of certain asset models, the dealer's platform pushes this data to the manufacturers of those asset models. Another representative example of such a class of rules may specify that the output of a certain data science model is to be pushed to a specific list of one or more other platforms in a network configuration. (in this regard, the output of the data science model may be fed back to the rules engine 704 via a messaging layer, or there may be another example of a rules engine implemented at the output of the data science model). Other examples are also possible.

In some instances, the rules employed by the rules engine 704 may also be organized by data type. For example, the rules engine 704 may have different sets of rules corresponding to different intake topics for the messaging layer, such that the data analysis system 504 may more efficiently process data by applying a particular set of rules directly related to the data in the topic and not apply rules unrelated to the data in the topic. The rules employed by the rules engine 704 may also take various other forms.

Further, the rules employed by the rules engine 704 may be defined in various ways. In one embodiment, the rules may be defined by a user of the platform. For example, the platform may provide tools (which may be referred to as "data isolation" tools) by which a user may create, modify, and/or delete rules used by the rules engine 704. As one possible example, this tool may take the form of a GUI that may be accessed by a user via a client station on the communication network 108. Using this tool, a user may enter rules such as those described above.

In another implementation, certain rules may be received from another platform (e.g., a master platform). For example, a manufacturer may release a new product, such as a new locomotive model that may need to be managed by the platform. In connection with this product version, the host platform may define new rules relating to the type and/or content of data received from the new locomotive model, and may then provide access to such rules to other platforms.

In another embodiment, certain rules may be predefined by the platform provider. Rules may also be defined in other ways.

It should also be understood that certain rules may be based on factors other than the source, type, and/or content of the received data. For example, a rule for pushing certain received data (and/or related commands) to another platform in the network configuration may also include a condition related to the recipient platform, such as a condition related to whether the recipient platform is eligible to participate in data sharing.

As a result of applying the rules, the rules engine 704 may generate an indication of what action should be performed based on the received data. In one example, this indication may take the form of metadata (e.g., in a header field) that is added to or otherwise associated with the received data. In another example, this indication may take the form of a separate command that is not associated with any underlying data. Other examples are also possible.

This indication of what action should be performed may take various forms and include various information, depending on the type of action. For example, if the action is to generate a given notification, the indication may specify the type of notification, the content of the notification, and/or the intended recipient of the notification. As another example, if the action is to apply a data science model to the received data, the indication may specify that the data science model is to be applied to the data. As another example, if the action is to push the received data to one or more other platforms, the indication may specify the one or more other platforms that are to receive the data. The indication of what action should be performed may also take various other forms.

The messaging layer may push the output of the rules engine 704 to the routing engine 706. In fact, the above scenario may be implemented by a message layer topic located between the rules engine 704 and the routing engine 706. Routing engine 706, in turn, is generally operable to route the output of the rules engine to the appropriate engine in data analysis platform 704. For example, routing engine 706 may (1) determine where to route the output of the rules engine based on an indication of what action should be performed, (2) prepare the output for routing to the target engine (which may involve, for example, generating an appropriate command to send the specified engine), and then (3) cause the output to be pushed to the destination engine via the messaging layer (e.g., by writing the output to an appropriate messaging layer topic). In practice, this routing engine 706 may take the form of an event-to-command engine.

For example, if the action is to generate a given notification, routing engine 706 can cause the output of the rules engine to be pushed to notification engine 708 via the messaging layer, which can then generate the given notification. As another example, if the action is to apply a given data science model to the received data, routing engine 706 may cause the output of the rules engine to be pushed via the messaging layer to data science engine 710, which may then run the application of the given data science model on the received data. As another example, if the action is to push certain received and/or generated data to another platform, routing engine 706 may cause the output of the rules engine to be pushed via the messaging layer to data sharing engine 712, which may in turn push the data to data sharing system 506.

As described above, the data analysis system 504 may perform other functions in addition to those illustrated in fig. 7.

D. Data sharing of asset-related information

FIG. 8 is a functional block diagram 800 illustrating some representative functions that may be performed by the data sharing system 506 after the data sharing system receives data from the data analysis system 504. As shown in fig. 8, the data sharing system 506 may include a mechanism for pushing data to another platform, and these functions may include create route commands 802, prepare data 804, and push data 806. In addition, the data sharing system 506 may also include functionality for receiving data from another platform, and these functions may include verification data 812 and pre-processing data 814. These functional blocks may enable the data sharing system 506 to generally facilitate communications between the example platform 500 and other platforms via the communication network 108.

The create route message function 802 may be used to generate messages to push to each of one or more other platforms. Indeed, create route message function 802 may generate these messages based on data received from data sharing engine 712, which may include the results of a determination of what action to take by the rules engine, and each such message may include (1) a command indicating what action a given platform is about to take, and (2) data for performing this action.

The message generated by create route message function 802 may take various forms. In one embodiment, this message may include a command instructing another platform to perform a CRUD action (e.g., create, read, update, or delete) for certain asset-related data. In this regard, along with the command, the information may include an identification of the asset-related data, and possibly also the content of the asset-related data that is the subject of the CRUD action (e.g., create, read, and update actions). This type of routing messages may thus enable different platforms in a network configuration to share and synchronize their asset-related data.

In another embodiment, this message may include a command instructing another platform to implement new logic, such as a new data model, new rules for preprocessing received data, and/or new rules indicating what action to take based on the received data. In this regard, the message may contain a definition of the new logic along with the command. This type of routing messages may thus enable certain platforms (e.g., a master platform) to assign logic to other platforms in a network configuration.

The message generated by the create route message function 802 may also take other forms, including the possibility that the message may include asset-related data without any corresponding command — in which case the data sharing system 506 may rely on the receiving platform to determine what action to take on the asset-related data.

The prepare data function 804 is generally operable to prepare messages before being sent out of the platform. This preparation function may take various forms. As one example, the preparation function 804 may include formatting the message according to the platform that is to receive the data. As another example, the prepare function 804 may include clearing data and/or clearing data before routing the data to another platform. For example, the data may have location information, sensitive personal information (e.g., social security numbers) or sensitive financial information that should not be published outside the platform, and this information may be removed from the data. The prepare data function 804 may take other forms as well.

The push data function 806 may generally be used to push routing messages to one or more other platforms via the communication network 108. As part of this process, the push data function 806 may establish a connection with one or more other platforms via the communication 108. For example, as described above, data routed to the data sharing system 506 via the sharing engine 712 may specify one or more other platforms to receive the data, and the push data function 806 may use this information to establish a connection with the one or more other platforms. As one possible example, the received data may include IP addresses of one or more other platforms (and so on), and the establish connection function 802 may use these IP addresses to establish a TCP or HTTP connection with each of the one or more other platforms via the communication network 108. Additionally, the push data function 806 may need to provide authentication information (e.g., user name, password, etc.) for one or more other platforms in order to establish the connection. Thereafter, the push data function 806 may then push routing messages to one or more other platforms via the connections established with each such platform.

As described above, the data sharing system 506 may also perform certain functions after it receives a routing message from another platform (e.g., the validation data function 812 and the pre-processing data function 814).

Verification data function 812 may be used to verify routing messages received from other platforms. For example, the verification data function 812 may verify the sender of the routing message and/or the content of the routing message. The pre-processing data function 814 may perform one or more pre-processing functions on the received routing message, such as data mapping, data deduplication, and/or data merging.

The data sharing system 506 may then provide routing messages received from other platforms (e.g., via an API POST) to the data intake system 502, which may then perform one or more of the functions described above on the routing messages. For example, the data intake system 502 can perform at least the action recognition function 610 on the routing message to identify what action should be taken based on the received routing message, and then place the routing message in a form for notifying the data analysis system 504 of the identified action. In practice, this may involve interpreting a command contained in the routing message, and then causing platform 500 to execute this command.

For example, if the routing message contains a command to take a CRUD action with respect to asset-related data, the action identification function 610 may interpret this command and then cause the data analytics system 504 to take the requested CRUD action (e.g., by creating, reading, updating, or deleting certain asset-related data). As another example, if the routing message includes a command to implement new logic, the action recognition function 610 may interpret this command and then cause the data inclusion system 502 and/or the data analysis system 504 to implement the new logic. Other examples are also possible.

V. exemplary flow chart

Turning now to fig. 9, a flow diagram is depicted illustrating an example method 900 for determining whether to share asset-related data in a network of platforms based on criteria received from another platform (e.g., a master or seed platform). For the method 900 discussed below, as well as other methods, the operations illustrated by the blocks in the flow diagrams may be performed in accordance with the discussion above. Further, one or more operations discussed above may be added to a given flowchart.

At block 902, method 900 may involve a first platform (e.g., owner platform 106) in network configuration 100 receiving criteria from a second platform (e.g., manufacturer platform 102) governing whether owner platform 106 is permitted to share asset-related data with other platforms in the system. This criterion may be based on the reliability of the asset-related data stored at the first platform. At block 904, method 900 may involve the first platform evaluating the reliability of its stored asset-related data. At block 906, the method 900 may involve the first platform applying the received criteria to the evaluated reliability of its stored asset-related data and thereby making a determination as to whether the first platform is permitted to share the asset-related data with one or more platforms in the network configuration 100. At block 908, the method 900 may involve the first platform operating according to the determination made at block 906.

FIG. 10 depicts a flow diagram of an example method 1000 for sharing asset-related data with another platform via a network. At block 1002, method 1000 may involve a first platform (e.g., owner platform 106) in network configuration 100 receiving data associated with one or more assets. At block 1004, method 1000 may involve a first platform making a determination to push a given portion of received data to a second platform (e.g., manufacturer platform 102) in network configuration 100. At block 1006, the method 1000 may involve the first platform preparing a given portion of the received data for transmission to the second platform. At block 1008, the method 1000 may involve the first platform pushing a given portion of the received data to the second platform via the network connection.

Conclusion VI

The above description discloses, among other things, various example systems, methods, devices, and articles of manufacture including, among other components, firmware and/or software executing on hardware. It should be understood that such examples are merely illustrative and should not be considered as limiting. For example, it is contemplated that any or all of the firmware, hardware, and/or software aspects or components could be embodied exclusively in hardware, exclusively in software, exclusively in firmware, or in any combination of hardware, software, and/or firmware. Accordingly, the examples provided are not the only way to implement such systems, methods, devices, and/or articles of manufacture.

Furthermore, references herein to "an embodiment" mean that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one example embodiment of the invention. The appearances of such phrases in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. As such, embodiments described herein, explicitly and implicitly understood by those of ordinary skill in the art, may be combined with other embodiments.

The description is presented primarily with illustrative environments, systems, procedures, steps, logic blocks, processes, and other symbolic representations of operations that are directly or indirectly analogous to data processing devices coupled to a network. These process descriptions and representations are generally used by those skilled in the art to most effectively convey the substance of their work to others skilled in the art. Numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be understood by those skilled in the art that certain embodiments of the present invention may be practiced without the specific details. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the embodiments. The scope of the invention is, therefore, indicated by the appended claims rather than by the foregoing description of the embodiments.

When reading any appended claims to cover a purely software and/or firmware implementation, at least one of the elements in at least one example is hereby expressly defined to include a tangible, non-transitory medium such as a memory, DVD, CD, Blu-ray, etc. storing the software and/or firmware.

To the extent that the examples described herein refer to operations performed or initiated by a participant, such as a "person," "operator," "user," or other entity, the foregoing is merely for purposes of example and explanation. The claims should not be construed to require action by such participants unless expressly recited in the claim language.

Claims (40)

1. In a system comprising a plurality of platforms communicatively coupled via a network, wherein each platform is configured to receive, process and store respective asset-related data, a computer-implemented method comprising:

receiving, at a first platform, data associated with one or more assets;

making, by the first platform, a determination that a given portion of the received data is to be pushed to a second platform;

and

based on the determination, the first platform (a) prepares the given portion of the received data for transmission to the second platform, and (b) pushes the given portion of the received data to the second platform via a network connection.

2. The computer-implemented method of claim 1, wherein receiving the data associated with the one or more assets comprises receiving the data on a messaging layer of the first platform.

3. The computer-implemented method of claim 1, further comprising:

a set of rules is maintained at the first platform including at least one rule indicating which data is to be pushed to the second platform.

4. The computer-implemented method of claim 3, wherein making the determination to push the given portion of the received data to a second platform comprises:

applying the set of rules to the received data to determine that the given portion of the received data is to be pushed to a second platform.

5. The computer-implemented method of claim 3, wherein the at least one rule indicating which data is to be pushed to the second platform is defined by a user of the first platform.

6. The computer-implemented method of claim 3, wherein the at least one rule indicating which data is to be pushed to the second platform comprises a rule indicating that data associated with a given group of assets is to be pushed to the second platform.

7. The computer-implemented method of claim 3, wherein the at least one rule indicating which data is to be pushed to the second platform comprises a rule indicating that a given type of data is to be pushed to the second platform.

8. The computer-implemented method of claim 1, wherein preparing the given portion of the received data for transmission to the second platform comprises generating a given command associated with the given portion of the received data, and wherein pushing the given portion of the received data to a second platform via the network connection comprises pushing the given command to the second platform with the given portion of the received data via the network connection.

9. The computer-implemented method of claim 8, wherein the given command comprises a command to perform one of a create action, a read action, an update action, or a delete action.

10. The computer-implemented method of claim 1, wherein preparing the given portion of the received data for transmission to the second platform comprises clearing the given portion of the received data.

11. The computer-implemented method of claim 1, wherein the first platform is associated with a first one of an asset manufacturer, an asset dealer, and an asset owner, and wherein the second platform is associated with a second one of the asset manufacturer, the asset dealer, and the asset owner.

12. A non-transitory computer-readable medium having instructions stored thereon that are executable to cause a first platform to:

receiving data associated with one or more assets;

making a determination that a given portion of the received data is to be pushed to a second platform; and

based on the determination, (a) preparing the given portion of the received data for transmission to the second platform, and (b) pushing the given portion of the received data to the second platform via a network connection.

13. The non-transitory computer-readable medium of claim 12, wherein the instructions executable to cause the first platform to receive the data associated with the one or more assets comprise instructions executable to cause the first platform to receive the data on a messaging layer of the first platform.

14. The non-transitory computer-readable medium of claim 12, further comprising instructions stored thereon that are executable to cause the first platform to:

a set of rules is maintained that includes at least one rule indicating which data is to be pushed to the second platform.

15. The non-transitory computer-readable medium of claim 14, wherein instructions executable to cause the first platform to make the determination that the given portion of the received data is to be pushed to a second platform comprise instructions executable to cause the first platform to apply the set of rules to the received data to determine that the given portion of the received data is to be pushed to a second platform.

16. The non-transitory computer-readable medium of claim 14, wherein the at least one rule indicating which data is to be pushed to the second platform is defined by a user of the first platform.

17. The non-transitory computer-readable medium of claim 14, wherein the at least one rule indicating which data is to be pushed to the second platform comprises a rule indicating that data associated with a given group of assets is to be pushed to the second platform.

18. The non-transitory computer-readable medium of claim 14, wherein the at least one rule indicating which data is to be pushed to the second platform includes a rule indicating that a given type of data is to be pushed to the second platform.

19. The non-transitory computer-readable medium of claim 14, wherein preparing the given portion of the received data to transmit to the second platform comprises generating a given command associated with the given portion of the received data, and wherein pushing the given portion of the received data to the second platform via the network connection comprises pushing the given command to the second platform with the given portion of the received data via the network connection.

20. A first platform, comprising:

a network interface configured to facilitate communication with one or more data sources and one or more other platforms via a communication network;

at least one processor;

a non-transitory computer-readable medium; and

program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor to cause the first platform to:

receiving data associated with one or more assets;

making a determination that a given portion of the received data is to be pushed to a second platform; and

based on the determination, (a) preparing the given portion of the received data for transmission to the second platform, and (b) pushing the given portion of the received data to the second platform via a network connection.

21. In a system comprising a plurality of platforms communicatively coupled via a network, wherein each platform is configured to receive, process and store respective asset-related data, a computer-implemented method comprising:

receiving, at a first platform from a second platform, criteria governing whether the first platform is permitted to share asset-related data with one or more other platforms in the system, wherein the criteria is based on a reliability of asset-related data stored at a platform;

the first platform evaluating the reliability of asset-related data stored at the first platform;

the first platform applying the received criteria to the evaluated reliability of asset-related data stored at the first platform and thereby making a determination as to whether the first platform is permitted to share asset-related data with the one or more other platforms; and

the first platform operates according to the determination.

22. The computer-implemented method of claim 21, wherein evaluating the reliability of asset-related data stored at the first platform comprises one or both of: (a) determining how many proportions of the asset-related data stored at the first platform were successfully mapped to a given data model and (b) determining how many proportions of the asset-related data stored at the first platform contain a set of preferred data fields after data mapping.

23. The computer-implemented method of claim 21, wherein making a determination as to whether the first platform is permitted to share asset-related data with one or more other platforms in the system comprises making a determination that the first platform is permitted to share asset-related data with the one or more other platforms.

24. The computer-implemented method of claim 23, wherein the first platform operating in accordance with the determination comprises:

the first platform begins sharing asset-related data with the one or more other platforms.

25. The computer-implemented method of claim 23, wherein the first platform operating in accordance with the determination comprises:

the first platform notifies the one or more other platforms that the first platform is permitted to share asset-related data.

26. The computer-implemented method of claim 21, wherein making a determination as to whether the first platform is permitted to share asset-related data with one or more other platforms in the system comprises making a determination that the first platform is not permitted to share asset-related data with the one or more other platforms.

27. The computer-implemented method of claim 26, wherein the first platform operating in accordance with the determination comprises:

the first platform disables its ability to share asset-related data to the one or more platforms.

28. The computer-implemented method of claim 21, further comprising:

logic that receives, at the first platform from the second platform, a message indicating a manner in which the first platform will process asset-related data; and

the first platform operates according to the received logic.

29. The computer-implemented method of claim 28, wherein the logic comprises a data model to be used by the first platform to map incoming asset-related data.

30. The computer-implemented method of claim 28, wherein the logic comprises data analysis rules to be applied by the first platform to incoming asset-related data.

31. The computer-implemented method of claim 21, wherein the second platform comprises a primary platform of the system.

32. A non-transitory computer-readable medium having instructions stored thereon that are executable to cause a first platform to:

receiving, from a second platform, criteria governing whether the first platform is permitted to share asset-related data with one or more other platforms in a system, wherein the criteria is based on a reliability of asset-related data stored at a platform;

evaluating the reliability of asset-related data stored at the first platform;

applying the received criteria to the evaluated reliability of asset-related data stored at the first platform and thereby making a determination as to whether the first platform is permitted to share asset-related data with the one or more other platforms; and

performing an operation according to the determination.

33. The non-transitory computer-readable medium of claim 32, wherein the instructions executable to cause the first platform to assess the reliability of asset-related data stored at the first platform comprise instructions executable to cause the first platform to assess the reliability of asset-related data stored at the first platform by one or both of: (a) determining how many proportions of the asset-related data stored at the first platform were successfully mapped to a given data model, and (b) determining how many proportions of the asset-related data stored at the first platform contain a set of preferred data fields after data mapping.

34. The non-transitory computer-readable medium of claim 32, wherein the instructions executable to cause the first platform to make the determination as to whether the first platform is permitted to share asset-related data with the one or more other platforms comprise instructions executable to cause the first platform to make a determination that the first platform is permitted to share asset-related data with the one or more other platforms.

35. The non-transitory computer-readable medium of claim 34, wherein the instructions executable to cause the first platform to operate according to the determination comprise:

instructions executable to cause the first platform to begin sharing asset-related data with the one or more other platforms.

36. The non-transitory computer-readable medium of claim 34, wherein the instructions executable to cause the first platform to operate according to the determination comprise:

instructions executable to cause the first platform to notify the one or more other platforms that the first platform is permitted to share asset-related data.

37. The non-transitory computer-readable medium of claim 34, wherein the instructions that are executable to cause the first platform to make the determination as to whether the first platform is permitted to share asset-related data with the one or more other platforms comprise instructions that are executable to cause the first platform to make a determination that the first platform is not permitted to share asset-related data with the one or more other platforms, and wherein the instructions that are executable to cause the first platform to operate in accordance with the determination comprise instructions that are executable to cause the first platform to disable its ability to share asset-related data to the one or more platforms.

38. The non-transitory computer-readable medium of claim 32, further comprising instructions executable to cause the first platform to:

logic that receives information from the second platform indicating a manner in which the first platform processes asset-related data; and

operating in accordance with the received logic.

39. The non-transitory computer-readable medium of claim 38, wherein the logic comprises one of a data model to be used by the first platform to map incoming asset-related data or a data analysis rule to be applied by the first platform to incoming asset-related data.

40. A first platform, comprising:

a network interface configured to facilitate communication with one or more data sources and one or more other platforms via a communication network;

at least one processor;

a non-transitory computer-readable medium; and

program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor to cause the first platform to:

receiving, from a second platform, criteria governing whether the first platform is permitted to share asset-related data with one or more other platforms in a system, wherein the criteria is based on a reliability of asset-related data stored at a platform;

evaluating the reliability of asset-related data stored at the first platform;

applying the received criteria to the evaluated reliability of asset-related data stored at the first platform and thereby making a determination as to whether the first platform is permitted to share asset-related data with the one or more other platforms; and

performing an operation according to the determination.