Forest Fires, IoT and Edge Computing

Greetings,

I had posted recently about the potential of IoT and Edge Computing to provide an early warning system for forest fires, particularly of the magnitude of the ones seen in California. Let us mull over some of the design considerations. A few architect type and thinkers get together....

Tech Head: "So tell us how you think an IoT Solution would build an early warning system"

IoT Head: "Well, some kind of sensors would need to be deployed - that alert when there is fire, either temperature rise or monoxide. And these sensors once triggered, would notify the fire-department(s), who then would notify the people in the path, besides calling for resources to put out the fire".

Tech Head: "How would these sensors notify the fire-department?. Why not do that and also use mobile and social media ?"

IoT Head: "Noted. Via a network and software platform somewhere, of course. The state of fire would be a small data set. Then if multiple sensors report the same and there is geo-location and based on the time-stamp, it is pretty straight-forward to conclude that A) There is a fire, B) It is moving in a particular direction and C) At a particular speed. Thus a)Logic about state of the fire and then b)Alerting the appropriate bodies"

Tech Head: "Whoa, slow down. We are talking about rugged terrain in the outdoors here with many places with no power and no cell phone network. The Nor Cal fires were over 200,000 acres at several points"

Network Head: "And no fiber buried, to connect cell phone towers and base stations"

IoT Head: "Yes, I hear both of you however there are sensors that work off a battery. Some of them can have a 15-20 year battery life. The challenge may be if something like a coyote or a bear say, were to damage one."

Tech Head: "Yes, but I have never heard of wireless cell phone networks supporting battery powered sensors"

Network Head: "That is where we have Low Power Networks coming in. They support low power devices with low data rates". Starts to sketch..."This is how IoT has driven the need for new networks, besides Ethernet, Wifi and LTE, under the triple constraint of Data, Range and Power".

IoT Head: "Brilliant, yes we would need sensors that last a long time without power and connected to a low-power wireless network. One would need some event processing that decides if there a fire and moving at what speed in a particular direction. One would also need some logic or construct to manage the sensors. At a minimum, we need to know which sensor stopped working due to something other than a fire. All of this has to work in a reasonably timely manner"

Tech Head: "What you allude to is perhaps called device management, similar to mobile phones, in which case the network operators activates the phones and know about their state of usage, connectivity, location and other data points".

Network Head: "Yes, but some of these sensors are not even on all the time. To conserve power they go into a sleep mode and are disconnected from the main network and any computing platform at the end of it. . So the network and platform need to support disconnected mode and also manage the state of devices"

IoT Head: "Yes, the event processing that decides about existence and the state of fire, and does further notification to fire-departments and citizens probably needs to be on some computing platform, not necessarily in the immediate vicinity of the sensors as long as the data set gets there in timely manner. But the construct that tracks the state of devices has to be somewhat redundant and "nearby" to the sensors/devices working with short-range networks."

Network Head: "What you are talking about then is overall latency between sensors and end notification to people. This traffic is one way with no round-trip actuation."

Tech Head: "We still haven't figured out what is the reach of the low power network and the range of its antennas from where there is power and fiber. It would seem this would be the "Edge" of the Network - where power and fiber end. Perhaps a set of wireless repeater stations, but still need power even if we could sacrifice data rates."

IoT Head: "Yes, one can have the complex event logic and integration done between the Clouds and Data Centers somewhere, obviously lower the latency the better. But a snapshot of the logic should be in the vicinity, at the "Edge" of the network periphery. However without power, it may be a problem, while the sensor can run off batteries, the "Edge Construct" likely can't. It also would need to be kept at the right temperature range given it is outdoors."

Network Head: "I guess we can have different type of "Edges" that work with different type of networks, power and data rates"

IoT Head: "While we talk about latency and like to have it below 10ms for notifications like this, what happened in some of the fires, had it worked, could have tolerated minutes of latency. People weren't notified until very late, until the fire was at their door, and this appeared to be a case of systems and processes not integrated well and not so much latency actually. But obviously sooner is always better"

Tech Head: "Lets get our focus back to the core design. So it would seem this "Edge Construct" you talk about needs to be A) Weather Hardened, B) Be able to support some basic compute, storage and network infrastructure, C)Be connected to devices via some access network, perhaps low-power D) Be connected to a data-center or cloud or both on the backend, depending on where the emergency systems are notified and E)Having the power redundancy and F) Have a appropriate method to keep temperature optimal for the hardware to function"

Network Head: "That sounds like a small Edge Data Center to me"

IoT Head: "Right On. We also need an Edge software to run on this "Edge Construct". This software would communicate with the devices and work in disconnected mode and also signal the Cloud/DC platform about device status"

Tech Head: "This software can run on the compute then and its messages can aggregate with the notification event system upstream in to where the the EMS systems are hosted (Cloud and/or Data Centers). Then these platforms would have to notify people via several methods - Social Media, Email, Mobile, others"

IoT Head: "So are you saying we could have a few types of Edge Topographies ? Like maybe a Gateway device and an Edge Data Center or both. Why not route from A) Sensor to Gateway to Data Center/Cloud directly or B)Sensor to Gateway to a Data Center/Cloud or C)Sensor to Gateway to On-Premise DC"

Tech Head: "All of the above sound like valid use cases to me. There are other Edge use cases also. but for this solution, the above seem right. Now, how would something like this be funded?"

Sales Head: Joining in with a smile, "My property came close to being burned, in fact the fires came to my fence line in Sonoma. Working backwards, the question may be How much would someone like me be willing to pay for peace of mind knowing such a system was in place. Maybe $30-$50/month. So suggest develop a subscription based model like a home security service".

Satellite Network Head: Overhearing the conversation from the next table, "Perhaps a terrestrial network won't be enough. You may need to connect to a satellite network. Send the fire status data to a uplink, then aggregate the fire status data down to a Cloud Data Center connected to the EMS/Fire Systems via a fast network !"

Network Head: "So we would need the low power sensors to work with a satellite network". Looking at the IoT Head, "This 'Edge Construct' you talk about would then need to be able to do that".

IoT Head: "Well, beyond simply getting the fire status to a platform where it can be deployed to users, this is where the complexity starts to rise, we have different social media platforms, phone systems (mobile and land) as well as fire departments (likely in different data centers). These systems have to aggregate the information quickly and they likely need to inter-connected via quick networks."

IoT Head: Looking at Satellite Network Head "I need to understand the latency and data-rates some more. Lets keep in touch on LinkedIN."

The above conversation could have occurred anywhere, maybe at a restaurant on Emerson Street in Palo Alto, or at SXSW in Austin....

It is good to know there is mind shift around this happening already, one more use case here..

#IoT, #EdgeComputing, #LPWAN

Note: The above does not represent the view of any employer or business partner, past of present