Sensor event coverage and energy conservation

Abstract

A method for sensor event coverage and energy conservation includes receiving device sensor data for a plurality of sensors in a sensor network. The method also includes identifying one or more anomalies in the device sensor data, the one or more anomalies indicating that one or more sensors from the plurality of sensors acquired data during an event at a particular point in time, and identifying a mobility pattern for the plurality of sensors based on the one or more anomalies. The method also includes updating a base participation profile for the plurality of sensors in response to the one or more anomalies and the mobility pattern, activating a first sensor from the plurality of sensors based on the updated base participation profile.

Description

Background Technology

[0001] This disclosure relates generally to sensor networks, and more specifically to managing sensor networks to provide event coverage while minimizing energy consumption.

[0002] Related computing devices, also known as Internet of Things (IoT) devices, are typically battery-powered and deployed in remote areas with limited or no access to electrical infrastructure. Battery-powered IoT devices capture sensor data and transmit it via a network to remote devices for evaluation. Because battery-powered IoT devices are not connected to electrical infrastructure, their batteries need to be periodically replaced or recharged to ensure data capture and event registration. Although IoT devices can harvest energy from the environment using solar and wind power to periodically recharge their batteries, continuous charging cycles reduce battery capacity over the battery's expected lifespan. Summary of the Invention

[0003] According to embodiments of the present invention, a method, computer program product, and computer system for sensor event coverage and energy saving are disclosed. The method, computer program product, and computer system can receive device sensor data for multiple sensors in a sensor network. The method, computer program product, and computer system can identify one or more anomalies in the device sensor data, the one or more anomalies indicating that one or more sensors from the multiple sensors acquired data during an event at a specific point in time. The method, computer program product, and computer system can identify movement patterns for the multiple sensors based on the one or more anomalies. The method, computer program product, and computer system can update a basic engagement profile for the multiple sensors in response to one or more anomalies and movement patterns, and activate a first sensor from the multiple sensors based on the updated basic engagement profile. Attached Figure Description

[0004] Figure 1 This is a functional block diagram illustrating a distributed data processing environment according to an embodiment of the present invention.

[0005] Figure 2 This describes an embodiment of the invention. Figure 1 A flowchart of the operational steps of a sensor event coverage procedure used to provide sensor network event coverage on a server computer within a distributed data processing environment.

[0006] Figure 3A An example of an activity participation pattern at time (n) of sensor network event coverage performed by a sensor event coverage procedure according to an embodiment of the present invention is shown.

[0007] Figure 3B An example of an active participation mode at time (n+50) of sensor network event coverage performed by a sensor event coverage procedure according to an embodiment of the present invention is shown.

[0008] Figure 3C An example of an active participation mode at time (n+100) of sensor network event coverage performed by a sensor event coverage procedure for different seasons, according to an embodiment of the present invention, is shown.

[0009] Figure 4 An example of an active participation mode at time (n) of sensor network event coverage performed by a sensor event coverage procedure according to an embodiment of the present invention is shown.

[0010] Figure 5 The invention describes an embodiment of the invention in Figure 1 A block diagram of the components of a server computer that executes sensor event overlay procedures in a distributed data processing environment.

[0011] Figure 6 A cloud computing environment according to an embodiment of the present invention is described; and

[0012] Figure 7 An abstract model layer according to an embodiment of the present invention is described. Detailed Implementation

[0013] Internet of Things (IoT) sensor networks utilize multiple associated computing devices to provide event coverage for data capture. However, not every IoT sensor in the network is required to capture and transmit data, thus consuming energy. Embodiments of the present invention manage the IoT sensor network based on participation profiles to activate a subset of sensors within an event coverage area to capture and transmit data to provide event coverage. In instances where a subset of sensors from the IoT sensor network does not need to provide event coverage based on participation profiles, this subset of sensors is placed in a low-power state (e.g., sleep mode). In this low-power state, this subset of sensors in the IoT network can receive activation commands but does not need to capture and transmit data because it is outside the event coverage area.

[0014] Figure 1 This is a functional block diagram illustrating a distributed data processing environment according to an embodiment of the present invention. The distributed data processing environment includes a server computer 102, client devices 104, and a sensor network 122, all of which are interconnected via a network 106.

[0015] Server computer 102 can be a desktop computer, laptop computer, tablet computer, dedicated computer server, smartphone, or any computer system capable of executing various embodiments of sensor event overlay program 108. In some embodiments, server computer 102 represents a computer system utilizing cluster computers and components that, when accessed via network 106, act as a single seamless resource pool, as this is common in data centers and with cloud computing applications. Typically, server computer 102 represents any programmable electronic device or combination of programmable electronic devices capable of executing machine-readable program instructions and communicating with other computer devices via a network. Server computer 102 has communication capabilities with other computer devices ( Figure 1 (Not shown) The ability to communicate with computer devices to query information. In this embodiment, server computer 102 includes sensor event overlay program 108 capable of communicating with database 110, wherein database 110 includes device participation profile 112, sensor data 114, anomaly data 116, and movement pattern data 118.

[0016] Client device 104 may be a cellular phone, smartphone, smartwatch, laptop computer, tablet computer, or any other electronic device capable of communicating via network 106. Typically, client device 104 represents one or more programmable electronic devices or combinations of programmable electronic devices capable of executing machine-readable program instructions and communicating with other computing devices (not shown) within a distributed data processing environment via a network such as network 106. In one embodiment, client computing device 104 represents one or more devices associated with a user. Client device 104 includes a user interface 120, which enables a user of client device 104 to interact with sensor event overlay program 108 on server computer 102.

[0017] Sensor event coverage procedure 108 uses participation profiles 112 of multiple sensors designated as sensors 124A, 124B, and 124N in sensor network 122 to determine when to activate and deactivate specific sensors in sensor network 122 to provide event coverage. In this embodiment, one or more participation profiles 112 from the multiple participation profiles 112 are associated with sensors (e.g., sensor 124A) from the multiple sensors. It should be noted that sensor 124A represents the first sensor, sensor 124B represents the second sensor, and sensor 124N represents the last sensor in sensor network 122, where sensor 124N may, for example, represent the twentieth or forty-fifth sensor in sensor network 122. Event coverage refers to an instance in which sensor event coverage procedure 108 activates one or more sensors in sensor network 122 to capture and transmit data during an event. Sensor event coverage procedure 108 uses the known locations of sensors 124A, 124B, and 124N and the determined event coverage area to establish participation profiles 112.

[0018] Sensor event coverage procedure 108 determines a basic engagement profile 112 for sensors 124A, 124B, and 124N in sensor network 122, wherein sensor event coverage procedure 108 utilizes a time-based activation schedule and / or user-defined activation preferences for sensors 124A, 124B, and 124N. Sensor event coverage procedure 108 receives device sensor data 114 from each sensor (e.g., sensor 124B) in sensor network 122, wherein device sensor data 114 indicates the time of data captured for each sensor 124A, 124B, and 124N, the reason for data capture, one or more data types captured, and one or more data types transmitted. Sensor event coverage procedure 108 identifies anomalies in the received device sensor data 114 and identifies movement patterns based on the identified anomalies. Subsequently, sensor event coverage procedure 108 stores device sensor data 114, stores the identified anomalies as anomaly data 116, and stores the identified movement patterns as movement pattern data 118. The sensor event coverage procedure 108 updates the basic engagement profile 112 of the sensor network 122 through an iterative machine learning process based on the received device sensor data 114, anomaly data 116, and mobility pattern data 118.

[0019] Sensor event coverage procedure 108 determines whether to initialize the participation profile 112 of sensors 124A, 124B, and 124N in sensor network 122. In response to determining that participation profile 112 should be initialized, sensor event coverage procedure 108 activates each sensor in sensor network 122 based on participation profile 112. In response to determining that sensor event coverage procedure 108 should not be initialized, sensor event coverage procedure 108 returns to receiving additional device sensor data 114 to perform another iteration of the machine learning process, thereby further updating participation profile 112. As sensor event coverage procedure 108 activates and deactivates each sensor in sensor network 122, sensor event coverage procedure 108 updates participation profile 112 of sensor network 122 based on the received device sensor data 114.

[0020] Database 110 is a repository of data used by sensor event overlay program 108, such as participation profile 112, device sensor data 114, anomaly data 116, and movement pattern data 118. In the depicted embodiment, database 110 resides on server computer 102. In another embodiment, database 110 may reside on client device 104 or elsewhere within a distributed data processing environment provided for the sensor event overlay program 108 to access. Database 110 can be implemented using any type of storage device capable of storing data and configuration files accessible and utilized by the generated design program 108, such as a database server, hard disk drive, or flash memory.

[0021] The engagement profile 112 for sensors 124A, 124B, and 124N provides instructions for activating and deactivating sensors 124A, 124B, and 124N, where sensor activation indicates that the sensor is capturing and transmitting data, and sensor deactivation indicates that the sensor is in a low-power state (e.g., sleep mode). Device sensor data 114 includes information for each sensor 124A, 124B, and 124N, such as the time of data capture, the reason for data capture, one or more data types captured, and one or more data types transmitted. Anomalous data 116 includes data captured by a specific sensor (e.g., sensor 124A) in sensor network 122, which sensor event coverage 108 identifies as irregular relative to data captured by other sensors (e.g., sensors 124B and 124N) in sensor network 122. Motion pattern data 118 includes motion patterns or changes across sensor network 122 identified by sensor event coverage 108 based on device sensor data 114 and anomalous data 116.

[0022] Typically, network 106 can be any combination of connections and protocols supporting communication between server computer 102, client device 104, and sensor network 122. Network 106 may include, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, a cellular network, or any combination thereof, and may also include wired, wireless, and / or fiber optic connections. In one embodiment, sensor event overlay 108 may be a web service accessible to a user of client device 104 via network 106. In another embodiment, sensor event overlay 108 may be directly operated by a user of server computer 102. Sensor network 122 can be any combination of connections and protocols supporting communication between sensors 124A, 124B, and 124N and network 106. Sensor network 122 may include, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, a cellular network, or any combination thereof, and may also include wired, wireless, and / or fiber optic connections independent of network 106.

[0023] Figure 2 This describes an embodiment of the invention. Figure 1 A flowchart of the operational steps of a sensor event coverage procedure used to provide sensor network event coverage on a server computer within a distributed data processing environment.

[0024] During the training phase, each sensor in the sensor network continuously captures sensor data, and based on the analysis of the captured sensor data, a sensor event coverage program identifies anomalies in the captured sensor data. Each sensor in the sensor network includes a unique identification tag, and a corresponding certificate for each captured sensor data is stored in a database. When a server computer with the sensor event coverage program receives sensor data from each sensor in the sensor network, a unique identification tag for each sensor is included to associate a specific sensor with the captured sensor data. The sensor event coverage program can identify movement patterns based on the identified anomalies. A matrix of sensor data values ​​for different time points (n) is fed into the neural network model of the sensor event coverage program. In one embodiment, the values ​​can be normalized to "0" and "1" to represent inactive and active sensors, respectively. An inactive sensor may represent a sensor that does not acquire data at a specific time point (n), while an active sensor may represent a sensor that acquires data at a specific time point (n). In another embodiment, the values ​​in the sensor data value matrix may include sensor readings for a specific sensor (e.g., 25°C). In yet another embodiment, the values ​​in the sensor data value matrix can indicate whether a particular sensor is operating under normal conditions or under abnormal detection conditions. Regarding Figures 3A-3C The visual representation of the example sensor data value matrix is ​​discussed in more detail.

[0025] Sensor event coverage procedures can deploy dimensionality reduction by reducing redundant features to make classification easier and feed input features into a neural network model. Dimensionality reduction unsupervised learning methods (e.g., Monte Carlo methods) can reduce or eliminate features over time, or in this example, reduce dependence on one or more sensor readings. Dimensionality reduction unsupervised learning methods achieve higher accuracy and speed up the process of adjusting weights and training the model more quickly. During another iteration of the training process, the neural network output is compared with the sensor value data at time (n+1), and the weights are adjusted as the neural network is trained in each iteration (i.e., time (n+2), time (n+3)...). Sensor event coverage procedures determine when the neural network has been sufficiently trained to deliver what the expected set of active sensors should be compared with the current time segment of the active sensor set.

[0026] During the operational phase, when the sensor network is not collecting data (i.e., no events occur), the neural network has no data to infer patterns, and the case overlaid on top of the prediction framework is the reconnaissance mode. The reconnaissance mode activates the minimum set of sensors in the sensor network to collect data, where the minimum set of sensors represents a subset of sensors in the sensor network. This subset can be selected based on user-defined specified reconnaissance sensors, the most active sensors, sensors acting as anomaly detection points, and can be chosen randomly. During the operational mode, the reconnaissance data signal indicates the presence of even-numbered time (n) data for at least one sensor in the sensor network. The neural network of the sensor event overlay procedure takes the sensor value data at time (n) as input, inner layers with trained weights compute the output values, and the neural network of the sensor event overlay procedure outputs the set of sensor activations at time (n+1). The sensor event overlay procedure uses the set of sensor activations to send wake-up signals to activate sensors and correspondingly send sleep signals to deactivate them.

[0027] Sensor event coverage procedure 108 determines a basic engagement profile (202) for the sensor network. In this embodiment, sensor event coverage procedure 108 determines the basic engagement profile for the sensor network by identifying whether any sensor in the sensor network utilizes a time-based activation schedule and / or user-defined activation preferences. In one example of a time-based activation schedule, sensor event coverage procedure 108 identifies that sensors in the sensor network can be activated and deactivated based on set time intervals (e.g., every twenty minutes), where a sensor is activated at a first time interval to acquire data and then deactivated until a second time interval is reached. In another example of a time-based activation schedule, sensor event coverage procedure 108 identifies that sensors in the sensor network can be active and deactivated during certain hours of the day (e.g., business hours), where a sensor is active between 8 AM and 6 PM and inactive during all other hours. In one example of user-defined activation preferences, sensor event coverage procedure 108 identifies that the user has grouped the sensors in the sensor network into subsets, where activation of a sensor in a subset results in activation of the remaining sensors in the subset, and deactivation of a sensor in a subset results in deactivation of the remaining sensors in the subset. In another example of user-defined activation preferences, sensor event coverage procedure 108 identifies that the user has specified that the sensor remains active for readings within a given range (e.g., X > 15°C), whereby the sensor can deactivate if the sensor reading is no longer within the given range (e.g., X ≤ 15°C). Sensor event coverage procedure 108 utilizes the identified time-based activation schedule and user-defined activation preferences to determine the basic engagement profile of each sensor in the sensor profile to provide event coverage.

[0028] Sensor event coverage procedure 108 receives data (204) from each sensor in the sensor network. Each sensor in the sensor network includes a unique identification tag for identifying the sensor type and known location, wherein the unique identification tag and the corresponding certificate of the device sensor data captured by each sensor are stored in a database. The device sensor data may include acquired readings (e.g., temperature, humidity, sound), activation indications (i.e., active or deactivated), operating status (i.e., normal state, abnormal state, error state), timestamps of the acquired readings, and the location of the acquired readings. Sensor event coverage procedure 108 receives device sensor data over time (n) in the form of a data value matrix, wherein each value in the data value matrix is ​​represented by an acquired reading from a single sensor in the sensor network. Sensor event coverage procedure 108 receives device sensor data with unique identification tags from each sensor in the sensor network and uses the received sensor data to identify anomalies. Sensor event coverage procedure 108 may use the location of the acquired readings to create a visual overlay on a map, wherein sensor event coverage procedure 108 may display the overlay with sensor locations on a map on a client device associated with a user. Users can select one or more sensors in the sensor network to exclude subsequent updates to the basic engagement profile, which will be discussed in further detail regarding (212).

[0029] Sensor event coverage procedure 108 identifies anomalies (206) in the received data. In this embodiment, sensor event coverage procedure 108 identifies anomalies in one or more sensors in the sensor network by comparing the received device sensor data of a single sensor in the sensor network with that of the remaining sensors in the sensor network over time (n). Anomalies identified by sensor event coverage procedure 108 in the received device sensor data of sensors in the sensor network indicate that the sensor is active and acquires data during the event at time (n). An event represents an occurrence in the vicinity of a sensor (i.e., the event coverage area) that requires sensor activation to acquire data and / or perform an action. In one example, multiple camera devices are located at a retail location, where each of the multiple camera devices includes a motion sensor for activating the corresponding camera. Sensor event coverage procedure 108 identifies anomalies in the multiple camera devices that indicate that a first camera device is activated in conjunction with a second camera device at time (n). However, in subsequent iterations of receiving device sensor data, sensor event coverage procedure 108 identifies anomalies in the multiple camera devices that indicate that a first camera device is activated in conjunction with a third camera device at time (n+1), but the second camera device remains inactive. Sensor event coverage procedure 108 identifies and complies with anomalies detected by multiple cameras at retail locations at multiple time points (i.e., time (n+1), time (n+2), time (n+3)...).

[0030] In another example, multiple temperature sensors are positioned in a crop field, where temperature readings and temperature thresholds (e.g., x > 25°C) at each temperature acquisition time (n) from the multiple temperature sensors activate a portion of an irrigation system near the temperature sensors. Activation of the portion of the irrigation system may include opening an electronically controlled water valve to ensure that the soil in the portion of the crop field near the temperature sensors maintains a specific moisture level when the reading is above the temperature threshold. Sensor event overlay procedure 108 identifies anomalies in the multiple temperature sensor data indicating that a first temperature sensor recorded a first reading above the temperature threshold at time (n). However, in subsequent iterations of receiving temperature sensor data, sensor event overlay procedure 108 identifies anomalies in the multiple temperature sensor data indicating that a first, second, and third temperature sensor recorded first, second, and third readings above the temperature threshold at time (n+1). Sensor event overlay procedure 108 identifies and complies with the identified anomalies of the multiple temperature sensors positioned in the crop field at multiple time points (i.e., time (n+1), time (n+2), time (n+3)...).

[0031] Sensor event coverage 108 identifies a movement pattern (208) based on identified anomalies. Sensor event coverage 108 identifies the movement pattern based on a comparison of identified anomalies in device sensor data received at time (n) with any previously identified anomalies in device sensor data received at time (n-1) and time (n-2). For discussion purposes, a movement pattern represents an instance of activation of a subset of sensors in a sensor network, where the subset of active sensors from the sensor network may change at different points in time (e.g., time (n-1) vs. time (n) vs. time (n+1)). In one example, in the case of multiple camera devices located at a retail location, sensor event coverage 108 identifies anomalies in multiple camera devices indicating that a first camera device is activated in conjunction with a second camera device at time (n). Sensor event coverage 108 also pre-identifies anomalies in multiple camera devices indicating that a first camera device is activated in conjunction with a third camera device at time (n-1) and a fourth camera device at time (n-2). Sensor event coverage procedure 108 compares the identified anomaly at time (n) with previously identified anomalies at times (n-1) and (n-2) to identify motion patterns of sensors in the sensor network. Sensor event coverage procedure 108 uses the known location of each camera device with motion sensors in the sensor network to determine when and how each motion sensor in the sensor network is activated and deactivated relative to each other.

[0032] In another example, in a case where multiple temperature sensors are located in a crop field, sensor event coverage 108 identifies anomalies in multiple temperature sensors indicating that a first temperature sensor recorded a first reading above a temperature threshold at time (n). Sensor event coverage 108 also pre-identifies anomalies in multiple temperature sensors indicating that a second temperature sensor recorded a second reading above a temperature threshold at time (n-1), a third temperature sensor recorded a third reading above a temperature threshold at time (n-2), and a fourth temperature sensor recorded a fourth reading above a temperature threshold at time (n-3). Sensor event coverage 108 compares the identified anomaly at time (n) with the previously identified anomalies at times (n-1), (n-2), and (n-3) to identify movement patterns of sensors in the sensor network. Sensor event coverage 108 utilizes the known location of each temperature sensor in the sensor network to determine when and how each temperature sensor in the sensor network is activated and deactivated relative to each other.

[0033] Sensor event coverage 108 stores the received data, identified anomalies, and identified movement patterns (210). Utilizing the unique identification marker and associated timestamp of each sensor in the sensor network, sensor event coverage 108 stores the movement pattern data, anomaly data, and received sensor data of the sensor network at time (n) in a database. Storing the combined data of the sensor network at time (n) represents a single iteration of compiling data for the machine learning process to update the basic engagement profile of the sensor network established in (202). Storing a previous instance of the combined data of the sensor network at time (n-1) and a subsequent instance of the combined data of the sensor network at time (n+1), each representing another iteration of compiling data for the machine learning process, continuously updates the basic engagement profile of the sensor network established in (202).

[0034] Sensor event coverage procedure 108 updates the basic engagement profile (212) for the sensor network. Sensor event coverage procedure 108 updates the basic engagement profile of the sensor network based on received sensor data, anomalous data, and motion pattern data of each sensor in the sensor network. As previously described, the engagement profile provides instructions for activating and deactivating each sensor in the sensor network to provide event coverage at specific points in time, where sensor activation indicates that the sensor is capturing and transmitting data, while sensor deactivation indicates that the sensor is in a low-power state (e.g., sleep mode). In one example, sensor event coverage procedure 108 predetermines the basic engagement profile based on a time-based activation schedule of motion sensors associated with camera devices in the sensor network, activating and deactivating certain hours of the day, where motion sensors are active between 8 AM and 6 PM and inactive at all other hours. However, based on multiple iterations of a machine learning process, sensor event coverage procedure 108 identifies motion patterns of motion sensors in the sensor network that indicate that only a subset of the motion sensors in the sensor network actively acquire data at specific points in time during a certain hour of the day (e.g., time (n-1), time (n+1)). Sensor event coverage procedure 108 updates the basic engagement profile by combining time-based activation scheduling with identified movement patterns of sensors in the sensor network. As a result, at specific time points between 8 AM and 6 PM, only a subset of motion sensors in the sensor network are activated. It should be noted that sensor event coverage procedure 108 also identifies which subset of motion sensors is activated at a specific time point, where a first subset of motion sensors in the sensor network is activated at time (n-1), and a second subset of motion sensors in the sensor network is activated at time (n). One or more sensors in the first subset of motion sensors may be the same as one or more sensors in the second subset of motion sensors.

[0035] In another example, sensor event coverage 108 predetermines a basic engagement profile based on both a time-based activation schedule and user-defined activation preferences for activating temperature sensors in the sensor network. The previously determined time-based activation schedule requires each temperature sensor in the network to be activated every 30 minutes to acquire temperature readings. The predetermined user-defined activation preferences include activating a subset of temperature sensors in the network when temperature readings from a specific temperature sensor are within a given range (e.g., X > 15°C) and deactivating the subset when temperature readings from a specific temperature sensor are outside the given range (e.g., X ≤ 15°C). Based on multiple iterations of the machine learning process, sensor event coverage 108 identifies movement patterns of temperature sensors in the network that instruct the temperature sensors in the network to acquire data only during daytime hours when the ambient temperature is within the given range. Furthermore, the sensor event coverage procedure 108 identifies movement patterns of temperature sensors in the sensor network that indicate only a subset of the temperature sensors are acquiring data within a given range, while the remaining subset is acquiring data outside the given range. Based on the identified movement patterns, the sensor event coverage procedure 108 updates the basic engagement profile for the sensor network to further reduce when temperature sensors are activated to acquire data (i.e., during daytime), and further reduces the subset of temperature sensors to the identified portion that will be activated to acquire temperature readings.

[0036] Sensor event coverage procedure 108 determines whether to initialize the participation profile for the sensor network (decision 214). In one embodiment, sensor event coverage procedure 108 uses the total iteration count of the machine learning process (e.g., one hundred iterations) to determine whether sufficient device sensor data has been received for each time point to establish the participation profile for the sensors in the sensor network. In another embodiment, sensor event coverage procedure 108 uses a stable iteration count for the machine learning process (e.g., ten iterations), where the stable iteration count represents the amount of data collected at each time point without an update to the participation profile. If sensor event coverage procedure 108 determines to initialize the participation profile for the sensor network (decision 214, "Yes" branch), sensor event coverage procedure 108 activates each sensor in the sensor network based on the participation profile (216). If sensor event coverage procedure 108 determines not to initialize the participation profile for the sensor network (decision 214, "No" branch), sensor event coverage procedure 108 performs another iteration of the machine learning process and returns to receiving additional data from each sensor in the sensor network at time (n+1) to further update the participation profile of the sensor network with the adjusted profile.

[0037] Sensor event coverage 108 activates each sensor in the sensor network (216) based on participation profiles. For each point in time, sensor event coverage 108 activates each sensor in the sensor network based on the participation profile, and similarly deactivates any sensor based on the participation profile. The participation profile spans various durations and depends on the intended use of the sensor network. In one example, sensor event coverage 108 activates and deactivates motion sensors associated with camera equipment in a retail location based on a seven-day participation profile, where the participation profile cycles continuously every seven days thereafter. In another example, sensor event coverage 108 activates and deactivates temperature sensors in a crop field based on participation profiles created for each day of the year, as seasonality and daily changes in solar energy patterns affect the activation of temperature sensors in the crop field.

[0038] Sensor event coverage procedure 108 updates the engagement profiles (218) for the sensor network. In one example, sensor event coverage procedure 108 activates and deactivates motion sensors associated with camera devices in a retail location based on a seven-day engagement profile, where the engagement profile is continuously cycled every seven days thereafter. As sensor event coverage procedure 108 utilizes the engagement profiles for motion sensors, it can continuously receive device sensor data from each active sensor to identify additional anomalies and movement patterns, further updating the engagement profile. This continuous machine learning process allows sensor event coverage procedure 108 to update engagement profiles for different times of the year, where different times of the year can influence how sensors in the sensor network are activated and deactivated to provide the required event coverage while maintaining energy conservation. In another example, sensor event coverage procedure 108 activates and deactivates temperature sensors in a crop field based on engagement profiles created for each day of the year, as seasonality and daily changes in solar energy patterns affect the activation of temperature sensors in the crop field. As the sensor event coverage program 108 utilizes the engagement profile for the temperature sensor, it can continuously receive device sensor data from each active sensor to identify additional anomalies and movement patterns, further updating the engagement profile. This continuous machine learning process allows the sensor event coverage program 108 to update the engagement profile for any newly introduced variables in the environment (i.e., the crop field), such as structures affecting solar patterns, which could influence the data acquired by the temperature sensor.

[0039] Figure 3AAn example of an activity participation pattern at time (n) of sensor network event coverage performed by a sensor event coverage procedure according to an embodiment of the present invention is shown. In this embodiment, sensor event coverage procedure 108 activates individual temperature sensors in the sensor network, wherein each temperature sensor is associated with an electronically controlled water valve in an activated irrigation system. If the temperature reading of the temperature sensor is at or above a threshold (e.g., X ≥ 25°C), the electronically controlled water valve associated with the temperature sensor opens to ensure that the soil in a portion of the crop field near the temperature sensor maintains a certain humidity level when the temperature reading is above the threshold. If the temperature reading of the temperature sensor is below the threshold (e.g., X < 25°C), the electronically controlled water valve associated with the temperature sensor closes. To ensure that the temperature sensors in the sensor network do not continuously consume power by acquiring data, sensor event coverage procedure 108 utilizes participation profiles to activate and deactivate the temperature sensors in the sensor network of the data value matrix 302. In this example, an activated temperature sensor is represented by "1", and an inactive temperature sensor is represented by "0". Through multiple iterations of the machine learning process, the sensor event coverage procedure 108 establishes participation profiles 304 for time (n), participation profiles 306 for time (n+1), and participation profiles 308 for time (n+2).

[0040] Sensor event coverage procedure 108 pre-identifies anomalies and movement patterns of temperature sensors in the sensor network. In this example, participating profiles 304, 306, and 308 each represent movement patterns of the sensor network, and data value matrix 302 represents a crop field, where each movement pattern is associated with a solar energy pattern on the crop field. At time (n) (e.g., 8 AM on June 1st), the edge of the solar energy pattern on the crop field is represented by participating profile 304, where temperature sensors located within the edge of the solar energy pattern represented by participating profile 304 are active, while temperature sensors located outside the edge of the solar energy pattern represented by participating profile 304 are inactive. The previously identified movement pattern sensor event coverage procedure 108 is associated with the solar energy pattern, where temperature sensors exposed to sunlight (directly or indirectly) experience a rapid increase in temperature readings. As a result, once covered by the solar energy pattern and exposed to solar rays, the temperature can rapidly exceed a threshold (e.g., 5 minutes) (e.g., X < 25°C). For the temperature sensor 310 located on the edge of the participating contour 304, the sensor event overlay procedure 108 takes into account the initialization and calibration cycle of the temperature sensor 310 (e.g., 30 seconds) and indicates that the temperature sensor 310 is active before being exposed to sunlight in solar mode.

[0041] Figure 3BAn example of an active participation pattern at time (n+50) for sensor network event coverage performed by a sensor event coverage procedure according to an embodiment of the present invention is shown. At time (n+50) (e.g., 12 PM on June 1st), the edge of the solar pattern on the crop field is represented by participation profile 306, wherein temperature sensors located within the edge of the solar pattern represented by participation profile 306 are active, and temperature sensors located outside the edge of the solar pattern represented by participation profile 306 are inactive. Although in Figure 3B It is not shown in the figure, but there are multiple participation profiles between time (n) and time (n+50), which provide a transition between participation profile 304 and participation profile 306.

[0042] Figure 3C An example of active participation patterns of sensor network event coverage by a sensor event coverage procedure for different seasons at time (n+100) according to an embodiment of the present invention is shown. At time (n+100) (e.g., 4 PM on June 1st), the edge of the solar pattern on the crop field is represented by participation profile 308, wherein temperature sensors located within the edge of the solar pattern represented by participation profile 308 are active, and temperature sensors located outside the edge of the solar pattern represented by participation profile 308 are inactive. It should be noted that a portion of the temperature sensors in the sensor network indicated as active by participation profiles 304 and 306 are no longer indicated as active by participation profile 308. Although in Figure 3C It is not shown in the figure, but there are multiple participation profiles between time (n+50) and time (n+100), which provide a transition between participation profile 306 and participation profile 308.

[0043] Figure 4 An example of an activity participation pattern at time (n) of sensor network event coverage in a sensor event coverage procedure according to an embodiment of the present invention is shown. Sensor event coverage procedure 108 utilizes participation profiles to activate and deactivate events from... Figures 3A-3C The data value matrix 302 is a temperature sensor in the sensor network, but at different times of the year, the solar mode and... Figures 3A-3CThe solar energy patterns differ. Activated temperature sensors are represented by "1", and inactive temperature sensors by "0". Through multiple iterations of the machine learning process, the sensor event coverage procedure 108 establishes participation profiles 402 for time (n), 404 for time (n+1), and 406 for time (n+2) at different times of the year. The sensor event coverage procedure 108 pre-identifies anomalies and movement patterns of temperature sensors in the sensor network. In this example, participation profiles 402, 404, and 406 each represent movement patterns of the sensor network, and the data value matrix 302 represents a crop field, where each movement pattern is associated with a solar energy pattern on the crop field.

[0044] At time (n) (e.g., 8 AM on October 1st), the edge of the solar pattern on the crop field is represented by participation profile 402, wherein temperature sensors located within the edge of the solar pattern represented by participation profile 402 are active, and temperature sensors located outside the edge of the solar pattern represented by participation profile 402 are inactive. At time (n+50) (e.g., 12 PM on October 1st), the edge of the solar pattern on the crop field is represented by participation profile 404, wherein temperature sensors located within the edge of the solar pattern represented by participation profile 404 are active, and temperature sensors located outside the edge of the solar pattern represented by participation profile 404 are inactive. At time (n+100) (e.g., 4 PM on October 1st), the edge of the solar pattern on the crop field is represented by participation profile 406, wherein temperature sensors located within the edge of the solar pattern represented by participation profile 406 are active, and temperature sensors located outside the edge of the solar pattern represented by participation profile 406 are inactive. The sensor event coverage procedure 108, which uses iterative machine learning, has the ability to identify movement patterns over time and accordingly establish profiles for each temperature sensor in the sensor network participating in the contours 304, 306, 308, 402, 404, and 406.

[0045] Figure 5A computer system is depicted, wherein server computer 102 is an example of a computer system that may include sensor event overlay program 108. The computer system includes processor 504, cache 516, memory 506, persistent storage device 508, communication unit 510, input / output (I / O) interfaces(s) 512, and communication structure 502. Communication structure 502 provides communication between cache 516, memory 506, persistent storage device 508, communication unit 510, and input / output (I / O) interfaces 512. Communication structure 502 can be implemented using any architecture designed to transfer data and / or control information between processors (such as microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, communication structure 502 can be implemented using one or more buses or crossbar switches.

[0046] Memory 506 and persistent storage device 508 are computer-readable storage media. In this embodiment, memory 506 includes random access memory (RAM). Typically, memory 506 may include any suitable volatile or non-volatile computer-readable storage medium. Cache 516 is a fast memory that enhances the performance of processor 504 by holding recently accessed data from memory 506 and data near the recently accessed data.

[0047] Program instructions and data used to practice embodiments of the present invention may be stored in persistent storage device 508 and memory 506 for execution by one or more corresponding processors 504 via cache 516. In embodiments, persistent storage device 508 includes a magnetic hard disk drive. As an alternative to or supplement to a magnetic hard disk drive, persistent storage device 508 may include a solid-state hard disk drive, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0048] The media used by the persistent storage device 508 can also be removable. For example, a removable hard disk drive can be used for the persistent storage device 508. Other examples include optical discs and disks, thumb drives, and smart cards, which are inserted into the drive for transfer to another computer-readable storage medium that is also part of the persistent storage device 508.

[0049] In these examples, communication unit 510 provides communication with other data processing systems or devices. In these examples, communication unit 510 includes one or more network interface cards. Communication unit 510 can provide communication by using one or both of physical and wireless communication links. Program instructions and data for practicing embodiments of the invention can be downloaded to permanent storage device 508 via communication unit 510.

[0050] Multiple I / O interfaces 512 allow data input and output to other devices that can be connected to each computer system. For example, I / O interfaces 512 can provide connectivity to external devices 518, such as keyboards, keypads, touchscreens, and / or other suitable input devices. External devices 518 may also include portable computer-readable storage media, such as thumb drives, portable optical discs or disks, and memory cards. Software and data used to practice embodiments of the invention can be stored on such portable computer-readable storage media and can be loaded onto persistent storage device 508 via the multiple I / O interfaces 512. The multiple I / O interfaces 512 are also connected to a display 520.

[0051] The display 520 provides a mechanism for displaying data to the user and can be, for example, a computer monitor.

[0052] It should be understood that although this disclosure includes a detailed description of cloud computing, the implementation of the teachings set forth herein is not limited to a cloud computing environment. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

[0053] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage devices, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with service providers. This cloud model may include at least five features, at least three service models, and at least four deployment models.

[0054] The features are as follows:

[0055] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring manual interaction with the service provider.

[0056] Wide Area Network (WAN) Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0057] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically allocated and reallocated based on demand. Location independence has significance because consumers typically do not control or know the exact location of the resources provided, but can specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0058] Rapid Flexibility: In some cases, the ability to scale outwards and inwards quickly and flexibly can be provided. For consumers, the available capacity often appears unlimited and can be purchased in any quantity at any time.

[0059] Measurement services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a level of abstraction appropriate to the service type (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both the providers and consumers of the services being utilized.

[0060] The service model is as follows:

[0061] Software as a Service (SaaS): The capability offered to consumers is the ability to use the provider's applications running on cloud infrastructure. Applications can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0062] Platform as a Service (PaaS): This provides consumers with the ability to deploy consumer-created or acquired applications onto cloud infrastructure using programming languages ​​and tools supported by the provider. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environments.

[0063] Infrastructure as a Service (IaaS): This provides consumers with the capability to offer processing, storage, networking, and other basic computing resources that enable consumers to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they have control over the operating system, storage, deployed applications, and possibly limited control over the selection of networking components (e.g., host firewalls).

[0064] The deployment model is as follows:

[0065] Private cloud: Cloud infrastructure operated solely by an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0066] Community cloud: Cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0067] Public cloud: Cloud infrastructure available to the general public or large industrial groups and owned by organizations that sell cloud services.

[0068] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported together (e.g., cloud bursting for load balancing between clouds).

[0069] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure of a network of interconnected nodes.

[0070] Now for reference Figure 6 The illustration depicts a cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 that can communicate with local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service, without requiring cloud consumers to maintain resources on their local computing devices. It should be understood that... Figure 6 The types of computing devices 54A-N shown are for illustrative purposes only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0071] Now for reference Figure 7 This demonstrates a cloud computing environment of 50 ( Figure 6 This provides a set of functional abstractions. It should be understood beforehand that... Figure 7 The components, layers, and functions shown are for illustrative purposes only, and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0072] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a host 61; a server 62 based on a RISC (Reduced Instruction Set Computer) architecture; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0073] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage device 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0074] In one example, management layer 80 may provide the following functionalities: Resource Provisioning 81 provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing 82 provides cost tracking when utilizing resources in the cloud computing environment, as well as billing or invoicing for consuming these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, and protection for data and other resources. User Portal 83 provides access to the cloud computing environment for consumers and system administrators. Service Level Management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service Level Agreement (SLA) Planning and Fulfillment 85 provides pre-scheduling and procurement of cloud resources, where future needs are anticipated according to the SLA.

[0075] Workload layer 90 provides examples of functionalities that can be leveraged in a cloud computing environment. Examples of workloads and functionalities that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and sensor event overlay procedures 108.

[0076] The programs described herein are identified based on applications that implement them in specific embodiments of the invention. However, it should be understood that any particular program terminology used herein is for convenience only, and therefore the invention should not be limited to use only in any particular application identified and / or implied by such terminology.

[0077] This invention can be a system, method, and / or computer program product. A computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0078] Computer-readable storage media can be any tangible device capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures with instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0079] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or via a network, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network, to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device.

[0080] Computer-readable program instructions for performing the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as Smalltalk, C++, etc.) and conventional procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from the computer-readable program instructions.

[0081] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0082] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other devices to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0083] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions, which execute on the computer, other programmable apparatus or other device, perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0085] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the invention. The terminology used herein is chosen to best explain the principles of the embodiments, their practical application, or improvements to existing technologies on the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for sensor event coverage, comprising: One or more processors receive device sensor data for multiple sensors in a sensor network; One or more processors identify one or more anomalies in the sensor data of the device, the one or more anomalies indicating that one or more sensors from the plurality of sensors acquired data during an event at a specific point in time; One or more processors identify movement patterns for the plurality of sensors based on the one or more anomalies; as well as In response to updating the basic engagement profile for the plurality of sensors based on the one or more anomalies and the movement mode, a first sensor from the plurality of sensors is activated by one or more processors based on the updated basic engagement profile; The basic engagement profile is determined based on a time-based activation schedule and user-defined activation preferences from each of the plurality of sensors. The method further includes: displaying a data matrix of the plurality of sensors representing an event coverage area by one or more processors, wherein a first participation profile from the updated basic participation profile is overlaid on the data matrix and includes the first sensor from the plurality of sensors.

2. The method according to claim 1, further comprising: One or more processors use the total iteration count of the machine learning process to determine whether to initialize the engagement profile for updates to the sensor network, in order to determine whether sufficient device sensor data has been received for the plurality of sensors at each time point; as well as In response to determining that the total iteration count has been reached, one or more processors initialize the participation profiles for the updates of the plurality of sensors in the sensor network.

3. The method according to claim 1, further comprising: One or more processors use a stable iteration count of the machine learning process to determine whether to initialize the engagement profile for the update of the sensor network, wherein the stable iteration count represents the number of instances in which the device sensor data is received without any additional updates to the basic engagement profile of the update; as well as In response to determining that the stable iteration count has been reached, one or more processors initialize the participation profiles for the updates of the plurality of sensors in the sensor network.

4. The method of claim 1, wherein the device sensor data for the plurality of sensors in the sensor network includes data selected from the group consisting of: acquired sensor readings, activation indications, operating states, timestamps of acquired sensor readings, and locations of acquired sensor readings.

5. The method of claim 4, wherein the movement mode represents an instance of activation of one or more of the plurality of sensors.

6. A computer program product, comprising: Program instructions stored on at least one of one or more storage media, the program instructions comprising: Program instructions for receiving device sensor data from multiple sensors in a sensor network; Program instructions for identifying one or more anomalies in the sensor data of the device; Program instructions for identifying movement patterns for the plurality of sensors based on the one or more anomalies; and Program instructions for responding to updating the basic engagement profile for the plurality of sensors based on the one or more anomalies and the movement pattern, and activating a first sensor from the plurality of sensors based on the updated basic engagement profile; The basic engagement profile is determined based on a time-based activation schedule and user-defined activation preferences from each of the plurality of sensors. The program instructions further include program instructions for displaying a data matrix of the plurality of sensors representing the event coverage area, wherein a first participation profile from the updated basic participation profile is overlaid on the data matrix and includes the first sensor from the plurality of sensors.

7. The computer program product of claim 6, further comprising program instructions stored on the one or more storage media, the program instructions causing the processor, when executed by the processor, to: Determine whether to use the total iteration count of the machine learning process to initialize the participation profile for updates to the sensor network, in order to determine whether sufficient device sensor data has been received for the plurality of sensors at each time point; and In response to determining that the total iteration count has been reached, the participation profile for the updates of the plurality of sensors in the sensor network is initialized.

8. The computer program product of claim 6, further comprising program instructions stored on the one or more storage media, the program instructions causing the processor, when executed by the processor, to: Determine whether to utilize a stable iteration count of the machine learning process to initialize the engagement profile for the updated sensor network, wherein the stable iteration count represents the number of instances in which device sensor data is received without additional updates to the basic engagement profile of the updated data; and In response to determining that the stable iteration count has been reached, the participation profile for the update of the plurality of sensors in the sensor network is initialized.

9. The computer program product of claim 6, wherein the device sensor data for the plurality of sensors in the sensor network includes data selected from the group consisting of: acquired sensor readings, activation indications, operating states, timestamps of acquired sensor readings, and locations of acquired sensor readings.

10. The computer program product of claim 9, wherein the movement mode represents an instance of activation of one or more of the plurality of sensors.

11. A computer system, comprising: One or more computer processors; One or more computer-readable storage media; as well as Program instructions, stored on the computer-readable storage medium for execution by at least one of the one or more computer processors, the program instructions comprising: Program instructions for receiving device sensor data from multiple sensors in a sensor network; Program instructions for identifying one or more anomalies in the sensor data of the device; Program instructions for identifying movement patterns for the plurality of sensors based on the one or more anomalies; and Program instructions for responding to updating the basic engagement profile for the plurality of sensors based on the one or more anomalies and the movement pattern, and for activating a first sensor from the plurality of sensors based on the updated basic engagement profile; The basic engagement profile is determined based on a time-based activation schedule and user-defined activation preferences from each of the plurality of sensors. The program instructions further include program instructions for displaying a data matrix of the plurality of sensors representing the event coverage area, wherein a first participation profile from the updated basic participation profile is overlaid on the data matrix and includes the first sensor from the plurality of sensors.

12. The computer system of claim 11, further comprising program instructions stored on the one or more computer-readable storage media, the program instructions causing the processor, when executed by the processor, to: Determine whether to use the total iteration count of the machine learning process to initialize the participation profile for the update of the sensor network, in order to determine whether sufficient device sensor data has been received for the plurality of sensors at each time point; and In response to determining that the total iteration count has been reached, the participation profile for the updates of the plurality of sensors in the sensor network is initialized.

13. The computer system of claim 11, further comprising program instructions stored on the one or more computer-readable storage media, the program instructions causing the processor, when executed by the processor, to: Determine whether to utilize a stable iteration count of the machine learning process to initialize the engagement profile for the updated sensor network, wherein the stable iteration count represents the number of instances in which device sensor data is received without additional updates to the basic engagement profile of the updated data; and In response to determining that the stable iteration count has been reached, the participation profile for the update of the plurality of sensors in the sensor network is initialized.

14. The computer system of claim 11, wherein the device sensor data of the plurality of sensors in the sensor network includes data selected from the group consisting of: acquired sensor readings, activation indications, operating states, timestamps of acquired sensor readings, and locations of acquired sensor readings.

Images