US20170353353A1 - Provisioning a Local Analytics Device - Google Patents

Abstract

Disclosed herein are systems, devices, and methods for provisioning a local analytics device to interact with a remote computing system on behalf of an asset that is coupled to the local analytics device and that is associated with a particular customer account hosted by the remote computing system.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS
• This application claims the benefit of U.S. Provisional Patent App. No. 62/345,170, filed on Jun. 3, 2016 and entitled Provisioning a Local Analytics Device, which is incorporated by reference in its entirety. This application also incorporates by reference each of the following patent applications in their entirety: U.S. Non-Provisional patent application Ser. No. 14/732,258, filed on Jun. 5, 2015 and entitled Asset Health Score; U.S. Non-Provisional patent application Ser. No. 14/744,352, filed on Jun. 19, 2015 and entitled Aggregate Predictive Model & Workflow for Local Execution; U.S. Non-Provisional patent application Ser. No. 14/963,207, filed on Dec. 8, 2015 and entitled Local Analytics at an Asset; U.S. Non-Provisional patent application Ser. No. ______, filed on Dec. ______, 2016 (Attorney Docket No. Uptake-00087) and entitled Facilitating the Provisioning of a Local Analytics Device.
BACKGROUND
• Machines (referred to herein as “assets”) and processing operations are essential elements of value creation in many industries. From locomotives that transfer cargo across countries to assembly lines that transform components into products and medical equipment that helps nurses and doctors to save lives, assets are foundational elements of economic activity. Asset cost and complexity can vary greatly depending on its intended use. For instance, some assets may include multiple subsystems that must operate in harmony for the asset to function properly (e.g., an engine, transmission, etc. of a locomotive).
• Because of the key role that assets play as essential factors of production, it is frequently desirable to minimize the time that they are unavailable. Accordingly, some have developed mechanisms to monitor and detect abnormal conditions within an asset to facilitate repairing the asset, perhaps with minimal downtime.
Overview
• Disclosed herein are systems, devices, and methods for provisioning a local analytics device coupled to an asset to thereby allow the local analytics device to interact with a remote computing system on behalf of the asset and a customer account that the asset is associated with.
• “Internet of Things” (IoT) technology has become widespread in everyday life, but in integrating such technology with everyday life, various problems have arisen. For example, an IoT device that is retrofitted to an existing device is faced with the challenges of recognizing that existing device, obtaining the required authorizations to act on behalf of that device, and/or routing data on behalf of that device to a proper recipient, among numerous other challenges.
• These, and other challenges, are especially prevalent in the IoT context of remote asset monitoring and management. For instance, in an asset condition-monitoring environment, an IoT device taking the form of a local analytics device collects a vast amount of data directly from or on behalf of a given asset, which is then typically processed by that device and subsequently routed to a remote asset-monitoring system. Provisioning such a local analytics device so that it is authorized to interact with the remote asset-monitoring system on behalf of the given asset presents a number of challenges including authorization as mentioned above, authentication, privacy and security, among other challenges. The abundant amount of asset data and number of assets with IoT-equipped analytics devices necessitates effective techniques for provisioning analytics devices to operate within an asset condition-monitoring environment.
• The example systems, devices, and methods disclosed herein seek to help address one or more of these issues. In accordance with example embodiments, a local analytics device coupled to an asset, a provisioning device communicatively coupled to the local analytics device, and an asset data platform may each perform one or more operations to help provision the local analytics device to interact with the asset data platform on behalf of the asset and a customer account hosted by the asset data platform that the asset is associated with. Distributing provisioning operations to multiple entities may help ensure that the local analytics device is operating on behalf of the asset in an authorized manner. As such, the various entities help to perform a multi-phase authorization process prior to the local analytics device operating on behalf of the asset.
• The provisioning operations described herein generally involve the exchange of credentials, where a particular credential enables a particular device to perform a particular, limited operation related to a particular asset. As such, a given credential may be role-specific and/or asset-specific. In some cases, a first, particular credential is required before a device can continue with provisioning operations described herein, such as exchanging with another device a second, particular credential. Specific credentials are discussed in further detail below, but generally, the operations described herein may involve asset-management credentials that may include or take the form of provisioning credentials or data-management credentials, among other credential types. In turn, data-management credentials may include specific, asset data-related credentials, such as analytics and/or data transfer credentials, among other examples.
• The process of provisioning a local analytics device to operate in an asset condition-monitoring environment may begin by a user (e.g., asset operator, technician, etc.) physically coupling the local analytics device to an asset. In example implementations, the local analytics device may be coupled to the asset in a relatively simple manner without requiring expert knowledge or physical modification of the asset. In one particular example, the local analytics device may be physically coupled to the asset via an asset interface, such as an On-Board Diagnostics (“OBD”) port or the like, thereby allowing the local analytics device to communicate with one or more of the asset's on-board computerized control systems. Various other asset interface types and possibilities of coupling a local analytics device to an asset are also possible.
• Before, after, or perhaps even simultaneously with the operation of physically coupling the local analytics device to the asset, a provisioning device may perform one or more provisioning operations as well. In general, the provisioning device may be a mobile computing device (e.g., smartphone, laptop, tablet, etc.) that runs a provisioning software application (e.g., a native or web application) that may or may not interact with other external systems and facilitates provisioning a local analytics device.
• As a preliminary step, the provisioning device and asset data platform may exchange data that results in one or more account credentials (e.g., usernames and corresponding passwords or other types of secure account credentials, such as security tokens) that are associated with a customer account hosted by the asset data platform and that provide access to the customer account. More specifically, the provisioning application running on the provisioning device may facilitate creating and/or associating existing customer accounts hosted by the asset data platform, creating and/or associating existing account credentials for a given customer account, authenticating inputted or otherwise exchanged account credentials (e.g., as a result of a log-in event or passing of a secure token), and/or accessing an existing customer account and information related thereto.
• In turn, the asset data platform may store one or more customer accounts that may include or otherwise be linked to databases that may include information associated with each customer account. Examples of such information may include account credentials, asset-role identifiers, asset-management credentials, asset-management permissions, data-management credentials, data-management permissions, asset identifiers, asset status information (e.g., registered or unregistered), and/or asset-related data posted by provisioned local analytics devices or other internal or external data sources. A customer account may include other information and/or may be stored by other computing systems independent of the asset data platform.
• In any event, after a customer account is established and account credentials are defined, the provisioning device may receive an account credential based on user inputs (e.g., via a user “log-in” event where the user inputs a username and password combination) and then transmit the received account credential to the asset data platform, which in turn may or may not authenticate the credential and either provide or deny access to the customer account.
• For example, the asset data platform will determine whether the account credential that it receives authorizes the provisioning device to access a particular customer account. If so, the asset data platform may then confirm whether provisioning permissions are associated with that account credential, and based on such a confirmation, identify one or more asset-management credentials associated with such particular provisioning permissions. The asset data platform may then transmit (preferably with some level of security) to the provisioning device one or more asset identifiers corresponding to registered and/or unregistered assets associated with the customer account, along with one or more asset-management credentials conferring one or more provisioning and/or data-management permissions intended for the devices that will perform the roles related to such permissions. The provisioning device may then utilize this information to further interact with the asset data platform and facilitate provisioning the local analytics device.
• Meanwhile, once the local analytics device is physically coupled to the asset, it may be configured to detect a change in physical state of the asset, such as a transition to a “power-on” state, a physical movement, or a change in an operating state, among other examples. After the local analytics device detects the change in physical state, it may proceed to perform various operations for the purposes of enabling it to operate within an asset condition-monitoring environment on behalf of the asset.
• In example embodiments, such operations may involve the local analytics device performing asset discovery operations to determine the identity of the asset that the local analytics device is currently physically coupled to. In general, the asset discovery operations involve the local analytics device determining an “asset signature” for the asset to which it is coupled, where the asset signature is indicative of the configuration of the asset (e.g., the subsystems, components, software versions, etc. that are part of the asset).
• In practice, the local analytics device may determine an asset signature in a variety of manners. Generally, the local analytics device determines an asset signature based on obtaining a plurality of data that is each indicative of a configuration parameter of the asset, which the local analytics device then utilizes to define the asset signature. Specific examples of how the local analytics device determines an asset signature are described in detail below, but such examples may generally involve the local analytics device analyzing asset data, either actively or passively, that is generated by the computer systems of the asset and/or performing a model-based asset identification process, among other examples.
• Preferably, the determined asset signature may be globally unique for the particular asset that the local analytics device is attached to, such that the local analytics device can distinguish between the particular asset and all other assets (e.g., across all customer accounts). However, such precision may not always be possible. Instead, the determined asset signature may be customer unique, such that the local analytics device can distinguish between the particular asset and any other asset that is also associated with a given customer account. To that end, the asset identification information may directly, or with additional analysis, identify at least the type of the asset (e.g., a bulldozer or excavator) or perhaps additional aspects of the configuration of the asset (e.g., the make, model, year of the asset, and/or the types of components and/or systems installed thereon). Other levels of precision for the asset signature are also possible.
• At any point before, after, or while identifying the asset, the local analytics device may send or receive a request to establish a communication link with a provisioning device. In practice, a provisioning device may seek to establish a communication link with the local analytics device in a variety of manners. In one particular example, this operation may involve establishing an ad-hoc network (e.g., a Bluetooth, mesh, USB, or other local wireless or wired network), which may involve the devices exchanging messages according to one or more protocols. The communication link may be established in other manners as well.
• In any event, after a connection is established between the local analytics device and the provisioning device, the local analytics device may provide the asset signature to the provisioning device. Based on the asset signature and the one or more asset identifiers provided by the asset data platform, the provisioning device may confirm that the asset signature corresponds to a particular asset associated with the particular customer account and confirm that the one or more asset-management credentials that it received from the asset data platform provide the provisioning device provisioning permissions with respect to the asset that the local analytics device is attached.
• If both of these confirmation steps are affirmative, the provisioning device may transmit one or more data-management credentials to the local analytics device that in turn serves to authorize the local analytics device to execute various operations on behalf of the connected asset according to any analytics and/or data transfer permissions associated with such credentials, such as ingesting data from the asset it is coupled to, executing particular asset-related models, and/or transmitting or receiving data to and from the asset data platform. Based on those permissions, the local analytics device may then perform one or more operations on behalf of the connected asset, provided that the local analytics device is authorized to do so.
• In instances where the asset signature cannot be confirmed, the provisioning device may either terminate the provisioning attempt or revert to a manual asset-identification operation (e.g., involving user inputs at the provisioning device). In example embodiments, the local analytics device and/or provisioning device may utilize manually entered asset information that is matched with the asset signature that is gathered by the local analytics device to automatically identify the asset in the future. This information may be provided to the asset data platform that maintains a “master database” of asset signatures and corresponding asset identifiers.
• As discussed above, the provisioning device may transmit one or more data-management credentials to the local analytics device as a result of an authorized “log-in” attempt. However, in certain situations, the provisioning device may have previously obtained (e.g., via a prior provisioning authentication session) an asset-management credential, and perhaps one or more account-specific asset identifiers, and stored that information. In example embodiments, the provisioning device may automatically execute an authentication session with the local analytics device after a connection is established with the local analytics device where the provisioning device exchanges a data-management credential that is based on the existence of a valid, stored asset-management credential. In some cases, the authentication session may involve the provisioning device utilizing data that is algorithmically related to any stored asset-management credentials to identify the data-management credential that is exchanged (e.g., the most recently stored information if it has stored multiple instances of such information).
• In any event, as noted above, the local analytics device may then utilize the data-management credential to interact with the asset data platform on behalf of the asset via a network that may be different from the communication link established with the provisioning device, thereby concluding the provisioning process and registering the asset with the particular customer account.
• After the local analytics device is provisioned, it may then interact with the asset and/or the asset data platform on behalf of the asset in accordance with the data-management permissions corresponding to the data-management credential. In example embodiments, the local analytics device may be allowed to ingest data from the asset, locally execute particular predictive models for the asset, publish data to the asset data platform on behalf of the asset (e.g., so that the asset data platform can execute, define, and/or modify a predictive model related to the operation of the asset), download from the asset data platform particular predictive models to be locally executed by the local analytics device for the asset, and/or instruct the asset data platform to perform particular data services for the asset, among various other example operations.
• Thus, the multi-actor and multi-phase provisioning process described above helps to securely manage authorizations within an asset condition-monitoring environment in a distributed manner. Moreover, this provisioning process limits the scope of operations that a given device or system can perform on behalf of a customer account, which may help protect the integrity of the customer account if a given credential is comprised. In this way, the provisioning process described herein helps to address several of the problems described above that arise from an IoT technological environment.
• While the foregoing discussion assumed that communication paths existed between the local analytics and provisioning devices with the asset data platform, the local analytics device may still be provisioned in cases where such paths do not exist. In some embodiments, the local analytics device may be provisioned so long as the local analytics device and provisioning device are able to establish a communication link between one another.
• In one example scenario where only the provisioning device is able to communicate with the asset data platform, some of the above-discussed provisioning operations may nonetheless still be performed. For instance, the provisioning device may still be utilized to facilitate authenticating account credentials and then provide the local analytics device a data-management credential. The local analytics device may still determine an asset signature and also store asset-related data during asset operation and then publish that data to the asset data platform upon detecting a network connection between it and the asset data platform at a time in the future.
• In another example scenario where only the local analytics device is able to communicate with the asset data platform, some of the above-discussed provisioning operations may nonetheless still be performed. For instance, the local analytics device may exchange the asset signature and the provisioning device may transmit a data-management credential previously received or otherwise derived by the provisioning device and stored thereon. The local analytics device may in turn begin interacting with the asset data platform on behalf of the asset based on the received data-management credential, in line with the above discussion.
• In yet another instance, neither the local analytics device nor the provisioning device may be able to communicate with the asset data platform but some of the above-discussed provisioning operations may nonetheless still be performed. For instance, the local analytics device may exchange the asset signature and the provisioning device may transmit a data-management credential to the local analytics device from a prior provisioning authentication session. The local analytics device may store asset-related data during asset operation and then later publish that data, based on the data-management credential, to the asset data platform upon detecting a network connection between it and the asset data platform at a time in the future. The asset data platform may then retroactively associate the transferred information with the proper customer account based on a parallel communication session between the provisioning device and the asset data platform that results in the asset data platform reconciling the data-management credential identified previously with the proper customer account. Other examples are also possible.
• As discussed above, examples provided herein are related to provisioning a local analytics device to act on behalf of an asset. In one aspect, a local analytics device configured to monitor operating conditions of an asset is provided. The local analytics device comprises an asset interface configured to couple the local analytics device to the asset, a network interface configured to communicatively couple the local analytics device to a remote computing system via a wide-area 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 local analytics device to: (a) obtain, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset, (b) based on the plurality of asset data, determine an asset signature for the asset, (c) transmit, via the network interface, to a computing device configured to execute an application for provisioning the local analytics device, the determined asset signature, (d) in response to transmitting the determined asset signature, receive, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset, and (e) utilize the data-management credential to interact with the remote computing system on behalf of the asset.
• In another aspect, a non-transitory computer-readable medium is provided having instructions stored thereon that are executable to cause a local analytics device coupled to an asset, via an asset interface of the local analytics device, to: (a) obtain, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset, (b) based on the plurality of asset data, determine an asset signature for the asset, (c) transmit, via a network interface, to a computing device configure to execute an application for provisioning the local analytics device, the determined asset signature, (d) in response to transmitting the determined asset signature, receive, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset, and (e) utilize the data-management credential to interact with a remote computing system on behalf of the asset, wherein the remote computing system is communicatively coupled with the local analytics device via a wide-area network.
• In yet another aspect, a method performed by a local analytics device coupled to an asset via an asset interface is provided to provision the local analytics device to interact with a remote computing system on behalf of the asset. The method comprises: (a) obtaining, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset, (b) based on the plurality of asset data, determining an asset signature for the asset, (c) transmitting, via a network interface of the local analytics device, to a computing device executing an application for provisioning the local analytics device, the determined asset signature, (d) in response to transmitting the determined asset signature, receiving, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset, and (e) utilizing the data-management credential to interact with the remote computing system on behalf of the asset.
• One of ordinary skill in the art will appreciate these as well as numerous other aspects in reading the following disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
• FIG. 1 depicts an example network configuration in which example embodiments may be implemented.
• FIG. 2 depicts a simplified block diagram of an example asset.
• FIG. 3 depicts a conceptual illustration of example abnormal-condition indicators and triggering criteria.
• FIG. 4 depicts a structural diagram of an example platform.
• FIG. 5 depicts a functional block diagram of an example platform.
• FIG. 6 depicts a conceptual illustration of information related to a customer account and relationships between such information.
• FIG. 7 is a signal flow diagram that depicts example signal flows that may occur while provisioning a local analytics device.
• FIG. 8ais a flow diagram that depicts example operations that may occur for determining whether to store asset-related data locally.
• FIG. 8bis a flow diagram that depicts example operations that may occur for determining whether to transmit a credential based on stored information.
• FIG. 9 depicts a flow diagram of an example method for provisioning a local analytics device that may be performed by a local analytics device.
• FIG. 10 depicts a flow diagram of an example method for provisioning a local analytics device that may be performed by a provisioning device.
• FIG. 11 depicts a flow diagram of an example method for provisioning a local analytics device that may be performed by an asset data platform.
DETAILED DESCRIPTION
• The following disclosure makes reference to the accompanying figures and several exemplary scenarios. One of ordinary skill in the art will understand that such references are for the purpose of explanation only and are therefore not meant to be limiting. Part or all of the disclosed systems, devices, and methods may be rearranged, combined, added to, and/or removed in a variety of manners, each of which is contemplated herein.
I. EXAMPLE NETWORK CONFIGURATION
• Turning now to the figures,FIG. 1 depicts anexample network configuration100 in which example embodiments may be implemented. As shown, thenetwork configuration100 includes at its core aremote computing system102 that may be configured as an asset data platform, which may communicate via acommunication network104 with one or more assets, such asrepresentative assets106 and108, one or more data sources, such asrepresentative data source110, and one or more mobile computing devices, such as representative provisioning device114 (e.g., a mobile computing device that includes an installed provisioning application, which is discussed in detail below). It should be understood that the network configuration may include various other components as well.
• Broadly speaking, the asset data platform102 (sometimes referred to herein as an “asset condition monitoring system”) may take the form of one or more computer systems that are configured to receive, ingest, process, analyze, and/or provide access to asset-related data. For instance, a platform may include one or more servers (or the like) having hardware components and software components that are configured to carry out one or more of the functions disclosed herein for receiving, ingesting, processing, analyzing, and/or providing access to asset-related data. Additionally, a platform may include one or more user interface components that enable a platform user to interface with the platform. In practice, these computing systems may be located in a single physical location or distributed amongst a plurality of locations and may be communicatively linked via a system bus, a communication network (e.g., a private network), or some other connection mechanism. Further, the platform may be arranged to receive and transmit data according to dataflow technology, such as TPL Dataflow or NiFi, among other examples. The platform may take other forms as well. Theasset data platform102 is discussed in further detail below with reference toFIG. 4.
• As shown inFIG. 1, theasset data platform102 may be configured to communicate, via thecommunication network104, with the one ormore assets106,108,data sources110, and/or mobile computing devices114 (or other output devices/systems) in thenetwork configuration100. For example, theasset data platform102 may receive asset-related data, via thecommunication network104, that is sent by one or more assets, data sources, and/or mobile computing devices. As another example, theasset data platform102 may transmit asset-related data and/or commands, via thecommunication network104, for receipt by an output system (e.g., a client station, a work-order system, a parts-ordering system, etc.), and/or mobile computing device. Additionally, theasset data platform102 may be configured to receive, via thecommunication network104, customer account-related data (e.g., account credentials, data-management credentials, account registration information, etc.) from mobile computing devices and/or local analytics devices and transmit customer account-related data (e.g., asset-management credentials, access permissions, account details, etc.) to mobile computing devices and/or local analytics devices. Theasset data platform102 may engage in other types of communication via thecommunication network104 as well.
• In general, thecommunication network104 may include one or more computing systems and network infrastructure configured to facilitate transferring data betweenasset data platform102 and the one or more assets, data sources, mobile computing devices, and/or output systems in thenetwork configuration100. Thecommunication network104 may be or may include one or more Wide-Area Networks (WANs) and/or Local-Area Networks (LANs), which may be wired and/or wireless and may support secure communication. In some examples, thecommunication network104 may include one or more cellular networks and/or the Internet, among other networks. Thecommunication network104 may operate according to one or more communication protocols, such as LTE, CDMA, GSM, LPWAN, WiFi, Bluetooth, Ethernet, HTTP/S, TCP, CoAP/DTLS and the like. Although thecommunication network104 is shown as a single network, it should be understood that thecommunication network104 may include multiple, distinct networks that are themselves communicatively linked. Further, in example cases, thecommunication network104 may facilitate secure communications between network components (e.g., via encryption or other security measures). Thecommunication network104 could take other forms as well.
• Further, although not shown, the communication path between theasset data platform102 and the one or more assets, data sources, mobile computing devices, and/or output systems may include one or more intermediate systems. For example, the one or more assets and/or data sources may send asset-related data to one or more intermediary systems, such as an asset gateway or an organization's existing platform (not shown), and theasset data platform102 may then be configured to receive the asset-related data from the one or more intermediary systems. As another example, the one or more assets may send asset-related data to one or more mobile computing devices, such asrepresentative provisioning device114, and theasset data platform102 may then be configured to receive the asset-related data from the mobile computing device. Further still, theasset data platform102 may communicate with an output system via one or more intermediary systems, such as a host server or gateway (not shown). Many other configurations are also possible.
• In general, theassets106 and108 may take the form of any machine configured to perform one or more operations (which may be defined based on the field) and may also include equipment configured to transmit data indicative of the operation of the given asset (i.e., operating conditions) and/or receive data from other systems. The transmitted data may take various forms, examples of which may include operating data, such as sensor/actuator data (e.g., signal data) and/or abnormal-condition indicators (e.g., fault codes), identifying data for the asset, location data for the asset, etc. The received data may take various forms, examples of which may include configuration information, commands, program updates, job instructions and other information useful to monitor, coordinate and/or manage the asset and its operation. Various other examples of transmitted and received data are also possible, some of which are discussed below.
• Representative examples of asset types may include transportation machines (e.g., locomotives, aircrafts, passenger vehicles, semi-trailer trucks, ships, etc.), industrial machines (e.g., mining equipment, construction equipment, processing equipment, assembly equipment, etc.), medical machines (e.g., medical imaging equipment, surgical equipment, medical monitoring systems, medical laboratory equipment, etc.), utility machines (e.g., turbines, solar farms, etc.), and unmanned aerial vehicles, among other examples. Additionally, the assets of each given type may have various different classes (e.g., brand, make, model) and/or the assets may vary in configuration in other manners (e.g., firmware version, type of components installed on the given asset, operating history including cumulative usage information, among others, and combinations of uniquely identifying information for that asset, etc.) and/or may be associated with different combinations of information that may be used to uniquely identify the given asset.
• As such, in some examples, theassets106 and108 may each be of the same type (e.g., a fleet of locomotives or aircrafts, a group of wind turbines, a pool of milling machines, or a set of magnetic resonance imagining (MM) machines, among other examples) and perhaps may be of the same class (e.g., the same brand, make, model, etc.), yet potentially differ in some ways with respect to their individual configuration. In other examples, theassets106 and108 may have different asset types or classes. For instance,assets106 and108 may be different pieces of equipment at a job site (e.g., an excavation site) or a production facility, among numerous other examples. Those of ordinary skill in the art will appreciate that these are but a few examples of assets and that numerous others are possible and contemplated herein.
• Depending on an asset's configuration, the asset may also include one or more subsystems configured to perform one or more respective operations. For example, in the context of transportation assets, subsystems may include engines, transmissions, drivetrains, fuel systems, battery systems, exhaust systems, braking systems, electrical systems, signal processing systems, generators, gear boxes, rotors, and hydraulic systems, among numerous other examples. In practice, an asset's multiple subsystems may operate in parallel or sequentially in order for an asset to operate. Representative assets are discussed in further detail below with reference toFIG. 2.
• In general, thedata source110 may be or include one or more computing systems configured to collect, store, and/or provide data that is related to the assets or is otherwise relevant to the functions performed by theasset data platform102. For example, thedata source110 may collect and provide operating data that originates from the assets (e.g., historical operating data), in which case thedata source110 may serve as an alternative source for such asset operating data. As another example, thedata source110 may be configured to provide data that does not originate from the assets, which may be referred to herein as “external data.” Such a data source may take various forms.
• In one implementation, thedata source110 could take the form of an environment data source that is configured to provide data indicating some characteristic of the environment in which assets are operated. Examples of environment data sources include weather-data servers, global navigation satellite systems (GNSS) servers, map-data servers, and topography-data servers that provide information regarding natural and artificial features of a given area, among other examples.
• In another implementation, thedata source110 could take the form of asset-management data source that provides data indicating events or statuses of entities (e.g., other assets) that may affect the operation or maintenance of assets (e.g., when and where an asset may operate or receive maintenance). Examples of asset-management data sources include asset-maintenance servers that provide information regarding inspections, maintenance, services, and/or repairs that have been performed and/or are scheduled to be performed on assets, traffic-data servers that provide information regarding air, water, and/or ground traffic, asset-schedule servers that provide information regarding expected routes and/or locations of assets on particular dates and/or at particular times, defect detector systems (also known as “hotbox” detectors) that provide information regarding one or more operating conditions of an asset that passes in proximity to the defect detector system, and part-supplier servers that provide information regarding parts that particular suppliers have in stock and prices thereof, among other examples.
• Thedata source110 may also take other forms, examples of which may include fluid analysis servers that provide information regarding the results of fluid analyses and power-grid servers that provide information regarding electricity consumption, among other examples. One of ordinary skill in the art will appreciate that these are but a few examples of data sources and that numerous others are possible.
• In practice, theasset data platform102 may receive data from thedata source110 by “subscribing” to a service provided by the data source. However, theasset data platform102 may receive data from thedata source110 in other manners as well.
• In example embodiments, theprovisioning device114 may take the form of a mobile (or stationary or embedded) computing device configured to facilitate provisioning a local analytics device (discussed in detail below) to interact with theasset data platform102 on behalf of an asset (e.g., the asset108) and customer account associated with that asset. More particularly, theprovisioning device114 may include hardware components such as a user interface, a network interface, a processor, and data storage that may contain software components that enable the device to perform the various functions described herein. In some examples, theprovisioning device114 may run a native software application and/or a web browser capable of accessing a web application provided by theasset data platform102 that may facilitate communications with theasset data platform102 and/orassets106 and108 via their respective local analytics devices. Theprovisioning device114 may be configured to generate credentials based on received credentials via functionality from a particular application (e.g., a provisioning application) or some other secure module that is independent of the particular application. Representative examples of provisioning devices may include a laptop, a netbook, a tablet, a smartphone, a personal digital assistant (PDA), a stationary computer remote or attached to an asset, or any other such device now known or later developed.
• It should be understood thatnetwork configuration100 may include various other output systems or devices for facilitating interactions withasset data platform102, which may take the form of mobile computing devices, desktop, industrial, or embedded computers, among other examples. Examples of output systems may include a work-order system configured to output a request for a mechanic or the like to repair an asset or a parts-ordering system configured to place an order for a part of an asset and output a receipt thereof, among others.
• It should be understood that thenetwork configuration100 is one example of a network in which embodiments described herein may be implemented. Numerous other arrangements are possible and contemplated herein. For instance, other network configurations may include additional components not pictured and/or more or less of the pictured components.
II. EXAMPLE ASSET
• Turning toFIG. 2, a simplified block diagram of anexample asset200 is depicted. Either or both ofassets106 and108 fromFIG. 1 may be configured like theasset200. As shown, theasset200 may include one ormore subsystems202, one ormore sensors204, one ormore actuators205, acentral processing unit206,data storage208, anetwork interface210, a user interface212, aposition unit214, and also alocal analytics device220, all of which may be communicatively linked (either directly or indirectly) by a system bus, network, or other connection mechanism. One of ordinary skill in the art will appreciate that theasset200 may include additional components not shown and/or more or less of the depicted components.
• Broadly speaking, theasset200 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 givensubsystem202.
• Generally, asubsystem202 may include a group of related components that are part of theasset200. Asingle subsystem202 may independently perform one or more operations or thesingle subsystem202 may operate along with one or more other subsystems to perform one or more operations. Typically, different types of assets, and even different classes of the same type of assets, may include different subsystems. Representative examples of subsystems are discussed above with reference toFIG. 1.
• As suggested above, theasset200 may be outfitted withvarious sensors204 that are configured to monitor operating conditions of theasset200 andvarious actuators205 that are configured to interact with theasset200 or a component thereof and monitor operating conditions of theasset200. In some cases, some of thesensors204 and/oractuators205 may be grouped based on aparticular subsystem202. In this way, the group ofsensors204 and/oractuators205 may be configured to monitor operating conditions of theparticular subsystem202, and the actuators from that group may be configured to interact with theparticular subsystem202 in some way that may alter the subsystem's behavior based on those operating conditions.
• In general, asensor204 may be configured to detect a physical property, which may be indicative of one or more operating conditions of theasset200, and provide an indication, such as an electrical signal, of the detected physical property. In operation, thesensors204 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, thesensors204 may be preconfigured with operating parameters for performing measurements and/or may perform measurements in accordance with operating parameters provided by the central processing unit206 (e.g., sampling signals that instruct thesensors204 to obtain measurements). In examples,different sensors204 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). In any event, thesensors204 may be configured to transmit electrical signals indicative of a measured physical property to thecentral processing unit206. Thesensors204 may continuously or periodically provide such signals to thecentral processing unit206.
• For instance,sensors204 may be configured to measure physical properties such as the location and/or movement of theasset200, in which case the sensors may take the form of GNSS sensors, dead-reckoning-based sensors, accelerometers, gyroscopes, pedometers, magnetometers, or the like. In example embodiments, one or more such sensors may be integrated with or located separate from theposition unit214, discussed below.
• Additionally,various sensors204 may be configured to measure other operating conditions of theasset200, examples of which may include temperatures, pressures, speeds, acceleration or deceleration rates, friction, power usages, fuel usages, fluid levels, runtimes, voltages and currents, magnetic fields, electric fields, presence or absence of objects, positions of components, and power generation, among other examples. One of ordinary skill in the art will appreciate that these are but a few example operating conditions that sensors may be configured to measure. Additional or fewer sensors may be used depending on the industrial application or specific asset.
• As suggested above, anactuator205 may be configured similar in some respects to asensor204. Specifically, anactuator205 may be configured to detect a physical property indicative of an operating condition of theasset200 and provide an indication thereof in a manner similar to thesensor204.
• Moreover, anactuator205 may be configured to interact with theasset200, one ormore subsystems202, and/or some component thereof. As such, anactuator205 may include a motor or the like that is configured to perform a mechanical operation (e.g., move) or otherwise control a component, subsystem, or system. In a particular example, an actuator may be configured to measure a fuel flow and alter the fuel flow (e.g., restrict the fuel flow), or an actuator may be configured to measure a hydraulic pressure and alter the hydraulic pressure (e.g., increase or decrease the hydraulic pressure). Numerous other example interactions of an actuator are also possible and contemplated herein.
• Generally, thecentral processing unit206 may include one or more processors and/or controllers, which may take the form of a general- or special-purpose processor or controller. In particular, in example implementations, thecentral processing unit206 may be or include microprocessors, microcontrollers, SoCs (“system on a chip”), application specific integrated circuits, digital signal processors, and the like. In turn, thedata storage208 may be or include one or more non-transitory computer-readable storage media, such as optical, magnetic, organic, or flash memory, among other examples.
• Thecentral processing unit206 may be configured to store, access, and execute computer-readable program instructions stored in thedata storage208 to perform the operations of an asset described herein. For instance, as suggested above, thecentral processing unit206 may be configured to receive respective sensor signals from thesensors204 and/oractuators205. Thecentral processing unit206 may be configured to store sensor and/or actuator data in and later access it from thedata storage208.
• Thecentral processing unit206 may also be configured to determine whether received sensor and/or actuator signals trigger any abnormal-condition indicators, such as fault codes. For instance, thecentral processing unit206 may be configured to store in thedata storage208 abnormal-condition rules, each of which include a given abnormal-condition indicator representing a particular abnormal condition and respective triggering criteria that trigger the abnormal-condition indicator. That is, each abnormal-condition indicator corresponds with one or more sensor and/or actuator measurement values that must be satisfied before the abnormal-condition indicator is triggered. In practice, theasset200 may be pre-programmed with the abnormal-condition rules and/or may receive new abnormal-condition rules or updates to existing rules from a computing system, such as theasset data platform102.
• In any event, thecentral processing unit206 may be configured to determine whether received sensor and/or actuator signals trigger any abnormal-condition indicators. That is, thecentral processing unit206 may determine whether received sensor and/or actuator signals satisfy any triggering criteria. When such a determination is affirmative, thecentral processing unit206 may generate abnormal-condition data and then may also cause the asset'snetwork interface210 to transmit the abnormal-condition data to theasset data platform102 and/or cause the asset's user interface212 to output an indication of the abnormal condition, such as a visual and/or audible alert. Additionally, thecentral processing unit206 may log the occurrence of the abnormal-condition indicator being triggered in thedata storage208, perhaps with a timestamp.
• FIG. 3 depicts a conceptual illustration of example abnormal-condition indicators and respective triggering criteria for an asset. In particular,FIG. 3 depicts a conceptual illustration of example fault codes. As shown, table300 includescolumns302,304, and306 that correspond to Sensor A, Actuator B, and Sensor C, respectively, androws308,310, and312 that correspond to FaultCodes 1, 2, and 3, respectively.Entries314 then specify sensor criteria (e.g., sensor value thresholds) that correspond to the given fault codes.
• For example,Fault Code 1 will be triggered when Sensor A detects a rotational measurement greater than 135 revolutions per minute (RPM) and Sensor C detects a temperature measurement greater than 65° Celsius (C),Fault Code 2 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° C., andFault Code 3 will be triggered when Sensor A detects a rotational measurement greater than 100 RPM, Actuator B detects a voltage measurement greater than 750 V, and Sensor C detects a temperature measurement greater than 60° C. One of ordinary skill in the art will appreciate thatFIG. 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 toFIG. 2, thecentral processing unit206 may be configured to carry out various additional functions for managing and/or controlling operations of theasset200 as well. For example, thecentral processing unit206 may be configured to provide instruction signals to thesubsystems202 and/or theactuators205 that cause thesubsystems202 and/or theactuators205 to perform some operation, such as modifying a throttle position. Additionally, thecentral processing unit206 may be configured to modify the rate at which it processes data from thesensors204 and/or theactuators205, or thecentral processing unit206 may be configured to provide instruction signals to thesensors204 and/oractuators205 that cause thesensors204 and/oractuators205 to, for example, modify a sampling rate. Moreover, thecentral processing unit206 may be configured to receive signals from thesubsystems202, thesensors204, theactuators205, the network interfaces210, the user interfaces212, and/or theposition unit214 and based on such signals, cause an operation to occur. Further still, thecentral processing unit206 may be configured to receive signals from a computing device, such as a diagnostic device, that cause thecentral processing unit206 to execute one or more diagnostic tools in accordance with diagnostic rules stored in thedata storage208. Other functionalities of thecentral processing unit206 are discussed below.
• Thenetwork interface210 may be configured to provide for communication between theasset200 and various network components connected to thecommunication network104. For example, thenetwork interface210 may be configured to facilitate wireless communications to and from thecommunication network104 and may thus take the form of an antenna structure and associated equipment for transmitting and receiving various over-the-air signals. In practice, thenetwork interface210 may be configured according to a communication protocol, such as but not limited to any of those described above. In some cases, theasset200 may not include thenetwork interface210. Other examples are possible as well.
• The user interface212 may be configured to facilitate user interaction with theasset200 and may also be configured to facilitate causing theasset200 to perform an operation in response to user interaction. Examples of user interfaces212 include touch-sensitive interfaces, mechanical interfaces (e.g., levers, buttons, wheels, dials, keyboards, etc.), and other input interfaces (e.g., microphones), among other examples. In some cases, the user interface212 may include or provide connectivity to output components, such as display screens, speakers, headphone jacks, and the like.
• Theposition unit214 may be generally configured to facilitate performing functions related to geo-spatial location/position and/or navigation. More specifically, theposition unit214 may be configured to facilitate determining the location/position of theasset200 and/or tracking theasset200's movements via one or more positioning technologies, such as a GNSS technology (e.g., GPS, GLONASS, Galileo, BeiDou, or the like), triangulation technology, and the like. As such, theposition unit214 may include one or more sensors and/or receivers that are configured according to one or more particular positioning technologies.
• In example embodiments, theposition unit214 may allow theasset200 to provide to other systems and/or devices (e.g., the asset data platform102) position data that indicates the position of theasset200, which may take the form of GPS coordinates, among other forms. In some implementations, theasset200 may provide to other systems position data continuously, periodically, based on triggers, or in some other manner. Moreover, theasset200 may provide position data independent of or along with other asset-related data (e.g., along with operating data).
• Thelocal analytics device220 may generally be configured to receive and analyze data related to theasset200 and based on such analysis, may cause one or more operations to occur at theasset200. For instance, thelocal analytics device220 may receive operating data for the asset200 (e.g., signal data or derived data based on signal data generated by thesensors204 and/or actuators205) and based on such data, may provide instructions to thecentral processing unit206, thesensors204, and/or theactuators205 that cause theasset200 to perform an operation. In another example, thelocal analytics device220 may receive location data from theposition unit214 and based on such data, may modify how it handles predictive models and/or workflows for theasset200. In still another example, thecentral processing unit206 may provide access to data indata storage208 that was not generated by thesensors204 and/or actuators205 (e.g., data generated by an embedded computer). Other example analyses and corresponding operations are also possible.
• To facilitate some of these operations, thelocal analytics device220 may include one ormore asset interfaces221 that are configured to couple thelocal analytics device220 to one or more of the asset's on-board systems. As such, the one ormore asset interfaces221 may take various forms, such as a diagnostic port or some other input/output connector.
• For instance, as shown inFIG. 2, thelocal analytics device220 may connect to the asset'scentral processing unit206 via anasset interface221, which may enable thelocal analytics device220 to receive data at the direction of the central processing unit206 (e.g., operating data that is generated bysensors204 and/oractuators205 and sent to thecentral processing unit206, position data generated by theposition unit214, or other asset data from data storage208) and then provide instructions to thecentral processing unit206. In this way, thelocal analytics device220 may indirectly interface with and receive data from other on-board systems of the asset200 (e.g., thesubsystems202,sensors204, and/or actuators205) via thecentral processing unit206.
• Additionally or alternatively, as shown inFIG. 2, thelocal analytics device220'sasset interface221 could interface to one ormore sensors204 and/oractuators205, which may enable thelocal analytics device220 to communicate directly with thesensors204 and/oractuators205.
• Further still, thelocal analytics device220 may additionally or alternatively connect to the asset via thelocal analytics device220'snetwork interface226 and the asset'snetwork interface210. Thelocal analytics device220 may interface with the on-board systems of theasset200 in other manners as well, including the possibility that the interfaces illustrated inFIG. 2 are facilitated by one or more intermediary systems that are not shown.
• In example embodiments, thelocal analytics device220 may be physically coupled to theasset200 either at the time theasset200 was manufactured or sometime after. That is, in some cases, thelocal analytics device220 may be added to theasset200 as after-market add-on equipment. Other examples are also possible.
• Moreover, thelocal analytics device220 may be configured to execute one or more operations that facilitate allowing thelocal analytics device220 to interact with theasset data platform102 on behalf of theasset200. As one example, interacting with theasset data platform102 may involve publishing asset-related data to theasset data platform102. Theasset data platform102 may then utilize such data for various purposes, such as defining, updating, and/or modifying asset-related model-workflows. The provisioning operations are discussed in further detail below.
• In practice, thelocal analytics device220 may locally perform advanced analytics and associated operations, such as executing a predictive model and corresponding workflow, for theasset200 that may otherwise not be able to be performed with the other on-asset components. As such, thelocal analytics device220 may help provide additional processing power and/or intelligence to theasset200.
• It should be understood that thelocal analytics device220 may also be configured to cause theasset200 to perform operations that are not related to a predictive model. For example, thelocal analytics device220 may receive data from a remote source, such as theasset data platform102 or one or more output devices, and based on the received data cause theasset200 to perform one or more operations. One particular example may involve thelocal analytics device220 receiving a firmware update for theasset200 from a remote source and then causing theasset200 to update its firmware. Another particular example may involve thelocal analytics device220 receiving a diagnosis instruction from a remote source and then causing theasset200 to execute a local diagnostic tool in accordance with the received instruction. Numerous other examples are also possible.
• As shown, in addition to the one or more asset interfaces discussed above, thelocal analytics device220 may also include aprocessing unit222, adata storage224, and anetwork interface226, all of which may be communicatively linked by a system bus, network, or other connection mechanism. Theprocessing unit222 may include any of the components discussed above with respect to thecentral processing unit206. In turn, thedata storage224 may be or include one or more non-transitory computer-readable storage media, which may take any of the forms of computer-readable storage media discussed above.
• Theprocessing unit222 may be configured to store, access, and execute computer-readable program instructions stored in thedata storage224 to perform the operations of a local analytics device described herein. For instance, theprocessing unit222 may be configured to receive respective sensor and/or actuator signals generated by thesensors204 and/oractuators205 and may execute a predictive model and corresponding workflow based on such signals. Other functions are described below.
• Thenetwork interface226 may be one more network interfaces configured the same or similar to the network interfaces described above. In one example, thenetwork interface226 may facilitate communication between thelocal analytics device220 and theasset data platform102. Additionally or alternatively, thenetwork interface226 may facilitate communication between thelocal analytics device220 and the provisioning device114 (as depicted inFIG. 1 by communication path112). In some such cases, thelocal analytics device220 andprovisioning device114 may perform various “pairing” operations that create an ad-hoc network between the two devices, such as a Bluetooth connection, mesh network, or the like. It should be understood that the one ormore network interfaces226 allow thelocal analytics device220 to communicate with other devices over separate networks and/or communication paths. For example, thelocal analytics device220 may communicate with theasset data platform102 via the communication network104 (e.g., a cellular network) and with theprovisioning device114 via an ad-hoc network link112 (e.g., Bluetooth, WiFi, CAN, LPWAN or mesh network) that is separate from thecommunication network104. Other examples are also possible.
• In some example implementations, thelocal analytics device220 may include and/or communicate with a user interface that may be similar to the user interface212. In practice, the user interface may be located remote from the local analytics device220 (and the asset200). Other examples are also possible.
• WhileFIG. 2 shows thelocal analytics device220 physically and communicatively coupled to its associated asset (e.g., the asset200) via one or more asset interfaces, it should also be understood that this might not always be the case. For example, in some implementations, thelocal analytics device220 may not be physically coupled to its associated asset and instead may be located remote from theasset200. In an example of such an implementation, thelocal analytics device220 may be wirelessly, communicatively coupled to theasset200. Other arrangements and configurations are also possible.
• For more detail regarding the configuration and operation of a local analytics device, please refer to U.S. application Ser. No. 14/963,207, which is incorporated by reference herein in its entirety.
• One of ordinary skill in the art will appreciate that theasset200 shown inFIG. 2 is but one example of a simplified representation of an asset and that numerous others are also possible. For instance, other assets may include additional components not pictured and/or more or less of the pictured components. Moreover, a given asset may include multiple, individual assets that are operated in concert to perform operations of the given asset. Other examples are also possible.
III. EXAMPLE PLATFORM
• FIG. 4 is a simplified block diagram illustrating some components that may be included in an exampleasset data platform400 from a structural perspective. In line with the discussion above, theasset data platform400 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 aprocessor402,data storage404,network interface406, and perhaps also a user interface410, all of which may be communicatively linked by acommunication link408, such as a system bus, network, or other connection mechanism.
• Theprocessor402 may include one or more processors and/or controllers, which may take the form of a general- or special-purpose processor or controller. In particular, in example implementations, theprocessing unit402 may include microprocessors, microcontrollers, application-specific integrated circuits, digital signal processors, and the like.
• In turn, thedata storage404 may comprise one or more non-transitory computer-readable storage mediums, examples of which may include volatile storage mediums such as random access memory, registers, cache, etc. and non-volatile storage mediums such as read-only memory, a hard-disk drive, a solid-state drive, flash memory, an optical-storage device, etc.
• Thedata storage404 may be provisioned with software components that enable theplatform400 to carry out the functions disclosed herein. These software components may generally take the form of program instructions that are executable by theprocessor402 and may be arranged together into applications, software development kits, toolsets, or the like. In addition, thedata storage404 may also be provisioned with one or more databases that are arranged to store data related to the functions carried out by the platform, examples of which include time-series databases, document databases, customer account databases, relational databases (e.g., MySQL), key-value databases, and graph databases, among others. The one or more databases in combination may also provide for polyglot storage.
• Thenetwork interface406 may be configured to facilitate wireless and/or wired communication between theplatform400 and various network components via thecommunication network104, such asassets106 and108,data source110, andprovisioning device114. As such, thenetwork interface406 may take any suitable form for carrying out these functions, examples of which may include wired or wireless technologies for local and/or remote communication, including Ethernet, serial bus interface (e.g., ModBus, OPC, CAN, RS-232 or RS-485, USB, etc.), a chipset and antenna adapted to facilitate wireless communication (e.g., any number of variants based on WiFi, Bluetooth, mesh, low power WAN, cellular or satellite), and/or any other interface that provides for wired and/or wireless communication. Thenetwork interface406 may also include multiple network interfaces that support various different types of data and control message authentication, authorization, accounting, encoding, compression, encryption and transfer, which may be either standardized or proprietary, some examples of which may include JSON, CBOR, XML, and Base64, HTTP/S, COAP/S, DDS, MQTT, SSH, MOSH, TLS, DTLS, TCP, UDP, SMS, IPV4 and IPV6 or 802.15.4. Other configurations are possible as well.
• Theexample asset platform400 may also support a user interface410 that is configured to facilitate user interaction with theplatform400 and may also be configured to facilitate causing theplatform400 to perform an operation in response to user interaction. This user interface410 may include or provide connectivity to various input components, examples of which include touch-sensitive interfaces, mechanical interfaces (e.g., levers, buttons, wheels, dials, keyboards, etc.), and other input interfaces (e.g., microphones), as well as programmatic interfaces including local or network APIs. Additionally, the user interface410 may include or provide connectivity to various output components, examples of which may include display screens, speakers, headphone jacks, and the like. Other configurations are possible as well, including the possibility that the user interface410 is embodied within a client station that is communicatively coupled to theasset data platform400.
• Referring now toFIG. 5, another simplified block diagram is provided to illustrate some components that may be included in an exampleasset data platform500 from a functional perspective. For instance, as shown, theexample platform500 may include adata intake system502 and adata analysis system504, each of which comprises a combination of hardware and software that is configured to carry out particular functions. Theplatform500 may also include one ormore databases506 coupled to one or more of thedata intake system502 and thedata analysis system504. In practice, these functional systems may be implemented on a single computer system or distributed across a plurality of computer systems.
• Thedata intake system502 may generally function to receive asset-related data and then provide at least a portion of the received data to thedata analysis system504. As such, thedata intake system502 may be configured to receive asset-related data from various sources, examples of which may include an asset, an asset-related data source, or an organization's existing infrastructure. The data received by thedata intake system502 may take various forms, examples of which may include analog signals, data streams, and/or network packets. Further, in some examples, thedata intake system502 may be configured according to a given dataflow technology, such as a NiFi receiver or the like.
• In some embodiments, before thedata intake system502 receives data from a given source (e.g., an asset, an asset-related data source, an organization's existing infrastructure, etc.), that source may be provisioned with adata agent508. In general, thedata agent508 may be a software component that functions to access the relevant data at the given data source, place the data in the appropriate format, and then facilitate the transmission of that data to theplatform500 for receipt by thedata intake system502. As such, thedata agent508 may cause the given source to perform operations such as compression and/or decompression, encryption and/or de-encryption, analog-to-digital and/or digital-to-analog conversion, filtration, amplification, and/or data mapping, among other examples. In other embodiments, however, the given data source may be capable of accessing, formatting, and/or transmitting data to theexample platform500 without the assistance of a data agent.
• The data received by thedata intake system502 may take various forms. As one example, the received data may include operating data for an asset such as, for example, signal data (e.g., sensor and/or actuator data), abnormal-condition indicators, asset event indicators, and asset location data. As another, the received data may include external data related to asset operation such as, for example, asset inspection/maintenance/repair information, hotbox data, weather data, etc. As yet another example, the received data may also include metadata, signal signatures, or the like that provide additional information about the received data, such as an identifier of the data source and/or a timestamp associated with the received data (e.g., a date and/or time at which the information was obtained). For instance, a unique identifier (e.g., a computer generated alphabetic, numeric, alphanumeric, or the like identifier) may be assigned to each asset, and perhaps to each sensor and actuator, and may be operable to identify the asset, sensor, or actuator from which data originates. The data received by thedata intake system502 may take other forms as well.
• Thedata intake system502 may also be configured to perform various pre-processing functions on the received data before it provides that data to the data analysis system, to ensure that the received data is clean, up to date, and consistent across records or data structures stored in theplatform500 that manage the data. For example, thedata intake system502 may map the received data into defined data structures and potentially drop any data that cannot be mapped to these data structures. As another example, thedata intake system502 may assess the reliability (or “health”) of the received data and potentially drop any unreliable data. As yet another example, thedata intake system502 may “de-dup” the received data by identifying any data has already been received by the platform and then ignoring or dropping such data. As still another example, thedata intake system502 may determine that the received data is related to data already stored in the platform's database506 (e.g., a different version of the same data) and then merge the received data and stored data together into one data structure or record. As a further example, thedata intake system502 may organize the received data into particular data categories (e.g., by placing the different data categories into different queues). Other functions may also be performed.
• In some embodiments, it is also possible that thedata agent508 may perform or assist with certain of these pre-processing functions. As one possible example, the data mapping function could be performed in whole or in part by thedata agent508 rather than thedata intake system502. Other examples are possible as well.
• Thedata intake system502 may further be configured to store the received data in thedatabase506 for later retrieval. In line with the discussion above, thedatabase506 may take various forms, examples of include a time-series database, document database, a relational database (e.g., MySQL), a key-value database, and a graph database, among others. Further, thedatabase506 may provide for poly-glot storage. For example, thedatabase506 may store the payload of received data in a first type of database (e.g., a time-series or document database) and store the associated metadata of received data in a second type of database that permits more rapid searching (e.g., a relational database). Other examples are possible as well.
• As shown, thedata intake system502 may then be communicatively coupled to thedata analysis system504. This interface between thedata intake system502 and thedata analysis system504 may take various forms. For instance, thedata intake system502 may be communicatively coupled to thedata analysis system504 via an API. Other interface technologies are possible as well.
• In one implementation, thedata intake system502 may provide, to thedata analysis system504, data that falls into three general categories: (1) signal data, (2) event data, and (3) asset status data. The signal data may generally take the form of raw or aggregated data representing the measurements taken by the sensors and/or actuators at the assets. The event data may generally take the form of data identifying events that relate to asset operation, such as asset events that correspond to indicators received from an asset (e.g., abnormal-condition indicators, asset event indicators, etc.), inspection events, maintenance events, repair events, fluid events, weather events, or the like. And asset status information may then include status information for the asset, such as an asset identifier, asset location data, etc. The data provided to thedata analysis system504 may also include other data and take other forms as well.
• Thedata analysis system504 may generally function to receive data from thedata intake system502, analyze that data, and then take various actions based on that data. For example, thedata analysis system504 may identify certain data that is to be output to a client station (e.g., based on a request received from the client station) and may then provide this data to the client station. As another example, thedata analysis system504 may determine that certain data satisfies a predefined rule and may then take certain actions in response to this determination, such as generating new event data or providing a notification to a user via the client station. As another example, thedata analysis system504 may use the received data to train and/or execute a predictive model related to asset operation, and thedata analysis system504 may then take certain actions based on the predictive model's output. As still another example, thedata analysis system504 may make certain data available for external access via an API.
• In order to facilitate one or more of these functions, thedata analysis system504 may be configured to provide a web application (or the like) that can be accessed and displayed by a client station. This web application may take various forms, but in general, the web application may comprise one or more web pages that can be displayed by the client station in order to present information to a user and also obtain user input. As another example, thedata analysis system504 may be configured to “host” or “drive” (i.e., provide data to) a native client application associated with the asset data platform that is installed and runs on a client station.
• In addition to analyzing the received data for taking potential actions based on such data, thedata analysis system504 may also be configured to store the received data intodatabase506. Thedatabase506 may persistently store the data for subsequent access by the platform or by other platforms. Additional data-storage related operations are discussed in further detail below.
• In some embodiments, thedata analysis system504 may also support a software development kit (SDK) for building, customizing, and adding additional functionality to the platform. Such an SDK may enable customization of the platform's functionality on top of the platform's hardcoded functionality.
• Thedata analysis system504 may perform various other functions as well. Some functions performed by thedata analysis system504 are discussed in further detail below.
• In example embodiments, theasset data platform500 may be configured to create and store customer accounts for entities that utilize services hosted by theasset data platform500. In practice, a given customer account may be created based on data provided to theasset data platform500 from an external device, such as theprovisioning device114, among other possibilities. A given customer account may include or otherwise be linked to databases that may include account credentials (e.g., username, passwords, etc.), asset-role identifiers, asset-management credentials, asset-management permissions, data-management credentials, data-management permissions, asset identifiers, asset status information (e.g., registered or unregistered), and/or asset-related data posted by provisioned local analytics devices. A customer account may include various other information and/or may be stored by other computing systems independent of the asset data platform.
• One of ordinary skill in the art will appreciate that the example platform shown inFIGS. 4-5 is but one example of a simplified representation of the components that may be included in a platform and that numerous others are also possible. For instance, other platforms may include additional components not pictured and/or more or less of the pictured components. Moreover, a given platform may include multiple, individual platforms that are operated in concert to perform operations of the given platform. Other examples are also possible.
IV. EXAMPLE OPERATIONS
• The operations of theexample network configuration100 depicted inFIG. 1 will now be discussed in further detail below. To help describe some of these operations, flow diagrams may be referenced to describe combinations of operations that may be performed. In some cases, each block may represent a module or portion of program code that includes instructions that are executable by a processor to implement specific logical functions or steps in a process. The program code may be stored on any type of computer-readable medium, such as non-transitory computer-readable media. In other cases, each block may represent circuitry that is wired to perform specific logical functions or steps in a process. Moreover, the blocks shown in the flow diagrams may be rearranged into different orders, combined into fewer blocks, separated into additional blocks, and/or removed based upon the particular embodiment.
• The following description may reference examples where a single data source provides data to theasset data platform102 that then performs one or more functions. It should be understood that this is done merely for sake of clarity and explanation and is not meant to be limiting. In practice, theasset data platform102 generally receives data from multiple sources, perhaps simultaneously, and performs operations based on such aggregate received data.
• A. Provisioning Local Analytics Devices
• As mentioned above, in accordance with example embodiments, a local analytics device (e.g., the local analytics device220) may be coupled to an asset (e.g., the asset108) and undergo provisioning operations that allow the local analytics device to interact with theasset data platform102 on behalf of the asset and a particular customer account hosted by theasset data platform102.
• For purposes of explanation and illustration, some of the provisioning operations may be discussed with reference toFIG. 7, which depicts a signal flow diagram700 that shows example signal flows that may occur while provisioning a local analytics device. For these purposes, the operations causing the signal flows shown in the signal flow diagram700 are described as being carried out by thelocal analytics device220, theprovisioning device114, and theasset data platform102, but other devices and/or systems may carry out these example operations. One of ordinary skill will appreciate that diagram700 is provided for the sake of clarity and explanation and that numerous other combinations of operations may be utilized to facilitate the provisioning of a local analytics device.
• 1. Customer Account Information
• As a preliminary matter, theasset data platform102 may be configured to store account information for customers that obtain services that are hosted by theasset data platform102. For instance, a given customer may own and/or operate theassets106 and108 and may utilize services provided by theasset data platform102 that monitor the operating conditions of those assets. Specifically, a local analytics device may be utilized for eachasset106 and108 to facilitate such asset monitoring.
• A given customer account may include a variety of information and that information may be stored in a variety of manners.FIG. 6 depicts a conceptual illustration of examples of information related to a customer account and exemplary relationships between such information. As shown inFIG. 6, information related to the customer account is represented in tables600,610,620, and630. Specifically, the table600 maps asset-management permissions (also referred to herein as “rights”) to a particular asset role and to a particular asset-management credential that enables those permissions to be exercised. The table610 maps a particular asset role to particular account credentials (e.g., a username and password combination). The table620 generally provides a representation of the customer account's asset inventory and stores a registration status of each particular asset of the customer account. The table630 associates asset-management credentials with data-management credentials and maps data-management permissions and data-management credentials that enable the corresponding permission to be exercised.
• More specifically, the table600 includes asset-role identifiers, asset-management permissions, and asset-management credentials. An asset-role identifier serves to distinguish one asset role from another asset role and may take various forms, such as a string of alphanumeric characters or the like (e.g., “Role ID #1”). In general, an asset role corresponds to a user's role with respect to the assets of the customer account, such as an asset owner, an asset administrator, an asset maintenance personnel, asset analytics specialist, etc. As such, some asset roles may have more inclusive asset permissions than other asset roles.
• Asset-management permissions define the customer-account and asset administration related operations that may be performed or otherwise facilitated. Examples of such operations may involve facilitating the provisioning of a local analytics device and/or providing access to data-management credentials, among other operations. Thus, in example embodiments, an asset-management permission may define the particular operations that a provisioning device can perform on behalf of the customer account. Examples of such operations may include generating a data-management credential based on an asset-management credential to facilitate provisioning a local analytics device, accessing a data-management credential provided by an asset data platform, or transferring to a local analytics device a data-management credential without accessing the credential, among other examples. An asset-management credential serves to authorize an attempted customer-account related operation. For instance, an asset-management credential may enable a provisioning device to complete a provisioning process to allow a local analytics device to interact with theasset data platform102 on behalf of a particular asset. That is, the asset-management credential may allow the local analytics device to be provisioned and/or may be utilized to provide the local analytics device authority to perform certain operations on behalf of a particular asset.
• In example embodiments, an asset-management credential may take various forms, such as a string of alphanumeric characters or the like (e.g., “Credential #1”) or a token. Additionally, the asset-management credential may include some level of security, such as some level of encryption, such that the credential is securely exchanged between authorized entities.
• The table610 includes account credentials (e.g., usernames and corresponding passwords) and a corresponding asset-role identifier. Other examples of account credentials, such as tokens, may be alternatively used. As such, the table610 may be used to determine what role has been assigned to a particular user's account credentials. Notably, multiple usernames may have the same asset-role identifier and thus, may provide the same management permissions.
• Table620 includes asset identifiers that identify the assets of the customer account and asset statuses that identify whether a given asset is registered with the customer account (i.e., whether a local analytics device has been provisioned to interact with theasset data platform102 on behalf of the particular asset).
• Table630 includes asset-management credentials, data-management credentials, and analytics permissions. As shown, each asset-management credential is associated with one or more data-management credentials. A data-management credential serves to authorize certain asset-related interactions. As mentioned above, various types of data-management credentials are possible, such as analytics and/or data transfer credentials. Generally, an analytics credential is related to operations that involve analyzing and/or processing asset data (e.g., an asset's signal data), while a data transfer credential is related to operations that involve exchanging asset data between devices and/or systems.
• For instance, a data-management credential may enable a local analytics device to ingest data from a particular asset, to execute particular predictive models or perform other analytics for a particular asset, to add, delete, and/or modify asset-related data, to publish asset-related data to an asset data platform, or to cause the asset data platform to perform an operation on behalf of the asset, among numerous other examples. A data-management credential may take various forms.
• Data-management permissions define asset-data-management related operations that may be performed or otherwise facilitated. As suggested above, data-management permissions may define the particular operations that a local analytics device can perform for a particular asset. Additionally or alternatively, in some example embodiments, data-management permissions may define the particular interactions that a local analytics device can partake in with theasset data platform102 on behalf of a particular asset. Examples of such interactions may include publishing asset data to theasset data platform102, instructing theasset data platform102 to provide certain information or predictive models to the local analytics device, and/or instructing theasset data platform102 to perform certain data services for the asset, among other examples.
• Additionally or alternatively, a data-management credential and corresponding permissions (or perhaps a different type of credential-permission pair) may define the particular operations that a local analytics device can perform on behalf of itself. That is, based on such a credential, the local analytics device may be authorized to interact with theasset data platform102 on behalf of itself. For instance, the local analytics device may be authorized to report back to theasset data platform102 various information related to the operation or status of the local analytics device, such as the number of hours the local analytics device has been in use, the health of the local analytics device's battery, the current software version running on the local analytics device, and/or the current data models available on the local analytics device, among other examples. In this way, only authorized local analytics device can report such information back to theasset data platform102.
• The tables shown inFIG. 6 are provided merely for purposes of example and explanation. Information related to a customer account may take various other forms and may include other information that is not depicted. For example, although not shown, various asset operating data (e.g., signal and/or abnormal-condition data) for the assets of the customer account is stored in a manner so that it is associated with the customer account. Other examples of additional information are also possible.
• 2. Initiation of Provisioning Operations
• Prior to asset-condition monitoring for theasset108, thelocal analytics device220 may be installed on theasset108. Typically, this operation may involve a user (e.g., asset operator, technician, etc.) physically coupling the local analytics device to theasset108. In example implementations, based on the design of thelocal analytics device220, thelocal analytics device220 may be physically coupled toasset108 in a relatively simple manner without requiring expert knowledge and/or physical modification of theasset108. For example, thelocal analytics device220 may be physically coupled to the asset via an asset interface, such as an asset diagnostics port, which may allow thelocal analytics device220 to communicate with one or more of theasset108's on-board components and/or systems (e.g., sensor(s)204, actuator(s)205, thecentral processing unit206, thedata storage208, etc.). In example embodiments, thelocal analytics device220 may communicate with theasset108 according to one or more asset communication protocols (e.g., J1939, etc.), which may depend on the asset type. Thelocal analytics device220 may be coupled to theasset108 and communicate therewith in various other ways.
• After thelocal analytics device220 is coupled to theasset108, it may be then configured to initiate operations that facilitate provisioning thelocal analytics device220. In practice, thelocal analytics device220 may initiate such operations based on a number of triggers (“initiation triggers”). In example embodiments, initiation triggers generally involve thelocal analytics device220 detecting a change in physical state of theasset108.
• One example trigger may involve thelocal analytics device220 determining that it is in a “power-on” state (e.g., that the local analytics device has powered-on from a powered-off state). In particular, thelocal analytics device220 may detect that power has been applied to it based on theasset108 being turned on or based on thelocal analytics device220 receiving a manual power on input (e.g., via a switch, button, etc.), among other examples. In practice, thelocal analytics device220 may receive power from theasset108, may contain its own power source, or some combination of both.
• Additionally or alternatively, an initiation trigger may take the form of thelocal analytics220 being first installed on an asset and/or thelocal analytics device220 receiving an instruction from a provisioning device based on the provisioning device executing a provisioning application. Other examples of initiation triggers are also possible.
• 3. Asset Discovery
• After the occurrence of an initiation trigger, thelocal analytics device220 may perform asset discovery operations to determine the identity of the asset to which thelocal analytics device220 is coupled (e.g., the asset108), as identified inFIG. 7 atblock702. That is, thelocal analytics device220 may be configured to determine information that is useful to identify the asset that it is coupled to. In practice, once such information is determined, thelocal analytics device220, theprovisioning device114, theasset data platform102, or some combination thereof may then confirm that that asset is associated with the particular customer account (discussed in detail below).
• In general, the asset identification operations involve thelocal analytics device220 determining an “asset signature” for the asset to which it is coupled that is indicative of configuration characteristics of the asset. An asset signature may include a particular sequence of data that is derived from results of a plurality of asset-identification operations. In particular, each asset signature correlates a particular combination of data and/or characteristics thereof (or in some cases, a single data or characteristic thereof) to a specific asset type, asset class, or unique asset configuration.
• For example, a first asset configuration (e.g., a first brand of construction equipment) may correspond to a first combination of particular data characteristics, while a second asset configuration (e.g., a second brand of construction equipment) may correspond to a second combination of characteristics that differs in some way from the first combination of characteristics. Moreover, a third asset configuration (e.g., a first model of bulldozers of the first brand) may correspond to a third combination of characteristics that differs in some way from the first and second combinations. Further still, a fourth asset configuration (e.g., a year 2010 version of the first model of bulldozer) may correspond to a fourth combination of characteristics that differs in some way from the first, second, and third combinations. Various other examples and/or granularities are also possible.
• Accordingly, an asset signature may enable thelocal analytics device220 to, at a minimum, distinguish between the particular asset and any other asset that is also associated with the particular customer account. To that end, the asset signature may take various forms and may vary in the precision of the identification, which may depend on the particular context, customer account, and/or assets associated therewith.
• For example, in a context where a customer account is associated with multiple assets but only one asset for any given type of asset (e.g., only one bulldozer, only one crane, etc.), then the asset signature may be relatively imprecise and still provide sufficient information to distinguish the asset (e.g., an asset-type signature). As another example, in a context where a customer account is associated with multiple assets of the same type, then the asset signature may be moderately precise (e.g., an asset-configuration signature). In yet another example where a customer account is associated with multiple assets of the same or similar configuration (e.g., a fleet of locomotives of the same make, model, etc.), then the asset signature may be highly precise (e.g., an asset-unique signature). Other examples are also possible.
• Accordingly, in example embodiments, an asset signature may at least identify the type of the asset or the class of the asset, and in some cases, the asset signature may uniquely identify the asset from all other assets (e.g., down to the asset's serial or VIN number or the like).
• As mentioned above, thelocal analytics device220 may determine an asset signature in a number of manners. Generally, thelocal analytics device220 determines an asset signature based on obtaining a plurality of asset data, where each asset data is indicative of a configuration parameter of the asset, such as a subsystem, component, software version, etc. that is part of the asset. Thelocal analytics device220 then utilizes the plurality of data to define the asset signature. Moreover, thelocal analytics device220 may maintain a record of the sequence of operations that it used to generate the asset signature (“a signature sequence”) to enable thelocal analytics device220 and/or theasset data platform102 to reproduce the asset signature for various reasons, such as asset confirmation (discussed in further detail below).
• In a first example embodiment, thelocal analytics device220 may determine an asset signature based on one or more queries to theasset108 that return data indicative of theasset108's configuration. The one or more queries and any respective responses may be based on an industry protocol, such as SAE1939, or other electronic identification mechanism that may be specific to particular assets.
• Specifically, thelocal analytics device220 may transmit to theasset108, via one or more asset interfaces, a request for identity information. Theasset108 may be configured to process the received request and facilitate fetching such information, or data from which such information can be derived, from one or more of theasset108's on-board systems maintaining such information (e.g., data storage, etc.).
• In practice, theasset108 may maintain identity information, or data from which such information can be derived, that may take a variety of forms and/or include a variety of information. For instance, the identity information may include details regarding theasset108's type, class (e.g., make, model, year, etc.), serial number, and/or other information regarding theasset108's configuration. Additionally or alternatively, the identity information may include details regarding some or all of theasset108's components or subsystems, such as their own respective configurations, firmware versions, serial numbers, etc.
• In a particular example, the identity information may be in accordance with a certain standard, such as SAE J1939, and include information particular to that standard, such as Product Identifying Information and/or Component Identification Information. In another particular example, the identity information may not be in accordance with any particular standard. In yet other particular example, some identity information may be in accordance with a standard, while other identity information is not in accordance with a standard.
• In any event, thelocal analytics device220 may be configured to determine the asset signature based on the responses to the one or more queries. In some instances, this operation may involve thelocal analytics device220 concatenating the query responses in a particular sequence that is then used as the asset signature. In other instance, the one or more query-responses themselves contain the asset signature. Indeed, in example embodiments, theasset108 may be configured to auto-identify itself in a manner that does not require an explicit query action from thelocal analytics device220.
• In a second example embodiment, thelocal analytics device220 may determine an asset signature based at least on passive data traffic monitoring of theasset108. That is, thelocal analytics device220 may define the asset signature for theasset108 based on asset data and/or characteristics thereof that thelocal analytics device220 obtains from the computer systems of theasset108. In practice, this process may also involve active queries, which may be different in nature from those described above in the first example embodiment. As such, this second example embodiment may differ from the first example embodiment in that thelocal analytics device220 defines the asset signature based on the nature of theasset108's data, as opposed to on identity information that inherently provides some indication of theasset108's configuration.
• Generally, the particular data available from assets, as well as characteristics thereof, may vary based on asset type, class, and/or other asset configuration considerations. For instance, a particular type of asset may provide certain types of data or data with certain data characteristics that differ from that provided by an asset of a different type. As such, certain asset data and/or characteristics thereof may be indicative of an asset's identity. Examples of such data or characteristics thereof may include asset-component or asset-subsystem data (e.g., data indicative of the particular engine type, such as a unique character sequence of an engine currently installed in the asset that may be used for engine identification purposes), the types and/or sequences of signal data output by an asset, the format of data generated by an asset, and/or the data generated by an asset in response to certain requests. Other examples are possible as well.
• In any event, as mentioned above, thelocal analytics device220 may receive, monitor, or otherwise obtain from theasset108 various asset data from which an asset signature can be derived. For instance, thelocal analytics device220 may request and receive particular data from theasset108, such as signal data generated by specific sensors and/or actuators, among other examples. It should be noted that, in some implementations, thelocal analytics device220 may not be required to request asset data but instead, theasset108 may be configured to automatically push certain data to thelocal analytics device220 periodically or based on certain triggers. In another instance, thelocal analytics device220 may additionally or alternatively monitor, via an asset interface, data traffic occurring on theasset108. Other examples are also possible.
• After obtaining the asset data, thelocal analytics device220 may identify certain data and/or characteristics thereof for use in determining the asset signature, which may occur in a number of manners. For example, thelocal analytics device220 may determine that certain types of data were received in response to certain requests, that monitored data included certain types of signal data, and/or that pushed data was provided in a particular format, among various other possibilities. In any event, thelocal analytics device220 may then define the asset signature, which may involve thelocal analytics device220 concatenating a particular sequence of the asset data, among other possibilities.
• In a third example embodiment, thelocal analytics device220 may determine an asset signature based on a data-model-based asset discovery process. In one particular example of such a discovery process, thelocal analytics device220 may first execute one or more asset-identification predictive models based on asset data from theasset108 that helps to identify the particular type of theasset108 and then perform individualized procedures for that asset type to obtain from theasset108 data and/or characteristics thereof that are used to generate an asset signature.
• In general, a given asset-identification predictive model receives as inputs asset data and/or characteristics thereof and outputs a likelihood that the source of the inputted data (e.g., the asset108) is of a particular asset type. Thus, in practice, thelocal analytics device220 may include multiple asset-identification predictive models; one for each possible asset type that thelocal analytics device220 could be coupled to. Thelocal analytics device220 may then execute each of these multiple asset-identification predictive models and use the results therefrom to help derive the asset signature.
• Generally, an example model-based asset discovery process may include two phases: (1) a modeling phase during which one or more asset-identification models are defined and (2) an asset-type determination phase (e.g., an “execution phase”). In practice, these phases may be performed in a variety of manners. The below discussion provides examples of these phases and should not be construed as limiting.
• The modeling phase is discussed in relation to an asset-configuration predictive model that outputs a likelihood that an asset is of a particular asset type. However, one of ordinary skill in the art will appreciate that such a modeling phase may be similarly used for other purposes as well.
• The example modeling phase may involve theasset data platform102 analyzing historical data for a plurality of assets of various asset types. From those assets, theasset data platform102 may identify assets of the asset type for which the asset-configuration model is being defined. After identifying these assets of interest, the asset data platform may then determine from the historical data for those assets of interest, asset data and/or characteristics thereof (“training data”) that are common amongst and/or are unique to that asset type.
• Once theasset data platform102 determines the training data, it may define one or more predictive models correlating the training data to a likelihood of a given asset being of the particular asset type. Specifically, theasset data platform102 may define a relationship between (1) the training data and (2) a likelihood that the training data is indicative of the particular asset type. This defined relationship may embody the given asset-configuration predictive model for the particular asset type. In practice, such a relationship may be defined by utilizing one or more modeling techniques that return a probability between zero and one, such as a random forest technique, logistic regression technique, or other regression technique. Additional asset-type models may be similarly defined for each type of asset that a local analytics device may be coupled to.
• After theasset data platform102 defines the one or more asset-identification predictive models, theasset data platform102 may provide the models to thelocal analytics device220 for use in the discovery process. In practice, theasset data platform102 may transmit the models to thelocal analytics device220 via thecommunication network104, or the models may be pre-loaded on thelocal analytics device220. In either case, theasset data platform102 and/or thelocal analytics device220 may update and/or modify one or more of the models over time.
• During the execution phase, thelocal analytics device220 may execute the one or more asset-identification predictive models based on asset data obtained via theasset108's asset interfaces. Specifically, thelocal analytics device220 may input certain data and/or data indicative of characteristics thereof into the one or more models. In turn, the one or more asset-identification models may cause thelocal analytics device220 to determine and output one or more probabilities (e.g., a value between 0-1) that theasset108 is of a particular asset type.
• Based on the outputs of the asset-identification models, the local analytics device may then identify the most likely type of theasset108. In example embodiments, this process may involve determining the asset-identification model output with the highest probability. In other examples, this process may involve determining whether any of probabilities exceeds a confidence probability threshold, which may be a value (e.g., between 0-1) that defines the confidence level at which a prediction should be utilized to derive asset identification information. Such a confidence probability threshold may be a fixed or variable value that is defined by a computing device or a user.
• In any event, after thelocal analytics device220 identifies the most likely asset type of theasset108, it may then perform certain procedures for that asset type to obtain from theasset108 data and/or characteristics thereof that are used to generate the asset signature. For instance, based on the results of the predictive models, thelocal analytics device220 may then monitor for certain asset data and/or query certain computer systems of theasset108. Then, thelocal analytics device220 may define the asset signature, which may be similar in form as discussed above.
• Alternatively, if thelocal analytics device220 is unable to identify a most likely asset type (e.g., if no probability exceeds the confidence probability threshold), thelocal analytics device220 may be configured to transmit to theasset108 additional requests for data in order to facilitate determining additional data and/or characteristics thereof. These additional requests may be based on the previously output probabilities for the asset-identification models that were numerically closest to the confidence probability threshold. That is, the additional requests may be specifically tailored to determine particular data of interest known to be exhibited by certain types of assets. In any event, thelocal analytics device220 may be configured to determine asset identification information based on predictive models in various other manners as well.
• The above discussion has set forth various ways in which thelocal analytics device220 may determine asset signatures. It should be noted, however, thatlocal analytics device220 may utilize any one, all, or some combination of the described processes (or some other processes) to determine asset signatures. For example, thelocal analytics device220 may utilize a query-based approach to determine theasset108's Component Identification Information and a messaging-traffic-based approach to determine theasset108's make or model. Various other combinations are also possible. Moreover, some or all of the asset discovery operations discussed above may involve some level of assistance from theasset data platform102. Other examples are also possible.
• As discussed in further detail below, after thelocal analytics device220 determines an asset signature for theasset108 that it is attached to, thelocal analytics device220 may provide that asset signature to other devices, such as theprovisioning device114, to help in the provisioning operations. Moreover, thelocal analytics device220 may store the asset signature in data storage for use in the provisioning process and for subsequent retrieval to confirm a connected asset's identity after the local analytics device has been power cycled, as discussed in further detail below.
• 4. Asset Confirmation
• In example embodiments, thelocal analytics device220 may be further configured to evaluate whether the asset to which thelocal analytics device220 is currently coupled (e.g., the asset108) is the same asset that thelocal analytics device220 last obtained data for. For instance, after thelocal analytics device220 is powered on from a powered-off state, thelocal analytics device220 confirms that the asset that it is presently coupled with is the same asset that it was coupled with prior to the powered-off state.
• Thelocal analytics device220 may perform this operation in a variety of manners. As one example, thelocal analytics device220 may store in memory an asset signature for the last asset that it was coupled with and compare that asset signature with the asset signature that is presently determined.
• In another example, thelocal analytics device220 may perform this confirmation process independent of any determined asset signature. For example, in one embodiment, thelocal analytics device220 may store in memory the most recent signature sequence and responses thereto and then utilize that stored information to perform the asset confirmation. Specifically, thelocal analytics device220 may replicate the same sequence of operations identified by the signature sequence (or some portion thereof) and confirm that it obtains the same responses as the stored responses. If thelocal analytics device220 does in fact obtain the same responses, it may then infer that it is still coupled to the same asset. Otherwise, it may infer that it is coupled to a different asset. In example embodiments, instead of replicating the same sequence of operations identified by the signature sequence, thelocal analytics device220 may be configured to execute a functionally equivalent set of operations that facilitate confirming the asset.
• If thelocal analytics device220 confirms that the asset it is presently coupled with is the same asset that it last obtained data for, then thelocal analytics device220 continues operating in a “paired to a specific asset” state. For instance, thelocal analytics device220 may continue with the provisioning process or may interact with theasset data platform102 on behalf of theasset108, assuming it is authorized to do so.
• Otherwise, thelocal analytics device220 may enter a state (e.g., an “unprovisioned state”) where thelocal analytics device220 preserves any data that it locally stored on behalf of the previous asset and/or isolates any data for the previous asset from the data for the present asset, such as by allocating particular memory for data collected on behalf of the present asset that is separate from the memory storing data for the previous asset. In this way, thelocal analytics device220 helps to ensure that it does not corrupt the data for the present asset or the data for the previous asset. Thereafter, thelocal analytics device220 may continue with the provisioning process with respect to the present asset.
• Additionally, in example embodiments, thelocal analytics device220 may at some later time transmit the data for the previous asset to theasset data platform102 and/or provide to the asset data platform102 a notice that thelocal analytics device220 is no longer coupled with the previous asset, thereby allowing theasset data platform102 to track whether assets have an active, connected local analytics device.
• 5. Coupling Provisioning & Local Analytics Device
• Before, after, or while thelocal analytics device220 determines the asset signature, a communication link may be established between thelocal analytics device220 and theprovisioning device114. For example, returning toFIG. 7, at704, theprovisioning device114 may seek to establish a network connection with thelocal analytics device220. In example embodiments, this operation may involve theprovisioning device114 broadcasting an “alive” message, which may generally indicate that theprovisioning device114 is ready to connect to a local analytics device. In some cases, theprovisioning device114 may broadcast such a message based on theprovisioning device114 receiving an input via the provisioning application and/or receiving from the asset data platform102 a provisioning credential, among other examples. WhileFIG. 7 depicts theprovisioning device114 initiating the connection to thelocal analytics device220, this may not always be the case. Indeed, in some example embodiments, thelocal analytics device220 may instead initiate a connection to theprovisioning device114, which may be based on detecting one or more of the trigger events discussed above.
• In a particular example, either thelocal analytics device220 or theprovisioning device114 may attempt to establish a connection (e.g., “pair”) with each other via an ad-hoc network (e.g., Bluetooth, mesh, WiFi, etc.), in which case the alive message may take the form of a periodically broadcasted device discovery message (e.g., “inquiry message”). In turn, the devices may be configured to “listen” or scan for a device discovery message. Once a device “hears” the device discovery message, it may transmit a response message including information needed to establish an ad-hoc network connection. The devices may then perform a paging procedure to facilitate establishing the network connection. Alternatively, thelocal analytics device220 and theprovisioning device114 may be coupled over a communication link other than an ad-hoc network connection, such as a wired, WAN (e.g., cellular network), or LAN connection, among other examples.
• 6. Exchange of Credentials
• Before, after, or while a network connection is established between thelocal analytics device220 and theprovisioning device114, theprovisioning device114 may act in concert with theasset data platform102 to authenticate one or more customer accounts. For example, theprovisioning device114 may receive, via the provisioning application, an account credential (e.g., a username and password combination or other authentication credential) via a log-in event. Theprovisioning device114 may then, at706 ofFIG. 7, transmit the account credential (or a representation thereof) to theasset data platform102, which in turn may or may not authenticate the log-in attempt and either provide or deny access to the customer account.
• In some cases, a customer account may not exist yet. Accordingly, theprovisioning device114 may receive inputs, via the provisioning application, that facilitate creating a new customer account. Theprovisioning device114 may provide data indicative of such inputs to theasset data platform102, which in turn may register the new account and store information for that account. As discussed above, theasset data platform102 may maintain a plurality of customer accounts, each of which may include or otherwise be linked to databases that may include various information related to customer accounts, such as information shown inFIG. 6, among other information.
• In any event, after theasset data platform102 receives the account credential from theprovisioning device114, it may proceed to determine whether to authenticate that account credential. For instance, returning toFIG. 6, theasset data platform102 may be configured to cross-reference the table610 with the received account credential and for example, determine whether the username and password combination match any row in the table610. If theasset data platform102 determines that the account credential matches a row in the table610, theasset data platform102 may determine the asset-role identifier for that row and reference the table600 to identify a corresponding asset-management credential and/or asset-management permissions.
• Then, at708 ofFIG. 7, theasset data platform102 may provide to theprovisioning device114 at least the identified asset-management credential and one or more asset identifiers that identify the asset inventory of the customer account, and perhaps also an indication of the asset-management permissions. More specifically, the one or more asset identifiers identify registered and unregistered assets associated with the particular customer account. After theprovisioning device114 has received the asset-management credential and asset identifiers, theprovisioning device114 may store this information for use in the provisioning process.
• On the other hand, if theasset data platform102 determines that the account credential does not match any row in the table610, it may then instead transmit a notification to theprovisioning device114 that access is denied. Similarly, in example embodiments, even if theasset data platform102 determines that there is a match, theasset data platform102 may nonetheless deny access if the asset-management permissions associated with that account credential does not cover the attempted interaction. For instance, if theasset data platform102 receives the account credential from a device executing a provisioning application and that account credential is not associated with a provisioning permission, then theasset data platform102 may provide an appropriate notification back to that device. Theasset data platform102 may authenticate account credentials in a variety of different manners, and/or computing systems independent of theasset data platform102 may carry out such authentication processes.
• Notably, the exchange of account and asset-management credentials by theprovisioning device114 andasset data platform102 does not have to occur after thelocal analytics device220 is coupled to theasset108 or a network connection is established between thelocal analytics device220 andprovisioning device114. Rather, theprovisioning device114 andasset data platform102 may authenticate account credentials at any time, so long as a communication path (e.g., network connection) exists between the two.
• At some point in time after the communication link is established between thelocal analytics device220 and theprovisioning device114, thelocal analytics device220 may, at710 ofFIG. 7, transmit to theprovisioning device114 the asset signature that was determined by thelocal analytics device220. Based at least on the asset signature, theprovisioning device114 may determine whether theasset108 that thelocal analytics device220 is attached to is indeed associated with the particular customer account. Theprovisioning device114 may perform this operation in a variety of manners.
• In practice, a particular asset identifier has a relationship to a particular asset signature. In example embodiments, a particular asset identifier is a truncated, representation of a particular asset signature. As such, an asset identifier may take a variety of forms, such as an alphanumeric text string, a token, or the like. The use of asset identifiers may be advantageous over using full asset signatures, which are typically much larger in terms of data size, because the asset identifiers are exchanged between devices across thecommunication network104 for a variety of reasons. As such, the use of asset identifiers helps to conserve network bandwidth, to reduce data usage, and may help deliver accurate communications when network connectivity is limited. To utilize asset identifiers, a mapping between asset signatures and asset identifiers for a given customer account is defined.
• Accordingly, asset identifiers may be generated in a variety of manners. In an example embodiment, thelocal analytics device220 and/or theprovisioning device114 provides the asset signature to theasset data platform102, which in turn determines whether that asset signature is currently mapped to an asset identifier. If not, theasset data platform102 may generate an asset identifier that maps to that asset signature and store that identifier and association in a database. In example embodiments, when theasset data platform102 generates an asset identifier, that identifier is at least unique for the particular customer account and may be globally unique across all customer accounts. After theasset data platform102 generates the asset identifier and stores the association with the asset signature (or if theasset data platform102 determines that the asset signature is already mapped to an asset identifier), it may then inform thelocal analytics device220 and/or theprovisioning device114 of the asset identifier and association.
• In another example embodiment, thelocal analytics device220 and/or theprovisioning device114 may locally generate an asset identifier for the asset signature, which may be necessary if there is no data connection back to theasset data platform102. Some time later, thelocal analytics device220 and/or theprovisioning device114 may provide theasset data platform102 the asset identifier and associated asset signature. In scenarios where the asset identifier that was locally generated is not unique (e.g., globally or for the particular customer account), theasset data platform102 may replace the asset identifier, update the mapping, and inform the provisioning and local analytics devices of the update. Other examples are also possible. Accordingly, theasset data platform102, theprovisioning device114, and thelocal analytics device220 may each maintain a mapping of asset signatures to asset identifiers for the particular customer account that can be dynamically updated.
• Returning to the provisioning operations, theprovisioning device114 may utilize the received asset identifiers and the received asset signature to verify that theasset108 is indeed an asset associated with the particular customer account. That is, theprovisioning device114 may determine whether the asset signature corresponds with one of the asset identifiers identifying an unregistered asset of the customer account. For example, if the account identifiers indicate that the particular customer account does not include an unregistered asset (e.g., all assets are registered), then theprovisioning device114 may infer that theasset108 is not associated with this customer account and terminate the provisioning process for that customer account.
• Alternatively, instead of thelocal analytics device220, at710 ofFIG. 7, transmitting the asset signature to theprovisioning device114, thelocal analytics device220 may itself identify the asset based on the asset signature and transmit to theprovisioning device114 the appropriate asset identifier. For example, thelocal analytics device220 may compare the determined asset signature to a plurality of asset signatures locally stored by thelocal analytics device220 and associated with corresponding asset identifiers also locally stored. In example embodiments, thelocal analytics device220 may have previously received one or more of the plurality of asset signatures from theasset data platform102 that maintains the master database of such signatures. As such, thelocal analytics device220 and theasset data platform102 may collaboratively perform asset discovery operations to facilitate identifying the particular asset to which thelocal analytics device220 is connected.
• In any event, based on this comparison, thelocal analytics device220 may locate a stored asset signature matching (or most closely matching) the asset signature determined for theasset108. From the matching signature, thelocal analytics device220 may then determine the corresponding asset identifier and transmit that identifier to theprovisioning device114.
• In some scenarios, neither thelocal analytics device220 nor theprovisioning device114 can confirm that the asset signature corresponds to a particular asset associated with the particular customer account. Assuming there is a network connection back to theasset data platform102, thelocal analytics device220 and/or theprovisioning device114 may provide to theasset data platform102 part or all of the asset signature, which may then assist in this confirmation step.
• If there is no network connection back to the asset data platform102 (or if theasset data platform102 cannot confirm), theprovisioning device114 may query the user to assist in this confirmation step. In particular, theprovisioning device114 may instruct the user to use theprovisioning device114 to capture an image of theasset108's identification tag or the like (e.g., a VIN plate) or instruct the user to manually enter such asset identification information. For example, theprovisioning device114 may include a digital camera configured to capture and process images. Theprovisioning device114 may capture an image of an identification tag or the like and then extract from that image asset identification information. However, such procedures may be less reliable and/or more prone to errors than the procedures discussed above. In any event, any information obtained manually may be provided to theasset data platform102 so that theasset data platform102 can supplement its asset signature-identifier mapping to help expand the knowledge of theasset108's identity.
• Before, after, or simultaneous with confirming that thelocal analytics device220 is attached to a particular asset that is associated with the particular customer account, theprovisioning device114 may determine whether the one or more asset-management credentials that it received from the asset data platform102 (e.g., at708 ofFIG. 7) provide theprovisioning device114 provisioning permission for the particular asset (e.g., the asset108). If theprovisioning device114 confirms this and the asset is confirmed, then theprovisioning device114 may, at712 ofFIG. 7, provide to thelocal analytics device220 one or more data-management credentials.
• In example embodiments, before exchanging any data-management credential, theprovisioning device114 may first identify a data-management credential that should be transferred to thelocal analytics device220, which may be performed in a variety of manners. As one example, theprovisioning device114 identifies the data-management credential by receiving the data-management credential from theasset data platform102, perhaps along with the asset-management credential, and determining that the data-management credential is for thelocal analytics device220. As discussed above, depending on theprovisioning device114's permissions, theprovisioning device114 may or may not have access to the data-management credential before it transmits the credential to thelocal analytics device220.
• In another example, theprovisioning device114 identifies the data-management credential by generating or otherwise deriving the data-management credential based on the received asset-management credential. For instance, theprovisioning device114 may generate the data-management credential based on some information included in the asset-management credential, generate a modified version of the asset-management credential (e.g., an asset-specific credential), or generate an electronic item associated with the asset-management credential (e.g., a token) that serves as the data-management credential. Other possibilities also exist.
• As such, theprovisioning device114 may receive an asset-management credential that it utilizes to exchange a data-management credential, where asset-management and data-management credentials differ from one another but are both associated with the customer account. As discussed above, the asset-management and data-management credentials may differ as to the scope of permissions that are associated with each. For instance, a given asset-management credential may be associated with a broader scope of permissions than a given data-management credential. Likewise, a first asset-management credential (e.g., one associated with asset identification, data ingestion, analytics, and provisioning permissions) may be associated with a broader scope of permissions than a second asset-management credential (e.g., a “provisioning” credential that is limited to provisioning based permissions). Similarly, a first data-management credential may be associated with a broader scope of permission than a second data-management credential. Other examples are possible.
• In any event, thelocal analytics device220 receives the one or more data-management credentials from theprovisioning device114, thereby completing the provisioning process. Thelocal analytics device220 may then store the received information in data storage to later perform operations on behalf of theasset108, as discussed below.
• 7. Operating on Behalf of Asset
• Thelocal analytics device220 may utilize the received data-management credential to interact with theasset108 and/or with theasset data platform102 on behalf of theasset108. In some example embodiments, thelocal analytics device220 may also receive from the provisioning device114 (or perhaps the asset data platform102) an indication of the permissions corresponding to the data-management credential (e.g., as defined in the table630 ofFIG. 6), which may then dictate the type of operations that thelocal analytics device220 may perform on behalf of theasset108.
• In example embodiments, thelocal analytics device220 interacting with theasset data platform102 involves, at714 ofFIG. 7, thelocal analytics device220 transmitting to theasset data platform102 an operation instruction that includes at least the data-management credential and perhaps also the asset identifier (e.g., representing a truncated version of the asset signature). Based on that credential, theasset data platform102 may determine (e.g., via the permissions from the table630 for that data-management credential) whether thelocal analytics device220 has authority to perform or cause theasset data platform102 to perform a particular operation in accordance with the operation instruction. In the event that thelocal analytics device220 is not so authorized, theasset data platform102 may deny that interaction by thelocal analytics device220 and perhaps provide an appropriate notification to thelocal analytics device220 and/or theprovisioning device114.
• At716 ofFIG. 7, theasset data platform102 confirmed that thelocal analytics device220 is authorized to interact with theasset data platform102 on behalf of theasset108 and as a result, followed the operation instruction provided by thelocal analytics device220. In this example, thelocal analytics device220 interacted with theasset data platform102 by publishing asset-related data on behalf of theasset108 to theasset data platform102 and instructing theasset data platform102 to execute one or more predictive models based on such data for theasset108. Theasset data platform102 executed those models and provided the results therefrom back to thelocal analytics device220.
• The asset-related data published by thelocal analytics device220 to theasset data platform102 may take a variety of forms, such as signal data (e.g., sensor and/or actuator data), position data generated by theasset108, abnormal condition indicators triggered by theasset108, and/or outputs of predictive models executed by thelocal analytics device220. Thelocal analytics device220 may publish various other forms of asset-related data. Furthermore, thelocal analytics device220 may publish the asset-related data continuously, periodically, and/or upon an asset-related event occurrence (e.g., triggered abnormal condition indicator, generated predictive model output, etc.). Asset-related data is discussed in further detail below.
• Thelocal analytics device220 may interact with theasset data platform102 on behalf of theasset108 in a variety of other manners as well. For example, it may instruct theasset data platform102 to allow it to download from theasset data platform102 certain predictive models for local execution by thelocal analytics device220 based on operating data from theasset108. As another example, it may instruct theasset data platform102 to perform various operations for theasset108, such as perform one or more data services for theasset108's data. Various other examples are also possible.
• In example embodiments, theasset data platform102 may be configured to revoke (e.g., invalidate) a given credential at any time. In such instances, theasset data platform102 may or may not provide an explicit revocation notification to thelocal analytics device220. In instances where such a notification is not provided, any subsequent data management attempt by thelocal analytics device220 would fail. In instances where such a notification is provided, thelocal analytics device220 would require a new credential before attempting any data management operations related to that revoked credential. Other examples are also possible.
• 8. Operating without Complete Network Availability
• The foregoing discussion in reference toFIG. 7 assumed that communication paths existed between thelocal analytics device220 andasset data platform102 and theprovisioning device114 andasset data platform102. However, such communication paths may not always be present or if present, the quality and/or reliability of the present path may be below a threshold quality and/or reliability value. Even so, thelocal analytics device220 may still be able to be provisioned, if at a minimum thelocal analytics device220 andprovisioning device114 are able to communicate with one another.
• For instance, thelocal analytics device220 may be provisioned even if only theprovisioning device114 is able to communicate with the asset data platform102 (i.e., even if thelocal analytics device220 cannot directly communicate with the asset data platform102). In such an example, theprovisioning device114 may perform one or more operations on behalf of thelocal analytics device220 to facilitate provisioning it.
• For example, theprovisioning device114 may act in concert with theasset data platform102 to authenticate account credentials, as discussed above. Furthermore, thelocal analytics device220 may be configured to determine that no communication path exists between it and the asset data platform102 (e.g., no network connection, poor quality connection, etc.), and based on that determination, transmit theasset108's asset signature to theprovisioning device114. Thereafter, theprovisioning device114 may forward to the local analytics device220 a data-management credential, in line with the above discussion. In this example, thelocal analytics device220 may be configured to collect and locally store asset-related data and may publish that data or otherwise interface with theasset data platform102 upon detecting a network connection between it and theasset data platform102 at a time in the future.
• FIG. 8ais a flow diagram800athat depicts example operations for determining whether to publish or locally store asset-related data. After thelocal analytics220 detects certain changes in physical state of the asset108 (e.g., detecting a power-on state) and has confirmed that it is still connected to the previously identified asset108 (as discussed above), atblock802, it may determine whether a network connection is available to the communication network104 (e.g., whether a communication path exists between thelocal analytics device220 and the asset data platform102). If a network connection is available (block804), thelocal analytics device220 may communicate with theasset data platform102 to determine whether theasset108 is registered (e.g., whether the table620 indicates a registered state for the asset108). If thelocal analytics device220 determines that theasset108 is in fact registered in the customer account, it may publish, atblock806, asset-related data on behalf of theasset108 or otherwise interact with theasset data platform102 on theasset108's behalf. However, if thelocal analytics device220 determines that no network connection is available and/or that theasset108 is unregistered, atblock808, it may collect and locally store asset-related data.
• In practice, thelocal analytics device220 may repeat the example process depicted byFIG. 8aduring operation by (perhaps periodically or continuously) checking for an available network connection in order to publish asset-related data to theasset data platform102 on behalf of theasset108. However, thelocal analytics device220 may be configured to enter an “offline” mode, for instance, to conserve battery power when external power is unavailable or if it was programmed to “wake” for specific times and durations. In such instances, thelocal analytics device220 may be configured to forgo some or all of the operations ofFIG. 8a.
• In another example, thelocal analytics device220 may be provisioned even if only thelocal analytics device220 is able to communicate with the asset data platform102 (i.e., even if theprovisioning device114 cannot directly communicate with the asset data platform102). As noted above, theprovisioning device114 andasset data platform102 may act in concert to authenticate account credentials at a time when a communication path exists between the two. Theprovisioning device114 may also be configured to locally store an asset-management credential along with asset identifiers representing the customer account's asset inventory from an authenticated log-in event, such as an asset-management credential for the most recently authenticated account credentials, and derive an data-management credential therefrom. Alternatively, theprovisioning device114 may be configured to locally store a data-management credential from a prior provisioning operation.
• Accordingly, in a scenario in which no communication path exists between theprovisioning device114 andasset data platform102, theprovisioning device114 may transmit a previously stored data-management credential to thelocal analytics device220 or generate a data-management credential based on a previously stored asset-management credential and transmit the generated data-management credential to thelocal analytics device220. Thereafter, thelocal analytics device220 may utilize the received data-management credential in line with the above discussion, thereby allowing thelocal analytics device220 to then interact with theasset data platform102 on behalf of theasset108, provided it has authority to do so.
• FIG. 8bis an example flow diagram800bthat depicts example operations for determining whether aprovisioning device114 will transmit credentials to alocal analytics device220 that are based on previously stored credentials on theprovisioning device114. Atblock810, theprovisioning device114 communicatively coupled to thelocal analytics device220 may determine whether a network connection is available to the communication network104 (e.g., whether a communication path exists to the asset data platform102). If theprovisioning device114 determines that a network connection is available, atblock812, it may act in concert with theasset data platform102 to authenticate account credentials, as discussed above.
• However, if theprovisioning device114 determines that no network connection is available, atblock814, it may determine whether theprovisioning device114 has a suitable asset-management credential (or data-management credential) previously stored in memory. Atblock816, based on a credential that was previously stored, theprovisioning device114 may transmit a data-management credential to thelocal analytics device220. In the event that theprovisioning device114 includes credentials for multiple accounts, theprovisioning device114 may further determine which credential to exchange, such as the most recently stored credential, among other examples. In the case where no such credential has been previously stored, theprovisioning device114 may continuously or periodically check for a network connection (e.g., block810) in order to facilitate the provisioning of the local analytics device.
• In yet another example, neither theprovisioning device114 nor thelocal analytics device220 has connectivity to theasset data platform102. In practice, either or both of theprovisioning device114 andlocal analytics device220 may be configured to determine that no communication path exists with theasset data platform102 and in response to such determinations, may be further configured to nonetheless perform certain provisioning operations. For example, thelocal analytics device220 may transmit to theprovisioning device114 theasset108's asset signature, and/or theprovisioning device114 may transmit to the local analytics device220 a data-management credential based on previously stored credentials. The received data may then be stored in the respective local data storage of the devices, and the devices may continue to perform their respective provisioning operations in line with the above discussion.
• B. Collection of Operating Data
• As mentioned above, each of therepresentative assets106 and108 may take various forms and may be configured to perform a number of operations. In a non-limiting example, theasset108 may take the form of a locomotive that is operable to transfer cargo across the United States. While in transit, the sensors and/or actuators of theasset108 may obtain data that reflects one or more operating conditions of theasset108. The sensors and/or actuators may transmit the data to a processing unit of theasset108.
• The processing unit may be configured to receive the data from the sensors and/or actuators. In practice, the processing unit may receive signal data from multiple sensors and/or multiple actuators simultaneously or sequentially. As discussed above, while receiving this data, the processing unit may also be configured to determine whether the data satisfies triggering criteria that trigger any abnormal-condition indicators, such as fault codes. In the event the processing unit determines that one or more abnormal-condition indicators are triggered, the processing unit may be configured to perform one or more local operations, such as outputting an indication of the triggered indicator via a user interface.
• The asset may then transmit operating data to thelocal analytics device220 via the asset interface, or thelocal analytics device220 may obtain the operating data via the asset interface itself. In turn, thelocal analytics device220 may transmit the operating data to theasset data platform102 via the network interface oflocal analytics device220 and thecommunication network104. In operation, thelocal analytics device220 may transmit operating data to theasset data platform102 continuously, periodically, and/or in response to triggering events (e.g., abnormal conditions). Specifically, thelocal analytics device220 may transmit operating data periodically based on a particular frequency (e.g., daily, hourly, every fifteen minutes, once per minute, once per second, etc.), or thelocal analytics device220 may be configured to transmit a continuous, real-time feed of operating data. Additionally or alternatively, thelocal analytics device220 may be configured to transmit operating data based on certain triggers, such as when sensor and/or actuator measurements satisfy triggering criteria for any abnormal-condition indicators. Thelocal analytics device220 may transmit operating data in other manners as well.
• In practice, operating data for an asset may include sensor data, actuator data, abnormal-condition data, and/or other asset event data (e.g., data indicating asset shutdowns, restarts, diagnostic operations, fluid inspections, repairs etc.). In some implementations, thelocal analytics device220 may be configured to provide the operating data in a single data stream, while in other implementations it may be configured to provide the operating data in multiple, distinct data streams. For example, thelocal analytics device220 may provide to the asset data platform102 a first data stream of signal data and a second data stream of abnormal-condition data. As another example, thelocal analytics device220 may provide to the asset data platform102 a separate data stream for each respective sensor and/or actuator on theasset108. Other possibilities also exist.
• Signal data may take various forms. For example, at times, sensor data (or actuator data) may include measurements obtained by each of the sensors (or actuators) of theasset108. While at other times, sensor data (or actuator data) may include measurements obtained by a subset of the sensors (or actuators) of theasset108.
• Specifically, the signal data may include measurements obtained by the sensors and/or actuators associated with a given triggered abnormal-condition indicator. For example, if a triggered fault code isFault Code 1 fromFIG. 3, then sensor data may include raw measurements obtained by Sensors A and C. Additionally or alternatively, the data may include measurements obtained by one or more sensors or actuators not directly associated with the triggered fault code. Continuing off the last example, the data may additionally include measurements obtained by Actuator B and/or other sensors or actuators. In some examples, theasset108 may include particular sensor data in the operating data based on a fault-code rule or instruction provided by theanalytics system108, which may have, for example, determined that there is a correlation between that which Actuator B is measuring and that which caused theFault Code 1 to be triggered in the first place. Other examples are also possible.
• Further still, the data may include one or more sensor and/or actuator measurements from each sensor and/or actuator of interest based on a particular time of interest, which may be selected based on a number of factors. In some examples, the particular time of interest may be based on a sampling rate. In other examples, the particular time of interest may be based on the time at which an abnormal-condition indicator is triggered.
• In particular, based on the time at which an abnormal-condition indicator is triggered, the data may include one or more respective sensor and/or actuator measurements from each sensor and/or actuator of interest (e.g., sensors and/or actuators directly and indirectly associated with the triggered indicator). The one or more measurements may be based on a particular number of measurements or particular duration of time around the time of the triggered abnormal-condition indicator.
• For example, if a triggered fault code isFault Code 2 fromFIG. 3, the sensors and actuators of interest might include Actuator B and Sensor C. The one or more measurements may include the most recent respective measurements obtained by Actuator B and Sensor C prior to the triggering of the fault code (e.g., triggering measurements) or a respective set of measurements before, after, or about the triggering measurements. For example, a set of five measurements may include the five measurements before or after the triggering measurement (e.g., excluding the triggering measurement), the four measurements before or after the triggering measurement and the triggering measurement, or the two measurements before and the two after as well as the triggering measurement, among other possibilities.
• Similar to signal data, the abnormal-condition data may take various forms. In general, the abnormal-condition data may include or take the form of an indicator that is operable to uniquely identify a particular abnormal condition that occurred at theasset108 from all other abnormal conditions that may occur at theasset108. The abnormal-condition indicator may take the form of an alphabetic, numeric, or alphanumeric identifier, among other examples. Moreover, the abnormal-condition indicator may take the form of a string of words that is descriptive of the abnormal condition, such as “Overheated Engine” or “Out of Fuel,” among other examples.
• Asset-related event data may take various forms as well. In example implementations, event data may include an indicator of the type of event that occurred (e.g., a fault code was triggered, diagnostics were run, a fluid anomaly occurred, etc.), a timestamp identifying when the particular event occurred, and/or a duration of time indicating how long the event occurred. Other examples are also possible.
• Theasset data platform102, and in particular, the data intake system of theasset data platform102, may be configured to receive operating data from one or more local analytics devices and/or data sources. The data intake system may be configured to intake at least a portion of the received data, perform one or more operations to the received data, and then relay the data to the data analysis system of theasset data platform102. In turn, the data analysis system may analyze the received data and based on such analysis, perform one or more operations. As one example, theasset data platform102 may be configured to define, modify, and/or execute a predictive model (e.g., a predictive model related to the operation of assets, such as an asset failure model) based on such received operating data. These example operations are discussed in U.S. patent application Ser. No. 14/732,258, which is incorporated herein by reference in its entirety.
V. EXAMPLE METHODS
• Turning now toFIG. 9, a flow diagram is depicted illustrating anexample method900 for provisioning a local analytics device to interact with an asset data platform on behalf of an asset that may be performed by thelocal analytics device220. For themethod900 and the other methods discussed below, the operations illustrated by the blocks in the flow diagrams may be performed in line with the above discussion. Moreover, one or more operations discussed above may be added to a given flow diagram.
• Atblock902, themethod900 may involve thelocal analytics device220 obtaining, via an asset interface of the local analytics device, a plurality of asset data, where each asset data is indicative of a configuration parameter of the asset. Atblock904, themethod900 may involve thelocal analytics device220, based on the plurality of asset data, determining an asset signature for the asset. Atblock906, themethod900 may involve thelocal analytics device220, transmitting, via a network interface of the local analytics device, to a computing device executing an application for provisioning the local analytics device (e.g., the provisioning device114), the determined asset signature. Atblock908, themethod900 may involve thelocal analytics device220, in response to transmitting the determined asset signature, receiving, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset. Atblock910, themethod900 may involve thelocal analytics device220 utilizing the data-management credential to interact with the remote computing system (e.g., the asset data platform102) on behalf of the asset.
• FIG. 10 depicts a flow diagram of anexample method1000 for provisioning a local analytics to interact with an asset data platform on behalf of an asset that may be performed by theprovisioning device114. Atblock1002, themethod1000 may involve theprovisioning device114, in response to transmitting an account credential to the remote computing system (e.g., the asset data platform102), receiving from the remote computing system an asset-management credential and one or more asset identifiers, wherein each asset identifier corresponds to a given asset associated with a customer account. Atblock1004, themethod1000 may involve theprovisioning device114 receiving from the local analytics device an asset signature, where the asset signature is indicative of a configuration of the asset. Atblock1006, themethod1000 may involve theprovisioning device114, based on the one or more asset identifiers and the asset signature, determining that the asset is associated with the customer account. Atblock1008, themethod1000 may involve theprovisioning device114 determining that a provisioning permission is associated with the asset-management credential. Atblock1010, themethod1000 may involve theprovisioning device114, based on (1) determining that the asset is associated with the customer account and (2) determining that the provisioning permission is associated with the asset-management credential, transmitting to the local analytics device a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset.
• FIG. 11 depicts a flow diagram of anexample method1100 for provisioning a local analytics device to interact with an asset data platform on behalf of an asset that may be performed by theasset data platform102. Atblock1102, themethod1100 may involve theasset data platform102 maintaining a plurality of asset-management credentials and a plurality of asset identifiers, where each asset identifier corresponds to a given asset associated with a customer account. Atblock1104, themethod1100 may involve theasset data platform102, based on an account credential received from theprovisioning device114 an account credentials, transmitting to theprovisioning device114 an asset-management credential and one or more asset identifiers. Atblock1106, themethod1100 may involve theasset data platform102 receiving from the local analytics device an operation instruction comprising a data-management credential that is based on the asset-management credential. Atblock1108, themethod1100 may involve theasset data platform102 performing an operation for the asset in response to receiving the data-management credential from the local analytics device.
VI. CONCLUSION
• Example embodiments of the disclosed innovations have been described above. Those skilled in the art will understand, however, that changes and modifications may be made to the embodiments described without departing from the true scope and sprit of the present invention, which will be defined by the claims.
• Further, to the extent that examples described herein involve operations performed or initiated by actors, such as “humans”, “operators”, “users” or other entities, this is for purposes of example and explanation only. The claims should not be construed as requiring action by such actors unless explicitly recited in the claim language.

Claims (20)

1. A local analytics device configured to interact with a remote computing system on behalf of an asset after the local analytics device has been provisioned, the local analytics device comprising:

an asset interface configured to couple the local analytics device to the asset;

a network interface configured to communicatively couple the local analytics device to the remote computing system via a wide-area 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 local analytics device to:

obtain, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset;

based on the plurality of asset data, determine an asset signature for the asset;

transmit, via the network interface, to a computing device configured to execute an application for provisioning the local analytics device, the determined asset signature;

in response to transmitting the determined asset signature, receive, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset; and

utilize the data-management credential to interact with the remote computing system on behalf of the asset.

2. The local analytics device ofclaim 1, wherein the program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor are further configured to cause the local analytics device to:

before obtaining the plurality of asset data, transmit a plurality of queries to the asset, and wherein obtaining the plurality of asset data is in response to the plurality of queries.

3. The local analytics device ofclaim 1, wherein the program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor are further configured to cause the local analytics device to:

before determining the asset signature, execute at least one asset-identification predictive model based on the plurality of asset data, wherein executing the at least one asset-identification predictive model outputs a likelihood that the asset is of a particular asset type.

4. The local analytics device ofclaim 3, wherein determining the asset signature comprises determining the asset signature based on executing the at least one asset-identification predictive model.

5. The local analytics device ofclaim 1, wherein the asset signature comprises the plurality of asset data compiled in a particular sequence.

6. The local analytics device ofclaim 1, wherein before determining the asset signature the local analytics device was in a powered-off state, and wherein the program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor are further configured to cause the local analytics device to:

before utilizing the data-management credential to interact with the remote computing on behalf of the asset, determine whether the local analytics device was coupled to the asset prior to the powered-off state.

7. The local analytics device ofclaim 6, wherein the local analytics device comprises signal data, and wherein the program instructions stored on the non-transitory computer-readable medium that are executable by the at least one processor are further configured to cause the local analytics device to, before utilizing the data-management credential to interact with the remote computing on behalf of the asset:

if the local analytics device was not coupled to the asset prior to the powered-off state, store the signal data in a particular memory location of the local analytics device; and

otherwise, utilize the data-management credential to publish the signal data to the remote computing system.

8. The local analytics device ofclaim 1, wherein utilizing the data-management credential to interact with the remote computing system comprises utilizing the data-management credential to instruct the remote computing system to transmit to the local analytics device, via the network interface, one or more predictive models related to the operation of the asset.

9. A non-transitory computer-readable medium having instructions stored thereon that are executable to cause a local analytics device coupled to an asset, via an asset interface of the local analytics device, to:

obtain, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset;

based on the plurality of asset data, determine an asset signature for the asset;

transmit, via a network interface, to a computing device configure to execute an application for provisioning the local analytics device, the determined asset signature;

in response to transmitting the determined asset signature, receive, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset; and

utilize the data-management credential to interact with a remote computing system on behalf of the asset, wherein the remote computing system is communicatively coupled with the local analytics device via a wide-area network.

10. The non-transitory computer-readable medium ofclaim 9, wherein the instructions are further executable to cause the local analytics device to:

before determining the asset signature, execute at least one asset-identification predictive model based on the plurality of asset data, wherein executing the at least one asset-identification predictive model outputs a likelihood that the asset is of a particular asset type.

11. The non-transitory computer-readable medium ofclaim 10, wherein determining the asset signature comprises determining the asset signature based on executing the at least one asset-identification predictive model.

12. The non-transitory computer-readable medium ofclaim 9, wherein before determining the asset signature the local analytics device was in a powered-off state, and wherein the instructions are further executable to cause the local analytics device to:

before utilizing the data-management credential to interact with the remote computing on behalf of the asset, determine whether the local analytics device was coupled to the asset prior to the powered-off state.

13. The non-transitory computer-readable medium ofclaim 12, wherein the local analytics device comprises signal data, and wherein the instructions are further executable to cause the local analytics device to, before utilizing the data-management credential to interact with the remote computing on behalf of the asset:

if the local analytics device was not coupled to the asset prior to the powered-off state, store the signal data in a particular memory location of the local analytics device; and

otherwise, utilize the data-management credential to publish the signal data to the remote computing system.

14. The non-transitory computer-readable medium ofclaim 9, wherein utilizing the data-management credential to interact with the remote computing system comprises utilizing the data-management credential to instruct the remote computing system to transmit to the local analytics device, via the network interface, one or more predictive models related to the operation of the asset.

15. A method performed by a local analytics device coupled to an asset via an asset interface to provision the local analytics device to interact with a remote computing system on behalf of the asset, the method comprising:

obtaining, via the asset interface, a plurality of asset data, wherein each asset data is indicative of a configuration parameter of the asset;

based on the plurality of asset data, determining an asset signature for the asset;

transmitting, via a network interface of the local analytics device, to a computing device executing an application for provisioning the local analytics device, the determined asset signature;

in response to transmitting the determined asset signature, receiving, via the network interface, a data-management credential for enabling the local analytics device to perform one or more operations on behalf of the asset; and

utilizing the data-management credential to interact with the remote computing system on behalf of the asset.

16. The method ofclaim 15, wherein the method further comprises, before determining the asset signature, executing at least one asset-identification predictive model based on the plurality of asset data, wherein executing the at least one asset-identification predictive model outputs a likelihood that the asset is of a particular asset type.

17. The method ofclaim 16, wherein determining the asset signature comprises determining the asset signature based on executing the at least one asset-identification predictive model.

18. The method ofclaim 15, wherein before determining the asset signature the local analytics device was in a powered-off state, and wherein the method further comprises, before utilizing the data-management credential to interact with the remote computing on behalf of the asset, determining whether the local analytics device was coupled to the asset prior to the powered-off state.

19. The method ofclaim 18, wherein the local analytics device comprises signal data, and wherein the method further comprises, before utilizing the data-management credential to interact with the remote computing on behalf of the asset:

if the local analytics device was not coupled to the asset prior to the powered-off state, storing the signal data in a particular memory location of the local analytics device; and

otherwise, utilizing the data-management credential to publish the signal data to the remote computing system.

20. The method ofclaim 15, wherein utilizing the data-management credential to interact with the remote computing system comprises utilizing the data-management credential to publish asset-related data to the remote computing system.

Images