Distributed sensor network

Distributed sensing is provided. A first node of a plurality of nodes receives a fire status message from a second node of the plurality of nodes. The fire status message indicates a determination by the second node that an environmental condition exceeds a predetermined threshold. Each node of the plurality of nodes is a computing device. The first node estimates an arrival time of a fire based, at least in part, on the fire status message and a geographic location of the second node. The arrival time is a time until the fire arrives at a predetermined geographic location.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of network communications and, more particularly, to a distributed sensor network.

A smoke detector is a device that senses smoke, typically as an indicator of fire. Most smoke detectors work either by optical detection (photoelectric) or by physical process (ionization), while others use both detection methods to increase sensitivity to smoke. Commercial and residential security devices issue a signal to a fire alarm control panel as part of a fire alarm system, while household detectors, known as smoke alarms, generally issue a local audible or visual alarm from the detector itself.

A wildfire is a fire in an area of combustible vegetation that occurs in the countryside or a wilderness area. A wildfire is often uncontrolled. A wildfire differs from other fires by its extensive size, the speed at which it can spread out from its original source, its potential to change direction unexpectedly, and its ability to jump gaps such as roads, rivers and fire breaks. Wildfires are characterized in terms of the cause of ignition, their physical properties such as speed of progression, the combustible material present, and the effect of weather on the fire.

SUMMARY

According to one embodiment of the present disclosure, a method for distributed sensing is provided. The method includes a first node of a plurality of nodes receiving a fire status message from a second node of the plurality of nodes, wherein the fire status message indicates a determination by the second node that an environmental condition exceeds a predetermined threshold, and wherein each node of the plurality of nodes is a computing device; and estimating, by the first node, an arrival time of a fire based, at least in part, on the fire status message and a geographic location of the second node, wherein the arrival time is a time until the fire arrives at a predetermined geographic location.

According to another embodiment of the present disclosure, a computer program product for distributed sensing is provided. The computer program product comprises a computer readable storage medium and program instructions stored on the computer readable storage medium. The program instructions include program instructions to receive a fire status message at a first node of a plurality of nodes from a second node of the plurality of nodes, wherein the fire status message indicates a determination by the second node that an environmental condition exceeds a predetermined threshold; and program instructions to estimate an arrival time of a fire based, at least in part, on the fire status message and a geographic location of the second node, wherein the arrival time is a time until the fire arrives at a predetermined geographic location.

According to another embodiment of the present disclosure, a computer system for distributed sensing is provided. The computer system includes one or more computer processors, one or more computer readable storage media, and program instructions stored on the computer readable storage media for execution by at least one of the one or more processors. The program instructions include program instructions to receive a fire status message at a first node of a plurality of nodes from a second node of the plurality of nodes, wherein the fire status message indicates a determination by the second node that an environmental condition exceeds a predetermined threshold; and program instructions to estimate an arrival time of a fire based, at least in part, on the fire status message and a geographic location of the second node, wherein the arrival time is a time until the fire arrives at a predetermined geographic location.

DETAILED DESCRIPTION

Embodiments of the present invention recognize that tracking the progress of a fire is difficult but is important for public safety. Embodiments of the present invention provide for a distributed sensor network. Some embodiments provide a distributed sensor network for tracking the progress of a fire, such as a wildfire.

In one example, a distributed sensor network includes a plurality of nodes that each monitor environmental conditions. In response to detecting certain conditions (e.g., smoke or fire), a node transmits a fire status message to communications addresses of a notification list of the node, such as to one or more other nodes of the distributed sensor network. Based on the fire status message and locations of one or more other nodes, a node estimates a fire arrival time at a given location, which may be a geographical location where the node is located or another geographical location. The geographical location may be a plurality of geographical locations along an evacuation route. The node may issue a notification to one or more communications addresses of the notification list (e.g., a communications address of a device of a user) that identifies one or both of a fire arrival time and an evacuation route.

The present disclosure will now be described in detail with reference to the Figures.FIG. 1is a functional block diagram illustrating a computing environment, in accordance with an embodiment of the present disclosure. For example,FIG. 1is a functional block diagram illustrating computing environment100. Computing environment100includes distributed sensor network140and registration server130connected over network120. Distributed sensor network140includes node102aand node102b(collectively, node102). In various embodiments, distributed sensor network140includes a fewer or greater number of nodes than depicted inFIG. 1. Each of node102includes an instance of application104, sensor array106, communications unit108, and user interface110. In one embodiment, distributed sensor network140is a network of nodes that is communicably interconnected with network120. In another embodiment, distributed sensor network140is a plurality of nodes (e.g., node102) that are in communication with one another and that are connected to network120. In this case, each node102is connected to each other (and to registration server130) over network120. In one embodiment, distributed sensor network140is implemented with full or partial mesh network connectivity. For example, node102aconnects to node102b, which replays messages between node102aand server130via network120.

In various embodiments, each node102is a computing device that can be a standalone device, a server, a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a personal digital assistant (PDA), a smartphone, a desktop computer, or any other programmable electronic device. In another embodiment, each node102represents a computing system utilizing clustered computers and components to act as a single pool of seamless resources. In general, each node102can be any computing device or a combination of devices with access to registration program132and sensor array106and capable of executing application104. Each node102may include internal and external hardware components, as depicted and described in further detail with respect toFIG. 6.

In some embodiments, one or more node of node102is implemented in conjunction with a portable power supply (e.g., a battery or a solar panel), thereby facilitating deployment of the node in remote locations. In some embodiments, one or more node of node102is heterogeneous with respect to another of node102. For example, one node102may be a smartphone that includes many capabilities in addition to those described herein, while another node102is a standalone device that is optimized to perform the capabilities described herein, while yet another node102is a PC.

In this exemplary embodiment, an instance of application104is stored on one or more nodes of node102, and registration program132is stored on registration server130. In other embodiments, one or both of application104and registration program132may reside on another computing device of computing environment100, provided that each can access and is accessible by each other. In yet other embodiments, one or both of application104and registration program132may be stored externally and accessed through a communication network, such as network120. Network120(or, e.g., distributed sensor network140) can be, for example, a local area network (LAN), a wide area network (WAN) such as the Internet, or a combination of the two, and may include wired, wireless, fiber optic or any other connection known in the art. In general, network120can be any combination of connections and protocols that will support communications between or among nodes of distributed sensor network140and between each node and registration server130, in accordance with a desired embodiment of the present invention. In general, distributed sensor network140can be any combination of connections and protocols that will support communications between and among nodes of distributed sensor network140, in accordance with a desired embodiment of the present invention. In one embodiment, network120is a cellular phone network. For example, one or more nodes of distributed sensor network140communicate with one another via network120using short message service (SMS) messages. In another embodiment, network120includes one or more pre-existing network infrastructures (e.g., a cellular phone network, 802.11 wireless infrastructure).

Application104operates to detect an alarm condition. In one embodiment, application104monitors data from sensor array106, based on which application104determines whether an alarm condition exists. In one embodiment, distributed sensor network140includes a plurality of nodes, in which case each node102includes an instance of application104, each of which has the capabilities described herein in connection with application104. In one embodiment, application104communicates with registration program132. In another embodiment, a first instance of application104(e.g., of node102a) communicates with a second instance of application104(e.g., of node102b). In one embodiment, an instance of application104(e.g., application104a) receives a signal (e.g., from sensor array106a, application104b, or sensor array106b). For example, the signal indicates one or both of the existence of or proximity (i.e., distance relative to the node generating the signal) of a fire (or an edge of a fire). In one embodiment, application104forwards a received signal (e.g., to another node). In one embodiment, application104forecasts an arrival time of a fire. In one embodiment, application104determines that an arrival time is below a threshold and application104issues a fire status message. In one embodiment, application104determines that a status signal time has expired and application104generates a node destruction notification.

In one embodiment, application104forecasts a fire arrival time relative to a geographical location associated with node102. The geographical location may be the location of node102, one or more locations other than the geographical location of node102, or a combination thereof. The one or more locations may be collectively referred to herein as the location to monitor. In one embodiment, application104forecasts a fire arrival time for each location to monitor and, in response to determining that the fire arrival time for at least one location to monitor is below a threshold, application104issues fire status messages (see, e.g.,FIGS. 2-6and the accompanying descriptions) for the location to monitor. The location to monitor may include one or more geographical locations along an evacuation route.

In some embodiments, application104operates on a central server (e.g., registration server130), in which case one or more nodes of distributed sensor network140may lack some or all of the capabilities described herein in connection with application104, as those capabilities are instead performed by application104operating on the central server or on other nodes of distributed sensor network140. For example, node102may be a computing device that excludes application104and forwards data from sensory array106to registration server130, which executes an instance of application104.

Registration program132operates to register node102. In one embodiment, registration program132operates to maintain a network (e.g., distributed sensor network140) of at least one node (e.g., node102). Registration program132determines a geographical location of node102. Registration program132registers node102with distributed sensor network140. Registration program132identifies, for node102, one or more other nodes adjacent to node102. Registration program132determines a notification list for node102. Registration program132monitors for alert signals.

Sensor array106is a device that provides data input. In one embodiment, sensor array106generates the data input by measuring environmental conditions. In various examples, sensor array106includes one or more of a smoke detector, thermometer, a light sensor or optical detector (e.g., a camera or any other photoreceptor operating in, for example, the infrared, visible, or other light spectrum), radar, lidar, a global positioning system (GPS) sensor, a proximity sensor, an audio sensor (i.e., a microphone), a gas (e.g., carbon monoxide) sensor, or a time-keeping device. In one embodiment, sensor array106detects and receives user input and, in response, provides data input. In one embodiment, sensor array106provides data input to internal storage of node102(seeFIG. 4and accompanying discussion). In various embodiments, sensor array106provides data input to one or more of application104, communications unit108, user interface110, registration program132, and registration data134.

Communications unit108is a device through which application104communicates. In one embodiment, communications unit108communicably connects node102to network120, distributed sensor network140, another node of distributed sensor network140, or any combination thereof. For example, communications unit108may be a network communications device (e.g., a network interface controller) that connects node102to network120, via which application104communicates with registration program132. In one embodiment, application104receives data from sensor array106and sends the data to registration server130via communications unit108. In one embodiment, communications unit108is a cellular transceiver.

User interface110is an interface that provides information (e.g., to a user). In one embodiment, user interface110receives input from a user via user interactions with user interface110. In one embodiment, user interface110provides alert information (e.g., a fire status message, a fire arrival time, or an evacuation recommendation). In one embodiment, one of more nodes of distributed sensor network104are implemented without user interface110. For example, node102receives data representing user input from another computing device (e.g., via network120). In another example, node102operates without user input. In another embodiment, user interface110is a device for producing a human-perceptible alarm signal (e.g., an audible, visual, or tactile alarm signal, or any combination thereof). For example, application104may issue a fire status message (seeFIGS. 2-6and accompanying discussion) by causing user interface110to produce an alarm sound and vibration.

User device150is a computing device of a user. In one embodiment, user device150is a node of distributed sensor network140. For example, user device150may include an instance of application104, sensor array106(e.g., a GPS sensor), communications unit108(e.g., a cellular transceiver), and user interface110(that presents information via, for example, display620as depicted inFIG. 6). In another embodiment, user device150is a device in communication with at least one node102, registration server130, or a combination thereof. For device150is a mobile communications device (e.g., a cellular phone) that is communicatively connected to distributed sensor network140via network120. User device150has a communications address (e.g., a phone number) that may be included on the notification list of one or more nodes102. In various embodiments, user device150may receive communications such as audio, SMS, or MMS from at least one node102and may present the received communication to a user of user device150. In various embodiments, user device150is a computing device that can be a standalone device, a server, a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a personal digital assistant (PDA), a smartphone, a desktop computer, or any other programmable electronic device. In another embodiment, user device150represents a computing system utilizing clustered computers and components to act as a single pool of seamless resources. In general, user device150can be any computing device or a combination of devices with access to distributed sensor network140. User device150may include internal and external hardware components, as depicted and described in further detail with respect toFIG. 6.

In various embodiments, registration server130is a computing device that can be a standalone device, a server, a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a personal digital assistant (PDA), a smartphone, a desktop computer, or any other programmable electronic device. In another embodiment, registration server130represents a computing system utilizing clustered computers and components to act as a single pool of seamless resources. In general, registration server130can be any computing device or a combination of devices with access to registration data134and each node102and capable of executing registration program132. Registration server130may include internal and external hardware components, as depicted and described in further detail with respect toFIG. 6.

Registration data134is a data repository that may be written to and read by one or both of registration program132and application104. Node details may be stored to registration data134. In one embodiment, node details include information pertaining to node102. For example, node details of node102include an identifier and a geographical location of node102. In one embodiment, the node details of node102include one or more other locations associated with node102. For example, the other locations may be waypoints of an evacuation route or may be other points of interest. In some embodiments, registration data134may be written to and read by programs and entities outside of computing environment100, for example to populate the repository with node details.

In some embodiments, registration data134stores one or more evacuation routes for each registered node. Each evacuation route includes one or more waypoints, which are geographical locations along a travel route from a starting point to a destination. In one embodiment, the starting point is a location of node102. In another embodiment, the starting point is a geographical location other than the location of node102. In one example, the starting point is the current location of a user. In another example, the starting point is a location associated with the user (e.g., a location of a home of the user). The destination is a geographical location such as, for example, a shelter, an evacuation zone, a roadway, or other location. In one embodiment, some or all of the starting point, destination, and each waypoint is user-configured, pre-determined, or algorithmically determined. For example, a user provides (e.g., via user device150) a starting point and a destination, and the waypoints are algorithmically determined based, at least in part, on maps of roads and other paths of travel. In one such embodiment, application104determines a fire arrival time for each waypoint of each evacuation route of a node. In response to determining that the fire arrival time for a waypoint of a first evacuation route is below a threshold, application104determines that the first evacuation route is unsafe. In response to determining that no evacuation routes are safe, application104issues an alert to user device150that notifies the user to seek shelter. In one embodiment, application104issues an evacuation recommendation (e.g., to user device150) that identifies one or more evacuation routes. For example, an evacuation recommendation identifies all evacuation routes that are safe. SeeFIG. 5for additional details.

FIG. 2is a flowchart depicting operations for distributed sensing, on a computing device within the computing environment ofFIG. 1, in accordance with an embodiment of the present disclosure. For example,FIG. 2is a flowchart depicting operations200of an instance of registration program132operating on registration server130within computing environment100.

In operation202, registration program132determines a geographical location to monitor. In one embodiment, registration program132receives the location to monitor from application104. In one embodiment, the location to monitor is the location of node102. In one example, application104receives data from sensor array106that indicates a geographical location (e.g., GPS coordinates) of the node102. In another example, application104receives a location of node102as user input (e.g., via user interface110). In yet another example, application104receives a location of node102from another node (e.g., from another instance of application104operating on another computer device). In another embodiment, registration program132determines the location of node102. For example, registration program132triangulates the location of node102based on communications with other nodes (or, alternatively, with infrastructure of network120). In another example, registration program132determines the location of node102utilizing geofencing to identify a geographical region that includes the location of node102. In another example, network120includes communications devices with known locations and communications ranges (e.g., radio towers, wireless networking devices, or other nodes) and registration program132determines the location of node102based on which communications device(s) are in communication with node102.

In one embodiment, the location to monitor is a location of interest to a user, which may be different from the location of node102. For example, node102bis a user device (e.g., a smartphone) and, based on input from a user, node102bprovides registration program132with a location of interest to the user, such as a street address of a house at which no nodes102are located. In response, registration program132determines the location to monitor based on the location provided by node102b, which may be different from the geographical location of node102b. In this example, the user uses node102bto monitor a location remote other than the location of node102bby node102bcommunicating with other nodes of distributed sensor network140. In various embodiments, there are zero or more nodes located at the location to monitor. In one example, the location to monitor is the location of a node. In another example, the location to monitor is a location within sensor range of one or more nodes, other than the location of a node.

In operation204, registration program132registers a node with distributed sensor network140. In one embodiment, registration program132registers node102with distributed sensor network140by storing node details of node102to registration data134. For example, application104sends node details of node102to registration program132, which stores the node details (e.g., location, communications address) to registration data134, thereby registering node102with distributed sensor network140.

In operation206, registration program132identifies one or more adjacent nodes. The adjacent nodes for a node (e.g., node102a) include one or more other nodes (e.g., node102b) that are registered with distributed sensor network140and that are within a predetermined geographical proximity to the location to monitor. In one embodiment, registration program132identifies one or more adjacent nodes based on node details stored in registration data134. For example, registration program132receives data from registration data134identifying one or more nodes that are registered with distributed sensor network140, based upon which registration program132determines one or more nodes that are adjacent to a the location to monitor. In another embodiment, application104identifies the one or more adjacent nodes. For example, application104identifies one or more adjacent nodes based on geographical locations received from the one or more adjacent nodes. In one embodiment, one or both of registration program132or application104can discover nodes of distributed sensor network140using a network discovery protocol.

In another embodiment, application104of a first node (e.g., node102) broadcasts a packet that requests geographical locations. In response to receiving such a packet, application104of a second node (e.g., node102b) unicasts to the first node (e.g., node102a) a packet identifying the geographical location of the second node (e.g., node102b). In various embodiments, a node discovers other nodes of distributed sensor network140utilizing a central server (e.g., registration server130); geofencing; SMS messaging, multicasting, or broadcasting; a wireless network; node-to-node radio communications; near-field communication, or any combination thereof. In one embodiment, node102communicates (e.g., via network120) with one or more other nodes using registration server130as an intermediary. In another embodiment, node102communicates (e.g., via network120) with one or more other nodes directly (i.e., without using registration server130as an intermediary). In one embodiment, distributed sensor network140is implemented without registration server130. For example, distributed sensor network140is a decentralized peer-to-peer network.

In one embodiment, the one or more adjacent nodes include a predetermined number of nodes that are geographically nearest to the location to monitor. In another embodiment, the one or more adjacent nodes include those nodes that are within a predetermined geographical proximity to the location to monitor. In some embodiments, the geographical distance differs based on a geographical distribution of the nodes in various directions relative to the location to monitor. For example, the location to monitor is a location of a first node and the one or more nodes adjacent to a first node include those nodes within ten miles north of the first node and within five miles south of the first node. In another embodiment, the one or more adjacent nodes include all nodes within direct communication range in the area surrounding the location to monitor. For example, where nodes of distributed sensor network140communicate via radio transceivers, the one or more adjacent nodes include those nodes within range to transmit and receive radio transmissions to one another. In another embodiment, the one or more adjacent nodes include all nodes of the distributed sensor network140. In another embodiment, the one or more adjacent nodes include an arbitrary selection of nodes.

In some embodiments, the one or more adjacent nodes include a number of nodes based, at least in part, on features of the geography surrounding the location to monitor. Such embodiments recognize that certain terrain or geographic features affect the speed at which fires spread. For example, a wildfire may spread faster across dry grasslands than across a river or highway. In one such embodiment, the one or more adjacent nodes include a count of nodes in each direction of the location to monitor, where each count is positively correlated with the speed at which fire spreads across the geographical features in that direction. For example, the one or more adjacent nodes include all nodes within ten miles north and within five miles south of the location to monitor, where fire spreads more slowly across the terrain to the south of the location to monitor. In some such embodiments, application104(or, in another embodiment, registration program132) determines geographic features adjacent to the location to monitor based on mapping data including, for example, topography, vegetation, weather, climate, wind patterns, transportation routes (e.g., roadways, rail lines, and highways), and bodies of water (e.g., rivers and lakes). In some such embodiments, the mapping data includes current or prior fire-fighting efforts (e.g., deployments of fire retardant or fire breaks).

In some embodiments, the nodes in the one or more adjacent nodes changes over time. In various embodiments, nodes can come online, go offline, or relocate. In another embodiment, the criteria by which registration program132(or application104) determines the one or more adjacent nodes can change. For example, registration program132(or application104) may receive updated mapping data. In another example, registration program132(or application104) determines the one or more adjacent nodes based upon a radius from the location to monitor and registration program132(or application104) may receive user input (e.g., via user interface110) changing the radius, in response to which registration program132(or application104) re-determines the one or more adjacent nodes. In one such embodiment, registration program132updates the one or more adjacent nodes of the location to monitor in response to registering a new node that is adjacent to the location to monitor. For example, registration program132determines that a new node is adjacent to the location to monitor and, in response, registration program132(or, application104) adds the new node to the one or more adjacent nodes for the location to monitor.

In some embodiments, node102stores a state for each of the one or more adjacent nodes of node102. For example, a state of a node may be one of: safe, smoke, fire, or offline. In this case, a safe state indicates that the node is online and has not reported any abnormalities. A smoke state indicates that the node has detected smoke and may no longer be online. A fire state indicates that the device has reported fire conditions (e.g., temperature above a pre-determined threshold) and may no longer be online. In one such embodiment, a fire status message may identify a state of a node. In response to receiving a fire status message that identifies a state of a node, application104updates the status for the node with the state identified by the fire status message. In some embodiments, node102also stores a status for each evacuation route of node102based on a status of each waypoint of the evacuation route. In one such embodiment, the status for an evacuation route is the highest level of alert of any waypoint of the evacuation route, where fire is a higher level of alert than smoke, which is a higher level of alert than safe. In one embodiment, a fire status message includes a timestamp, which identifies a time. In various examples, the timestamp of a fire status message issued by a node identifies the time at which the node generated the fire status message, the time at which the node issues the fire status message, or the time at which the node detects fire conditions (e.g., the time at which the node determines than an ambient temperature exceeds a predetermined threshold).

In operation208, registration program132(or application104) determines a notification list. The notification list includes one or more communications addresses to which registration program132(or application104) can issue notifications. In various embodiments, registration program132(or application104) can issue a notification to an adjacent node via a network address (of network120) of the adjacent node, to a phone number via an audible pre-recorded message, to a phone number via a message service such as SMS or multimedia message service (MMS), or to registration program132via network120. In one embodiment, registration program132(or application104) determines the notification list based, at least in part, on one or more of the following: a network address of each of the one or more adjacent nodes, user input (e.g., provided by a user via user interface110) identifying one or more phone numbers, email addresses, or other communications addresses, and a network address of registration server130or other computing device executing registration program132. In one embodiment, the notification list includes a communications address for emergency services (e.g., police, fire department, or forest service).

In some embodiments, the notification list includes one or more records, each of which identifies <address, type, format>, where address is a communications address, type is a type of the communications address, and format is a format of a communication to send to the communications address. In various examples, the type of a communications address may be a phone number, email address, or a network address. In one such embodiment, registration program132(or application104) determines which medium by which to issue a notification to a communications address based on the type of the communications address. For example, a record may identify <123.123.123.123, network address, adjacent node>, which identifies 123.123.123.123 as a network address for an adjacent node. In this example, “adjacent node” identifies a format compatible with the adjacent node. In another example, a record may identify <123-456-7890, phone number, voice>, which identifies 123-456-7890 as a phone number that receives voice communications. In yet another example, a record may identify <098-765-4321, phone number, SMS>, which identifies 098-765-4321 as a phone number that receives SMS message communications.

In operation210, registration program132monitors for alert signals. In one embodiment, alert signals include fire status messages or destruction alerts. For example, application104determines that an arrival time of a fire is below a threshold (see decision306, discussed further below) and, in response, issues a fire status message (see operation308, discussed further below). In this example, application104issues the fire status message by sending the fire status message to registration program132. In response to receiving the fire status message from application104, registration program132sends the fire status message notification to each communications address on the notification list in this example. In another example, application104sends the fire status message notification to each communications address on the notification list of node102. In one embodiment, registration program132logs alerts signals received by registration server130. In another embodiment, registration program132receives a destruction alert identifying a destroyed node of distributed sensor network140. In response, registration program132de-registers the destroyed node by removing the registration information for the destroyed node from registration data134. In yet another embodiment, registration program132(or, alternatively, application104of various nodes) updates the one or more adjacent nodes of any node that had included the destroyed node as an adjacent node to remove the destroyed node as an adjacent node.

FIG. 3is a flowchart depicting operations for distributed sensing, on a computing device within the computing environment ofFIG. 1, in accordance with an embodiment of the present disclosure. For example,FIG. 3is a flowchart depicting operations300of application104operating on node102within computing environment100.

In operation302, application104monitors sensor array106. In one embodiment, application104monitors the input data as described above in connection with operation210. Application104monitors sensor array106by receiving data from sensor array106. In one embodiment, sensor array106detects environmental conditions in the proximity of node102, such as temperature, wind speed, and the level of certain gasses (e.g., carbon dioxide, carbon monoxide). In one embodiment, application104receives and monitors data reflecting the conditions detected by sensor array106.

In some embodiments, application104monitoring sensor array106includes node102operating in an adaptive sleep cycle. In one embodiment, during the adaptive sleep cycle, application104alternates between a normal state and a low-power state. In this embodiment, in the normal state, application104continuously monitors sensor array106by continually receiving data from sensor array106. In the low-power state, node102monitors the sensor array106by receiving data from sensor array106periodically and reducing power to certain components (e.g., sensor array106) at other times. In one such embodiment, the length of the period is based, at least in part, on an ambient temperature (i.e., the temperature in the immediate vicinity of node102).

Thus, in this embodiment, application104monitoring sensor array106includes monitoring the data from sensor array106more frequently in response to the ambient temperature being higher than a pre-determined threshold value. For example, application104determines a frequency of twenty minutes if the ambient temperature is below 30° C., five minutes if ambient temperature is at least 30° C. but below 60° C., two minutes if temperature is at least 60° C. but below 80° C., and once second if the temperature is above 80° C. In another embodiment, application104deactivates the adaptive sleep cycle if the temperature reaches a pre-determined threshold value (e.g., 80° C.), in which case application104monitors sensor array106continuously.

In operation304, application104forecasts a fire arrival time. A fire arrival time is an estimated time until a fire arrives at a location to monitor (e.g., the location of node102). In one embodiment, application104forecasts a fire arrival time in response to detecting the presence of a fire. For example, application104forecasts a fire arrival time for the location to monitor in response to determining the presence of a fire based on data from sensor array106. In another example, application104forecasts a fire arrival time in response to receiving a fire status message from an adjacent node. In another embodiment, application104forecasts a fire arrival time regardless of whether application104detects a fire. For example, if application104does not detect a fire, then application104forecasts a fire arrival time based on the distance between the location to monitor and the nearest edge of the graphical region monitored by distributed sensor network140.

Alternatively, if application104does not detect a fire, then application104forecasts a fire arrival time by determining a fire risk based, at least in part, on data of sensor array106. For example, application104determines a higher fire risk when the data from sensor array106indicates environmental conditions that are hot, dry, and windy than when the data indicates environmental conditions are cool, damp, and calm. In one embodiment, application104forecasts a fire arrival time based, at least in part, on pre-determined weighting factors for each type of data from sensor array106and pre-determined tables correlating such values with speeds at which a fire spreads. In another embodiment, application104forecasts a fire arrival time by detecting the position of an edge of a fire at two points in time and determining the speed at which the edge of fire is approaching the location to monitor as the distance traveled by the edge of the fire at each point in time divided by the time elapsed between the two points in time.

In some embodiments, application104provides some or all of the data from sensor array106to one or both of an adjacent node and registration server130. In some embodiments, application104provides one or both of the fire arrival time and the determined fire risk to one or both of an adjacent node and registration server130. In some embodiments, application104makes a determination based on data of sensor array106and includes data of sensor arrays of one or more other (e.g., adjacent) nodes. For example, a first node determines a fire risk based on data received from sensor array106of the first node and also from sensor array106from one or more one or more adjacent nodes. In another example, a first node forecasts a fire arrival time based on fire status messages received from a second node and a third node and further based on the geographical positions of the first node, second node and third node.

In some embodiments, application104determines a shape of an edge of a fire. In one such embodiment, application104sends information indicating the shape of the edge of the fire to registration server130. In one embodiment, application104determines a degree to which node102is surrounded by the fire. In this embodiment, sensor array106has a field of view, which is the range of directions in which sensor array106detects data. Based upon the data from sensor array106, application104determines in which directions the fire exists. For example, the field of view of sensor array106spans two hundred seventy degrees, from due south (i.e., 180°) through due west and due north to due east (i.e., 90°). Based upon the data across this field of view, application104determines that a fire exists from 280° to 330°. In one embodiment, application104also determines that sensor array106provides insufficient data to determine whether a fire exists in the ninety degree range from due east through south-east to due south. In another embodiment, application104determines a shape of an edge of a fire by determining a distance between node102and various points along the edge of the fire. For example, application104determines that a portion of the fire at 280° is half a mile away and that a portion of the fire at 315° is one mile away. In yet another embodiment, application104determines one or both of a shape of an edge of a fire or a degree to which node102is surrounded based on fire status messages from one or more adjacent nodes. For example, application104determines that a fire exists to the west of node102based on application104receiving a fire status message from an adjacent node to the west.

In some embodiments, application104determines a confidence score. The confidence score represents the strength of a determination. In one such embodiment, application104forecasting a fire arrival time includes application104determining a confidence score. In one such embodiment, application104determines a confidence score by sending a fire confirmation request to another node. For example, application104of a first node, based on input received from sensor array106of the first node, detects environmental conditions, such as an ambient temperature of 70° C. and other data (camera imagery, gas concentrations, etc.), that indicate the probable existence of a fire in an identified location. In this case, application104of the first node sends a fire confirmation request to a second node that is within sensory range (based on sensor array106of the second node) to the identified location. In this example, application104of the second node, based upon data received from sensory array106of the second node, detects environmental conditions consistent with a fire. In response, sends a positive confirmation signal to application104of the first node. Application104of the first node forecasts a fire arrival time based, at least in part, on the positive confirmation signal. The positive confirmation signal may also indicate, for example, some or all of the environmental conditions detected by the second node. In another such embodiment, application104(operating, in various examples, on a node of distributed sensor network140or on registration server130) utilizes data from sensor array106of a plurality of nodes of distributed sensor network140to triangulate one or more of a position, shape, and speed of a fire. For example, application104determines the position of an edge of a fire by measuring the parallax of a point along the edge of the fire utilizing camera imagery from two nodes and the locations of the two nodes.

In some embodiments, node102monitors sensor array106(operation302) by monitoring for fire status messages from one or more adjacent nodes. Node102receives one or more fire status messages. In response, forecasts a fire arrival time (operation304). In various embodiments, node102forecasts the fire arrival time based on a time of the fire status message, a location of the adjacent node that issued the fire status message, or any combination thereof. The time of the fire status message is, in various examples, a time at which the adjacent node issues the fire status message or a time at which node102receives the fire status message. In another example, the fire status message identifies a location of the adjacent node. In yet another example, node102determines the location of the adjacent node based on data of registration data132.

In decision306, application104determines whether the fire arrival time is below a threshold. If application104determines that the fire arrival time is below the threshold, then application104issues a fire status message (operation308). If application104determines that the fire arrival time is not below the threshold, then application104continues to monitor input data (operation302). In various embodiments, the threshold is pre-determined, user-configured, or algorithmically-determined.

In operation308, application104issues a fire status message. In one embodiment, application104issues a fire status message to some or all communications address identified by the notification list. In another embodiment, application104issues a fire status message to registration server130(e.g., to registration program132), which issues the fire status message to some or all communications addresses identified by the notification list. In one embodiment, application104repeatedly or continuously issues a fire status message. For example, application104repeatedly issues the fire status message in response to repeatedly determining that the fire arrival time is below the pre-determined threshold (decision306, YES branch). In another example, application104continuously issues the fire status message until application104determines that the fire arrival time is no longer below the pre-determined threshold (or, for example, until application104is rendered inoperable, such as due to destruction by fire).

In some embodiments, if application104determines that the fire arrival time is below the threshold, then application104sends a heartbeat signal to at least one adjacent node (or, alternatively, to registration server130). In various embodiments, application104continuously or repeatedly sends a heartbeat signal (e.g., until application104determines that the fire arrival time is not below the threshold or until application104is incapable of sending the heartbeat signal, such as due to destruction of the node executing application104). In some embodiments, if application104determines that the fire arrival time is no longer below the pre-determined threshold, then application104sends an all-clear heartbeat signal and ceases sending additional heartbeat signals. The adjacent node (or registration server130) monitors the heartbeat signal (seeFIG. 4and accompanying discussion). In some embodiments, application104sends a heartbeat signal at regular intervals. In some embodiments, a heartbeat signal identifies a period of time within which application104will send the next heartbeat signal. In some embodiments, a first node sends a heartbeat signal to a second node, which, in response, sends a heartbeat signal to the first node, thereby creating a bilateral heartbeat link. In this case, the first node and second node monitors the heartbeat signal of each other. If either node determines that the other node is destroyed (see operation408and accompanying discussion), then the node creates a bilateral heartbeat link with a third node, which is another adjacent node.

In some embodiments, the fire alert includes an evacuation recommendation. In various embodiments, an evacuation recommendation identifies some or all of an evacuation route, a safe time remaining for an evacuation route, and whether an evacuation route is safe. In another embodiment, application104determines that no evacuation routes of node102are safe. In response, application104generates an evacuation recommendation that recommends seeking shelter locally (e.g., a “stay and defend” recommendation). For further details regarding evacuation routes and evacuation recommendations, seeFIG. 6and the accompanying discussion

FIG. 4is a flowchart depicting operations for distributed sensing, on a computing device within the computing environment ofFIG. 1, in accordance with an embodiment of the present disclosure. For example,FIG. 4is a flowchart depicting operations400of application104operating on node102within computing environment100.

In operation402, application104receives a fire status message. In one embodiment, application104receives the fire status message from an adjacent node that issued a fire status message. For example, the adjacent node issued the fire status message in response to an instance of application104of the adjacent node determining that a forecasted fire arrival time is below a threshold (seeFIG. 3and accompanying discussion). In some embodiments, the fire status message includes a heartbeat signal, as discussed above. In some embodiments, the fire status message identifies a forecasted fire arrival time and/or some or all node details (e.g., an identifier or a location) of the node issuing the fire status message.

In operation404, application104adjusts a status signal timer. In one embodiment, the status signal timer decrements a value representing time remaining. For example, the status signal timer counts down from five seconds as time elapses. The time expires based on the time remaining reaching zero. In one embodiment, application104receives a fire status message from an adjacent node. In response, application104adjusts a status signal timer by initiating a status signal timer for the adjacent node. In one embodiment, application104receives a heartbeat signal from the adjacent node and initializes a status signal timer with a value at least equal to the duration of time between heartbeat signals. For example, application104initializes a status signal timer for an adjacent node to ten seconds and the adjacent node sends a heartbeat signal every second. By initializing the timer to a value greater than the heartbeat interval, application104allows for missed or delayed (e.g., due to network latency) heartbeat signals, thereby increasing resilience against false positive node destruction notifications. In one embodiment, application104receives a heartbeat signal from an adjacent node with an associated status signal timer. In response, increases the time remaining for the status signal timer (e.g., by re-initializing the timer value to the initial value of the timer or by increasing the timer value by a pre-determined amount). For example, application104receives a heartbeat signal from an adjacent node that is associated with a status signal timer that has not yet expired and application104adjusts the status signal timer by setting the timer value to an initial value (ten seconds, in the previous example). In another embodiment, application104adjusts a status signal timer based on an amount of elapsed time. For example, application104decrements a time value of a status signal timer by an amount equal to the time that has elapsed since application104last adjusted the status signal timer. In some embodiments, application104ceases monitoring the status signal timer in response to receiving an all-clear heartbeat signal from a node with which the status signal timer is associated.

In decision406, application104determines whether a status signal timer is expired. If application104determines that the status signal timer is expired (decision406, YES branch), then application104generates a node destruction notification (operation408). If application104determines that the status signal timer is not expired (decision406, NO branch), then application104adjusts the status signal timer (operation404). For example, adjusts the status signal timer (operation404) by setting a time value of the status signal timer to an amount equal to the time elapsed since application104last received a heartbeat signal from the adjacent node associated with the status signal timer. In another embodiment, application104determines whether the status signal timer is expired (decision406) periodically (e.g., once per second, once per five seconds). For example, application104determines whether the status signal is expired in time intervals greater than or equal to the expected time between each heartbeat signal.

In operation408, application104generates a node destruction notification. In various embodiments, application104sends the node destruction notification to one or more nodes (e.g., an adjacent node), registration server130, or a combination thereof. In one embodiment, the node destruction notification represents a determination by application104that an adjacent node has been rendered non-operational, in which case the node destruction notification identifies the adjacent node. In another embodiment, a first node receives a node destruction notification that identifies a second node. In response, the first node removes the second node (e.g., or a communications address thereof) from a notification list of the first node. In yet another embodiment, application104generates a node destruction notification for an adjacent node. In response, marks the adjacent node as destroyed. For example, application104updates the list of one or more adjacent nodes of node102by setting the status of the adjacent to destroyed. In yet another embodiment, application104determines a fire arrival time for the adjacent node that application104determined to be destroyed, wherein the fire arrival time is based, at least in part, on the time at which application104received the last heartbeat signal from the node and the time at which application104expected the next heartbeat signal from the node. For example, application104determines a fire arrival time for the adjacent node as the average of the time at which application104received last heartbeat signal from the node and the time at which application104expected the next heartbeat signal.

FIG. 5is a flowchart depicting operations for distributed sensing, on a computing device within the computing environment ofFIG. 1, in accordance with an embodiment of the present disclosure. For example,FIG. 5is a flowchart depicting operations500of application104operating on node102within computing environment100.

In operation502, application104forecasts a fire arrival time for one or more waypoints of one or more evacuation routes. For example, application104forecasts a fire arrival time for each waypoint of each evacuation route associated with node102. In one embodiment, application104forecasts a fire arrival time for a waypoint as described above in connection with application104forecasting a fire arrival time for a location to monitor.

In decision504, application104determines whether the fire arrival time for a waypoint of an evacuation route is below a threshold. In various embodiments, the threshold is pre-determined, user-configured, or algorithmically-determined. If application104determines that the fire arrival time for the waypoint is below the threshold (decision504, YES branch), then application104marks the evacuation route as unsafe (operation508). If application104determines that the fire arrival time for the waypoint is not below the threshold (decision504, NO branch), then application104determines the safe time remaining for the evacuation route.

In operation510, application104determines the safe time remaining for the evacuation route. In one embodiment, application104determines the safe time remaining for each evacuation route associated with node102. In another embodiment, application104determines the safe time remaining for each evacuation route that is not marked as unsafe. In one embodiment, application104determines the safe time remaining for an evacuation route based on a fire arrival time for each waypoint on the evacuation route, in which case the safe time remaining for an evacuation route is the least of the fire arrival times.

In some embodiments, application104ranks the evacuation routes for node102. In one embodiment, application104ranks the evacuation routes based on the safe time remaining for each evacuation route. For example, application104determines which evacuation route is the safest, which is the evacuation route with the highest safe time remaining. In some embodiments, application104determines the safety of one or more evacuation routes of another node. For example, node102ais located geographically proximate to node102b. In this example, node102ahas no evacuation routes (or no safe evacuation routes). Application104areceives one or more evacuation routes of node102band determines whether the evacuation routes node102bare safe. In one such embodiment, application104determines whether an evacuation route of an adjacent node is safe in response to application104determining that node102has no safe evacuation route. In this embodiment, application104may also determine a route from the location to monitor to the location to monitor of the adjacent node.

For example, node102is located adjacent to a home of a user and is associated with a first evacuation route leading south from the home toward a first highway and a second evacuation route leading north from the home toward a second highway. Registration data134stores the first evacuation route, which includes a first waypoint and a second waypoint. Further, registration data134stores the second evacuation route, which includes a third waypoint. In this example, application104of the node (or, alternatively, of registration server130) monitors sensor inputs from one or more nodes. Application104determines a fire arrival time for node102and for each waypoint of each of the first and second evacuation routes, based on which application104determines a safe time remaining for each evacuation route. In response to determining that an escape route is safe, application104generates a recommendation for a user to follow the escape route. Alternatively, in response to determining that no escape route is safe, application104generates a recommendation for a user to prepare shelter.

FIG. 6is a block diagram of components of a computing device, generally designated600, in accordance with an embodiment of the present disclosure. In various embodiments, computing device600is representative of node102, registration server130, or user device150. For example,FIG. 6is a block diagram of components of node102executing operations of application104within computing environment100.

It should be appreciated thatFIG. 6provides only an illustration of one implementation and does not imply any limitations with regard to the environments in which different embodiments may be implemented. Many modifications to the depicted environment may be made.

Computing device600includes communications fabric602, which provides communications between computer processor(s)604, memory606, persistent storage608, communications unit610, and input/output (I/O) interface(s)612. Communications fabric602can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, communications fabric602can be implemented with one or more buses.

Memory606and persistent storage608are computer-readable storage media. In this embodiment, memory606includes random access memory (RAM)614and cache memory616. In general, memory606can include any suitable volatile or non-volatile computer-readable storage media. Software and data622is stored in persistent storage608for execution and/or access by one or more of the respective computer processors604via one or more memories of memory606. With respect to node102, software and data622represents application104, data collected by application104from sensor array106, and user interface110. With respect to registration server130, software and data622represents registration program132and registration data134.

Communications unit610, in these examples, provides for communications with other data processing systems or devices, including resources of network120. In these examples, communications unit610includes one or more network interface cards. Communications unit610may provide communications through the use of either or both physical and wireless communications links. Software and data622may be downloaded to persistent storage608through communications unit610.

I/O interface(s)612allows for input and output of data with other devices that may be connected to computing device600. For example, I/O interface612may provide a connection to external devices618such as a keyboard, keypad, a touch screen, and/or some other suitable input device. External devices618can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present invention (e.g., software and data622) can be stored on such portable computer-readable storage media and can be loaded onto persistent storage608via I/O interface(s)612. I/O interface(s)612also connect to a display620.

The term(s) “Smalltalk” and the like may be subject to trademark rights in various jurisdictions throughout the world and are used here only in reference to the products or services properly denominated by the marks to the extent that such trademark rights may exist.