U.S. patent application number 15/370225 was filed with the patent office on 2017-12-07 for provisioning a local analytics device.
The applicant listed for this patent is Uptake Technologies, Inc.. Invention is credited to Brett Heliker, Brad Nicholas.
Application Number | 20170353353 15/370225 |
Document ID | / |
Family ID | 60483606 |
Filed Date | 2017-12-07 |
United States Patent
Application |
20170353353 |
Kind Code |
A1 |
Nicholas; Brad ; et
al. |
December 7, 2017 |
Provisioning a Local Analytics Device
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.
Inventors: |
Nicholas; Brad; (Wheaton,
IL) ; Heliker; Brett; (Chicago, IL) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Uptake Technologies, Inc. |
Chicago |
IL |
US |
|
|
Family ID: |
60483606 |
Appl. No.: |
15/370225 |
Filed: |
December 6, 2016 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62345170 |
Jun 3, 2016 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
H04L 41/0803 20130101;
H04W 4/50 20180201; H04W 4/38 20180201; H04W 4/70 20180201; H04L
67/12 20130101; H04L 67/34 20130101; G07C 5/0808 20130101 |
International
Class: |
H04L 12/24 20060101
H04L012/24; H04L 29/08 20060101 H04L029/08 |
Claims
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 of claim 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 of claim 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 of claim 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 of claim 1, wherein the asset
signature comprises the plurality of asset data compiled in a
particular sequence.
6. The local analytics device of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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 of claim 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.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] 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
[0002] 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).
[0003] 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
[0004] 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.
[0005] "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.
[0006] 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.
[0007] 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.
[0008] 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.
[0009] 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.
[0010] 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.
[0011] 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.
[0012] 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.
[0013] 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.
[0014] 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.
[0015] 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.
[0016] 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).
[0017] 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.
[0018] 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.
[0019] 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.
[0020] 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.
[0021] 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.
[0022] 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.
[0023] 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).
[0024] 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.
[0025] 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.
[0026] 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.
[0027] 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.
[0028] 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.
[0029] 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.
[0030] 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.
[0031] 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.
[0032] 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.
[0033] 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.
[0034] 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
[0035] FIG. 1 depicts an example network configuration in which
example embodiments may be implemented.
[0036] FIG. 2 depicts a simplified block diagram of an example
asset.
[0037] FIG. 3 depicts a conceptual illustration of example
abnormal-condition indicators and triggering criteria.
[0038] FIG. 4 depicts a structural diagram of an example
platform.
[0039] FIG. 5 depicts a functional block diagram of an example
platform.
[0040] FIG. 6 depicts a conceptual illustration of information
related to a customer account and relationships between such
information.
[0041] FIG. 7 is a signal flow diagram that depicts example signal
flows that may occur while provisioning a local analytics
device.
[0042] FIG. 8a is a flow diagram that depicts example operations
that may occur for determining whether to store asset-related data
locally.
[0043] FIG. 8b is a flow diagram that depicts example operations
that may occur for determining whether to transmit a credential
based on stored information.
[0044] 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.
[0045] FIG. 10 depicts a flow diagram of an example method for
provisioning a local analytics device that may be performed by a
provisioning device.
[0046] 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
[0047] 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
[0048] Turning now to the figures, FIG. 1 depicts an example
network configuration 100 in which example embodiments may be
implemented. As shown, the network configuration 100 includes at
its core a remote computing system 102 that may be configured as an
asset data platform, which may communicate via a communication
network 104 with one or more assets, such as representative assets
106 and 108, one or more data sources, such as representative data
source 110, and one or more mobile computing devices, such as
representative provisioning device 114 (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.
[0049] Broadly speaking, the asset data platform 102 (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. The asset data platform 102 is discussed in
further detail below with reference to FIG. 4.
[0050] As shown in FIG. 1, the asset data platform 102 may be
configured to communicate, via the communication network 104, with
the one or more assets 106, 108, data sources 110, and/or mobile
computing devices 114 (or other output devices/systems) in the
network configuration 100. For example, the asset data platform 102
may receive asset-related data, via the communication network 104,
that is sent by one or more assets, data sources, and/or mobile
computing devices. As another example, the asset data platform 102
may transmit asset-related data and/or commands, via the
communication network 104, 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, the asset data
platform 102 may be configured to receive, via the communication
network 104, 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.
The asset data platform 102 may engage in other types of
communication via the communication network 104 as well.
[0051] In general, the communication network 104 may include one or
more computing systems and network infrastructure configured to
facilitate transferring data between asset data platform 102 and
the one or more assets, data sources, mobile computing devices,
and/or output systems in the network configuration 100. The
communication network 104 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, the communication network 104 may include one or
more cellular networks and/or the Internet, among other networks.
The communication network 104 may operate according to one or more
communication protocols, such as LTE, CDMA, GSM, LPWAN, WiFi,
Bluetooth, Ethernet, HTTP/S, TCP, CoAP/DTLS and the like. Although
the communication network 104 is shown as a single network, it
should be understood that the communication network 104 may include
multiple, distinct networks that are themselves communicatively
linked. Further, in example cases, the communication network 104
may facilitate secure communications between network components
(e.g., via encryption or other security measures). The
communication network 104 could take other forms as well.
[0052] Further, although not shown, the communication path between
the asset data platform 102 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 the asset data
platform 102 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 as representative provisioning
device 114, and the asset data platform 102 may then be configured
to receive the asset-related data from the mobile computing device.
Further still, the asset data platform 102 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.
[0053] In general, the assets 106 and 108 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.
[0054] 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.
[0055] As such, in some examples, the assets 106 and 108 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, the assets 106
and 108 may have different asset types or classes. For instance,
assets 106 and 108 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.
[0056] 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 to FIG. 2.
[0057] In general, the data source 110 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 the asset data platform 102. For example,
the data source 110 may collect and provide operating data that
originates from the assets (e.g., historical operating data), in
which case the data source 110 may serve as an alternative source
for such asset operating data. As another example, the data source
110 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.
[0058] In one implementation, the data source 110 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.
[0059] In another implementation, the data source 110 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.
[0060] The data source 110 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.
[0061] In practice, the asset data platform 102 may receive data
from the data source 110 by "subscribing" to a service provided by
the data source. However, the asset data platform 102 may receive
data from the data source 110 in other manners as well.
[0062] In example embodiments, the provisioning device 114 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 the asset data
platform 102 on behalf of an asset (e.g., the asset 108) and
customer account associated with that asset. More particularly, the
provisioning device 114 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,
the provisioning device 114 may run a native software application
and/or a web browser capable of accessing a web application
provided by the asset data platform 102 that may facilitate
communications with the asset data platform 102 and/or assets 106
and 108 via their respective local analytics devices. The
provisioning device 114 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.
[0063] It should be understood that network configuration 100 may
include various other output systems or devices for facilitating
interactions with asset data platform 102, 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.
[0064] It should be understood that the network configuration 100
is one example of a network in which embodiments described herein
may be implemented. Numerous other arrangements are possible and
contemplated herein. For instance, other network configurations may
include additional components not pictured and/or more or less of
the pictured components.
II. EXAMPLE ASSET
[0065] Turning to FIG. 2, a simplified block diagram of an example
asset 200 is depicted. Either or both of assets 106 and 108 from
FIG. 1 may be configured like the asset 200. As shown, the asset
200 may include one or more subsystems 202, one or more sensors
204, one or more actuators 205, a central processing unit 206, data
storage 208, a network interface 210, a user interface 212, a
position unit 214, and also a local analytics device 220, 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 the asset 200 may
include additional components not shown and/or more or less of the
depicted components.
[0066] Broadly speaking, the asset 200 may include one or more
electrical, mechanical, and/or electromechanical components
configured to perform one or more operations. In some cases, one or
more components may be grouped into a given subsystem 202.
[0067] Generally, a subsystem 202 may include a group of related
components that are part of the asset 200. A single subsystem 202
may independently perform one or more operations or the single
subsystem 202 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 to FIG. 1.
[0068] As suggested above, the asset 200 may be outfitted with
various sensors 204 that are configured to monitor operating
conditions of the asset 200 and various actuators 205 that are
configured to interact with the asset 200 or a component thereof
and monitor operating conditions of the asset 200. In some cases,
some of the sensors 204 and/or actuators 205 may be grouped based
on a particular subsystem 202. In this way, the group of sensors
204 and/or actuators 205 may be configured to monitor operating
conditions of the particular subsystem 202, and the actuators from
that group may be configured to interact with the particular
subsystem 202 in some way that may alter the subsystem's behavior
based on those operating conditions.
[0069] In general, a sensor 204 may be configured to detect a
physical property, which may be indicative of one or more operating
conditions of the asset 200, and provide an indication, such as an
electrical signal, of the detected physical property. In operation,
the sensors 204 may be configured to obtain measurements
continuously, periodically (e.g., based on a sampling frequency),
and/or in response to some triggering event. In some examples, the
sensors 204 may be preconfigured with operating parameters for
performing measurements and/or may perform measurements in
accordance with operating parameters provided by the central
processing unit 206 (e.g., sampling signals that instruct the
sensors 204 to obtain measurements). In examples, different sensors
204 may have different operating parameters (e.g., some sensors may
sample based on a first frequency, while other sensors sample based
on a second, different frequency). In any event, the sensors 204
may be configured to transmit electrical signals indicative of a
measured physical property to the central processing unit 206. The
sensors 204 may continuously or periodically provide such signals
to the central processing unit 206.
[0070] For instance, sensors 204 may be configured to measure
physical properties such as the location and/or movement of the
asset 200, in which case the sensors may take the form of GNSS
sensors, dead-reckoning-based sensors, accelerometers, gyroscopes,
pedometers, magnetometers, or the like. In example embodiments, one
or more such sensors may be integrated with or located separate
from the position unit 214, discussed below.
[0071] Additionally, various sensors 204 may be configured to
measure other operating conditions of the asset 200, 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.
[0072] As suggested above, an actuator 205 may be configured
similar in some respects to a sensor 204. Specifically, an actuator
205 may be configured to detect a physical property indicative of
an operating condition of the asset 200 and provide an indication
thereof in a manner similar to the sensor 204.
[0073] Moreover, an actuator 205 may be configured to interact with
the asset 200, one or more subsystems 202, and/or some component
thereof. As such, an actuator 205 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.
[0074] Generally, the central processing unit 206 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, the central processing unit 206 may be
or include microprocessors, microcontrollers, SoCs ("system on a
chip"), application specific integrated circuits, digital signal
processors, and the like. In turn, the data storage 208 may be or
include one or more non-transitory computer-readable storage media,
such as optical, magnetic, organic, or flash memory, among other
examples.
[0075] The central processing unit 206 may be configured to store,
access, and execute computer-readable program instructions stored
in the data storage 208 to perform the operations of an asset
described herein. For instance, as suggested above, the central
processing unit 206 may be configured to receive respective sensor
signals from the sensors 204 and/or actuators 205. The central
processing unit 206 may be configured to store sensor and/or
actuator data in and later access it from the data storage 208.
[0076] The central processing unit 206 may also be configured to
determine whether received sensor and/or actuator signals trigger
any abnormal-condition indicators, such as fault codes. For
instance, the central processing unit 206 may be configured to
store in the data storage 208 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, the
asset 200 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 the asset data
platform 102.
[0077] In any event, the central processing unit 206 may be
configured to determine whether received sensor and/or actuator
signals trigger any abnormal-condition indicators. That is, the
central processing unit 206 may determine whether received sensor
and/or actuator signals satisfy any triggering criteria. When such
a determination is affirmative, the central processing unit 206 may
generate abnormal-condition data and then may also cause the
asset's network interface 210 to transmit the abnormal-condition
data to the asset data platform 102 and/or cause the asset's user
interface 212 to output an indication of the abnormal condition,
such as a visual and/or audible alert. Additionally, the central
processing unit 206 may log the occurrence of the
abnormal-condition indicator being triggered in the data storage
208, perhaps with a timestamp.
[0078] 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, table 300 includes
columns 302, 304, and 306 that correspond to Sensor A, Actuator B,
and Sensor C, respectively, and rows 308, 310, and 312 that
correspond to Fault Codes 1, 2, and 3, respectively. Entries 314
then specify sensor criteria (e.g., sensor value thresholds) that
correspond to the given fault codes.
[0079] 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.degree. 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.degree. C., and Fault 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.degree. C. One of
ordinary skill in the art will appreciate that FIG. 3 is provided
for purposes of example and explanation only and that numerous
other fault codes and/or triggering criteria are possible and
contemplated herein.
[0080] Referring back to FIG. 2, the central processing unit 206
may be configured to carry out various additional functions for
managing and/or controlling operations of the asset 200 as well.
For example, the central processing unit 206 may be configured to
provide instruction signals to the subsystems 202 and/or the
actuators 205 that cause the subsystems 202 and/or the actuators
205 to perform some operation, such as modifying a throttle
position. Additionally, the central processing unit 206 may be
configured to modify the rate at which it processes data from the
sensors 204 and/or the actuators 205, or the central processing
unit 206 may be configured to provide instruction signals to the
sensors 204 and/or actuators 205 that cause the sensors 204 and/or
actuators 205 to, for example, modify a sampling rate. Moreover,
the central processing unit 206 may be configured to receive
signals from the subsystems 202, the sensors 204, the actuators
205, the network interfaces 210, the user interfaces 212, and/or
the position unit 214 and based on such signals, cause an operation
to occur. Further still, the central processing unit 206 may be
configured to receive signals from a computing device, such as a
diagnostic device, that cause the central processing unit 206 to
execute one or more diagnostic tools in accordance with diagnostic
rules stored in the data storage 208. Other functionalities of the
central processing unit 206 are discussed below.
[0081] The network interface 210 may be configured to provide for
communication between the asset 200 and various network components
connected to the communication network 104. For example, the
network interface 210 may be configured to facilitate wireless
communications to and from the communication network 104 and may
thus take the form of an antenna structure and associated equipment
for transmitting and receiving various over-the-air signals. In
practice, the network interface 210 may be configured according to
a communication protocol, such as but not limited to any of those
described above. In some cases, the asset 200 may not include the
network interface 210. Other examples are possible as well.
[0082] The user interface 212 may be configured to facilitate user
interaction with the asset 200 and may also be configured to
facilitate causing the asset 200 to perform an operation in
response to user interaction. Examples of user interfaces 212
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 interface 212 may include or provide connectivity
to output components, such as display screens, speakers, headphone
jacks, and the like.
[0083] The position unit 214 may be generally configured to
facilitate performing functions related to geo-spatial
location/position and/or navigation. More specifically, the
position unit 214 may be configured to facilitate determining the
location/position of the asset 200 and/or tracking the asset 200'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, the position unit
214 may include one or more sensors and/or receivers that are
configured according to one or more particular positioning
technologies.
[0084] In example embodiments, the position unit 214 may allow the
asset 200 to provide to other systems and/or devices (e.g., the
asset data platform 102) position data that indicates the position
of the asset 200, which may take the form of GPS coordinates, among
other forms. In some implementations, the asset 200 may provide to
other systems position data continuously, periodically, based on
triggers, or in some other manner. Moreover, the asset 200 may
provide position data independent of or along with other
asset-related data (e.g., along with operating data).
[0085] The local analytics device 220 may generally be configured
to receive and analyze data related to the asset 200 and based on
such analysis, may cause one or more operations to occur at the
asset 200. For instance, the local analytics device 220 may receive
operating data for the asset 200 (e.g., signal data or derived data
based on signal data generated by the sensors 204 and/or actuators
205) and based on such data, may provide instructions to the
central processing unit 206, the sensors 204, and/or the actuators
205 that cause the asset 200 to perform an operation. In another
example, the local analytics device 220 may receive location data
from the position unit 214 and based on such data, may modify how
it handles predictive models and/or workflows for the asset 200. In
still another example, the central processing unit 206 may provide
access to data in data storage 208 that was not generated by the
sensors 204 and/or actuators 205 (e.g., data generated by an
embedded computer). Other example analyses and corresponding
operations are also possible.
[0086] To facilitate some of these operations, the local analytics
device 220 may include one or more asset interfaces 221 that are
configured to couple the local analytics device 220 to one or more
of the asset's on-board systems. As such, the one or more asset
interfaces 221 may take various forms, such as a diagnostic port or
some other input/output connector.
[0087] For instance, as shown in FIG. 2, the local analytics device
220 may connect to the asset's central processing unit 206 via an
asset interface 221, which may enable the local analytics device
220 to receive data at the direction of the central processing unit
206 (e.g., operating data that is generated by sensors 204 and/or
actuators 205 and sent to the central processing unit 206, position
data generated by the position unit 214, or other asset data from
data storage 208) and then provide instructions to the central
processing unit 206. In this way, the local analytics device 220
may indirectly interface with and receive data from other on-board
systems of the asset 200 (e.g., the subsystems 202, sensors 204,
and/or actuators 205) via the central processing unit 206.
[0088] Additionally or alternatively, as shown in FIG. 2, the local
analytics device 220's asset interface 221 could interface to one
or more sensors 204 and/or actuators 205, which may enable the
local analytics device 220 to communicate directly with the sensors
204 and/or actuators 205.
[0089] Further still, the local analytics device 220 may
additionally or alternatively connect to the asset via the local
analytics device 220's network interface 226 and the asset's
network interface 210. The local analytics device 220 may interface
with the on-board systems of the asset 200 in other manners as
well, including the possibility that the interfaces illustrated in
FIG. 2 are facilitated by one or more intermediary systems that are
not shown.
[0090] In example embodiments, the local analytics device 220 may
be physically coupled to the asset 200 either at the time the asset
200 was manufactured or sometime after. That is, in some cases, the
local analytics device 220 may be added to the asset 200 as
after-market add-on equipment. Other examples are also
possible.
[0091] Moreover, the local analytics device 220 may be configured
to execute one or more operations that facilitate allowing the
local analytics device 220 to interact with the asset data platform
102 on behalf of the asset 200. As one example, interacting with
the asset data platform 102 may involve publishing asset-related
data to the asset data platform 102. The asset data platform 102
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.
[0092] In practice, the local analytics device 220 may locally
perform advanced analytics and associated operations, such as
executing a predictive model and corresponding workflow, for the
asset 200 that may otherwise not be able to be performed with the
other on-asset components. As such, the local analytics device 220
may help provide additional processing power and/or intelligence to
the asset 200.
[0093] It should be understood that the local analytics device 220
may also be configured to cause the asset 200 to perform operations
that are not related to a predictive model. For example, the local
analytics device 220 may receive data from a remote source, such as
the asset data platform 102 or one or more output devices, and
based on the received data cause the asset 200 to perform one or
more operations. One particular example may involve the local
analytics device 220 receiving a firmware update for the asset 200
from a remote source and then causing the asset 200 to update its
firmware. Another particular example may involve the local
analytics device 220 receiving a diagnosis instruction from a
remote source and then causing the asset 200 to execute a local
diagnostic tool in accordance with the received instruction.
Numerous other examples are also possible.
[0094] As shown, in addition to the one or more asset interfaces
discussed above, the local analytics device 220 may also include a
processing unit 222, a data storage 224, and a network interface
226, all of which may be communicatively linked by a system bus,
network, or other connection mechanism. The processing unit 222 may
include any of the components discussed above with respect to the
central processing unit 206. In turn, the data storage 224 may be
or include one or more non-transitory computer-readable storage
media, which may take any of the forms of computer-readable storage
media discussed above.
[0095] The processing unit 222 may be configured to store, access,
and execute computer-readable program instructions stored in the
data storage 224 to perform the operations of a local analytics
device described herein. For instance, the processing unit 222 may
be configured to receive respective sensor and/or actuator signals
generated by the sensors 204 and/or actuators 205 and may execute a
predictive model and corresponding workflow based on such signals.
Other functions are described below.
[0096] The network interface 226 may be one more network interfaces
configured the same or similar to the network interfaces described
above. In one example, the network interface 226 may facilitate
communication between the local analytics device 220 and the asset
data platform 102. Additionally or alternatively, the network
interface 226 may facilitate communication between the local
analytics device 220 and the provisioning device 114 (as depicted
in FIG. 1 by communication path 112). In some such cases, the local
analytics device 220 and provisioning device 114 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 or more network
interfaces 226 allow the local analytics device 220 to communicate
with other devices over separate networks and/or communication
paths. For example, the local analytics device 220 may communicate
with the asset data platform 102 via the communication network 104
(e.g., a cellular network) and with the provisioning device 114 via
an ad-hoc network link 112 (e.g., Bluetooth, WiFi, CAN, LPWAN or
mesh network) that is separate from the communication network 104.
Other examples are also possible.
[0097] In some example implementations, the local analytics device
220 may include and/or communicate with a user interface that may
be similar to the user interface 212. In practice, the user
interface may be located remote from the local analytics device 220
(and the asset 200). Other examples are also possible.
[0098] While FIG. 2 shows the local analytics device 220 physically
and communicatively coupled to its associated asset (e.g., the
asset 200) via one or more asset interfaces, it should also be
understood that this might not always be the case. For example, in
some implementations, the local analytics device 220 may not be
physically coupled to its associated asset and instead may be
located remote from the asset 200. In an example of such an
implementation, the local analytics device 220 may be wirelessly,
communicatively coupled to the asset 200. Other arrangements and
configurations are also possible.
[0099] 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.
[0100] One of ordinary skill in the art will appreciate that the
asset 200 shown in FIG. 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
[0101] FIG. 4 is a simplified block diagram illustrating some
components that may be included in an example asset data platform
400 from a structural perspective. In line with the discussion
above, the asset data platform 400 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 a processor
402, data storage 404, network interface 406, and perhaps also a
user interface 410, all of which may be communicatively linked by a
communication link 408, such as a system bus, network, or other
connection mechanism.
[0102] The processor 402 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, the processing unit 402 may include
microprocessors, microcontrollers, application-specific integrated
circuits, digital signal processors, and the like.
[0103] In turn, the data storage 404 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.
[0104] The data storage 404 may be provisioned with software
components that enable the platform 400 to carry out the functions
disclosed herein. These software components may generally take the
form of program instructions that are executable by the processor
402 and may be arranged together into applications, software
development kits, toolsets, or the like. In addition, the data
storage 404 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.
[0105] The network interface 406 may be configured to facilitate
wireless and/or wired communication between the platform 400 and
various network components via the communication network 104, such
as assets 106 and 108, data source 110, and provisioning device
114. As such, the network interface 406 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. The network interface 406
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.
[0106] The example asset platform 400 may also support a user
interface 410 that is configured to facilitate user interaction
with the platform 400 and may also be configured to facilitate
causing the platform 400 to perform an operation in response to
user interaction. This user interface 410 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 interface
410 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 interface
410 is embodied within a client station that is communicatively
coupled to the asset data platform 400.
[0107] Referring now to FIG. 5, another simplified block diagram is
provided to illustrate some components that may be included in an
example asset data platform 500 from a functional perspective. For
instance, as shown, the example platform 500 may include a data
intake system 502 and a data analysis system 504, each of which
comprises a combination of hardware and software that is configured
to carry out particular functions. The platform 500 may also
include one or more databases 506 coupled to one or more of the
data intake system 502 and the data analysis system 504. In
practice, these functional systems may be implemented on a single
computer system or distributed across a plurality of computer
systems.
[0108] The data intake system 502 may generally function to receive
asset-related data and then provide at least a portion of the
received data to the data analysis system 504. As such, the data
intake system 502 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 the data intake system 502 may
take various forms, examples of which may include analog signals,
data streams, and/or network packets. Further, in some examples,
the data intake system 502 may be configured according to a given
dataflow technology, such as a NiFi receiver or the like.
[0109] In some embodiments, before the data intake system 502
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 a data agent 508. In general, the
data agent 508 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 the platform 500 for receipt by the data intake system 502.
As such, the data agent 508 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 the example platform 500 without the assistance of a data
agent.
[0110] The data received by the data intake system 502 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 the data intake system 502 may
take other forms as well.
[0111] The data intake system 502 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 the platform 500 that manage the data.
For example, the data intake system 502 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, the
data intake system 502 may assess the reliability (or "health") of
the received data and potentially drop any unreliable data. As yet
another example, the data intake system 502 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, the data intake system 502 may determine that the
received data is related to data already stored in the platform's
database 506 (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, the data intake system
502 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.
[0112] In some embodiments, it is also possible that the data agent
508 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 the data agent 508 rather than
the data intake system 502. Other examples are possible as
well.
[0113] The data intake system 502 may further be configured to
store the received data in the database 506 for later retrieval. In
line with the discussion above, the database 506 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, the database
506 may provide for poly-glot storage. For example, the database
506 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.
[0114] As shown, the data intake system 502 may then be
communicatively coupled to the data analysis system 504. This
interface between the data intake system 502 and the data analysis
system 504 may take various forms. For instance, the data intake
system 502 may be communicatively coupled to the data analysis
system 504 via an API. Other interface technologies are possible as
well.
[0115] In one implementation, the data intake system 502 may
provide, to the data analysis system 504, 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 the data analysis system 504 may also include
other data and take other forms as well.
[0116] The data analysis system 504 may generally function to
receive data from the data intake system 502, analyze that data,
and then take various actions based on that data. For example, the
data analysis system 504 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, the data analysis system 504 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, the data analysis
system 504 may use the received data to train and/or execute a
predictive model related to asset operation, and the data analysis
system 504 may then take certain actions based on the predictive
model's output. As still another example, the data analysis system
504 may make certain data available for external access via an
API.
[0117] In order to facilitate one or more of these functions, the
data analysis system 504 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, the data analysis system 504 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.
[0118] In addition to analyzing the received data for taking
potential actions based on such data, the data analysis system 504
may also be configured to store the received data into database
506. The database 506 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.
[0119] In some embodiments, the data analysis system 504 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.
[0120] The data analysis system 504 may perform various other
functions as well. Some functions performed by the data analysis
system 504 are discussed in further detail below.
[0121] In example embodiments, the asset data platform 500 may be
configured to create and store customer accounts for entities that
utilize services hosted by the asset data platform 500. In
practice, a given customer account may be created based on data
provided to the asset data platform 500 from an external device,
such as the provisioning device 114, 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.
[0122] One of ordinary skill in the art will appreciate that the
example platform shown in FIGS. 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
[0123] The operations of the example network configuration 100
depicted in FIG. 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.
[0124] The following description may reference examples where a
single data source provides data to the asset data platform 102
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, the asset data platform 102
generally receives data from multiple sources, perhaps
simultaneously, and performs operations based on such aggregate
received data.
[0125] A. Provisioning Local Analytics Devices
[0126] As mentioned above, in accordance with example embodiments,
a local analytics device (e.g., the local analytics device 220) may
be coupled to an asset (e.g., the asset 108) and undergo
provisioning operations that allow the local analytics device to
interact with the asset data platform 102 on behalf of the asset
and a particular customer account hosted by the asset data platform
102.
[0127] For purposes of explanation and illustration, some of the
provisioning operations may be discussed with reference to FIG. 7,
which depicts a signal flow diagram 700 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 diagram 700 are described as being carried out
by the local analytics device 220, the provisioning device 114, and
the asset data platform 102, but other devices and/or systems may
carry out these example operations. One of ordinary skill will
appreciate that diagram 700 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.
[0128] 1. Customer Account Information
[0129] As a preliminary matter, the asset data platform 102 may be
configured to store account information for customers that obtain
services that are hosted by the asset data platform 102. For
instance, a given customer may own and/or operate the assets 106
and 108 and may utilize services provided by the asset data
platform 102 that monitor the operating conditions of those assets.
Specifically, a local analytics device may be utilized for each
asset 106 and 108 to facilitate such asset monitoring.
[0130] 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 in FIG. 6,
information related to the customer account is represented in
tables 600, 610, 620, and 630. Specifically, the table 600 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
table 610 maps a particular asset role to particular account
credentials (e.g., a username and password combination). The table
620 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 table 630 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.
[0131] More specifically, the table 600 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.
[0132] 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 the asset data platform 102
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.
[0133] 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.
[0134] The table 610 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 table 610 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.
[0135] Table 620 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 the asset data platform 102 on behalf of the
particular asset).
[0136] Table 630 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.
[0137] 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.
[0138] 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 the
asset data platform 102 on behalf of a particular asset. Examples
of such interactions may include publishing asset data to the asset
data platform 102, instructing the asset data platform 102 to
provide certain information or predictive models to the local
analytics device, and/or instructing the asset data platform 102 to
perform certain data services for the asset, among other
examples.
[0139] 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 the asset data platform 102 on behalf
of itself. For instance, the local analytics device may be
authorized to report back to the asset data platform 102 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 the asset data platform 102.
[0140] The tables shown in FIG. 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.
[0141] 2. Initiation of Provisioning Operations
[0142] Prior to asset-condition monitoring for the asset 108, the
local analytics device 220 may be installed on the asset 108.
Typically, this operation may involve a user (e.g., asset operator,
technician, etc.) physically coupling the local analytics device to
the asset 108. In example implementations, based on the design of
the local analytics device 220, the local analytics device 220 may
be physically coupled to asset 108 in a relatively simple manner
without requiring expert knowledge and/or physical modification of
the asset 108. For example, the local analytics device 220 may be
physically coupled to the asset via an asset interface, such as an
asset diagnostics port, which may allow the local analytics device
220 to communicate with one or more of the asset 108's on-board
components and/or systems (e.g., sensor(s) 204, actuator(s) 205,
the central processing unit 206, the data storage 208, etc.). In
example embodiments, the local analytics device 220 may communicate
with the asset 108 according to one or more asset communication
protocols (e.g., J1939, etc.), which may depend on the asset type.
The local analytics device 220 may be coupled to the asset 108 and
communicate therewith in various other ways.
[0143] After the local analytics device 220 is coupled to the asset
108, it may be then configured to initiate operations that
facilitate provisioning the local analytics device 220. In
practice, the local analytics device 220 may initiate such
operations based on a number of triggers ("initiation triggers").
In example embodiments, initiation triggers generally involve the
local analytics device 220 detecting a change in physical state of
the asset 108.
[0144] One example trigger may involve the local analytics device
220 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, the local analytics device 220 may detect that power
has been applied to it based on the asset 108 being turned on or
based on the local analytics device 220 receiving a manual power on
input (e.g., via a switch, button, etc.), among other examples. In
practice, the local analytics device 220 may receive power from the
asset 108, may contain its own power source, or some combination of
both.
[0145] Additionally or alternatively, an initiation trigger may
take the form of the local analytics 220 being first installed on
an asset and/or the local analytics device 220 receiving an
instruction from a provisioning device based on the provisioning
device executing a provisioning application. Other examples of
initiation triggers are also possible.
[0146] 3. Asset Discovery
[0147] After the occurrence of an initiation trigger, the local
analytics device 220 may perform asset discovery operations to
determine the identity of the asset to which the local analytics
device 220 is coupled (e.g., the asset 108), as identified in FIG.
7 at block 702. That is, the local analytics device 220 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, the local analytics device 220, the provisioning device
114, the asset data platform 102, or some combination thereof may
then confirm that that asset is associated with the particular
customer account (discussed in detail below).
[0148] In general, the asset identification operations involve the
local analytics device 220 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.
[0149] 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.
[0150] Accordingly, an asset signature may enable the local
analytics device 220 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.
[0151] 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.
[0152] 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).
[0153] As mentioned above, the local analytics device 220 may
determine an asset signature in a number of manners. Generally, the
local analytics device 220 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. The local analytics device 220 then utilizes the plurality
of data to define the asset signature. Moreover, the local
analytics device 220 may maintain a record of the sequence of
operations that it used to generate the asset signature ("a
signature sequence") to enable the local analytics device 220
and/or the asset data platform 102 to reproduce the asset signature
for various reasons, such as asset confirmation (discussed in
further detail below).
[0154] In a first example embodiment, the local analytics device
220 may determine an asset signature based on one or more queries
to the asset 108 that return data indicative of the asset 108's
configuration. The one or more queries and any respective responses
may be based on an industry protocol, such as SAE 1939, or other
electronic identification mechanism that may be specific to
particular assets.
[0155] Specifically, the local analytics device 220 may transmit to
the asset 108, via one or more asset interfaces, a request for
identity information. The asset 108 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 the asset 108's on-board systems maintaining such information
(e.g., data storage, etc.).
[0156] In practice, the asset 108 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 the asset 108's type, class (e.g., make, model,
year, etc.), serial number, and/or other information regarding the
asset 108's configuration. Additionally or alternatively, the
identity information may include details regarding some or all of
the asset 108's components or subsystems, such as their own
respective configurations, firmware versions, serial numbers,
etc.
[0157] 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.
[0158] In any event, the local analytics device 220 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 the local analytics device 220 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, the asset 108 may be configured to auto-identify
itself in a manner that does not require an explicit query action
from the local analytics device 220.
[0159] In a second example embodiment, the local analytics device
220 may determine an asset signature based at least on passive data
traffic monitoring of the asset 108. That is, the local analytics
device 220 may define the asset signature for the asset 108 based
on asset data and/or characteristics thereof that the local
analytics device 220 obtains from the computer systems of the asset
108. 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 the local
analytics device 220 defines the asset signature based on the
nature of the asset 108's data, as opposed to on identity
information that inherently provides some indication of the asset
108's configuration.
[0160] 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.
[0161] In any event, as mentioned above, the local analytics device
220 may receive, monitor, or otherwise obtain from the asset 108
various asset data from which an asset signature can be derived.
For instance, the local analytics device 220 may request and
receive particular data from the asset 108, such as signal data
generated by specific sensors and/or actuators, among other
examples. It should be noted that, in some implementations, the
local analytics device 220 may not be required to request asset
data but instead, the asset 108 may be configured to automatically
push certain data to the local analytics device 220 periodically or
based on certain triggers. In another instance, the local analytics
device 220 may additionally or alternatively monitor, via an asset
interface, data traffic occurring on the asset 108. Other examples
are also possible.
[0162] After obtaining the asset data, the local analytics device
220 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, the local analytics device 220 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, the local
analytics device 220 may then define the asset signature, which may
involve the local analytics device 220 concatenating a particular
sequence of the asset data, among other possibilities.
[0163] In a third example embodiment, the local analytics device
220 may determine an asset signature based on a data-model-based
asset discovery process. In one particular example of such a
discovery process, the local analytics device 220 may first execute
one or more asset-identification predictive models based on asset
data from the asset 108 that helps to identify the particular type
of the asset 108 and then perform individualized procedures for
that asset type to obtain from the asset 108 data and/or
characteristics thereof that are used to generate an asset
signature.
[0164] 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 asset 108) is of a particular asset type. Thus, in practice,
the local analytics device 220 may include multiple
asset-identification predictive models; one for each possible asset
type that the local analytics device 220 could be coupled to. The
local analytics device 220 may then execute each of these multiple
asset-identification predictive models and use the results
therefrom to help derive the asset signature.
[0165] 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.
[0166] 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.
[0167] The example modeling phase may involve the asset data
platform 102 analyzing historical data for a plurality of assets of
various asset types. From those assets, the asset data platform 102
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.
[0168] Once the asset data platform 102 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, the asset data platform 102
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.
[0169] After the asset data platform 102 defines the one or more
asset-identification predictive models, the asset data platform 102
may provide the models to the local analytics device 220 for use in
the discovery process. In practice, the asset data platform 102 may
transmit the models to the local analytics device 220 via the
communication network 104, or the models may be pre-loaded on the
local analytics device 220. In either case, the asset data platform
102 and/or the local analytics device 220 may update and/or modify
one or more of the models over time.
[0170] During the execution phase, the local analytics device 220
may execute the one or more asset-identification predictive models
based on asset data obtained via the asset 108's asset interfaces.
Specifically, the local analytics device 220 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 the local analytics device 220 to determine and output
one or more probabilities (e.g., a value between 0-1) that the
asset 108 is of a particular asset type.
[0171] Based on the outputs of the asset-identification models, the
local analytics device may then identify the most likely type of
the asset 108. 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.
[0172] In any event, after the local analytics device 220
identifies the most likely asset type of the asset 108, it may then
perform certain procedures for that asset type to obtain from the
asset 108 data and/or characteristics thereof that are used to
generate the asset signature. For instance, based on the results of
the predictive models, the local analytics device 220 may then
monitor for certain asset data and/or query certain computer
systems of the asset 108. Then, the local analytics device 220 may
define the asset signature, which may be similar in form as
discussed above.
[0173] Alternatively, if the local analytics device 220 is unable
to identify a most likely asset type (e.g., if no probability
exceeds the confidence probability threshold), the local analytics
device 220 may be configured to transmit to the asset 108
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, the local analytics device 220 may be configured to
determine asset identification information based on predictive
models in various other manners as well.
[0174] The above discussion has set forth various ways in which the
local analytics device 220 may determine asset signatures. It
should be noted, however, that local analytics device 220 may
utilize any one, all, or some combination of the described
processes (or some other processes) to determine asset signatures.
For example, the local analytics device 220 may utilize a
query-based approach to determine the asset 108's Component
Identification Information and a messaging-traffic-based approach
to determine the asset 108'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 the asset data platform 102. Other examples are
also possible.
[0175] As discussed in further detail below, after the local
analytics device 220 determines an asset signature for the asset
108 that it is attached to, the local analytics device 220 may
provide that asset signature to other devices, such as the
provisioning device 114, to help in the provisioning operations.
Moreover, the local analytics device 220 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.
[0176] 4. Asset Confirmation
[0177] In example embodiments, the local analytics device 220 may
be further configured to evaluate whether the asset to which the
local analytics device 220 is currently coupled (e.g., the asset
108) is the same asset that the local analytics device 220 last
obtained data for. For instance, after the local analytics device
220 is powered on from a powered-off state, the local analytics
device 220 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.
[0178] The local analytics device 220 may perform this operation in
a variety of manners. As one example, the local analytics device
220 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.
[0179] In another example, the local analytics device 220 may
perform this confirmation process independent of any determined
asset signature. For example, in one embodiment, the local
analytics device 220 may store in memory the most recent signature
sequence and responses thereto and then utilize that stored
information to perform the asset confirmation. Specifically, the
local analytics device 220 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 the local analytics device 220 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, the local analytics device 220 may be
configured to execute a functionally equivalent set of operations
that facilitate confirming the asset.
[0180] If the local analytics device 220 confirms that the asset it
is presently coupled with is the same asset that it last obtained
data for, then the local analytics device 220 continues operating
in a "paired to a specific asset" state. For instance, the local
analytics device 220 may continue with the provisioning process or
may interact with the asset data platform 102 on behalf of the
asset 108, assuming it is authorized to do so.
[0181] Otherwise, the local analytics device 220 may enter a state
(e.g., an "unprovisioned state") where the local analytics device
220 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, the local analytics device 220 helps to ensure that it
does not corrupt the data for the present asset or the data for the
previous asset. Thereafter, the local analytics device 220 may
continue with the provisioning process with respect to the present
asset.
[0182] Additionally, in example embodiments, the local analytics
device 220 may at some later time transmit the data for the
previous asset to the asset data platform 102 and/or provide to the
asset data platform 102 a notice that the local analytics device
220 is no longer coupled with the previous asset, thereby allowing
the asset data platform 102 to track whether assets have an active,
connected local analytics device.
[0183] 5. Coupling Provisioning & Local Analytics Device
[0184] Before, after, or while the local analytics device 220
determines the asset signature, a communication link may be
established between the local analytics device 220 and the
provisioning device 114. For example, returning to FIG. 7, at 704,
the provisioning device 114 may seek to establish a network
connection with the local analytics device 220. In example
embodiments, this operation may involve the provisioning device 114
broadcasting an "alive" message, which may generally indicate that
the provisioning device 114 is ready to connect to a local
analytics device. In some cases, the provisioning device 114 may
broadcast such a message based on the provisioning device 114
receiving an input via the provisioning application and/or
receiving from the asset data platform 102 a provisioning
credential, among other examples. While FIG. 7 depicts the
provisioning device 114 initiating the connection to the local
analytics device 220, this may not always be the case. Indeed, in
some example embodiments, the local analytics device 220 may
instead initiate a connection to the provisioning device 114, which
may be based on detecting one or more of the trigger events
discussed above.
[0185] In a particular example, either the local analytics device
220 or the provisioning device 114 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, the local analytics device 220 and the
provisioning device 114 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.
[0186] 6. Exchange of Credentials
[0187] Before, after, or while a network connection is established
between the local analytics device 220 and the provisioning device
114, the provisioning device 114 may act in concert with the asset
data platform 102 to authenticate one or more customer accounts.
For example, the provisioning device 114 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. The provisioning device 114 may then, at 706 of FIG.
7, transmit the account credential (or a representation thereof) to
the asset data platform 102, which in turn may or may not
authenticate the log-in attempt and either provide or deny access
to the customer account.
[0188] In some cases, a customer account may not exist yet.
Accordingly, the provisioning device 114 may receive inputs, via
the provisioning application, that facilitate creating a new
customer account. The provisioning device 114 may provide data
indicative of such inputs to the asset data platform 102, which in
turn may register the new account and store information for that
account. As discussed above, the asset data platform 102 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 in FIG. 6, among other information.
[0189] In any event, after the asset data platform 102 receives the
account credential from the provisioning device 114, it may proceed
to determine whether to authenticate that account credential. For
instance, returning to FIG. 6, the asset data platform 102 may be
configured to cross-reference the table 610 with the received
account credential and for example, determine whether the username
and password combination match any row in the table 610. If the
asset data platform 102 determines that the account credential
matches a row in the table 610, the asset data platform 102 may
determine the asset-role identifier for that row and reference the
table 600 to identify a corresponding asset-management credential
and/or asset-management permissions.
[0190] Then, at 708 of FIG. 7, the asset data platform 102 may
provide to the provisioning device 114 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 the provisioning device 114 has received the
asset-management credential and asset identifiers, the provisioning
device 114 may store this information for use in the provisioning
process.
[0191] On the other hand, if the asset data platform 102 determines
that the account credential does not match any row in the table
610, it may then instead transmit a notification to the
provisioning device 114 that access is denied. Similarly, in
example embodiments, even if the asset data platform 102 determines
that there is a match, the asset data platform 102 may nonetheless
deny access if the asset-management permissions associated with
that account credential does not cover the attempted interaction.
For instance, if the asset data platform 102 receives the account
credential from a device executing a provisioning application and
that account credential is not associated with a provisioning
permission, then the asset data platform 102 may provide an
appropriate notification back to that device. The asset data
platform 102 may authenticate account credentials in a variety of
different manners, and/or computing systems independent of the
asset data platform 102 may carry out such authentication
processes.
[0192] Notably, the exchange of account and asset-management
credentials by the provisioning device 114 and asset data platform
102 does not have to occur after the local analytics device 220 is
coupled to the asset 108 or a network connection is established
between the local analytics device 220 and provisioning device 114.
Rather, the provisioning device 114 and asset data platform 102 may
authenticate account credentials at any time, so long as a
communication path (e.g., network connection) exists between the
two.
[0193] At some point in time after the communication link is
established between the local analytics device 220 and the
provisioning device 114, the local analytics device 220 may, at 710
of FIG. 7, transmit to the provisioning device 114 the asset
signature that was determined by the local analytics device 220.
Based at least on the asset signature, the provisioning device 114
may determine whether the asset 108 that the local analytics device
220 is attached to is indeed associated with the particular
customer account. The provisioning device 114 may perform this
operation in a variety of manners.
[0194] 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 the communication
network 104 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.
[0195] Accordingly, asset identifiers may be generated in a variety
of manners. In an example embodiment, the local analytics device
220 and/or the provisioning device 114 provides the asset signature
to the asset data platform 102, which in turn determines whether
that asset signature is currently mapped to an asset identifier. If
not, the asset data platform 102 may generate an asset identifier
that maps to that asset signature and store that identifier and
association in a database. In example embodiments, when the asset
data platform 102 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 the asset data
platform 102 generates the asset identifier and stores the
association with the asset signature (or if the asset data platform
102 determines that the asset signature is already mapped to an
asset identifier), it may then inform the local analytics device
220 and/or the provisioning device 114 of the asset identifier and
association.
[0196] In another example embodiment, the local analytics device
220 and/or the provisioning device 114 may locally generate an
asset identifier for the asset signature, which may be necessary if
there is no data connection back to the asset data platform 102.
Some time later, the local analytics device 220 and/or the
provisioning device 114 may provide the asset data platform 102 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), the asset
data platform 102 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, the
asset data platform 102, the provisioning device 114, and the local
analytics device 220 may each maintain a mapping of asset
signatures to asset identifiers for the particular customer account
that can be dynamically updated.
[0197] Returning to the provisioning operations, the provisioning
device 114 may utilize the received asset identifiers and the
received asset signature to verify that the asset 108 is indeed an
asset associated with the particular customer account. That is, the
provisioning device 114 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 the provisioning device 114 may infer that the
asset 108 is not associated with this customer account and
terminate the provisioning process for that customer account.
[0198] Alternatively, instead of the local analytics device 220, at
710 of FIG. 7, transmitting the asset signature to the provisioning
device 114, the local analytics device 220 may itself identify the
asset based on the asset signature and transmit to the provisioning
device 114 the appropriate asset identifier. For example, the local
analytics device 220 may compare the determined asset signature to
a plurality of asset signatures locally stored by the local
analytics device 220 and associated with corresponding asset
identifiers also locally stored. In example embodiments, the local
analytics device 220 may have previously received one or more of
the plurality of asset signatures from the asset data platform 102
that maintains the master database of such signatures. As such, the
local analytics device 220 and the asset data platform 102 may
collaboratively perform asset discovery operations to facilitate
identifying the particular asset to which the local analytics
device 220 is connected.
[0199] In any event, based on this comparison, the local analytics
device 220 may locate a stored asset signature matching (or most
closely matching) the asset signature determined for the asset 108.
From the matching signature, the local analytics device 220 may
then determine the corresponding asset identifier and transmit that
identifier to the provisioning device 114.
[0200] In some scenarios, neither the local analytics device 220
nor the provisioning device 114 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 the asset data platform 102, the local analytics device 220
and/or the provisioning device 114 may provide to the asset data
platform 102 part or all of the asset signature, which may then
assist in this confirmation step.
[0201] If there is no network connection back to the asset data
platform 102 (or if the asset data platform 102 cannot confirm),
the provisioning device 114 may query the user to assist in this
confirmation step. In particular, the provisioning device 114 may
instruct the user to use the provisioning device 114 to capture an
image of the asset 108's identification tag or the like (e.g., a
VIN plate) or instruct the user to manually enter such asset
identification information. For example, the provisioning device
114 may include a digital camera configured to capture and process
images. The provisioning device 114 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 the asset data platform 102 so that the asset
data platform 102 can supplement its asset signature-identifier
mapping to help expand the knowledge of the asset 108's
identity.
[0202] Before, after, or simultaneous with confirming that the
local analytics device 220 is attached to a particular asset that
is associated with the particular customer account, the
provisioning device 114 may determine whether the one or more
asset-management credentials that it received from the asset data
platform 102 (e.g., at 708 of FIG. 7) provide the provisioning
device 114 provisioning permission for the particular asset (e.g.,
the asset 108). If the provisioning device 114 confirms this and
the asset is confirmed, then the provisioning device 114 may, at
712 of FIG. 7, provide to the local analytics device 220 one or
more data-management credentials.
[0203] In example embodiments, before exchanging any
data-management credential, the provisioning device 114 may first
identify a data-management credential that should be transferred to
the local analytics device 220, which may be performed in a variety
of manners. As one example, the provisioning device 114 identifies
the data-management credential by receiving the data-management
credential from the asset data platform 102, perhaps along with the
asset-management credential, and determining that the
data-management credential is for the local analytics device 220.
As discussed above, depending on the provisioning device 114's
permissions, the provisioning device 114 may or may not have access
to the data-management credential before it transmits the
credential to the local analytics device 220.
[0204] In another example, the provisioning device 114 identifies
the data-management credential by generating or otherwise deriving
the data-management credential based on the received
asset-management credential. For instance, the provisioning device
114 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.
[0205] As such, the provisioning device 114 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.
[0206] In any event, the local analytics device 220 receives the
one or more data-management credentials from the provisioning
device 114, thereby completing the provisioning process. The local
analytics device 220 may then store the received information in
data storage to later perform operations on behalf of the asset
108, as discussed below.
[0207] 7. Operating on Behalf of Asset
[0208] The local analytics device 220 may utilize the received
data-management credential to interact with the asset 108 and/or
with the asset data platform 102 on behalf of the asset 108. In
some example embodiments, the local analytics device 220 may also
receive from the provisioning device 114 (or perhaps the asset data
platform 102) an indication of the permissions corresponding to the
data-management credential (e.g., as defined in the table 630 of
FIG. 6), which may then dictate the type of operations that the
local analytics device 220 may perform on behalf of the asset
108.
[0209] In example embodiments, the local analytics device 220
interacting with the asset data platform 102 involves, at 714 of
FIG. 7, the local analytics device 220 transmitting to the asset
data platform 102 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, the asset data platform 102
may determine (e.g., via the permissions from the table 630 for
that data-management credential) whether the local analytics device
220 has authority to perform or cause the asset data platform 102
to perform a particular operation in accordance with the operation
instruction. In the event that the local analytics device 220 is
not so authorized, the asset data platform 102 may deny that
interaction by the local analytics device 220 and perhaps provide
an appropriate notification to the local analytics device 220
and/or the provisioning device 114.
[0210] At 716 of FIG. 7, the asset data platform 102 confirmed that
the local analytics device 220 is authorized to interact with the
asset data platform 102 on behalf of the asset 108 and as a result,
followed the operation instruction provided by the local analytics
device 220. In this example, the local analytics device 220
interacted with the asset data platform 102 by publishing
asset-related data on behalf of the asset 108 to the asset data
platform 102 and instructing the asset data platform 102 to execute
one or more predictive models based on such data for the asset 108.
The asset data platform 102 executed those models and provided the
results therefrom back to the local analytics device 220.
[0211] The asset-related data published by the local analytics
device 220 to the asset data platform 102 may take a variety of
forms, such as signal data (e.g., sensor and/or actuator data),
position data generated by the asset 108, abnormal condition
indicators triggered by the asset 108, and/or outputs of predictive
models executed by the local analytics device 220. The local
analytics device 220 may publish various other forms of
asset-related data. Furthermore, the local analytics device 220 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.
[0212] The local analytics device 220 may interact with the asset
data platform 102 on behalf of the asset 108 in a variety of other
manners as well. For example, it may instruct the asset data
platform 102 to allow it to download from the asset data platform
102 certain predictive models for local execution by the local
analytics device 220 based on operating data from the asset 108. As
another example, it may instruct the asset data platform 102 to
perform various operations for the asset 108, such as perform one
or more data services for the asset 108's data. Various other
examples are also possible.
[0213] In example embodiments, the asset data platform 102 may be
configured to revoke (e.g., invalidate) a given credential at any
time. In such instances, the asset data platform 102 may or may not
provide an explicit revocation notification to the local analytics
device 220. In instances where such a notification is not provided,
any subsequent data management attempt by the local analytics
device 220 would fail. In instances where such a notification is
provided, the local analytics device 220 would require a new
credential before attempting any data management operations related
to that revoked credential. Other examples are also possible.
[0214] 8. Operating without Complete Network Availability
[0215] The foregoing discussion in reference to FIG. 7 assumed that
communication paths existed between the local analytics device 220
and asset data platform 102 and the provisioning device 114 and
asset data platform 102. 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, the local analytics device 220 may
still be able to be provisioned, if at a minimum the local
analytics device 220 and provisioning device 114 are able to
communicate with one another.
[0216] For instance, the local analytics device 220 may be
provisioned even if only the provisioning device 114 is able to
communicate with the asset data platform 102 (i.e., even if the
local analytics device 220 cannot directly communicate with the
asset data platform 102). In such an example, the provisioning
device 114 may perform one or more operations on behalf of the
local analytics device 220 to facilitate provisioning it.
[0217] For example, the provisioning device 114 may act in concert
with the asset data platform 102 to authenticate account
credentials, as discussed above. Furthermore, the local analytics
device 220 may be configured to determine that no communication
path exists between it and the asset data platform 102 (e.g., no
network connection, poor quality connection, etc.), and based on
that determination, transmit the asset 108's asset signature to the
provisioning device 114. Thereafter, the provisioning device 114
may forward to the local analytics device 220 a data-management
credential, in line with the above discussion. In this example, the
local analytics device 220 may be configured to collect and locally
store asset-related data and may publish that data or otherwise
interface with the asset data platform 102 upon detecting a network
connection between it and the asset data platform 102 at a time in
the future.
[0218] FIG. 8a is a flow diagram 800a that depicts example
operations for determining whether to publish or locally store
asset-related data. After the local analytics 220 detects certain
changes in physical state of the asset 108 (e.g., detecting a
power-on state) and has confirmed that it is still connected to the
previously identified asset 108 (as discussed above), at block 802,
it may determine whether a network connection is available to the
communication network 104 (e.g., whether a communication path
exists between the local analytics device 220 and the asset data
platform 102). If a network connection is available (block 804),
the local analytics device 220 may communicate with the asset data
platform 102 to determine whether the asset 108 is registered
(e.g., whether the table 620 indicates a registered state for the
asset 108). If the local analytics device 220 determines that the
asset 108 is in fact registered in the customer account, it may
publish, at block 806, asset-related data on behalf of the asset
108 or otherwise interact with the asset data platform 102 on the
asset 108's behalf. However, if the local analytics device 220
determines that no network connection is available and/or that the
asset 108 is unregistered, at block 808, it may collect and locally
store asset-related data.
[0219] In practice, the local analytics device 220 may repeat the
example process depicted by FIG. 8a during operation by (perhaps
periodically or continuously) checking for an available network
connection in order to publish asset-related data to the asset data
platform 102 on behalf of the asset 108. However, the local
analytics device 220 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, the local analytics device 220
may be configured to forgo some or all of the operations of FIG.
8a.
[0220] In another example, the local analytics device 220 may be
provisioned even if only the local analytics device 220 is able to
communicate with the asset data platform 102 (i.e., even if the
provisioning device 114 cannot directly communicate with the asset
data platform 102). As noted above, the provisioning device 114 and
asset data platform 102 may act in concert to authenticate account
credentials at a time when a communication path exists between the
two. The provisioning device 114 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, the
provisioning device 114 may be configured to locally store a
data-management credential from a prior provisioning operation.
[0221] Accordingly, in a scenario in which no communication path
exists between the provisioning device 114 and asset data platform
102, the provisioning device 114 may transmit a previously stored
data-management credential to the local analytics device 220 or
generate a data-management credential based on a previously stored
asset-management credential and transmit the generated
data-management credential to the local analytics device 220.
Thereafter, the local analytics device 220 may utilize the received
data-management credential in line with the above discussion,
thereby allowing the local analytics device 220 to then interact
with the asset data platform 102 on behalf of the asset 108,
provided it has authority to do so.
[0222] FIG. 8b is an example flow diagram 800b that depicts example
operations for determining whether a provisioning device 114 will
transmit credentials to a local analytics device 220 that are based
on previously stored credentials on the provisioning device 114. At
block 810, the provisioning device 114 communicatively coupled to
the local analytics device 220 may determine whether a network
connection is available to the communication network 104 (e.g.,
whether a communication path exists to the asset data platform
102). If the provisioning device 114 determines that a network
connection is available, at block 812, it may act in concert with
the asset data platform 102 to authenticate account credentials, as
discussed above.
[0223] However, if the provisioning device 114 determines that no
network connection is available, at block 814, it may determine
whether the provisioning device 114 has a suitable asset-management
credential (or data-management credential) previously stored in
memory. At block 816, based on a credential that was previously
stored, the provisioning device 114 may transmit a data-management
credential to the local analytics device 220. In the event that the
provisioning device 114 includes credentials for multiple accounts,
the provisioning device 114 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, the provisioning device 114 may continuously or
periodically check for a network connection (e.g., block 810) in
order to facilitate the provisioning of the local analytics
device.
[0224] In yet another example, neither the provisioning device 114
nor the local analytics device 220 has connectivity to the asset
data platform 102. In practice, either or both of the provisioning
device 114 and local analytics device 220 may be configured to
determine that no communication path exists with the asset data
platform 102 and in response to such determinations, may be further
configured to nonetheless perform certain provisioning operations.
For example, the local analytics device 220 may transmit to the
provisioning device 114 the asset 108's asset signature, and/or the
provisioning device 114 may transmit to the local analytics device
220 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.
[0225] B. Collection of Operating Data
[0226] As mentioned above, each of the representative assets 106
and 108 may take various forms and may be configured to perform a
number of operations. In a non-limiting example, the asset 108 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 the asset 108 may obtain data that reflects one or
more operating conditions of the asset 108. The sensors and/or
actuators may transmit the data to a processing unit of the asset
108.
[0227] 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.
[0228] The asset may then transmit operating data to the local
analytics device 220 via the asset interface, or the local
analytics device 220 may obtain the operating data via the asset
interface itself. In turn, the local analytics device 220 may
transmit the operating data to the asset data platform 102 via the
network interface of local analytics device 220 and the
communication network 104. In operation, the local analytics device
220 may transmit operating data to the asset data platform 102
continuously, periodically, and/or in response to triggering events
(e.g., abnormal conditions). Specifically, the local analytics
device 220 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 the local analytics
device 220 may be configured to transmit a continuous, real-time
feed of operating data. Additionally or alternatively, the local
analytics device 220 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. The local analytics device 220 may transmit operating
data in other manners as well.
[0229] 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, the local analytics device 220 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, the local
analytics device 220 may provide to the asset data platform 102 a
first data stream of signal data and a second data stream of
abnormal-condition data. As another example, the local analytics
device 220 may provide to the asset data platform 102 a separate
data stream for each respective sensor and/or actuator on the asset
108. Other possibilities also exist.
[0230] 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 the asset 108. While at other
times, sensor data (or actuator data) may include measurements
obtained by a subset of the sensors (or actuators) of the asset
108.
[0231] 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 is Fault Code 1 from FIG. 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, the asset 108 may
include particular sensor data in the operating data based on a
fault-code rule or instruction provided by the analytics system
108, which may have, for example, determined that there is a
correlation between that which Actuator B is measuring and that
which caused the Fault Code 1 to be triggered in the first place.
Other examples are also possible.
[0232] 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.
[0233] 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.
[0234] For example, if a triggered fault code is Fault Code 2 from
FIG. 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.
[0235] 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 the asset
108 from all other abnormal conditions that may occur at the asset
108. 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.
[0236] 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.
[0237] The asset data platform 102, and in particular, the data
intake system of the asset data platform 102, 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 the asset data platform 102. In turn, the
data analysis system may analyze the received data and based on
such analysis, perform one or more operations. As one example, the
asset data platform 102 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
[0238] Turning now to FIG. 9, a flow diagram is depicted
illustrating an example method 900 for provisioning a local
analytics device to interact with an asset data platform on behalf
of an asset that may be performed by the local analytics device
220. For the method 900 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.
[0239] At block 902, the method 900 may involve the local analytics
device 220 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. At block 904,
the method 900 may involve the local analytics device 220, based on
the plurality of asset data, determining an asset signature for the
asset. At block 906, the method 900 may involve the local analytics
device 220, 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
device 114), the determined asset signature. At block 908, the
method 900 may involve the local analytics device 220, 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. At block 910, the method 900 may involve the local
analytics device 220 utilizing the data-management credential to
interact with the remote computing system (e.g., the asset data
platform 102) on behalf of the asset.
[0240] FIG. 10 depicts a flow diagram of an example method 1000 for
provisioning a local analytics to interact with an asset data
platform on behalf of an asset that may be performed by the
provisioning device 114. At block 1002, the method 1000 may involve
the provisioning device 114, in response to transmitting an account
credential to the remote computing system (e.g., the asset data
platform 102), 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. At block 1004, the method 1000
may involve the provisioning device 114 receiving from the local
analytics device an asset signature, where the asset signature is
indicative of a configuration of the asset. At block 1006, the
method 1000 may involve the provisioning device 114, based on the
one or more asset identifiers and the asset signature, determining
that the asset is associated with the customer account. At block
1008, the method 1000 may involve the provisioning device 114
determining that a provisioning permission is associated with the
asset-management credential. At block 1010, the method 1000 may
involve the provisioning device 114, 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.
[0241] FIG. 11 depicts a flow diagram of an example method 1100 for
provisioning a local analytics device to interact with an asset
data platform on behalf of an asset that may be performed by the
asset data platform 102. At block 1102, the method 1100 may involve
the asset data platform 102 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. At block 1104, the method 1100 may involve
the asset data platform 102, based on an account credential
received from the provisioning device 114 an account credentials,
transmitting to the provisioning device 114 an asset-management
credential and one or more asset identifiers. At block 1106, the
method 1100 may involve the asset data platform 102 receiving from
the local analytics device an operation instruction comprising a
data-management credential that is based on the asset-management
credential. At block 1108, the method 1100 may involve the asset
data platform 102 performing an operation for the asset in response
to receiving the data-management credential from the local
analytics device.
VI. CONCLUSION
[0242] 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.
[0243] 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.
* * * * *