WEB SERVICES FOR SMART ENTITY CREATION AND MAINTENANCE USING TIME SERIES DATA
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.
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.
BACKGROUNDOne 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.
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.
SUMMARYOne 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.
In some embodiments, the relational objects may semantically define the relationships between the object entities and the data entities.
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.
In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity.
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.
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.
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.
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.
In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries.
In some embodiments, at least one of the first or second devices may be a sensor.
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.
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.
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.
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.
In some embodiments, the relational objects may semantically define the relationships between the object entities and the data entities.
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.
In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity.
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.
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.
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.
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.
In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries.
In some embodiments, at least one of the first or second devices may be a sensor.
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.
In some embodiments, the method may further include creating a shadow entity to store historical values of the first raw data.
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.
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.
In some embodiments, the relational objects may semantically define the relationships between the object entities and the data entities.
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.
In some embodiments, the first input timeseries may correspond to the dynamic attribute of the first object entity.
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.
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.
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.
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.
In some embodiments, the derived timeseries may include one or more virtual data points calculated according to the first and second input timeseries.
In some embodiments, at least one of the first or second devices may be a sensor.
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.
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.
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.
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:
Hereinafter, example embodiments will be described in more detail with reference to the accompanying drawings.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.).
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.
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.
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.
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 SystemReferring now to
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).
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.
Still referring to
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.
Still referring to
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.
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
Still referring to
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.
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.
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.
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.
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.
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.
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
Referring now to
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.
IoTMS 300 can include many of the same components as IoTMS 200, as described with reference to
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.
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.
Still referring to
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.
Still referring to
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., ° F., ° 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).
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, timestamp1, value1>, <key, timestamp2, value2>, <key, timestamp3, value3>]
where key is an identifier of the source of the raw data samples (e.g., timeseries ID, sensor ID, device ID, etc.), timestampi identifies the time at which the ith sample was collected, and valuei indicates the value of the ith sample.
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.
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.
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.
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.
Still referring to
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.
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 (pointID3) by adding two or more actual data points (pointID1 and pointID2) (e.g., pointID3=pointID1+pointID2). As another example, timeseries service 328 can calculate an enthalpy data point (pointID4) based on a measured temperature data point (pointID5) and a measured pressure data point (pointID6) (e.g., pointID4=enthalpy(pointID5, pointID6)). The virtual data points can be stored as derived timeseries data.
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
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.
Still referring to
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.
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 ServiceReferring now to
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.
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.
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.
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.
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→hasPart→Entity B).
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.
For example, referring to
For example, an entity type (or object) “Activity Tracker” may be represented via the below schema:
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.
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:
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.”
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:
where various attributes are static attributes (e.g., “Description” and “Device_Type”) and dynamic attributes (e.g., “Present-Value”).
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.
For example, still referring to
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.
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.
In this example, the data entity AI 201-01 526 may be represented by the following data model:
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.
The data entity TS Id 1 534 may be represented, for example, by the following data model:
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.
Still referring to
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
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.
Referring again to
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.
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.
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® 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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
Still referring to
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.
Still referring to
Referring now to
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.
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:
- [<key, timestamp1,value1>, <key, timestamp2, value2>, <key, timestamp3, value3>]
where key is an identifier of the source of the data samples (e.g., timeseries ID, sensor ID, device ID, etc.), timestampi identifies a time associated with the ith sample, and valuer indicates the value of the ith sample.
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:
-
- [<eventID1, start_timestamp1, end_timestamp1, state1>, . . . , <eventIDN, start_timestampN, end_timestampN, stateN>]
where eventIDi is an identifier of the ith event, start_timestampi is the time at which the ith event started, end_timestampi 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.
- [<eventID1, start_timestamp1, end_timestamp1, state1>, . . . , <eventIDN, start_timestampN, end_timestampN, stateN>]
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.
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.
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.
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.
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.
Still referring to
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.
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.
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.
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.
Still referring to
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.
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).
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.
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.
Referring to
Accordingly, in the example of
For example,
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.
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
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 EmbodimentsThe 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.
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.
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.
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.
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.
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).
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
Type: Application
Filed: Sep 26, 2018
Publication Date: Mar 28, 2019
Inventors: Youngchoon Park (Brookfield, WI), Sudhi R. Sinha (Milwaukee, WI), Vaidhyanathan Venkiteswaran (Brookfield, WI), Erik S. Paulson (Madison, WI), Vijaya S. Chennupati (Brookfield, WI)
Application Number: 16/142,758
