U.S. patent application number 16/142758 was filed with the patent office on 2019-03-28 for web services for smart entity creation and maintenance using time series data.
The applicant listed for this patent is Johnson Controls Technology Company. Invention is credited to Vijaya S. Chennupati, Youngchoon Park, Erik S. Paulson, Sudhi R. Sinha, Vaidhyanathan Venkiteswaran.
Application Number | 20190095518 16/142758 |
Document ID | / |
Family ID | 65807587 |
Filed Date | 2019-03-28 |
United States Patent
Application |
20190095518 |
Kind Code |
A1 |
Park; Youngchoon ; et
al. |
March 28, 2019 |
WEB SERVICES FOR SMART ENTITY CREATION AND MAINTENANCE USING TIME
SERIES DATA
Abstract
One or more non-transitory computer readable media contain
program instructions that, when executed, cause one or more
processors to: receive first raw data from a first device, the
first raw data including one or more first data points generated by
the first device; generate first input timeseries according to the
data points; access a database of interconnected smart entities,
the smart entities including object entities representing each of
the plurality of physical devices and data entities representing
stored data, the smart entities being interconnected by relational
objects indicating relationships between the smart entities;
identify a first object entity representing the first device from a
first device identifier in the first input timeseries; identify a
first data entity from a first relational object indicating a
relationship between the first object entity and the first data
entity; and store the first input timeseries in the first data
entity.
Inventors: |
Park; Youngchoon;
(Brookfield, WI) ; Sinha; Sudhi R.; (Milwaukee,
WI) ; Venkiteswaran; Vaidhyanathan; (Brookfield,
WI) ; Paulson; Erik S.; (Madison, WI) ;
Chennupati; Vijaya S.; (Brookfield, WI) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Johnson Controls Technology Company |
Auburn Hills |
MI |
US |
|
|
Family ID: |
65807587 |
Appl. No.: |
16/142758 |
Filed: |
September 26, 2018 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
62564247 |
Sep 27, 2017 |
|
|
|
62588179 |
Nov 17, 2017 |
|
|
|
62588190 |
Nov 17, 2017 |
|
|
|
62588114 |
Nov 17, 2017 |
|
|
|
62611962 |
Dec 29, 2017 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 9/547 20130101;
H04L 41/12 20130101; G06F 16/9024 20190101; H04L 41/142 20130101;
G06F 16/2228 20190101; H04L 41/024 20130101; H04L 67/10 20130101;
H04L 67/02 20130101; H04W 4/38 20180201; G06F 16/2358 20190101;
G06F 16/288 20190101; H04L 67/32 20130101; G06F 16/2379 20190101;
H04L 69/08 20130101 |
International
Class: |
G06F 17/30 20060101
G06F017/30; H04L 29/08 20060101 H04L029/08; H04L 12/24 20060101
H04L012/24 |
Claims
1. One or more non-transitory computer readable media containing
program instructions that, when executed by one or more processors,
cause the one or more processors to perform operations comprising:
receiving first raw data from a first device of a plurality of
physical devices, the first raw data including one or more first
data points generated by the first device; generating first input
timeseries according to the one or more data points; accessing a
database of interconnected smart entities, the smart entities
comprising object entities representing each of the plurality of
physical devices and data entities representing stored data, the
smart entities being interconnected by relational objects
indicating relationships between the object entities and the data
entities; identifying a first object entity representing the first
device from a first device identifier in the first input
timeseries; identifying a first data entity from a first relational
object indicating a relationship between the first object entity
and the first data entity; and storing the first input timeseries
in the first data entity.
2. The one or more non-transitory computer readable media of claim
1, wherein the relational objects semantically define the
relationships between the object entities and the data
entities.
3. The one or more non-transitory computer readable media of claim
1, wherein one or more of the object entities comprises a static
attribute to identify the object entity, a dynamic attribute to
store data associated with the object entity that changes over
time, and a behavioral attribute that defines an expected response
of the object entity in response to an input.
4. The one or more non-transitory computer readable media of claim
3, wherein the first input timeseries corresponds to the dynamic
attribute of the first object entity.
5. The one or more non-transitory computer readable media of claim
3, wherein at least one of the first data points in the first input
timeseries is stored in the dynamic attribute of the first object
entity.
6. The one or more non-transitory computer readable media of claim
1, wherein the input timeseries includes the first device
identifier, a timestamp indicating a generation time of the one or
more first data points, and a value of the one or more first data
points.
7. The one or more non-transitory computer readable media of claim
6, wherein the instructions further cause the one or more
processors to: identify a second object entity representing a
second device from a second relational object indicating a
relationship between the first object entity and the second object
entity; and identify a second data entity from a third relational
object indicating a relationship between the second object entity
and the second data entity, the second data entity storing second
input timeseries corresponding to one or more second data points
generated by the second device.
8. The one or more non-transitory computer readable media of claim
7, wherein the instructions further cause the one or more
processors to: identify one or more processing workflows that
defines one or more processing operations to generate derived
timeseries using the first and second input timeseries; execute the
one or more processing workflows to generate the derived
timeseries; identify a third data entity from a fourth relational
object indicating a relationship between the first object entity
and the third data entity; and store the derived timeseries in the
third data entity.
9. The one or more non-transitory computer readable media of claim
8, wherein the derived timeseries includes one or more virtual data
points calculated according to the first and second input
timeseries.
10. The one or more non-transitory computer readable media of claim
8, wherein at least one of the first or second devices is a sensor,
and the instructions cause the one or more processors to:
periodically receive measurements from the sensor; and update at
least the derived timeseries in the third data entity each time a
new measurement from the sensor is received.
11. A method for managing data relating to a plurality of physical
devices connected to one or more electronic communications
networks, comprising: receiving, by one or more processors, first
raw data from a first device of a plurality of physical devices,
the first raw data including one or more first data points
generated by the first device; generating, by the one or more
processors, first input timeseries according to the one or more
data points; accessing, by the one or more processors, a database
of interconnected smart entities, the smart entities comprising
object entities representing each of the plurality of physical
devices and data entities representing stored data, the smart
entities being interconnected by relational objects indicating
relationships between the object entities and the data entities;
identifying, by the one or more processors, a first object entity
representing the first device from a first device identifier in the
first input timeseries; identifying, by the one or more processors,
a first data entity from a first relational object indicating a
relationship between the first object entity and the first data
entity; and storing, by the one or more processors, the first input
timeseries in the first data entity.
12. The method of claim 11, wherein the relational objects
semantically define the relationships between the object entities
and the data entities.
13. The method of claim 11, wherein one or more of the object
entities comprises a static attribute to identify the object
entity, a dynamic attribute to store data associated with the
object entity that changes over time, and a behavioral attribute
that defines an expected response of the object entity in response
to an input.
14. The method of claim 13, wherein the first input timeseries
corresponds to the dynamic attribute of the first object
entity.
15. The method of claim 13, wherein at least one of the first data
points in the first input timeseries is stored in the dynamic
attribute of the first object entity.
16. The method of claim 11, wherein the input timeseries includes
the first device identifier, a timestamp indicating a generation
time of the one or more first data points, and a value of the one
or more first data points.
17. The method of claim 16 further comprising: identifying, by the
one or more processors, a second object entity representing a
second device from a second relational object indicating a
relationship between the first object entity and the second object
entity; and identifying, by the one or more processors, a second
data entity from a third relational object indicating a
relationship between the second object entity and the second data
entity, the second data entity storing second input timeseries
corresponding to one or more second data points generated by the
second device.
18. The method of claim 17 further comprising: identifying, by the
one or more processors, one or more processing workflows that
defines one or more processing operations to generate derived
timeseries using the first and second input timeseries; executing,
by the one or more processors, the one or more processing workflows
to generate the derived timeseries; identifying, by the one or more
processors, a third data entity from a fourth relational object
indicating a relationship between the first object entity and the
third data entity; and storing, by the one or more processors, the
derived timeseries in the third data entity.
19. An entity management cloud computing system for managing data
relating to a plurality of physical devices connected to one or
more electronic communications networks, comprising: one or more
processors communicably coupled to a database of interconnected
smart entities, the smart entities comprising object entities
representing each of the plurality of physical devices and data
entities representing stored data, the smart entities being
interconnected by relational objects indicating relationships
between the object entities and the data entities; and one or more
computer-readable storage media communicably coupled to the one or
more processors having instructions stored thereon that, when
executed by the one or more processors, cause the one or more
processors to: receive first raw data from a first device of the
plurality of physical devices, the first raw data including one or
more first data points generated by the first device; generate
first input timeseries according to the one or more data points;
identify a first object entity representing the first device from a
first device identifier in the first input timeseries; identify a
first data entity from a first relational object indicating a
relationship between the first object entity and the first data
entity; and store the first input timeseries in the first data
entity.
20. The system of claim 19, wherein the first input timeseries
includes the first device identifier, a timestamp indicating a
generation time of the one or more first data points, and a value
of the one or more first data points.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of and priority to U.S.
Provisional Patent Application No. 62/564,247 filed Sep. 27, 2017,
U.S. Provisional Patent Application No. 62/588,179 filed Nov. 17,
2017, U.S. Provisional Patent Application No. 62/588,190 filed Nov.
17, 2017, U.S. Provisional Patent Application No. 62/588,114 filed
Nov. 17, 2017, and U.S. Provisional Patent Application No.
62/611,962 filed Dec. 29, 2017. The entire disclosure of each of
these patent applications is incorporated by reference herein.
BACKGROUND
[0002] One or more aspects of example embodiments of the present
disclosure generally relate to creation and maintenance of smart
entities using timeseries data. One or more aspects of example
embodiments of the present disclosure relate to a system and method
for defining relationships of timeseries data between smart
entities. One or more aspects of example embodiments of the present
disclosure relate to a system and method for identifying and
processing timeseries data produced by related smart entities.
[0003] The Internet of Things (IoT) is a network of interconnected
objects (or Things), hereinafter referred to as IoT devices, that
produce data through interaction with the environment and/or are
controlled over a network. An IoT platform is used by application
developers to produce IoT applications for the IoT devices.
Generally, IoT platforms are utilized by developers to register and
manage the IoT devices, gather and analyze data produced by the IoT
devices, and provide recommendations or results based on the
collected data. As the number of IoT devices used in various
sectors increases, the amount of data being produced and collected
has been increasing exponentially. Accordingly, effective analysis
of a plethora of collected data is desired.
SUMMARY
[0004] One implementation of the present disclosure is an entity
management cloud computing system for managing data relating to a
plurality of devices connected to one or more electronic
communications networks. The system includes one or more processors
and one or more computer-readable storage media. The one or more
processors are communicably coupled to a database of interconnected
smart entities, the smart entities including object entities
representing each of the plurality of physical devices and data
entities representing stored data, the smart entities being
interconnected by relational objects indicating relationships
between the object entities and the data entities. The one or more
computer-readable store media are communicably coupled to the one
or more processors and have instructions stored thereon. When
executed by the one or more processors, the instructions cause the
one or more processors to receive first raw data from a first
device of the plurality of physical devices, the first raw data
including one or more first data points generated by the first
device, generate first input timeseries according to the one or
more data points, identify a first object entity representing the
first device from a first device identifier in the first input
timeseries, identify a first data entity from a first relational
object indicating a relationship between the first object entity
and the first data entity, and store the first input timeseries in
the first data entity.
[0005] In some embodiments, the relational objects may semantically
define the relationships between the object entities and the data
entities.
[0006] In some embodiments, one or more of the object entities may
include a static attribute to identify the object entity, a dynamic
attribute to store data associated with the object entity that
changes over time, and a behavioral attribute that defines an
expected response of the object entity in response to an input.
[0007] In some embodiments, the first input timeseries may
correspond to the dynamic attribute of the first object entity.
[0008] In some embodiments, at least one of the first data points
in the first input timeseries may be stored in the dynamic
attribute of the first object entity.
[0009] In some embodiments, the input timeseries may include the
first device identifier, a timestamp indicating a generation time
of the one or more first data points, and a value of the one or
more first data points.
[0010] In some embodiments, the instructions may further cause the
one or more processors to identify a second object entity
representing a second device from a second relational object
indicating a relationship between the first object entity and the
second object entity, and identify a second data entity from a
third relational object indicating a relationship between the
second object entity and the second data entity. The second data
entity may store second input timeseries corresponding to one or
more second data points generated by the second device.
[0011] In some embodiments, the instructions may further cause the
one or more processors to identify one or more processing workflows
that defines one or more processing operations to generate derived
timeseries using the first and second input timeseries, execute the
one or more processing workflows to generate the derived
timeseries, identify a third data entity from a fourth relational
object indicating a relationship between the first object entity
and the third data entity, and store the derived timeseries in the
third data entity.
[0012] In some embodiments, the derived timeseries may include one
or more virtual data points calculated according to the first and
second input timeseries.
[0013] In some embodiments, at least one of the first or second
devices may be a sensor.
[0014] In some embodiments, the instructions may further cause the
one or more processors to periodically receive measurements from
the sensor, and update at least the derived timeseries in the third
data entity each time a new measurement from the sensor is
received.
[0015] In some embodiments, the instructions may further cause the
one or more processors to create a shadow entity to store
historical values of the first raw data.
[0016] In some embodiments, the instructions may further cause the
one or more processors to calculate a virtual data point from the
historical values, and create a fourth data entity to store the
virtual data point.
[0017] Another implementation of the present disclosure is a method
for managing data relating to a plurality of physical devices
connected to one or more electronic communications networks. The
method includes receiving first raw data from a first device of a
plurality of physical devices. The first raw data includes one or
more first data points generated by the first device. The method
includes generating first input timeseries according to the one or
more data points, and accessing a database of interconnected smart
entities. The smart entities include object entities representing
each of the plurality of physical devices and data entities
representing stored data, the smart entities being interconnected
by relational objects indicating relationships between the object
entities and the data entities. The method includes identifying a
first object entity representing the first device from a first
device identifier in the first input timeseries, identifying a
first data entity from a first relational object indicating a
relationship between the first object entity and the first data
entity, and storing the first input timeseries in the first data
entity.
[0018] In some embodiments, the relational objects may semantically
define the relationships between the object entities and the data
entities.
[0019] In some embodiments, one or more of the object entities may
include a static attribute to identify the object entity, a dynamic
attribute to store data associated with the object entity that
changes over time, and a behavioral attribute that defines an
expected response of the object entity in response to an input.
[0020] In some embodiments, the first input timeseries may
correspond to the dynamic attribute of the first object entity.
[0021] In some embodiments, at least one of the first data points
in the first input timeseries may be stored in the dynamic
attribute of the first object entity.
[0022] In some embodiments, the input timeseries may include the
first device identifier, a timestamp indicating a generation time
of the one or more first data points, and a value of the one or
more first data points.
[0023] In some embodiments, the method may further include
identifying a second object entity representing a second device
from a second relational object indicating a relationship between
the first object entity and the second object entity, and
identifying a second data entity from a third relational object
indicating a relationship between the second object entity and the
second data entity. The second data entity may store second input
timeseries corresponding to one or more second data points
generated by the second device.
[0024] In some embodiments, the method may further include
identifying one or more processing workflows that defines one or
more processing operations to generate derived timeseries using the
first and second input timeseries, executing the one or more
processing workflows to generate the derived timeseries,
identifying a third data entity from a fourth relational object
indicating a relationship between the first object entity and the
third data entity, and storing the derived timeseries in the third
data entity.
[0025] In some embodiments, the derived timeseries may include one
or more virtual data points calculated according to the first and
second input timeseries.
[0026] In some embodiments, at least one of the first or second
devices may be a sensor.
[0027] In some embodiments, the method may further include
periodically receiving measurements from the sensor, and updating
at least the derived timeseries in the third data entity each time
a new measurement from the sensor is received.
[0028] In some embodiments, the method may further include creating
a shadow entity to store historical values of the first raw
data.
[0029] In some embodiments, the method may further include
calculating a virtual data point from the historical values, and
creating a fourth data entity to store the virtual data point.
[0030] Another implementation of the present disclosure is one or
more non-transitory computer readable media containing program
instructions. When executed by one or more processors, the
instructions cause the one or more processors to perform operations
including receiving first raw data from a first device of a
plurality of physical devices. The first raw data includes one or
more first data points generated by the first device. The method
includes generating first input timeseries according to the one or
more data points, and accessing a database of interconnected smart
entities. The smart entities include object entities representing
each of the plurality of physical devices and data entities
representing stored data, the smart entities being interconnected
by relational objects indicating relationships between the object
entities and the data entities. The method includes identifying a
first object entity representing the first device from a first
device identifier in the first input timeseries, identifying a
first data entity from a first relational object indicating a
relationship between the first object entity and the first data
entity, and storing the first input timeseries in the first data
entity.
[0031] In some embodiments, the relational objects may semantically
define the relationships between the object entities and the data
entities.
[0032] In some embodiments, one or more of the object entities may
include a static attribute to identify the object entity, a dynamic
attribute to store data associated with the object entity that
changes over time, and a behavioral attribute that defines an
expected response of the object entity in response to an input.
[0033] In some embodiments, the first input timeseries may
correspond to the dynamic attribute of the first object entity.
[0034] In some embodiments, at least one of the first data points
in the first input timeseries may be stored in the dynamic
attribute of the first object entity.
[0035] In some embodiments, the input timeseries may include the
first device identifier, a timestamp indicating a generation time
of the one or more first data points, and a value of the one or
more first data points.
[0036] In some embodiments, the instructions may further cause the
one or more processors to identify a second object entity
representing a second device from a second relational object
indicating a relationship between the first object entity and the
second object entity, and identify a second data entity from a
third relational object indicating a relationship between the
second object entity and the second data entity. The second data
entity may store second input timeseries corresponding to one or
more second data points generated by the second device.
[0037] In some embodiments, the program instructions may further
cause the one or more processors to identify one or more processing
workflows that defines one or more processing operations to
generate derived timeseries using the first and second input
timeseries, execute the one or more processing workflows to
generate the derived timeseries, identify a third data entity from
a fourth relational object indicating a relationship between the
first object entity and the third data entity, and store the
derived timeseries in the third data entity.
[0038] In some embodiments, the derived timeseries may include one
or more virtual data points calculated according to the first and
second input timeseries.
[0039] In some embodiments, at least one of the first or second
devices may be a sensor.
[0040] In some embodiments, the instructions may cause the one or
more processors to periodically receive measurements from the
sensor, and update at least the derived timeseries in the third
data entity each time a new measurement from the sensor is
received.
[0041] In some embodiments, the instructions may further cause the
one or more processors to create a shadow entity to store
historical values of the first raw data.
[0042] In some embodiments, the instructions may further cause the
one or more processors to calculate a virtual data point from the
historical values, and create a fourth data entity to store the
virtual data point.
BRIEF DESCRIPTION OF THE DRAWINGS
[0043] The above and other aspects and features of the present
disclosure will become more apparent to those skilled in the art
from the following detailed description of the example embodiments
with reference to the accompanying drawings, in which:
[0044] FIG. 1 is a block diagram of an IoT environment according to
some embodiments;
[0045] FIG. 2 is a block diagram of an IoT management system,
according to some embodiments;
[0046] FIG. 3 is a block diagram of another IoT management system,
according to some embodiments;
[0047] FIG. 4 is a block diagram illustrating a Cloud entity
service of FIG. 3 in greater detail, according to some
embodiments;
[0048] FIG. 5 in an example entity graph of entity data, according
to some embodiments;
[0049] FIG. 6 is a block diagram illustrating timeseries service of
FIG. 3 in greater detail, according to some embodiments;
[0050] FIG. 7 is a flow diagram of a process or method for
updating/creating an attribute of a related entity based on data
received from a device, according to some embodiments;
[0051] FIG. 8 is an example entity graph of entity data, according
to some embodiments;
[0052] FIG. 9 is a flow diagram of a process or method for
analyzing data from a second related device based on data from a
first device, according to some embodiments; and
[0053] FIG. 10 is a flow diagram of a process or method for
generating derived timeseries from data generated by a first device
and a second device, according to some embodiments.
DETAILED DESCRIPTION
[0054] Hereinafter, example embodiments will be described in more
detail with reference to the accompanying drawings.
[0055] FIG. 1 is a block diagram of an IoT environment according to
some embodiments. The environment 100 is, in general, a network of
connected devices configured to control, monitor, and/or manage
equipment, sensors, and other devices in the IoT environment 100.
The environment 100 may include, for example, a plurality of IoT
devices 102a-102n, a Cloud IoT platform 104, at least one IoT
application 106, a client device 108, and any other equipment,
applications, and devices that are capable of managing and/or
performing various functions, or any combination thereof. Some
examples of an IoT environment may include smart homes, smart
buildings, smart cities, smart cars, smart medical implants, smart
wearables, and the like.
[0056] The Cloud IoT platform 104 can be configured to collect data
from a variety of different data sources. For example, the Cloud
IoT platform 104 can collect data from the IoT devices 102a-102n,
the IoT application(s) 106, and the client device(s) 108. For
example, IoT devices 102a-102n may include physical devices,
sensors, actuators, electronics, vehicles, home appliances,
wearables, smart speaker, mobile phones, mobile devices, medical
devices and implants, and/or other Things that have network
connectivity to enable the IoT devices 102 to communicate with the
Cloud IoT platform 104 and/or be controlled over a network (e.g., a
WAN, the Internet, a cellular network, and/or the like) 110.
Further, the Cloud IoT platform 104 can be configured to collect
data from a variety of external systems or services (e.g., 3rd
party services) 112. For example, some of the data collected from
external systems or services 112 may include weather data from a
weather service, news data from a news service, documents and other
document-related data from a document service, media (e.g., video,
images, audio, social media, etc.) from a media service, and/or the
like. While the devices described herein are generally referred to
as IoT devices, it should be understood that, in various
embodiments, the devices references in the present disclosure could
be any type of devices capable of communicating data over an
electronic network.
[0057] In some embodiments, IoT devices 102a-102n include sensors
or sensor systems. For example, IoT devices 102a-102n may include
acoustic sensors, sound sensors, vibration sensors, automotive or
transportation sensors, chemical sensors, electric current sensors,
electric voltage sensors, magnetic sensors, radio sensors,
environment sensors, weather sensors, moisture sensors, humidity
sensors, flow sensors, fluid velocity sensors, ionizing radiation
sensors, subatomic particle sensors, navigation instruments,
position sensors, angle sensors, displacement sensors, distance
sensors, speed sensors, acceleration sensors, optical sensors,
light sensors, imaging devices, photon sensors, pressure sensors,
force sensors, density sensors, level sensors, thermal sensors,
heat sensors, temperature sensors, proximity sensors, presence
sensors, and/or any other type of sensors or sensing systems.
[0058] Examples of acoustic, sound, or vibration sensors include
geophones, hydrophones, lace sensors, guitar pickups, microphones,
and seismometers. Examples of automotive or transportation sensors
include air flow meters, air-fuel ratio meters, AFR sensors, blind
spot monitors, crankshaft position sensors, defect detectors,
engine coolant temperature sensors, Hall effect sensors, knock
sensors, map sensors, mass flow sensors, oxygen sensors, parking
sensors, radar guns, speedometers, speed sensors, throttle position
sensors, tire-pressure monitoring sensors, torque sensors,
transmission fluid temperature sensors, turbine speed sensors,
variable reluctance sensors, vehicle speed sensors, water sensors,
and wheel speed sensors.
[0059] Examples of chemical sensors include breathalyzers, carbon
dioxide sensors, carbon monoxide detectors, catalytic bead sensors,
chemical field-effect transistors, chemiresistors, electrochemical
gas sensors, electronic noses, electrolyte-insulator-semiconductor
sensors, fluorescent chloride sensors, holographic sensors,
hydrocarbon dew point analyzers, hydrogen sensors, hydrogen sulfide
sensors, infrared point sensors, ion-selective electrodes,
nondispersive infrared sensors, microwave chemistry sensors,
nitrogen oxide sensors, olfactometers, optodes, oxygen sensors,
ozone monitors, pellistors, pH glass electrodes, potentiometric
sensors, redox electrodes, smoke detectors, and zinc oxide nanorod
sensors.
[0060] Examples of electromagnetic sensors include current sensors,
Daly detectors, electroscopes, electron multipliers, Faraday cups,
galvanometers, Hall effect sensors, Hall probes, magnetic anomaly
detectors, magnetometers, magnetoresistances, mems magnetic field
sensors, metal detectors, planar hall sensors, radio direction
finders, and voltage detectors.
[0061] Examples of environmental sensors include actinometers, air
pollution sensors, bedwetting alarms, ceilometers, dew warnings,
electrochemical gas sensors, fish counters, frequency domain
sensors, gas detectors, hook gauge evaporimeters, humistors,
hygrometers, leaf sensors, lysimeters, pyranometers, pyrgeometers,
psychrometers, rain gauges, rain sensors, seismometers, SNOTEL
sensors, snow gauges, soil moisture sensors, stream gauges, and
tide gauges. Examples of flow and fluid velocity sensors include
air flow meters, anemometers, flow sensors, gas meter, mass flow
sensors, and water meters.
[0062] Examples of radiation and particle sensors include cloud
chambers, Geiger counters, Geiger-Muller tubes, ionisation
chambers, neutron detections, proportional counters, scintillation
counters, semiconductor detectors, and thermoluminescent
dosimeters. Wexamples of navigation instruments include air speed
indicators, altimeters, attitude indicators, depth gauges, fluxgate
compasses, gyroscopes, inertial navigation systems, inertial
reference nits, magnetic compasses, MHD sensors, ring laser
gyroscopes, turn coordinators, tialinx sensors, variometers,
vibrating structure gyroscopes, and yaw rate sensors.
[0063] Examples of position, angle, displacement, distance, speed,
and acceleration sensors include auxanometers, capacitive
displacement sensors, capacitive sensing devices, flex sensors,
free fall sensors, gravimeters, gyroscopic sensors, impact sensors,
inclinometers, integrated circuit piezoelectric sensors, laser
rangefinders, laser surface velocimeters, LIDAR sensors, linear
encoders, linear variable differential transformers (LVDT), liquid
capacitive inclinometers odometers, photoelectric sensors,
piezoelectric accelerometers, position sensors, position sensitive
devices, angular rate sensors, rotary encoders, rotary variable
differential transformers, selsyns, shock detectors, shock data
loggers, tilt sensors, tachometers, ultrasonic thickness gauges,
variable reluctance sensors, and velocity receivers.
[0064] Examples of optical, light, imaging, and photon sensors
include charge-coupled devices, CMOS sensors, colorimeters, contact
image sensors, electro-optical sensors, flame detectors, infra-red
sensors, kinetic inductance detectors, led as light sensors,
light-addressable potentiometric sensors, Nichols radiometers,
fiber optic sensors, optical position sensors, thermopile laser
sensors, photodetectors, photodiodes, photomultiplier tubes,
phototransistors, photoelectric sensors, photoionization detectors,
photomultipliers, photoresistors, photoswitches, phototubes,
scintillometers, Shack-Hartmann sensors, single-photon avalanche
diodes, superconducting nanowire single-photon detectors,
transition edge sensors, visible light photon counters, and
wavefront sensors.
[0065] Examples of pressure sensors include barographs, barometers,
boost gauges, bourdon gauges, hot filament ionization gauges,
ionization gauges, McLeod gauges, oscillating u-tubes, permanent
downhole gauges, piezometers, pirani gauges, pressure sensors,
pressure gauges, tactile sensors, and time pressure gauges.
Examples of force, density, and level sensors include bhangmeters,
hydrometers, force gauge and force sensors, level sensors, load
cells, magnetic level gauges, nuclear density gauges,
piezocapacitive pressure sensors, piezoelectric sensors, strain
gauges, torque sensors, and viscometers.
[0066] Examples of thermal, heat, and temperature sensors include
bolometers, bimetallic strips, calorimeters, exhaust gas
temperature gauges, flame detections, Gardon gauges, Golay cells,
heat flux sensors, infrared thermometers, microbolometers,
microwave radiometers, net radiometers, quartz thermometers,
resistance thermometers, silicon bandgap temperature sensors,
special sensor microwave/imagers, temperature gauges, thermistors,
thermocouples, thermometers, and pyrometers. Examples of proximity
and presence sensors include alarm sensors, Doppler radars, motion
detectors, occupancy sensors, proximity sensors, passive infrared
sensors, reed switches, stud finders, triangulation sensors, touch
switches, and wired gloves.
[0067] In some embodiments, different sensors send measurements or
other data to Cloud IoT platform 104 using a variety of different
communications protocols or data formats. Cloud IoT platform 104
can be configured to ingest sensor data received in any protocol or
data format and translate the inbound sensor data into a common
data format. Cloud IoT platform 104 can create a sensor object
smart entity for each sensor that communicates with Cloud IoT
platform 104. Each sensor object smart entity may include one or
more static attributes that describe the corresponding sensor, one
or more dynamic attributes that indicate the most recent values
collected by the sensor, and/or one or more relational attributes
that relate sensors object smart entities to each other and/or to
other types of smart entities (e.g., space entities, system
entities, data entities, etc.).
[0068] In some embodiments, Cloud IoT platform 104 stores sensor
data using data entities. Each data entity may correspond to a
particular sensor and may include a timeseries of data values
received from the corresponding sensor. In some embodiments, Cloud
IoT platform 104 stores relational objects that define
relationships between sensor object entities and the corresponding
data entity. For example, each relational object may identify a
particular sensor object entity, a particular data entity, and may
define a link between such entities.
[0069] In some embodiments, Cloud IoT platform 104 generates data
internally. For example, Cloud IoT platform 104 may include a web
advertising system, a website traffic monitoring system, a web
sales system, and/or other types of platform services that generate
data. The data generated by Cloud IoT platform 104 can be
collected, stored, and processed along with the data received from
other data sources. Cloud IoT platform 104 can collect data
directly from external systems or devices or via the network 110.
Cloud IoT platform 104 can process and transform collected data to
generate timeseries data and entity data.
[0070] Client device(s) 108 can include one or more human-machine
interfaces or client interfaces (e.g., graphical user interfaces,
reporting interfaces, text-based computer interfaces, client-facing
web services, web servers that provide pages to web clients, and/or
the like) for controlling, viewing, or otherwise interacting with
the IoT environment, IoT devices 102, IoT applications 106, and/or
the Cloud IoT platform 104. Client device(s) 108 can be a computer
workstation, a client terminal, a remote or local interface, or any
other type of user interface device. Client device 108 can be a
stationary terminal or a mobile device. For example, client device
108 can be a desktop computer, a computer server with a user
interface, a laptop computer, a tablet, a smartphone, a PDA, or any
other type of mobile or non-mobile device.
[0071] IoT applications 106 may be applications running on the
client device 108 or any other suitable device that provides an
interface for presenting data from the IoT devices 102 and/or the
Cloud IoT platform 104 to the client device 108. In some
embodiments, the IoT applications 106 may provide an interface for
providing commands or controls from the client device 108 to the
IoT devices 102 and/or the Cloud IoT platform 104.
IoT Management System
[0072] Referring now to FIG. 2, a block diagram of an IoT
management system (IoTMS) 200 is shown, according to some
embodiments. IoTMS 200 can be implemented in an IoT environment to
automatically monitor and control various device functions. IoTMS
200 is shown to include Cloud IoT controller 266 and IoT devices
228. IoT devices 228 are shown to include a plurality of IoT
devices. However, the number of IoT devices is not limited to those
shown in FIG. 2. Each of the IoT devices 228 may include any
suitable device having network connectivity, such as, for example,
a mobile phone, laptop, tablet, smart speaker, vehicle, appliance,
light fixture, thermostat, wearable, medical implant, equipment,
sensor, and/or the like. Further, each of the IoT devices 228 can
include any number of devices, controllers, and connections for
completing its individual functions and control activities. For
example, any of the IoT devices 228 can be a system of devices in
itself including controllers, equipment, sensors, and/or the
like.
[0073] Cloud IoT controller 266 can include one or more computer
systems (e.g., servers, supervisory controllers, subsystem
controllers, etc.) that serve as system level controllers,
application or data servers, head nodes, or master controllers the
IoT devices 228 and/or other controllable systems or devices in an
IoT environment. Cloud IoT controller 266 may communicate with
multiple downstream IoT devices 228 and/or systems via a
communications link (e.g., IoT device interface 209) according to
like or disparate protocols (e.g., HTTP(s), TCP-IP, HTML, SOAP,
REST, LON, BACnet, OPC-UA, ADX, and/or the like).
[0074] In some embodiments, the IoT devices 228 receive information
from Cloud IoT controller 266 (e.g., commands, setpoints, operating
boundaries, etc.) and provides information to Cloud IoT controller
266 (e.g., measurements, valve or actuator positions, operating
statuses, diagnostics, etc.). For example, the IoT devices 228 may
provide Cloud IoT controller 266 with measurements from various
sensors, equipment on/off states, equipment operating capacities,
and/or any other information that can be used by Cloud IoT
controller 266 to monitor or control a variable state or condition
within the IoT environment.
[0075] Still referring to FIG. 2, Cloud IoT controller 266 is shown
to include a communications interface 207 and an IoT device
interface 209. Interface 207 may facilitate communications between
Cloud IoT controller 266 and external applications (e.g.,
monitoring and reporting applications 222, enterprise control
applications 226, remote systems and applications 244, applications
residing on client devices 248, and the like) for allowing user
control, monitoring, and adjustment to Cloud IoT controller 266
and/or IoT devices 228. Interface 207 may also facilitate
communications between Cloud IoT controller 266 and client devices
248. IoT device interface 209 may facilitate communications between
Cloud IoT controller 266 and IoT devices 228.
[0076] Interfaces 207, 209 can be or include wired or wireless
communications interfaces (e.g., jacks, antennas, transmitters,
receivers, transceivers, wire terminals, etc.) for conducting data
communications with IoT devices 228 or other external systems or
devices. In various embodiments, communications via interfaces 207,
209 can be direct (e.g., local wired or wireless communications) or
via a communications network 246 (e.g., a WAN, the Internet, a
cellular network, etc.). For example, interfaces 207, 209 can
include an Ethernet card and port for sending and receiving data
via an Ethernet-based communications link or network. In another
example, interfaces 207, 209 can include a Wi-Fi transceiver for
communicating via a wireless communications network. In another
example, one or both of interfaces 207, 209 can include cellular or
mobile phone communications transceivers. In some embodiments,
communications interface 207 is a power line communications
interface and IoT device interface 209 is an Ethernet interface. In
other embodiments, both communications interface 207 and IoT device
interface 209 are Ethernet interfaces or are the same Ethernet
interface.
[0077] Still referring to FIG. 2, in various embodiments, Cloud IoT
controller 266 is implemented using a distributed or cloud
computing environment with a plurality of processors and memory.
That is, Cloud IoT controller 266 can be distributed across
multiple servers or computers (e.g., that can exist in distributed
locations). For convenience of description, Cloud IoT controller
266 is shown as including at least one processing circuit 204
including a processor 206 and memory 208. Processing circuit 204
can be communicably connected to IoT device interface 209 and/or
communications interface 207 such that processing circuit 204 and
the various components thereof can send and receive data via
interfaces 207, 209. Processor 206 can be implemented as a general
purpose processor, an application specific integrated circuit
(ASIC), one or more field programmable gate arrays (FPGAs), a group
of processing components, or other suitable electronic processing
components.
[0078] Memory 208 (e.g., memory, memory unit, storage device, etc.)
can include one or more devices (e.g., RAM, ROM, Flash memory, hard
disk storage, etc.) for storing data and/or computer code for
completing or facilitating the various processes, layers and
modules described in the present application. Memory 208 can be or
include volatile memory or non-volatile memory. Memory 208 can
include database components, object code components, script
components, or any other type of information structure for
supporting the various activities and information structures
described in the present application. According to some
embodiments, memory 208 is communicably connected to processor 206
via processing circuit 204 and includes computer code for executing
(e.g., by processing circuit 204 and/or processor 206) one or more
processes described herein.
[0079] However, the present disclosure is not limited thereto, and
in some embodiments, Cloud IoT controller 266 can be implemented
within a single computer (e.g., one server, one housing, etc.).
Further, while FIG. 2 shows applications 222 and 226 as existing
outside of Cloud IoT controller 266, in some embodiments,
applications 222 and 226 can be hosted within Cloud IoT controller
266 (e.g., within memory 208).
[0080] Still referring to FIG. 2, memory 208 is shown to include an
enterprise integration layer 210, an automated measurement and
validation (AM&V) layer 212, a fault detection and diagnostics
(FDD) layer 216, an integrated control layer 218, and an IoT device
integration later 220. Layers 210-220 can be configured to receive
inputs from IoT deices 228 and other data sources, determine
optimal control actions for the IoT devices 228 based on the
inputs, generate control signals based on the optimal control
actions, and provide the generated control signals to IoT devices
228.
[0081] Enterprise integration layer 210 can be configured to serve
clients or local applications with information and services to
support a variety of enterprise-level applications. For example,
enterprise control applications 226 can be configured to provide
subsystem-spanning control to a graphical user interface (GUI) or
to any number of enterprise-level business applications (e.g.,
accounting systems, user identification systems, etc.). Enterprise
control applications 226 may also or alternatively be configured to
provide configuration GUIs for configuring Cloud IoT controller
266. In yet other embodiments, enterprise control applications 226
can work with layers 210-220 to optimize the IoT environment based
on inputs received at interface 207 and/or IoT device interface
209.
[0082] IoT device integration layer 220 can be configured to manage
communications between Cloud IoT controller 266 and the IoT devices
228. For example, IoT device integration layer 220 may receive
sensor data and input signals from the IoT devices 228, and provide
output data and control signals to the IoT devices 228. IoT device
integration layer 220 may also be configured to manage
communications between the IoT devices 228. IoT device integration
layer 220 translates communications (e.g., sensor data, input
signals, output signals, etc.) across a plurality of
multi-vendor/multi-protocol systems.
[0083] Integrated control layer 218 can be configured to use the
data input or output of IoT device integration layer 220 to make
control decisions. Due to the IoT device integration provided by
the IoT device integration layer 220, integrated control layer 218
can integrate control activities of the IoT devices 228 such that
the IoT devices 228 behave as a single integrated supersystem. In
some embodiments, integrated control layer 218 includes control
logic that uses inputs and outputs from a plurality of IoT device
subsystems to provide insights that separate IoT device subsystems
could not provide alone. For example, integrated control layer 218
can be configured to use an input from a first IoT device subsystem
to make a control decision for a second IoT device subsystem.
Results of these decisions can be communicated back to IoT device
integration layer 220.
[0084] Automated measurement and validation (AM&V) layer 212
can be configured to verify that control strategies commanded by
integrated control layer 218 are working properly (e.g., using data
aggregated by AM&V layer 212, integrated control layer 218, IoT
device integration layer 220, FDD layer 216, and/or the like). The
calculations made by AM&V layer 212 can be based on IoT device
data models and/or equipment models for individual IoT devices or
subsystems. For example, AM&V layer 212 may compare a
model-predicted output with an actual output from IoT devices 228
to determine an accuracy of the model.
[0085] Fault detection and diagnostics (FDD) layer 216 can be
configured to provide on-going fault detection for the IoT devices
228 and subsystem devices (equipment, sensors, and the like), and
control algorithms used by integrated control layer 218. FDD layer
216 may receive data inputs from integrated control layer 218,
directly from one or more IoT devices or subsystems, or from
another data source. FDD layer 216 may automatically diagnose and
respond to detected faults. The responses to detected or diagnosed
faults can include providing an alert message to a user, a
maintenance scheduling system, or a control algorithm configured to
attempt to repair the fault or to work-around the fault.
[0086] FDD layer 216 can be configured to output a specific
identification of the faulty component or cause of the fault (e.g.,
faulty IoT device or sensor) using detailed subsystem inputs
available at IoT device integration layer 220. In other exemplary
embodiments, FDD layer 216 is configured to provide "fault" events
to integrated control layer 218 which executes control strategies
and policies in response to the received fault events. According to
some embodiments, FDD layer 216 (or a policy executed by an
integrated control engine or business rules engine) may shut-down
IoT systems, devices, and/or or components or direct control
activities around faulty IoT systems, devices, and/or components to
reduce waste, extend IoT device life, or to assure proper control
response.
[0087] FDD layer 216 can be configured to store or access a variety
of different system data stores (or data points for live data). FDD
layer 216 may use some content of the data stores to identify
faults at the IoT device or equipment level and other content to
identify faults at component or subsystem levels. For example, the
IoT devices 228 may generate temporal (i.e., time-series) data
indicating the performance of IoTMS 200 and the various components
thereof. The data generated by the IoT devices 228 can include
measured or calculated values that exhibit statistical
characteristics and provide information about how the corresponding
system or IoT application process is performing in terms of error
from its setpoint. These processes can be examined by FDD layer 216
to expose when the system begins to degrade in performance and
alert a user to repair the fault before it becomes more severe.
IoT Management System with Cloud IoT Platform Services
[0088] Referring now to FIG. 3, a block diagram of another IoT
management system (IoTMS) 300 is shown, according to some
embodiments. IoTMS 300 can be configured to collect data samples
(e.g., raw data) from IoT devices 228 and provide the data samples
to Cloud IoT platform services 320 to generate raw timeseries data,
derived timeseries data, and/or entity data from the data samples.
Cloud IoT platform services 320 can process and transform the raw
timeseries data to generate derived timeseries data. Throughout
this disclosure, the term "derived timeseries data" is used to
describe the result or output of a transformation or other
timeseries processing operation performed by Cloud IoT platform
services 320 (e.g., data aggregation, data cleansing, virtual point
calculation, etc.). The term "entity data" is used to describe the
attributes of various smart entities (e.g., IoT systems, devices,
components, sensors, and the like) and the relationships between
the smart entities. The derived timeseries data can be provided to
various applications 330 of IoTMS 300 and/or stored in storage 314
(e.g., as materialized views of the raw timeseries data). In some
embodiments, Cloud IoT platform services 320 separates data
collection; data storage, retrieval, and analysis; and data
visualization into three different layers. This allows Cloud IoT
platform services 320 to support a variety of applications 330 that
use the derived timeseries data and/or entity data, and allows new
applications 330 to reuse the existing infrastructure provided by
Cloud IoT platform services 320.
[0089] It should be noted that the components of IoTMS 300 and/or
Cloud IoT platform services 320 can be integrated within a single
device (e.g., a supervisory controller, a IoT device controller,
etc.) or distributed across multiple separate systems or devices.
In other embodiments, some or all of the components of IoTMS 300
and or Cloud IoT platform services 320 can be implemented as part
of a cloud-based computing system configured to receive and process
data from one or more IoT systems, devices, and/or components. In
other embodiments, some or all of the components of IoTMS 300
and/or Cloud IoT platform services 320 can be components of a
subsystem level controller, a subplant controller, a device
controller, a field controller, a computer workstation, a client
device, or any other system or device that receives and processes
data from IoT devices.
[0090] IoTMS 300 can include many of the same components as IoTMS
200, as described with reference to FIG. 2. For example, IoTMS 300
is shown to include an IoT device interface 302 and a
communications interface 304. Interfaces 302-304 can include wired
or wireless communications interfaces (e.g., jacks, antennas,
transmitters, receivers, transceivers, wire terminals, etc.) for
conducting data communications with IoT devices 228 or other
external systems or devices. Communications conducted via
interfaces 302-304 can be direct (e.g., local wired or wireless
communications) or via a communications network 246 (e.g., a WAN,
the Internet, a cellular network, etc.).
[0091] Communications interface 304 can facilitate communications
between IoTMS 300 and external applications (e.g., remote systems
and applications 244) for allowing user control, monitoring, and
adjustment to IoTMS 300. Communications interface 304 can also
facilitate communications between IoTMS 300 and client devices 248.
IoT device interface 302 can facilitate communications between
IoTMS 300, Cloud IoT platform services 320, and IoT devices 228.
IoTMS 300 can be configured to communicate with IoT devices 228
and/or Cloud IoT platform services 320 using any suitable protocols
(e.g., HTTP(s), TCP-IP, HTML, SOAP, REST, LON, BACnet, OPC-UA, ADX,
and/or the like). In some embodiments, IoTMS 300 receives data
samples from IoT devices 228 and provides control signals to IoT
devices 228 via IoT device interface 302.
[0092] IoT devices 228 may include any suitable device having
network connectivity, such as, for example, a mobile phone, laptop,
tablet, smart speaker, vehicle, appliance, light fixture,
thermostat, wearable, medical implant, equipment, sensor, and/or
the like. Further, each of the IoT devices 228 can include any
number of devices, controllers, and connections for completing its
individual functions and control activities. For example, any of
the IoT devices 228 can be a system of devices in itself including
controllers, equipment, sensors, and/or the like.
[0093] Still referring to FIG. 3, each of IoTMS 300 and Cloud IoT
platform services 320 includes a processing circuit including a
processor and memory. Each of the processors can be a general
purpose or specific purpose processor, an application specific
integrated circuit (ASIC), one or more field programmable gate
arrays (FPGAs), a group of processing components, or other suitable
processing components. Each of the processors is configured to
execute computer code or instructions stored in memory or received
from other computer readable media (e.g., CDROM, network storage, a
remote server, etc.).
[0094] The memory can include one or more devices (e.g., memory
units, memory devices, storage devices, etc.) for storing data
and/or computer code for completing and/or facilitating the various
processes described in the present disclosure. Memory can include
random access memory (RAM), read-only memory (ROM), hard drive
storage, temporary storage, non-volatile memory, flash memory,
optical memory, or any other suitable memory for storing software
objects and/or computer instructions. Memory can include database
components, object code components, script components, or any other
type of information structure for supporting the various activities
and information structures described in the present disclosure.
Memory can be communicably connected to the processor via the
processing circuit and can include computer code for executing
(e.g., by the processor) one or more processes described
herein.
[0095] Still referring to FIG. 3, Cloud IoT platform services 320
is shown to include a data collector 312. Data collector 312 is
shown receiving data samples from the IoT devices 228 via the IoT
device interface 302. However, the present disclosure is not
limited thereto, and the data collector 312 may receive the data
samples directly from the IoT devices 228 (e.g., via network 246 or
via any suitable method). In some embodiments, the data samples
include data values for various data points. The data values can be
measured or calculated values, depending on the type of data point.
For example, a data point received from a sensor can include a
measured data value indicating a measurement by the sensor. A data
point received from a controller can include a calculated data
value indicating a calculated efficiency of the controller. Data
collector 312 can receive data samples from multiple different
devices (e.g., IoT systems, devices, components, sensors, and the
like) of the IoT devices 228.
[0096] The data samples can include one or more attributes that
describe or characterize the corresponding data points. For
example, the data samples can include a name attribute defining a
point name or ID (e.g., "B1F4R2.T-Z"), a device attribute
indicating a type of device from which the data samples are
received, a unit attribute defining a unit of measure associated
with the data value (e.g., .degree. F., .degree. C., kPA, etc.),
and/or any other attribute that describes the corresponding data
point or provides contextual information regarding the data point.
The types of attributes included in each data point can depend on
the communications protocol used to send the data samples to Cloud
IoT platform services 320. For example, data samples received via
the ADX protocol or BACnet protocol can include a variety of
descriptive attributes along with the data value, whereas data
samples received via the Modbus protocol may include a lesser
number of attributes (e.g., only the data value without any
corresponding attributes).
[0097] In some embodiments, each data sample is received with a
timestamp indicating a time at which the corresponding data value
was measured or calculated. In other embodiments, data collector
312 adds timestamps to the data samples based on the times at which
the data samples are received. Data collector 312 can generate raw
timeseries data for each of the data points for which data samples
are received. Each timeseries can include a series of data values
for the same data point and a timestamp for each of the data
values. For example, a timeseries for a data point provided by a
temperature sensor can include a series of temperature values
measured by the temperature sensor and the corresponding times at
which the temperature values were measured. An example of a
timeseries which can be generated by data collector 312 is as
follows:
[<key, timestamp.sub.1, value.sub.1>, <key,
timestamp.sub.2, value.sub.2>, <key, timestamp.sub.3,
value.sub.3>]
where key is an identifier of the source of the raw data samples
(e.g., timeseries ID, sensor ID, device ID, etc.), timestamp.sub.i
identifies the time at which the ith sample was collected, and
value.sub.i indicates the value of the ith sample.
[0098] Data collector 312 can add timestamps to the data samples or
modify existing timestamps such that each data sample includes a
local timestamp. Each local timestamp indicates the local time at
which the corresponding data sample was measured or collected and
can include an offset relative to universal time. The local
timestamp indicates the local time at the location the data point
was measured at the time of measurement. The offset indicates the
difference between the local time and a universal time (e.g., the
time at the international date line). For example, a data sample
collected in a time zone that is six hours behind universal time
can include a local timestamp (e.g., Timestamp=2016-03-18T14:10:02)
and an offset indicating that the local timestamp is six hours
behind universal time (e.g., Offset=-6:00). The offset can be
adjusted (e.g., +1:00 or -1:00) depending on whether the time zone
is in daylight savings time when the data sample is measured or
collected.
[0099] The combination of the local timestamp and the offset
provides a unique timestamp across daylight saving time boundaries.
This allows an application using the timeseries data to display the
timeseries data in local time without first converting from
universal time. The combination of the local timestamp and the
offset also provides enough information to convert the local
timestamp to universal time without needing to look up a schedule
of when daylight savings time occurs. For example, the offset can
be subtracted from the local timestamp to generate a universal time
value that corresponds to the local timestamp without referencing
an external database and without requiring any other
information.
[0100] In some embodiments, data collector 312 organizes the raw
timeseries data. Data collector 312 can identify a system or device
associated with each of the data points. For example, data
collector 312 can associate a data point with an IoT device,
system, component, sensor, or any other type of system or device.
In some embodiments, a data entity may be created for the data
point, in which case, the data collector 312 (e.g., via entity
service) can associate the data point with the data entity. In
various embodiments, data collector uses the name of the data
point, a range of values of the data point, statistical
characteristics of the data point, or other attributes of the data
point to identify a particular system, device, or data point entity
associated with the data point. Data collector 312 can then
determine how that system or device relates to the other systems or
devices in the IoT environment from entity data. For example, data
collector 312 can determine that the identified system or device is
part of a larger system or serves a particular function within the
larger system from the entity data. In some embodiments, data
collector 312 uses or retrieves an entity graph (e.g., via the
entity service 326) based on the entity data when organizing the
timeseries data.
[0101] Data collector 312 can provide the raw timeseries data to
the other Cloud IoT platform services 320 and/or store the raw
timeseries data in storage 314. Storage 314 may be internal storage
or external storage. For example, storage 314 can be internal
storage with relation to Cloud IoT platform service 320 and/or
IoTMS 300, and/or may include a remote database, cloud-based data
hosting, or other remote data storage. Storage 314 can be
configured to store the raw timeseries data obtained by data
collector 312, the derived timeseries data generated by Cloud IoT
platform services 320, and/or directed acyclic graphs (DAGs) used
by Cloud IoT platform services 320 to process the timeseries
data.
[0102] Still referring to FIG. 3, Cloud IoT platform services 320
can receive the raw timeseries data from data collector 312 and/or
retrieve the raw timeseries data from storage 314. Cloud IoT
platform services 320 can include a variety of services configured
to analyze, process, and transform the raw timeseries data. For
example, Cloud IoT platform services 320 is shown to include a
security service 322, an analytics service 324, an entity service
326, and a timeseries service 328. Security service 322 can assign
security attributes to the raw timeseries data to ensure that the
timeseries data are only accessible to authorized individuals,
systems, or applications. Security service 322 may include a
messaging layer to exchange secure messages with the entity service
326. In some embodiment, security service 322 may provide
permission data to entity service 326 so that entity service 326
can determine the types of entity data that can be accessed by a
particular entity or device. Entity service 324 can assign entity
information (or entity data) to the timeseries data to associate
data points with a particular system, device, or component.
Timeseries service 328 and analytics service 324 can apply various
transformations, operations, or other functions to the raw
timeseries data to generate derived timeseries data.
[0103] In some embodiments, timeseries service 328 aggregates
predefined intervals of the raw timeseries data (e.g.,
quarter-hourly intervals, hourly intervals, daily intervals,
monthly intervals, etc.) to generate new derived timeseries of the
aggregated values. These derived timeseries can be referred to as
"data rollups" since they are condensed versions of the raw
timeseries data. The data rollups generated by timeseries service
328 provide an efficient mechanism for IoT applications 330 to
query the timeseries data. For example, IoT applications 330 can
construct visualizations of the timeseries data (e.g., charts,
graphs, etc.) using the pre-aggregated data rollups instead of the
raw timeseries data. This allows IoT applications 330 to simply
retrieve and present the pre-aggregated data rollups without
requiring IoT applications 330 to perform an aggregation in
response to the query. Since the data rollups are pre-aggregated,
IoT applications 330 can present the data rollups quickly and
efficiently without requiring additional processing at query time
to generate aggregated timeseries values.
[0104] In some embodiments, timeseries service 328 calculates
virtual points based on the raw timeseries data and/or the derived
timeseries data. Virtual points can be calculated by applying any
of a variety of mathematical operations (e.g., addition,
subtraction, multiplication, division, etc.) or functions (e.g.,
average value, maximum value, minimum value, thermodynamic
functions, linear functions, nonlinear functions, etc.) to the
actual data points represented by the timeseries data. For example,
timeseries service 328 can calculate a virtual data point
(pointID.sub.3) by adding two or more actual data points
(pointID.sub.1 and pointID.sub.2) (e.g.,
pointID.sub.3=pointID.sub.1+pointID.sub.2). As another example,
timeseries service 328 can calculate an enthalpy data point
(pointID.sub.4) based on a measured temperature data point
(pointID.sub.5) and a measured pressure data point (pointID.sub.6)
(e.g., pointID.sub.4=enthalpy(pointID.sub.5, pointID.sub.6)). The
virtual data points can be stored as derived timeseries data.
[0105] IoT applications 330 can access and use the virtual data
points in the same manner as the actual data points. IoT
applications 330 may not need to know whether a data point is an
actual data point or a virtual data point since both types of data
points can be stored as derived timeseries data and can be handled
in the same manner by IoT applications 330. In some embodiments,
the derived timeseries are stored with attributes designating each
data point as either a virtual data point or an actual data point.
Such attributes allow IoT applications 330 to identify whether a
given timeseries represents a virtual data point or an actual data
point, even though both types of data points can be handled in the
same manner by IoT applications 330. These and other features of
timeseries service 328 are described in greater detail with
reference to FIG. 6.
[0106] In some embodiments, analytics service 324 analyzes the raw
timeseries data and/or the derived timeseries data with the entity
data to detect faults. Analytics service 324 can apply a set of
fault detection rules based on the entity data to the timeseries
data to determine whether a fault is detected at each interval of
the timeseries. Fault detections can be stored as derived
timeseries data. For example, analytics service 324 can generate a
new fault detection timeseries with data values that indicate
whether a fault was detected at each interval of the timeseries.
The fault detection timeseries can be stored as derived timeseries
data along with the raw timeseries data in storage 314.
[0107] Still referring to FIG. 3, IoTMS 300 is shown to include
several IoT applications 330 including a resource management
application 332, monitoring and reporting applications 334, and
enterprise control applications 336. Although only a few IoT
applications 330 are shown, it is contemplated that IoT
applications 330 can include any of a variety of applications
configured to use the raw or derived timeseries generated by Cloud
IoT platform services 320. In some embodiments, IoT applications
330 exist as a separate layer of IoTMS 300 (e.g., a part of Cloud
IoT platform services 320 and/or data collector 312). In other
embodiments, IoT applications 330 can exist as remote applications
that run on remote systems or devices (e.g., remote systems and
applications 244, client devices 248, and/or the like).
[0108] IoT applications 330 can use the derived timeseries data and
entity data to perform a variety data visualization, monitoring,
and/or control activities. For example, resource management
application 332 and monitoring and reporting application 334 can
use the derived timeseries data and entity data to generate user
interfaces (e.g., charts, graphs, etc.) that present the derived
timeseries data and/or entity data to a user. In some embodiments,
the user interfaces present the raw timeseries data and the derived
data rollups in a single chart or graph. For example, a dropdown
selector can be provided to allow a user to select the raw
timeseries data or any of the data rollups for a given data
point.
[0109] Enterprise control application 336 can use the derived
timeseries data and/or entity data to perform various control
activities. For example, enterprise control application 336 can use
the derived timeseries data and/or entity data as input to a
control algorithm (e.g., a state-based algorithm, an extremum
seeking control (ESC) algorithm, a proportional-integral (PI)
control algorithm, a proportional-integral-derivative (PID) control
algorithm, a model predictive control (MPC) algorithm, a feedback
control algorithm, etc.) to generate control signals for IoT
devices 228. In some embodiments, IoT devices 228 use the control
signals to operate other systems, devices, components, and/or
sensors, which can affect the measured or calculated values of the
data samples provided to IoTMS 300 and/or Cloud IoT platform
services 320. Accordingly, enterprise control application 336 can
use the derived timeseries data and/or entity data as feedback to
control the systems and devices of the IoT devices 228.
Cloud Entity IoT Platform Service
[0110] Referring now to FIG. 4, a block diagram illustrating entity
service 326 in greater detail is shown, according to some
embodiments. Entity service 326 registers and manages various
devices and entities in the Cloud IoT platform services 320.
According to various embodiments, an entity may be any person,
place, or physical object, hereafter referred to as an object
entity. Further, an entity may be any event, data point, or record
structure, hereinafter referred to as data entity. In addition,
relationships between entities may be defined by relational
objects.
[0111] In some embodiments, an object entity may be defined as
having at least three types of attributes. For example, an object
entity may have a static attribute, a dynamic attribute, and a
behavioral attribute. The static attribute may include any unique
identifier of the object entity or characteristic of the object
entity that either does not change over time or changes
infrequently (e.g., a device ID, a person's name or social security
number, a place's address or room number, and the like). The
dynamic attribute may include a property of the object entity that
changes over time (e.g., location, age, measurement, data point,
and the like). In some embodiments, the dynamic attribute of an
object entity may be linked to a data entity. In this case, the
dynamic attribute of the object entity may simply refer to a
location (e.g., data/network address) or static attribute (e.g.,
identifier) of the linked data entity, which may store the data
(e.g., the value or information) of the dynamic attribute.
Accordingly, in some such embodiments, when a new data point (e.g.,
timeseries data) is received for the object entity, only the linked
data entity may be updated, while the object entity remains
unchanged. Therefore, resources that would have been expended to
update the object entity may be reduced.
[0112] However, the present disclosure is not limited thereto. For
example, in some embodiments, there may also be some data that is
updated (e.g., during predetermined intervals) in the dynamic
attribute of the object entity itself. For example, the linked data
entity may be configured to be updated each time a new data point
is received, whereas the corresponding dynamic attribute of the
object entity may be configured to be updated less often (e.g., at
predetermined intervals less than the intervals during which the
new data points are received). In some implementations, the dynamic
attribute of the object entity may include both a link to the data
entity and either a portion of the data from the data entity or
data derived from the data of the data entity. For example, in an
embodiment in which periodic odometer readings are received from a
connected car, an object entity corresponding to the car could
include the last odometer reading and a link to a data entity that
stores a series of the last ten odometer readings received from the
car.
[0113] The behavioral attribute may define a function of the object
entity, for example, based on inputs, capabilities, and/or
permissions. For example, behavioral attributes may define the
types of inputs that the object entity is configured to accept, how
the object entity is expected to respond under certain conditions,
the types of functions that the object entity is capable of
performing, and the like. As a non-limiting example, if the object
entity represents a person, the behavioral attribute of the person
may be his/her job title or job duties, user permissions to access
certain systems, expected location or behavior given a time of day,
tendencies or preferences based on connected activity data received
by entity service 326 (e.g., social media activity), and the like.
As another non-limiting example, if the object entity represents a
device, the behavioral attributes may include the types of inputs
that the device can receive, the types of outputs that the device
can generate, the types of controls that the device is capable of,
the types of software or versions that the device currently has,
known responses of the device to certain types of input (e.g.,
behavior of the device defined by its programming), and the
like.
[0114] In some embodiments, the data entity may be defined as
having at least a static attribute and a dynamic attribute. The
static attribute of the data entity may include a unique identifier
or description of the data entity. For example, if the data entity
is linked to a dynamic attribute of an object entity, the static
attribute of the data entity may include an identifier that is used
to link to the dynamic attribute of the object entity. In some
embodiments, the dynamic attribute of the data entity represents
the data for the dynamic attribute of the linked object entity. In
some embodiments, the dynamic attribute of the data entity may
represent some other data that is derived, analyzed, inferred,
calculated, or determined based on data from a plurality of data
sources.
[0115] In some embodiments, the relational object may be defined as
having at least a static attribute. The static attribute of the
relational object may semantically define the type of relationship
between two or more entities. For example, in a non-limiting
embodiment, a relational object for a relationship that
semantically defines that Entity A has a part of Entity B, or that
Entity B is a part of Entity A may include:
hasPart{Entity A, Entity B}
where the static attribute hasPart defines what the relationship is
of the listed entities, and the order of the listed entities or
data field of the relational object specifies which entity is the
part of the other (e.g., Entity A.fwdarw.hasPart.fwdarw.Entity
B).
[0116] In various embodiments, the relational object is an
object-oriented construct with predefined fields that define the
relationship between two or more entities, regardless of the type
of entities. For example, Cloud IoT platform service 320 can
provide a rich set of pre-built entity models with standardized
relational objects that can be used to describe how any two or more
entities are semantically related, as well as how data is exchanged
and/or processed between the entities. Accordingly, a global change
to a definition or relationship of a relational object at the
system level can be effected at the object level, without having to
manually change the entity relationships for each object or entity
individually. Further, in some embodiments, a global change at the
system level can be propagated through to third-party applications
integrated with Cloud IoT platform services 320 such that the
global change can be implemented across all of the third-party
applications without requiring manual implementation of the change
in each disparate application.
[0117] For example, referring to FIG. 5, an example entity graph of
entity data is shown, according to some embodiments. The term
"entity data" is used to describe the attributes of various
entities and the relationships between the entities. For example,
entity data may be represented in the form of an entity graph. In
some embodiments, entity data includes any suitable predefined data
models (e.g., as a table, JSON data, and/or the like), such as
entity type or object, and further includes one or more relational
objects that semantically define the relationships between the
entities. The relational objects may help to semantically define,
for example, hierarchical or directed relationships between the
entities (e.g., entity X controls entity Y, entity A feeds entity
B, entity 1 is located in entity 2, and the like). For example, an
object entity (e.g., IoT device) may be represented by entity type
or object, which generally describes how data corresponding to the
entity will be structured and stored.
[0118] For example, an entity type (or object) "Activity Tracker"
may be represented via the below schema:
TABLE-US-00001 Activity Tracker { Type, Model No, Device Name,
Manufactured date, Serial number, MAC address, Location, Current
Time, Current Date, Current Heart Rate, Daily Number of Steps,
Target Daily Number of Steps, Point schedule }
where various attributes are static attributes (e.g., "Type,"
"Model Number," "Device Name," etc.,), dynamic attributes (e.g.,
"Location," "Current Time," etc.), or behavioral attributes (e.g.,
"Current Heart Rate," "Daily Number of Steps," etc.) for the object
entity "Activity Tracker." In a relational database, the object
"Activity Tracker" is a table name, and the attributes represents
column names.
[0119] An example of an object entity data model for a person named
John Smith in a relational database may be represented by the below
table:
TABLE-US-00002 First Last Job Name Name Tel. No. Age Location Title
John Smith (213)220-XXXX 36 Home Engineer
where various attributes are static attributes (e.g., "First Name,"
"Last Name," etc.,), dynamic attributes (e.g., "Age," "Location,"
etc.), or behavioral attributes (e.g., "Engineer") for the object
entity "John Smith."
[0120] An example data entity for the data point "Daily Number of
Steps" for the "Activity Tracker" owned by John Smith in a
relational database may be represented by the below table:
TABLE-US-00003 Unit of Present-Value Description Device_Type
measure 2365 "John's current daily Activity Tracker 2 feet/step
number of steps"
where various attributes are static attributes (e.g., "Description"
and "Device_Type") and dynamic attributes (e.g.,
"Present-Value").
[0121] While structuring the entities via entity type or object may
help to define the data representation of the entities, these data
models do not provide information on how the entities relate to
each other. For example, an IoT application, controller, or
platform may need data from a plurality of sources as well as
information on how the sources relate to each other in order to
provide a proper decision, action, or recommendation. Accordingly,
in various embodiments, the entity data further includes the
relational objects to semantically define the relationships between
the entities, which may help to increase speeds in analyzing data,
as well as provide ease of navigation and browsing.
[0122] For example, still referring to FIG. 5, an entity graph 500
for the Activity Tracker object entity 502 includes various class
entities (e.g., User, Address, SetPoint Command, and Activity
Object), object entities (e.g., John and Activity Tracker),
relational objects (e.g., isAKindOf, Owns, isLinked, hasStorage,
and hasOperation), and data entities (AI 201-01, TS ID 1, Daily
Average 1, AO 101-1, and Geo 301-01). The relational objects
describe the relationships between the various class, object, and
data entities in a semantic and syntactic manner, so that an
application or user viewing the entity graph 500 can quickly
determine the relationships and data process flow of the Activity
Tracker object entity 502, without having to resort to a data base
analyst or engineer to create, index, and/or manage the entities
(e.g., using SQL or NoSQL). In some embodiments, each of the
entities (e.g., class entity, object entity, and data entity)
represents a node on the entity graph 500, and the relational
objects define the relationships or connections between the
entities (or nodes).
[0123] For example, the entity graph 500 shows that a person named
John (object entity) 504 isAKindOf (relational object) 506 User
(class entity) 508. John 504 Owns (relational object) 510 the
Activity Tracker (object entity) 502. The Activity Tracker 502 has
a location attribute (dynamic attribute) 512 that isLinked
(relational object) 514 to Geo 301-01 (data entity) 316, which
isAKindOf (relational object) 518 an Address (class entity) 520.
Accordingly, Geo 301-01 316 should have a data point corresponding
to an address.
[0124] The Activity Tracker 502 further includes a "Daily Number of
Steps" attribute (dynamic attribute) 522 that isLinked (relational
object) 524 to AI 201-01 (data entity) 526. AI 201-01 526 isAKindOf
(relational object) 528 Activity Object (class entity) 530. Thus,
AI 201-01 526 should contain some sort of activity related data. AI
201-01 526 hasStorage (relational object) 532 at TS ID 1 (data
entity) 534. AI 201-01 526 hasOperation (relational object) 536 of
Daily Average 1 (data entity) 538, which isAKindOf (relational
object) 540 Analytic Operator (class entity) 542. Accordingly,
Daily Average 1 should hold some data that is the result of an
analytic operation.
[0125] In this example, the data entity AI 201-01 526 may be
represented by the following data model:
TABLE-US-00004 point { name: "AI 201-01"; type: "analog input";
value: 2365; unit: "2 feet/step"; source: "Pedometer Sensor 1"
}
where "point" is an example of a data entity that may be created by
Cloud IoT platform Services 320 to hold the value for the linked
"Daily Number of Steps" 522 dynamic attribute of the Activity
Tracker entity 502, and source is the sensor or device in the
Activity Tracker device 502 that provides the data to the linked
"Daily Number of Steps" 522 dynamic attribute.
[0126] The data entity TS Id 1 534 may be represented, for example,
by the following data model:
TABLE-US-00005 timeseries { name: "TS Id 1"; type: "Daily Average";
values: "[2365, 10683, 9166, 8254, 12982]; unit: "2 feet/step";
point: "AI 201-01"; source: "Daily Average 1" }
where the data entity Daily Average 1 538 represents a specific
analytic operator used to create the data entity for the average
daily timeseries TS Id 1 534 based on the values of the
corresponding data entity for point AI 201-01 526. The relational
object hasOperation shows that the AI 201-01 data entity 526 is
used as an input to the specific logic/math operation represented
by Daily Average 1 538. TS Id 1 534 might also include an attribute
that identifies the analytic operator Daily Average 1 538 as the
source of the data samples in the timeseries.
[0127] Still referring to FIG. 5, the entity graph 500 for Activity
Tracker 502 shows that the "Target Daily Number of Steps" attribute
(dynamic attribute) 544 isLinked (relational attribute) 546 to the
data entity AO 101-01 (data entity) 548. AO 101-01 data entity
isAKindOf (relational attribute) 550 a SetPoint Command (class
entity) 552. Thus, the data in data entity AO 101-01 548 may be set
via a command by the user or other entity. Accordingly, in various
embodiments, entity graph 500 provides a user friendly view of the
various relationships between the entities (or nodes) and data
processing flow, which provides for ease of navigation, browsing,
and analysis of data.
[0128] In some embodiments, any two entities (or nodes) can be
connected to each other via one or more relational objects that
define different relationships between the two entities (or nodes).
For example, still referring to FIG. 5, the object entity John 504
is shown to be connected to the object entity Activity Tracker 502
via one relational object Owns 510. However, in another embodiment,
the object entity John 504 can be connected to the object entity
Activity Tracker 502 via more than one relational object, such
that, in addition to the relational object Owns 510, another
relational object can define another relationship between the
object entity John 504 and the object entity Activity Tracker 502.
For example, another relational object such as isWearing or
isNotWearing can define whether or not John (or the entity object
for John 504) is currently wearing (e.g., via the relational object
isWearing) or currently not wearing (e.g., via the relational
object isNotWearing) the activity tracker (or the entity object for
the activity tracker 502).
[0129] In this case, when the data entities associated with the
activity tracker object entity 502 indicates that John is wearing
the activity tracker (e.g., which may be determined from the daily
number of steps attribute 522 or the location attribute 512), the
relational object isWearing may be created between the object
entity for John 510 and the object entity for activity tracker 502.
On the other hand, when the data entities associated with the
activity tracker object entity 502 indicates that John is not
wearing the activity tracker (e.g., which may be determined when
the daily number of steps attribute 522 for a current day is zero
or the location attribute 512 shows a different location from a
known location of John), the relational object isNotWearing can be
created between the object entity for John 510 and the object
entity for activity tracker 502. For example, the relational object
isNotWearing can be created by modifying the relational object
isWearing or deleting the relational object isWearing and creating
the relational object isNotWearing. Thus, in some embodiments, the
relational objects can be dynamically created, modified, or deleted
as needed or desired.
[0130] Referring again to FIG. 4, entity service 326 may transforms
raw data samples and/or raw timeseries data into data corresponding
to entity data. For example, as discussed above with reference to
FIG. 5, entity service 326 can create data entities that use and/or
represent data points in the timeseries data. Entity service 326
includes a web service 402, a registration service 404, a
management service 406, a transformation service 408, a search
service 410, and storage 412. In some embodiments, storage 412 may
be internal storage or external storage. For example, storage 412
may be storage 314 (see FIG. 3), internal storage with relation to
entity service 326, and/or may include a remote database,
cloud-based data hosting, or other remote data storage.
[0131] Web service 402 can be configured to interact with web-based
applications to send entity data and/or receive raw data (e.g.,
data samples, timeseries data, and the like). For example, web
service 402 can provide an interface (e.g., API, UI/UX, and the
like) to manage (e.g., register, create, edit, delete, and/or
update) an entity (e.g., class entity, object entity, data entity,
and/or the like) and the relational objects that define the
relationships between the entities. In some embodiments, web
service 402 provides entity data to web-based applications. For
example, if one or more of applications 330 are web-based
applications, web service 402 can provide entity data to the
web-based applications. In some embodiments, web service 402
receives raw data samples and/or raw timeseries data including
device information from a web-based data collector, or a web-based
security service to identify authorized entities and to exchange
secured messages. For example, if data collector 312 is a web-based
application, web service 402 can receive the raw data samples
and/or timeseries data including a device attribute indicating a
type of device (e.g., IoT device) from which the data samples
and/or timeseries data are received from data collector 312. In
some embodiments, web service 402 may message security service 322
to request authorization information and/or permission information
of a particular entity or device. In some embodiments, web service
402 receives derived timeseries data from timeseries service 328,
and/or may provide entity data to timeseries service 328. In some
embodiments, the entity service 326 processes and transforms the
collected data to generate the entity data.
[0132] The registration service 404 can perform registration of
devices and entities. For example, registration service 404 can
communicate with IoT devices 228 and client devices 248 (e.g., via
web service 402) to register each IoT device with Cloud IoT
platform services 320. In some embodiments, registration service
404 registers a particular IoT device 228 with a specific user
and/or a specific set of permissions and/or entitlements. For
example, a user may register a device key and/or a device ID
associated with the IoT device 228 via a web portal (e.g., web
service 402). In some embodiments, the device ID and the device key
may be unique to the IoT device 228. The device ID may be a unique
number associated with the device such as a unique alphanumeric
string, a serial number of IoT device 228, and/or any other static
identifier. In various embodiments, IoT device 228 is provisioned
by a manufacturer and/or any other entity. In various embodiments,
the device key and/or device ID are saved to IoT device 228 based
on whether IoT device 228 includes a trusted platform module (TPM).
If the IoT device 228 includes a TPM, the IoT device 228 may store
the device key and/or device ID according to the protocols of the
TPM. If the IoT device 228 does not include a TPM, the IoT device
228 may store the device key and/or device ID in a file and/or file
field which may be stored in a secure storage location. Further, in
some embodiments, the device ID may be stored with BIOS software of
the IoT device 228. For example, a serial number of BIOS software
may become and/or may be updated with the device ID.
[0133] In various embodiments, the device key and/or the device ID
are uploaded to registration service 404 (e.g., an IoT hub such as
AZURE.RTM. IoT Hub). In some embodiments, registration service 404
is configured to store the device key and the device ID in secure
permanent storage and/or may be stored by security service 322
(e.g., by a security API). In some embodiments, a manufacturer
and/or any other individual may register the device key and the
device ID with registration service 404 (e.g., via web service
402). In various embodiments, the device key and the device ID are
linked to a particular profile associated with the IoT device 228
and/or a particular user profile (e.g., a particular user). In this
regard, a device (e.g., IoT device 228) can be associated with a
particular user. In various embodiments, the device key and the
device ID make up the profile for IoT device 228. The profile may
be registered as a device that has been manufactured and/or
provisioned but has not yet been purchased by an end user.
[0134] In various embodiments, registration service 404 adds and/or
updates a device in an IoT hub device registry. In various
embodiments, registration service 404 may determine if the device
is already registered, can set various authentication values (e.g.,
device ID, device key), and can update the IoT hub device registry.
In a similar manner, registration service 404 can update a document
database with the various device registration information.
[0135] In some embodiments, registration service 404 can be
configured to create a virtual representation (e.g., "digital
twins" or "shadow records") of each IoT device in an IoT
environment within Cloud IoT platform services 320. In some
embodiments, the virtual device representations are smart entities
that include attributes defining or characterizing the
corresponding physical IoT devices and are associated to the
corresponding physical IoT devices via relational objects defining
the relationship of the IoT device and the smart entity
representation thereof. In some embodiments, the virtual device
representations maintain shadow copies of the IoT devices with
versioning information so that Cloud entity service 326 can store
not only the most recent update of an attribute (e.g., a dynamic
attribute) associated with the IoT device, but records of previous
states of the attributes (e.g., dynamic attributes) and/or
entities. For example, the shadow record may be created as a type
of data entity that is related to a linked data entity
corresponding to the dynamic attribute of the object entity (e.g.,
IoT device). For example, the shadow entity may be associated with
the linked data entity via a relational object (e.g., isLinked,
hasStorage, hasOperation, and the like). In this case, the shadow
entity may be used to determine additional analytics for the data
point of the dynamic attribute. For example, the shadow entity may
be used to determine an average value, an expected value, or an
abnormal value of the data point from the dynamic attribute.
[0136] Management service 406 may create, modify, or update various
attributes, data entities, and/or relational objects of the devices
managed by Cloud IoT platform services 326 for each entity rather
than per class or type of entity. This allows for separate
processing/analytics for each individual entity rather than only to
a class or type of entity. Some attributes (or data entities) may
correspond to, for example, the most recent value of a data point
provided to Cloud IoT platform services 326 via the raw data
samples and/or timeseries data. For example, the "Daily Number of
Steps" dynamic attribute of the "Activity Tracker" object entity
502 in the example discussed above may be the most recent value of
a number of steps data point provided by the Activity Tracker
device. Management service 406 can use the relational objects of
the entity data for Activity Tracker to determine where to update
the data of the attribute.
[0137] For example, Management service 406 may determine that a
data entity (e.g., AI 201-01) is linked to the "Daily Number of
Steps" dynamic attribute of Activity Tracker via an isLinked
relational object. In this case, Management service 406 may
automatically update the attribute data in the linked data entity.
Further, if a linked data entity does not exist, Management service
406 can create a data entity (e.g., AI 201-01) and an instance of
the isLinked relational object 524 to store and link the "Daily
Number of Steps" dynamic attribute of Activity Tracker therein.
Accordingly, processing/analytics for activity tracker 502 may be
automated. As another example, a "most recent view" attribute (or
linked data entity) of a webpage object entity may indicate the
most recent time at which the webpage was viewed. Management
service 406 can use the entity data from a related click tracking
system object entity or web server object entity to determine when
the most recent view occurred and can automatically update the
"most recent view" attribute (or linked data entity) of the webpage
entity accordingly.
[0138] Other data entities and/or attributes may be created and/or
updated as a result of an analytic, transformation, calculation, or
other processing operation based on the raw data and/or entity
data. For example, Management service 406 can use the relational
objects in entity data to identify a related access control device
(e.g., a card reader, a keypad, etc.) at the entrance/exit of a
building object entity. Management service 406 can use raw data
received from the identified access control device to track the
number of occupants entering and exiting the building object entity
(e.g., via related card entities used by the occupants to enter and
exit the building). Management service 406 can update a "number of
occupants" attribute (or corresponding data entity) of the building
object entity each time a person enters or exits the building using
a related card object entity, such that the "number of occupants"
attribute (or data entity) reflects the current number of occupants
within the building (or related building object entity). As another
example, a "total revenue" attribute associated with a product line
object entity may be the summation of all the revenue generated
from related point of sales entities. Management service 406 can
use the raw data received from the related point of sales entities
to determine when a sale of the product occurs, and can identify
the amount of revenue generated by the sales. Management service
406 can then update the "total revenue" attribute (or related data
entity) of the product line object entity by adding the most recent
sales revenue from each of the related point of sales entities to
the previous value of the attribute.
[0139] In some embodiments, management service 406 may use derived
timeseries data generated from timeseries service 328 to update or
create a data entity (e.g., Daily Average 1) that uses or stores
the data points in the derived timeseries data. For example, the
derived timeseries data may include a virtual data point
corresponding to the daily average steps calculated by timeseries
service 328, and management service 406 may update the data entity
or entities that store or use the data corresponding to the virtual
data point as determined via the relational objects. In some
embodiments, if a data entity corresponding to the virtual data
point does not exist, management service 406 may automatically
create a corresponding data entity and one or more relational
objects that describe the relationship between the corresponding
data entity and other entities.
[0140] In some embodiments, management service 406 uses entity data
and/or data from multiple different data sources to update the
attributes (or corresponding data entities) of various object
entities. For example, an object entity representing a person
(e.g., a person's cellular device or other related object entity)
may include a "risk" attribute that quantifies the person's level
of risk attributable to various physical, environmental, or other
conditions. Management service 406 can use relational objects of
the person object entity to identify a related card device and/or a
related card reader from a related building object entity (e.g.,
the building in which the person works) to determine the physical
location of the person at any given time. Management service 406
can determine from raw data (e.g., time that the card device was
scanned by the card reader) or derived timeseries data (e.g.,
average time of arrival) whether the person object is located in
the building or may be in transit to the building. Management
service 406 can use weather data from a weather service in the
region in which the building object entity is located to determine
whether any severe weather is approaching the person's location.
Similarly, management service 406 can use building data from
related building entities of the building object entity to
determine whether the building in which the person is located is
experiencing any emergency conditions (e.g., fire, building
lockdown, etc.) or environmental hazards (e.g., detected air
contaminants, pollutants, extreme temperatures, etc.) that could
increase the person's level of risk. Management service 406 can use
these and other types of data as inputs to a risk function that
calculates the value of the person object entity's "risk" attribute
and can update the person object entity (or related device entity
of the person) accordingly.
[0141] In some embodiments, management service 406 can be
configured to synchronize configuration settings, parameters, and
other device-specific information between the entities and Cloud
IoT platform services 320. In some embodiments, the synchronization
occurs asynchronously. Management service 406 can be configured to
manage device properties dynamically. The device properties,
configuration settings, parameters, and other device-specific
information can be synchronized between the smart entities created
by and stored within Cloud IoT platform services 320.
[0142] In some embodiments, management service 406 is configured to
manage a manifest for each of the IoT devices. The manifest may
include a set of relationships between the IoT devices and various
entities. Further, the manifest may indicate a set of entitlements
for the IoT devices and/or entitlements of the various entities
and/or other entities. The set of entitlements may allow an IoT
device and/or a user of the device to perform certain actions
within the IoT environment (e.g., control, configure, monitor,
and/or the like).
[0143] Still referring to FIG. 4, transformation service 408 can
provide data virtualization, and can transform various predefined
standard data models for entities in a same class or type to have
the same entity data structure, regardless of the device or Thing
that the entity represents. For example, each device entity under a
device class may include a location attribute, regardless of
whether or not the location attribute is used or even generated.
Thus, if an application is later developed requiring that each
device entity includes a location attribute, manual mapping of
heterogenous data of different entities in the same class may be
avoided. Accordingly, interoperability between IoT devices and
scalability of IoT applications may be improved.
[0144] In some embodiments, transformation service 408 can provide
entity matching, cleansing, and correlation so that a unified
cleansed view of the entity data including the entity related
information (e.g., relational objects) can be provided.
Transformation service 408 can support semantic and syntactic
relationship description in the form of standardized relational
objects between the various entities. This may simplify machine
learning because the relational objects themselves provide all the
relationship description between the other entities. Accordingly,
the rich set of pre-built entity models and standardized relational
objects may provide for rapid application development and data
analytics.
[0145] Still referring to FIG. 4, the search service 410 provides a
unified view of product related information in the form of the
entity graph, which correlates entity relationships (via relational
objects) among multiple data sources (e.g., CRM, ERP, MRP and the
like). In some embodiments, the search service 410 is based on a
schema-less and graph based indexing architecture. For example, in
some embodiments, the search service 410 provides the entity graph
in which the entities are represented as nodes with relational
objects defining the relationship between the entities (or nodes).
The search service 410 facilitates simple queries without having to
search multiple levels of the hierarchical tree of the entity
graph. For example, search service 410 can return results based on
searching of entity type, individual entities, attributes, or even
relational objects without requiring other levels or entities of
the hierarchy to be searched.
Timeseries Data Platform Service
[0146] Referring now to FIG. 6, a block diagram illustrating
timeseries service 328 in greater detail is shown, according to
some embodiments. Timeseries service 328 is shown to include a
timeseries web service 602, an events service 603, a timeseries
processing engine 604, and a timeseries storage interface 616.
Timeseries web service 602 can be configured to interact with
web-based applications to send and/or receive timeseries data. In
some embodiments, timeseries web service 602 provides timeseries
data to web-based applications. For example, if one or more of IoT
applications 330 are web-based applications, timeseries web service
602 can provide derived timeseries data and/or raw timeseries data
to the web-based applications. In some embodiments, timeseries web
service 602 receives raw timeseries data from a web-based data
collector. For example, if data collector 312 is a web-based
application, timeseries web service 602 can receive raw data
samples or raw timeseries data from data collector 312. In some
embodiments, timeseries web service 602 and entity service web
service 402 may be integrated as parts of the same web service.
[0147] Timeseries storage interface 616 can be configured to store
and read samples of various timeseries (e.g., raw timeseries data
and derived timeseries data) and eventseries (described in greater
detail below). Timeseries storage interface 616 can interact with
storage 314. For example, timeseries storage interface 616 can
retrieve timeseries data from a timeseries database 628 within
storage 314. In some embodiments, timeseries storage interface 616
reads samples from a specified start time or start position in the
timeseries to a specified stop time or a stop position in the
timeseries. Similarly, timeseries storage interface 616 can
retrieve eventseries data from an eventseries database 629 within
storage 314. Timeseries storage interface 616 can also store
timeseries data in timeseries database 628 and can store
eventseries data in eventseries database 629. Advantageously,
timeseries storage interface 616 provides a consistent interface
which enables logical data independence.
[0148] In some embodiments, timeseries storage interface 616 stores
timeseries as lists of data samples, organized by time. For
example, timeseries storage interface 616 can store timeseries in
the following format: [0149] [<key,
timestamp.sub.1,value.sub.1>, <key, timestamp.sub.2,
value.sub.2>, <key, timestamp.sub.3, value.sub.3>] where
key is an identifier of the source of the data samples (e.g.,
timeseries ID, sensor ID, device ID, etc.), timestamp.sub.i
identifies a time associated with the ith sample, and value.sub.r
indicates the value of the ith sample.
[0150] In some embodiments, timeseries storage interface 616 stores
eventseries as lists of events having a start time, an end time,
and a state. For example, timeseries storage interface 616 can
store eventseries in the following format: [0151]
[<eventID.sub.1, start_timestamp.sub.1, end_timestamp.sub.1,
state.sub.1>, . . . , <eventID.sub.N, start_timestamp.sub.N,
end_timestamp.sub.N, state.sub.N>] where eventID.sub.i is an
identifier of the ith event, start_timestamp.sub.i is the time at
which the ith event started, end_timestamp.sub.i is the time at
which the ith event ended, state describes a state or condition
associated with the ith event (e.g., cold, hot, warm, etc.), and N
is the total number of events in the eventseries.
[0152] In some embodiments, timeseries storage interface 616 stores
timeseries and eventseries in a tabular format. Timeseries storage
interface 616 can store timeseries and eventseries in various
tables having a column for each attribute of the
timeseries/eventseries samples (e.g., key, timestamp, value). The
timeseries tables can be stored in timeseries database 628, whereas
the eventseries tables can be stored in eventseries database 629.
In some embodiments, timeseries storage interface 616 caches older
data to storage 314 but stores newer data in RAM. This may improve
read performance when the newer data are requested for
processing.
[0153] In some embodiments, timeseries storage interface 616 omits
one or more of the attributes when storing the timeseries samples.
For example, timeseries storage interface 616 may not need to
repeatedly store the key or timeseries ID for each sample in the
timeseries. In some embodiments, timeseries storage interface 616
omits timestamps from one or more of the samples. If samples of a
particular timeseries have timestamps at regular intervals (e.g.,
one sample each minute), timeseries storage interface 616 can
organize the samples by timestamps and store the values of the
samples in a row. The timestamp of the first sample can be stored
along with the interval between the timestamps. Timeseries storage
interface 616 can determine the timestamp of any sample in the row
based on the timestamp of the first sample and the position of the
sample in the row.
[0154] In some embodiments, timeseries storage interface 616 stores
one or more samples with an attribute indicating a change in value
relative to the previous sample value. The change in value can
replace the actual value of the sample when the sample is stored in
timeseries database 628. This allows timeseries storage interface
616 to use fewer bits when storing samples and their corresponding
values. Timeseries storage interface 616 can determine the value of
any sample based on the value of the first sample and the change in
value of each successive sample.
[0155] In some embodiments, timeseries storage interface 616
invokes entity service 326 to create data entities in which samples
of timeseries data and/or eventseries data can be stored. The data
entities can include JSON objects or other types of data objects to
store one or more timeseries samples and/or eventseries samples.
Timeseries storage interface 616 can be configured to add samples
to the data entities and read samples from the data entities. For
example, timeseries storage interface 616 can receive a set of
samples from data collector 312, entity service 326, timeseries web
service 602, events service 603, and/or timeseries processing
engine 604. Timeseries storage interface 616 can add the set of
samples to a data entity by sending the samples to entity service
326 to be stored in the data entity, for example, or may directly
interface with the data entity to add/modify the sample to the data
entity.
[0156] Timeseries storage interface 616 can use data entities when
reading samples from storage 314. For example, timeseries storage
interface 616 can retrieve a set of samples from storage 314 or
from entity service 326, and add the samples to a data entity
(e.g., directly or via entity service 326). In some embodiments,
the set of samples include all samples within a specified time
period (e.g., samples with timestamps in the specified time period)
or eventseries samples having a specified state. Timeseries storage
interface 616 can provide the samples in the data entity to
timeseries web service 602, events service 603, timeseries
processing engine 604, applications 330, and/or other components
configured to use the timeseries/eventseries samples.
[0157] Still referring to FIG. 6, timeseries processing engine 604
is shown to include several timeseries operators 606. Timeseries
operators 606 can be configured to apply various operations,
transformations, or functions to one or more input timeseries to
generate output timeseries and/or eventseries. The input timeseries
can include raw timeseries data and/or derived timeseries data.
Timeseries operators 606 can be configured to calculate aggregate
values, averages, or apply other mathematical operations to the
input timeseries. In some embodiments, timeseries operators 606
generate virtual point timeseries by combining two or more input
timeseries (e.g., adding the timeseries together), creating
multiple output timeseries from a single input timeseries, or
applying mathematical operations to the input timeseries. In some
embodiments, timeseries operators 606 perform data cleansing
operations or deduplication operations on an input timeseries. In
some embodiments, timeseries operators 606 use the input timeseries
to generate eventseries based on the values of the timeseries
samples. The output timeseries can be stored as derived timeseries
data in storage 314 as one or more timeseries data entities.
Similarly, the eventseries can be stored as eventseries data
entities in storage 314.
[0158] In some embodiments, timeseries operators 606 do not change
or replace the raw timeseries data, but rather generate various
"views" of the raw timeseries data (e.g., as separate data
entities) with corresponding relational objects defining the
relationships between the raw timeseries data entity and the
various views data entities. The views can be queried in the same
manner as the raw timeseries data. For example, samples can be read
from the raw timeseries data entity, transformed to create the view
entity, and then provided as an output. Because the transformations
used to create the views can be computationally expensive, the
views can be stored as "materialized view" data entities in
timeseries database 628. Instances of relational objects can be
created to define the relationship between the raw timeseries data
entity and the materialize view data entities. These materialized
views are referred to as derived data timeseries throughout the
present disclosure.
[0159] Timeseries operators 606 can be configured to run at query
time (e.g., when a request for derived data timeseries is received)
or prior to query time (e.g., when new raw data samples are
received, in response to a defined event or trigger, etc.). This
flexibility allows timeseries operators 606 to perform some or all
of their operations ahead of time and/or in response to a request
for specific derived data timeseries. For example, timeseries
operators 606 can be configured to pre-process one or more
timeseries that are read frequently to ensure that the timeseries
are updated whenever new data samples are received, and the
pre-processed timeseries may be stored in a corresponding data
entity for retrieval. However, timeseries operators 606 can be
configured to wait until query time to process one or more
timeseries that are read infrequently to avoid performing
unnecessary processing operations.
[0160] In some embodiments, timeseries operators 606 are triggered
in a particular sequence defined by a directed acyclic graph (DAG).
The DAG may define a workflow or sequence of operations or
transformations to apply to one or more input timeseries. For
example, the DAG for a raw data timeseries may include a data
cleansing operation, an aggregation operation, and a summation
operation (e.g., adding two raw data timeseries to create a virtual
point timeseries). The DAGs can be stored in a DAG database 630
within storage 314, or internally within timeseries processing
engine 604. DAGs can be retrieved by workflow manager 622 and used
to determine how and when to process incoming data samples.
Exemplary systems and methods for creating and using DAGs are
described in greater detail below.
[0161] Timeseries operators 606 can perform aggregations for
dashboards, cleansing operations, logical operations for rules and
fault detection, machine learning predictions or classifications,
call out to external services, or any of a variety of other
operations which can be applied to timeseries data. The operations
performed by timeseries operators 606 are not limited to sensor
data. Timeseries operators 606 can also operate on event data or
function as a billing engine for a consumption or tariff-based
billing system. Timeseries operators 606 are shown to include a
sample aggregator 608, a virtual point calculator 610, a weather
point calculator 612, a fault detector 614, and an eventseries
generator 615.
[0162] Still referring to FIG. 6, timeseries processing engine 604
is shown to include a DAG optimizer 618. DAG optimizer 618 can be
configured to combine multiple DAGs or multiple steps of a DAG to
improve the efficiency of the operations performed by timeseries
operators 606. For example, suppose that a DAG has one functional
block which adds "Timeseries A" and "Timeseries B" to create
"Timeseries C" (i.e., A+B=C) and another functional block which
adds "Timeseries C" and "Timeseries D" to create "Timeseries E"
(i.e., C+D=E). DAG optimizer 618 can combine these two functional
blocks into a single functional block which computes "Timeseries E"
directly from "Timeseries A," "Timeseries B," and "Timeseries D"
(i.e., E=A+B+D). Alternatively, both "Timeseries C" and "Timeseries
E" can be computed in the same functional block to reduce the
number of independent operations required to process the DAG.
[0163] In some embodiments, DAG optimizer 618 combines DAGs or
steps of a DAG in response to a determination that multiple DAGs or
steps of a DAG will use similar or shared inputs (e.g., one or more
of the same input timeseries). This allows the inputs to be
retrieved and loaded once rather than performing two separate
operations that both load the same inputs. In some embodiments, DAG
optimizer 618 schedules timeseries operators 606 to nodes where
data is resident in memory in order to further reduce the amount of
data required to be loaded from the timeseries database 628.
[0164] Timeseries processing engine 604 is shown to include a
directed acyclic graph (DAG) generator 620. DAG generator 620 can
be configured to generate one or more DAGs for each raw data
timeseries. Each DAG may define a workflow or sequence of
operations which can be performed by timeseries operators 606 on
the raw data timeseries. When new samples of the raw data
timeseries are received, workflow manager 622 can retrieve the
corresponding DAG and use the DAG to determine how the raw data
timeseries should be processed. In some embodiments, the DAGs are
declarative views which represent the sequence of operations
applied to each raw data timeseries. The DAGs may be designed for
timeseries rather than structured query language (SQL).
[0165] In some embodiments, DAGs apply over windows of time. For
example, the timeseries processing operations defined by a DAG may
include a data aggregation operation that aggregates a plurality of
raw data samples having timestamps within a given time window. The
start time and end time of the time window may be defined by the
DAG and the timeseries to which the DAG is applied. The DAG may
define the duration of the time window over which the data
aggregation operation will be performed. For example, the DAG may
define the aggregation operation as an hourly aggregation (i.e., to
produce an hourly data rollup timeseries), a daily aggregation
(i.e., to produce a daily data rollup timeseries), a weekly
aggregation (i.e., to produce a weekly data rollup timeseries), or
any other aggregation duration. The position of the time window
(e.g., a specific day, a specific week, etc.) over which the
aggregation is performed may be defined by the timestamps of the
data samples of timeseries provided as an input to the DAG.
[0166] In operation, sample aggregator 608 can use the DAG to
identify the duration of the time window (e.g., an hour, a day, a
week, etc.) over which the data aggregation operation will be
performed. Sample aggregator 608 can use the timestamps of the data
samples in the timeseries provided as an input to the DAG to
identify the location of the time window (i.e., the start time and
the end time). Sample aggregator 608 can set the start time and end
time of the time window such that the time window has the
identified duration and includes the timestamps of the data
samples. In some embodiments, the time windows are fixed, having
predefined start times and end times (e.g., the beginning and end
of each hour, day, week, etc.). In other embodiments, the time
windows may be sliding time windows, having start times and end
times that depend on the timestamps of the data samples in the
input timeseries.
[0167] FIG. 7 shows a flow diagram of a process or method for
updating/creating a data entity based on timeseries data for a
device, according to some embodiments. Referring to FIG. 7, the
process starts, and when timeseries data (e.g., input or raw
timeseries data) that has been generated for an IoT device (e.g.,
by the data collector) is received, the transformation service 408
may determine an identifier of the IoT device from the received
timeseries data at block 705. At block 710, the transformation
service 408 may compare an identity static attribute from the data
with identity static attributes of registered object entities to
locate a data container for the IoT device. If a match does not
exist from the comparison at block 715, the transformation service
408 may invoke the registration service to register the IoT device
at block 720. If a match exists from the comparison at block 715,
the transformation service 408 may generate an entity graph or
retrieve entity data for the device at block 725. From the entity
graph or entity data, transformation service 408 may determine if a
corresponding data entity exists based on the relational objects
(e.g., isLinked) for the IoT device to update a dynamic attribute
from the data at block 735. If not, management service 406 may
create a data entity for the dynamic attribute and an instance of a
corresponding relational object (e.g., isLinked) to define the
relationship between the dynamic attribute and created data entity
at block 740. If the corresponding data entity exists, management
service 406 may update the data entity corresponding to the dynamic
attribute from the data at block 745. Then, transformation service
408 may update or regenerate the entity graph or entity data at
block 650, and the process may end.
[0168] FIG. 8 is an example entity graph of entity data according
to an embodiment of the present disclosure. The example of FIG. 8
assumes that a fault based application has detected a faulty
measurement with respect to IoT device 2. However, IoT device 2
relies on various other systems and devices in order to operate
properly. Thus, while the faulty measurement was detected with
respect to IoT device 2, IoT device 2 itself may be operating
properly. Accordingly, in order to pin point the cause of the
faulty measurement, the fault based application may require
additional information from various related IOT systems and devices
(e.g., entity objects), as well as the zones and locations (e.g.,
entity objects) that the systems and devices are configured to
serve, in order to properly determine or infer the cause of the
faulty measurement.
[0169] Referring to FIG. 8, entity graph 800 represents each of the
entities (e.g., IoT device 2 and other related entities) as nodes
on the entity graph 800, and shows the relationship between IoT
device 2 and related entities via relational objects (e.g., Feeds,
hasPoint, hasPart, Controls, etc.). For example, entity graph 800
shows that the entities related to IoT device 2 include a plurality
of IoT systems 1-4, IoT device 1, zones 1 and 2, and locations 1
and 2, each represented as a node on the entity graph 800. Further,
the relational objects indicate that IoT device 2 provides a data
point (e.g., hasPoint) to zone 1. Zone 1 is shown to service
location 1 (e.g., hasPart), which is also serviced by zone 2 (e.g.,
hasPart). Zone 2 also services location 2 (e.g., hasPart), and is
controlled by IoT system 4 (e.g., controls). IoT device 2 is shown
to also provide a data point (e.g., hasPoint) to IoT system 2. IoT
system 2 is shown to include IoT system 3 (e.g., hasPart), and
feeds (e.g., Feeds) zone 1. Further, IoT system 2 is fed (e.g.,
Feeds) by IoT system 1, which receives a data point (e.g.,
hasPoint) from IoT device 1.
[0170] Accordingly, in the example of FIG. 8, in response to
receiving the faulty measurement from IoT device 2, the fault based
application and/or analytics service 324 can determine from the
entity graph that the fault could be caused by some malfunction in
one or more of the other related entities, and not necessarily a
malfunction of the IoT device 2. Thus, the fault based application
and/or the analytics service 324 can investigate into the other
related entities to determine or infer the most likely cause of the
fault.
[0171] For example, FIG. 9 is a flow diagram of a process or method
for analyzing data from a second related device based on data from
a first device, according to some embodiments. Referring to FIG. 9,
the process starts and timeseries data (e.g., raw or input
timeseries data generated by data collector) including an abnormal
measurement from a first device is received at block 905.
Transformation service 408 determines an identifier of the first
device from the received timeseries data at block 910.
Transformation service 408 identifies a second device related to
the first device through relational objects associated with the
first device at block 915. Transformation service 408 invokes web
service 402 to retrieve measurement data from the second device at
block 920. Analytics service 324 analyzes the data from the first
device and the second device at block 925. Analytics service 324
provides a recommendation from the analysis of the data from each
of the first device and the second device at block 930, and the
process ends.
[0172] FIG. 10 is a flow diagram of a process or method for
generating derived timeseries from data generated by a first device
and a second device, according to some embodiments. Referring to
FIG. 10, the process starts and raw data is received from a first
device at block 1005. The raw data may include one or more data
points generated by the first device. For example, the data points
may be measurement values generated by the first device. The data
collector 312 generates raw (or input) timeseries from the raw data
at block 1010. The raw timeseries may include an identifier of the
first device, a timestamp (e.g., a local timestamp) of when the one
or more data points were generated by the first device and an
offset value, and a value of the one or more data points.
[0173] Transformation service 408 determines an identifier of the
first device from the raw timeseries data, and identifies a first
object entity representing the first device at block 1015 (e.g.,
using entity graph or data). The raw timeseries data is stored in a
corresponding data entity that is related to the first object
entity at block 1020. For example, transformation service 408 may
identify the corresponding data entity from a relational object
defining the relationship between the first object entity and the
corresponding data entity.
[0174] Timeseries processing engine 604 identifies a processing
workflow (e.g., a DAG processing workflow) to process the raw
timeseries data at block 1025. In the example of FIG. 10, the
processing workflow takes as input, the raw timeseries data for the
first device, and data from a second device. Accordingly, a second
object entity for the second device is identified at block 1030.
For example, the second object entity may be determined from a
relational object indicating a relationship between the first
object entity and the second object entity. A corresponding data
entity storing raw or derived timeseries data for the second device
is identified at block 1035. For example, the corresponding data
entity may be determined from a relational descriptor indicating a
relationship between the second object entity and the corresponding
data entity.
[0175] The processing workflow is executed to generate the derived
timeseries at block 1040. For example, the derived timeseries may
include a virtual data point that is calculated using data from the
first device and the second device. For example, an arithmetic
operation may be performed on the data of the first and second
devices to calculate the virtual data point. A corresponding data
entity is identified to store the derived timeseries. For example,
the corresponding data entity may be identified through one or more
relational objects indicating a relationship between the
corresponding data entity and the first device and/or the
corresponding data entity and the second device. The derived
timeseries is stored in the corresponding data entity at block
1045, and the process ends.
Configuration of Exemplary Embodiments
[0176] The construction and arrangement of the systems and methods
as shown in the various exemplary embodiments are illustrative
only. Although only a few embodiments have been described in detail
in this disclosure, many modifications are possible (e.g.,
variations in sizes, dimensions, structures, shapes and proportions
of the various elements, values of parameters, mounting
arrangements, use of materials, colors, orientations, etc.). For
example, the position of elements can be reversed or otherwise
varied and the nature or number of discrete elements or positions
can be altered or varied. Accordingly, all such modifications are
intended to be included within the scope of the present disclosure.
The order or sequence of any process or method steps can be varied
or re-sequenced according to alternative embodiments. Other
substitutions, modifications, changes, and omissions can be made in
the design, operating conditions and arrangement of the exemplary
embodiments without departing from the scope of the present
disclosure.
[0177] The present disclosure contemplates methods, systems and
program products on any machine-readable media for accomplishing
various operations. The embodiments of the present disclosure can
be implemented using existing computer processors, or by a special
purpose computer processor for an appropriate system, incorporated
for this or another purpose, or by a hardwired system. Embodiments
within the scope of the present disclosure include program products
comprising machine-readable media for carrying or having
machine-executable instructions or data structures stored thereon.
Such machine-readable media can be any available media that can be
accessed by a general purpose or special purpose computer or other
machine with a processor. By way of example, such machine-readable
media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical
disk storage, magnetic disk storage or other magnetic storage
devices, or any other medium which can be used to carry or store
desired program code in the form of machine-executable instructions
or data structures and which can be accessed by a general purpose
or special purpose computer or other machine with a processor.
Combinations of the above are also included within the scope of
machine-readable media. Machine-executable instructions include,
for example, instructions and data which cause a general purpose
computer, special purpose computer, or special purpose processing
machines to perform a certain function or group of functions.
[0178] Although the figures show a specific order of method steps,
the order of the steps may differ from what is depicted. Also two
or more steps can be performed concurrently or with partial
concurrence. Such variation will depend on the software and
hardware systems chosen and on designer choice. All such variations
are within the scope of the disclosure. Likewise, software
implementations could be accomplished with standard programming
techniques with rule based logic and other logic to accomplish the
various connection steps, processing steps, comparison steps and
decision steps.
[0179] The term "client or "server" include all kinds of apparatus,
devices, and machines for processing data, including by way of
example a programmable processor, a computer, a system on a chip,
or multiple ones, or combinations, of the foregoing. The apparatus
may include special purpose logic circuitry, e.g., a field
programmable gate array (FPGA) or an application specific
integrated circuit (ASIC). The apparatus may also include, in
addition to hardware, code that creates an execution environment
for the computer program in question (e.g., code that constitutes
processor firmware, a protocol stack, a database management system,
an operating system, a cross-platform runtime environment, a
virtual machine, or a combination of one or more of them). The
apparatus and execution environment may realize various different
computing model infrastructures, such as web services, distributed
computing and grid computing infrastructures.
[0180] The systems and methods of the present disclosure may be
completed by any computer program. A computer program (also known
as a program, software, software application, script, or code) may
be written in any form of programming language, including compiled
or interpreted languages, declarative or procedural languages, and
it may be deployed in any form, including as a stand-alone program
or as a module, component, subroutine, object, or other unit
suitable for use in a computing environment. A computer program
may, but need not, correspond to a file in a file system. A program
may be stored in a portion of a file that holds other programs or
data (e.g., one or more scripts stored in a markup language
document), in a single file dedicated to the program in question,
or in multiple coordinated files (e.g., files that store one or
more modules, sub programs, or portions of code). A computer
program may be deployed to be executed on one computer or on
multiple computers that are located at one site or distributed
across multiple sites and interconnected by a communication
network.
[0181] The processes and logic flows described in this
specification may be performed by one or more programmable
processors executing one or more computer programs to perform
actions by operating on input data and generating output. The
processes and logic flows may also be performed by, and apparatus
may also be implemented as, special purpose logic circuitry (e.g.,
an FPGA or an ASIC).
[0182] Processors suitable for the execution of a computer program
include, by way of example, both general and special purpose
microprocessors, and any one or more processors of any kind of
digital computer. Generally, a processor will receive instructions
and data from a read only memory or a random access memory or both.
The essential elements of a computer are a processor for performing
actions in accordance with instructions and one or more memory
devices for storing instructions and data. Generally, a computer
will also include, or be operatively coupled to receive data from
or transfer data to, or both, one or more mass storage devices for
storing data (e.g., magnetic, magneto-optical disks, or optical
disks). However, a computer need not have such devices. Moreover, a
computer may be embedded in another device (e.g., a mobile
telephone, a personal digital assistant (PDA), a mobile audio or
video player, a game console, a Global Positioning System (GPS)
receiver, or a portable storage device (e.g., a universal serial
bus (USB) flash drive), etc.). Devices suitable for storing
computer program instructions and data include all forms of
non-volatile memory, media and memory devices, including by way of
example semiconductor memory devices (e.g., EPROM, EEPROM, and
flash memory devices; magnetic disks, e.g., internal hard disks or
removable disks; magneto-optical disks; and CD ROM and DVD-ROM
disks). The processor and the memory may be supplemented by, or
incorporated in, special purpose logic circuitry.
[0183] In various implementations, the steps and operations
described herein may be performed on one processor or in a
combination of two or more processors. For example, in some
implementations, the various operations could be performed in a
central server or set of central servers configured to receive data
from one or more devices (e.g., edge computing devices/controllers)
and perform the operations. In some implementations, the operations
may be performed by one or more local controllers or computing
devices (e.g., edge devices), such as controllers dedicated to
and/or located within a particular building or portion of a
building. In some implementations, the operations may be performed
by a combination of one or more central or offsite computing
devices/servers and one or more local controllers/computing
devices. All such implementations are contemplated within the scope
of the present disclosure. Further, unless otherwise indicated,
when the present disclosure refers to one or more computer-readable
storage media and/or one or more controllers, such
computer-readable storage media and/or one or more controllers may
be implemented as one or more central servers, one or more local
controllers or computing devices (e.g., edge devices), any
combination thereof, or any other combination of storage media
and/or controllers regardless of the location of such devices.
[0184] To provide for interaction with a user, implementations of
the subject matter described in this specification may be
implemented on a computer having a display device (e.g., a CRT
(cathode ray tube), LCD (liquid crystal display), OLED (organic
light emitting diode), TFT (thin-film transistor), or other
flexible configuration, or any other monitor for displaying
information to the user and a keyboard, a pointing device, e.g., a
mouse, trackball, etc., or a touch screen, touch pad, etc.) by
which the user may provide input to the computer. Other kinds of
devices may be used to provide for interaction with a user as well;
for example, feedback provided to the user may be any form of
sensory feedback (e.g., visual feedback, auditory feedback, or
tactile feedback), and input from the user may be received in any
form, including acoustic, speech, or tactile input. In addition, a
computer may interact with a user by sending documents to and
receiving documents from a device that is used by the user; for
example, by sending web pages to a web browser on a user's client
device in response to requests received from the web browser.
[0185] Implementations of the subject matter described in this
disclosure may be implemented in a computing system that includes a
back-end component (e.g., as a data server), or that includes a
middleware component (e.g., an application server), or that
includes a front end component (e.g., a client computer) having a
graphical user interface or a web browser through which a user may
interact with an implementation of the subject matter described in
this disclosure, or any combination of one or more such back end,
middleware, or front end components. The components of the system
may be interconnected by any form or medium of digital data
communication (e.g., a communication network). Examples of
communication networks include a LAN and a WAN, an inter-network
(e.g., the Internet), and peer-to-peer networks (e.g., ad hoc
peer-to-peer networks).
[0186] The present disclosure may be embodied in various different
forms, and should not be construed as being limited to only the
illustrated embodiments herein. Rather, these embodiments are
provided as examples so that this disclosure will be thorough and
complete, and will fully convey the aspects and features of the
present disclosure to those skilled in the art. Accordingly,
processes, elements, and techniques that are not necessary to those
having ordinary skill in the art for a complete understanding of
the aspects and features of the present disclosure may not be
described. Unless otherwise noted, like reference numerals denote
like elements throughout the attached drawings and the written
description, and thus, descriptions thereof may not be repeated.
Further, features or aspects within each example embodiment should
typically be considered as available for other similar features or
aspects in other example embodiments.
[0187] It will be understood that, although the terms "first,"
"second," "third," etc., may be used herein to describe various
elements, components, regions, layers and/or sections, these
elements, components, regions, layers and/or sections should not be
limited by these terms. These terms are used to distinguish one
element, component, region, layer or section from another element,
component, region, layer or section. Thus, a first element,
component, region, layer or section described below could be termed
a second element, component, region, layer or section, without
departing from the spirit and scope of the present disclosure.
[0188] The terminology used herein is for the purpose of describing
particular embodiments and is not intended to be limiting of the
present disclosure. As used herein, the singular forms "a" and "an"
are intended to include the plural forms as well, unless the
context clearly indicates otherwise. It will be further understood
that the terms "comprises," "comprising," "includes," and
"including," "has," "have," and "having," when used in this
specification, specify the presence of the stated features,
integers, steps, operations, elements, and/or components, but do
not preclude the presence or addition of one or more other
features, integers, steps, operations, elements, components, and/or
groups thereof. As used herein, the term "and/or" includes any and
all combinations of one or more of the associated listed items.
Expressions such as "at least one of," when preceding a list of
elements, modify the entire list of elements and do not modify the
individual elements of the list.
[0189] As used herein, the term "substantially," "about," and
similar terms are used as terms of approximation and not as terms
of degree, and are intended to account for the inherent variations
in measured or calculated values that would be recognized by those
of ordinary skill in the art. Further, the use of "may" when
describing embodiments of the present disclosure refers to "one or
more embodiments of the present disclosure." As used herein, the
terms "use," "using," and "used" may be considered synonymous with
the terms "utilize," "utilizing," and "utilized," respectively.
Also, the term "exemplary" is intended to refer to an example or
illustration.
[0190] A portion of the disclosure of this patent document contains
material which is subject to copyright protection. The copyright
owner has no objection to the facsimile reproduction by anyone of
the patent document or the patent disclosure, as it appears in the
Patent and Trademark Office patent file or records, but otherwise
reserves all copyright rights whatsoever.
* * * * *